Anton Aylward wrote:
I'm confused by the way you've phrased all that. My root is a LVM partition. It been possible to use a LVM partition for some while now. So long as you choose a file system that can be expanded live such as my default choice, reiserFS, then its not a problem.
---- Its the fact that you boot from a ramdisk first, which then boots your hard disk. That's fine if that's your want. But I like the ability to *see* what I am booting... If I change a script in /etc/init.d/XXX.d and reboot, I immediately see the changes. I don't have to regenerate an opaque blob of an initrd. Do you know all the files that go into your initrd? I have a pretty good idea of the files that my system boots from because they are in front of my eyes all the time. But the files in an initrd are not -- they are in an enclosed blob that you need to go out of your way to peer into and become familiar with. I like being familiar with my system's boot procedure -- I tend to read the boot log nearly every time it comes up --- usually because it's a new kernel and I look for changes. If it boots up off an opaque blob, it is human nature not to look to crack open your initrd and read it on a weekly basis. I like to be able to make changes or tweaks in how things come up. If some step takes too long, I fix it. If it was buried in a ram disk, I wouldn't have as easy access.
My opinion is that many people create problems for themselves by the choices they make. If they had made different choices they wouldn't have those problems. I say that about myself too; my problems arise from my choices. The real issue is that most people don't want to admit that, they want to blame other people.
---- Problems don't just come from choices 1 person makes, but in combination with choices others make that intersect their choices. The lake doesn't make a choice to get polluted, but it makes a choice to stay in place since it's only other choice is to evaporate and fall someplace else. But when someone comes along and starts dumping in your basin, sure, you can say it's the lake's fault for the choices it made to stay where it was at, or you can look at the ones who made a choice to dump antithetical-to-lake-being junk in the lake. You can look at it from either side. The indians who didn't want to move and lived with the land, or take the side of looking at them as obstacles to growth and new ways of doing things. Sure, you can blame it on the ones who don't want to be forced into new ways for reasons that are predominantly, not in their best interests (having ones computer locked down so one can't do what one will with it, isn't my idea of fun), but MANY people preferred their walled-gardens, as is well seen with apple's growing influence. The fact that those creating the walled gardens may destroy the rest of the ecosphere for those who don't want to live that way -- sure, you can call it "their choice" and "their fault" for not taking the easy road, but is it really? In the end it won't make much difference as the forces pushing for uniformity and control are much longer lived than any independent forces....and move people will take the easier route and become part of the collective.
But the whole point of systemd was to be able to bring the system up without the need for a shell.
---- Without the need is 1 thing, but since I do development on my system, things sometimes get hosed. If I can't get to a console, restoration is alot more painful.
And your example of backgrounding each script after starting them in sequential order also strikes me as risky.
If I did that for everything, all the time, yes... but for smaller "bites", it's fine.
Some of what sysvinit did was sequential because it needed dependencies. Universal parallelism doesn't achieve that.
----- Systemd *didn't* do the choke points very well. If followed dependencies starting order, but didn't wait for them to finish. This was especially true of legacy scripts and another reason I steered away from systemd. Too many times it tried to mount the lvm volumes BEFORE lvm was finished running. (as one example -- there were others).
Lennart discussed this in some of his early posting on this subject.
If you are going to decry systemd than please do get your facts about it straight and accurate. There's been enough misinformation about systemd and historic UNIX promulgated in these threads already.
--- systemd has no such abilities for low level debugging and fixing.
I must admit I've never needed it. The declarative form of systemd avoid programming mistakes that might appear in shell scripts such as sysvinit uses.
---- That's not where the problems come in -- but when libs don't load due to conflicts and you can't login because pam won't approve you. IT's not bugs in the shell scripts but in how the SW is or is not linked together.
However your assertion is incorrect. It does. Having such must at the very least been a part of the development cycle: how else could the developers have seen what was going on?
But more specifically: http://freedesktop.org/wiki/Software/systemd/Debugging/
----- There are many levels of debugging. But being able to have your debug environment be one that is familiar to you because you already know the utilities and shell they run under is a big bonus. If I had to break out a special purpose debugger like gdb or such to debug, I'd be lost -- because I don't do it that often.
I presume you've read http://en.opensuse.org/SDB:Systemd#Getting_debug_from_systemd and goggled for information on debugging systemd? The latter produced quite a bit of interesting stuff.
---- If my system is down I can't google. That's perhaps another difference. The system that systemd affects is my only route to the internet. If it doesn't boot, there are no 'online resources' or references -- I have to go by memory or what I can pull from the system. That means something familiar and reliable is the best way to go. Not something foreign and complex with all it's documentation in the cloud.
Please stop making assertions about systemd that are incorrect, that could have been cleared up by a simple google or a RTFM.
They are correct for my use case. If you can't access online, then there is no documentation. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org