In Dune wurden die Computer schon hunderte Jahre vor den Ereignissen der Handlung zerstört. Die ganze Technik ist analog und alles was auch nur in die Nähe eines programmierbaren Informationsverarbeitungssystems kommt ist verbannt. Der Versuch der Herstellung ist eine der schwerstmöglichen Straftaten.
Trouble is: Those smart devices usually come with WiFi, and it's become common that ISP-owned-and-supplied routers will offer hotspots. You can bet, that the makers of smart devices are going to strike deals, to get by-default access to those hotspot WiFi access points, if they're not connected explicitly to another network to spy on.
So the recommendation is: Do not power on ANY smart device within (radio) shouting distance to your home/network.
Yes, indeed. I did invoke that just for the sake or argument; the argument being, that the whole IP status would be extremely difficult to evaluate even if it were the much simpler case the system not being trained on a vast corpus of data with unclear copyright status.
Yep. Even if we set aside the whole plagiarism problem associated with LLMs, the mere act of commissioning a 3rd party with writing source code according your your specifications has deep intellectual property law implications. Who holds the copyright and authorship rights of the commissioned work? Are the binding contracts in place that concern the terms of redistribution and reuse of the work?
3rd party in this case refers to the companies offering the LLM services.
And just for the sake of discussion, assume you're running a local model, and for the sake of argument can also prove that it doesn't plagiarize: What's the IP status of source code that is manufactured mechanically from a prompt? Is it a transformative process as running it through a compiler?
Or is it akin to a selfie photograph taken by a monkey?
I second that recommendation (@mcc I see that you've already starred that post of mine, where I made that assessment a couple of days ago).
My prognosis is, that once we come out on the other side of the inevitable AI bubble core collapse event Linux development will likely revert to 6.18, back-porting the most important security fixes, and otherwise just discarding the slop.
I've pinned all of my systems to 6.18-LTS, and that's what I recommend everyone else.
Back on topic: The fact that something like Flock cameras is actually legal to operate in the USA is disturbing. And sets a very, very bad precedent.
Right now in Germany we still have kind-of (they're weakening) protections of public spaces. It is illegal to install surveillance cameras that cover public spaces, without going through a permit process. A private property owner who has one of their cameras picking up public space without permission is committing a felony.
Oh. Uh… wouldn't that be then "Orwellian", since the name of the author is Orwell?
"1984", "Animal Farm" (borth Orwell) and "Brave New World" (Huxley) are among the books that had most influence on my personal development in teenage years.
(just for the record: My native language is German)
Anyway, the GPU-is-also-display-adapter model has been dragging down computer architecture and still is to this day.
There's an important difference in doing highly complex rendering sourcing large set of data ( >100 MiB per frame), and just throwing a couple of simple-ish primitives onto a UI.
GUIs should be fully representable as simple draw lists (see e.g. ImGui).
Yes, no modern X11 app will submit draw commands because of ill-advised group think and most developers seemingly turning off their higher brain functions when writing graphics related stuff.
This is not an X.org issue. GPU clients locking up the GPU have been known for a long time and on every platform that have APIs that grant a direct channel to the GPU.
Windows has a watchdog timer, reseting the GPU if it gets stalled by more than 250ms. macOS as a watchdog timer doing the same thing.
X.org is not a special citizen. It's been using the very same interfaces to kernel land as Wayland-land does as well (DRM). If X.org can lock up drivers in kernel code, so can Wayland. Which is then a bug that should be fixed DRM side in the kernel.
Do not use GPU rendering if your application doesn't absolutely need it. Are you writing a text editor? Don't use the GPU. Are you writing a terminal? Do not use the GPU! Seriously, Terminology and Alacritty should never have been created.
Are you writing a CAD program, or a 3D modeller? Then of course use GPU APIs.
Are you writing a massively parallelizable signal processing system. Yes, then using the GPU is called for.
I thought so for a very long time, too. Until I started developing applications that push a sustained stream of >100 GBit/s from digitizer to GPU for realtime signal processing and visualization.
Your mental model of a GPU should be co-processor, not programmable display-interface.
It took me a while, too, to come to realize that. But technically GPUs shouldn't even be on the cards we plug displays into.