Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

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: Citation needed (Score 1) 754

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
291

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.

Comment: Re:Yes (Score 1) 716

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

Example, libvirt doesn't use /etc/network/interfaces, this is stupid and complicates firewalling scripts and so on.

/etc/network/interfaces is Debian-specific. Libvirt (optionally) supports the netcf library, which is a cross-platform network configuration library that claims to support Debian. Is libvirt in Debian compiled against netcf?

And it insists on running its own copies of dnsmasq, rather than just dropping some files in /etc/dnsmasq.d. What a PITA. Use the goddamned operating system, that's what it's there for.

Have you filed a bug?

Comment: Re: My FreeBSD Report: Four Months In (Score 1) 471

by buchanmilne (#48970495) Attached to: Systemd Getting UEFI Boot Loader

So because Debian has bugs in their 'upgrade-to-syatemd' process in their in-development release, which numerous other Linux distros (Red Hat/Fedora, SUSE, Arch, Mageia) *don't* have in their released versions, your reaction is to ditch your distro?

Wow.

Maybe you shouldn't have been running testing ...

Comment: Re:pfsense (Score 1) 403

by buchanmilne (#48826993) Attached to: Ask Slashdot: Migrating a Router From Linux To *BSD?

Have you actually looked at any of these shell scripts? The largest one in F14 is less that 400 lines and they are all straight forward to read. Where is the tangled mess and when have they ever not worked for you?

RHEL6:
$ wc -l /etc/rc.sysinit
662 /etc/rc.sysinit

RHEL5:
$ wc -l /etc/rc.sysinit
980 /etc/rc.sysinit

This is what systemd actually *replaces*.

Comment: Re:systemd hatred (Score 1) 403

by buchanmilne (#48826939) Attached to: Ask Slashdot: Migrating a Router From Linux To *BSD?

its adoption will force a *lot* of people who don't want it to either suffer through it or suffer through migration to another OS. That is reason enough not to adopt it.

How is it something to 'suffer through'. Read a man page or two, and you should be able to admin it and gain the benefits it provides (eg. cgroups configured by default).

Running systemd on all my personal machines and my workstation at the office, I haven't experiened any problems. We'll be upgrading systems in the coming months, and I see no reason to avoid systemd.

Comment: Re:pfsense (Score 1) 403

by buchanmilne (#48826923) Attached to: Ask Slashdot: Migrating a Router From Linux To *BSD?

it's the dependencies thats a real problem.

Which dependencies exactly? About the only new dependency vs. the previous init system on this distro is: dbus

There are separate projects out there that literally do every single thing systemd does without making it un modular and non posix compliant and have code that is readable.

Please provide a link or a name for one project that has at least all of the useful functionality that systemd has.

Then you have some major projects like gnome where are going to require systemd. Its not a big deal for BSD though. some developers are almost done with systembsd which emulates systemd without actually installing it allowing the depend software to be used without inheriting things like PAM for authentication and other things that are not liked and not actually giving control of the system over to it.

And GNOME developers will just ignore any bugs related to functionality not available on BSD and just stubbed in systembsd ...

I have systemd on all of my personal linux boxes (my laptop, wife's laptop, media player, NAS), and it hasn't introduced any issues while resulting in all machines booting faster and provided many more features.

Comment: Re:If that's what you are selling - yes (Score 1) 163

No consumer broadband ISP promises raw bandwidth without prioritisation on their cheapest ($/GB, $/Mbps) prices.

Why? Because it's impossible to ensure everyone can get DNS responses while 20% of the users are flooding the network with as many P2P packets as they can.

It is not best to swap horses while crossing the river. -- Abraham Lincoln

Working...