Morpheus Linux
morpheus.2f30.org
morpheus.2f30.org
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.
I 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.
Embedded systems? (Despite the small number of packages, the size of some make me think not)
Reproducible builds?
Unikernels?
[0] http://sta.li/
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?
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.