Rob OpenSuSE wrote:
On 4 July 2011 08:10, Linda Walsh <suse@tlinx.org> wrote:
Per Jessen wrote:
Rob OpenSuSE wrote:
In old days, it would take ages for an array of disks to spin up, Staggered spin-up is still the norm.
I have 24 external and 8 internal RAID disks (3 are 15K SAS, the rest are 2TB SATA), ...
My init-d start takes all of 20 seconds -- that's with all disks mounted and my disks are set for auto-spinup -- but that happens during BIOS initialization and adds no noticeable time over an empty controller.... So...it is only a 2.6MHz CPU (2x4core), so it's NOT because it's a fast CPU...
What benefit is systemd going to give me that will be worth _any_ hassles.
As https://features.opensuse.org/310327 says, "systemd provides aggressive parallelization capabilities,
Which, AFAICT (can tel) buy me nothing.
uses socket and D-Bus activation for starting services,
Which ... same as above...
offers on-demand starting of daemons,
Possibly interesting.
keeps track of processes using Linux cgroups,
Current kernel auto-cgrouping implemented in 2.6.38 works great! Used to be if I ran a kernel build with "make -j", it would cause my server to get a bit sluggish, so I'd have to limit it if I didn't want other things (like editing via 'X', file-serving and http-access via squid) to be affected. Now, with the auto-cgrouping, even with a load over 800 during the 112s build (cold cache, cleaned source dir), Nothing else is bothered. So...why do I want something to mess with this?
snapshotting and restoring of the system state,
Using any file system? Or would I have to change that too?
maintains mount and automount points
Linux and automount already do that.
and implements an elaborate transactional dependency-based service control logic."
Complexity = bugs and problems. i.e. sounds bad. with no benefit.
Apart from that, it means openSUSE project share code with other distro's rather than maintaining own parrelised Sys V Init.
---- Oh. Well, that's always a good reason -- if they all switch to a BSD kernel will we as well?
Upgrading a distro release, will always bring "hassles", it's a trade off on the benefits. Big Iron deployments do not have a hope in hell, of holding back a community distro, the on-demand demon starting helps many by saving memory on startup & avoiding need to disable unused daemons, lowering maintenance & support issues.
---- Big iron? *cough*.... The base server was <2K (it's gotten additions since I bought it). It's a home server that replaced my 10-y/o dual P-III (1GHz!) workstation that was my previous server. (most expensive part is buying the disks)....
FWIW Sys V init was new at one time, and WE hated it, as it was slow & over engineered, I remember it taking minutes to change run levels, when "simply using rc.local" was so much simpler & faster and what did we need all that start/stop crapola when we could just SIGHUP the daemon or kill it ourselves.
While now it takes seconds.
Things change..
Yup... The only reason that I would find useful is the source-sharing and being more like other distro's (yeah, while I nay-say the sheep aspect, that doesn't mean it wouldn't have benefits)... Don't get me wrong -- I'm NOT saying -- ultimately, that we shouldn't go with systemd, it sounds like 'next gen' (like ng-syslog did before we abandoned it... hmmmm....wonder if there is a lesson in there)... But I don't think there needs to be a such a rush to adopt systemd, that little details, like making sure local file systems are mounted and running before 'consumer device networks' (that would likely want to access those local file systems - or are you suggesting that people's home directories ALSO be on the root partition?). I love 'change' -- but not breakneck speed where I risk my neck and ability to use my system. When I upgrade my server -- I'm 'offline' for as long as it takes to get that server backup -- it's my sole means of internet access. So having problems that require disk reformatting and repartitioning just to upgrade are not my ideal scenario... -l -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org