Raspbian and systemd

There is already a port of Raspbian/Jessie avalable - it's more or less tracking Debian/Jessie as I understand it...

Personally, since Wheezy ought to have long term support until c2017 which is when a new Pi might be made with a new architecture then I think sticking to Wheezy is a sensible thing to do.

That's my plans, anyway.

Gordon

Dzieki, notbob, za post o tresci:

Hopefully not long.

Except that Wheezy is lacking some useful bits that are in Jessie. I had to enable the Jessie repos to pull in PiL and it's dependancies.

Fortunately, those who do not want systemd have a choice.

Gordon

PiBang is using Raspbian repositories, but using systemd. I installed it last week, and it has been stable so far. I accidently pulled the plug while compiling qupzilla, and there was ext4 recover during the reboot, GCC found a truncated file that I had to delete which it then built and resumed normal service.

X86 Crunchbang seemed to be a bit easier to configure desktop stuff. Thunar was dropped in favour of SpaceFM, but I could configure Thunar to do a copy of a file path. Maybe I have to get used to the multi window and tree on the side style to see the benefits. I'll try installing Thunar sometime. I have already removed vlc in favour of omxplayer. Sounds like mpv with gpu support might be coming, some mention of it being in the testing repository.

But for those of us who dont know, what is the problem with the switch to systemd?

Ron M.

Dzieki, Ron, za post o tresci:

The problem is with the lack, or delaying of switching. systemd is a suite of programs designed to reduce differences between various distributions. It also provides many useful APIs.

The Pidora, which was Fedora remix for Pi and included systemd, seem to have died by the end of academic year ? no new builds for few months.

The developer is expanding what started out as a simple init system into a Swiss army knife that insinuates its way into what should be unrelated parts of the system, and creates compatibility problems for other software. It basically goes against Unix design philosophy, and makes Linus say rude things.

You are assuming, incorrectly, that everyone wants systemd, or that its implementation in every different Linux distribution is an inevitability.

People have choice, and some people will exercise that choice and not use systemd and its as simple as that.

Gordon

Yes it's call FreeBSD

It will kill your first born

The Unix philosophy was for each program to do one thing and do it well. Systemd is a very big program that does lots of things. Some people will say it doesn't do lots of things very well at all, I don't have experience of that. It is meant to allow for faster boot times.

It also replaces a lot of the text logs files produced with binary logs and you need to use a special utility to view the files. This seems a bad move to a simpleton like myself.

When it all works it probably makes little difference to many people. The faster boot times are important for laptop/desktop users but for sysadmins with servers boot time is not normally an issue. (Looks at servers here, uptimes are in the 240days region).

The author of systemd has managed to create a lot of friction between himself and many Linux developers so there are personality issues involved. Systemd as an init system is considered by many to be infecting its methodology into lots of non-init software. So there is worry that you may not be able to easily choose which init system to use, you may be forced to use systemd as other software may fail with out it.

Google Lennart Poettering and make up your own mind. I'm trying to remain neutral and keep an open mind in case a lot of the complaints are due to it being different rather than wrong. But, TBH, it feels a bit wrong.

I dunno - it doesn't do much more than sysvinit - all I can think of offhand is that it makes a pretty good job of restarting daemons and its rather easier to configure than sysvinit ever was. Besides, you can still use the old sysvinit daemon management scripts if you want.

So is the Linux kernel, but I don't hear people whining about not having the much smaller Mach kernel. BTW, I've used Mach-based machines and there can be performance issues ....

I admit I was doubtful at first, but its pretty stable and unobtrusive here. I've been using it since it first appeared in the Fedora distro and don't currently have any problems with it.

I simply haven't notices that. All the logs in /var/log and subdirectories that I've needed to look at in there are the same old text files. dmesg works just the same too.

Thats pretty much the same here.

Quite, though if he had a controlling interest on GNOME, as I hear he did, then that rates him a huge down vote. All I can say is that systemd has been a much better experience that getting lumbered with Gnome 3 - that drove me to XFCE and I've never looked back except to spit.

If you want to pick on parts of Linux that are unnecessarily complex and generally snafued, there are much better targets than systemd: might I recommend grub2 and Gnome3 as prime targets with possibly NetworkManager thrown in for good measure, though its latest incarnation seems to be quite an improvement.

Gnome3 the toolkit is OK, its gnome3 the desktop manager that is barfed beyond belief.

Grub2 is just messy.

Yes, the DTM was what I was objecting to - that and the unbelievably slapdash approach to the final changes to Gnome 2 - testing and attention to detail, i.e. releasing it with documented and supposedly carried over early Gnome 2 features that simply weren't implemented because nobody could be arsed to do it.

Yep. But you left out 'overly complex', 'much harder to configure or customise' and 'manual, what bloody manual'.

There is now no manpage and, incredibly, 'info grub' provides a developer manual but nothing, nada for a plain sysadmin.

For another perspective, IIRC it was Mageia 2 that defaulted to systemd. I do a test VM for new OS releases to figure out the installation and changes in packaging and configuration. The systemd-based test VM installed nicely. However, on first boot, it hung for several minutes, then timed out. It ended up booting to a login prompt without several of the mdadm RAIDs assembled, so it was pretty crippled. The tool to examine the binary logs was not installed by default, and installing it on a crippled system was difficult. In the end, it generated a really pretty gantt-type chart but without any information to provide clues as to how to fix it. That is what caused my intention to be one of the last people on this planet to be running something other than systemd as PID 1. When Mageia 3 (IIRC) made systemd mandatory, I switched to Debian. Now, the situation is repeating.

There are also concerns based on the writings of systemd's main author. One speculation is that the ultimate goal of systemd is to force Digital Restrictions Management onto Linux.

HTH

My main machine has been running Fedora with SystemD for at least a year I don't see any issue with it myself.

Old style initV for Daemons still works for any that have not been converted to utilise SystemD

I suspect the dread is just FUD.

Really?

Move /usr to it's own partition and try booting that.

In fact move /usr /tmp /home and /var to there own partitions and then tell me how it goes. Then make the /bin /lib /lib64 /etc /sbin file systems read only.

Also try to boot to level 3 run system or level 2.

Try dropping to single user to fix something with out rebooting.

I have a desktop system and want to boot without X11 or xdm.

I know that doesn't work, but there's no real rational apart from tradition and historically small disks to split /bin from /usr/bin Besides, since those days the assignment of executables to one or the other directory has become essentially random. Is it even the same between distros?

Both work just fine in their own partitions. Thats part of my standard set-up.

And, yes, I do put locally compiled executables in /usr/local/bin and their config files in /usr/local/etc. Both these also work as expected.

I used to separate /var into its own partition but haven't bothered doing that for several years.

Never tried that under any distro or daemon manager, but why would I want to? It will just screw up my weekly yum update. Besides, if I thought I needed that additional protection I'd just enable SELinux

I still it is a good reason not to use systemd. When the programmer is incapable of solving issues like that, he should not be trusted with a core part of the system.

Previous experience with pulsaudio shows that this is not the first thing this guy has fouled up a working subsystem.

I speculate he is secretly paid by a company that can profit when Linux goes down the drain.