Whether or not you like Lennart Poettering, you have to recognize that this is a major undertaking and addresses some real issues. Slides: https://cfp.all-systems-go.io/media/homed-asg2019.pdf
Whether or not you like Lennart Poettering, you have to recognize that this is a major undertaking and addresses some real issues.
I don't see any real issues in those slides, though. ProblemsNeedswritable/etc+MixesStateandCon gurationUIDassignmentsneedtob epropagatedb etweensystemsNoencryption(Or\mismatching"encryption)Nomo...
I don't see any real issues in those slides, though.
All of those are either well addressed in a modular fashion, or a made up problem (ie, no resource management, it's almost like Lennart doesn't know about ulimits. Writeable /etc, which it really doesn't. not extensible well, it really is.)
So much breakage for nothing. Hopefully the distros won't force this on us, or I'm going back to FreeBSD or maybe GuixSD. Many questions and problems with this for me; SSH logins are vital, can't...
So much breakage for nothing. Hopefully the distros won't force this on us, or I'm going back to FreeBSD or maybe GuixSD. Many questions and problems with this for me;
SSH logins are vital, can't give them up. Home encryption is already there.
It's better to encrypt actual sensitive files with GPG rather than the entire disk or the entire home directory.
My files may (and do, in my use case) outside of my home directory.
Most personal computers are indeed single user, why fight against that?
If memory can't be encrypted, this whole thing is futile, so why bother?
This will create tonnes of compatibility issues that are essentially unnecessary.
Who the heck is this guy to decide on everything that goes into our OSes?
How will we prevent that major distributions just force this on all users like they do with systems?
I really dislike the power this guy and systems in general has over or tech lives. There are problems, but this whole thing is bullshit. The worst solution possible.
I don't think that's planned. Where did you see that? For you, yes, but not for most users. I'd welcome no-hassle, on-by-default encryption. Why? If you're thinking performance, encryption has a...
SSH logins are vital, can't give them up
I don't think that's planned. Where did you see that?
Home encryption is already there.
For you, yes, but not for most users. I'd welcome no-hassle, on-by-default encryption.
It's better to encrypt actual sensitive files with GPG rather than the entire disk or the entire home directory.
Why? If you're thinking performance, encryption has a very, very low footprint thanks (I think) to hardware support.
Most personal computers are indeed single user, why fight against that?
Why indeed? I didn't see Lennart trying to fight against it.
If memory can't be encrypted, this whole thing is futile, so why bother?
Recovering RAM is a lot harder than recovering data from a hard drive/SSD. Preventing everyday data theft is not futile.
This will create tonnes of compatibility issues that are essentially unnecessary.
That remains to be seen, but I agree Lennart's track record on that respect is not absolutely stellar.
Who the heck is this guy to decide on everything that goes into our OSes?
Lennart Poettering is a top engineer at Red Hat, who is by far the top contributor to Desktop Linux. If you don't want to use Red Hat products, that's fine, but you will find out that a big chunk of the software you use daily originates from them. So I think it's only fair that they have control on the software they develop. Others have tried to do without them, but they usually don't get very far due to lack of resources. Also, they tend to make good software, which is why people like to use it. The Pulseaudio and SystemD controversies have pretty much died down.
I feel that's similar to saying "Who the heck is [Linus Torvalds] to decide on everything that goes into our kernel?". In that it's both a wild exaggeration, and also an unjustified call-out....
Who the heck is this guy to decide on everything that goes into our OSes?
I feel that's similar to saying "Who the heck is [Linus Torvalds] to decide on everything that goes into our kernel?".
In that it's both a wild exaggeration, and also an unjustified call-out. Poettering has built up a bad reputation because his software is so direly needed, many distros have rushed to adopt it, often too early (First with Pulseaudio, then with systemd). This draws ire from users who have to adapt to the changes. But he is an exceptional developer, and much less of an asshole than other people who are praised for their "no bullshit" attitude.
How will we prevent that major distributions just force this on all users like they do with systems?
You can go ahead and make your own distro if you so wish. Or join one of the couple that are led by similarly-cranky people. I'll give you the low down on that: It won't work out. Poettering has a knack for getting his stuff shipped in distros because he solves problems. He's not writing "yet another tool to do X which is done by 20 other solutions", he's writing "this is how we solve X, the proper way", and doing so with financial backing, which allows throwing real resources at it.
I wish the Linux community would shut the fuck up about this guy because this approach is the only one that has even a hope of continuing to compete with modern operating systems. Linux has failed to keep up with how users deal with personal computers nowadays. We can catch up, but it takes work; homed is one of the components needed to catch up.
I'll address this as an aside:
It's better to encrypt actual sensitive files with GPG rather than the entire disk or the entire home directory.
It is not. Full-disk encryption is common on desktops, laptops and even more so on mobile devices (Android and iOS). I don't think you gave a moment's thought at a regular user actually bothering to encrypt/decrypt their sensitive files one at a time; if they even are able to determine what actually is sensitive, that is.
The big problem that I have with many of Poettering's projects is that he is able to do what he does because the people that came before him made simple text / file based tooling. Some of it not...
I wish the Linux community would shut the fuck up about this guy because this approach is the only one that has even a hope of continuing to compete with modern operating systems.
The big problem that I have with many of Poettering's projects is that he is able to do what he does because the people that came before him made simple text / file based tooling. Some of it not great, but in any case, it is easy to extend most of linux because it's often just a few files and maybe some shell scripts or whatever. His projects on the other hand basically pull up the ladder behind them by creating sprawling interfaces that stick their fingers in everywhere. I have a problem with this because it will make it very hard for us to ever escape this local minima if something better rolls along. His works complete disdain for modularity is maddening.
One of the things I find massively frustrating is that my time and talents are wrapped up solving other problems. I'm super jealous of his 40 hours a week that he gets to spend creating software that I often have to actively avoid. I shit you not, I am actively trying to achieve financial independence s.t. I throw my hat in the ring on this stuff because I have completely lost faith in the Poettering-led vision for the end state of linux userspace.
I guess I should also add that I don't care much for
compet[ing] with modern operating systems
whatever that is supposed to mean. I want to be able to enjoy my computer without it puking all over me. I lost many hours to systemd (oh your user service failed to start in 30 seconds, I guess I'll log you out of your session, and other such nonsense). And it's not the man, it's the code. PulseAudio has definitively made things better. Systemd is a mess. If he can find someway to design something s.t. that any other project has a cat in hells chance of using it without dragging in the entire jungle I'll be pleased to see it, but I won't hold my breath.
Lastly:
Or join one of the couple that are led by similarly-cranky people.
It's a real dick move to suggest that everyone that is dissatisfied with systemd is a crank. There are plenty of reasons to not want to use it, and you undermine everything else you say by mixing in such commentary.
We all stand on the shoulders of giants. I get what you're saying (and I agree to an extent with his distain for modularity, even though it's not completely true). If you're serious about this,...
The big problem that I have with many of Poettering's projects is that he is able to do what he does because the people that came before him made simple text / file based tooling.
We all stand on the shoulders of giants. I get what you're saying (and I agree to an extent with his distain for modularity, even though it's not completely true).
I shit you not, I am actively trying to achieve financial independence s.t. I throw my hat in the ring on this stuff
If you're serious about this, I'm happy to try to help guide you through finding a job in the linux desktop space. Red Hat is the obvious one but working at KDE is also a very good bet if you want to work to improve these things. Canonical often has open jobs as well and they do some good work. There's many ways to be paid to contribute.
I want to be able to enjoy my computer without it puking all over me.
I can't help with your systemd issues… you may have various things misconfigured. Most people have it working fine; those that don't generally messed with the configuration without really understanding it. The portion that's left hitting real bugs, those generally get fixed if they're reported. You can see where I'm going with this. What you're describing (logout on user service failure to start) definitely sounds like a misconfiguration; a service dependant on another which fails to start, thus the other one gets killed. The feature would work as intended, what you put into it doesn't.
It's a real dick move to suggest that everyone that is dissatisfied with systemd is a crank.
Heavens no. I'm just talking about the knee-jerk distros that were spawned by it. And it's absolutely fair to say those people are cranks, if you've had to deal with them.
I also feel that "cranky" is the least offensive way to describe a post ending in "this whole thing is bullshit. The worst solution possible."…
That's super cool of you, but I'll pass. I intend to "retire" early by paying off my house in the next couple of years through a mix of contracting gigs and investments, and then go full time OSS....
If you're serious about this, I'm happy to try to help guide you through finding a job in the linux desktop space. Red Hat is the obvious one but working at KDE is also a very good bet if you want to work to improve these things. Canonical often has open jobs as well and they do some good work. There's many ways to be paid to contribute.
That's super cool of you, but I'll pass. I intend to "retire" early by paying off my house in the next couple of years through a mix of contracting gigs and investments, and then go full time OSS. I don't yet know which projects I'd like to contribute to.
I can't help with your systemd issues…
That's the thing, I'm not asking for help. I solve my own problems. Eventually I solved them completely by ditching systemd entirely where possible, and limiting usage of it's features where I can't (I run a lot of rhel / centos boxes).
The feature would work as intended, what you put into it doesn't.
This is I guess where I completely disagree with the kinds of UX choices systemd makes. Lets be concrete: this particular issue was a fun confluence of things: I had a working socket activated user service of gnupg. Arch at some point decided they would also provide that service. Conflict! Fine. Whatever. What I take issue with is how this manifested: I'd login, then 30 seconds later I'd get logged out. What. The. Fuck. After scrabbling around for 10 minutes I put on my thinking cap, logged in via a tty, worked my way through journalctl and figured it out. What would have been much easier is if systemd had just let the service fail and left me to notice my gnupg setup was broken when I went to use it, and I'd have had the luxury of my whole DE to investigate it. This and other papercuts too mundane to remember eventually got me off arch on my personal boxes.
I know you can't randomly know the skills and abilities of random people on the internet but I've written hundreds of systemd unit files and know many of the man pages off heart. Systemd has weird failure modes and fails in more cryptic ways than just about any other supervision suite. I will freely admit I push more edges many people would (I am a distributed systems engineer with a strong SRE / ops bent). I'd take runit or s6 any day of the week.
I don't think that's a completely fair read of people's issues with Poettering, systemd, and the like. Part of it is the attitude. If systemd or its developers breaks something, it is...
This draws ire from users who have to adapt to the changes.
I don't think that's a completely fair read of people's issues with Poettering, systemd, and the like.
Part of it is the attitude. If systemd or its developers breaks something, it is automatically your fault. Systemd can do no wrong.
And I don't mean that in the sense of not having bugs, I mean that in the sense of that if systemd-whateverd breaks your system, that's your problem. Systemd is making all the things better, get out of the way, little peon! It's an attitude thing. I recall a kerfluffle on the kernel mailing lists a few years back where systemd decided to squat on a debug flag on the kernel's boot args, which led to so much crap being piped into dmesg that it actually led to systems failing to boot, requiring the kernel developers to make changes to message handling in response. The systemd developers were incredibly dismissive of this issue, closing the bug report in a couple of hours until a large amount of outrage (and possible hostile changes from the kernel developers) forced their hand.
It's a mix of presumptuousness, antagonism and inability to admit being wrong. And when I say antagonism, I don't mean leveling insults, I mean the kind of "civil" antagonism you might see on a politically hot article on a Wikipedia talk page.
Systemd might solve concrete problems, but it does so at the cost of a monstrous increase in complexity, bug (and so, security attack) surface, and wasted sysadmin time dealing with both of these things. It never solved a problem I actually had (to include writing init scripts - who actually does this by hand anymore?), but has most definitely caused me hours of headache at work, and that's not even getting into the stuff I've had to deal with at home.
Give me openrc and does-one-thing-well daemons any day of the week.
You have never followed the development of any of his projects, huh? He is a worse asshole than Torvalds. He is just "sly" about it. CLOSED. WONTFIX. NOTABUG. is a meme with with his projects.
and much less of an asshole than other people who are praised for their "no bullshit" attitude.
You have never followed the development of any of his projects, huh?
He is a worse asshole than Torvalds. He is just "sly" about it. CLOSED. WONTFIX. NOTABUG. is a meme with with his projects.
When they are an obvious bug, yes. And then, when you spend the next 3 days telling the user they are doing everything wrong, and much change their workflow to do things the New Right Way (aka the...
When they are an obvious bug, yes. And then, when you spend the next 3 days telling the user they are doing everything wrong, and much change their workflow to do things the New Right Way (aka the Poettering way), yes.
I have. I've met the guy. I've seen him be an asshole, even a massive jerk, a couple of times. But overall he's pretty okay, and doesn't shout at people. I do not like him to be clear, but I can...
I have. I've met the guy. I've seen him be an asshole, even a massive jerk, a couple of times. But overall he's pretty okay, and doesn't shout at people.
I do not like him to be clear, but I can forgive a bad attitude once in a while especially when you're a public harassment target.
Not shouting at people doesn't necessarily make one not an asshole. I'm generally considered an "asshole" at work, but never raise my voice. I'm an asshole, because technologically, I'm...
Not shouting at people doesn't necessarily make one not an asshole. I'm generally considered an "asshole" at work, but never raise my voice. I'm an asshole, because technologically, I'm conservative: I wait until things are proven reliable before jumping on them.
A bit of a knee-jerk reaction in my opinion. From the presentation to me it's pretty clear that this homed thing can safely coexist with regular pam managed users and that it represents a solution...
There are problems, but this whole thing is bullshit.
A bit of a knee-jerk reaction in my opinion.
From the presentation to me it's pretty clear that this homed thing can safely coexist with regular pam managed users and that it represents a solution for pure desktop users. For that case, having to local login before being able to ssh, seems a reasonable compromise. For servers, where you need to have remote access without any of this stuff, you can still use plain old user and ssh key management.
So, I guess my always on desktop at home is a shitty setup... I often SSH to it, as a jump point to other place, before I ever consider "locally logging on"...
So, I guess my always on desktop at home is a shitty setup... I often SSH to it, as a jump point to other place, before I ever consider "locally logging on"...
I am not sure if you interpret what I said earlier as being that your setup is shitty, but using a computer as a jump host is a perfectly valid use-case. However that is usually done for...
I am not sure if you interpret what I said earlier as being that your setup is shitty, but using a computer as a jump host is a perfectly valid use-case. However that is usually done for minimizing the allowed incoming IP pool on the destinations to just the IP of the bastion, not because you store your credentials on it.
And, like I said above, nobody will "make you" enable homed if you don't want to. Nothing that I saw in the presentation makes me believe you won't be able to use pam based users in the future.
I feel that interlocking dependencies making it more and more difficult to do overrides your notion of it being a false implication. Gnome for example, required systemd-logind. system-logind...
I feel that interlocking dependencies making it more and more difficult to do overrides your notion of it being a false implication.
Gnome for example, required systemd-logind. system-logind requires systemd. systemd requires systemd-logind...
And given all the work being poured in to locking out alternatives (See the push against udevd, or the lack of documented and stable API for systemd-logind)... You can see where this is going?
Sure it's FOSS, and someone can always take the burden on themselves to hack around that stuff (Like eudevd), but it takes extra work everytime a change is introduced, and it's a purposeful decision to do that by Redhat. Redhat wants Gnome and their stack to be the stack.
OK, I'll give you that RedHat is trying to push systemd onto people. But as long as you can install Gentoo with elogind and a random non Gnome UI stack, you are able to use linux without systemd....
OK, I'll give you that RedHat is trying to push systemd onto people. But as long as you can install Gentoo with elogind and a random non Gnome UI stack, you are able to use linux without systemd. You stated a very general statement which is not true.
Also I don't accept your statements (before you add some proper citation) about pushing out other projects and unstable logind API, etc, etc.
This is my last comment on the subject. We are of different opinions and that's fine by me.
The citation: https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ See how much of that is not covered under their API stability promise? Specially between...
See how much of that is not covered under their API stability promise? Specially between required components, that are then required (Now) by other projects, in order to function?
I have the same feelings, except that my “escape plan” is OpenBSD. Maybe with some Plan 9 From User Space niceness. At this pace, GNU/Linux will turn into systemd/Linux very soon. Just tell me...
I have the same feelings, except that my “escape plan” is OpenBSD. Maybe
with some Plan 9 From User Space niceness. At this pace, GNU/Linux will
turn into systemd/Linux very soon. Just tell me that systemd/coreutilsd
or systemd/ccd sound improbable.
GuixSD is different: it has it's own daemon manager (which is only a daemon manager), and it's way better at separating state and config. When Poettering says user config is state, that's quite...
GuixSD is different: it has it's own daemon manager (which is only a daemon manager), and it's way better at separating state and config.
When Poettering says user config is state, that's quite indicative of how ignorant he is. User config is config, and in GuixSD, it's right there where it belongs, in a config file with structured syntax using a proper programming language. I really want to migrate to GuixSD soon.
Re-posting one of my comments from HN on the subject. I see this opinion quite often and I think it's based far too much on "ancient wisdom" and not actually grounded in reality. Because in...
Re-posting one of my comments from HN on the subject.
I've always viewed the "fragmentation" (opinionated differences giving the end-user more choice) between distros as a feature, not a bug.
I see this opinion quite often and I think it's based far too much on "ancient wisdom" and not actually grounded in reality.
Because in practice, the fragmentation has meant that people creating/selling cross-platform desktop apps take one look at linux and think: "Yeah, this isn't worth it".
It means a poorer user experience for Linux novices (and even advanced users), because documentation doesn't always match what's on their desktop. They're missing binaries. Arguments are different. Things are implemented differently not even for the sake of being different, but simply because there was no opportunity to reuse the work, so none was reused (and now backwards-compatibility is in the way of changing that).
It also means that there's a ridiculous amount of duplicated work between all the distributions. That duplicated work takes a toll on all distributions, which run on limited, usually-volunteer manpower.
Those distributions with less manpower, the ones that will actually try new things rather than do something slightly-different, are the ones that are more likely to die. The fragmentation between things that are essentially-the-same creates a higher effort barrier to creating actual new things.
systemd is slowly fixing all of this, and thank fuck.
I don't think this is true. Every major distro for newbies uses almost the same tools. Ubuntu and Mint are the two bigger distros for the average user and they are the same. Of course we have...
I don't think this is true.
Every major distro for newbies uses almost the same tools.
Ubuntu and Mint are the two bigger distros for the average user and they are the same.
Of course we have Fedora, Arch, Gentoo, Void, but making the software that works on Ubuntu working on them is a task that mostly the distro contributors do. There is no need for those companies to expand their software to even smaller distros. If there is profit, it's with Ubuntu and Redhat.
What the software companies do is support mostly Ubuntu and maybe Redhat/CentOS/Fedora.
The others just catch up by themselves if they want.
The reason Linux isn't widely adopted as desktop is simply because computers come with Windows and the regular user never change OS. Systemd-homed will not change that. If you need to make encryption easy for the regular user (which already is, the installer in those distro takes care of that), you can imagine that they don't know how to burn an iso to a thumbdrive, format and change OS.
I can guarantee you it's the case. I've contributed to Ubuntu, Debian, and now heavily participating in Arch Linux development and seen it all first hand. It all manifests itself in many places....
I can guarantee you it's the case. I've contributed to Ubuntu, Debian, and now heavily participating in Arch Linux development and seen it all first hand.
It all manifests itself in many places. Gaming is a good example because, you'd think most distros would behave the same but they don't. Different audio systems and configurations. Different x11 behaviours which fuck with the graphics. Different ways of getting various bits of system info.
People give up. Most of them have a legitimate attempt at it and then someone up the chain says: stop wasting SO MUCH TIME on 0.1 percent of our users.
We should be making it easy. As easy as electron made it.
But that's the point. Why are you participating in the fraction of a fraction? Most of the profit is on Ubuntu. Develop only for it. If you don't want fragmentation, why are you caring about Arch...
But that's the point. Why are you participating in the fraction of a fraction? Most of the profit is on Ubuntu.
Develop only for it. If you don't want fragmentation, why are you caring about Arch at all?
Fedora too. But this shows that fragmentation is not the problem. The problem is profit. If there's money in it, the company will support it. They don't have to do for all distributions, just the...
Fedora too.
But this shows that fragmentation is not the problem. The problem is profit. If there's money in it, the company will support it. They don't have to do for all distributions, just the most used one or two.
They don't have to care about Void, Devuan, Gentoo.
I mean seriously, how did Krita get developed for WIndows, MacOS, and all the Linux distributions! It's an impossible task. /s
Because in practice, the fragmentation has meant that people creating/selling cross-platform desktop apps take one look at linux and think: "Yeah, this isn't worth it".
I mean seriously, how did Krita get developed for WIndows, MacOS, and all the Linux distributions! It's an impossible task. /s
I think the point is that Krita is complex, so is Blender, and it's doable. And they have less money than Adobe. They don't develop for Linux because the profit is small, not because of fragmentation.
I think the point is that Krita is complex, so is Blender, and it's doable. And they have less money than Adobe.
They don't develop for Linux because the profit is small, not because of fragmentation.
Of course it's doable. I've done it. What I said is that most companies decide it's not worth it. Listing the amount of software compatible only windows + macos seems like a more reasonable...
Of course it's doable. I've done it. What I said is that most companies decide it's not worth it.
Listing the amount of software compatible only windows + macos seems like a more reasonable approach. But I would think I don't need to do that because it is common knowledge that Linux is not worth porting to, especially for commercial software. The only reason why we have more modern apps on Linux nowadays is Electron.
I agree, what i'm disagreeing to is that the reason is fragmentation. It is not. It's because of profit. Linux as desktop is way smaller than even MacOS. Linux has a lot of fragmentation, but only...
I agree, what i'm disagreeing to is that the reason is fragmentation. It is not. It's because of profit. Linux as desktop is way smaller than even MacOS.
Linux has a lot of fragmentation, but only if you look for it. Ubuntu is the most widespread distro for the regular user and is the go to for every company that ships computers with Linux.
They don't need to develop for all distros, just for Ubuntu. They don't do it because there is no money in it since people don't change the OS.
Why people keep using Facebook even after all the scandals and leaks? Because everybody is using it and it comes by default in every smartphone.
I don't like you accusing me of bad faith, when I was merely contesting your position that fragmentation is the reason app dev uptake on Linux is slow.
I don't like you accusing me of bad faith, when I was merely contesting your position that fragmentation is the reason app dev uptake on Linux is slow.
I apologize if it wasn't in bad faith, but I'm having a hard time interpreting it otherwise. I never said true cross-platform doesn't exist; I contribute to a lot of it myself. But I feel it's a...
I apologize if it wasn't in bad faith, but I'm having a hard time interpreting it otherwise. I never said true cross-platform doesn't exist; I contribute to a lot of it myself. But I feel it's a safe assertion to say that most people and companies will land on "it's not worth it".
I feel I should also clarify I don't think fragmentation is the only reason for the low dev uptake, but it is definitely one. I've seen it with my own eyes. (/cc @Grand0rbiter)
As soon as you announce "we'll support Linux", first of all, people expect more than Ubuntu. You'll get complaints if you only support Ubuntu / RH. Then, you'll get a flurry of complaints that you don't use standard so-and-so, or aren't compatible with such-and-such configuration setup. They get enough of those as it is with Windows, it's a real pain to sort through all of it.
I feel people are way too idealistic when they think about how "easy" it is to support Linux "if you just do the lowest-effort thing". Sure, it is, but you first have to know what the lowest-effort thing is, and then deal with the consequences of doing only that.
I agree that this happens a lot. But what happens if you ignore it and only support Ubuntu/RH? I don't think you will loose any significant profit at all. Just support Ubuntu / RH. People will...
As soon as you announce "we'll support Linux", first of all, people expect more than Ubuntu. You'll get complaints if you only support Ubuntu / RH. Then, you'll get a flurry of complaints that you don't use standard so-and-so, or aren't compatible with such-and-such configuration setup.
I agree that this happens a lot. But what happens if you ignore it and only support Ubuntu/RH?
I don't think you will loose any significant profit at all. Just support Ubuntu / RH. People will complain, but if fragmentation is the problem, just stop supporting other small use cases.
In the end, it's still Linux and people who really need/want your product will change to Ubuntu/RH.
There's a real cost in even triaging the issues, that's the thing. I'll try to dig up some examples for later so you can see real-world cases of this :)
There's a real cost in even triaging the issues, that's the thing. I'll try to dig up some examples for later so you can see real-world cases of this :)
That's basically what you're saying, and then blaming fragmentation. When in reality, it boils down to marketshare. Then saying you're not saying it. So appreciate the apology, but perhaps you...
I apologize if it wasn't in bad faith, but I'm having a hard time interpreting it otherwise.
That's basically what you're saying, and then blaming fragmentation. When in reality, it boils down to marketshare. Then saying you're not saying it.
Because, accusingly pointing a finger and saying "BAD FAITH" is, in and of itself, considered "Bad faith", especially when used to silence opposition.
But I feel it's a safe assertion to say that most people and companies will land on "it's not worth it".
Right, because market penetration of linux is tiny. With the work to port to Linux, you get at best a 3% uptake. Which would be lower, if it's not FOSS, since most Linux users will lean towards FOSS apps, even if they aren't on par yet.
As soon as you announce "we'll support Linux", first of all, people expect more than Ubuntu.
Valve seems to be doing just fine saying,"Just Ubuntu".
I generally do. Maybe you should re-read your post: Sarcastic, hostile tone and an obvious exaggeration. Don't be surprised if it's read as bad faith; if you don't appreciate that, maybe don't do...
Assume Good Faith
I generally do. Maybe you should re-read your post: Sarcastic, hostile tone and an obvious exaggeration. Don't be surprised if it's read as bad faith; if you don't appreciate that, maybe don't do that.
Valve seems to be doing just fine saying,"Just Ubuntu".
They're not doing fine. I love them, by the way; they're taking in a massive amount of work and hugely helped the Wine efforts. Proton is amazing. The amount of money and effort they've invested in Linux gaming is a massive help. But all in all, they've received little credit for it, and they're having to deal with a massively increased workload for all this.
My point stands besides Valve, anyway; Valve somehow got itself a vested interest in seeing Linux succeed, so the barriers don't matter for them. The barriers matter for the majority. It's a numbers game: You have to get large amounts of people ready and willing to pick up development towards Linux. Give them incentives, and make the work as easy as possible for them. Then it'll only increase for them.
This isn't rocket science. It's a well known and practiced strategy, by every single other platform out there. Linux fails at it because the commercial incentives don't line up and most people overall are clueless about how to achieve these goals. They'll focus on irrelevant things such as the command line interface of whatever package manager they prefer.
The devs that care end up having to abstract away all of this to avoid everyone hating them. Lennart comes in and instead provides solutions that break paradigms, and people yell at him for that… but the people who yell at him generally haven't actually thought about the problem space, unlike him.
Sounds kinda nice to me... Some people already have their home directory in a separate partition, so making that an encrypted loopback fs sounds like a reasonable step. The only thing that really...
Sounds kinda nice to me... Some people already have their home directory in a separate partition, so making that an encrypted loopback fs sounds like a reasonable step. The only thing that really changes is the process of creating accounts and logging in, which can be handled by systemd anyway.
Everything about the "sidecar" databases sounds optional and the most likely to break stuff.
Edit: to be clear, I'm not a fan of solutions like systemd that ignore the Unix philosophy. It sounds like making your home directory an encrypted loopback fits just fine with modularity and interoperability, though. I'd be happy to see homed flop and be replaced by some small shell script that does the decryption and mounting at login time.
Whether or not you like Lennart Poettering, you have to recognize that this is a major undertaking and addresses some real issues.
Slides: https://cfp.all-systems-go.io/media/homed-asg2019.pdf
What real issues?
The slides go over them.
I don't see any real issues in those slides, though.
ProblemsNeedswritable/etc+MixesStateandCon gurationUIDassignmentsneedtob epropagatedb etweensystemsNoencryption(Or\mismatching"encryption)Nomo dernauthenticationmechanismsNotextensible;plenty\Sidecar"databases(/etc/shadow,accounts-daemon,samba,SSH,pamlimits)Noresourcemanagemen
All of those are either well addressed in a modular fashion, or a made up problem (ie, no resource management, it's almost like Lennart doesn't know about ulimits. Writeable /etc, which it really doesn't. not extensible well, it really is.)
So much breakage for nothing. Hopefully the distros won't force this on us, or I'm going back to FreeBSD or maybe GuixSD. Many questions and problems with this for me;
SSH logins are vital, can't give them up. Home encryption is already there.
It's better to encrypt actual sensitive files with GPG rather than the entire disk or the entire home directory.
My files may (and do, in my use case) outside of my home directory.
Most personal computers are indeed single user, why fight against that?
If memory can't be encrypted, this whole thing is futile, so why bother?
This will create tonnes of compatibility issues that are essentially unnecessary.
Who the heck is this guy to decide on everything that goes into our OSes?
How will we prevent that major distributions just force this on all users like they do with systems?
I really dislike the power this guy and systems in general has over or tech lives. There are problems, but this whole thing is bullshit. The worst solution possible.
I don't think that's planned. Where did you see that?
For you, yes, but not for most users. I'd welcome no-hassle, on-by-default encryption.
Why? If you're thinking performance, encryption has a very, very low footprint thanks (I think) to hardware support.
Why indeed? I didn't see Lennart trying to fight against it.
Recovering RAM is a lot harder than recovering data from a hard drive/SSD. Preventing everyday data theft is not futile.
That remains to be seen, but I agree Lennart's track record on that respect is not absolutely stellar.
Lennart Poettering is a top engineer at Red Hat, who is by far the top contributor to Desktop Linux. If you don't want to use Red Hat products, that's fine, but you will find out that a big chunk of the software you use daily originates from them. So I think it's only fair that they have control on the software they develop. Others have tried to do without them, but they usually don't get very far due to lack of resources. Also, they tend to make good software, which is why people like to use it. The Pulseaudio and SystemD controversies have pretty much died down.
How so? Every newbie friendly distro i tried recently (Solus, Ubuntu, Fedora) has the option for encryption in it's installer.
yes, but disc encryption is not really working for notebooks, as it is not encrypted during suspend. I think he explains that really well.
This system is incompatible with many usecases of SSH, it's pretty clear on the Q&A session
I feel that's similar to saying "Who the heck is [Linus Torvalds] to decide on everything that goes into our kernel?".
In that it's both a wild exaggeration, and also an unjustified call-out. Poettering has built up a bad reputation because his software is so direly needed, many distros have rushed to adopt it, often too early (First with Pulseaudio, then with systemd). This draws ire from users who have to adapt to the changes. But he is an exceptional developer, and much less of an asshole than other people who are praised for their "no bullshit" attitude.
You can go ahead and make your own distro if you so wish. Or join one of the couple that are led by similarly-cranky people. I'll give you the low down on that: It won't work out. Poettering has a knack for getting his stuff shipped in distros because he solves problems. He's not writing "yet another tool to do X which is done by 20 other solutions", he's writing "this is how we solve X, the proper way", and doing so with financial backing, which allows throwing real resources at it.
I wish the Linux community would shut the fuck up about this guy because this approach is the only one that has even a hope of continuing to compete with modern operating systems. Linux has failed to keep up with how users deal with personal computers nowadays. We can catch up, but it takes work; homed is one of the components needed to catch up.
I'll address this as an aside:
It is not. Full-disk encryption is common on desktops, laptops and even more so on mobile devices (Android and iOS). I don't think you gave a moment's thought at a regular user actually bothering to encrypt/decrypt their sensitive files one at a time; if they even are able to determine what actually is sensitive, that is.
The big problem that I have with many of Poettering's projects is that he is able to do what he does because the people that came before him made simple text / file based tooling. Some of it not great, but in any case, it is easy to extend most of linux because it's often just a few files and maybe some shell scripts or whatever. His projects on the other hand basically pull up the ladder behind them by creating sprawling interfaces that stick their fingers in everywhere. I have a problem with this because it will make it very hard for us to ever escape this local minima if something better rolls along. His works complete disdain for modularity is maddening.
One of the things I find massively frustrating is that my time and talents are wrapped up solving other problems. I'm super jealous of his 40 hours a week that he gets to spend creating software that I often have to actively avoid. I shit you not, I am actively trying to achieve financial independence s.t. I throw my hat in the ring on this stuff because I have completely lost faith in the Poettering-led vision for the end state of linux userspace.
I guess I should also add that I don't care much for
whatever that is supposed to mean. I want to be able to enjoy my computer without it puking all over me. I lost many hours to systemd (oh your user service failed to start in 30 seconds, I guess I'll log you out of your session, and other such nonsense). And it's not the man, it's the code. PulseAudio has definitively made things better. Systemd is a mess. If he can find someway to design something s.t. that any other project has a cat in hells chance of using it without dragging in the entire jungle I'll be pleased to see it, but I won't hold my breath.
Lastly:
It's a real dick move to suggest that everyone that is dissatisfied with systemd is a crank. There are plenty of reasons to not want to use it, and you undermine everything else you say by mixing in such commentary.
We all stand on the shoulders of giants. I get what you're saying (and I agree to an extent with his distain for modularity, even though it's not completely true).
If you're serious about this, I'm happy to try to help guide you through finding a job in the linux desktop space. Red Hat is the obvious one but working at KDE is also a very good bet if you want to work to improve these things. Canonical often has open jobs as well and they do some good work. There's many ways to be paid to contribute.
I can't help with your systemd issues… you may have various things misconfigured. Most people have it working fine; those that don't generally messed with the configuration without really understanding it. The portion that's left hitting real bugs, those generally get fixed if they're reported. You can see where I'm going with this. What you're describing (logout on user service failure to start) definitely sounds like a misconfiguration; a service dependant on another which fails to start, thus the other one gets killed. The feature would work as intended, what you put into it doesn't.
Heavens no. I'm just talking about the knee-jerk distros that were spawned by it. And it's absolutely fair to say those people are cranks, if you've had to deal with them.
I also feel that "cranky" is the least offensive way to describe a post ending in "this whole thing is bullshit. The worst solution possible."…
That's super cool of you, but I'll pass. I intend to "retire" early by paying off my house in the next couple of years through a mix of contracting gigs and investments, and then go full time OSS. I don't yet know which projects I'd like to contribute to.
That's the thing, I'm not asking for help. I solve my own problems. Eventually I solved them completely by ditching systemd entirely where possible, and limiting usage of it's features where I can't (I run a lot of rhel / centos boxes).
This is I guess where I completely disagree with the kinds of UX choices systemd makes. Lets be concrete: this particular issue was a fun confluence of things: I had a working socket activated user service of gnupg. Arch at some point decided they would also provide that service. Conflict! Fine. Whatever. What I take issue with is how this manifested: I'd login, then 30 seconds later I'd get logged out. What. The. Fuck. After scrabbling around for 10 minutes I put on my thinking cap, logged in via a tty, worked my way through journalctl and figured it out. What would have been much easier is if systemd had just let the service fail and left me to notice my gnupg setup was broken when I went to use it, and I'd have had the luxury of my whole DE to investigate it. This and other papercuts too mundane to remember eventually got me off arch on my personal boxes.
I know you can't randomly know the skills and abilities of random people on the internet but I've written hundreds of systemd unit files and know many of the man pages off heart. Systemd has weird failure modes and fails in more cryptic ways than just about any other supervision suite. I will freely admit I push more edges many people would (I am a distributed systems engineer with a strong SRE / ops bent). I'd take runit or s6 any day of the week.
I don't think that's a completely fair read of people's issues with Poettering, systemd, and the like.
Part of it is the attitude. If systemd or its developers breaks something, it is automatically your fault. Systemd can do no wrong.
And I don't mean that in the sense of not having bugs, I mean that in the sense of that if systemd-whateverd breaks your system, that's your problem. Systemd is making all the things better, get out of the way, little peon! It's an attitude thing. I recall a kerfluffle on the kernel mailing lists a few years back where systemd decided to squat on a debug flag on the kernel's boot args, which led to so much crap being piped into dmesg that it actually led to systems failing to boot, requiring the kernel developers to make changes to message handling in response. The systemd developers were incredibly dismissive of this issue, closing the bug report in a couple of hours until a large amount of outrage (and possible hostile changes from the kernel developers) forced their hand.
It's a mix of presumptuousness, antagonism and inability to admit being wrong. And when I say antagonism, I don't mean leveling insults, I mean the kind of "civil" antagonism you might see on a politically hot article on a Wikipedia talk page.
Systemd might solve concrete problems, but it does so at the cost of a monstrous increase in complexity, bug (and so, security attack) surface, and wasted sysadmin time dealing with both of these things. It never solved a problem I actually had (to include writing init scripts - who actually does this by hand anymore?), but has most definitely caused me hours of headache at work, and that's not even getting into the stuff I've had to deal with at home.
Give me openrc and does-one-thing-well daemons any day of the week.
You have never followed the development of any of his projects, huh?
He is a worse asshole than Torvalds. He is just "sly" about it. CLOSED. WONTFIX. NOTABUG. is a meme with with his projects.
When they are an obvious bug, yes. And then, when you spend the next 3 days telling the user they are doing everything wrong, and much change their workflow to do things the New Right Way (aka the Poettering way), yes.
I have. I've met the guy. I've seen him be an asshole, even a massive jerk, a couple of times. But overall he's pretty okay, and doesn't shout at people.
I do not like him to be clear, but I can forgive a bad attitude once in a while especially when you're a public harassment target.
Not shouting at people doesn't necessarily make one not an asshole. I'm generally considered an "asshole" at work, but never raise my voice. I'm an asshole, because technologically, I'm conservative: I wait until things are proven reliable before jumping on them.
A bit of a knee-jerk reaction in my opinion.
From the presentation to me it's pretty clear that this homed thing can safely coexist with regular pam managed users and that it represents a solution for pure desktop users. For that case, having to local login before being able to ssh, seems a reasonable compromise. For servers, where you need to have remote access without any of this stuff, you can still use plain old user and ssh key management.
So, I guess my always on desktop at home is a shitty setup... I often SSH to it, as a jump point to other place, before I ever consider "locally logging on"...
I am not sure if you interpret what I said earlier as being that your setup is shitty, but using a computer as a jump host is a perfectly valid use-case. However that is usually done for minimizing the allowed incoming IP pool on the destinations to just the IP of the bastion, not because you store your credentials on it.
And, like I said above, nobody will "make you" enable homed if you don't want to. Nothing that I saw in the presentation makes me believe you won't be able to use pam based users in the future.
The same thing was said of systemd... And then systemd-journald... And then systemd-logind...
I feel that as long as you can find distributions without systemd your comment is making a false implication.
I feel that interlocking dependencies making it more and more difficult to do overrides your notion of it being a false implication.
Gnome for example, required systemd-logind. system-logind requires systemd. systemd requires systemd-logind...
And given all the work being poured in to locking out alternatives (See the push against udevd, or the lack of documented and stable API for systemd-logind)... You can see where this is going?
Sure it's FOSS, and someone can always take the burden on themselves to hack around that stuff (Like eudevd), but it takes extra work everytime a change is introduced, and it's a purposeful decision to do that by Redhat. Redhat wants Gnome and their stack to be the stack.
OK, I'll give you that RedHat is trying to push systemd onto people. But as long as you can install Gentoo with elogind and a random non Gnome UI stack, you are able to use linux without systemd. You stated a very general statement which is not true.
Also I don't accept your statements (before you add some proper citation) about pushing out other projects and unstable logind API, etc, etc.
This is my last comment on the subject. We are of different opinions and that's fine by me.
The citation: https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
See how much of that is not covered under their API stability promise? Specially between required components, that are then required (Now) by other projects, in order to function?
I have the same feelings, except that my “escape plan” is OpenBSD. Maybe with some Plan 9 From User Space niceness. At this pace, GNU/Linux will turn into systemd/Linux very soon. Just tell me that systemd/coreutilsd or systemd/ccd sound improbable.
GuixSD is different: it has it's own daemon manager (which is only a daemon manager), and it's way better at separating state and config.
When Poettering says user config is state, that's quite indicative of how ignorant he is. User config is config, and in GuixSD, it's right there where it belongs, in a config file with structured syntax using a proper programming language. I really want to migrate to GuixSD soon.
Re-posting one of my comments from HN on the subject.
I see this opinion quite often and I think it's based far too much on "ancient wisdom" and not actually grounded in reality.
Because in practice, the fragmentation has meant that people creating/selling cross-platform desktop apps take one look at linux and think: "Yeah, this isn't worth it".
It means a poorer user experience for Linux novices (and even advanced users), because documentation doesn't always match what's on their desktop. They're missing binaries. Arguments are different. Things are implemented differently not even for the sake of being different, but simply because there was no opportunity to reuse the work, so none was reused (and now backwards-compatibility is in the way of changing that).
It also means that there's a ridiculous amount of duplicated work between all the distributions. That duplicated work takes a toll on all distributions, which run on limited, usually-volunteer manpower.
Those distributions with less manpower, the ones that will actually try new things rather than do something slightly-different, are the ones that are more likely to die. The fragmentation between things that are essentially-the-same creates a higher effort barrier to creating actual new things.
systemd is slowly fixing all of this, and thank fuck.
I don't think this is true.
Every major distro for newbies uses almost the same tools.
Ubuntu and Mint are the two bigger distros for the average user and they are the same.
Of course we have Fedora, Arch, Gentoo, Void, but making the software that works on Ubuntu working on them is a task that mostly the distro contributors do. There is no need for those companies to expand their software to even smaller distros. If there is profit, it's with Ubuntu and Redhat.
What the software companies do is support mostly Ubuntu and maybe Redhat/CentOS/Fedora.
The others just catch up by themselves if they want.
The reason Linux isn't widely adopted as desktop is simply because computers come with Windows and the regular user never change OS. Systemd-homed will not change that. If you need to make encryption easy for the regular user (which already is, the installer in those distro takes care of that), you can imagine that they don't know how to burn an iso to a thumbdrive, format and change OS.
I can guarantee you it's the case. I've contributed to Ubuntu, Debian, and now heavily participating in Arch Linux development and seen it all first hand.
It all manifests itself in many places. Gaming is a good example because, you'd think most distros would behave the same but they don't. Different audio systems and configurations. Different x11 behaviours which fuck with the graphics. Different ways of getting various bits of system info.
People give up. Most of them have a legitimate attempt at it and then someone up the chain says: stop wasting SO MUCH TIME on 0.1 percent of our users.
We should be making it easy. As easy as electron made it.
I'll elaborate on this later, I have to go.
See: Valve.
Valve says,"Make your game run on this runtime (Ubuntu 14.04), and we'll make sure it works everywhere".
But that's the point. Why are you participating in the fraction of a fraction? Most of the profit is on Ubuntu.
Develop only for it. If you don't want fragmentation, why are you caring about Arch at all?
Fedora too.
But this shows that fragmentation is not the problem. The problem is profit. If there's money in it, the company will support it. They don't have to do for all distributions, just the most used one or two.
They don't have to care about Void, Devuan, Gentoo.
I mean seriously, how did Krita get developed for WIndows, MacOS, and all the Linux distributions! It's an impossible task. /s
Why don't you list every single one of them? Then I guess I'll do the same and we'll see who has a point?
I dont like this bad faith post.
I think the point is that Krita is complex, so is Blender, and it's doable. And they have less money than Adobe.
They don't develop for Linux because the profit is small, not because of fragmentation.
Of course it's doable. I've done it. What I said is that most companies decide it's not worth it.
Listing the amount of software compatible only windows + macos seems like a more reasonable approach. But I would think I don't need to do that because it is common knowledge that Linux is not worth porting to, especially for commercial software. The only reason why we have more modern apps on Linux nowadays is Electron.
I agree, what i'm disagreeing to is that the reason is fragmentation. It is not. It's because of profit. Linux as desktop is way smaller than even MacOS.
Linux has a lot of fragmentation, but only if you look for it. Ubuntu is the most widespread distro for the regular user and is the go to for every company that ships computers with Linux.
They don't need to develop for all distros, just for Ubuntu. They don't do it because there is no money in it since people don't change the OS.
Why people keep using Facebook even after all the scandals and leaks? Because everybody is using it and it comes by default in every smartphone.
Because profit is low, because most folks using Linux also prefer FOSS.
I don't like you accusing me of bad faith, when I was merely contesting your position that fragmentation is the reason app dev uptake on Linux is slow.
I apologize if it wasn't in bad faith, but I'm having a hard time interpreting it otherwise. I never said true cross-platform doesn't exist; I contribute to a lot of it myself. But I feel it's a safe assertion to say that most people and companies will land on "it's not worth it".
I feel I should also clarify I don't think fragmentation is the only reason for the low dev uptake, but it is definitely one. I've seen it with my own eyes. (/cc @Grand0rbiter)
As soon as you announce "we'll support Linux", first of all, people expect more than Ubuntu. You'll get complaints if you only support Ubuntu / RH. Then, you'll get a flurry of complaints that you don't use standard so-and-so, or aren't compatible with such-and-such configuration setup. They get enough of those as it is with Windows, it's a real pain to sort through all of it.
I feel people are way too idealistic when they think about how "easy" it is to support Linux "if you just do the lowest-effort thing". Sure, it is, but you first have to know what the lowest-effort thing is, and then deal with the consequences of doing only that.
People really just do give up.
I agree that this happens a lot. But what happens if you ignore it and only support Ubuntu/RH?
I don't think you will loose any significant profit at all. Just support Ubuntu / RH. People will complain, but if fragmentation is the problem, just stop supporting other small use cases.
In the end, it's still Linux and people who really need/want your product will change to Ubuntu/RH.
There's a real cost in even triaging the issues, that's the thing. I'll try to dig up some examples for later so you can see real-world cases of this :)
That's basically what you're saying, and then blaming fragmentation. When in reality, it boils down to marketshare. Then saying you're not saying it.
So appreciate the apology, but perhaps you should read over "Assume Good Faith": https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
Because, accusingly pointing a finger and saying "BAD FAITH" is, in and of itself, considered "Bad faith", especially when used to silence opposition.
Right, because market penetration of linux is tiny. With the work to port to Linux, you get at best a 3% uptake. Which would be lower, if it's not FOSS, since most Linux users will lean towards FOSS apps, even if they aren't on par yet.
Valve seems to be doing just fine saying,"Just Ubuntu".
I generally do. Maybe you should re-read your post: Sarcastic, hostile tone and an obvious exaggeration. Don't be surprised if it's read as bad faith; if you don't appreciate that, maybe don't do that.
They're not doing fine. I love them, by the way; they're taking in a massive amount of work and hugely helped the Wine efforts. Proton is amazing. The amount of money and effort they've invested in Linux gaming is a massive help. But all in all, they've received little credit for it, and they're having to deal with a massively increased workload for all this.
My point stands besides Valve, anyway; Valve somehow got itself a vested interest in seeing Linux succeed, so the barriers don't matter for them. The barriers matter for the majority. It's a numbers game: You have to get large amounts of people ready and willing to pick up development towards Linux. Give them incentives, and make the work as easy as possible for them. Then it'll only increase for them.
This isn't rocket science. It's a well known and practiced strategy, by every single other platform out there. Linux fails at it because the commercial incentives don't line up and most people overall are clueless about how to achieve these goals. They'll focus on irrelevant things such as the command line interface of whatever package manager they prefer.
The devs that care end up having to abstract away all of this to avoid everyone hating them. Lennart comes in and instead provides solutions that break paradigms, and people yell at him for that… but the people who yell at him generally haven't actually thought about the problem space, unlike him.
Sounds kinda nice to me... Some people already have their home directory in a separate partition, so making that an encrypted loopback fs sounds like a reasonable step. The only thing that really changes is the process of creating accounts and logging in, which can be handled by systemd anyway.
Everything about the "sidecar" databases sounds optional and the most likely to break stuff.
Edit: to be clear, I'm not a fan of solutions like systemd that ignore the Unix philosophy. It sounds like making your home directory an encrypted loopback fits just fine with modularity and interoperability, though. I'd be happy to see homed flop and be replaced by some small shell script that does the decryption and mounting at login time.