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.

F1 hasnt been a sport for years.

I dont know of another sport which changes fundamental rules mid-season just because one team is dominating. In F1, it has happened many many times.

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.

It is a good example, because its someone who was never in the US being charged, tried and jailed in the US for an alleged crime against a British company.

Dual criminality means that the act that they are being extradited for is also an offence under UK law. It does NOT mean that they actually broke UK law. And in the case I am thinking of, they were never prosecuted in the UK. Thge UK-US extradition act is also severely lopsided, with a firm case having to be presented to extradite from the US, but only reasonable suspicion being required to extradite from the UK.

That is part of the English language, used extensively in England, and not pronounced the way its spelled.

Literally just picking a few place names from where I used to live in the UK, and you get:

Happisburgh - dates back a thousand years.

Wymondham - dates back approximately 1,500 years, and originates from an Anglo-Saxon name.

Costessey - originates from around 600AD, and again originates from an Anglo-Saxon name.

"Lieutenant" (and numerous other words) wants to have a word with you :)

Note that the US has, multiple times, extradited people from the UK in order to try them in the US, for actions done in the UK - simply because they breached US laws and somewhere in the chain there was a US connection.

The US loves fining foreign companies as well, including major banks like HSBC, for breaching US law.

The US has also confiscated transactions between two Europeans who carried out a transaction in two countries outside the US, simply because they breached the US embargo on Cuba and the transaction was done across the SWIFT network.

In other words, the US loves to do what it complains about here.

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.