thyristan
Joined 2 years ago
Joined 2 years ago
There are also various reports of things like running e.g. Fedora on an FP6, https://www.notebookcheck.net/Fairphone-6-turns-into-a-Linux... or Debian on FP4/5, but those generally aren't something that is usable due to lacking support for basic things like calls.
Great idea, I will definitely do this!
The user is supposed to have read Meta's terms and conditions and agreed to them. Of course nobody does that, but that doesn't absolve of the responsibility, it rather means that the user who uploads stuff to Meta does things in full knowledge and willingly or carelessly. It just might make Meta liable as well, because naturally their terms were sneaky, hidden, unclear and probably illegal.
And I'd guess that Meta Ireland has been sued often enough that they have some export clause deep in their conditions as well, which the user should also have read and agreed to.
I'd guess that the glasses first transfer the recordings to Meta who process and store them abroad for various commercial purposes. That way of working can never fall under the household or journalistic exemptions. And per GDPR the owner of the glasses is on the hook for whatever Meta is doing, because the owner is (by GDPR) contracting Meta to do data processing for him/her.
Edit: if you need proof, 2 for 6.50€, shipping included: https://www.ebay.de/itm/277671545941
Not an LLM problem, just an undecaffeinated meat brain and some faulty memories. I've misread 'When PS=0, the page table address field represents the physical address of the page table that manages the four megabytes at that point.' to mean that when PS=1, the address isn't physical. But PS is page size... And I somehow remembered that you could induce pagefaults when walking the page tables...
Sorry.
Nope. Not on x86. You can use either physical or virtual addresses at your choosing. Consumer OSes use virtual ones, so you can swap out page tables (yes, really!). See https://wiki.osdev.org/X86_Paging "Page directory".
All the siblings might talk a lot about "but ruggedized!", "but realtime!", "but supported!".
But in many cases, it is just a case of vendor lock-in. Ruggedized is just a casing and decoupled I/O-ports, you can get that for your Raspberry Pi. Realtime is a concern, but modern PLCs aren't really realtime anymore. Those are usually some big multicore non-realtime ARM, plus some small realtime-capable I/O-processors that do the really time-critical stuff. Or even just a CPLD to implement some trivial ladder logic cycles. Support matters, but if your PLC vendor goes bankrupt you've drained a few millions. Might be better to get something cheap where you can just stock up a few hundred replacement parts for cheaper.
That's why actually, a lot of smaller PLCs are Raspberry Pi CMs now. The vendor won't tell you, but if you open them up, you'll see.
And the big customers also wised up to the PLC scam and are now moving towards putting their control tasks on standard x86 hardware in the shop floor basement plus realtime ethernet with cheap I/O extenders on the shop floor. Which is why the big PLC vendors now try to sell "virtual PLC" to those customers, so they get at least a little money instead of none ;) https://www.siemens.com/en-us/products/simatic/s7-1500v/
https://www.knipex.de/schaltschrankschluessel?v=2921
Real locks in such systems are rare, sometimes even disallowed. Usually, a lock with a real key is only used to temporarily prevent switching on a machine during maintenance or such.
Leads to x86 page table MMU magic being turing complete: https://github.com/jbangert/trapcc
And the simplest thing you can do on such a system is just to loop indefinitely, thus creating a simple instruction with a memory access (mov or anything, doesn't really matter, even the instruction fetch for a nop would work) to take infinite time.