Please create an account to participate in the Slashdot moderation system


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re: This whole issue needs to be buried (Score 1) 293

And why is it that the woman is the one to take care of children?

I don't know if you have noticed that men and women are different. Women happen to be more suitable for taking care of babies because they can do one thing men can't: breastfeed.

At least, that is one of the reasons why my wife took 6 months maternity leave, and luckily in those 6 months our situation changed so that we could manage without her working. And we have had more children since, so she is still at home.

Of course, we do realise that she will have fewer years of work experience when/if she returns to work, and this also not earn what she would have if she had continued working. However, the investment in our kids/family life is worth it.

Comment: Re: What is systemd exactly? (Score 1) 765

by buchanmilne (#49198525) Attached to: Ubuntu To Officially Switch To systemd Next Monday

systemd can run legacy sysv init scripts just as badly (or better than) as sysv init can. No need for alarm or panic.

But, why do that when a 4-line config file can do most of what you need.

In the case of a more complex service, you can write a pre-exec script, so that may require some conversion.

Comment: Re: What is systemd exactly? (Score 4, Informative) 765

by buchanmilne (#49198433) Attached to: Ubuntu To Officially Switch To systemd Next Monday

Note that sysv init only does anything useful for 3 use cases:
-booting the system
-shutting down the system
-changing run levels (which both of tje above are considered to be)

On most machines these days, no one changes run levels more than once or twice a month.

Note that sysv init does absolutely nothing for stopping/starting or restarting services without changing run levels. All of this is done by scripts (that are compatible with sysv init) which are unique for every family of distros, and mainly source lots of othwr shell scrupt libraries. They also have different locations for the config files these scripts use.

Packages that are made to work on multiple distros need to ship their own tooling (which dulicates this but pften with their own bigs or misfeatures) to do what the 'init system' should provide standard interfaces for.

On a sysv init system, you can't even be sure you are starting a service the same way the previous admin did, because his environment (PATH, LD_LIBRARY_PATH etc.) might have been different. Compare the /proc/$pid/environ of a service started at boot to one that has been restarted since ...

systemd is noy perfect, but it is much better in all of these aspects.

Comment: Re: Goodbye, Ubuntu (Score 1) 765

by buchanmilne (#49197975) Attached to: Ubuntu To Officially Switch To systemd Next Monday

So sysv init (or bsd init) isn't good enough for your desktop, why is it (or in actual fact, upstart in sysv compat mode) good enough for servers (where some of its features are more useful). Or do you want to duplicate configuration or functionality by running an 'init' system which basically has no useful features during the majority of time it is running and a supervising system (which doesn't integrate at all with supplied diatro packages)?

Do you really like the fact that all distros require separate scripts (e.g. some that use /etc/rc.d/functions for RH-derived distros, other scripts that work on Debian-derived distros, others for SUSE, Arch etc., because sysv init basically has no useful features and all distros implemented the missing minimumfunctionality differently?

Comment: Re: Just make it less bloated (Score 1) 300

by buchanmilne (#49197661) Attached to: Mozilla: Following In Sun's Faltering Footsteps?

The machines I regularly use have:

The last two need to run at least 2 and 4 VMs with 3Gb ram each respectively. Running chrome for day-to-day work would make these setups impractical, whereas firefox runs well (firefox needs to be restarted more frequently than the OSs, but not significantly).

Additionally, chrome/chromium have some display issues on one machine (linux, KDE, radeon).

No, I can't (or can't justify just for chrome when firefox is fine) adding more ram, most of the above are work machines, 1 already is fully populated with DDR2, upgrading the ram would be prohibitively expensive

Comment: Re: I'm dying of curiousity (Score 1) 188

by buchanmilne (#49194483) Attached to: Software Freedom Conservancy Funds GPL Suit Against VMWare

Have you tried Red Hat Enterprise Virtualisation ( )? It adds the management features like vCenter Server adds the vSphere to ESXi, and costs less for a suppprted environment than the cheapest VMWare option, and has feature parity and performs better (kvm).

Comment: Citation needed (Score 1) 755

by buchanmilne (#49067571) Attached to: Removing Libsystemd0 From a Live-running Debian System

The introduction of systemd has unilaterally created a polarization of the GNU/Linux community

Citation needed. It seems to me the polarization has been created in the Debian community by the anti-systemd crowd. Instead of fixing the problems that resulted in systemd acquiring more of the Linux user-space functionality, or work actively towards supporting multiple init systems, they continually claim that there are divisions in the community created by the systemd developers.

This doesn't seem to be an issue in other distributions.

Comment: Re:Proof the systemd shills are liars (Score 1) 716

by buchanmilne (#49046927) Attached to: Is Modern Linux Becoming Too Complex?

It shows that the kids running systemd don't get the concepts of stderr or exit statuses.

No, this example shows that in previous 'init systems', the init system was adding no value after the default runlevel was reached. You were basically just running a script, and you had the option to check its return value. It just so happens that the init system would also run this script when changing to the relevant run level (but not in exactly the same way).

In systemd, systemctl tells systemd to start the service. systemctl doesn't exec the script in question itself.

The difference is that, under e.g. sysvinit, while a server remains at a specific runlevel, init scripts are no different than any other scripts. This also means that there are potential problems, where the last person to have started the service may have had different environment variables which made the service work (PATH, LANG, LC_ALL, JAVA_HOME etc. etc.), now when it fails (or the machine is rebooted), you (or init, in the one case it actually does something) try and start it, and it doesn't behave the same way. Go compare the /proc/$pid/environ for a service on a sysvinit box that was started at boot to the environ if you restart it later. In systemd, since systemctl isn't forking the init script (or similar), a clean environment can be gauranteed.

So, since systemctl isn't exec()ing the script, systemctl doesn't have to wait for the execution to finish before it returns.

Setting Type=forking will change the behaviour to what you expect. Why? In the case of a forking daemon, the init system *should* wait for the process to fork before it returns. Maybe there should be another option for Type that doesn't require a PID file but does return the exit status.

However, instead you can always call sytemctl is-active broken_systemd after-the-fact. But, if your 'service' may take some time to get through it's initial checking, maybe you are better off using Type=forking.

Comment: Re:Just one step closer to becoming Windows (Score 1) 716

by buchanmilne (#49046531) Attached to: Is Modern Linux Becoming Too Complex?

systemctl status postfix # will show the last 10 log entries for the service, along with all the other useful information
journalctl -f # tail all logs
journalctl -b /usr/lib64/postfix/pickup # show just the logs for this boot of the postfix pickup binary

These are a few examples from a different distro, so you'll have to use totally different commands and log file names ... oh wait, with systemd you don't need to do that, you can always easily find the logs unlike before where each distro configured it's chosen default logging daemon differently by default.

It looks like you haven't even bothered to read anything about systemd, and it's not like you have an excuse:
$ rpm -qd systemd|grep man|wc -l

A good place to start is probably 'man systemd'

Comment: Re: Yes (Score 1) 716

by buchanmilne (#49040873) Attached to: Is Modern Linux Becoming Too Complex?

I know that I am not the only sysadmin who refuses to install Red Hat Enterprise Linux 7

Did you even try it?

What bugs did you encounter that were specifically due to systemd? Did you file any?

We are preparing to start rolling out RHEL7 (still have some internal packages to rebuild), and systemd didn't really feature as a problem at all.

Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?