EDIT: A number of the Unity Linux developers have added comments. I forgot a few things, and there are some great additions. Be sure to read the comments for a more full picture of what’s been going on!

---

Intro ∞

So it occurs to me that I’ve never really sat down and talked about Unity Linux. I’ve engaged in bunches of discussions and have even popped in on some early forum posts when Unity Linux was just conceived, so that I could correct things. But I haven’t really participated in any of that (even before my recent break).

Part of the reasoning was that I was expecting a manifesto or at least a good official description to be crafted which goes over anything I would want to say. The rest of the reasoning was that I figured the magazine would sprout up and I’d be able to do interviews or articles within it which would clarify anything not covered by the official stuff.

So seeing as that stuff hasn’t been done, I may as well write up a bunch of stuff from my own personal perspective. So let me emphasize that again this is a blog post written by spiralofhope and it is not an official press release by the Unity Linux team. It is personal opinion, memory, perspective and whatever.. and it may damned well be wrong!. There, hopefully no dumbasses will come along and misunderstand/misrepresent anything I say. Well they’ll probably straw man or quote out of context anyways. Bastards.

What is Unity Linux? ∞

Unity Linux is the name of a project and the name of it’s product. It is a Linux Distribution.

What makes Unity Linux different? ∞

A plainer way to ask this would be “Aren’t you duplicating effort?”

Yes and no.

First I’ll address the notion of duplication. In a free environment, where anyone works on their own projects how and when they like, there is no overriding notion of feature-sets or goals.

That probably won’t make a lot of sense. So let’s go for an example.

Let’s imagine we have ten people. They don’t know one another, but they could find one another, and they could even collaborate if they put forth that effort. But let’s imagine they don’t.

Each of those ten people has a problem. It just so happens that between all ten people the problem is roughly the same. Even so, all ten people will approach their problem differently. No matter how slight, they will each have different skills, different tools, different timings and who knows what else is different.

After some time, three of these projects “go live” and make it out into the world and get some recognition and use. A community forms. Then those three projects each learn about the other. The seven remaining learn about the three.

Now I want you to think about two developer perspectives..

• 1) My project isn’t done yet. Someone else made something that’s done.

• 2) My project is done and working. Someone else made something that’s done.

Then think a bit more..

• 1a) My project isn’t done yet and someone else’s is? Ok, I’ll use that.
• 1aa) Maybe some of my code would be useful to them.

• 1ab) Maybe I can join that project.

• 1b) My project isn’t done yet and someone else’s is? So what, I can do better!

• 2a) My project is done and working, and someone else is doing the same thing? I give up!

  • (This is almost never gonna happen. Anyone who invests their time and passion in something will be reluctant to abandon it)

• 2b) My project is done and working, and someone else is doing the same thing? Hey I wonder if I can use some of their code!

  • (Open source is awesome)

• 2c) My project is done and working, and someone else is doing the same thing? Maybe we can merge our projects together.

  • (This is so extremely unlikely – less for social reasons and more for technical reasons. With different tools and even programming languages, trying to do something like this is next to pointless. It becomes easier for 2a to occur)

So let’s get back to the original question of Aren’t you duplicating effort?. The answer is definitely yes – some duplication must exist, because the problem of a Linux distribution is “roughly” the same. The answer is also definitely no – some unique innovation (no matter how novel) exists. That uniqueness gives the project a reason to live. This doesn’t quite answer the “no” fully, so I’ll continue.

Back to “overriding notion of feature-sets or goals”. Let’s imagine our three projects are examining each other to make some decisions on how to act. They all know their projects have significant overlap and a similar goal. However their goals and methods and their entire emergent cultures aren’t perfectly compatible.

Their goals are not “out there”, they are internal and they are also influenced by all sorts of things. If the goal was a particular meal and each project uses a “similar” recipe, then each project has a developer or team with their own flavour to add to their dish. This analogy isn’t right though, because a meal, a recipe and ingredients are all “out there” and can be agreed-upon by different cooks in different kitchens. For our projects and their developers, they have no “shared reference”.

This lack of an external reference, and the fact that projects are a live body, and the harsh reality of technique and technical incompatibility, means that projects can’t simply be merged.

But Unity Linux wasn’t a project developed in the dark. Everyone knew that other projects existed. Hell, everyone used those other projects! So let’s talk about why Unity Linux came to be instead of having all that “duplicated” effort poured into any one or many existing or emerging projects.

• One or more Unity Linux project members were contributing to existing Linux projects.
• One or more Unity Linux project members had a personal flavour different and incompatible with existing projects.
• One or more Unity Linux project members felt that existing and emerging Linux projects did not or would not solve their particular problems.
• One or more Unity Linux project members wanted the grass-roots experience of founding a project.

• One or more Unity Linux project members followed others.

