parker_mountain

Feature, not a bug. "Want support? Pay us."

> experimental attempts emphasizing ease of use

yes, i would define them very much as experimental

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.

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.

> irrational bias

Then say it. :)

> 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.

And it has been that way for years.

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.

> But Android also lets you run custom builds

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.

It's good that they do but it's not enough.

> If everyone else paid taxes like Zuckerberg, we’d have a lot less money in our pockets.

Tell ya what, you give me enough money for me to pay taxes like Zuckerberg, and I will /happily/ give you back half of whatever is leftover.

I'm not sure if you're familiar with how Touch ID and the secure enclave works?

Not open, not transparent, makes a bunch of claims without backing them up. If this was a side project, I'd be more forgiving. If it was someone's attempt at building their own signal, and was open source, and wasn't being billed as a real company, I'd be more forgiving.

> Widely reviewed Open Source Public Key Cryptography and App itself can be fully audited and accredited

But, this is a slick looking web page with a slick looking app and a bunch of appeals to authority and even an "endorsement" from the EU (whatever that means).

Do not use this app.

Gosh, there's so much wrong here.

> weird slow proprietary

They're often not weird, a simple single task runner with a few libraries to handle common tasks and cryptographic operations. Very simple, lightweight, and they generally share a common high level architecture (there's not much variation in an RTOS)

They're often not slow, they're minimalist OSes - barely qualifying as an OS if at all - designed to run a single task, with time guarantees, and to get out of the way. In fact, if it's a single task you need to run, they're faster than any general purpose OS - by design!

They're often not proprietary - a handful of RTOS with huge market penetration used in billions of devices (and now ThreadX) - are open source and have permissive licenses. What IS often proprietary about them are BSPs, but that's a whole separate issue. Yes, there are a lot of proprietary ones out there, but as a blanket statement, it's simply not true.

> readers run antiquated Android

Many use a stripped down version of AOSP, which has become a de facto standard BSP, yes. But many, many others do not (usually a flavor of embedded linux, or an RTOS).

> about some HP printer running buggy custom OS

It was a Xerox printer, and it was because he was frustrated from adding existing job management and notification features he had written to the new printer.

Google says "regulatory uncertainty". It sounds like they're unhappy with Canadian regulators. Be thankful your government is giving them enough grief.