Slashdot Mirror

Yeah, you can download it for free here.

Have you ever looked at some bash startup scripts? Its difficult to analyse compared to the declarative style. Bash scripts are a much more serious support issue compared to the simplicity of systemd declarative unit files.

Shell, and scripting generally in shell languages, is a key component of all *nix systems. Yes, it's possible to write horrible shell code in an init script, but that's largely the fault of the *author*. Most init scripts are simple; except for whatever custom logic is needed uniquely for this daemon, the rest is boilerplate.

I'd submit that if you can't understand this code, you're not ready to operate or administer a *nix system at the command line or service management debugging level.
https://fedoraproject.org/wiki/EPEL:SysVInitScripts#Initscript_template

It is being discussed for Fedora, RHEL is its derivative.

First, post-install script runs as root. Second, it runs during installation. If putting it in the program (e.g. acroread), the user has to run it to trigger. Most Linus package systems support post-install script. e.g. https://docs-old.fedoraproject...

I have noticed chosen distro does not really make a difference. First my sons used Linux Mint happily, mostly watching videos on Youtube. Later I installed Ubuntu Gnome and they made no remarks, they found the browser on their own. I went back to Linux Mint because my older son likes to update the OS, and Mint has nice icon showing when updates are available. I like using Mint in computers I've promised to maintain (my 70+ years old aunt and uncle and some friends) because the machines really do not require much effort. Seldom update them with remote connection and twice installed printer drivers remotely. If you want to present your kids some nice games, I recommend Fedora Games distribution https://labs.fedoraproject.org... . It has ~100 games pre-installed, they work off-line and some of them are actually ok.

If you REALLY need some bleeding-edge feature that CentOS / Redhat doesn't have, the trade-off might be worth it

This is what the EPEL repo is for. This way you're able to keep a stable foundation while having access to newer packages that RHEL/CentOS wouldn't otherwise have.

It's already available. https://download.fedoraproject...

It was a short wait.

I've been working for a couple of years on Fedora and Linux on RISC-V and the "Seeking alpha" article is the strangest thing. The RISC-V Foundation offers BSD-licensed specs and multiple CPU designs (and a lot more besides). WD, Google, and many more are members. But they are not in any real sense "joining forces to develop a new open-source chip design". The design and chips are already out there, you can make your own FPGA or (if you're very rich) ASIC and have been able to for years. WD are going to switch all their hard drives to RISC-V soon. Google are likely interested because it could be used for their TPUs of their own design. "Joining forces" just means the companies subscribed to the Foundation for a very nominal fee, back-of-the-sofa loose change for these companies.

Nb. don't believe this happens often? See the example from one random distribution:
https://koji.fedoraproject.org...
Look into the changelog – how often governments change their minds and how few days are left to react.

Exactly! This is the MASSIVE point that pro-systemd-ers completely fail to address.

If any portion of my sysvinit system fails to process... at the console I can ctrl-c, carry on, and figure the issue out normally.

This sounds like a possible security issue. You shouldn't be able to modify system behaviour without authentication (if required), as it could allow authentication bypass (just reboot your machine and CTRL-C to access a root shell). For example, there is a recent bug regarding LUKS encrypted partitions that I believe systemd isn't vulnerable to. Even if that is not the case, correctly handling untrusted input isn't something that everyone gets right all the time and I believe systemd was designed to *not* take keyboard input at boot time by default.

