SoylentNews is people
SoylentNews
from the resistance-is-futile.-/home-will-be-assimilated dept.
Good News:
Linux home directory management is about to undergo major change:
With systemd 245 comes systemd-homed. Along with that, Linux admins will have to change the way they manage users and users' home directories.
[...] Prior to systemd every system and resource was managed by its own tool, which was clumsy and inefficient. Now? Controlling and managing systems on Linux is incredibly easy.
But one of the creators, Leannart Poettering, has always considered systemd to be incomplete. With the upcoming release of systemd 245, Poettering will take his system one step closer to completion. That step is by way of homed.
[...] let's take a look at the /home directory. This is a crucial directory in the Linux filesystem hierarchy, as it contains all user data and configurations. For some admins, this directory is so important, it is often placed on a separate partition or drive than the operating system. By doing this, user data is safe, even if the operating system were to implode.
However, the way /home is handled within the operating system makes migrating the /home directory not nearly as easy as it should be. Why? With the current iteration of systemd, user information (such as ID, full name, home directory, and shell) is stored in /etc/passwd and the password associated with that user is stored in /etc/shadow. The /etc/passwd file can be viewed by anyone, whereas /etc/shadow can only be viewed by those with admin or sudo privileges.
[...] Poettering has decided to make a drastic change. That change is homed. With homed, all information will be placed in a cryptographically signed JSON record for each user. That record will contain all user information such as username, group membership, and password hashes.
Each user home directory will be linked as LUKS-encrypted containers, with the encryption directly coupled to user login. Once systemd-homed detects a user has logged in, the associated home directory is decrypted. Once that user logs out, the home directory is automatically encrypted.
[...] Of course, such a major change doesn't come without its share of caveats. In the case of systemd-homed, that caveat comes by way of SSH. If a systemd-homed home directory is encrypted until a user successfully logs in, how will users be able to log in to a remote machine with SSH?
The big problem with that is the .ssh directory (where SSH stores known_hosts and authorized_keys) would be inaccessible while the user's home directory is encrypted. Of course Poettering knows of this shortcoming. To date, all of the work done with systemd-homed has been with the standard authentication process. You can be sure that Poettering will come up with a solution that takes SSH into consideration.
Older articles:
- Pack Your Bags – Systemd Is Taking You To A New Home
- Systemd-Homed Merged As A Fundamental Change To Linux Home Directories
Will systemd be considered complete once the kernel and boot loader have been absorbed into systemd?
(Score: 5, Funny) by The Mighty Buzzard on Friday May 01 2020, @11:43AM (29 children)
What the hell, Leannart? Why would you store important information in a human readable form like json when you could store it in a binary container that requires a specific executable tool to interact with?
My rights don't end where your fear begins.
(Score: 5, Insightful) by Azuma Hazuki on Friday May 01 2020, @01:02PM
Fecking LOL. +1 Funny, though it's also tragic.
I am "that girl" your mother warned you about...
(Score: 3, Interesting) by janrinok on Friday May 01 2020, @01:08PM (23 children)
You've just answered your own question. It would require a specific executable tool.
Your drive can be encrypted. You can move it to another computer that you have never used before and plug it in, unlock the encryption, and it can automatically create your user credentials on the new machine. Your files remain secure. Only you have access to them because they are now protected by your user ID and the file permissions. You can work on your files on this computer and then simply unplug the drive and take your data away safely leaving nothing on the computer that you used.
His proposal also allows for a system that computers can prevent the issuing of administrative permissions to any drives mounted this way to protect the computer itself.
You don't have to like it - in fact, I'm fairly sure that you won't - but have you got a better solution to this problem? Because here is your opportunity to be very wealthy and solve a long-established problem with data security.
(Score: 4, Informative) by tekk on Friday May 01 2020, @01:14PM (1 child)
The joke is that Systemd likes to use opaque binary formats which require special tools where they used to just be text files.
(Score: 5, Funny) by janrinok on Friday May 01 2020, @01:16PM
(Score: 5, Insightful) by Grishnakh on Friday May 01 2020, @03:06PM (12 children)
but have you got a better solution to this problem?
What if I don't consider this a problem at all? I have no desire at all to move my files, encrypted, to another computer I've never used before.
However, I absolutely do require that I can log into my account with SSH, which apparently is a no-go with this "solution".
The problem here is that this "solution" breaks existing use-cases, in favor of a different use-case that they haven't shown that anyone really needs.
(Score: 0) by Anonymous Coward on Friday May 01 2020, @04:25PM (2 children)
I like systemd and use systemd, but yes I don't see any value in homed/homectl.
Assuming they get SSH working, I can see this as something acceptable to use but I don't see why anyone would actually want it. Maybe, maybe this could be useful in enterprise environments. Maybe homed/homectl would make it easier to have a school or business environment in which any user can login on any machine and use it as though it has been their own machine all along. Of course there are dozens of architectural ways to tackle that problem and thousands of technologies you can use, I'm not at all sold that this is a desirable solution.
(Score: 3, Informative) by PocketSizeSUn on Friday May 01 2020, @05:31PM
Those environments use LDAP where this solution is both redundant, pointless, and broken.
(Score: 2) by janrinok on Saturday May 02 2020, @07:39AM
The use of homed is at the user's discretion. You can keep your SSH access without making any changes to your system and forego the homed.
The major systemd distros have insisted on this because many people rely on it.
(Score: 4, Insightful) by NotSanguine on Friday May 01 2020, @08:41PM (7 children)
Apparently, TFS (and likewise TFA) has that bit wrong.
According to the homectl man page [freedesktop.org]:
Just to clarify, I'm not advocating wide adoption of systemd-homed. In fact, I'm not at all sold on the purported use case at all.
It seems to me that it would be both simpler and more useful to just set ownership on portable files to be the same as the logged-in user plugging in the device with the files on them.
This would be a simple file system shim which wouldn't require creation of a parallel set of data and tools to manage portable user data.
If one *really* wanted to have an entire user configuration environment stored on a USB key or similar, an additional login shim could detect such a portable store at login and ask the user if they wished to use the portable storage as a home directory.
What's more, storing independent user configuration information on a portable device opens up serious InfoSec issues. Especially since such data must be unencrypted on the device in order to configure the system to accept *unknown* logins onto arbitrary systems.
What could go wrong? I'd elucidate, but the max comment size here would be easily exceeded.
I'm curious. Can *anyone* present a use case that would *require* the use of something like systemd-homed?
N.B.: I use systemd on the systems I manage, mostly without issue. But this seems like a disaster waiting to happen.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 4, Insightful) by digitalaudiorock on Friday May 01 2020, @09:22PM (5 children)
Wow...I do NOT get how that --ssh-authorized-keys option is supposed to work. As I understand it, because the home is encrypted until you've logged in, it's impossible to read ~/.ssh which IS what the ssh daemon will assume(??). So that option would have to specify a keys file somewhere else?...where and with what ownership/permissions. And again most importantly, how is ssh itself going to look there? Can't make any sense out of that one.
Everything I read indicates that ssh just can't work, at least not unless the ssh devs made changes the (hopefully) would refuse to consider. Sounds like that option is a pipe dream. This is probably the silliest and least useful change those ass-hats have come up with so far.
Tom
(Score: 2, Insightful) by DECbot on Friday May 01 2020, @10:03PM
What makes you think there will ever be an openssh solution? I'm betting the solution will simply be systemd-sshd and sshdctl to manage ssh connections and configuration. Not sure what this will look like, but I doubt it will be binary data or INI files or JSON or encrypted directories... It's got to be unique. Oh, we haven't done a distributed database yet. That's the method, ssh login information will be stored in a distributed no-sql database with custom btree topology. /s
cats~$ sudo chown -R us /home/base
(Score: 2) by NotSanguine on Saturday May 02 2020, @02:28AM (2 children)
A fair point. Which made me wonder how exactly that might work.
As I was reading through this [reddit.com] and saw this comment [reddit.com] which suggests the following:
Since the host in question must run an instance of sshd to which the client can connect, you can store keys *on the host* for a specified set of users by specifying an absolute pathto such keys vs. one relative to the (still encrypted) home directory in the sshd configuration That wouldn't support an arbitrary set of users, but is probably workable for the client/desktop use case Poettering discusses [reddit.com].
All that said, I still think it's a stupid idea. Given the source, I'm not very surprised.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 1) by DECbot on Saturday May 02 2020, @06:45AM (1 child)
While I like my distributed database solution for ssh keys the sister post, I think the simple solution would be to stick the authorized machines and public ssh keys in the json file with user id and password and keep the private ones in ~/.ssh. The question is: will openssh bend to Pottering and look in new-standard ways in shared json config files for public keys or will he make his own implementation of sshd to get the required changes done? Of course, RH may come down and say "We don't need to reinvent ssh. Openssh is sacrosanct and doesn't need to change--we just need all the distros to change where sshd must look for keys via the configs. Therefore, only users that can use ssh are those blessed by an admin adding their keys and authorized machines to the systemd approved /etc/sshd/keys/userkeys and /etc/sshd/user/authorizedmachines files." Because, you know, it is bad to put users and passwords in /etc but sticking ssh keys there is just fine.
cats~$ sudo chown -R us /home/base
(Score: 2) by rleigh on Saturday May 02 2020, @08:09AM
Debian (internally) uses a patched OpenSSH to store the public keys in LDAP. This avoids the need for a centrally mounted NFS home directory on every system. It also means the permitted keys are centrally managed and that key-only access to systems can be revoked in a single action. Maybe this has been picked up by the OpenSSH people now, but IIRC they used to be averse to this approach.
(Score: 2) by hendrikboom on Saturday May 02 2020, @02:38PM
That plug-in file system is encrypted?
So why not let the login password for the visiting user be the passphrase for the decryption key?
The encrypted filesystems I have demand a passphrase when I mount them.
All we'd need is a change to the login process to enable the user to mount his home directory by passphrase.
Or that could even be done by an automounter, that subsequently logs in the user plugging the encrypted file system in.
seems simple.
-- hendrik
(Score: 2) by janrinok on Saturday May 02 2020, @07:40AM
(Score: 0) by Anonymous Coward on Saturday May 02 2020, @08:26AM
To be fair, this is not an entirely new problem with SSH. Similar problems occur when using NFS and Kerberos: unless you've previously authenticated (and your credentials have not expired), the ssh server cannot access the NFS filesystem and cannot authenticate against an authorized_keys file on such a filesystem. And even if it could read authorized_keys, you would end up with a session that couldn't initially access any files (may not be a huge problem but e.g., you wouldn't be able to rely on your shell startup scripts running all the time).
One way to avoid this particular problem is to use GSSAPI authentication in SSH (instead of public key authentication). You can forward credentials from the connecting machine to the SSH server (GSSAPIDelegateCredentials option) and then those credentials enable access your files via NFS. Perhaps someting similar could be accomplished with encryption keys. Maybe you could even do such a thing with GSSAPI as it already exists.
(Score: 1) by DECbot on Friday May 01 2020, @03:58PM (7 children)
So, if the login information is in the encrypted partition, on a system you have never touched before how do you decrypt the drive? Does a pop-up show up over the login prompt asking you to decrypt the drive? So the system should automatically trust and attempt to decrypt all drives plugged into it? I'm asking because I've never looked into this beyond what the talking heads praise and blather about on ye-ol' podcasts.
cats~$ sudo chown -R us /home/base
(Score: 2) by janrinok on Friday May 01 2020, @05:50PM (6 children)
In exactly the same way that you decrypt a LUKS drive now. We've been using LUKS for many years. It works. All my hard drives are secured using it. You can type in a password or use something like 4kb of random data as the key and store it on a usb key.
If you don't want your machines to have the facility to accept such a drive you simply disable the LUKS support for specific or all USB devices.
(Score: 1) by DECbot on Friday May 01 2020, @06:40PM (5 children)
Right, I'm using LUKS to encrypt my SSD on my ZFS on root laptop now. That gets decrypted on boot before booting into a kernel. My question is regards to the scenario where you have a portable drive with the LUKS encrypted home directory. I'm guessing the user's password file, the replacement for /etc/shadow, is unencrypted somewhere on that volume with the encrypted partition? Perhaps in a second partition? Or is the encrypted partition really just an LUKS encrypted file on an unencrypted partition with the user info the system can use authenticate against?
And am I required to use LUKS or can I use the native ZFS encryption?
cats~$ sudo chown -R us /home/base
(Score: 2) by janrinok on Friday May 01 2020, @08:36PM (3 children)
OK, as i understand it:
When you log in to your home directory the password is used to decrypt the LUKS encryption that has been applied automatically to the home directory contents. When you log out the home directory contents are securely encrypted again using LUKS. The encryption of the home directory is always LUKS, as this is the linux standard encryption.
It is possible to have your home directory on a separate drive which can - but need not necessarily - be removable.
If it is removable it is possible to use the same drive on different computers. The target computers must be configured to accept such drives and the configuration remains under the control of the administrators of the computers. Thus if someone doesn't want to give anybody the ability to insert a drive then he can configure the computer to simply ignore the drive when it is inserted, which might simply be a case of plugging it in via a USB cable. However, an administrator can configure the computer to accept such drives. I do not have any details of this process but the capability was discussed in various computer magazines over 6 months ago.
It is also possible to encrypt an entire drive - which it appears that we both do. I do not know if any other encryption than LUKS can be used for this process which would still enable systemd.homed to function, but I doubt it. As systemd.homed has not yet been released I haven't got any experience of using it. I have read reports about the potential of the new systemd.homed and have seen the various git discussions regarding its development . It is not clear from what I have read whether a fully encrypted drive is first decrypted as it usually would be by the system and then the home directory is subsequently decrypted again when you log in, or whether the full disk encryption defeats the 'homed' function entirely. It is also possible that the earlier publicity was also speculative and could therefore be inaccurate.
It is entirely possible that the drive remains in place inside a single computer but, as it is encrypted when the user logs out, even the administrator cannot get access to your private data. He will simply see an encrypted user area. It will not protect your data once you have logged in as root will still have access to your user partition if you are on a network, although other users could be controlled by the usual user/group permissions..
The user data that is stored as JSON provides sufficient information to replicate your user id on whichever computer it is connected to providing that the administrator has configured the computer appropriately. It also - if I understand it correctly - manages to deconflict your userid from existing userids already on the computer. I do not know how it does this.
(Score: 3, Interesting) by Bot on Friday May 01 2020, @10:00PM (2 children)
What's missing from this scenario is that home directories contain machine-specific configuration files. Which means that the portable home will be screwed up when you take it back home. Hey why is all audio rerouted to one channel when my soundcard has 8? Hey why the window is outside the screen?
Has poettering addressed these INSIGNIFICANT details?
Account abandoned.
(Score: 1, Insightful) by Anonymous Coward on Friday May 01 2020, @10:13PM (1 child)
Those are insignificant issues fixed by an if statement.
(Score: 2) by Bot on Sunday May 03 2020, @07:21PM
It's trivial to split machine dependent prefs from document related prefs, but done on the whole of an ecosystem it is a tragedy. Where would you put that if statement? systemd? preference parsing code? transfer routines?
Account abandoned.
(Score: 0) by Anonymous Coward on Friday May 01 2020, @09:34PM
If you use the drive only in userland, ZFS native encryption is probably preferable. For anything that needs early mount, or other sw integration, you probably want LUKS.
(Score: 3, Insightful) by Bot on Friday May 01 2020, @01:35PM (3 children)
Good objection but, let's proceed in an orderly manner. Soon the limitation of json will become apparent and a new DSL will be needed to deal with the pesky problem of access to home dirs. Just have people onboard this for the moment, you want people to get entrapped first.
Account abandoned.
(Score: 2) by bzipitidoo on Friday May 01 2020, @07:15PM (2 children)
Limitations of JSON? What limitations are you talking about? That it isn't YAML?
(Score: 2, Touché) by DECbot on Friday May 01 2020, @07:27PM (1 child)
It's not some sort of binary format only readable by some systemd utility.
cats~$ sudo chown -R us /home/base
(Score: 0) by Anonymous Coward on Saturday May 02 2020, @05:32AM
In case you are wondering, they are actually working on a binary form of JSON. There are a couple, actually. But the one people seem to be settling on is UBJSON and its introduction has be suggested a few times to systemd.
(Score: 5, Insightful) by Anonymous Coward on Friday May 01 2020, @11:46AM (2 children)
This exists only to create problems, add pointless complexity, and cause incompatibilities. Imaginary "improvements" are the fig leaf, breaking things is the real purpose.
(Score: 3, Interesting) by EEMac on Friday May 01 2020, @07:49PM (1 child)
We're seeing (continued, growing) tension between:
* Linux users/hobbyists who were the core of the movement at the beginning
* Large copmanies who fund Red Hat and a lot of Linux development
Linux hobbyists want a computer that's fully open and that they control. That was the promise of Linux in the beginning, after all: completely open source, no corporate jerks interfering with you, you're completely in charge of your own computer.
Large organizations want things locked down, remotely manageable, and they have security concerns that just don't make sense at the hobbyist level.
Will Linux end up as another corporate OS, with a few distros like Slackware available to meet hobbyist needs? Can hobbyist distros still run the software people want without including corporate-friendly stuff like systemd? It will be interesting to see how this plays out.
(Score: 1, Interesting) by Anonymous Coward on Friday May 01 2020, @09:42PM
Haha, "security concerns".
The large organization I work for insists on monthly password changes using large restrictive password requirements, forcing everyone to write them down on sticky notes. Then the very same security department wants to implement a new threat management tool that they downloaded off github and comes as Debian packages. But all our Linux servers run Red Hat. So they can't get it to work on Red Hat because nobody knows how the threat management tool even works, and the developers don't know jack shit about anything other than installing it on the latest Ubuntu with the latest bleeding edge dev libraries of everything. So nobody can make this work on Red Hat, even though the application advertises itself as Red Hat ready. So instead of recognizing the red flags that are flying up everywhere, security doubles down and runs the application in a container, that will never see a security update again in it's lifetime. All the while the "threat management tool " needs to be able to contact servers all over the world to update it's threat identifiers punching huge holes in our firewall.
So now we have an application, downloaded from the internet with no vendor support, frozen in time with what ever security vulnerabilities may be found in the future, scanning our internal networks and communicating with unknown and uncontrolled external servers outside of our networks. For all I know it's mining bitcoin. AND OUR SECURITY DEPARTMENT DEMANDED THIS TOOL.
So no, large organizations are not driving security concerns. They want their Linux servers to act more like point and click windowish tools.
(Score: 5, Insightful) by Anonymous Coward on Friday May 01 2020, @11:50AM (1 child)
>> Lennart Poettering has always considered systemd to be incomplete
And he always will... until it takes over 100% of the functionality, at which point we will start calling it Lennux (as in, "I can't get my Lennux system to boot because of systemd").
(Score: 0) by Anonymous Coward on Friday May 01 2020, @05:11PM
And the "fix"? Sysremd's own version of openssh, just like everything else.
(Score: 5, Insightful) by Dr Spin on Friday May 01 2020, @12:02PM (42 children)
Didn't your granny ever tell you "Don't put all your eggs in one basket
Especially if systemd has been within 10 furlongs of of the basket.
Every time I get an update to my Ubuntu system, resolv.conf gets totally fucked. No matter how I remove symlinks, make it immutable, write protected, etc.
Listen Poettering, If I remove your symlink, and mark my resolv.conf as un-writeable by anyone - leave the fuck alone. When the sign says "do not touch" don't bloody touch it, OK?
All my other systems use OpenBSD - and they don't keep getting fucked by unexpected updates. I have had two year uptimes (obviously not on internet connected systems). Unix was fine before you got involved. Go and lock yourself down, and don't come back.
Warning: Opening your mouth may invalidate your brain!
(Score: 1, Funny) by Anonymous Coward on Friday May 01 2020, @12:11PM (38 children)
Linux is open source. If you don't like the way systemd handles your resolv.conf file, then just fork systemd, make the changes you want, review the license agreement with your lawyers, write a Code of Conduct for your fork, and then your problem's fixed.
(Score: 5, Insightful) by SemperOSS on Friday May 01 2020, @12:22PM (8 children)
So, let me get this right, you think that instead of complaining of a completely strange and unnecessary behaviour that does not make sense, people should fork the program and correct it themselves?
That, unfortunately, is not a viable solution for most people … and not a good solution either. The problem with systemd is that Lennart Poettering does not listen to anyone but himself and that he does not care whether what he creates makes sense or not, whether it adds value or not. He wants it and most of the rest of the Linux world has to suffer!
I still wonder how a person with such traits as LP's ever got so much power and why some people thinks he is such a genius?
I don't need a signature to draw attention to myself.
Maybe I should add a sarcasm warning now and again?
(Score: 4, Insightful) by Grishnakh on Friday May 01 2020, @03:13PM (6 children)
So, let me get this right, you think that instead of complaining of a completely strange and unnecessary behaviour that does not make sense, people should fork the program and correct it themselves?
Did you miss the bit about the Code of Conduct?
Honestly, some people are really sarcasm-impaired; this should have been totally obviously from the AC's post.
I still wonder how a person with such traits as LP's ever got so much power and why some people thinks he is such a genius?
This is just human psychology. I've seen it many times. I can't quite explain it myself (if I could reliably predict it, I'd probably be very wealthy), but it seems that people love to latch onto certain outspoken people as "visionaries" or somesuch, and form cult followings around them. I saw this at a former workplace: half the employees seemed to have an almost cult-like following for the department head, and always spoke in glowing terms about him. It was really bizarre. The guy wasn't a bad guy or anything, but he wasn't any "visionary" or genius, he was just a guy in a suit. He wasn't even particularly inspiring when he did speeches at department meetings. I think a lot of it is confidence and putting yourself out there; lots of people like to be followers and look for someone to follow. It's how actual cults get started and go as far as they do, even sometimes to drinking Kool-aid.
(Score: 5, Interesting) by RS3 on Friday May 01 2020, @04:57PM (5 children)
Thank you, you beat me to it. I've been misunderstood when I thought the sarcasm was very obvious, so I now include /s or something for those who don't (understandably) get it.
I don't mind things like systemd, if they're optional. But it really is taking over.
I think the reason Poettering et al are rewarded is what has been my biggest gripe for 30+ years- non-technical people are making technical decisions that they have NO business making. Space Shuttle Challenger is a huge example I often refer to. Engineers said "don't launch, it will blow up", managers said "we're boss, launch". I had hoped the world would learn, yet the problem continues.
Certain people have some kind of sales appeal that the MBA / manager-types like. It involves a certain amount of polished BS. If I was really smart, I'd have either changed careers, or learned the craft. But I'm so ethically opposed to BS that I can't do it.
I've heard, several times, that when you present something to a boss, you have to carefully orchestrate and present the various options to pretty much steer the boss into the correct one. We tech-types are too open with info, and the bosses often just don't get it. Their huge egos make them act like they get it, and they have to be assertive to hold their boss position (and hide their ignorance). The few times I've done it I feel like I've done something dirty and unethical, and that I've played into and perpetuated a very broken system. A great recent example is Boeing 737 MAX killing machine. And from what I'm reading, they STILL don't get it. I wish I could see an answer...
(Score: 2) by Grishnakh on Friday May 01 2020, @06:47PM (3 children)
I think the reason Poettering et al are rewarded is what has been my biggest gripe for 30+ years- non-technical people are making technical decisions that they have NO business making.
I don't follow here. Poettering *is* a technical person. You may not agree with his technical direction, but he's not some dumb manager who doesn't know how to write code, he's the principal programmer for systemd. There are a fair number of technical people who cross over into leadership roles, with differing levels of success.
A great recent example is Boeing 737 MAX killing machine. And from what I'm reading, they STILL don't get it.
True, but even here, the disgraced CEO, Dennis Muilenberg, was himself an engineer before he rose to the executive ranks. The new guy who's trying to hunt down employees who've complained by email, however, is not.
(Score: 2) by RS3 on Friday May 01 2020, @07:57PM (2 children)
Is Poettering RedHat CEO? CFO? Point is, there are layers of management above him that approved systemd becoming integral to RedHat Linux. My complaint: they did not make it optional.
If you don't understand corporate management, the "Dilbert Principal", and others, that's okay.
That Muilenberg became CEO doesn't mean he was ever a good engineer. Perhaps he was and is a good engineer, but had no idea what was going on with MCAS. I fault FAA as much or more BTW. FAA trusted Boeing. Lazy indifference. Proof: 2nd plane killed months later. And there were many many reports of huge problems with 737 MAX (MCAS at work). Broken system.
You can be a good manager and not be technical. But don't overrule your technical staff when they raise a red flag. It's bad for morale. So is the resulting death.
(Score: 0) by Anonymous Coward on Saturday May 02 2020, @02:05AM
The non-technical directors are used only in cases where the corporation has switched from selling a good or service to focusing on playing the stock market and other investments. Take Nokia as an example. They have been getting out of the hardware business since Microsoft's Elop delivered the fatal blow. They have some networking left, but that won't be around another decade with the new non-technical CEO unless they really make a credible move to show they are serious about it. Other companies do the same thing once they get large enough these days.
They bring in a non-technical CEO who brings in lays off the non-technical staff and quickly displace and lay off the technical staff. The appearance of makeing or selling something is kept but just the appearance. Behind that fascade they buy and sell stock, funds or portfolios.
(Score: 2) by janrinok on Saturday May 02 2020, @08:08AM
Yes they did - it is optional, at the user's discretion.
(Score: 1, Insightful) by Anonymous Coward on Friday May 01 2020, @06:59PM
Poettering and friends are arrogant, not incompetent. They understand "fundamental OS design principles" but fail to grok unix or the mysterious text-based world we were initiated into where every command had it's own hidden lore to be passed down through the generations.
I've recently been drawing parallels with this event in the context of a committee from a well known world organization that has repeatedly made the wrong calls. No authority without responsibility, these two immutably linked concepts give rise to accountability. If an engineer or medical doctor makes a wrong call, it's malpractice. Political appointees cannot have authority if they are not responsible and if they are not held to account they had no authority - those who appointed them must be held accountable. The rot is setting in with the "every child gets a prize" mindset that millennials bring to the table, no concept of losing having taken responsibility and failed.
(Score: 2) by meustrus on Friday May 01 2020, @07:50PM
Fully acknowledging GP was being snarky...
If forking the program and correcting it yourself is not viable, then free software is broken. We need to be capable of fixing problems without consulting the Grand Vizier, and sometimes that's only possible with a fork.
Hell, the idea that we have different Linux "distributions" to begin with is only possible because of forking. Maybe systemd breaks the premise of that system.
Or maybe we should give up on the idea of the One True Userspace Compatibility and truly fork the OS.
I say this fully knowing that I still haven't tried BSD, that I'm becoming more invested in Linux because of Docker. But at least as long as I do stuff in Docker, I don't have to worry about system initialization anyway. Software is so much easier on commodity servers.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 5, Insightful) by epitaxial on Friday May 01 2020, @12:55PM (1 child)
I'd like to know why a program meant for sequencing how items load during startup is concerned with DNS resolution?
(Score: 2) by RS3 on Friday May 01 2020, @11:54PM
Ever see the movie "The Blob"?
(Score: 2, Troll) by janrinok on Friday May 01 2020, @01:45PM (23 children)
Even easier, is just use a different distro. But for those of us who actually find systemd solves some problems then I will keep on using it. It hasn't been a major change in how I have to use my computer, but it is more powerful than its predecessors IMHO. Of course, you may disagree, but that is nothing worth arguing about. I'll bet we've decorated our homes differently too.
(Score: 4, Touché) by Arik on Friday May 01 2020, @01:49PM (8 children)
That's not a good thing. Think about it.
What if your local dog-catcher had nuclear weapons?
You would definitely have a more powerful dog-catcher. But what good would that be?
If laughter is the best medicine, who are the best doctors?
(Score: 3, Insightful) by janrinok on Friday May 01 2020, @02:05PM (6 children)
What a ridiculous argument.
Imagine a temporary problem with my network. Several parts of the system might stop working because they have lost connectivity. systemd knows which programs rely on the network and, when the temporary problem is resolved, it automatically restarts all the programs that need to be restarted. That is powerful and useful - but doesn't involve dog catchers or nuclear weapons.
I'm not Dr Spin - I don't care whether you use systemd or not, but it is doing everything that I ask of it, and more than previous init systems did for me.
(Score: 5, Insightful) by Arik on Friday May 01 2020, @02:25PM (4 children)
It's not a ridiculous argument at all. Making programs more powerful doesn't always or even often make them better programs. If take my init system and give it power over the entire system I don't get a better init, I just make the consequences of a bug in the init system much more severe.
"Imagine a temporary problem with my network."
OK.
"Several parts of the system might stop working because they have lost connectivity."
What? Why? That shouldn't be happening. Which parts specifically?
"systemd knows which programs rely on the network and, when the temporary problem is resolved, it automatically restarts all the programs that need to be restarted."
Well that sounds like slapping a bandaid on a gunshot wound. It would be better to fix the parts of your system that are faulty. Bandaids like automatically restarting a program can be applied with different tools.
"it is doing everything that I ask of it"
Perhaps you should think about what you are asking of it, and why.
What I ask of an init system is to reliably start (init, get it?) my system, no less and no more.
Once I have a shell prompt it needs to unload and get out of the way. If I need something restarted, that's the job of another program, not the init system.
If laughter is the best medicine, who are the best doctors?
(Score: 1, Troll) by janrinok on Friday May 01 2020, @03:10PM (3 children)
I was with you until here - then you lost it.
You admit by implication that there is a need to automatically restart programs because there are different tools for doing that job. So your objection is that they are perfectly acceptable but systemd isn't. Systemd wasn't written for the home user - it was initially targetted at instances running in the cloud. Have you tried manually restarting several thousand instances when necessary? No, I thought not. There it is very useful indeed. However, it can be equally useful on much small networks or even individual systems. You don't have to use any of it, if you don't wish. But many distros are looking at supporting more than just the home user or indeed larger networks. So they adopted a standard way of doing the things that their customers wanted to be done. And one of those things was to enable systems to keep themselves going when there are faults.
I have no problem with those that don't want to use it - but the people on here complaining about it are mostly those who DO NOT use it. They tell us about how this distro or that distro is still free of systemd and therefore 'much better'. That's fine, but why argue about something that you do not use? Lots of us just get on with it. It works, I have no problems with it, it does what it says on the tin, and I have no need of paid support from Red Hat or anyone else. Why shouldn't I be able to use it if it does exactly what I want. And this feature - to me - is useful. I won't tell you what to install on your computers.
Shall we argue about emacs/vi next or Python/Rust/Go?
(Score: 5, Insightful) by Arik on Friday May 01 2020, @03:59PM
Sure, in practice it's sometimes good to have a bandaid available. That doesn't mean we need to re-organize our entire lives around a full body suit that applies bandaids automatically.
"So your objection is that they are perfectly acceptable but systemd isn't."
My objection is that this is not how you build good tools. Systemd is an attempt to replace the entire toolbox with one robot.
I can see how this idea can have some attraction - working with tools requires effort, and thought, and occasionally you skin a knuckle. It's so much easier just to turn the robot on and let it do all the work.
But then we're left with no good tools, and completely dependent on the robot and its owner (hint, that is not you or I.)
"it was initially targetted at instances running in the cloud."
You mean in VMs right? "The cloud" is meaningless marketdroid speak.
Look it might be very useful there. But if you want that functionality, implement it within the design of the system, or fork your own distro just for VMs and include shims so that you don't break things.
"That's fine, but why argue about something that you do not use?"
Because it's a well-funded commercial project that's not only openly aiming to destroy the free software infrastructure needed to support my continued ability to operate without them, but is already pretty far down that road.
Yes, we still have other choices. And we'd like for that to continue to be the case. Operating systems do require maintenance. The more free software developers that get hornswoggled into using systemd, the more quickly that choice will disappear.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Friday May 01 2020, @10:21PM (1 child)
{ for ip in $(cat ips.txt); do ssh -n "$ip" "whatever command" & done } >output.log 2>error.log
Works pretty well for me when I need to do stuff on ~2400 VMs simultaneously. Which was pretty darn regular until last week when that project finished.
(Score: 0) by Anonymous Coward on Saturday May 02 2020, @05:56AM
We do what one of my coworkers calls "FCUs" or ForceCommand Users. Just the act of authenticating with ssh with the right credentials triggers certain actions. Proper auditing and access control makes that stuff simple and a lot easier to find bad actions.
(Score: 2) by Bot on Friday May 01 2020, @08:31PM
> Several parts of the system might stop working because they have lost connectivity. systemd knows which programs rely on the network and, when the temporary problem is resolved, it automatically restarts all the programs that need to be restarted.
This is breaking the principle of locality and modularity in software. Not to mention it needs more synchronization among devs of a probably different project and you have to learn and deal with potential issues in the DSL that tells systemd which programs need to be restarted under which conditions, which might not be the same for everyone... how much outage is tolerated? how many data hanging around or lost?
What about this, a program dealing with networking is robust and deals with connectivity issues. Or if it's a simple tool, in the unix tradition, loudly fails with a proper error code.
The rest is an issue of the sysadmin, who either sets up the program to restart or catches the exception, with runit or equivalent or shell script, or prefers the error to propagate or to trigger error handling elsewhere (a network health monitor, for example). In any simple scenario the DSL is overly complex, in any complex scenario a turing complete script with all the arsenal of userland is more suited for the task.
Account abandoned.
(Score: 0) by Anonymous Coward on Friday May 01 2020, @05:23PM
The dog catcher also moonlights as a pimp for the local LEA decoys. The more weaponry, the better.
(Score: 3, Insightful) by RS3 on Friday May 01 2020, @05:10PM (10 children)
This is an amazing discussion and I'm learning and greatly respect everyone's input.
No interest in quarreling, just want to point out: I wish to move away from RedHat / CentOS / systemd, but the few distros that are NOT systemd-based have weak package management systems (imho). (I'm a SlackWare guy from the start, so I might finally go SlackWare on production systems...)
I wish systemd was more of an option.
And I think that might be the core of most people's unhappiness- lack of option, which is kind of what the whole Linux / open source world was about... to me anyway...
That and systemd brings some pretty big changes, again, crammed down our throats. I might be very okay with it if I install it on a non-production box- sysadmin's dev box, and "play" with it, learn it, etc., for whatever time it takes. But I don't want to be forced into using something so pervasive. Make any sense?
(Score: 3, Informative) by janrinok on Friday May 01 2020, @06:06PM (3 children)
The thing that people are forgetting is that whether you use systemd.homed is OPTIONAL. It is not, and should not be, enforced because it does break SSH and many users might prefer that over a homed directory. Unfortunately it currently defaults to 'homed' being selected and not the preferred alternative of being unselected but there is already a bug report [github.com] in to change this behaviour.
Systemd.homed is not yet ready for release and it is not surprising that there are bug reports extant.
Now it is also true that Lennart has a habit of not listening to people - but the distros have insisted on the ability to disable homed being included.
(Score: 4, Insightful) by Anonymous Coward on Friday May 01 2020, @07:11PM
It may be currently optional, but systemd was optional at first, too. We know it won't remain that way.
(Score: 0) by Anonymous Coward on Friday May 01 2020, @09:56PM
Optional...
Until it's required to log into your system.
Optional...
Until every Linux tool that has anything to do with /home or passwords, or logins needs to be systemd aware and won't operate without systemd.homed running.
This will be no more optional than the dozens of applications that all ready require systemd prerequisites, for no real reason.
(Score: 2) by Bot on Friday May 01 2020, @10:04PM
Everything is optional under linux, what you want to know is: is it DEFAULT?
Because once the luser has installed his flashy distro, he is stuck with his default LUKS image, and you sysadmin/helpful hacker are going to deal with it.
Account abandoned.
(Score: 1) by DECbot on Friday May 01 2020, @07:47PM (2 children)
If you want package management, for now Debian is still kinda supporting systemd-shim, which lets you choose your own init adventure. If you want more commitment on systemd alternatives, but like Debian's package management, then give Devuan a go. Jesse and Ascii are both SysV and I believe they are looking at OpenRC for Beowulf or whatever comes after Beowulf.
I agree with you. If systemd was just an init change, I probably wouldn't have had second thoughts about it. However it is not just an init change, it is also a networking change, a DNS change, a logging change, a login change, and more. Granted, some distros have opt-ed out of these changes and a few of these changes you can revert--but they are mostly opt-out on default. I prefer an opt-in by default manner where I can evaluate the changes one by one and adopt them when I am ready to try something new on a system I know is stable or designed for testing. Between the NIH-forceful changes to the OS, the arrogant support of the developers (not-a-bug bug), and the political nature of how it ended up as a default on other distros, I'm not inclined to view it positively.
cats~$ sudo chown -R us /home/base
(Score: 2) by RS3 on Friday May 01 2020, @08:09PM (1 child)
Yes, and thank you so much for the suggestions! I will try Devuan. I like the large selection of Debian packages available, and that most 3rd party software is available in .rpm or .deb.
I really want to use Alpine Linux- it's awesome, but I have very little confidence in the package manager. There's barely any interaction. You can add or del packages, but you barely know what's going on under the hood.
My fear of systemd is: 1) it's been growing, spreading tentacles further and further, and as I keep commenting: 2) it's not an option with RedHat, and that's a big disappointment for me because RedHat is so strong in the market.
And it may be Devuan, but there are some distros that want to install systemd by default, but you can choose to not install it, and choose sysvinit, openrc, whatever else.
Again, I've been a SlackWare guy from, well, very long ago. Problem is- I have a rock-solid 14.1 system. Tried to install, from scratch, 14.2, and many things don't work correctly, or at all. Spent too many hours trying to fix stupid things and gave up. Too many hours spent, too many other more productive things to do right now. Keeping 14.1 system for now. :)
Thanks again!
(Score: 0) by Anonymous Coward on Saturday May 02 2020, @03:13AM
Guess why RedHat (now IBM division) is so happy to push systemd, gnome and all other "new & shiny, we have to do it because the others are old" things. To reinforce their position. More vendor lock-in, more strength, more market share, wihtout pause.
They are not interested in playing nice and being compatible. The only compatibility they understand is the one they "set". That they go with GPL is just a left over, and as long as they control the organizations, it will mater zilch if GPL style licenses, MIT style or closed source. But in spirit they are very far from GPL.
Or as repeated many other times in this and other stories: Linux is not done until everyone is in RH support contracts.
(Score: 3, Informative) by Azuma Hazuki on Saturday May 02 2020, @12:16AM (2 children)
In my experience, Void and Arch do *not* have "weak packaging systems." Pacman is the best package manager I've ever used, ever, and Void's xbps suite is a close second only because it's a tad more verbose and clunky. Feels oddly like a *BSD package manager, actually, since it has xbps-src tools too.
Slackware doesn't (by default) have a package manager, so things like slapt-get are naturally going to be a little wonky.
And Gentoo, well, we know Gentoo. I have a 32GiB kit of DDR4-2400 coming this week because apparently 8 is *not* enough for modern Gentoo @_@
I am "that girl" your mother warned you about...
(Score: 2) by RS3 on Saturday May 02 2020, @01:17AM (1 child)
Thanks for the tips!
It's been quite a few years since I've tried Void or Arch. Arch of course uses systemd, and I'm not ready to switch production servers to systemd. Never know what the future holds of course.
IIRC there's an Arch-based distro with systemd removed, but some reports of problems with packages that depend on systemd.(?)
I'm well anchored in Slackware and have no problem running it live, but if something happens to me, or I bail, I'd hate to leave a system that many admins would struggle with, and curse me for. And it kind of has package management, "pkgtool", "upgradepkg", and a few others, but not dependency management if that's what you mean. IIRC it did way way back.
While I'm on it, I used to add "&" to the end of many of the startup script command lines and kind of got my own parallel startups happening. Had to be aware of dependencies, but that wasn't too difficult for many things.
I'm slightly embarrassed to admit I've never done Gentoo. Need a distcc farm?
(Score: 2) by Arik on Saturday May 02 2020, @03:06PM
If laughter is the best medicine, who are the best doctors?
(Score: 2) by Dr Spin on Friday May 01 2020, @07:38PM
I should have thought it was perfectly obvious from my post that where I have the choice, I would not use the bloody shit-heap in the first place.
Not everyone gets a choice of what OS is on computers they have to use (I might go as far as threats of physical violence for anyone who tries
to get me to use Windows).
However good OpenBSD is for me, not least because I have been a Unix user since 1978, it is not ideal for everybody. Indeed, it is my contention is that
some like Gnome, some like KDE, and some don't. As someone else has already said "there is nothing inherently wrong with systemd existing*. There is
a lot wrong with anyone who thinks that kind of stuff should be rammed down anyone's unwilling throat (except perhaps on Pronhub)". It is choice that is
good, and not ramming things down people's throats.
(I have several other perfectly good rants in the waiting, but I shall wait til the brandy wears off).
* Although it would obviously be better it it existed in an alternate universe, and not the one I am in.
Warning: Opening your mouth may invalidate your brain!
(Score: 3, Insightful) by janrinok on Saturday May 02 2020, @07:02AM
You can disagree all you like - but this is not SPAM.
(Score: 2) by Thexalon on Saturday May 02 2020, @01:54PM
What do you mean by "powerful"?
If you mean "does more things", then that's only a good thing if the things it does are the things I want it to do.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Friday May 01 2020, @02:32PM (2 children)
You forgot the "Vision Statement" and the "Mission Statement".
(Score: 4, Funny) by DannyB on Friday May 01 2020, @02:51PM (1 child)
First thing is first: design the icons and t-shirt.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Saturday May 02 2020, @06:01AM
Boss: Is the minimum viable product ready yet?
Programmer: Not even close.
Sales: But we have one million stickers ordered.
Boss: Ship it now! We can't let the stickers go to waste!
(Score: 2) by Arik on Friday May 01 2020, @12:22PM
At most it should take one such incident to convince you to move to a distro that doesn't suck.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Friday May 01 2020, @07:02PM
even if something was being broken (i doubt it) you don't have to use systemd-resolvd to use systemd-networkd. you don't have to use systemd-networkd either...
(Score: 1, Informative) by Anonymous Coward on Friday May 01 2020, @08:47PM
systemctl disable NetworkManager
systemctl mask NetworkManager
systemctl enable network
Will stop that shit from happening.
(Score: 5, Insightful) by Farkus888 on Friday May 01 2020, @12:03PM (13 children)
We all know that Bach is good. But here in the real world nearly everyone listens to top 40 anyway. We want to eat healthy, but choose fast food. In the same way, Poettering likes the idea of Linux but hates everything about it. So many people seem to feel the same way. Thanks to all those people, I have to essentially learn a new OS as a 20 year Linux user. My newest joy was discovering that Debian doesn't include ifconfig anymore. Like the actual luddites, I'm not opposed to change in itself. I think that change should be considered and only adopted if it is the best way to add the alleged value. What does ip give me that couldn't be solved with a new flag in ifconfig?
(Score: 4, Informative) by Anonymous Coward on Friday May 01 2020, @12:08PM
>> What does ip give me that couldn't be solved with a new flag in ifconfig?
The ability to confuse you so much that you have to buy Red Hat support services, which is the raison d'etre for Poettering's existence.
(Score: 2) by Arik on Friday May 01 2020, @12:18PM
No, you don't. http://www.slackware.com/
Debian was once a respectable distro, but it's been enemy territory for years now.
If laughter is the best medicine, who are the best doctors?
(Score: 3, Funny) by Bot on Friday May 01 2020, @12:35PM (9 children)
Bach is not good. Bach is mathematically careful removal of tension in fugues. If you want to know what harmonic tension is ask Chopin. Even pop groups like Alphaville (in Big in Japan and in the lower quality forever young) and countless other which wrote fugues were able to put more tension in it than Bach's.
Yes Bach is admirable. But in its lifeless modernity. If even a bot noticed...
Account abandoned.
(Score: 2) by hendrikboom on Friday May 01 2020, @02:15PM (4 children)
Where can I read more about the mathematics of harmonic tension in general? Whether Bach's or Chopin's style?
(Score: 2) by Bot on Friday May 01 2020, @09:45PM
Start by googling harmonic tension :)
Well I'd go for getting the basics of harmony from a music theory point of view. I guess there is enough material online. Bach IIRC did perform a math analysis when writing music, I dunno how much of it he divulged. Then I'd read up sound engineering stuff and acoustics as a branch of physics, which tie up listening with math.
Anyway, the hearing apparatus is DSP. The decoding provides you survival tips. Spectral decoding on hi freqs, time pattern analysis on low freqs aka high periods, melody somehow in the middle. Some decoding is easy (the octave, a wave inside the other), some is challenging (dissonance, chaos). Easy doesn't provide satisfaction, Challenging does, but one challenge after another becomes tiring. Also, the brain detecting continuous imbalance bothers you, so, the various cultures have come up with stuff that stimulates the brain without too much tiring and imbalance.
You might want to analyze the math behind it, but satisfying music is like satisfying jokes or stories or paintings. There is a lot of experts and analyzers of music, literature, art, they all suck at producing. The discovery of the elusive joke, or melody, of harmonic sequence, is a matter of sitting down and trying. Math can help you try, but maybe you would come out with something equally interesting by mere experimenting. You need knowledge, sure, not to reinvent wheels. Culture FILTERS the intuition.
Plus you have to find your public and your fellow artists (you listen other than produce). Consider that many people now are drones with no developed sense of taste. Even the guys at the theater who boo the tenor who got a flat note. A stupid analyzer can tell he got a flat note, so what? You are not hearing music, you are bothered with the execution, a hobby that does not involve taste. Consider that as a musician you might concentrate on melody and harmony, while a dancer might concentrate more on timbre and dynamics and a rocker on how you are perceived in his (approved by the real powers) rebellious quest.
So it's more of finding your niches. If you git good, the mainstream might notice, but I consider that a misfortune. You risk eventual catastrophe with your first signature on a contract.
Account abandoned.
(Score: 3, Interesting) by Thexalon on Saturday May 02 2020, @02:22PM (2 children)
There's a long history of the math of harmonic tension dating all the way back to the Pythagoreans. One classic in the field is The Craft of Musical Composition by Paul Hindemith, which rates the various components of harmony using the mathematics around frequency ratios. There are also useful explorations by musicologists like Curt Sachs, who studied a lot of musical styles other than the 12-note one you're probably most familiar with, such as gamelan and the Indian classical traditions (Carnatic and Hindustani).
The basic idea is that music is generally calm when the frequency ratios between the notes in the harmony are relatively simple: 1/1 (unison), 2/1 (octave), 3/2 (perfect 5th, e.g. C and G), 5/4 (major third, e.g. C and E). And by contrast, tense moments create some really complex frequency ratios. That's not quite 100% true, because the math of scales requires that the ratios aren't quite followed, but it's close enough that that's what people tend to hear.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by hendrikboom on Saturday May 02 2020, @06:51PM
I know about simple frequency relationships in two=note combinations.
But I found this: Explaining the Sonority and Affective Valence of Chords: The psychophysics of 3-tone combinations [researchgate.net] about tension in three-note chords.
Unfortunately they don't specify precisely how they do the calculations involving overtones.
-- hendrik
(Score: 2) by hendrikboom on Sunday May 03 2020, @03:24AM
I was just blown away when I first heard ragas.
-- hendrik
(Score: 2) by Thexalon on Saturday May 02 2020, @02:11PM (3 children)
Apparently you haven't listened to or studied much Bach. Because his music is exactly the opposite of the removal of tension, and even today there are tons of moments that cause even the most experienced music listeners out there, especially the first time they hear it, to say "WTF was that, and why does it work?" As an example, one of the more famous pieces out there, the first prelude of the first book of the Well-Tempered Clavier, has the harmony Ab-F-B-C-D - try it out for yourself and tell me what you think it means.
If you're wondering why the mood of a Bach piece doesn't change much in the middle of it, it's because the style of his day was to do the equivalent of holding up something in good light and examine it from every direction to see all of its beauty and properties. It was Beethoven and the people who followed him that switched to "music should take you on an emotional journey somewhere".
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by Bot on Saturday May 02 2020, @10:29PM (2 children)
WTF moments, you can have one when you hear gershwin's two chords in summertime but they have more tension than bach's. Bach is likely to get stuck in the head because of some solutions that I agree are very interesting, but tension is still low. As you said, something that you admire from angles, nothing that captures you and takes you somewhere.
Account abandoned.
(Score: 2) by Thexalon on Sunday May 03 2020, @03:51PM (1 child)
You're seriously going to trot out George Gershwin as a radical harmonist? He wasn't, not even close. Basically, his ideas came right out of the newly forming jazz and blues tradition, were about 5-10 years behind the likes of W.C. Handy, which he combined with enough European classical stylings to not make white people too scared of it.
Also consider who his contemporaries were: Mahler, Schoenberg, Stravinsky, Ravel, and you want to tell me that some blue notes makes him radically modern or tense? Those guys apparently liked Gershwin's works, but they are comparatively extremely tame.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by Bot on Monday May 04 2020, @10:51PM
Since you are arguing about stuff you yourself imply, I'll simply reiterate: Gershwin, which I picked up because 1. "I did not think of that" and 2. still a better tension story than bach, has more tension than bach. Whether he was behind a handy WC is irrelevant to both points.
Account abandoned.
(Score: 4, Informative) by epitaxial on Friday May 01 2020, @01:00PM
How about removing traceroute? I was having an issue getting routing setup on a Debian box so no downloading from repos. Some time ago they replaced traceroute with tracepath for reasons? I wasn't aware of such nonsense and that made fixing the routing issues fun. Also they replaced the actual route command for some reason and the new one has different syntax? I'd love to hear that excuse.
(Score: 5, Insightful) by Anonymous Coward on Friday May 01 2020, @12:13PM (6 children)
I would have much more respect for Red Hat and Lennart, if they would come clean and at least admit what they're really doing -- developing a totally different operating system. This is what systemd is. Hence the comment title: systemd/linux. Sure its a variant on UNIX and gnu/linux, and runs much of the same software, but it is a different OS. Plus, I believe what I have read others say: systemd is a take-over attempt on the free software world. Red Hat wants to be the Microsoft of Linux.
This is not a good development in my book.
(Score: 0) by Anonymous Coward on Friday May 01 2020, @12:45PM (1 child)
Linext/Leannext
(Score: 0) by Anonymous Coward on Friday May 01 2020, @02:36PM
Linexit/Leannexit
fthfy
(Score: 0) by Anonymous Coward on Friday May 01 2020, @02:48PM (1 child)
I also wish he would put his hands into the X world. People dislike that API and interaction so much, and this guy _loves_ crappifying everything more, no doubt he has a grand vision for that.
Also, with breaking X compatibility, then he'll have broken the _complete_ stack and there's nothing left but systemd/linux. That'll be a complete fork. Hopefully it happens sooner rather than later, so that we can all get back to something that isn't broken.
(Score: 0) by Anonymous Coward on Friday May 01 2020, @08:53PM
Can you say Wayland [freedesktop.org]?
(Score: 5, Informative) by rleigh on Friday May 01 2020, @07:34PM (1 child)
Well said. I think that what Lennart and his pals are doing is something that many of us have wanted to do. We've noticed that the way things are done can be improved, and that the existing way has numerous deficiencies.
Where we differ is that (when I was maintaining Debian sysvinit and related low-level boot stuff), I saw the possibilities but I also took into account the widespread breakage which would result, and decided to leave things alone. Which is not to say no improvements were made, but that they were always made with both sets of tradeoffs carefully considered. I introduced /run, for example following the systemd lead but being painless upgrade on working systems. Breaking an existing workflow was an absolute no-no. The contrast is that Lennart has cheerfully broken the entire system in multiple ways, and then told all us developers and end users to suck it up. That's where we differ. I would never have countenanced behaving that way.
I always saw software maintenance as being mindful of the legacy and being diligent in preserving compatibility. When hundreds of thousands of companies and individuals have entrusted you with keeping their businesses running and enabling their work and leisure activities, I always considered it a responsibility of some importance, and took great care not to break that trust, with small and focussed changes backed by extensive testing. systemd drove a bulldozer through it all. The breakage in Debian was unreal. Yes, the system wasn't perfect, but it had over 25 years of accumulated experienced encoded in it to support a truly vast set of use cases, and hardware variants. With systemd, if Lennart doesn't think your use case is important, then screw you! You're doing it his way! I see the fallout of this as an act of utter vandalism. After sinking so much of my life into Debian, I don't feel too ashamed to admit that I spent several years afterward with what I suspect was depression. I couldn't even face working on free software for several years afterward. Some bits, I still can't face. My motivation has been completely erased.
What really surprises me is the seeming lack of oversight within RedHat itself. Though maybe after we saw how the RPM maintainer used to behave, it shouldn't be surprising.
(Score: 4, Interesting) by Thexalon on Saturday May 02 2020, @02:55PM
The thing I've also noticed about Lennart's approach is that it seems to have carefully ignored everything about *why* the old way of doing things was the old way of doing things.
A key design decision systemd made very early on that has colored everything it has done since is "text-based communication between processes is bad". And this is the exact opposite of what Thompson, Ritchie, Kernighan, et al were trying to do when they built Unix, namely to avoid giant blobs of code where you can't easily examine or modify how the various parts talk to each other. And there was a very good reason for that: Those guys had experienced lots of quite complex operating systems with giant blobs of code where they couldn't easily examine or modify how the various parts talk to each other, and found them to be inflexible and hard to work with. This decision is precisely what leads to monstrosities like binary logs that can only be read if you have the right tools on hand and were written to disk without errors (even as the system might be in the process of crashing).
A key assumption that went into the design of Unix was "anything can break in ways we didn't anticipate, so let's make sure an admin can cope and fix it". A key assumption that went into the design of systemd was "anything that breaks breaks in a way that Lennart anticipated", and that assumption is so key that when things have broken in ways Lennart didn't anticipate his response has frequently amounted to "WONTFIX - theoretically impossible, so the bug report must be wrong". As an example of this being a problem, the experience that will always color my opinion of systemd was the day I rendered my system unbootable by cold-unplugging my mouse, because apparently Lennart hadn't anticipated that somebody might do that, and rather than start up without mouse support or drop me to a single-user shell or even spit out an error message systemd instead decided to show me a black black screen with a non-responsive keyboard.
And the thing is, I've worked with people like Lennart before, folks who were completely certain that their way of doing things was the One True Way and everyone else didn't understand their vision and skill and if those nattering nabobs of negativism would just let them code the results would be great all around. And every single one of them produced code that didn't actually work very well and was a nightmare to fix.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 1, Informative) by Anonymous Coward on Friday May 01 2020, @12:16PM
No, they will not.