This is old news by now (it’s been a very busy week), but Debian sarge has (finally) been released. Congrats to all involved and especially to the release managers for what I can only imagine was, at times, a seemingly impossible task (it was impossible enough in the days of a few dozen developers and a few hundred packages). Press coverage here: eWEEK, InfoWorld, InternetNews.com, ZDNet UK, and various other places too.
Now what? If you ask me (and you didn’t, but I’m going to tell you anyway), Debian should have two overarching priorities for the next release: 1. putting a timed release cycle in place, so what happened with sarge never happens again; and 2. keeping the growing family of Debian derivatives united around a common core—namely, Debian itself. What’s at stake? Bottom line: If we don’t do something about both of these problems, actual and potential, Debian will be irrelevant by the time etch is out.
Debian is one of exactly three Linux distributions that have global reach today (Red Hat and Novell/SuSE are the other two). In terms of mindshare, userbase, and almost everything else that matters, Debian is a strong #2, well ahead of SuSE in most places (even, it appears, Germany) and behind Red Hat only in the U.S. and perhaps a few other (albeit important) places. SuSE is often thought of as the #2 in commercial circles, but this is mainly because the industry isn’t quite sure how to interface with the real #2. Until it figures out how to do that (hint: we should be helping), the industry needs an alternative, any alternative, to keep Red Hat honest. Not exactly the strongest market position, and it’s beginning to show too. Unequivocally, this means Debian’s potential is enormous; unfortunately, a big part of that potential remains untapped.
How, then, do we tap it? Let’s start by looking at what makes Debian unique.
First of all (and this is the obvious part), Debian is a non-commercial, community project, which means it isn’t owned or controlled by a commercial interest. As such, Debian is an embodiment of what made Linux what it is today: openness, vendor neutrality, and community. It’s a reminder of where we all came from. It keeps the industry honest. Or, in the words of IBM and HP executives, it’s “the core of the Linux community” and a vendor neutral “arbiter… to make sure everybody plays nice”. Sure, Debian isn’t entirely unique in this respect (there are, after all, other community distros, most notably Slackware and Gentoo). However, combined with its popularity, Debian’s “non-commercial, community project” status makes it a force to be reckoned with. In other words, Debian may not be the only global player, and it may not be the only non-commercial, community project, but it’s the only global player that’s also a non-commercial, community project.
Second, Debian is less an operating system and more a collection of compatible software. (Note the word compatible—that will be important later.) Red Hat, SuSE, and the other distros are much more like traditional operating systems: monolithic, vertically integrated, one-size-fits-all products. Because Debian is modular by design (it had to be, or it wouldn’t have been possible to subdivide the work amongst many distributed developers), it’s an excellent foundation for “value added” Linux distros, and we’ve seen numerous of these distros emerge over the years: Corel, Stormix, Progeny, Linspire, Xandros, KNOPPIX, LinEx, Skolelinux, MEPIS, and Ubuntu, to name but a few. In fact, it’s safe to say the vast majority of all distributions today are derived either from Debian or from Red Hat, and because the Red Hat derivatives have long ago splintered into many different and incompatible varieties, it’s also safe to say Debian is truly unique among distros not because it’s the basis of so many derivatives, but because those derivatives are, after all these years, still compatible with each other.
Debian’s popularity as a base distro goes beyond technology. In many ways, Debian facilitates the Linux equivalent of “think globally, act locally”. With Debian, governments and nonprofit organizations can launch projects like LinEx and Skolelinux that focus on meeting local needs the big vendors might not otherwise have the capacity, expertise, or interest to address, yet do so in a way that connects them into a larger, global community so their local focus doesn’t make them an island. Companies like Progeny, Linspire, and Ubuntu can build upon the strength and momentum of an open, global platform, allowing them to focus on bringing new and innovative products to market without fear the underlying platform vendor that makes it all possible will go out of business or, worse, be acquired by a competitor. In short, because Debian allows organizations of all kinds to “stand on the shoulders of giants”, Linux is making inroads into geographies and markets that would otherwise be underserved. Would Red Hat or Novell have been interested in cornering the market in Extremadura, Spain? I doubt it. Yet Linux is changing everything in Extremadura, as it is in a lot of places.
To me, these observations point the way to an answer to our question. First of all, we need to make it easier for the industry to interface with us. That means we need a predictable release cycle, one that results in a new Debian stable every 12 or 18 months. It also means we need to take the industry’s needs seriously, which in turn means we need to better engage the ISVs, IHVs, and OEMs that want to support Debian but aren’t quite sure how to do it. They want to engage us, not just because we’re a global player, but because we’re a non-commercial, community project. Yet when I bring this up in Debian circles, the reaction I almost always get is similar to the following: “Why do we need <insert proprietary application here>? We already have <insert open source alternative here>.” The answer is simple: we need it because a lot of our potential users need it (or at least think they need it—why argue with them about that?). Fortunately, there’s an existing effort that already enjoys broad industry support whose sole mission is to provide a single, vendor neutral ISV/IHV/OEM interface to the Linux world, namely the LSB, so we don’t have to go it alone here. All we have to do is work more closely with the LSB folks. Let’s face it. Our track record to date with the LSB hasn’t exactly been stellar. Let’s change that and work with the LSB to make Debian a vendor neutral implementation of the LSB standard. It’s got the mindshare, userbase, etc. to make a reference implementation a reality and give the LSB some real punch.
Second, we need to tap into Debian’s most unique asset, namely the collective power of the Debian derivatives. On their own, the derivatives aren’t significant players; but, taken as a group, they dwarf the individual leaders (Red Hat and Novell), and they’ve got breadth a single company couldn’t dream of having on its own even with billions of dollars of cash to market vertically oriented solutions or open hundreds of branch offices in different parts of the world. Debian’s opportunity, then, is to connect the derivatives into the powerful, global force they have the potential to become, to nurture a sort of “network of peers” approach to service and support to replace the traditional, vertically integrated model that’s being used by today’s leading commercial vendors. Of course, this opportunity can only be recognized to the extent the global fabric that connects these local communities is strong, and it cannot be strong if we don’t have a common, compatible foundation. Predictable releases are a requirement, because in the absence of a common, compatible foundation that has a clearly articulated roadmap, each of the derivatives will necessarily have to go its own way, something that, in my opinion, is already happening. We need a commitment on the part of the derivatives to work with the larger Debian community and make sure fragmentation doesn’t happen. Personally, wearing my Progeny hat, I’m willing to make this commitment, and I hope my peers at the other Debian derivatives are willing to do so as well.
Anyway, those are my thoughts. Take them or leave them, but please at least consider them.
Perhaps Debian should not “release” anything. Imagine if Debian limited itself to only testing and unstable and the versioning was left to the Debian derivatives. Ubuntu and others have shown this model can work.
Standardize
As a Debian user I feel that some things needs to be standardized more than other. Service handling for intance.
Some services have STARTUP=”no” in /etc/defaul/service and doesn’t start even though symlinks are present in /etc/rc2.d/. Let’s do something like Apple and refresh the service management.
Most init scripts also have lines like
test -x /usr/sbin/program || exit 0
exit 0 doesn’t really make it, imho
System logging is another example. I don’t see the big difference between /var/log/syslog and /var/log/daemon.log , as there are a lot of the same entries in both logs. It’s not very easy to filter out what you want when logging is handled like that.
User defined configuration is another thing, but I’ll save you from blog spamming for now:-)
“Me too”. I hope Debian will listen.
Ryan, I think that would be a big mistake. I think many of the problems with the sarge release were that packages had drifted so far from a releasable state, because there’d been no release on the horizon. Regular releases mean that people who are writing software on top of debian can structure their schedules around a release, and in turn, around the releases of other projects in the same boat.
Ian,
I think an annual release is reasonable, but I think some thought should be given as to the details of an annual release.
– For servers, I need to know the kernel I’ve got is reliable.
– I need to keep the systems patched and running.
– Change systems as users need changes.
I do -not- need to upgrade everything every 12 months. This is a serious threat to my fragile sys-admin peace of mind.
I suggest a biennial (every -other- year) kernel and core packages (ex. minimal install) upgrade with non-core package upgrades annually.
Benefit: You get to participate in the annual “new” hype-fest and don’t change at the expense of stability.
Benefit: The kernel gets the attention to detail (re: security & stability) it needs for production server use.
Benefit: Desktop users can use the latest eye-candy.
I don’t know anything about the inner-workings of the Debian community, so I’d love to hear how you think an idea like this would be received.
There is an excellent product called zenlinux that is based on debian.
What makes it very special is that it isn’t just based on debain but it *is* debian, as in, fully compatible with debian. Compatibily with repositories etc… It just has a far nicer installer and the ability to boot live.
I wish others, such as ubuntu etc, woul track with and work with Debian more closely. having seperate repositories is the biggest problem around.
Maybe just have the sub distro track time when “unstable” is in a very good state, and make a release based on it. Zen has a zen -upgrade command that does something similar, upgrading to the version of every package specified by zen, but doing it from debian repositories.
It is a wonderful system, and although very early in development, it already works amazingly well.
It also has automatic remastering, which means yo can change it in any way, and make a new installer cd using the “zen -remaster” command as root. Then you just burn the iso.
I started contributing once I realized what a great thing that was. Zen could use your help. Maybe with some community support, Zen could even become an official part of debian.
Dear Ian,
i just want to say that one of the greatest strenghts in Debian is it’s long release cycle for “debian-stable”. Every 3 years is very good!! That’s one of the reasons some people buy RH or SuSE.
If Debian would _commit_ to a _steady_ 3 year release cycle (and another half-a-year of updates for the “old-stable”) I’m *sure* some vendors would even start supporting Debian with drivers, at least for server-class equipment. Really! Talk to them, they will ear you and they will be glad ;)
Vendors are lazy, in the sense that they don’t want to have many people working in support/having training that will only last 1 or 2 years. Vendors support the “enterprise Linux” distros not (only) because of commercial agreements, but because they last for 5+ years and that makes them save money and please the customers with a quality and stable solution.
Release cycles of 6 or 12 months are not acceptable for the enterprise. (period)
If you want to humor the desktop/home users with the latest puzzle-bubble please do that without hurting the *only* stable and Free alternative that’s not based on RH or SuSE solutions.
(Maybe a new branch, in the form of 1 or 2 CDs with a good-enough “debian-testing” updated every 3 months and apt-get’able? Something like “debian-desktop-2005-q1, q2, q3 and q4?)
Hello All,
Just installed my first Debian, sarge, and have tried RH, Suse, Knoppix, Xandros, DSL, FrugalLinux, etc.
As a new user, it will take some getting use to Debian but I like the Debian philosophy and will try to use it as my regular Linux.
We’ll see.
I agree with Michael that for servers an upgrade every 12 months isn’t necessary.
For myself, I’d like the following:
1. Debian Server (Lets give users a term they understand)
Server would be the longer lasting edition; well tested etc. It may also only include server type app’s, including GUI management app’s etc.
2. Debian Desktop (Once again something users understand)
Desktop would release more often (12 months is reasonable) and have more up to date packages a-la Ubuntu, Knoppix et al.
Possibly these two editions would be maintained by (somewhat) separate groups, as most of us have a preference for one of more stable or latest app’s.
Server could take the Desktop codebase maybe 6 months before a release of Server is due & tune it till it’s bug free enough for server use.
Then there could still be “Testing” or “Unstable” for those who like the bleeding edge & 50 meg’s of updates every day or so.
And I wholly agree on the Debian derivatives sticking together, or it may all fall apart (United we stand etc.). Ubuntu developers take note. Why on earth do you have to change your package names?
My 2c.
Agree with Adrian that renaming to “Server” and “Desktop” is a good idea. So many people think that “unstable” means that it is likely to crash! That problem goes beyond Debian – we need some new terminology.
Please stop talking about LinEx and Linux in School in Extremadura.
I’m from Extremadura, I’m a Debian user, I have many students and teachers in my family … and all of them hate Linux. And LinEx is to blame for this.
Go pick 10 non-technical people and explain you want to give them “unstable” and see how many take it.
It looks like a server and desktop tier is required. Keep is simple and rock the structured folks boat a bit. Just change the names.
Also, and perhaps most important, if it weren’t for Mepis most newbies would know what debian can do. A live CD with installer is worth a thousand words.
Why not have a debian sanctioned Live, easy instalable DESKTOP debian. A whole new team could work on it but it would be Debian. It would plow the road toward acceptance and standards. It could give hardware makers something get behind.
The focus of this new debian would be ease of use and it could then provide a preset base hard drive install (changable) giving true time saving real world usefull benefits. Benefits where no other OS benefit is left behide and new Debian GNU/Linux benefits are realized (in 20 minutes or less!).
Debian greatests strength is that is Free as in freedom and not dependant on any companies. This is our major advantage over other distros. It will became more important in the future as the are no other serios community GNU/Linux. Also when Linux is growing in the third world rabidly it’s only fair that they can choose freedom. So this side should be more focused.
What comes to releases, mayby it’s time to rename Testing to Desktop Debian, but at the same time keep stable also (for servers and desktop for schools/workplaces).
Some excellent ideas presented here. Regardless of exactly what happens, I have faith in the Debian community to continue to provide (IMHO) the best Linux experience available. Having used Debian for years (and tried all the others), I know it to be the most flexible, well-tested and often easiest to configure distribution (all depends on that documentation, folks). Renaming stable/testing/unstable sounds like an excellent idea for “newbie” clarification; something like server/desktop/longhorn (just kidding) would give a better impression while reflecting common usage.
I think setting a yearly release date for desktop and sticking to every three years for server would be perfect. After about a year of a new stable is when I find myself starting to hunt the testing packages for the new stuff on my desktop, but I know I still want my servers running only stable.
Focussing more on the LSB would be a very good idea. It would allow ISVs the confidence of knowing what target they are aiming for. And as far as the Office-type apps, I think they are sufficiently “there” that we no longer need to worry; it’s user apps that are critical at this point: games, educational titles, accounting, etc. I know Debian has an educational branch, but the quality of those games needs to match up with thing like Broderbund or The Learning Company puts out — even one or two titles would make a huge difference. The same goes for games — a couple of them are really excellent, but most seem to be little more than “solitaire” mentality toys.
As a last side note, Debian support needs a bit more finesse. I’ll gladly help out with documentation and possibly some live support over IRC, but what exists now is perceived as being elitist. Users seeking help tend to get “abused” if they haven’t read the entire manual first, or searched all known Google sites for their own answers. I know no one wants a idiot behind the keyboard, but handling these people more tactfully would improve Debian’s image, making the entire project appear more professional.
All in all, excellent work has been done with Debian. To keep the #2 spot — or become #1 — more focus on the users is critical, it’s that simple.
Ian,
I agree with most of what you have said.
If I take MS Windows for example, I install it and whatever software and it goes or doesn’t as the case may be.
Linux on the other hand, there are as many distributions as there are types of user. I started out with Red Hat, then SuSE, possibly Corel I don’t remember, followed by Knoppix, Debian, PDDE etc.
Linux I keep reinstalling, changing distribution looking for the best and greatest and to be honest not getting anywhere in a hurry. I am user not a programmer, yet in my time using Linux since late 1998, I have spent more time with my head under the bonnet, than with Windows.
My current installation on my old PII Laptop is Debian unstable, it doesn’t do everything, but does most of what I want, what has sold me on Debian is apt and synaptic.
In my mind choice is good, distributions for specific needs also, but at times I wonder if we are not all trying to reinvent the wheel and therefore smothering creativity and innovation and going no where quickly.
That’s my 2 Euro cent worth.
Michael
I’m glad Ian still sees such potential and growth in Debian, and agree with his assessment of its strengths and weaknesses. I’d just like to nitpick a pet peeve of mine: “we need [insert proprietary application here] because a lot of our potential users need it.” I think chasing after potential users can be a mistake: from my perspective as a GNOME outsider, it appeared as though that project chased away some of its user base by making significant changes in the pursuit of new users. But perhaps a vocal minority skewed my perception.
In summary, I would prefer to please existing users than attract new users, when these goals are incompatible.
I don’t see why LSB is important. Oracle, for example, will never run on some arbitrary system, even if that system supports LSB. Oracle has zillions of little hidden dependencies on Red Hat particulars. LSB is not enough to get Oracle. The EDA industry has also standardized on Red Hat, not LSB.
Furthremore, when LSB does something truly bone-headed, does Debian need to follow them down that path? LSB has managed to specify a C++ ABI that was 1) never shipped with any major distribution, and 2) already obsolete. This does not seem like a bright move, and I’d rather not use a system that sacrifices technical excellence on the alter of binary compatibility.
Anyway the LSB’s goal is to enable the use of proprietary software on Linux. I’m not sure that’s in the best interest of Debian users’ future in the long term.
Debian is at a juncture and is facing the exact same dilema that Redhat faced and solved approx 2 years ago. Server admins want long release cycles and mature stable code. Desktop users want the latestest and greatest – features features features!
I feel that Debian is being torn and the best solution – let it happen! There really needs to be a Debian Server (DS) and Debian Desktop (DD) releases – just as there are Redhat Enterprise Linux and Fedora Linux. Two competing needs both satisfied. I’d recommend 18month release cycles for Debian Server and 6 month release cycles for Debian Desktop. Debian Server could target every 3rd Desktop release, and that desktop release would be one that’s been in the wild for several months.
The server admins would benefit greatly from having the desktop users hammer bugs in the wild for half a year before DS is put together for release. So c’mon Debian – Redhat figured it out – time for you guys to stop navel-gazing and figure it out also!
Ian,
In order to satisfy a wide range of users, you need not just a frequent regular release cycle but also support for key packages of older releases. That way people can opt to be on the bleeding edge or only update every three releases, all while using the same distribution.
We tried really hard a couple of years ago to use Debian but it just wasn’t up-to-date enough for modern server needs (e.g. LVM over MD). I’ve used V7, Xenix, SVR3, Minix, Slackware, and Redhat. Right now we’re busy migrating servers and workstations from Fedora to Ubuntu.
I hope Debian survives and prospers.
–Mike
There is a lot of loose talk here about long release cycles for server Debian, but I don’t think the Debian volunteers would be that interested in maintaining ancient, out-of-date software. That is incredibly boring work that only paid programmers for commercial companies would be willing to do. Remember, virtually all the Debian volunteer effort has gone into packaging new versions of software for unstable for the last three years and has not gone toward fixing bugs in the stable version. So I am all for an annual release cycle for Debian with security support guaranteed for at least a year, but in my view if businesses want just bug-fixed server software from some old Debian version with absolutely no new features, they can pay a commercial company to provide that service.
> [the industry] want to engage us, not just because we’re a global player,
> but because we’re a non-commercial, community project.
Indeed. Debian’s focus on free software and actual users is a huge strength.
> Yet when I bring this up in Debian circles, the reaction I almost always get
> is similar to the following: “Why do we need application here>? We already have here>.”
If that’s the answer you got, what was the question? You seem to be assuming that a question about industry wanting to engage Debian necessitates wanting proprietary applications.
The industry have clear guidelines for how to engage us: work on free software.
Jeff Baker wrote:
> Oracle has zillions of little hidden dependencies on Red Hat particulars.
I run two production Oracle servers on Debian Sarge at work just fine. Our DBA manages it with his windows tools just like he does all of his other Win2000-based Oracle servers.
I think you’re right that Debian absolutely must have a more predictable release cycle in order to keep the “Debian and derivatives” community together. If Debian “never” releases (either testing+stable only, or unpredictable multi-year cycle) then I think we’ll end up with a large set of mutually inconstent snapshots of testing, and much of the benefit of being based on Debian will be lost.
As a mainly server admin (I look after several dozen Debian servers spread over half a dozen or so organisations) I tend to agree with others that a 6-month release cycle is too frequent to be updating production servers. (OpenBSD do 6-month calendar-timed releases, and I usually only upgrade the OpenBSD systems I look after every second release. Sometimes even less often because of the effort required to get the downtime.)
But on the other hand, releases every 2-3 years are clearly too infrequent. With Potato, and even more so with Woody, I had an insane number of backported packages on my “stable” servers (in some cases around 50% of the packages on the servers were backports), and it was getting unworkable. In most cases these backports were driven by “business needs”, particularly for application support – new MTAs, AS/AV packages, newer database packages, new application environments (eg, Zope), etc, etc. And no amount of “we’ll release when it’s ready” will wish that “business need” for applications based on newer libraries, etc, away.
My personal feeling is that the ideal release schedule — at least for the systems I manage — would be once per year, pretty much to a calendar schedule. With production quality support for another year. And ideally some sort of “legacy” support for another year (ie, total of 3 years). I’m still supporting one RedHat 7.3 system, and much as the Fedora Legacy project has struggled, it’s been extremely valuable to have even that legacy security support available.
I suspect the combination of that sort of predicatable release cycle, which hopefully deriviatives could track in some manner, plus some clear point of contact between the project and commercial organisations would make it much more feasible for Debian to continue to be #2. Without it, I tend to agree that the “Debian universe” will fragment in the way that the Redhat deriviatives have (ie, to being pretty much complete separate now, apart from the ones that are basically RHEL-recompiled).
Ewen
Pingback: Grafika No. 2 » Blog Archive » debian now what
Simply well said. Are they listening? I hope!
I agree that there should be more frequent debian releases, maybe once every 18 months. As a sysadmin, IMHO, debian should concentrate more on LSB.
A seperate Debian desktop/server is a bad idea, there is a lot of other distributions that fill the role. Progeny CL, ubuntu, linspire etc to mention a few. Debain already has package maintainers working towards optimising specific packages for desktop or server use. Colin Walters desktop work comes to mind. (http://web.verbum.org)
Splitting the distro is a bad idea because it’d only increase the complexity and maintenance aspect of the current release cycle. Moderately frequent release cycles working towards LSB complaince may be beneficial for debian as it may reduce the need for backports.
I liked Ian’s article. I like most of the comments. I did however find one bone to pick.
Mandrake (or as it is called now: Mandriva) has a rather large share of the market. Enough market share to be profitable, and the ONLY for profit Linux company to actually be making money. Red Hat has not “made” money at any time in its’ history save many years ago on its’ IPO (sotck offering).
SuSE also bleeds considerable amounts of money.
Mandrake/Mandriva was poorly managed too, for a short while several years ago. It ended up in French bankruptcy court, but has for the last year or silightly longer turned a true profit, based on their sales and support services. Again, none of the other Linux distributions mentioned has done that. The two Ian picked are essentially dot.com babies that are living off their influx of “unearned” income (so to speak).
I think Ian’s article would be more accurate and infomative had he also included Mandrake not just because it is the ONLY large Linux distribution that “makes a profit”, but because it IS a large distribution in numbers of users as well.
Personally I use and.or maintain about 10 distributions on a regular basis. None of them is a Debian or Debian derived distribution. One of them is a Red Hat/Fedora derivative. And one of them is Mandrake/Mandriva. Which is to show that while Debian *IS* a major distribution, there is room to talk about more than just Debian and its’ derivitives, Red Hat and its’ derivatives, ESPECIALLY if one is trying to make the point Ian is trying to above.
Finally some markets rate Mandrake/Mandriva no. 2 behind Ubuntu. It may not be the market analysis Ian used, but often it is hard to gauge these things accurately, especially when it comes to business markets using Linux when commerical and non-commerically oriented distributions are being compared.
Anyways, as always, very best regards;
Bob Finch
I think the issue of how often to release while trying to address the needs of all users (eg server and desktop) can be solved simply with how long security support will be available. Ie– have a 12 month release cycle, but 24 months of security updates. Let the users decide on how to upgrade. The debian security people would obviously need some help– but they have already committed to 12 months of security support for woody, so maybe everything they need is already there.
I was the one that suggested the longer release cycle for server-related stuff near the top of the comments.
Based on ensuing comments, I agree that it might not be such a wise thing now.
– The Debian community would likely want to move the platform forward with new and interesting things, not concentrate on bug fixing. That would keep it interesting on a volunteer level.
– Providing a longer release schedule is too limiting. Towards EOL of the “stable” version it gets much less attractive to users because of hardware and package limitations.
– A longer security support phase is not so exciting for the volunteers. They want to work on new stuff too.
My question:
Let’s say the community goes to 12-month releases, would a sysadmin pay (red hat prices) to keep a Sarge server patched and perhaps include a few newer packages after 2006? Or, does free-as-in-beer make it a null point?
Debian needs to think more from corporate prospective. Customers tend to stick to corporate vendors for support and service. Corporates are going to support Debian only if it agrees to work together.
An example would be better:
XYZ releases a new feature in its hardware for which it has the patch readily available. Given the time the patch requires to be accepted upstream to the kernel, Debian needs to have an accountable team which could work closely with corporate entities to “verify” and include those patches in the release.
I know it is something difficult because there isn’t any “single point of accountable contact” as such, but if this can be sorted out I guess Debian would rock.
Pingback: Ian Murdock’s Weblog » Debian: Para onde devemos ir a partir de agora
First, sorry my bad English….
In my opinion, it’s important continuos with just one Debian with a cycle, like 12 months, of new releases.
Debian is going to be a big base distro, because this, we need a more regular releases, or we gonna be another Red Hat, a big Disto with no compability with
his sons. This is important, because with a lot of different distros working together, all of the distros, for especific applications, will develop all he community.
Maybe a revision of the way that manteners make, test the packages is the solution.
I think that Debian has a good future.
The names of the release levels is important. While using the names of the toys is cute and fun. Debian has matured far beyond being a geek’s toy. We need something more akin to the phrases the commercial world uses to market their offings. How about something like Debian Proven, Debian Working, and for the least stable, Debian Workshop.
If preferred the order of the words could be reversed.
Proven Debian, Working Debian, and Workshop Debian. Yes that’s better. And the unstable Sid might be “The Debain Forge”.
Wow, did I read that right?— debian.org didn’t ask Ian Murdoch for input into where Debian should be headed?! I am a clueless newbie, but I just read “Rebel Code”, so I know who Ian is and can see the irony here.
I have a comment/appeal which might not fit in very well with the general tenor of this blog, but which is related to the question of where linux in general and Debian derivatives like Mepis in particular should be heading.
I am a linux home user (for just under a year), not a developer– in fact, I’m still a more or less clueless newbie. As a would-be security-minded home user of linux, I want to try to express my (paranoid?) needs to developers, especially anyone thinking about devising a new live CD distro similar to Mepis.
Here in the US, during the past few years I have seen considerable coverage in the mass media (newspapers, local and national TV) of stories involving computer security, spyware, ID theft rings, nation-wide private sector “intelligence dossiers” [compiled by companies like ChoicePoint for marketing and credit-checking purposes] on individual citizens, and various other privacy concerns. I tend to see these as related by a common theme of corporate/government indifference to the individual rights of the hapless consumer/citizen, and I tend to see Open Source as one of the few developments opposing technopolitical trends favoring Big Whatever over the individual. Does this media frenzy reflect a genuine and growing public concern? Or only mass media outlets trying to increase their own profits by frightening the public and thereby increasing readership/viewership? I don’t know, but assuming the former, it seems to me that there is a niche which I fervently wish some fine person would rush to fill with an Open Source solution.
Namely: providing an easy to install but moderately (highly?) secure system for the home user, particularly someone like myself who is quite willing to trade off inessential luxuries for better security. The distros I’ve investigated (including Mandrake and Mepis) have been disappointing in that regard.
Gripe number one: I haven’t yet found a distro which goes out of its way to help the user to install some kind of integrity checker like Tripwire immediately after installation. Yes, I do not doubt that any moderately knowledgeable user can do this in minutes, but -I- wasn’t able to do it! Maybe I could do it now that I know more, but what would be the point? From everything I’ve been reading, this is an extremely basic and essential step, but it needs to be performed immediately after installation. But none of the distros I’ve examined seems to facillitate this step for an utterly clueless newbie, despite advances (e.g by Knoppix) in hardware detection and other essential aspects of autoinstallation.
Gripe number two: via Distrowatch, I’ve been scanning the basic installation instructions for various distros for some time, but have yet to find any which I as a cautious newbie consider to be sufficiently helpful regarding the proper order of operations. For example, I have gradually become aware that as a basic part of good security practice, some kind of physical firewall is needed for rudimentary protection during the download and patching of a new install. (Certainly true for Windows, or so I am told, but I anticipate this will increasingly be true for linux as well.) Routers need not be expensive, so why not advise the new user to obtain one along with his/her box?
Nor have I found a set of instructions which clearly explains for the newbie exactly how to use tools like apt-get! (E.g. briefly explaining the role and possible flaws in signatures whether the user needs to make any special effort to obtain a various desirable feature such as signature checking, etc.) This baffles me, since I am vaguely aware that apt-get is one of the most powerful features of Debian derivative distros. My own (munged?) Mepis installation can only rarely use apt-get successfully to install new packages, either from the command line or under kpackage, and I still don’t know enough to intall packages I want “by hand”. (I know this isn’t the place to ask for help on this, I am just trying to explain my so far unmet needs.) Even worse, it is still not clear to me that I am even successfully updating or patching the packages I -was- able to install. (E.g, I tried to tighten permissions, and this might have broken the functionality of apt-get.) Has anyone considered creating a package whose sole purpose is to help the newbie to more or less directly check that apt-get really is updating or applying patches correctly, in the context of something like a Mepis installation?
(I could make similarly complaints regarding rpm and Mandrake type distros, BTW.)
Gripe number three: the Mepis basic install seems to break all the rules of good security practice, as expressed in the books I’ve been reading. E.g. starting with minimal permissions/packages/services and adding more as you decide you really need them. The distros I’ve tried seem to assume the home user either doesn’t care at all about security, or else will proceed in the opposite direction, by progressively -removing- permissions/packages. But I found the latter is a -terrible- strategy for a newbie, because a newbie can’t be expected to have any idea what “perl” is or why removing it might break other stuff he/she knows that he/she does want to use.
(Again, similar remarks hold for Mandrake.)
Gripe number four: prices for hardware continue to decrease, and here in the US (and I believe also in the UK and many other places around the world) you can obtain a “bare bones” box with 128 MB memory for US $150. Has anyone else thought about setting up a two box system, with a downstream box having more RAM and production tools like compilers installed, with more permissive permissions in the interests of usability, and the upstream box having much less RAM and the bare minimumof packages installed to run an IDS and/or perhaps a suitable logical firewall in lieu of the router (which might be used only during the initial installation and patching), in the interests of security? Or even having the upstream box run off a live CD to prevent easy tampering with system utilities?
What I am trying to say is that from what I’ve been reading, I have the sense that even two boxes should enable the home user to divide up functions between the box on which one does most “work”, where security is compromised in favor of features, and the box reponsible for IDS and system logging, where features are decreased in favor of security.
The idea I am struggling to express here is that perhaps a modest alteration of the “default concept” of what the average user’s home system might look like could -greatly- increase the security of the “average home system”, -without- greatly increasing cost or decreasing speed and convenience. At the very least, a two box configuration might make it easier for newbies to use security tools originally developed for sysadmins of large systems.
My hope would be that a sensible security philosophy like this could be incorporated into the next generation of live CD distros, and would be no more difficult for a clueless newbie to set up than say a basic Mepis installation.
I anticipate that many readers will feel I am excessively paranoid. Maybe so, but even lunatics have needs, yes? And what is paranoid today might not seem excessive tomorrow.
I fear that developers of contemporary distros may be failing to look a few years into the future and see that at some point, enough people will have personally experienced ID theft, estalking, or something horrible like that, to appreciate that the consequences of losing control of sensitive information can be so dire that taking considerable pains to prevent this is well worth anyone’s time. If so, in a few years, the general public may be much more willing to accept minor inconveniences in the interest of better security than is presently the case. If so, it seems to me that it is not too soon to start developing much more secure basic home installs for linux.
Any comments? (Use small words, please! I don’t really understand the jargon very well at all, as you might have noticed.)