If you want to boot in interactive mode with systemd, use systemd.confirm_spawn=1 at the kernel command line (see http://fedoraproject.org/wiki/...), on production systems I have deployed this would require entering a grub password (hopefully with a version of grub that can't be bypassed :-().

https://torrent.fedoraproject.... https://tails.boum.org/torrent... and maybe https://www.techsupportalert.c...

By the way, you can also upgrade like this from shell if that is what you prefer: $ sudo dnf system-upgrade download --releasever=27 $ sudo dnf system-upgrade reboot

This is my preferred method, you do have to install dnf-plugin-system-upgrade first though. The process is described here.

I'm relatively new to fedora, jumping on board at version 25 but I have been pleasantly surprised at how easy the last to distro upgrades have been.

That blob has been fixed both upstream and in Fedora chromium since 2016-09-07: enable_hotwording=false

Super Mario Bros. Or, maybe Robotron. Perhaps, Pac-Man?

Oh, wait, THEY WERE WRITTEN IN ASSEMBLY LANGUAGE! For some projects, the machine code is the source.

Get the fuck off my lawn.

Here are the sources for a rebuild with single rpmbuild command, sometimes I was patching them:

You do not need to upstream a change to use the change, you can keep it forked locally.

FWIW Fedora 27 is targetting 32bit UEFI support for x86_64 cpus (no idea if they'll actually make it...): https://fedoraproject.org/wiki/Changes/32BitUefiSupport You are however right that this probably isn't going to help Clover Trail (which is x86 only as the chip has has x86_64 disabled, plus PowerVR graphics, so no linux drivers, not sure what else wouldn't work), but it might help with some Bay Trail systems.

you mean this? https://fedoraproject.org/wiki...

I don't think many of the people complaining about systemd are "crusty old sys admins", I think we're talking about mostly hobbyists who don't like change. SysV init has never been considered a thing of beauty by those who have to maintain GNU/Linux (or any *ix) systems. That's why systemd is the latest in a long line of replacements, from Apple's LaunchD (also about to be used in FreeBSD) to Ubuntu's Upstart.

Strongly disagree here, at least from RedHat land. SysV-style init scripts have been a solved problem for quite a while. If there are problems, they're usually a result of the daemon/app itself having problems that workarounds are needed for -- workarounds that usually end up in the systemd.service files as well unless upstream finally did something about the underlying issues.

Seriously, when I need to create an init script for something in EL6, just cut and paste https://fedoraproject.org/wiki/EPEL:SysVInitScripts?rd=Packaging:SysVInitScript#Initscript_template, change a few variables and/or add customization needed, and you're done. It's not rocket science and worked perfectly adequately. BSD folks complained about using chkconfig to manage your rcX.d/ structure (compared to rc.conf), but that wasn't that hard to figure out.

Debian (and Ubuntu) init scripts, on the other hand, seem to more or less be an unmitigated dumpster fire of strange techniques and non-standardization. But I've been a RH guy for forever. If systemd had come out of Debian-world, I'd totally understand its genesis and probably sympathize more. That it came out of Fedora/RH strikes me as quite bizarre. The only thing systemd could use to really justify itself with at F14/F15 time was boot speed, something which Debian had seen good improvements at by swapping https://wiki.debian.org/DashAsBinSh. Had Fedora/RH adopted that, we might not have seen systemd exalted to the degree it was.

Team effort to a fault at times :/

Here's Fedora trying to come up with a release name for Fedora 20:
https://fedoraproject.org/wiki...

Which, whatever, ok...

Eventually they decided they could never come up with release names any more, it was just too hard:
https://lists.fedoraproject.or...

Which is why you'll see stuff like 'Fedora Core 25 ("Twenty Five")' - the part in quotes was supposed to be a fun name. But every name is offensive.

https://lwn.net/Articles/48890...

You can't name things after astronomical objects, because those are offensive, because Mars is offensive (apparently lol). Anything named after something religious or mythological offends an atheist. Coffee can't be used because some religions are offended by coffee. Scientist names are sexist because most of them are men, and they even tried that card to claim numbers are offensive, but that one apparently didn't fly.

So when everyone gets together to name something, they eventually just decide that Things are simply not nameable, lest someone be offended. If instead, some asshole was in charge of naming, it would just be named GloryPork and anyone who wanted to bitch about it would have their complaints circular filed. There are benefits to just some asshole in charge.

Team effort to a fault at times :/

Here's Fedora trying to come up with a release name for Fedora 20:
https://fedoraproject.org/wiki...

Which, whatever, ok...

Eventually they decided they could never come up with release names any more, it was just too hard:
https://lists.fedoraproject.or...

Which is why you'll see stuff like 'Fedora Core 25 ("Twenty Five")' - the part in quotes was supposed to be a fun name. But every name is offensive.

https://lwn.net/Articles/48890...

You can't name things after astronomical objects, because those are offensive, because Mars is offensive (apparently lol). Anything named after something religious or mythological offends an atheist. Coffee can't be used because some religions are offended by coffee. Scientist names are sexist because most of them are men, and they even tried that card to claim numbers are offensive, but that one apparently didn't fly.

So when everyone gets together to name something, they eventually just decide that Things are simply not nameable, lest someone be offended. If instead, some asshole was in charge of naming, it would just be named GloryPork and anyone who wanted to bitch about it would have their complaints circular filed. There are benefits to just some asshole in charge.

If you had installed Linux onto Desktops more than 5 years ago you would know what I am referring to.

It's not Bullshit:

https://fedoraproject.org/wiki...

Can't deny that. I meant his "broken out of the box" concept was bullshit, not your reply to him. Sorry for any confusion.

If you had installed Linux onto Desktops more than 5 years ago you would know what I am referring to.

It's not Bullshit:

https://fedoraproject.org/wiki...

A few months ago I got a game that, unfortunately, depended on PulseAudio. I'd been PA-free for years because of problems with it in the past, but I figured it's been long enough that I could give it another chance. As it turns out, this was a terrible idea. You see, I wear headphones. Fairly good ones, with a pretty good volume range. Using them, setting the system volume to around 20-30% of maximum gives a normal, comfortable volume level. I've used them like this for about a decade now with no trouble. At least I did, until I installed Pulse Audio.

You see, PA has a horrible misfeature it calls "flat-volumes". When flat-volumes is enabled, PA-using applications can indirectly change the system-wide volume setting; if the app tries to set its own volume higher than the system volume, PA dutifully increases the system volume along with it. What makes this even worse is, the first time you open an application that uses PulseAudio, it defaults to -- you guessed it -- 100%.

Unfortunately, I had no idea that this "feature" existed until too late. So, after I installed PulseAudio, I started my audio player -- with headphones off, just in case -- and tweaked the various volume knobs to get things comfortable. System volume looked good, and I thought I was set. Then, later, another PA-using application started at 100% while I was listening to music, and it blasted my ears, because suddenly it was at 100% volume when 20% is the safe, comfortable level.

Now I enjoy some minor hearing damage and a constant ringing in my ears. Thanks, Lennart.

Oh, and this absolutely insane default is a known problem. Many distros have started disabling it by default by changing /etc/pulse/daemon.conf, but it's not universal because the PA upstream still thinks flat-volumes is a good default because they think that if 100% is too loud then it's a problem with your soundcard, speakers, etc. and not their fault. (I tried to find the "it's not our fault, your shit is wrong" justification page again to provide a link, but I don't remember what search terms I used to find it before, unfortunately.)

It's not just me, either: here's another story about it from the fedora mailing list, and here's a different one from Reddit. There are even more stories about it online if you search. The only difference with me is I actually suffered some real damage from it.

So, I'd have to say my experience with Pulse Audio has been fairly negative, because my attempt to "skip the whining and bitching, get with the times and install it already" literally caused me physical harm because the know-it-all devs would rather have an unsafe default than admit they did something dumb. People joke about ALSA defaulting to mute, but at least it never blasted my ears.

They didn't expect a group of most competent devs jumping ship and making MariaDB. It's nearly impossible for a fork of something as complex to succeed, thus it was a near-sure bet that control of MySQL would let them slowly extinguish their biggest competitor. Well, proper use cases for Oracle-the-DB and MySQL differ but most people who decide don't know the difference: if that wasn't the case, MySQL wouldn't have the massive usage share it enjoys, as if you need real SQL then Postgres is much better, and if you don't, you're better served by a non-relational database.

Thus, instead of reaping the rewards, they flail wildly and merely make MySQL unusable: stop real new features, shut down access to most of bug database, halt any detailed information about security vulnerabilities (providing fixes only as massive new versions, unfit for backporting). Thus, distributions are switching to MariaDB left and right: Debian just did, Fedora did so ages ago.

(Disclaimer: I work for Red Hat on virtualization)

Red Hat and Fedora have a strict "upstream first" policy. We also have a large team working on KVM and qemu. A natural consequence of this is that we implement many features and fix many bugs in KVM/qemu, and these go upstream, and every other distribution benefits. This is great for open source. But I think your question is How is it good for Red Hat? since your implication is you can free ride on Red Hat's efforts.

There are three cases where you might benefit buying RHEL: Firstly if you call support with a serious bug, then eventually it'll get escalated likely to the person who actually wrote the original code. Secondly RHEL subscribers influence the future development direction (of course, the larger ones have a bit more influence). We really care about how our customers are using the tools. Third, you're probably not just using a single KVM host, you might want to try out OpenStack or oVirt, and we have systems architects who help customers with these larger deployments - the same architects who previously worked with large telco subscribers using OpenStack or huge bank deployments of oVirt, so they have loads of real world experience.

However if you're happy to free-ride, then us developers are happy too, because at the end of the day we really care about Free software.

The summary left out a link to the Release Notes.

Some of them are pretty big.
    Wayland display server by default
    Flatpak

And its noteworthy that Rust is finally in.

...why would I pick Fedora? It's one thing if we're talking servers and I needed RHEL or Oracle Unbreakable, but for personal usage? When SteamOS is based on Ubuntu, why not pick a Ubuntu or even a Debian based distro? .deb is a lot easier to handle than .rpm

I prefer Fedora KDE spin but other people prefer different spins (ie. GUI or CLI) such as Gnome and Xfce but there are others to choose as well. The best way to pick one is to download a Live spin and run it from DVD or USB key before making a decision if you wish to install. You can actually do something similar with the Debian (eg. Ubuntu and Mint) based distributions.

It is important to realize that Fedora is only supported for about a year with a major release approximately every six months and you do get updates fairly frequently although by default they come as delta updates so the rpm packages only contain the data that needs updating. This technique can reduce overall update sizes from 10% to 95%. Like all Linux distributions you are in control of your updates and decide when you want to reboot. Like most Linux distributions you can use the command line or a graphical interface to manage your software.

Obviously when you get a new kernel you should reboot but you decide when you wish to do this.

Installation of Fedora is pretty much the same as installing Mint and it only starts to get complicated if you wish to use the Logical Volume Manager and/or a different filesystem (with Fedora 24 "ext4" was the default).

Basically, if you don't like Fedora then there are plenty of other distributions to choose from.

Select your stream here.

The focus for Fedora 25 with the limited time and resources available, was to provide a polished experience with a single disk image for both the Raspberry Pi 2 and 3. At the time the work started it wasn't clear whether the aarch64 kernel support would land upstream in time. The intention is to officially support the Raspberry Pi 3 as an aarch64 device in Fedora 26. There has been significant enabling work in Fedora 25 but there is still quite a bit more work to do to finish the aarch64 support at time of writing.

https://fedoraproject.org/wiki...

Of course you can change targets ("runlevels") with systemd without rebooting. If you use Fedora, they have even preserved the telinit command and made equivalent "runlevel" targets, to make it easy for people coming from a sysvinit background.

https://fedoraproject.org/wiki...

There are 60, 70, 80 year olds that literally wrote the books on what our modern society is built on.

What are "books"?

You can get them in epub which is one of the many formats that are are available for your book reader . Personally I use Calibre which works perfectly under Fedora 24. My wife actually uses a Kobo reader.

Kids nowadays, can't even do a simple web search. Next, they will be telling us they need an easy mode in games like Dark Souls and Bloodborne ... Oh! Wait.

And that kills user programs without any logging whatsoever.

                      https://lists.fedoraproject.or...

And now it kills background tasks in *secret*, with no logging whatsoever!!!! How fun!!!!

        https://lists.fedoraproject.or...

Lennart Pottering has already indicated he's not interested in enabling logging for this, nor especially in setting up a "warning" setting for KillUserProcess so that you can audit for what systemd *would* kill if you activated the feature. It's all or nothing, baby! Every nohup, screen, tux, shared NX session, rsync, or Petabyte spanning fsck session that gets its remote SSH connection interrupted, all at risk for mid-process interruption!!! Best advertising I've seen to throw out systemd and switch a a BSD UNIX I've seen in at least 30 minutes!

Why ban wolf 3D just as they app store does not like the content?

That depends on whether they banned Id's parent company Zenimax from posting it or whether they banned third parties from posting it.

Why ban NES EMU's just because big N said to?

Different repositories have different excuses.

Why ban wolf 3D just as they app store does not like the content?

That depends on whether they banned Id's parent company Zenimax from posting it or whether they banned third parties from posting it.

Why ban NES EMU's just because big N said to?

Different repositories have different excuses.

Incidentally, when did systemd make its way into Fedora?

30 March 2010; 6 years ago

BTW. For Fedora, all you need to do is choose a Live Spin , boot and test to see if it is to your liking then if you do like what you see you can install. If you don't like it then take out your USB key and reboot back to the OS you were originally using.

Each "Spin" has it's own basic packages, which are enough to get you started. Once you have installed the "Spin" you want then it is a simple matter of using your package manager (GUI) or "dnf" to install particular packages which in turn will install all dependencies relevant to that package.

All up my Fedora 23 KDE spin has about 9.1 GB of system storage comprising 2627 packages some of which are fairly heavy math and scientific programs.

>> New GNOME (in Fedora 24) will also let you easily upgrade to Fedora 25

Ummm...that's one of your "tons of improvements"?

Unfortunately yes. Fedora has had a huge problem with upgrades in the past. They believe they have finally fixed that.

You do know that Fedora has had "spins" for a few years now. You can choose KDE, XFce, LXDE, Mate-Compiz, Gnome, Cinnamon, SOAS (see here ).

As for upgrading or fresh install, I find that it is actually quicker to do a fresh install providing you have configured your filesystems such that your system filesystems don't contain user data. Obviously, due diligence is important here in that you should know what add-ons you require (ie. document them) and any configurations you need such as password and group files (easier to save the /etc directory (it's not that big). For me, going from Fedora 23 to Fedora 24 should take me about an hour since my system filesystems are on an SSD while the rest of my user data is on a 3TB HDD.

It actually took me less than 20 minutes to install Fedora 24 in a virtual machine which was running under Fedora 23. Of course, no matter which way you go it is essential to do backups.

Here is a default install of Fedor 24 on a virtual machine (only showing relevant parts)

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/fedora-root 17938864 4596544 12408024 28% /
tmpfs 1986484 24 1986460 1% /tmp
/dev/sda1 487652 113609 344347 25% /boot

Of course, you may want to add a /usr and /var filesystem but you can always mount appropriate user data filesystems such as databases and web information. A separate /home filesystem IMHO is essential as is additional filesystems associated with user data as long as you can differentiate between what is system data and user data then you don't have to worry about updating when you get a new release. In fact, his concept works for pretty much on all modern operating systems including Unix and even if you want to go to the dark side, MS Windows.

You're aware that Fedora officially supports other DEs, right? : https://spins.fedoraproject.or...

Grab a torrent now and help your peers!

there is always a choice. there is always a path to escape.

one of many. http://cdimage.debian.org/debi...

You can also try the stable releases of Fedora . You can even choose what GUI you would like as the default.

Of course, you can also try one of the many distributions as described here .

If you are an avid gamer then you basically have two choices. 1) Have a Microsoft Operating System or 2) Run a Linux distribution and run a Microsoft OS in a virtual machine if your PC has enough power. There is a third choice and that is to dual boot but IMHO this is rather pointless since most people will only stick with the OS that they play games on.

If you are not willing to switch to a Mac or a Linux distribution then just put up with Microsoft Windows.

THAT'S EXACTLY THE POINT. Need something /sbin/init didn't already do? Have it launch another, specialized service manager of your choosing. Have it launch several! Original inetd, xinetd, crond, supervise/daemontools, linux-ha / heartbeat, ... plenty of options. Have it integrate with other systems however you need it to. That's why you're an administrator.

The problem is that this results in race conditions and "who watches the watchdog" type of scenarios. Plus if the intermediate supervisor dies for some reason the children with then be reparented to PID1, ie the basic simple init, and the restarted supervisor would then lose sight of them properly (ie no longer a parent so can't wait() on them).

You're correct in that it can cause race conditions, but you're not giving sufficient weight to the fact that admins have heterogenous solutions for those. Who watches the watcher? Maybe a cron job. Maybe puppet. Maybe another service. Maybe monit or any other monitoring system you have. An administrator should look at their own likely failure states and automate accordingly.

How many times has xinetd crashed on you in the last 10 years? How often does daemontools or supervise crash on you? These types of servers are single-purpose designed and have well tested code. Small, simple, focused programs that do one thing and one thing well precisely to reduce the problems that can result. /sbin/init forking a shell and forking a small bit of C code (eg, svscan) with a monitor running via cron (and maybe a second monitor running persistently as a distinct service) is oodles more auditable, reliable, and understandable than a monoculture of systemd attempting to be responsible for everything.

Fedora can't even do that any more... Fedora IS the upstream and there's basically no one who can push back at the Fedora level for a dumb upstream systemd decision

Note quite. Fedora is not the upstream for systemd, systemd is its own upstream and frankly has been driven more by CoreOS needs than Fedora ones recently (with the whole resolved and networkd stuff which are not used in Fedora since we use NetworkManager). Check the number of patches in the F24 spec for instance. The discussion is ongoing at the moment and this will become a F25 change that gets debated by FESCO. It's likely that the Server and Workstation product, for instance, may split in their behaviours here given the different use cases.

Be fair. That entirely was the situation. It's a neat sophist trick, wearing the upstream hat and the downstream hat and claiming the other guy with the hat is tying your hands. (Not you personally, the collective "you".) https://bugzilla.redhat.com/show_bug.cgi?id=1170765#c58 The simple fact is that huge bits of what once had been Fedora-level policy is now more or less handled by "upstream" and there's continual pressure to not deviate from upstream. Anyone with any experience in any sort of team politics should be familiar with that.

systemd was and is a power grab, plain and simple

No it is an attempt to fix our broken init landscape (it's notable that no one wanted to keep sysvinit as the default in the Debian CTTE decision) and solved not only the sysvinit problems but the upstart ones as well.

Go back and look at any of the small decisions over time from Fedora 15 onward made to make it extremely inconvenient to use any other init system anywhere in the ecosystem.

Fedora is a well integrated distribution with

THAT'S EXACTLY THE POINT. Need something /sbin/init didn't already do? Have it launch another, specialized service manager of your choosing. Have it launch several! Original inetd, xinetd, crond, supervise/daemontools, linux-ha / heartbeat, ... plenty of options. Have it integrate with other systems however you need it to. That's why you're an administrator.

The problem is that this results in race conditions and "who watches the watchdog" type of scenarios. Plus if the intermediate supervisor dies for some reason the children with then be reparented to PID1, ie the basic simple init, and the restarted supervisor would then lose sight of them properly (ie no longer a parent so can't wait() on them).

You're correct in that it can cause race conditions, but you're not giving sufficient weight to the fact that admins have heterogenous solutions for those. Who watches the watcher? Maybe a cron job. Maybe puppet. Maybe another service. Maybe monit or any other monitoring system you have. An administrator should look at their own likely failure states and automate accordingly.

How many times has xinetd crashed on you in the last 10 years? How often does daemontools or supervise crash on you? These types of servers are single-purpose designed and have well tested code. Small, simple, focused programs that do one thing and one thing well precisely to reduce the problems that can result. /sbin/init forking a shell and forking a small bit of C code (eg, svscan) with a monitor running via cron (and maybe a second monitor running persistently as a distinct service) is oodles more auditable, reliable, and understandable than a monoculture of systemd attempting to be responsible for everything.

Fedora can't even do that any more... Fedora IS the upstream and there's basically no one who can push back at the Fedora level for a dumb upstream systemd decision

Note quite. Fedora is not the upstream for systemd, systemd is its own upstream and frankly has been driven more by CoreOS needs than Fedora ones recently (with the whole resolved and networkd stuff which are not used in Fedora since we use NetworkManager). Check the number of patches in the F24 spec for instance. The discussion is ongoing at the moment and this will become a F25 change that gets debated by FESCO. It's likely that the Server and Workstation product, for instance, may split in their behaviours here given the different use cases.

Be fair. That entirely was the situation. It's a neat sophist trick, wearing the upstream hat and the downstream hat and claiming the other guy with the hat is tying your hands. (Not you personally, the collective "you".) https://bugzilla.redhat.com/show_bug.cgi?id=1170765#c58 The simple fact is that huge bits of what once had been Fedora-level policy is now more or less handled by "upstream" and there's continual pressure to not deviate from upstream. Anyone with any experience in any sort of team politics should be familiar with that.

systemd was and is a power grab, plain and simple

No it is an attempt to fix our broken init landscape (it's notable that no one wanted to keep sysvinit as the default in the Debian CTTE decision) and solved not only the sysvinit problems but the upstart ones as well.

Go back and look at any of the small decisions over time from Fedora 15 onward made to make it extremely inconvenient to use any other init system anywhere in the ecosystem.

Fedora is a well integrated distribution with

THAT'S EXACTLY THE POINT. Need something /sbin/init didn't already do? Have it launch another, specialized service manager of your choosing. Have it launch several! Original inetd, xinetd, crond, supervise/daemontools, linux-ha / heartbeat, ... plenty of options. Have it integrate with other systems however you need it to. That's why you're an administrator.

The problem is that this results in race conditions and "who watches the watchdog" type of scenarios. Plus if the intermediate supervisor dies for some reason the children with then be reparented to PID1, ie the basic simple init, and the restarted supervisor would then lose sight of them properly (ie no longer a parent so can't wait() on them).

Fedora can't even do that any more... Fedora IS the upstream and there's basically no one who can push back at the Fedora level for a dumb upstream systemd decision

Note quite. Fedora is not the upstream for systemd, systemd is its own upstream and frankly has been driven more by CoreOS needs than Fedora ones recently (with the whole resolved and networkd stuff which are not used in Fedora since we use NetworkManager). Check the number of patches in the F24 spec for instance. The discussion is ongoing at the moment and this will become a F25 change that gets debated by FESCO. It's likely that the Server and Workstation product, for instance, may split in their behaviours here given the different use cases.

systemd was and is a power grab, plain and simple

No it is an attempt to fix our broken init landscape (it's notable that no one wanted to keep sysvinit as the default in the Debian CTTE decision) and solved not only the sysvinit problems but the upstart ones as well.

Go back and look at any of the small decisions over time from Fedora 15 onward made to make it extremely inconvenient to use any other init system anywhere in the ecosystem.

Fedora is a well integrated distribution with a set scope of things supported clearly defined. Just as we don't support a BSD kernel the fundamental frameworks are made clear so that the stuff packaged can be well tested against that base.

People who didn't want to use systemd absolutely were being subjected to it against our will. To claim otherwise is ludicrous.

You are entirely free to use Slackware, Gentoo, Debian, Devuan or any other non-systemd distro you wish. It's notable that Arch and Suse switched to systemd of their own free will and neither are downstream of Fedora or subject to decisions there.

THAT'S EXACTLY THE POINT. Need something /sbin/init didn't already do? Have it launch another, specialized service manager of your choosing. Have it launch several! Original inetd, xinetd, crond, supervise/daemontools, linux-ha / heartbeat, ... plenty of options. Have it integrate with other systems however you need it to. That's why you're an administrator.

The problem is that this results in race conditions and "who watches the watchdog" type of scenarios. Plus if the intermediate supervisor dies for some reason the children with then be reparented to PID1, ie the basic simple init, and the restarted supervisor would then lose sight of them properly (ie no longer a parent so can't wait() on them).

Fedora can't even do that any more... Fedora IS the upstream and there's basically no one who can push back at the Fedora level for a dumb upstream systemd decision

Note quite. Fedora is not the upstream for systemd, systemd is its own upstream and frankly has been driven more by CoreOS needs than Fedora ones recently (with the whole resolved and networkd stuff which are not used in Fedora since we use NetworkManager). Check the number of patches in the F24 spec for instance. The discussion is ongoing at the moment and this will become a F25 change that gets debated by FESCO. It's likely that the Server and Workstation product, for instance, may split in their behaviours here given the different use cases.

systemd was and is a power grab, plain and simple

No it is an attempt to fix our broken init landscape (it's notable that no one wanted to keep sysvinit as the default in the Debian CTTE decision) and solved not only the sysvinit problems but the upstart ones as well.

Go back and look at any of the small decisions over time from Fedora 15 onward made to make it extremely inconvenient to use any other init system anywhere in the ecosystem.

Fedora is a well integrated distribution with a set scope of things supported clearly defined. Just as we don't support a BSD kernel the fundamental frameworks are made clear so that the stuff packaged can be well tested against that base.

People who didn't want to use systemd absolutely were being subjected to it against our will. To claim otherwise is ludicrous.

You are entirely free to use Slackware, Gentoo, Debian, Devuan or any other non-systemd distro you wish. It's notable that Arch and Suse switched to systemd of their own free will and neither are downstream of Fedora or subject to decisions there.

Why do you think there no solid reasons for this new default. It is something somebody told you, or are you just presenting what you imagine as facts?

Th reason for this new default is because Gnome wasn't cleaning up after itself and no one could be bothered to find out why. Killing everything after logout was the only fix they could find: https://lists.fedoraproject.or...

Fedora 23 doesn't have that version of systemd yet - this change appears in version 230 and F23 has version 222 right now.

There's also currently a discussion on the "devel" Fedora mailing list about it, and most people are calling for that to be turned into a "system-wide change" for F25. That would mean that the Fedora Engineering Steering Commitee (FESCo) would have to properly discuss this and determine whether or not this change should be accepted (the default can be turned off at compile time). Someone suggested having it on for the Workstation variant and off for the Server variant.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZNQW72UP36UAFMX53HPFFQTWTQDZVJ3M/

FWIW, I've only found one quote by Lennart Poettering about the entire thing (source):

I am not sure I follow. Note that user@.service is already reference counted by the login sessions around. i.e. it is started before the first user session of a specific user is created, and stopped when the last user session ends. I don't follow why that behaviour is not sufficient?

Lennart seems to have learned by now to be careful what he says in public, so I don't expect him to call anyone a moron here.

No, there's a similar debate blowing up on the Fedora list as well, it's just that there's hardly anyone left with the energy to fight the cabal any more.

From the Fedora List:

In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout. It has been discussed for ages now among many OS people, that this should possible but certainly not be the default, but nobody dared so far to flip the switch to turn it from a default to an option. Not cleaning up user sessions after logout is not only ugly and somewhat hackish but also a security problem.

...

I am pretty sure we should consider it our duty as Fedora developers to improve the Linux platform, and I am pretty sure that properly cleaning up processes on logout is a step towards that, not against it.

https://codecs.fedoraproject.org/openh264/24/

Looks like they will support H.264 in F24. Kind of scary actually.

For example I think the Linux (POSIX?) file system was written before they invented autocomplete, it's all TLAs like /var/usr/bin/lib/wtf.

In this case it's the file system hierarchy, not the file system. Personally, I think the argument for longer filenames is bogus. Using longer filenames isn't necessarily going to make their purpose any more clear, and for everything outside of the home folder, the novice user should probably not be touching that stuff, any more than they should be poking around in C:\Windows. Being user friendly is not a feature for things that are not intended for casual use. Autocomplete is an even worse argument: I'm not saving any keystrokes by typing /bi[TAB] versus /bin.

However, your example was somewhat poorly chosen in another sense, because while there is no call to make the names longer, at least one major distribution got rid of some of those top-level folders. Fedora likes to move fast and break things anyway, but in this case the historical justification for splitting up the binaries was, well, kind of ridiculous. Thompson and Ritchie created that particular issue a couple years before CP/M inflicted drive letters on us, but forty years later it's still a bug worth fixing. Most of today's code and systems will be pretty hoary in forty years, and I'm not sure I would consider it a virtue if it ran unmodified on my...hmm, well, whatever system exists at that time. One can always use emulation to provide old features, but most of the time I'd rather that not be happening at the OS level.

Given that Windows inherited both 8.3 filenames and drive letters from CP/M, it makes sense to talk about them in the same context. Drive letters are pretty harmless, but having "secret" 8.3 filenames and unremovable folders is probably something that needs to go. Linux definitely doesn't have those kind of problems.

If you really feel that sysvinit was something that should be kept around, [a] you're in the substantial minority; even OpenRC is mostly written in C (check their GitHub page if you don't believe me), and [b] you're welcome to maintain it -- and you should, because no one else is willing to.

There's less point NOW, but that's due to the land grab that systemd's developers performed, not due to technical evaluation... and certainly not in the Fedora 15 days. Anyone who's ever been in a large, political org with management trying to gain control of systems and services in such a way that no one objects strenuously enough at any given step, but that makes them difficult to remove at the end, should be that pattern. Or anyone who's ever been a boiled frog.

There was some guy on here complaining that people didn't get enough use out of the actual sysv init's abilities (i.e. things provided by inittab). He was absolutely right. inittab does such a bad job of managing services that practically no one used it -- certainly not for anything important. So people rewrote init functionality into their own scripts. And then they duplicated it, for each script. Sometimes better than other times. For thirty years.

And... what exactly was wrong with that? A core /sbin/init that does very little but reap zombies and for all important actions hands things off to userland scripts? This model works fine for many other aspects of many OS's... A core micro kernel that's simple, auditable, secure, and trusted, and user-level code to do everything else?

A typical argument in favor of systemd was that people writing scripts to imperatively handle startup was somehow wrong, without clearly explaining why. I'll admit that Ubuntu's scripts were a little messy, but (ironically, given how it spread), in RedHat-land things were quite nice. If you didn't want to have a startup script, you could use one of several service managers to deal with the startup and tear down (xinetd, for example). If you wanted one, it was extremely simple to write one.

1) Cut and paste https://fedoraproject.org/wiki/EPEL:SysVInitScript#Initscript_template
2) Replace 2 or 3 variables
3) Customize further as or if needed.

Done. That's not hard.

It's distinctly possible that had OpenRC been more mature, it could have had more uptake. What is completely certain is that sysvinit needed a stake put through its heart, and even though they have (moved a great deal of code into C libraries, added dependency resolution, cgroup support, and parallel startup, and generally) cleaned up the codebase quite a bit, I still don't think they have the right balance. You can put a lot of lipstick on a pig (daemontools, or whatever you like), but most of the time, providing half of the features you really need is worse than providing none at all. Even in OpenRC, the init process either does too much (even for a small codebase there's still stuff in there no one uses), or too little (e.g. without process tracking it has no idea if the services it starts are still running).

Mu.

Seriously, you're begging the question here. If I want a service manager, I should use one. If I want something to hold sockets open for me, I should use a supervisor (inet, xinetd, etc). These all functioned (and function!) perfectly well as independent subsystems. There's very little that MUST be handled in pid1, and very little reason why some-random-administrative-task MUST be handled by something from the systemd-* project vs what was already out there.

What it sounds like you're saying is that you like the way things are broken right now, as opposed to the different broken that some other system provides. That's great for you, but I wouldn't lump anyone else into that box. Especially if you're pining for ye olde init scripts; those aren't