Disclaimer: This post just sums up a concept for a new distribution which matches certain ideals. It is not the announcement of a new distribution. These are just abstract ideas. (However, if there is high interest in a project like this, it might of course develop into something real…)
I have been involved in Debian and Ubuntu for a long time now. When Ubuntu started, I was a Debian Testing user, and I immediately switched to Ubuntu when it started, because I liked the idea of a short-release-cycle, user-centric company-supported Debian based Linux distribution. However, I am now back to Debian for a long time, because of many reasons which nearly all had to do with Canonical policy. But this is not a post to criticise Ubuntu, so I’ll leave out most of that part. I am highly disappointed on how Ubuntu develops – not only the technical decisions are at least questionable, but also the social and community part is not that great anymore. There is a high asymetry in the relation between Canonical and other developers, Ubuntu mailinglists basically don’t create meaningful results, they sometimes even mutate to a Canonical Q/A session. The community does not seem to have a large influence on decisions about core services, and it can’t have it if there are things developed behind closed doors. (This is all, of course my subjective impression)
But really nobody can argue against the basic idea of Ubuntu and the great things Ubuntu created Also, many of the processes Ubuntu uses to develop the distribution are just great and well-working, as well as there is a highly active community around it. As you simply cannot argue with Canonical to change their policy (they are a company and have hidden plans, also they have every right to apply whatever policy they want), the natural way in any OSS project would be to fork it. But doing that blindly would just create another distribution, which would almost certainly vanish again soon, since there are already many Ubuntu derivatives which cover many use-cases using an Ubuntu base.
I discussed this stuff with Daniel some time ago, and we did some kind of brainstorming about what a perfect distribution would look like, from the perspective of a developer who wants to use a Debian-based distribution.
Here is a list of points which would define such a project:
- Every available package complies with the DFSG and Debian policy.
- Packages of DISTRO stay in close sync with Debian packages, changes are preferrably applied in Debian. DISTRO might work as a playground for new technology while Debian is in freeze.
- DISTRO stays as close to upstream as possible. It applies as less patches as possible, to deploy desktop environments which look like the thing upstream intended it to look like. Changes for DISTRO are developed upstream and only applied downstream if doing that doesn’t make sense or changes are distribution-specific and can’t be abstracted.
- All desktop environments are treated equally. There is no preferred DE.
- DISTRO stays in sync with release cycles of KDE and GNOME, to provide developers the latest stable development environment and users a recent version of fresh upstream software.
- DISTRO is user-centric. It tries to make the distribution work on as many hardware as possible and to fix any usability quirks which are found. But work on that should go upstream, of course.
- At the beginning of a release cycle, packages are merged from Debian and selectively merged from Ubuntu, where it makes sense.
- All Debian developers automatically have upload access to DISTRO, so they can upload versions of their packages to the cutting-edge DISTRO and also maintain the Debian things.
- All DISTRO developers can upload any package, but are responsible for everything they might break. Also, changes should be discussed with the original maintainer at Debian – this is the person who knows the package best.
- DISTRO is not a testing environment for Debian, it is developed like a short-cycle-less-stable-but-usable Debian. DISTRO recommends Debian Stable as “LTS” version.
- No CLA is enforced on anyone. People are free to contribute, as well as companies. The project structure is meritocratic.
- Features are discussed in the open. If there is disagreement about the direction of the project or about any technical issue, a public voting on this feature is created, where every project member can vote. The vote result is final (but can be changed in future, of course).
- Create a well-maintained core, make it possible to install the newest applications on that distribution (by using native packages, Listaller or Glick) Think about rolling releases, where applications are constantly updated and the core stuff is refreshed once a year/every 6 months. With this users have new apps immediately, but don’t live in fear that some core API or a desktop workflow changes immediately. (Also not desired for desktops in schools, universities and companies – maintaining a moving target in these larger environments is a pain)
- Create an Application-Center and application-ecosystem based on AppStream and Listaller around it. Encourage upstream developers to publish fresh applications there. Make it possible for every distribution to use this solution and help others to adapt it. Don’t try to lock people on that one platform by providing stuff exclusively for DISTRO or making it harder to use it.
- Encourage using additional commercial stuff like Amazon searches, magazine stores etc., but make these things available on a separate repository and make them entirely opt-in. Never enable stuff like this by default, but add simple instructions how to use these things for people who want to use them.
This is basically what we would like to have in a new distribution. 🙂 If you take a closer look, you will see that an effort like this would basically create a close-to-upstream, user-centric short-cycle Debian-based and close-to-Debian distribution, which would cover many use cases, including fixing the “use experimental for new packages during freeze” issue at Debian (DISTRO could be used as environment to run cutting-edge technology, which is generally stable enough, but not yet “Debian-Stable”-stable). Something like this does not exist at the moment. If you take a second look at the list above, you will also see that I mixed technical aspects with organizational aspects. This is intentional. This is just brainstorming, because it is good to know what you would like to have, instead of complaing about the status quo of other projects.
But maybe there will be a distribution which matches some of the above points, to create an upstream-friendly entirely community based Ubuntu.
siduction or aptosid are debian sid based and have some of these points 🙂
Some of this sounds like Arch Linux (e.g. staying as true to upstream as possible). Any particular reason you prefer a Debian basis?
Yes, but the reasons which really matter are non-technical: I like the Debian workflow, the package format, the policy, the package maintainership, the QA and generally the way Debian is constructed. This is a matter of personal taste 😉
One other reason is that Debian has an incredibly big repository with many well-maintained packages. Debian Testing is basically a raw-diamond for building an OS.
Not sure if these arguments convince you ;-). But unlike creating many pieces of core-infrastructure for application developers to choose, having a choice in distributions is a good thing, IMO.
Oh, and well, the point that I am a Debian developer might contribute to the fact that I prefer Debian 😀
Nobody in his right mind can look into a .deb file and say: “That’s a great format.” It’s an archive which in turn houses two additional archives.
apt does not handle delta packages OOTB and xz compression is also missing.
In addition the packages are not LSB compliant.
Also spec files being a single file… makes a lot more sense than Debian.
It’s literally impossible for any Debian-based project to stay upstream as much as Arch stays for the simple reason that Debian tampers in a weird way with upstream packages so much that they’re vaguely similar to what coders once baked them.
Take Apache2 for instance:
Arch: /etc/httpd/… – pretty much similar to upstream stuff
Debian: /etc/apache2/WTF? – Debian’s Way.
Same goes with BIND9 and pretty much everything else Debian touches and that’s not only bizarre but meaningless, I mean: why not stick upstream? It’s like the distribution suffers from a chronic NIH syndrome in the terms of “we can’t let it go without at least adding it our own special sauce” 😛
From the point of vue of an user (which I am, as I’m not a developper), the ideal Desktop distro would be :
– choose a target type of user (e.g. browsing+write basic documents+diplay/manage photos+listen music/videos) and select a list of applications that fit this purpose (e.g. Firefox + LibreOffice + Digikam + Amarok + VLC).
– choose one DE (e.g. KDE) and focus on the integration of all chosen applications to this specific DE.
– focus on stability over novelty, the Distro dev team should only work on stabilising and polishing the DE and the selected applications
– with the exception of some application with security problems (e.g. the browser should stay up to date)
I would love to have a very stable/polish KDE, with a bunch of very stable/polished applications, I don’t care for the new features as, to me, the current features are sufficient.
Today we have a very stable Kernel, a feature complete DE, a large set of feature complete Applications and nobody is really working on stabilisation/polishing of the old branches. Novelty is very good, easy on the eye, but if it is at the cost of less polish and less stability, it doesn’t really worth it.
Give me a KDE SC 4.8.6 (polished 1 year old KDE SC) with a 3.2.40 or even 3.0.68 Linux Kernel (one year old stable Kernel) together with the latest Firefox. And keep polishing these applications for 5 more years. I grinch every time I see that when a new KDE 4.x+1 comes out, the previous 4.x receive its very last update.
One year ago, the features in KDE SC 4.8 applications were sufficient for the vast majority of users. It just wasn’t polished enough for one PC vendor to install it by default and sell it like cupcakes. And this is, to me, the problem with the Open Source community. Polishing and Stabilizing is boring for the developpers so they don’t do it. That’s why today Linux is not yet ready for the Desktop. That’s why it will never be ready.
The kernel team are aware of that so the long term kernel are stable and polished. The user space should also follow this good example. Choose KDE 4.10 and make it PERFECT, continue to polish it, correct bugs, improve performances, and when KDE 4.10.20 goes out, Linux will be ready for the Desktop.
And I will be in heaven!
I agree with Pierre.
This project is just like this: Just Another Linux Distro on the block. We have enough already.
Focus on a SINGLE Desktop Environment and improve and _INNOVATE_ from it and cater NOT the developers but end users.
You want to equally treat all Desktop Environments??? That’s a very nonsense strategy. You can’t polish anything under the sun. What Canonical did was exactly the right thing = focous on a single DE, though you may not like the way they do, but the point is focus on user experience. There is no such a thing as innovation in any Linux distribution I’ve meet except at least from a few distros, everything is just like Another Distro nonsense!
Well, I disagree: What you should to use is Debian Stable or some comperable Distro.
At first it does not make sense to choose a limited target user. Your result will fit for very few users, and you would need lots of distributions. Further more a user would strumble on major issues, when he extends his intrest in long term. Therefore it is not the right way to focus on a few packages.
Focus on polishing?
– Stability: If you use a conservative distribution release, than you will have reasonable stable software.
– Usability: Improving the usability is continously done in the development of most applications. What is the advantage from limiting the development to usability issues for a couple of years? You could just take a later version. Then you would have the same result with some additional features.
– Performance: You don’t even have to work on this. After the time of waiting, the hardware evolution will do this task. But to be honest: The only scenarios where I have preformance issues, are tasks which I did not perform in former times. With a ancient browser and the corresponding websites, I could do most tasks on a 10 year old hardware with extended RAM and current software versions (Yes, the RAM consumption increased dramatically in the last years).
On the other hand: Commercial systems are not better in this regards. So: why should this be the showstopper for OSS?
The real reason might be, that all users are motivated to upgrade their systems to the latest versions. There are much scenarios, where this is a wrong decision.
Commercial software is not upgraded such often, as the user has to pay and/or the upgrades are not delivered automatically. This is different to OOS, but I don’t think, that new distro would make a change.
Yeah! More fragmentation.
Just what I thought and pretty sure also what Canonical wants to achieve – divide and conquer…
Better to join existing projects like Mageia or openSUSE.
Well, just a random comment, take it with a grain of salt, but if you replace that debian thing with Arch Linux at least 1/4 or 1/3 of your list is done and the rest you can build/create/develop that new DISTRO as easy or maybe easier using it if you really find the need.
Seriously consider it and don’t just discard it because it is not debian. That’s the main selling point anyway.
The distro you describe is one I would consider to switch to from Debian testing.
@Arch users: I don’t think you really understand Debian users. For me switching away from a Debian based distro is a non-option because I’m using Debian on all of my systems and like that Debian is rather stable. I do dislike rolling releases (and can see the problems with that in the bugtracker. It’s always Arch users hitting the problems because of untested code) and are using Debian testing only as a compromise.
Consider also that arch users are more likely to report bugs because of the distro philosophy and needed skills to use it. From The Arch Way:
“Arch Linux targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system”
ps. Thanks for your work.
So, this distro concept is not for end users, an Arch-based distro is for Linux users.
Arch is almost the opposite in many of the point.
Its dev centric not user centric
It don’t have a stable base, all is rolling
If it should work for a regular Ubuntu user Arch require to much knowledge/(or work) for many user new to linux.
Interesting ideas. I would like to add one thing for consideration (it may actually be implied by some of your above points).
All current linux distros have a single repo that serves as the base for all packages. Most of the time this means that kernel upgrades, core library upgrades and LibreOffice upgrades are handled similarly. This can create a situation that either slows down the push of userland apps or speeds up the push of system apps. Maybe consider separating the distro into 3 repositories (OS, System, Userland), with different policies for each. For example:
OS – this layer consists of the kernel, key CLI utilities, glibc, GRUB, etc. It would move the slowest.
System – Language interpreters (python, ruby, etc), GUI Libraries, DE It could move at a faster rate.
Userland – Firefox, Libreoffice, This repo could be rolling.
“Maybe consider separating the distro into 3 repositories (OS, System, Userland), with different policies for each.”
You describe Chakra http://chakra-project.org/wiki/index.php?title=Repositories
And “The Half-Rolling Release Model” http://chakra-project.org/wiki/index.php?title=Chakra#The_Half-Rolling_Release_Model
That’s exactly was I’m telling Matthias, core small OS with more up to date apps.
And I am not against it 😉
Mark’s suggestion to with different repositories won’t work that way, but defining a set of packages which is “core”, “framework” and “apps” makes a lot of sense. The “apps” set of packages would be rolling, while the other parts of the system get updates once/twice a year.
You got the gist of my proposal, I am not tied to a method of implementation. I used repos as a way to enforce the separation in my example, if there is a better way to achive these ends, I’m all for it.
I second the idea of a semi-rolling release where the “core” is stable, some of the tools are updates more frequently, and the user oriented apps are updated on essentially a rolling basis.
Most users want a stable OS with up to date apps.
Great idea, I’ve had similar thoughts often in the past. Though personally, I would not like “new release every 6 months”, I’d prefer rolling-release. But maybe that’s just because the only fixed-release distro I ever used was Kubuntu, and on almost every upgrade, something broke, which was really a pain – plus the fact that updates are always release during the first lecture week of a new semester, which is a totally unfit time to do a major upgrade since I need the PC to Just Work (TM). Two weeks earlier would be a lot better 😉
Yes! Chakra, has implemented the concept of half-rolling relleases as far as I’m aware of (wikipedia also mentions PCLinuxOS, Aurora OS but I don’t know to what degree, AuroraOS is Debian based, but I don’t know about the other things like package policies and that stuff.),
I’m a Chakra user and their repositories are doing exactly what you are describing! I sure want to see more distros like this, that actually is the best approach I can see at the moment. 😉
http://en.wikipedia.org/wiki/Rolling_release#Part-rolling_distributions
The only difference I see in this regard is that you are describing three layers of repositories rolling at different speed, whereas chakra only implements two.
http://chakra-linux.org/wiki/index.php?title=Half-Rolling_Release_Model
I’m sorry looking closely it seem there are also three layers, but I think it’s pretty different for what you are planning, since chakra is KDE centric.
I’ll have to look at Chakra more closely, I thought it was just KDE-centric Arch. Also, how easys is it to get Official Google Chome working on it?
Indeed it’s KDE tailored, originaly based on Arch, nowadays it’s driffting more to become a unique independent distro, but it is one by now. In order to make Chrome run you use a Chakra bundle:
http://chakra.sourceforge.net/wiki/index.php/Bundles
This approach is taken anly becuase chakra is KDE centric, but of course it wouldn’t be needed in a desktop agnostic distro.
http://www.chakra-project.org/packages/index.php?act=search&subdir=&sortby=name&order=ascending&searchpattern=x86_64*.cb
Also take in mind that Chakra is x86_64 only now, that’s what I call focus 🙂
Also what I meant to say about more distros with this release model, I don’t mean more distros per se, but more existing distros adopting this approach.
It seems Mark S. doesn’t get a rolling release model doesn’t have to be unstable, you could even make it roll as slow as you want(need), and in a layared fashion as in half-rolling. Focus in cuality not in dead-lines.
Frankly I find PPAs to be a mess, in the long run.
Oops, forgot to add this, when I mentioned Mark S. i was talking about this:
http://www.markshuttleworth.com/archives/1228
Honestly it would be a dream!
Sounds like you just want Debian itself?
DFSG-compliant? Oh, great, another Distro where I can’t run my hardware out of the box properly…
Yeah, also wondered how DFSG and user-centric at the same time would work…
Hi,
Here it is what I think a great distro would be:
1. Get Debian stable as core, which will provide 2 years of stable base to work on it
2. Add on top a stable Debian a rolling, but well tested KDE desktop – like starting to get in new major versions only of KDE after 4.x.2 releases
3. Add rolling userland programs as well, at least the major ones, like Firefox, Chromium, LibreOffice
4. Add great driver support, with binary and closed source drivers as well
5. Add multimedia support
6. Use systemd
After all this got done, things like a good system configuration center (like OpenSUSE or Mageia has), a welcome application for KDE, a good software center can be started to integrate.
Of course this would be a huge work, but with a good team it can be done – Debian team will maintain the core, latest KDE releases are quite stable, not much work is needed other than recompile new versions, the same with the latest Firefox or LibreOffice – the hard thing would be to get all this knead together.
Run in RAM please!
Please! Please!
Large amounts of RAM are so cheap (and Fast!).
Forgetfulness, eg just switch on/off persistence.
Once set up as you prefer, switch off further changes.
Harder to get malware, get hacked.
Update due?, allow persistent changes, switch it off again.
Regards
gvnmcknz
PS mostly To RAM please though
I recently made a request for a blogger to discuss some thought similar to what Pierre expressed above and maybe a little of the original ideas of what Matthias posted. I think Linux lags behind MS and Apple is due to it’s fragmentation, uncertainty/instability in choices and rolling releases which equates to “bugginess”. As it turns out the blogger like so many Linux users seem to default to an almost childish type of response, ‘its not my fault blame the OEMs for lack of exposure’, I bet you have all heard that before right? I wonder how many have MS friend that tell tell about how difficult it is to work with Linux, ‘but it’s easier than MS’, you’ve heard that too right? Ever responded, ‘but only because we have been playing with this thing for 2 yrs already know where to find things in all the DE and how to use CLI for fine tuning when stuff doesn’t work’.
The truth is that the reason we have so many Debian, including Ubuntu, off-shoots is because of Debian’s philosophy about stability, not that they are cutting edge. Now any one can adopt the stability to their own cutting edge stuff and that is quite fine but we need working stable systems that work even if it looks a bit boring. If the OS is open and allows for installation of other Des and WMs then we can figure out how to tweak it with all the eye candy in the world and then get back the boring stuff if things stat to break
I like the ideas that Matthias has just presented. And I also found a word familiar to me from my previou job – usecase. To me this is a key word when talking about a distro. Why? Because when we think about a distro, we should keep in mind the user type the distro is for and the type of work the user will use it for.
So here is my user classification, linuxwise:
1. Developer – I would say that a developer needs a stable base and modules he can add when he needs them. In fact, he should be able to easily do whatever he wants – I mean a developer is his own master here. In other words, a developer does not really need anything but a stable linux kernel, and the rest is his own preference and hobby.
2. An engineer, an artist, musician, other professional, no programming skills – stable kernel, system and apps. General upgrades not to often. Apps upgraded when new, stable version available. Needs to use apps from many different repos, systems – the need for a univeral, compatibility enabling package management system. Very good HW compatibility. Ability to seemlessly get online and log in to different systems, ability to be centrally managed. Easy to manage security tools. Fully functional, flexible and beautiful GUI (KDE). Ability to easily (or automatically) enable all the non-free software, drivers, etc. Where needed, a simple way to buy the necessary add-ons for strictly professional use. So this would be the PRO version.
3. The home user needs a stable, good initial distro that must be easy to use, be beautiful and be both flexible (custimizable on the GUI level) and compatible with his previous experience. The needs here are different from the professional user point of view. I would distinguish severl groups here, like serious home user (SO-HO), gamer, student, and any computer user of any age with no clear agenda or purpose at the moment – they all need something different and all you can do is try, by the quality of your distro, to convince them to use it.
If a distro that caters to the most demanding professional user (not a programmer) is built and properly maintained (which means stability, speed, reliability, quality and good looks) then there might be a chance of success. The person who solves this equation will surely make history.
What the developer needs (IMHO): Developers are only working on few packages. So they don’t want to setup the whole system. Basically they need a stable and relyable system, just as everyone else does. There are only few things, where developers differ from the average user:
– Packages close to upstream: This minimizes the amount of packages, which they have to build by their own.
– Good documentation of all downstream patches: This eases the use of own builds.
– They are also able to work arround problems. Still they don’t like to spend time on tweaking their system.
Good documentation is needed for every stable distribution. So it is no exclusive requirement. Few downstream patches are something, which are also beneficial for the software quality. So there is no special requirement for developers, as long you focus on high quality packages.
Hi! Sounds like a great project, with the potential of getting more non-expert users into the dev-loop. I hope it will work out — I for one am in!
I’m interested to know how you found the double-swirl, and why you picked that for the tentative first logo. And why green and blue in the end. (The reason I ask, is that I uploaded the original red-black one to wikimedia. I’m not criticizing your changes or anything, in fact I love the final logo and I’m proud to having contributed in a small way to the project; I’m just very curious about how it happened. .. =)
Hi! We’re just preparing our first Live-CD, which is a bit difficult due to some core infrastructure changes, but we’ll have something soon 🙂
As for the logo, we now have a different one 🙂 The double-circle should show the strong connection to Debian, and Tanglu being an addition to it.
For the colors, take a look at https://desktopsummit.org/ and you will immediately know why there is green and blue 😉
The first ideas were discussed at DS, and my personal goal is to create a perfect base for both KDE and GNOME, and to treat them equally and to push cross-desktop solutions where it makes sense.
But we will start with KDE as desktop, since the KDE team is larger (well, compared to a non-existent GNOME team, of course it is ^^)
Yes, I’ve seen the new logo on the web-site. It’s very nice, I love it! =) Still curious, though, as to how you ran across that rather obscure black-red version.
I prefer Gnome to KDE myself, perhaps because I happen to know some people deep in the Gnome project… I also know (I accidentally wrote gnow first…) they’re unhappy with how quickly Gnome developments are available to Ubuntu-users for instance, so I guess this might be an opportunity for them…. I’ll let them know about this, though I can’t promise they’ll jump right at it.
In reality, I almost exclusively use WMII these days, though. As long as I can install that somehow (and it’s in Debian, so it shouldn’t be a problem I guess), so whether it’s Gnome or KDE by default is of less concern to me… 😉
… and speaking of WMII, I notice from packages.tanglu.org that the version in the first release is v 3.10. This is AGES behind Debian stable (v3.92 in Wheezy, 3.6 in Squeeze), which seems strange.
I’ll admit to not knowing much about these things, but in your blogpost from 8 Apr you mention that there were issues when importing the Debian archives. Perhaps this very old version in your repo is an artifact from these troubles? (In which case, there’s likely to be more similar issues…)
Anyway, I guess this is something for the email lists, not your blog comments, really…