There are probably lots of other things that can be added to this list, but let’s keep it at this for now. Also keep in mind that there may (or may not) be overlap between the items. Let’s take me for example. I didn’t “feel the groove” for other existing projects. I wanted the grass-roots experience of founding a project. I was strongly motivated by devnet’s involvement.

I’ve got my own distribution ideas, and while I could use existing projects I felt that a future version of Unity Linux would perfectly suit me. What’s better than getting in on that sweet action as early as possible, and contributing to significant conversations to influence the project’s long-term goals? What’s better than starting from scratch and doing things “the right way”? (of course I had no clue what that was and still really don’t, but that’s half the fun)

So regarding the duplication of effort.. yes there is partial duplication with significant project (and project member) incompatibilities.

So what make Unity Linux different from existing and emerging Linux distributions? ∞

Good question me, I’m glad I asked myself.

So let me tie back to the fact that there are non-technical reasons why Unity Linux came together. But for this I’ll get a little more technical.

First is the underlying philosophy.

Unity Linux, at its core, has a different goal in mind than most other Linux distributions. Linux From Scratch is a project whose project is to help a developer build a Linux distribution from source code. That project is the most closely similar to Unity Linux. All others are meant to be end-user distributions.

Unity Linux is meant to be an end-developer distribution. The fact that it’s perfectly suitable for end-users has led to no end of confusion in justifying Unity Linux’s continued existence.

Now let’s talk technical. Sortof. I’m not involved with a lot of the more hardcore technical stuff so it’s difficult for me to relay this sort of information. This is really unfortunate since this is probably the most interesting stuff that needs to be put out there. Seeing as Unity Linux is for developers, and developers want to talk tech, this list/explanation is definitely something that will be worked on in the future.

RPM5 + smart, updated mkisofs, kernel, hardware detection and bootup-related stuff, stronger focus on internationalization and translation, focus on branding and re-mastering.

RPM had drama surrounding it. First, there have been and still are several versions of RPM floating around. Various versions are used by various distributions. The problem is that there was a schism for whatever reasons that I can’t remember and will probably write on later. That rift led to various forks, various revisions in various places and incompatibilities galore. I mean seriously. RPM is this half-working propped-up-with-duct-tape piece of crap.

The RPM5 project was one of those splits. This project had some weight to it and actually got their product working to the satisfaction of enough of the Unity Linux developers for it to be adopted. That adoption itself led to one developer leaving the project. His reasons are still valid to this day, examining both the technical merits of the various RPMs and both the discussion and decision-making processes.

I don’t know enough of the technical side, so I can’t explain that side of things. I do have lots of notes and this is a subject that I definitely want to bring up again. Reading up on RPM5 will explain part of the story, but there is a lot of back-story and other perspectives as well as a shit-tonne of opinion, poor-writing and misinformation. So I’m staying away from this for a while.

The social side was just a matter of how fast and unexamined the decision was. The challenges of communication is a topic for a separate post.

mkisofs was another one of those half-working projects that had to be personally patched and hacked upon by each project that used it. It had no maintainer as such, and the person who was entrusted with one of the versions of it was one of the early members of the Unity Linux team.

Ok, some more juicy drama. See, this is what you get for reading through this wall of text! =) This developer also left us, but damned if I can remember the details. Shit, I thought I could make this interesting. Art-related? I can’t remember. Maybe I’ll write on this in the future, it was quite a loss.

The kernel! Actually we lost an early developer on this one as well but he came back to us. I guess the kernel demanded it. We are extraordinarily lucky to have quality kernel hacking. Some very serious issues existed within our kernel and still exist in those of others. Again there is a lot of brokenness with various kernels various patches and hacks from different projects just “getting by”. Because of our complete break from everything else, we were able to “tear the bandage off quickly” and do away with any need for legacy support.. well since we had no legacy to support.

Choosing to not support the old stuff also meant that we needed to rebuild every package from scratch. Every. Last. One. Originally leveraged on the back of Mandrake Linux, the Unity Linux project now stands completely on its own. Mandrake is like our uncle. We examine source code and get a lot of inspiration, but we don’t have any sort of package compatibility like we did back in the experimental alpha days. PCLinuxOS was also an early influence, and the earlier TinyME (which was then based on PCLinuxOS) was a development platform for several people including myself.

We had another developer leave over the state of QA. Another seems to come-and-go depending on the state of documentation and organization. Organization is a huge topic and it’s so very difficult to realize implement and enforce. The very fact that this is all volunteering means that people end up doing things however and whenever they want. All kinds of issues with misdirected manpower occur. Wheels are spinning but the car’s not going anywhere.

A documentation-driven project with excellent QA are dreams that are difficult to manifest.

Hardware detection and bootup stuff. Ok I just threw that in there to look smart. I have no clue. Stuff works, that’s all I care about really. I just know that a lot of fiddling on the insides has been done. Me press button, it go. Ugh.

