I watched this movie and missed that this was mentioned. Funnily, I am from and live in Nicaragua and find it funny that we have no such land formation. I am assuming that is the point you are trying to make.
> I am assuming that is the point you are trying to make.
Not exactly. My point is that LLMs dramatically increase the danger and risk of certain types of manipulation, fraud, and brainwashing. Those things will become much easier to do cheaply and secretly and at a large scale.
The Truman Show offers a useful way to convey those kinds of risks, but the details of the product being sold doesn't really matter, we just need to know that the company is willing to do those kinds of things.
> no such land formation
I'm sure the script-writers knew this. I believe they chose it because they wanted to make a satire (mocking joke) of real-world coffee-products being sold at a certain time, but did not want to include details that that some real-company (or country) could get too angry about.
As a speaker of English as a second language and being educated using American English, I find British English richer in a cultural and expressive manner. It also conveys more properness.
I boot my computer every time I will use it and shut it down when I am done. No matter whether on Linux, Windows, or Mac. It's a mindset thing: I will sit at the computer, do what I have to do and then shut it down. Just sharing my way of using it.
From a completely technical standpoint, is systemd really better than SysVInit? I ask this question in good faith. I have used both and had no problems with either, although for personal preference, I am more traditional and favor SysVInit.
I always dreaded trying to create a service with bash-based init scripts. Not only did it involve rolling a heck of a lot yourself (the thing you were running was generally expected to do the double-fork hack itself and otherwise do 'well behaved daemon' things), it varied significantly from distro to distro, and I was never confident I actually got it right (and indeed, I often saw cases where it had most definitely gone wrong). Whereas systemd has a pretty trivial interface for running most anything and having some confidence it'll actually work right (in part because it can actually enforce things, like actually killing every process that's part of a service instead of kind of hoping that killing whats in the PIDfile is sufficient).
Your link is irrelevant.
It points to OpenBSD which uses rc, not sysv.
The 3 lines of this rc startup script use a file of 400 lines of shell with commands that don't exist in SysVinit.
With sysv, the difficulty depended on the local tools because the launching scripts could not be shared across Linux distributions. Debian used the compiled helper `start-stop-daemon` while Redhat did not.
With sysv, some sysadmin tasks require external tools. Try to write a launching script with a smart autorestart in case of crash. Make it work even when the daemon forks. Do not assume that the daemon writes its initial PID anywhere. IIRC, to get this feature, we had to drop sysv for runit, two decades ago. Now it's just 2 lines in a systemd unit.
Init and run control aren't the same thing. Which is part of what's nice about sysv (which, yes, OpenBSD's init is based on). OpenBSD's run control system is particularly nice, and it's the sort of thing you can use with an init system that isn't constantly eating everything.
It's probably straightforward for someone who works with it. For a newb like me, it needs effort to understand. I think unit files are self-documenting and straightforward to understand the first time you see them.
Not sure how much it could help, but is there a possibility you connect the SSD to another machine with the same architecture, run Windows install in it, then once Windows is installed and running, shut down, move the SSD back to the Snapdragon kit and attempt to boot? Just an idea...
reply