You made it to The Verge. Congratulations! This is a big moment for phoronix and desktop linux.
systemd 255 Released With A "Blue Screen of Death" For Linux Systems
Collapse
X
-
Originally posted by ojsl1 View PostWtf is wrong with the current black and white panic and oops screens, how is systemd-bsod an improvement other than just hurr durr colors equal better brand identity. Are distros going to start invoking systemd-bsod when unrecovable gpu or xorg freezes/lockups occur?
Originally posted by ojsl1 View PostOT: Its funny how in my whole previous life of using windows it was fleetingly rare for gpu crashes to require a complete reboot - unlike on linux where its next to unheard of for gpus to recover from crashes.
Other than all that the much bigger headache for linux newcomers is the issue of booting into blinking cursor and/or a black screen and the tens of reasons that could have caused it. People (other than me) arent going to spend ten minutes (not to mention hours) googling for why their system is stuck on boot when they can just quickly install windows again.
Comment
-
-
Originally posted by Almindor View PostOk that one goes in the book. And unlike the 640k one this one was actaually uttered by someone!
It's like saying today that 64 GB is more than enough, when talking to artists using Photoshop. And it is.
Comment
-
-
Originally posted by LightBit View PostCan we see screenshot of it?
This is an example from a VM, produced by 'sudo logger -p EMERG …'.
Comment
-
-
Originally posted by user1 View Post
Sorry, I meant slowdowns with website loading. Sometimes the whole website takes ages to load. Other times, if certain websites load quickly, some of their elements still take ages to load. And it's related to the Github issue in my previous comment. When the slowdown happens, I see the "Using degraded feature set" message in logs.
Ah, that makes more sense. Thanks for the clarification!
Originally posted by Almindor View Post
Ok that one goes in the book. And unlike the 640k one this one was actaually uttered by someone!
Lol, a resolver can't slow network traffic <wipes tears>. Classic. Dude! Todays programs tend to requery domain names like 500 times a second coz they suck so much. Of course a bad resolver will slow traffic. Not only that, it can literally brick your system for seconds coz most of those crappy programs will block on it too!
Comment
-
-
Originally posted by F.Ultra View PostNo a resolver cannot slow network traffic. It can ofc slow down / halt name resolving for obvious reasons but that is two completely different things. Why play loose with definitions?
Comment
-
-
Originally posted by skeevy420 View Post
The problem with systemd is that it's both an init system and a service manager. An init system doesn't need most of what it offers while a service manager does.
Then your "init system" becames Linux EFI stub with some initrd tools (like dracut) and systemd is service manager.
The only part of systemd that can be called "init system" is systemd-boot and mkosi, which are absolutely optional and actually don't dominate the ecosystem (this is mostly grub2 and dracut domain).
And if you meant /sbin/init - without service managing part it becomes redundant. If I got service manager in place, running, then there's no purpose for any "init", my service manager can reap the orphans itself, so your /sbin/init becomes basically a noop and can be simply removed from the picture.
/sbin/init doesn't go in par with service manager, it's its subset.
You can either have /sbin/init stub with some peculiar tools standing aside, just to make the various services run (like SysV hell), but which cannot manage them fully (supervision, monitoring resources, handling cgroups), or you can have fully-fledged system-and-service manager.
And it just happens that users expect the system manager controlling entire environment, not just some bunch of software randomly running on their systems without any reasonable way to manage them.
Comment
-
-
Originally posted by varikonniemi View PostSO MANY features get rolled into this project. New keywords for service files even when there already existed a whole bagful.
Honestly, almost no-one knows how to correctly write a systemd service file that does exactly what is wanted.
There are 5 methods to do the same thing, but they differ slightly in behavior in some edge case, and it usually takes a discussion thread of like 5 experienced systemd users and several days of brainstorming to achieve a "final" consensus how some non-trivial service file should be written. WTF?
This is called "incompetence" or "ignorance". Instead of "5 systemd users" you simply need "one experienced sysadm".
I managed pretty well to live with cron and shell scripts under sysV. With systemd i can only hope google brings me to the right discussion thread for the type of service i need...
Old-style engines were also easy to fix with a few tools. The always-increasing complexity is being called the "progress".
Comment
-
Comment