Your second sentence is a red herring that misses the point of that goal. Of course nobody has that goal (hopefully). But when people don't have that goal, complexity tends to creep in.
Simplicity rarely happens by chance in large software.
Every time I've seen people have the simplicity goal from the outset, they inevitably have to at some point abandon it or their simple software gets replaced by software that has additional complexity. It often happens that the complex replacement then again grows too complex, and someone comes along with a simpler solution and the cycle repeats indefinitely. Firefox was supposed to be a simpler Mozilla, and when it got too complex, Chrome came out. I wouldn't be surprised that now that both of them are too complex, in a few more years someone comes out with a browser that is simpler than both of them and is intended to replace them both.
Software development, in a very essentialist sense, is nothing but complexity management. Trying to never have any complexity is a naïve view of what software is.
End users don't want simplicity, they want ease of use. Simple beautiful software is out there aplenty with diverse features, you just have to desire to use it.
They don't want simplicity until the app crashes. They don't want simplicity until their supposedly compatible older programs don't run. They don't want simplicity until a security breach takes out their business. They don't want simplicity until their custom software "can't be made portable, realistically. It'll all have to be rewritten." They don't want simplicity until the program's behavior changes, and it's not at all clear why, or how to recover. They don't want simplicity until they've lost or overwritten data for no reason that can be discovered.
In other words, it's not the falling that kills ya, it's hitting the ground.
Very interesting take on things. From this point of view the virtue of the New Jersey Way is that they shorten this cycle, keeping things from getting way out of the ordinary f*ed up before the cycle restarts - after all, why wait 'till your car skids out and crashes before you replace your bald tires; that sort of thing.
From this point of view I don't think the opposite of "simple" is "complicated" but rather "full-featured". Softwares who try to follow the KISS philosophy often implement the usual 80% of functionalities that take 20% of the time, and leave the rest to other projects.
"Nobody in Hollywood ever sets out to make a bad movie."
Often said in that industry, and technically/semantically true - just highly misleading and a thin excuse. A whole lot of people in Hollywood are pretty much indifferent to quality as opposed to flash. What they are, is highly focused on the marketing and star-vehicle issues which will determine their paychecks (at least in the short term.) The result is still all too predictable, and lamentable. They set out to do a great many things - it's just that making a really fine movie that people will want to watch twenty years from now wasn't one of them.
Almost all programmers like to solve problems. It's why they took the job. But very few programmers really enjoy to re-solving problems, only better. The results of the latter activity aren't exactly highly visible, so the rewards aren't as obvious.
Narcissists don't actively try to do the job badly or to cause future problems, this is just an inevitable and profound side effect of their relentless focus on getting superficially good-looking results now. Their indifference - even to human life - is not praiseworthy, or the absence of a flaw.
How is that any different? Right off the bat, it assumes I must know what argv, argp, wide chars and junction points are. Which is to be expected given it's a POSIX layer for Windows, and so you should expect a minimalistic Linux distro blurb would need some prerequisite knowledge.
You're on a vendetta for no reason that I can discern. Nothing about Morpheus' front page is hard to understand in the slightest.
Vendetta? Ha, I post one comment with a better example of introducing a project's motivations and I'm on a vendetta? That escalated (in your mind and nowhere else) quickly.
[why Plan9 mk?] Stable release model with binary packages and a ports system (Plan9 mk-based).
[why static link? Why musl-libc?] Statically linked, using musl-libc.
[never heard of them. Explain] Sane simple base utilities, see: sbase, ubase, hbase etc.
[hmm... I think I get it] Package management using mount overlays (aufs), but mostly FHS compatible.
[fine] UTF-8 locale.
[good, popular enough to not need explanation] libressl linked.
[what's that?] No Native Language Support (NLS).
[what instead?] No systemd and rabbit hole.
[fine] No binary blob drivers (except linux-firmware).
[perfect example of explaining with just the right amount of detail] Separate /emul namespace for legacy or binary-blob software (skype, wine, robot-unicorn-attack).
Given the list of linked projects it seems to follow the same minimalist approach of the http://suckless.org/ community. Build a small distribution with small tools that do one thing well.
In all seriousness, Poettering is at least trying to replace complexities with simplicities. He thinks unified config files are simpler than ad-hoc shell scripts for init systems. He thinks a sound system that handles all audio in a uniform way is simpler than having a bunch of different APIs that implement a different and incompatible part of the audio stack.
Nobody is trying to make things more complex, or if they are, it's usually a joke like brainfuck.
He thinks unified config files are simpler than ad-hoc shell scripts for init systems.
That's a gross misrepresentation of the problem. Shell-based rc does not have to be "ad-hoc" if there is a sane process management framework in place. In such cases, the scripts can be extremely terse. [1] [2] In essence, the scripts become mere "callbacks" and have their primary purpose to provide the start command line, optionally with some form of chain loading to compose execution state. One can go further and write a small, special-purpose LL(1) command language for chain loading of programs, e.g. execline. The unit file format, conversely, cannot be composed, the options must be treated as static entries, and implicit state is carried, sometimes making service writers resort to horrifically subverting the systemd model just to escape. [3]
I'm not trying to represent the problem nor do I want to discuss the merits of systemd. I am just talking about what Poettering is trying to do and why he says systemd is better. Whether he's actually achieving it is of no relevance to his stated intentions.
I am really not liking this newly interventionist moderation regime. It's not just that I disagree with many of the individual decisions (though I do). It's that it's thoroughly capricious, and that makes HN a really unpleasant place to be.
There are a lot of distros out there. That is what makes Linux so great. You can roll your own formula of kernel and userland for YOUR needs[and then share it]. You aren't forced to just take what Microsoft or Apple or XXXX gives you nor do you have to completely write your own from scratch.
Yeah, I agree. We were ready to ship our AAA game on Windows, Mac and Linux and had tested with all versions, but now that this distro came out we have to spin up the test farm again and re-hire all the testers... Not to mention updating the graphics so it gracefully degrades from playing it on 8 monitors on a couple of the latest nVidias to playing it on the console over ssh. And let me tell you, getting specular reflections to render properly on a braille terminal was a real bitch.
I've often wondered if the Linux world will eventually split into two camps: desktop/mobile/embedded, and servers.
With desktop/mobile/embedded applications, you often have to do a lot of hardware-level integration to provide the best customer experience. This requires lots of features to support different use cases like hibernation, cellular radio on/off, power control, realtime device support, drivers that support many different drivers on different platforms, etc.
With servers, you actually want the OS to be hardware agnostic. Tight hardware integration is a drawback - not a feature - since it makes it harder to migrate / clone a system. Performance is pretty much the primary driver on a server, so having fewer abstraction layers should improve speed. Simple is better, because there's usually enough complexity in the applications themselves.
I don't think these use cases can be served by the same system. The whole systemd schism was a symptom of this core problem - systemd is great for the laptop/mobile/embedded case because it adds a whole lot of control over various system states. The server guys hate it because it adds a lot of complexity and doesn't give them much functionality that makes their lives easier. But the problem isn't systemd, its that these two use cases are very hard to solve with one system.
I figured the break would be between desktop/server and mobile/embedded - you have behemoths driving the development of each (Red Hat and Google respectively) that don't always see eye to eye.
There is a certain overlap you may be overlooking, the "enthusiast amateur". They overlap a bit with server and a bit with desktop/mobile/embedded.
But they are into computers for computers sake, so to speak, rather than into computers as a tool for doing a different job.
Meaning they are looking for agnosticism, much like your server example, but on desktop/mobile/embedded.
And those seem to be what gets the hardest squeeze in all this, and are the least articulate in their complaints.
The irony is that many of those that are in that segment may know more about the day to day inner workings of things than the actual devs writing the code. This because they see the code in action with all the ragged edges exposed, rather than in pristine code form.
I'd say they're a niche market; and often IMO are people who fall in the "server" camp in their day jobs, and want to see something similar for their personal devices. It's a small fraction of the overall desktop/mobile/embedded market though, so it's not going to drive market preference.
For me the most important morpheus feature is the static recipes, most linux distributions compile software dynamically against glibc and then the generated binaries won't run in other distributions. Static builds will run in many linux environments.
I used morpheus and other similar distributions recipes to create `static-get`[0] a static linux binary repository.
Statically linking everything seems to complicate upgrades significantly. If libc is rev'd does that mean every binary on the system needs to be rev'd as well? Static linking is great for simplifying the deployment strategy but can degrade the user/administrator experience.
My comment is not directly related to Morpheus Linux.
The first link on the page "Keep it simple" directs to "http://suckless.org/philosophy" whose motto is "software that sucks less".
I've never contributed any software to the open-source community (I hope I will one day), but I find it fairly unfair to all those devs that spent years making open source tools that are used by every single sysadmin to say that you want to write "software that sucks less".
You might want to write software that is "better" but not that "sucks less". Saying a tool sucks in hindsight is way easier than writing a tool that doesn't suck in the first place. After all, you probably learned how to write a tool that "sucks less" thanks to all of those other developers that made those mistakes for you.
So, although I do agree with some statements made in the "philosophy" part of the website, like this one:
> Most hackers actually don’t care much about code quality. Thus, if they get something working which seems to solve a problem, they stick with it. If this kind of software development is applied to the same source code throughout its entire life-cycle, we’re left with large amounts of code, a totally screwed code structure, and a flawed system design. This is because of a lack of conceptual clarity and integrity in the development process.
I do think the domain name and mottos are poorly chosen.
"sucks less" is a nod to the fact that all software sucks in some regard. Yes, also the software written by the suckless people. (It's also the motto of the mutt email client) Acknowledging that there is something wrong is the first step to making better things. Also, IMHO "We aim to do stuff that sucks less" is a bit more humble than saying "We aim to write better software", but in the end, both probably mean the same thing.
Would you go to your co-worker and tell him/her/it, "Hey, I'm going to write the same software you did, but I'm going to write in a way that sucks less"? I wouldn't. But that's me.
And the case of the coworker vs. the website: There's a difference. If a coworker said that to me, I'd have words to say back (unless it really does suck. I'd be willing to hear a well-reasoned argument or admit my own flaws).
The website though? Unlike a coworker, I never have to see a website more than once. A coworker saying that directly to me sounds like an attack on my character and my ability to write code. A website published for everyone to see is just a critique of code.
Finally, I can close a website, turn off my computer, and take a walk after being offended (as I do often). I cannot do the same with a coworker. Knowing I can't avoid or dismiss a person like that means that I have to confront them. And that ends really, really poorly.
The idea of code sucking more or less is totally subjective. That website is purely opinion. I like to use dwm on my Desktop computer because it's really lightweight and easy to set up. Others prefer a shinier and less confusing system like GNOME Shell or something.
Essentially, they are presenting one side of the argument. They want to show the world why trying to minimize code is a good thing (and only good; there is a necessary bias in debate). And you are choosing to be offended by the idea that someone out there in the world thinks someone else's code sucks.
It seems like you just have a personal vendetta against suckless, and it seems you fully understand that and choose to make HN your soapbox regardless of whether or not it is on topic. That's why you're getting downvotes. Someone came up with a cool idea, and you nitpick on something so miniscule it's incredible, rather than discussing the pros and cons of the concepts themselves.
> The website though? Unlike a coworker, I never have to see a website more than once. A coworker saying that directly to me sounds like an attack on my character and my ability to write code. A website published for everyone to see is just a critique of code.
> Finally, I can close a website, turn off my computer, and take a walk after being offended (as I do often). I cannot do the same with a coworker. Knowing I can't avoid or dismiss a person like that means that I have to confront them. And that ends really, really poorly.
> The idea of code sucking more or less is totally subjective. That website is purely opinion. I like to use dwm on my Desktop computer because it's really lightweight and easy to set up. Others prefer a shinier and less confusing system like GNOME Shell or something.*
This misses the point. Be it in real life, or on a website, "Suckless" is just, subjectively, very negative, and I pointed it out. Obviously not everybody thinks it is, and that's fine.
> And you are choosing to be offended by the idea that someone out there in the world thinks someone else's code sucks.
Offended might be a bit of a strong term, that I did not use. I did, however, say that I think the domain name and motto are poorly chosen.
> It seems like you just have a personal vendetta against suckless
Not at all. And although I've never tried their software, I'm sure it's great.
> and it seems you fully understand that and choose to make HN your soapbox regardless of whether or not it is on topic.
I believe HN is a place to express opinions, constructive criticism. I don't think my comment falls out of that scope.
It so happens that the first link on that website pointed to a website whose domain name stuck out for me. I then just stated my opinion about what I read on said website.
> Someone came up with a cool idea, and you nitpick on something so miniscule (sic) it's incredible, rather than discussing the pros and cons of the concepts themselves.
Whether or not this is a cool idea (which I think it is) has nothing to do with my first comment. I even specified my comment was not directly related to Morpheus Linux.
> That's why you're getting downvotes.
Let it be said that I was merely pointing out the lack of arguments from down votes. I'm glad you took the time adding a comment.
> I don't really understand your position.
That's ok, someone's always wrong on the internet.
> I find it fairly unfair to all those devs that spent years making open source tools that are used by every single sysadmin to say that you want to write "software that sucks less".
I am one of those systems administrators. The fact that my job exists at all is 100% down to the fact that software sucks. If it didn't suck, systems would administer themselves. It does nobody any good to pretend otherwise out of some kind of abstract politeness.
My argument is not that software doesn't suck, nor that we should pretend it doesn't.
However, recognizing that other's people work, upstream of yours, contributed to the "betterness/sucklessness" of yours is, IHMO, important. But this is purely subjective (therefore the IHMO).
Now, the /philosophy page of suckless.org objectively disregards this; by not acknowledging it in the first place.
That's because it's wholly irrelevant. The software sucks. This is the whole of the message. It's not important why it can be done better if nobody ever does it better.
It's ironic you're complaining about straw men while criticizing a technology project because you don't like the way they talk about technology, completely ignoring the technology itself. It's an unproductive gripe, unlikely to better anyone's situation.
It is rooted in the Suckless Stali [0] stuff. It is a community trying to build their personal dream Unix. So primarily desktop and server is the goal.
70 comments
[ 2.4 ms ] story [ 113 ms ] threadI wonder who has ever had as a goal to make complicated software from the outset.
Simplicity rarely happens by chance in large software.
Software development, in a very essentialist sense, is nothing but complexity management. Trying to never have any complexity is a naïve view of what software is.
In other words, it's not the falling that kills ya, it's hitting the ground.
Often said in that industry, and technically/semantically true - just highly misleading and a thin excuse. A whole lot of people in Hollywood are pretty much indifferent to quality as opposed to flash. What they are, is highly focused on the marketing and star-vehicle issues which will determine their paychecks (at least in the short term.) The result is still all too predictable, and lamentable. They set out to do a great many things - it's just that making a really fine movie that people will want to watch twenty years from now wasn't one of them.
Almost all programmers like to solve problems. It's why they took the job. But very few programmers really enjoy to re-solving problems, only better. The results of the latter activity aren't exactly highly visible, so the rewards aren't as obvious.
Narcissists don't actively try to do the job badly or to cause future problems, this is just an inevitable and profound side effect of their relentless focus on getting superficially good-looking results now. Their indifference - even to human life - is not praiseworthy, or the absence of a flaw.
I have to infer a bunch.
Start writing a good synopsis on the first page of your projects people.
You're on a vendetta for no reason that I can discern. Nothing about Morpheus' front page is hard to understand in the slightest.
[good] Keep it simple.
[why Plan9 mk?] Stable release model with binary packages and a ports system (Plan9 mk-based).
[why static link? Why musl-libc?] Statically linked, using musl-libc.
[never heard of them. Explain] Sane simple base utilities, see: sbase, ubase, hbase etc.
[hmm... I think I get it] Package management using mount overlays (aufs), but mostly FHS compatible.
[fine] UTF-8 locale.
[good, popular enough to not need explanation] libressl linked.
[what's that?] No Native Language Support (NLS).
[what instead?] No systemd and rabbit hole.
[fine] No binary blob drivers (except linux-firmware).
[perfect example of explaining with just the right amount of detail] Separate /emul namespace for legacy or binary-blob software (skype, wine, robot-unicorn-attack).
Their URLs lead to their respective cgit repos, where looking at the top-level source tree immediately demystifies their purpose.
Rest is nitpicking by some nebulous standard that barely any project satisfies. It's clearly mentioned that sinit and svc replace systemd, too.
Nobody is trying to make things more complex, or if they are, it's usually a joke like brainfuck.
That's a gross misrepresentation of the problem. Shell-based rc does not have to be "ad-hoc" if there is a sane process management framework in place. In such cases, the scripts can be extremely terse. [1] [2] In essence, the scripts become mere "callbacks" and have their primary purpose to provide the start command line, optionally with some form of chain loading to compose execution state. One can go further and write a small, special-purpose LL(1) command language for chain loading of programs, e.g. execline. The unit file format, conversely, cannot be composed, the options must be treated as static entries, and implicit state is carried, sometimes making service writers resort to horrifically subverting the systemd model just to escape. [3]
[1] http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/ru...
[2] http://www.openbsd.org/faq/faq10.html#rc
[3] http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...
I am really not liking this newly interventionist moderation regime. It's not just that I disagree with many of the individual decisions (though I do). It's that it's thoroughly capricious, and that makes HN a really unpleasant place to be.
With desktop/mobile/embedded applications, you often have to do a lot of hardware-level integration to provide the best customer experience. This requires lots of features to support different use cases like hibernation, cellular radio on/off, power control, realtime device support, drivers that support many different drivers on different platforms, etc.
With servers, you actually want the OS to be hardware agnostic. Tight hardware integration is a drawback - not a feature - since it makes it harder to migrate / clone a system. Performance is pretty much the primary driver on a server, so having fewer abstraction layers should improve speed. Simple is better, because there's usually enough complexity in the applications themselves.
I don't think these use cases can be served by the same system. The whole systemd schism was a symptom of this core problem - systemd is great for the laptop/mobile/embedded case because it adds a whole lot of control over various system states. The server guys hate it because it adds a lot of complexity and doesn't give them much functionality that makes their lives easier. But the problem isn't systemd, its that these two use cases are very hard to solve with one system.
The key is to find what can be agreed on and where the split needs to be.
If my foggy memory serves me right, the windows embedded team took action on an analysis like this about 10-15 years ago.
But they are into computers for computers sake, so to speak, rather than into computers as a tool for doing a different job.
Meaning they are looking for agnosticism, much like your server example, but on desktop/mobile/embedded.
And those seem to be what gets the hardest squeeze in all this, and are the least articulate in their complaints.
The irony is that many of those that are in that segment may know more about the day to day inner workings of things than the actual devs writing the code. This because they see the code in action with all the ragged edges exposed, rather than in pristine code form.
I used morpheus and other similar distributions recipes to create `static-get`[0] a static linux binary repository.
[0] https://github.com/minos-org/minos-static
The first link on the page "Keep it simple" directs to "http://suckless.org/philosophy" whose motto is "software that sucks less".
I've never contributed any software to the open-source community (I hope I will one day), but I find it fairly unfair to all those devs that spent years making open source tools that are used by every single sysadmin to say that you want to write "software that sucks less".
You might want to write software that is "better" but not that "sucks less". Saying a tool sucks in hindsight is way easier than writing a tool that doesn't suck in the first place. After all, you probably learned how to write a tool that "sucks less" thanks to all of those other developers that made those mistakes for you.
So, although I do agree with some statements made in the "philosophy" part of the website, like this one:
> Most hackers actually don’t care much about code quality. Thus, if they get something working which seems to solve a problem, they stick with it. If this kind of software development is applied to the same source code throughout its entire life-cycle, we’re left with large amounts of code, a totally screwed code structure, and a flawed system design. This is because of a lack of conceptual clarity and integrity in the development process.
I do think the domain name and mottos are poorly chosen.
"sucks less" has a negative connotation, but I can see the message delivered is not necessarily negative.
I'll put it another way:
Would you go to your co-worker and tell him/her/it, "Hey, I'm going to write the same software you did, but I'm going to write in a way that sucks less"? I wouldn't. But that's me.
And the case of the coworker vs. the website: There's a difference. If a coworker said that to me, I'd have words to say back (unless it really does suck. I'd be willing to hear a well-reasoned argument or admit my own flaws).
The website though? Unlike a coworker, I never have to see a website more than once. A coworker saying that directly to me sounds like an attack on my character and my ability to write code. A website published for everyone to see is just a critique of code.
Finally, I can close a website, turn off my computer, and take a walk after being offended (as I do often). I cannot do the same with a coworker. Knowing I can't avoid or dismiss a person like that means that I have to confront them. And that ends really, really poorly.
The idea of code sucking more or less is totally subjective. That website is purely opinion. I like to use dwm on my Desktop computer because it's really lightweight and easy to set up. Others prefer a shinier and less confusing system like GNOME Shell or something.
Essentially, they are presenting one side of the argument. They want to show the world why trying to minimize code is a good thing (and only good; there is a necessary bias in debate). And you are choosing to be offended by the idea that someone out there in the world thinks someone else's code sucks.
It seems like you just have a personal vendetta against suckless, and it seems you fully understand that and choose to make HN your soapbox regardless of whether or not it is on topic. That's why you're getting downvotes. Someone came up with a cool idea, and you nitpick on something so miniscule it's incredible, rather than discussing the pros and cons of the concepts themselves.
I don't really understand your position.
> Finally, I can close a website, turn off my computer, and take a walk after being offended (as I do often). I cannot do the same with a coworker. Knowing I can't avoid or dismiss a person like that means that I have to confront them. And that ends really, really poorly.
> The idea of code sucking more or less is totally subjective. That website is purely opinion. I like to use dwm on my Desktop computer because it's really lightweight and easy to set up. Others prefer a shinier and less confusing system like GNOME Shell or something.*
This misses the point. Be it in real life, or on a website, "Suckless" is just, subjectively, very negative, and I pointed it out. Obviously not everybody thinks it is, and that's fine.
> And you are choosing to be offended by the idea that someone out there in the world thinks someone else's code sucks.
Offended might be a bit of a strong term, that I did not use. I did, however, say that I think the domain name and motto are poorly chosen.
> It seems like you just have a personal vendetta against suckless
Not at all. And although I've never tried their software, I'm sure it's great.
> and it seems you fully understand that and choose to make HN your soapbox regardless of whether or not it is on topic.
I believe HN is a place to express opinions, constructive criticism. I don't think my comment falls out of that scope.
It so happens that the first link on that website pointed to a website whose domain name stuck out for me. I then just stated my opinion about what I read on said website.
> Someone came up with a cool idea, and you nitpick on something so miniscule (sic) it's incredible, rather than discussing the pros and cons of the concepts themselves.
Whether or not this is a cool idea (which I think it is) has nothing to do with my first comment. I even specified my comment was not directly related to Morpheus Linux.
> That's why you're getting downvotes.
Let it be said that I was merely pointing out the lack of arguments from down votes. I'm glad you took the time adding a comment.
> I don't really understand your position.
That's ok, someone's always wrong on the internet.
I am one of those systems administrators. The fact that my job exists at all is 100% down to the fact that software sucks. If it didn't suck, systems would administer themselves. It does nobody any good to pretend otherwise out of some kind of abstract politeness.
My argument is not that software doesn't suck, nor that we should pretend it doesn't.
However, recognizing that other's people work, upstream of yours, contributed to the "betterness/sucklessness" of yours is, IHMO, important. But this is purely subjective (therefore the IHMO).
Now, the /philosophy page of suckless.org objectively disregards this; by not acknowledging it in the first place.
It's ironic you're complaining about straw men while criticizing a technology project because you don't like the way they talk about technology, completely ignoring the technology itself. It's an unproductive gripe, unlikely to better anyone's situation.
I'm pretty much running a similar stack on a laptop in gentoo. took a lot of work to unmask it all, though. would a howto be useful to anyone?
Embedded systems? (Despite the small number of packages, the size of some make me think not)
Reproducible builds?
Unikernels?
[0] http://sta.li/