He shot himself 2 days before they found him. This is not some triumph of technology. It's not a victory for the FBI. He shot himself with time that he could have used to escape or shoot some other people.

I very much doubt it since the OS is just the bit on top of which the EPG, web apps, DLNA client and all the rest run. Not to mention the drivers that tune the TV, set the input / outputs, listen to IR, configure wifi etc. I also expect the OS and proprietary software is all running from a partition protected by a bootloader and there is a small amount of writable flash for storing preferences and downloaded apps. It's possible there is a serial line on the board or a port knock which would open up the TV for hacking.

Safe by default quite obviously implies you can turn the safety off, and to be useful as a systems programming language there must be a way to turn it off. I don't see it as being a hard concept to learn and frankly most of the people who try and split hairs are either ignorant of the language as a whole, in denial that safety is a problem (it is) or are just shit posting.

I have no idea what comment you are referring to. I see you linked to a "Unsafe Rust is harder than C". Harder != worse. Especially when the article is referring a specific use case in a heavily asynchronous application. I doubt anyone would even dare use C like that so the author's complaints about trying to pin lists in futures is kind of moot because you wouldn't dare use C that way without suffering a world of hurt on issues with (lack of) lifetime checking, borrow checking, move, sync+send, pinning etc.

Unsafe Rust is not worse than C. Even in an unsafe block the compiler does borrow and lifetime checks so it is still safer than C. The unsafe keyword enables access to pointer & memory manipulation / copy / transmutation functions. Programmers use an unsafe block where it's calling C, or dealing with hardware address memory or whatever where it needs to manipulate memory to deal with that external system. The rest of the time, the default for the majority of code, it is not in an unsafe block.

While I am sure you could abuse unsafe and make your code as liable to crash as C, best practice is to avoid unsafe at all costs and only use if it *must* be used. And if your code *does* crash, then the first course of action is grep for "unsafe" and most likely one of those blocks is the culprit.

And I expect even if the 20% claim were true we'd look at the crate in the majority of cases the usage is because the crate wraps some C function call. I can only think of one case where a popular high level crate was using unsafe beyond necessity which was actixweb for "performance reasons" and it received a lot of attention and almost all of the unsafe blocks were excised. I think there are about 7 unsafe blocks consisting of a few lines each left in quite a substantial codebase.

No it isn't. Unsafe blocks still do borrow & lifetime checks. In C or C++ it would be trivial to call a dangling pointer/reference or to inadvertently free something more than once. Also, the entirety of C and C++ is unsafe by default whereas Rust is safe by default. And even if you needed to use unsafe, when strictly necessary, those blocks stand out like beacons if there is an issue.

It's actually incredibly easy to avoid for the vast bulk of code. The only place it is typically seen is when Rust has to call some C library, or has to do something low level. For example, some C function wants to take an address to something and Rust has to use unsafe to do that work.

And if you're seeing unsafe in packages then most likely it is because that's what they're doing. Even a few unsafe blocks is infinitely preferable to everything being unsafe. As an example I developed a project over 3 years with tens of thousands of lines and a couple of unsafes. It crashed once. That was due to me calling an openssl function with the wrong arguments. Since I only had a few unsafe blocks it was very easy to identify the issue and fix it.

Rust by default does not let you manipulate pointers or memory. When you enclose something in an unsafe block you can do that stuff. It's basically like a superuser command granting you extra powers. Using unsafe strongly discouraged and most Rust code doesn't need or use it. Where you have to use it is where you're interacting with external code (e.g. a C library), or hardware.

One misconception is that unsafe is throwing away all the safety guarantees that normal Rust provides, but it doesn't. You still get borrow & lifetime checking within the unsafe block. So unsafe Rust is still safer than C or C++.

And more than likely as soon as the issue was discovered somebody grepped for "unsafe" and narrowed the issue down in a fraction of the time.

That's exactly it. Python has built an ecosystem of libs for AI probably for the reasons you say but it is still the absolutely worst platform to be doing AI or machine learning from.

In fairness, Python is somewhat better than BASIC given that it's portable, supports functional programming like lambdas, has decent slicing and other conveniences.

But at the same time it's also a very poor choice of language to actually write anything substantial in. Performance blows and it doesn't scale. Multithreading is especially bad and even if they fix that, code is liable to break in all sorts of racy ways due to the body of code out there. Package management is a disaster with workarounds using virtual environments and other nonsense to get around the globalness of packages. Typing (or rather hinting) is an afterthought and a lot of code barely bothers with it. Lack of strong types bleeds into truthy/falsely, e.g. empty arrays being considered False.

What gets me is Python being most popular for LLM programming when it is possibly the slowest mainstream language in existence. AI is probably bolstering Python's popularity but really something like Rust would be far more suitable for that purpose.

Some lazy ad firm clearly just wrote extended prompts in the vein of "draw a scene of a woman carrying christmas presents slipping in snow and falling over" etc and concatenated the least worst clips together. That was the extent of their effort.

In which case switching back is just as "wasteful". And Rubio gets to punch down on the visually impaired in the process. I'm sure it won't end in a series of costly and "wasteful" lawsuits. Great job.

These foldable / rollable screens are so easy to destroy and so expensive and complex to replace that the entire device effectively becomes e-waste when it happens.