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.
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...
I had a similar issue, but I ended up installing Debian and running Windows 10 as a virtual machine with VirtualBox. The webcam can be accessed as if were installed on the guest OS and haven't had a problem with Zoom or Teams. Just sharing in case it helps.
I considered that but is is such a waste of resources in my case: I deliberately use a lighter laptop that just covers my dev needs.
But yes, this is a possibility, or accessing the windows via rdp. The loss would be with the "always-handy" kind of setup, where Outlook is a click away and pops up its calendar reminder
Exactly. This is the best example of what Windows 11 is. I have the feeling that Microsoft is trying to bring change at the same time that it cannot, and has to come up with workarounds like this one. This would explain the Settings panel like someone mentioned in this thread.
Another thing that I dislike (with all due respect to developers of React) is this migration to React and Reactish behavior of Windows. We have been fine with Win32 after so many years. Why change that, other than wanting to stay "relevant" or "modern"? Just my opinion.
Thank you for sharing. I have always found Japanese focus into the smallest detail as something worth of the greatest admiration. And I am always trying to learn from those ways to apply it into my life.
Very nice game. Barely made it to getting to the office and receiving orders from a manager. I could completely relate to the "hot desk" experience, that's something that would irritate me. I do not claim to be in the spectrum, nor have any diagnosis to claim or reject it. Again, congratulations for the game and the feeling.
Just adding this comment to say congratulations and how impressed I am by your project! I've been an OS Dev fan since my teens and it feels great to see this achievement come to life. I am a little curious to know how the graphics subsystem is initialized. I wish you the best of success.
I completely agree with you. Let's add to the fact that volume, being three-dimensional, is being represented on two dimensions (graphics on a computer screen), which might cause some loss of perspective, fundamental for comparison. Perhaps a better way to represent it would have been the volume of inhabitable land (as you suggest) vs the volume of available water but extrapolated to two dimensions?
reply