I GIve Up On Systemd

After many hours of reading/fiddling/reconfiguring I’ve given up on Systemd. It doesn’t work for me, preventing me from logging in until absolutely every service is running on my desktop system. Before, with systemd in charge, it was 83s to get a login screen. That was unacceptable. Today, after apt-get install sysvinit-core and a reboot, I fired up Beast at 7:40:10 and by 7:40:53, I had a login screen even with mysql and postgresql starting. With all the servers and databases held back, from the starting of Linux until my browser ran was 28s. I’m now back in Runlevel 2 so I had to tweak the scripts but Debian’s /etc/rc2.d/README was explicit and helpful and concise, so everything worked right away. I then removed systemd almost entirely. Now virt-manager won’t run (“Unable to connect to libvirt…libvirtError: error from service: CheckAuthorization: The name org.freedesktop.PolicyKit1 was not provided by any .service files”)… sigh. Hello, VirtualBricks:
I’ll be installing Wheezy in my virtual machines for now.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology. Bookmark the permalink.

39 Responses to I GIve Up On Systemd

  1. oiaohm says:

    DrLoser squid cache can be a lot more cacheable than you think.

    http://wiki.squid-cache.org/Features/SslBump
    (and ignoring the fact that URLs these days are not as cacheable as they were)
    Sorry they are just as cache-able as they always have been. Just now its a Man in the middle proxy required. Turns out for many networks the advantage of inform staff section of network has no privacy for the gained speed and traffic reduction.

    School systems sometimes use squid man in the middle for site and content filtering.

    5) Perhaps squid fires up, starts its housekeeping, and reports back that it’s “up and ready.” Doesn’t matter whether it’s sysvinit or systemd
    Kind the case. Housekeeping is required. Deleting everything out the cache that is expired improves the performance of the cache. Sometimes squid can disappear for 20+ mins on startup. This is normally because it has not shutdown clean.

    Just starting squid with a LSB sysv init script wrapped into a systemd unit instead of a systemd unit results in systemd waiting until squid says I am 100 percent up. The annoying part about squid is it might take 20 mins to do the Housekeeping but its able to process traffic from about 30 seconds after start up. Systemd LSB sysvinit conversion generator suxs with particular things.

    On a home system with about three to five users, all of whom are likely accessing completely different parts of the Web … no, an HTTP cache is going to offer you no performance benefit whatsoever.
    Not that simple.
    http://sichent.wordpress.com/2014/02/22/filtering-https-traffic-with-squid-on-pfsense-2-1/
    You have children and you want to site filter. Not everything is about performance benefits. There are other filtering tricks like disappearing advertisements.

  2. DrLoser says:

    To forestall the inevitable meanderings off into the middle of nothing particularly relevant, oiaohm, one question for you:

    Which organisations do you think are the primary users of squid?

    Clue: not individuals. Not even school systems and the like.

    There are two obvious use cases, and neither one fits the current discussion.

  3. DrLoser says:

    That’s a silly and rude comment. A web-cache can serve a bunch of functions but in that case it could well speed up access to a local web-application.

    On a central server with several dozen or more users, all of whom are hitting the same set of URLs (and ignoring the fact that URLs these days are not as cacheable as they were), you are correct, Robert. This use case almost certainly matches your experience in a school environment.

    On a home system with about three to five users, all of whom are likely accessing completely different parts of the Web … no, an HTTP cache is going to offer you no performance benefit whatsoever. All it’s going to do is to waste RAM and swap space.

    You may remember that oiaohm was mumbling something about squid (“[it] can disappear for up to 20 mins cleaning up the squid cache”). We can draw several tentative conclusions from this:

    1) oiaohm is wildly flailing around and coming up with the first googled thing he can think of. This is quite plausible.
    2) Perhaps squid is atrociously badly designed. F’rinstance, when would you need to “clean up” a squid cache? That’s not even how a cache, properly so called, works.
    3) Perhaps squid is the worst-designed daemon ever written? Look, the damn thing has, as its primary justification, what you, Robert, have claimed is “the speed-up of serving Web pages” (not an exact quote, but near enough, I believe). I don’t think that spending twenty minutes clearing its cache advances this justification much.
    4) Perhaps squid doesn’t behave as oiaohm claims. Why, it might even be sensible. It might back off the original cache for housekeeping and start a new one.
    5) Perhaps squid fires up, starts its housekeeping, and reports back that it’s “up and ready.” Doesn’t matter whether it’s sysvinit or systemd/b>.

    Personally I regard a combination of 1, 4 and 5 as very likely. But I’m not going to test them. And why not, you may ask?

    Because, given an average page size of 100KB, the purported cleaning time of 1200 seconds, and an estimate of ~100 pages “cleaned” per second … the first and third sound like reasonable estimates to be getting on with … we’re looking at a cache of 12GB here. And no, none of that is going to be on disk — rational servers don’t work that way.

    I am not about to go out and buy 12GB of RAM to test out oioahm’s ill-founded theories, Robert.

    I am not, therefore, being “silly and rude.” I am simply being rational.

  4. DrLoser says:

    Yet you still run the test wrong. If this difference was front and center in your mind you would not have screwed the test up in the first place.

    No, I haven’t “run the tests” at all. What “tests”? These “tests” are a figment of your imagination, oiaohm.

    All I’ve got is a baseline — you’re an expert on performance testing, as with everything else; you should be aware of what a baseline is. Assuming that I run the Wikipedia data test you propose (I have a SQL dump of 3.5 GB, which should be sufficient), then I can extrapolate from the baseline.

    What’s your testing methodology, oiaohm? Spitting into the wind, and hoping that the direction doesn’t change and you don’t splatter yourself in the face?

  5. DrLoser wrote, ” Anybody expecting to use an HTTP cache server on something that is expected to be an interactive machine at the same time is, frankly, nuts.”

    That’s a silly and rude comment. A web-cache can serve a bunch of functions but in that case it could well speed up access to a local web-application. There are other layers that could help as well, the browser’s cache, the web-application’s cache are two. It’s nuts to have the awesome power of a computer idle while some disk drive seeks all over creation to construct a page when a cache knows right where the data is. If the cache is faster than the web-application on its own, it’s the right way to do it. In the North, I usually had a web-cache to buffer our rather limited connections but I also put it to filtering our local servers for all kinds of purposes, speed being just one. That’s not silly if it works. These days a cache could be in RAM or SSD as well as disc-storage so there’s the possibility of getting an even better result by caching caches… That could be silly but CPUs do it all the time. Typically they have two or three caches in layers. There’s no reason a single PC with a bunch of processes could not do the same beneficially if there’s a wide range of speeds/capabilities involved. A cache is a great means of giving a user what he wants when he wants it. I’ve had X window systems that actually cached data so that less had to be redrawn on the screen and that’s the last layer of the interface to the user.

  6. oiaohm says:

    DrLoser
    I think you can assume that I am aware of the difference in performance between an empty database and a full one.
    Yet you still run the test wrong. If this difference was front and center in your mind you would not have screwed the test up in the first place.

  7. DrLoser says:

    DrLoser did you put any data into Postgresql I know you did not because it only added 2 seconds to the boot.

    … and so on and so on and so on. Good grief, oiaohm, I credit even you with a little native intelligence every now and again. I think you can assume that I am aware of the difference in performance between an empty database and a full one.

    Your suggestion of importing Wikipedia is, however, a very good one. I’ll give it a try. Absent any knowledge of Robert’s real-world usage, this seems a perfectly good test.

    And no, I am not going to sully even a virtual machine with squid. Anybody expecting to use an HTTP cache server on something that is expected to be an interactive machine at the same time is, frankly, nuts.

    And once again, if you don’t constantly reboot (by constantly, I mean more than once a week … which should cycle new kernel builds nicely enough), then I completely fail to see the problem in the first place.

  8. oiaohm says:

    DrLoser did you put any data into Postgresql I know you did not because it only added 2 seconds to the boot. Exactly why would you be running a database with no data unless you have made a error having it running anyhow. This is a failure to understand how to do real world testing.

    I did say the postgresql problem was file auditing DrLoser. To have postgresql file auditing happen require to you to have filled postgresql with some databases.

    If you install squid you have to fill the cache before it starts showing its evil as well.

    DrLoser how can you claim to audit anything when you cannot understand something so simple and proceeded to test postgresql without filling it.

    Yes the default data of postgresql that is under 10 megs adds over 2 seconds to the boot. A few large databases and postgresql takes a while.

    Good test database is the wikipedia. Basically take your 14 seconds starting virtual machine added the wikipedia data to postgresql reboot and enjoy the lag.

  9. DrLoser wrote, “You can’t even be bothered to put the effort in to fire the thing up in a virtual machine, can you?”

    I have systemd working on another system and it’s fine there. It’s the particular mix of services that drive me nuts on Beast: two databases, and a web-server were starting before I was allowed to log in. That’s not how I want Beast to operate and there was no simple way to override systemd configured in Debian. It was either a single-user setup with no services running or a multi-user setup with every service having higher priority than me. I may still fiddle with it but I have better things to do. My new tractor is on the way and I have to arrange shipping and make room for it. I might also build a trailer to haul it around. I’m also moving the little woman and her data onto Beast. That’s taking longer than expected because of Beast’s firewall which has grown thicker over the years. Then there was the meltdown of the server…

  10. DrLoser says:

    And back to the subject of this post, which as y’all will remember is systemd on Debian Jessie

    Now, I don’t want anybody to think that I don’t listen tooiaohm’s pointless and generally uninformed and totally inaccurate bleating. On the contrary. I revel in the stuff.

    But you can’t really revel unless you put the hard yakka in to disprove his unfounded drivel, can you?

    So, once again. In a VirtualBox. On a seriously crappy AMD machine. Debian Jesse plus postgresql.

    Five seconds kernel, fourteen seconds user-space.

    Do you want me to test out squid now, oiaohm?

    Or are you going to admit that your claims are pathetic and idiotic?

  11. DrLoser says:

    You know, Robert, in five years of your insistence that Gnu/Debian is the way to go …

    … This is actually the first time that I’ve been convinced that it’s at least barely adequate. And, naturally, you have chosen this point in time to diss your own Distro.

    Some sort of “closing all the Windows” evangelist you are. You can’t even be bothered to put the effort in to fire the thing up in a virtual machine, can you?

    Well, thank God for (professionally trained) trolls like me!

  12. DrLoser says:

    Hi, Community!

    Time for me to give back!

    I finally fought Jesse through VirtualBox (it’s not trivial, I’ll tell you), and I now have a full, 3-DVD set of Debian Jessie to play with. And what do we do first, kiddies?

    Why, we boot it up.

    Once again, courtesy of system-analyse, we can harvest the relevant statistics. And it turns out that Jessie, featuring native systemd, is a vast improvement on Debian Wheezy!

    Kernel down from 7 seconds to 5 seconds. User space down from whatever it was to 12 seconds.

    And, yes, ps -ef|grep apache reveals that I have a web-server up and active.

    Frankly, I find this quite impressive. Apparently Debian have actually put in the necessary effort and made systemd work like a dream.

    Over to you, Robert.

  13. DrLoser says:

    What issue Robert Pogson run into is how systemd emulates sysv.

    That’s not the issue I’m hearing from Robert, oiaohm. The issue I’m hearing is “time to interactive terminal.”

    You may not have noticed this (how could you? You’re clueless as always), but systemd doesn’t “emulate” sysvinit. It replaces it. An “emulation” would be completely pointless.

    DrLoser the two worst for slowing the boot down is postgresql and squid.

    So what?

    Oh, and if you keep your Linux server running for the traditional 180+ days, there is simply no reason to care.

    I mean, it seems to take at least twelve hours to recover from a misconfigured nginx server that persists an “Error 502” page. In comparison, even squid at its worst is chicken-feed.

  14. oiaohm says:

    DrLoser as per normal you gloss over it. What issue Robert Pogson run into is how systemd emulates sysv. I had shredded away most of that. DrLoser you have TM over the very thing you just did.

    Problem is I have a very long memory I remember when sysv init on debian was single threaded. 5 min startups was not that bad back then.

    Or am I to understand that this “You can boot a Linux server up and forget about it for the next 180 days” stuff is just a myth?
    Its not a myth but it takes effort setup and some cases paying money.

    Enabled required updating.
    Setup is cron/timer jobs to detect when services have been updated and have not been restarted. This is made simpler with systemd or openrc cgroups. Look up cgroup on process with open file that is deleted in /usr /bin /lib and restart it.
    ksplice, kgraph or kpatch for kernel updates. Please note the last 2 are working on being mainline Linux kernel.

    What is annoying is this stuff at this stage does not come configured out box with most Linux Distributions.

    DrLoser the two worst for slowing the boot down is postgresql and squid. squid can disappear for up to 20 mins cleaning up the squid cache. postgresql is file auditing. systemd sysv emulation needs a few options to allow services to be tagged to start late simpler. Its also partly how LSB sysv scripts are designed as well. LSB sysv init scripts were not design with any idea of start on demard.

  15. DrLoser says:

    Or am I to understand that this “You can boot a Linux server up and forget about it for the next 180 days” stuff is just a myth?

    Because, evidently, Robert, that is not how you operate The Beast.

  16. DrLoser says:

    Having installed Debian Wheezy on a VirtualBox on my very weedy two-core i5 $400 desktop, Robert, I can report the following preliminary figures:

    ~7 seconds kernel; ~42 seconds user-space.

    Courtesy of systemd-analyze.

    Now, this doesn’t strike me as the moment the Rapture descends from the heavens. I mean, it’s in a virtual machine on a rubbish bit of ancient hardware. (For reference, I installed absolutely everything I could think of — all three DVDs — with the sole exception of the laptop stuff. And yes, it does include Apache 2.2.)

    I fail to see what you are whining about.

    And if you think that 49 seconds is some sort of hardship … why, I can install Debian Wheezy on a VirtualBox without system … shouldn’t be too hard, you actually have to apt-get two packages, although you didn’t mention this …

    And it will probably still take ~7 seconds of kernel time. And, who knows, but quite possibly 42 seconds of user-space time.

    Don’t you have anything else to worry about, Robert?

    Like, say, real life?

  17. oiaohm says:

    Robert Pogson I forgot that a major power fluctuation from the PSU could cause the RTC start running either major-ally slow or major-ally fast. But normally the on motherboard clock battery clock prevents this. Question does the motherboard have a clock battery and the battery is not flat? If missing or flat you can suspect PSU as only problem but if it has one the RTC should have been functioning correctly no matter what. Yes the one part standard PC that has a built-in UPS is the RTC on the Motherboard. That should kinda tell you how important the RTC is.

    Basically see clock issues its big problems. RTC faults being reported by ntp is basically early warning to pending disaster.

    Robert Pogson you are not alone on blaming systemd or Linux kernel for hardware faults.

  18. oiaohm wrote, “a major hardware problem.”

    Looks like it. That system crashed again with nothing in the logs and shortly lost connection to the brand-new USB-keyboard/mouse. It could be the PSU is off spec. I may move her hard drive to Beast and give her a thin client. That would automatically give her a 64-bit software system and free up a lot of space around her desk. She was running on 32-bit.

  19. oiaohm says:

    Robert Pogson wonky clock is a very big issue. This can also be a sign that random generation on the hardware is off sometimes really badly to the point of being frozen. The clock is used to take samples for the random number generator and it if short there may not be enough time to generate random values.

    Upower complaining is also to be expected if clock is not working correctly. Hardware power management in fact does depending on the rtc clock. Upower is not part of systemd and is technically not a friend of systemd.

    http://upower.freedesktop.org/ Upower is a independent project under independent management to systemd. Richard Hughes would be very annoyed by your linking him to Systemd.

    Robert Pogson first question what clock is wonky. You have two at a min in a PC software or RTC. RTC or software running fast causing time to have to be moved backwards all the time equals major integrity problems to databases and office suites. If it a case of running slow there is not as much of integrity problems. All logging software should complain if it on a system where the clock is being moved backwards all the time.

    rsyslog in a old sysvinit system will also complain if the clock is too wonky.

    Yes Robert Pogson does have some issues but the problem I have is systemd is becoming scape goat for real issues that should be fixed. Sysvinit and Systemd systems both should complain about a wonky clock.

    http://ahsoftware.de/usb-rtc/ replacements to a wonky RTC are possible but a lot of cases it cheaper and better long term to junk the complete motherboard.

    Why junk the motherboard the power management of the motherboard depends on the motherboards RTC clock chip working correctly. Its the RTC clock chip that wakes the computer up from short suspends.

    Basically wonky clock is a major hardware problem.

  20. Meanwhile, the little woman’s PC, still running systemd crashed on its own last night. The log was full of messages from upower, a friend of systemd. Upower was complaining every time ntpdate corrected the system time and the complaints kept getting longer until the system crashed. Her machine has a wonky clock which drifts too much. I removed upower but there are still two copies of systemd running and they both complain when the time changes.

  21. DrLoser wrote, ” all it takes is for you to track down (in no particular order) xdm, apached, postgresd and mysqld and adjust the Requires, Befores, and Afters accordingly?”

    Yep, I did all that and still Apache wanted to finish loading before xdm. You see, there is no config file for Apache. It’s dynamically configured by systemd. I would have had to replace all the targets with my own version to get it to work and then I would have to keep that updated should systemd ever change. I don’t want to be an expert with systemd. I just wanted my box to work “out of the box” as it used to do. Introducing systemd changed my booting procedure. There was an obvious bias to treat Apache as some service supporting the desktop rather than a desktop application which I a user could use or not. I wanted to use Apache the same way I use any other server out on the web. There was no simple means to make that change except to put Apache in another machine. I could not even put Apache in a virtual machine because systemd wanted to start those first as well. Systemd doesn’t work for me. Systemd was deliberately ignoring my “Afters”, finding loops in its reality. Anyway, it’s done. I won’t do any more experiments with systemd until it matures, say, in a couple of years. Debian and others are still figuring out how to use it. This is just one problem out of hundreds that using systemd as a default cause. I will use Wheezy for installations for the next while.

  22. DrLoser says:

    I hate to pre-empt Adam Williamson on this, because the man seems to be of Good Counsel, but have you tried actually putting some thought into this, Robert?

    You’ve got a Directed Acyclic Graph, courtesy of Adam’s suggestion.

    You’ve got clear evidence off that graph that xdm is for some reason a pre-requisite for your db servers, when obviously it should not be. (There may be an intermediate dependency, but even I do not believe that Debian Jesse is that borked.)

    Surely, all it takes is for you to track down (in no particular order) xdm, apached, postgresd and mysqld and adjust the Requires, Befores, and Afters accordingly?

    I’m assuming you didn’t take my advice and try a clean install in a VM, which would probably make things clearer.

    One more suggestion: as Adam says, you have an outlying set of requirements. I would again try the following in a VM, but why not just forget for an instant that you need any two of apached, mysqld and postgresd?

    Get one of those three working in systemd and proceed from there.

    Honestly. No sarcasm.

  23. ram says:

    You guys complain about boot-ups in the the tens of seconds range? I have a Linux cluster with around 2000 cores and to get it booted takes several minutes, sometimes several tens of minutes. However, after booting, it is really really fast 😉

  24. Adam Williamson wrote, “generate a graphical visualization of the whole dependency tree for boot on your system.”

    I did that. xdm required apache2, mysql and postgresql to finish loading before starting. I fiddled with everything that made sense and it was like pushing water uphill. I think it would have worked defining a completely new set of targets but I don’t want to maintain a systemd package. I want to use my system. It now is back to working nearly as before but there’s still some cruft with systemd stuff involved like not being able to use virt-manager. This is supposed to work out of the box and it’s supposed to parallelize stuff. It was serializing stuff. I realize it’s the particular setup on Debian but it’s what I had to deal with. Something that basic to the init-system should not be so intrusive. Let it start processes, but at least let me start the processes I want when I want.

  25. dougman says:

    People should give up on M$…..seriously.

    Problem: Windows 8 is stuck in an automatic repair loop
    Solution: Backup and Reformat

    Lay-mans terms: Our OS sucks, you need to erase and start over again

  26. dougman says:

    64GB? Eh??…I prefer the 10K Velociraptors over SSD’s, 300 GB VelociRaptor runs $54.00 ea. on Amazon.

    On the question of “How often do you reckon that the average user of Windows XP has to reboot every day?” I say ask the people that suffer under the infinite boot loop malware, I bet the count is in the order hundreds of times per day!

    http://youtu.be/awDLnys7zpo

    By reading through some of the comments it seems the infinite boot loop malware even affects Win-Dohs 8…

    Eh.

  27. Er…why do you have two database servers and a graphical desktop all running on the same system in the first place? I’m not sure why I’d ever want to set one up like that.

    Anyway, systemd is a framework for service startup. Actually defining the services is up to upstreams and/or distributions. It seems unlikely Debian would configure things such that interactive login blocked on database server init, but it’s hard to say for sure, and you certainly don’t provide enough details for anyone to tell. There are tools systemd provides for visualizing inter-service dependencies, which might be useful in your case – try ‘systemd-analyze dot | dot -Tsvg > systemd.svg’ , as mentioned in ‘man systemd-analyze’, to generate a graphical visualization of the whole dependency tree for boot on your system.

  28. DrLoser says:

    The visitors here are becoming more rude every day. I want to tweak my system just a tiny bit and I should go out and buy a bunch of new hardware?

    Well, considering that you could buy a 64GB SSD from Amazon for $50 including a three year guarantee, Robert, then yes. It’s a Kingston. It’s not some rubbishy thing you’d have to use your welding skills on. It would work very nicely.

    I don’t know about “a bunch,” but I think this small outlay would delight you for years to come.

  29. DrLoser says:

    So now you have a borked and, with sys5init ultimately going the way of the dinosaur, ultimately unmaintainable system system that does things your way, all to save 40 sec on bootup.

    Once again, olderman, you are being tedious and presumptuous.

    Robert, thanks to the Four Freedoms, has perfect access to the source code of Debian Wheezy. (And what an appropriate name that has turned out to be.)

    Robert, on his own, or possibly with a small coterie of like-minded fustians, can keep Debian Wheezy and sysvinit viable for … why, practically forever!

    There’s absolutely no reason for Robert to put in a bit of extra effort and understand how a fully-declarative boot-up process works, is there?

    Shame on you, olderman. Shame!

    You underestimate the ability of an educator with fifteen years of real-life experience in Linux system administration.

    Go hide in a corner, you ancient reprobate!

  30. DrLoser says:

    14:41:48 up 183 days, 15:08, 1 user, load average: 2.37, 2.36, 2.41

    Isn’t a load average of ~2.4 a trifle high over a 24 hour period, Dougie? What on earth are you doing to the poor thing for half a year?

    Mining bit-coins?

  31. DrLoser says:

    Anyway, back to the 83 second boot-up. No need to feel that your Linux server is humiliating you, Robert: just ask oiaohm!

    Here we have a fine, upstanding member of the Community who is only too ready and willing to sort out those gritty little problems!

  32. DrLoser says:

    What OLDman does not say, is that he boots routinely throughout the day multiple times.

    Oh, how amusing that “OLD” bit was, Dougie.

    Now, purveyor of snake-oil to the defenceless masses (well, dozens, anyhow), answer me this:

    How often do you reckon that the average user of Windows XP (I am using a M$ OS that is EOL deliberately here) has to reboot every day?

    Place bet NOW!

    Y’know, Dougie, I can seriously see you as the “Cheeky Chappie” who dreams of creating the Naked Lady Gamble.

    As far as even vague IT comprehension goes, though …

    Place Bet Now!

  33. DrLoser says:

    Actually, one more (helpful?) thought.

    Have you tried running a fresh install of Debian Jessie inside a VM? Do you still see an 83 second gap to login?

  34. DrLoser says:

    I’m no expert in this, Robert, but have you considered editing the systemd unit files?

    Since they are declarative in nature (and therefore enforce a set of requirements), I would have thought that you should be able to fire up the daemons for a simple login at your convenience.

    Say, X and maybe a few tiny dependencies that XFCE has? Basically, a rc1.d script with a couple of frills.

  35. dougman says:

    What OLDman does not say, is that he boots routinely throughout the day multiple times. So what if Linux systems takes 40-seconds, you are only doing it a few times a year anyways.

    $ uptime
    14:41:48 up 183 days, 15:08, 1 user, load average: 2.37, 2.36, 2.41

  36. olderman wrote, “thanks to a solid state boot disk. A much more sane and supportable solution IMHO.”

    The visitors here are becoming more rude every day. I want to tweak my system just a tiny bit and I should go out and buy a bunch of new hardware? Silly. I just want control of the boot-process. Is that too much to ask? If they ever get systemd into a mature state, I will be ready to use it. At the moment, it’s too inflexible. Why should the desktop be the lowest priority of my system? That’s silly with me sitting at a keyboard ready, willing and able to do stuff.

  37. olderman says:

    My windows 7 system with its RHEL 7 VM boots in 12sec BTW thanks to a solid state boot disk. A much more sane and supportable solution IMHO.

  38. olderman says:

    “Before, with systemd in charge, it was 83s to get a login screen. That was unacceptable. ”
    So now you have a borked and, with sys5init ultimately going the way of the dinosaur, ultimately unmaintainable system system that does things your way, all to save 40 sec on bootup.

    Stupidity.

  39. wolfgang says:

    With so much to do and with such valuable time, saving 40 seconds is incredible. But why do you need to re-log in so often. Haven’t you heard of hibernate mode or sleep mode? If you had a newer machine you wouldn’t have to fuss so much.

Leave a Reply