Internationalization, translation and branding are all main focuses of Unity Linux. While internationalization and translation are nowhere near new, and other projects are and will be doing this better than Unity Linux for a good while, it’s the branding and the branching/remastering stuff that will make Unity Linux stand separate from all other Linux distributions.

A developer can really benefit from having complete guides to build a Linux distribution not from scratch but from an already-working base. I can churn something custom out in an afternoon. But when all the other pieces are done right, a team could easily create something targetted to another language or to any special needs.

Remastering is easy with Mandrake Linux, PCLinuxOS [ 1 ], and probably others, but keep in mind the technical differences Unity Linux has. A non-crusty package management system and packages, a kernel that’s actually up-to-date and working, designed from the ground up for remastering not just tacked on with a half-working script.

The guides are things which really need to be worked on, and that’s right around where I come in. I live and breathe documentation.

zomg too much text! ∞

I know. I really just wanted to relay some simple stuff.

• Download the Unity Linux ISO. It’s not small, it’s got all the development, internationalization, language and branding tools on it. No need to download more stuff.
• Add and remove packages. I personally have a couple of scripts that trivially smart remove x y z and smart install x y z.
• Add branding – update pictures using guides that have to get made still.
• Remove unneeded stuff – the various development tools, old configuration files
• Do any custom hacking
• Run the prep script and spit out an ISO
• ???

• Profit!

So Unity Linux isn’t a light distribution? ∞

No, it was never meant to be either. There has been and still is some discussion over the notion of including “just what’s needed”. It started really light but then bloated to where it is now..

• Robust hardware detection
• A basic prompt
• The usual commandline linux tools
• Package creation tools
• Package management
• Software compiling tools

• Enough to get a net connection

X got snuck in because a GUI web browser was needed for one developer to access his router and get internet working. A desktop and toolbar were there for a while partly because we were using TinyME as a base.

I’m actually not sure about what all is there since I’ve been out of it for a while. I don’t think it’s possible to compile stuff from source on the default ISO without downloading some stuff. I should nag to get that included, but I don’t think it matters. The whole point is to have the minimal set of stuff with a net connection to get anything else you need.

The internationalization and other stuff was “cooked in” by default because it was such a challenge to make it external. it was probably impossible to separate some of it out, or it was impossible to have something minimal update to the more robust version of things. Or something.

So I use Unity Linux to make my own distribution then? ∞

Maybe. I just use it as my minimal desktop.

You could also use one of the other projects based on Unity Linux and build off of their work. That would take a bit more branding-work to at least remove their branding.

Basing off of TinyME for a minimal experience and a small ISO is probably way easier than using the main Unity Linux distribution itself.

Correcting common misconceptions ∞

Based off of is meaningless.

Unity Linux in its current state does not rely on any other Linux distribution at all. Period. Talk about Mandrake Linux or PCLinuxOS is just history. Whatever of them that was used was just scaffolding that has since been discarded.

Split from PCLinuxOS is also wrong.

Yes some Unity Linux developers were PCLinuxOS developers. But some Unity Linux developers were NOT PCLinuxOS developers. Some of those not-ever-PCLinuxOS-developers have expressed offence at the association.

Yes there was some drama and insanity from PCLinuxOS. Yes that was some of the reasoning for some developers to leave PCLinuxOS. Yes some of those developers who left PCLinuxOS under those circumstances ended up on the Unity Linux team. However some developers left far earlier than that split and some probably after. Also, it’s incorrect to think that there was one moment that had a mass of people leave PCLinuxOS and form up Unity Linux.

Detach the association between Unity Linux developers and PCLinuxOS developers. People come and go.

The idea of Unity Linux was seeded in the minds of several people for some time before there was any actual talk about it. Before the aforementioned drama and insanity the Unity Linux project had already begun forming and was being talked about more openly. I’ve always seen that drama (which I wasn’t a part of) as being “the last straw” for some people.

But it literally was..

zomg juicy drama! Share! ∞

Again, I wasn’t there so I don’t know. I’ve heard that open disagreement between active developers and “non-technical leadership” ended with several banishings. Don’t misunderstand this as one event though, I also understand that there was a slope before that drop. I heard about forum posts being deleted and forum bannings.

So if you were a developer and you just got your accounts all locked out so you can’t even continue discussion, what would you do? If you were a developer and one of your friends vanished one day in the heat of discussion and you learned they were banished, what would you do?

Me, I’d haul ass. “What’s everyone else up to? Ooh something new.” Some people came together, as people do, and others came for a while then went, still others are watching and waiting to see where things go, and others went their separate way. Such is life!

fin.

If there’s other stuff I haven’t covered, comment. If this answered a question you had, comment. If this corrected a misconception or misinformation you had, comment. If this was entertaining, comment. If you have a better way to explain something or especially if I’m wrong, comment!

Footnotes

1. PCLinuxOS remastering [ ↩ ]