The other day I found out that it's impossible to use yum on a Red Hat machine with an expired RHN subscription. It proved quite unpleasant to work my way around it, as wget was not installed.
Of course you should have a valid subscription, otherwise you won't get security updates. It happens every now and then that I run into people that run five year old RHEL installations which they have never updated because they either are too cheap to pay for it or have never heard about CentOS.
Pretty soon we'll need a valid subscription to start daemons, something made possible by "improvements" like systemd.
It don't understand how you made that conclusion.
This subscription model is becoming quite the rage (Microsoft, Adobe, Red Hat, etc) and this is leading real fast to absurd situations like in the novel from Philip K. Dick (Ubik) where the guy has to pay a few dimes each time he wants to use the door of his apartment.
You have to pay if you want to continue to get binary software from Red Hat, you can always get it in source form even if you're not under a subscription.
I wouldn't be surprised if most sysadmins actually want systemd, or at least is ok with it. From what I've seen the people that really don't want it is more of a vocal minority.
However, the fact that systemd comes with the "USE US OR FAIL!" dire warning (cf "if you don't use Windows, you can't use our ISP") and appears entirely engineered to intefere with everything on a Linux system, no matter how divorced from SETTING UP THE OS it is indicates that the proponents of systemd have one of two aims:
This article isn't even about systemd. You can fairly easily use Debian without systemd. This is about libsystemd which is a small library for interfacing with systemd if it is installed. It doesn't depend on systemd so you can have it installed without having systemd itself installed.
This is not even about systemd, it's a about libsystemd which is just a library for interfacing with systemd. You can have libsystemd installed and still don't have systemd itself installed. Debian has built some of their packages so that they depend on libsystemd, so installing them will bring libsystemd with them. Not a problem if you don't want to run systemd, but if you for some reason can't live with dpkg-query -l | grep systemd printing even a single line then this is apparently a problem.
I think it is rather obvious that there should be a way to have more options. Competition is good, choice is good. Can't someone fork a version without systemd? Also, note that other distribution, like Slackware, don't depend on systemd, but the pressure is mounting.
It's important to realize that this article is not about systemd, it's about libsystemd which is not systemd. It's a library that is used as an interface to systemd, and Debian has built some of it's packages to depend on it. Note that having libsystemd installed in no ways means that you have systemd installed. It's just a library that won't do anything if systemd itself is not installed.
I mostly use GNOME nowadays but still uses fvwm on my work machine. It's a brilliant window manager but you really need to spend the time learning how to configure it. I like GNOME but it doesn't scale when it comes to managing up to hundreds of windows at the same time.
You can already run GNOME on Wayland on Fedora 21. I don't know when they will switch to it by default, but last time I heard anything about it the target was at Fedora 22.
That design change from Gedit has nothing to do with GTK 3, except that it relies on things added in GTK 3. Take a look at Gedit 3.0 to 3.10 and you'll find pretty much a GTK 3 version of Gedit 2.
The thing I worry about is that, since Red Hat (which controls systemd) is a USA company, it is quite likely in bed with the NSA, which has been *proven* to be spying on everyone worldwide as much as it can. So it is possible that there's exploits built into systemd to allow NSA spying.
I would feel much safer if it were a project made by a company in some other country, like Finland, not an American company. American companies cannot be trusted to protect our privacy, or really trusted in any way at all.
I guess you don't run a lot of software then.
An by the way, systemd is not controlled by Red Hat. Even Canonical has had some systemd commiters since long before Ubuntu decided to switch.
I looked at it and from what I could see the only dependency in jessie that I could find was that gvfs-daemons depends on libsystemd0. Libsystemd0 is not systemd, and it's certainly not an init system. It's a utility library that provides an interface for applications to call systemd components but it does not depend on systemd itself.
That's the problem. There isn't a stable release with systemd.
Fedora has so far released six stable releases with systemd, and Red Hat shipped their first stable release with systemd last summer.
The code isn't audited, nor has it seen actual production testing. It was just foisted on the end users without any transition period, possibly breaking every single app that uses the init.d mechanism for starting and control.
It has been shipping in Fedora for the past four years, and in RHEL since last summer. If that's not production testing then what is?
To boot, with systemd's ability to listen on the network, it has a good chance of becoming a massive remote root exploit in the waiting. Does it have any internal security? We can cross fingers that this large blob of new code does more harm than good, but all it takes is one glitch, and it would mean havoc worse than the RTM worm on the UNIX side ages ago, or the Windows worms in the early 2000s.
Inetd has been doing that for years. It has since moved to a different project. Big deal?
Just over four months ago, I updated my Debian testing workstation. To keep a long story short, systemd was installed, and my workstation basically got trashed. It no longer booted properly, and none of my attempts to fix it worked. I used a livecd to perform one final backup.
Have you tried it on a stable OS release that has systemd? I assume you know that testing is a development branch and is supposed to break, otherwise it would be called stable. Fedora has been using it for years now and it has been fine.
Slashdot Mirror
The other day I found out that it's impossible to use yum on a Red Hat machine with an expired RHN subscription. It proved quite unpleasant to work my way around it, as wget was not installed.
Of course you should have a valid subscription, otherwise you won't get security updates. It happens every now and then that I run into people that run five year old RHEL installations which they have never updated because they either are too cheap to pay for it or have never heard about CentOS.
Pretty soon we'll need a valid subscription to start daemons, something made possible by "improvements" like systemd.
It don't understand how you made that conclusion.
This subscription model is becoming quite the rage (Microsoft, Adobe, Red Hat, etc) and this is leading real fast to absurd situations like in the novel from Philip K. Dick (Ubik) where the guy has to pay a few dimes each time he wants to use the door of his apartment.
You have to pay if you want to continue to get binary software from Red Hat, you can always get it in source form even if you're not under a subscription.
He's a prime example of the mentality that keeps Linux from achieving mainstream desktop and laptop use.
He works on GNU, not Linux.
I wouldn't be surprised if most sysadmins actually want systemd, or at least is ok with it. From what I've seen the people that really don't want it is more of a vocal minority.
However, the fact that systemd comes with the "USE US OR FAIL!" dire warning (cf "if you don't use Windows, you can't use our ISP") and appears entirely engineered to intefere with everything on a Linux system, no matter how divorced from SETTING UP THE OS it is indicates that the proponents of systemd have one of two aims:
This article isn't even about systemd. You can fairly easily use Debian without systemd. This is about libsystemd which is a small library for interfacing with systemd if it is installed. It doesn't depend on systemd so you can have it installed without having systemd itself installed.
This is not even about systemd, it's a about libsystemd which is just a library for interfacing with systemd. You can have libsystemd installed and still don't have systemd itself installed. Debian has built some of their packages so that they depend on libsystemd, so installing them will bring libsystemd with them. Not a problem if you don't want to run systemd, but if you for some reason can't live with dpkg-query -l | grep systemd printing even a single line then this is apparently a problem.
I think it is rather obvious that there should be a way to have more options. Competition is good, choice is good. Can't someone fork a version without systemd? Also, note that other distribution, like Slackware, don't depend on systemd, but the pressure is mounting.
It's important to realize that this article is not about systemd, it's about libsystemd which is not systemd. It's a library that is used as an interface to systemd, and Debian has built some of it's packages to depend on it. Note that having libsystemd installed in no ways means that you have systemd installed. It's just a library that won't do anything if systemd itself is not installed.
I mostly use GNOME nowadays but still uses fvwm on my work machine. It's a brilliant window manager but you really need to spend the time learning how to configure it. I like GNOME but it doesn't scale when it comes to managing up to hundreds of windows at the same time.
Ah yes, login screen in F22 and default in F23. Thanks!
Quite a lot of people use GNOME. The 3.0-3.6 versions were a bit shaky, but starting with 3.8 I would say that it's been quite good again.
You can already run GNOME on Wayland on Fedora 21. I don't know when they will switch to it by default, but last time I heard anything about it the target was at Fedora 22.
If it wasn't for that the price of the hardware can often be close to ten times higher than the equivalent x86 machine.
Except that it doesn't.
That design change from Gedit has nothing to do with GTK 3, except that it relies on things added in GTK 3. Take a look at Gedit 3.0 to 3.10 and you'll find pretty much a GTK 3 version of Gedit 2.
pkg's updated usually at least once weekly.
Does that mean that you can go up to six days without a security update?
No that's what dd does.
It looks like Mono has support for WinForms. I've never used it though, and usually used GTK# for GUI development on Linux.
The thing I worry about is that, since Red Hat (which controls systemd) is a USA company, it is quite likely in bed with the NSA, which has been *proven* to be spying on everyone worldwide as much as it can. So it is possible that there's exploits built into systemd to allow NSA spying.
I would feel much safer if it were a project made by a company in some other country, like Finland, not an American company. American companies cannot be trusted to protect our privacy, or really trusted in any way at all.
I guess you don't run a lot of software then.
An by the way, systemd is not controlled by Red Hat. Even Canonical has had some systemd commiters since long before Ubuntu decided to switch.
I looked at it and from what I could see the only dependency in jessie that I could find was that gvfs-daemons depends on libsystemd0. Libsystemd0 is not systemd, and it's certainly not an init system. It's a utility library that provides an interface for applications to call systemd components but it does not depend on systemd itself.
RHEL 7 shipped last summer and uses systemd. It's generally regarded as pretty stable.
If the user can change the keys then I don't see a problem with it, and there are plenty of UEFI motherboards where you can change the keys.
That's the problem. There isn't a stable release with systemd.
Fedora has so far released six stable releases with systemd, and Red Hat shipped their first stable release with systemd last summer.
The code isn't audited, nor has it seen actual production testing. It was just foisted on the end users without any transition period, possibly breaking every single app that uses the init.d mechanism for starting and control.
It has been shipping in Fedora for the past four years, and in RHEL since last summer. If that's not production testing then what is?
To boot, with systemd's ability to listen on the network, it has a good chance of becoming a massive remote root exploit in the waiting. Does it have any internal security? We can cross fingers that this large blob of new code does more harm than good, but all it takes is one glitch, and it would mean havoc worse than the RTM worm on the UNIX side ages ago, or the Windows worms in the early 2000s.
Inetd has been doing that for years. It has since moved to a different project. Big deal?
Did you have to install the entire systemd or just a systemd-related package like for example libsystemd?
UEFI is not about security, but UEFI secure boot is absolutely about security.
Just over four months ago, I updated my Debian testing workstation. To keep a long story short, systemd was installed, and my workstation basically got trashed. It no longer booted properly, and none of my attempts to fix it worked. I used a livecd to perform one final backup.
Have you tried it on a stable OS release that has systemd? I assume you know that testing is a development branch and is supposed to break, otherwise it would be called stable. Fedora has been using it for years now and it has been fine.
Fosdem has over 550 talks, and is completely run by volunteers. It will take some time, but will most likely end up on http://video.fosdem.org/2015.