In any normal deployment, you're probably not going to be pushing even a 1.5gbps through these during heavy use. The real benefit of 7E is reduced latency, not bandwidth.
If you need high throughput, they and other vendors sell that.
There are tons of 10gbps PoE switches on the market.
I'd say that if you're trying to find the Mint/Ubuntu/Zorin/elementary of BSD, then it's not really for you. The BSD ecosystem isn't really driven by ease of use, today they're more interested in various niches - hardware appliances, OS research, etc.
If you're curious about what unix is and what a bsd is, I would recommend netbsd or openbsd in a vm.
Well of course they're not trying to replace macOS, for instance, but when an OS gets big enough to have offshoots and different front-ends and desktop environments and so forth, one would assume there are at least experimental attempts emphasizing ease of use, just like there are experiments to develop offshoots for any other purpose, from power users to pen testers. At least like, someone's toy project on GitHub or SourceForge. I just assumed BSD was big and well-established enough to have such efforts.
Besides GhostBSD, looks like there's also Lumina, MidnightBSD, FuryBSD, and TrueOS/Project Trident?
I work for a large consulting company that does work all around the world. From what I've seen, the midwest appears to have a pretty heavy use of .NET and other Microsoft technologies. Very large banking and insurance companies moving their .NET code bases to Azure. As you move further to the coasts, AWS takes over more as the cloud provider of choice for most enterprises and you see a lot more Java. Right now I'm looking for .NET + Azure architects in Iowa, Nebraska, Minnesota, Kansas and Illinois.
I can think of a lot of reasons why companies and startups would find it bad for their use cases tbh. It's hamstrung by microsoft licensing and ecosystem, and while building tools for enterprisey stuff is great, web-style startups are more of the focus here.
> If there is a factory that allows a worker to step in front of a robot and depends on a wireless communication mechanism for safety, something is very very wrong.
All of those robots leave enough threshold to avoid collisions with other robots should they need to stop suddenly. The robots do on device calculations and report back their status to the central server to help other robots route around "damage" (stopped robots, for example). Instead, they give the robots general path instructions with enough buffer area to allow the robots to not trigger their own on device collision sensing. In the links that you gave, it's very clear that the robots do not depend on communicating with a central server if a worker steps in front of a robot.
By the way, in warehouses without such advanced protection, humans are _absolutely_ banned from the floor and it's treated like any other large industrial scale operation, including fail safes on gates (if gate is open, do not allow restart and human presence sensing (often through a badge of some sort).
Failure of this sort would lead to massive liabilities to the warehouse and robot owners. They are heavily incentivized to do things the right way. I'm not saying it's perfect, but it's actually quite advanced and safe.
Anyone who's worked out on a regular basis can confirm this. And it's not just anecdotal, significant components such as creatine simply don't exist in vegan meals without supplements.
As an ex-vegetarian (who rarely eats meat now), I'd love to see more research into this and what's missing. Also, what needs to be done to supplement a vegan/vegetarian diet for exercise is pretty well known.
But this "study" of a small sample size confirms what has been pretty much completely and unambiguously known for decades. And it's meat industry funded. Nice.
Yes, but that is only one component of a modern phone. Basebands and system bootloaders, among other firmwares, don't receive updates. Those are regularly attacked.
> In our work, we present seven attacks against the cryptographic protocols used by Threema, in three distinct threat models. All the attacks are accompanied by proof-of-concept implementations that demonstrate their feasibility in practice.
> We disclosed our findings to the Threema development team on the 3rd of October 2022, including possible mitigations for the attacks. Soon after, we met with Threema representatives to discuss our work and its public disclosure. On that occasion, we agreed on an initial batch of mitigations to be released in Q4 of 2022, followed by the public disclosure and final mitigations to be released in Q1 of 2023. In December 2022, we agreed on the 9th of January 2023 as the date of public disclosure.
> On the 29th of November 2022, Threema released a new protocol, Ibex, in order to further mitigate our attacks. The Ibex protocol aims to provide forward security for the E2E layer in Threema. We have not audited this new protocol.
I wonder if the new protocol would survive an audit
