you must be the only one, i've not seen anyone else complain about git in that fashion - did you email your bug report to Linus (or did it get put in the spam folder by google)?
Just in case my post you replied to was too long to read.. here is the rest of it
I know i'd rather my admins use journalctl to extract logs for a specific time span using one line rather than spend time writing and debugging scripts to extract logs from all separate files, merge and sort them into order before looking into the problem. journalctl is basically a time saver that has more data than current logging systems and time coded logs that reflect time zones correctly.
It's pointless explaining to posters who are so anti, they're not going to change their mind even if everything turns to gold. He obviously didn't fully understand or read what I wrote. He totally ignored the rest of my post which addressed his comment.
Nothing disingenuous about my comprehension, it's only the few anti that have that problem. I see the reasons for bashing systemd are changing. Once it's shown you can still use scripts you have to find another spurious angle. Why have loads of duplicated code in all those scripts? They all do basically the same thing. So what do you do to monitor those services started by the scripts? Manually watch them or add another binary to watch and restart them? Computing is all about automation, nothing wrong in getting the OS service management More automated.
Saving seconds on boot in commercial context is always beneficial. The more time generating money or increasing customer service the better. Have that argument with your commercial manager.
Why should it be platform independent, how many of these other non-linux platforms have implemented cgroups which is the core for systemd? Even sysvinit is only platform independent to a point because almost every linux distro puts files in a different place so i can't safely copy a redhat startup script to another distro without making some mods to directories etc, systemd cures that problem. Systemd is no more a single point of failure than the kernel or init or disk controller etc. Its just a learning curve for everyone, if people actually researched what systemd did, didn't do and comprises of, most of the negative comments would disappear (apart from a few trolls). It would help if they understood that the systemd project includes the 3 main components of systemd, journald and udev (which are dependent on each other) and is a collection of *optional* executables which can replace the current executables if you want to. They should have called the project something different to stop the confusion.
"Most people will also agree that it accomplishes this at the cost of significant downsides inherent to the design of systemd," - can you back up the "Most people" statement? its just a vocal few (as usual) who know very little or nothing about systemd. i've yet to see breakaway Red Hat, Suse, etc non-systemd systems like Devuan (which no longer seems to make an news).
you can still use your shell scripts within systemd but as most standard init scripts are pretty much identical, they seem an unnecessary duplication of code. Boot time is a side product of systemd not a target but it does benefit those that load and kill VMs a lot, perhaps not an issue for your systems.
Are you going to be able to create a log reading tool like journalctl? Once you've used journalctl a few times, you'll see the binary logging is appropriate. e.g. I know i'd rather my admins use journalctl to extract logs for a specific time span using one line rather than spend time writing and debugging scripts to extract logs from all separate files, merge and sort them into order before looking into the problem. journalctl is basically a time saver that has more data than current logging systems and time coded logs that reflect time zones correctly.
List all the dependencies then, i only see 3. If you can't configure a system with config files, thats not systemd's problem, its a learning curve for you.
"And that is the problem. There is no need for a "suite of basic building blocks for a Linux system."" - why not, elements of the system are improved, developed and replaced all the time e.g. what was around before sysvinit?.
"There are well-working components that have stood the test of time that already offer this functionality." - you can say that for virtually every bit of software on your system, i'm sure the init system before sysvinit also had well working component that stood the test of time.
" there is countless software for Linux that must also run on other UNIX-like systems and the systemd-philosophy seems to be outright hostile to that idea." - thats a choice for the developers of that software if they decide to make use of systemd without offering you a configuration option. There is nothing wrong with Linux looking after its own interests
yet more rubbish trolling by someone who knows very little about systemd and what is and isn't dependent. stop spreading crap - systemd, journald and udev are the only dependents, everything else is optional.
"The people complaining about systemd aren't complaining because it's different." - yes they are.
"They're complaining about it because it's utter shit!" - no its not.
"For crying out loud, systemd's most vocal opponents are career sysadmins with the most experience." - no, its the trolls like you with no knowledge of systemd that are the loudest
the rest of your post is as full of crap as the first bit, go to Devuan if Debian has screwed the config.
as there is already technology helping drivers in bad weather, 4 wheel drive, anti-lock brakes, traction control etc, i would expect an autonomous car to make better use of those than a human. And when there are fully electric autonomous cars with all 4 wheels being driven independently, they'd be able to deal with bad weather much better than a human
Slashdot Mirror
register and log in then maybe you'll be listened to - what are you scared of?
why not read the article and view the video to find out?
yep, they are almost as bad as Microsoft on this score
you must be the only one, i've not seen anyone else complain about git in that fashion - did you email your bug report to Linus (or did it get put in the spam folder by google)?
you really understood the problem..... just as well you posted as an AC
perhaps you only watch women drivers...
Sex.. i'm surprised i'm the first one to put this in the replies... or am i?
Just in case my post you replied to was too long to read.. here is the rest of it
I know i'd rather my admins use journalctl to extract logs for a specific time span using one line rather than spend time writing and debugging scripts to extract logs from all separate files, merge and sort them into order before looking into the problem. journalctl is basically a time saver that has more data than current logging systems and time coded logs that reflect time zones correctly.
It's pointless explaining to posters who are so anti, they're not going to change their mind even if everything turns to gold. He obviously didn't fully understand or read what I wrote. He totally ignored the rest of my post which addressed his comment.
Linux kernel, GUIs - explain the Unix philosophy on those
Nothing disingenuous about my comprehension, it's only the few anti that have that problem. I see the reasons for bashing systemd are changing. Once it's shown you can still use scripts you have to find another spurious angle. Why have loads of duplicated code in all those scripts? They all do basically the same thing. So what do you do to monitor those services started by the scripts? Manually watch them or add another binary to watch and restart them? Computing is all about automation, nothing wrong in getting the OS service management More automated.
Saving seconds on boot in commercial context is always beneficial. The more time generating money or increasing customer service the better. Have that argument with your commercial manager.
Why should it be platform independent, how many of these other non-linux platforms have implemented cgroups which is the core for systemd? Even sysvinit is only platform independent to a point because almost every linux distro puts files in a different place so i can't safely copy a redhat startup script to another distro without making some mods to directories etc, systemd cures that problem. Systemd is no more a single point of failure than the kernel or init or disk controller etc. Its just a learning curve for everyone, if people actually researched what systemd did, didn't do and comprises of, most of the negative comments would disappear (apart from a few trolls).
It would help if they understood that the systemd project includes the 3 main components of systemd, journald and udev (which are dependent on each other) and is a collection of *optional* executables which can replace the current executables if you want to. They should have called the project something different to stop the confusion.
Could it be a direct clone? Has Haiku implemented Linux cgroups or a compatible cgroups?
"Most people will also agree that it accomplishes this at the cost of significant downsides inherent to the design of systemd," - can you back up the "Most people" statement? its just a vocal few (as usual) who know very little or nothing about systemd. i've yet to see breakaway Red Hat, Suse, etc non-systemd systems like Devuan (which no longer seems to make an news).
you can still use your shell scripts within systemd but as most standard init scripts are pretty much identical, they seem an unnecessary duplication of code. Boot time is a side product of systemd not a target but it does benefit those that load and kill VMs a lot, perhaps not an issue for your systems.
" systemd does not have any reasonable level of stability for a productive release." - now you are just making things up.
Are you going to be able to create a log reading tool like journalctl? Once you've used journalctl a few times, you'll see the binary logging is appropriate. e.g. I know i'd rather my admins use journalctl to extract logs for a specific time span using one line rather than spend time writing and debugging scripts to extract logs from all separate files, merge and sort them into order before looking into the problem. journalctl is basically a time saver that has more data than current logging systems and time coded logs that reflect time zones correctly.
List all the dependencies then, i only see 3. If you can't configure a system with config files, thats not systemd's problem, its a learning curve for you.
"And that is the problem. There is no need for a "suite of basic building blocks for a Linux system."" - why not, elements of the system are improved, developed and replaced all the time e.g. what was around before sysvinit?.
"There are well-working components that have stood the test of time that already offer this functionality." - you can say that for virtually every bit of software on your system, i'm sure the init system before sysvinit also had well working component that stood the test of time.
" there is countless software for Linux that must also run on other UNIX-like systems and the systemd-philosophy seems to be outright hostile to that idea." - thats a choice for the developers of that software if they decide to make use of systemd without offering you a configuration option. There is nothing wrong with Linux looking after its own interests
yet more rubbish trolling by someone who knows very little about systemd and what is and isn't dependent. stop spreading crap - systemd, journald and udev are the only dependents, everything else is optional.
"The people complaining about systemd aren't complaining because it's different." - yes they are.
"They're complaining about it because it's utter shit!" - no its not.
"For crying out loud, systemd's most vocal opponents are career sysadmins with the most experience." - no, its the trolls like you with no knowledge of systemd that are the loudest
the rest of your post is as full of crap as the first bit, go to Devuan if Debian has screwed the config.
yes, but the Stones still do celeb stuff so they'll get noticed. I don't see Pink Floyd doing celeb stuff
i presume you took into account the subsidies/tax breaks/"politicians in pockets" paid to fossil fuel companies before you did your "comparison"
"Typically both cars need to screw up (at least a little) for an accident to happen. " - thats complete bollox, that will be a rare situation
as there is already technology helping drivers in bad weather, 4 wheel drive, anti-lock brakes, traction control etc, i would expect an autonomous car to make better use of those than a human. And when there are fully electric autonomous cars with all 4 wheels being driven independently, they'd be able to deal with bad weather much better than a human