Slashdot Mirror

If target is compromised, a malicious user can run arbitrary commands through rsync.

I agree this is an issue, the best solution I have found is Push Mirroring with this the command that can be run is put in the ssh public key and then the compromised client can only run this specific command.

Microsoft has released several new updates to address your concerns.

BTW, withoug RMS, there would BE NO FOSS movement. He is the heart and soul of it. Were he to die, it would be utterly co-opted by commercial forces.

All nice distributions, but all lacking good QA.

Wherever there is a demand for paid support, you'll find plenty of people and businesses willing to provide it. http://www.debian.org/consultants/

IMPORTANT UPDATE: Please show your support for Ceren in this poll of Geek Babes!

Is it any wonder people think Linux users are a bunch of flaming homosexuals when its fronted by obviously gay losers like these?! BSD has a mascot who leaves us in no doubt that this is the OS for real men! If Linux had more hot chicks and gorgeous babes then maybe it would be able to compete with BSD! Hell this girl should be a model!

Linux is a joke as long as it continues to lack sexy girls like her! I mean just look at this girl! Doesn't she excite you? I know this little hottie puts me in need of a cold shower! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little minx. Don't you wish the guy in this pic was you? Are you telling me you wouldn't like to get your hands on this ass?! Wouldn't this just make your Christmas?! Yes doctor, this uber babe definitely gets my pulse racing! Oh how I envy the lucky girl in this shot! Linux has nothing that can possibly compete. Come on, you must admit she is better than an overweight penguin or a gay looking goat! Wouldn't this be more liklely to influence your choice of OS?

With sexy chicks like the lovely Ceren you could have people queuing up to buy open source products. Could you really refuse to buy a copy of BSD if she told you to? Personally I know I would give my right arm to get this close to such a divine beauty!

Don't be a fag! Join the campaign for more cute open source babes today!

$Id: ceren.html,v 9.0 2004/08/01 16:01:34 ceren_rocks Exp $

ORR.... stick with OS-X, and live without these apps. I mean, certainly it comes down to the fact that if you're more comfortable with one particular program or the other, you're more likely to stick with the platform to use it, but still... it's starting to become almost rediculous to try to compare any ONE package of proprietary programs (as impressive as Apple's is) with any full linux distribution, you simply get such a huge diverse set of apps with linux.

Originally posted on the debian-devel list: http://lists.debian.org/debian-devel/2004/11/msg00 547.html

My polite and nice debian stable box just sits there. I receive almost daily a mail or two telling me that I have a security problem or there is a new version of some of the packages installed. I run "apt-get update", "apt-get dist-upgrade" and everything just keeps working. No reboots, no nothing.

Of course the software in the stable branch is quite old, but still I'd like to see MS telling me what's wrong in the product they are about to push to me.

Yeah, it's a piece of piss to setup a local repository on a server and then point all the other machines to update from that, and you'll find the tools (e.g. apt-move) to do this in your favourite distro :)

GP is Yet Another Silly Windows Cluebie (YASWC).

I looked at Debian's people page, and I counted 1506 entries. These people are actively maintaining a part of Debian.

How? I grepped for "<a name=", which seems to match the correct lines. There are several "group" entries, so this number is only a rough estimate. (A group implies at least one member, but some people belong to more than one group.)

Many comments provide examples of some things to do to make you look busy (ping 127.0.0.1, etc)

This automates the issue.

Have fun.

Because it's not sticking to a fork of the old XFree86 code, and it is moving to X.Org, like other distros.

I think many of us are wondering when x.org will be added to Debian unstable. It's nowhere in the package lists for stable, testing or unstable.

I can't find any recent news regarding X.org for Debian on Debian.org, or in the FAQ. I see some discussion and debate about 7 months ago, but many things have changed since then.

Because it's not sticking to a fork of the old XFree86 code, and it is moving to X.Org, like other distros.

I think many of us are wondering when x.org will be added to Debian unstable. It's nowhere in the package lists for stable, testing or unstable.

I can't find any recent news regarding X.org for Debian on Debian.org, or in the FAQ. I see some discussion and debate about 7 months ago, but many things have changed since then.

Instead of wishing, go here and help it happen by fixing as many of the 93 release-critical bugs as you can. Once that number is low enough, Sarge will be released.

Umm, that's where logrotate is for. Yeah I know, there are some stupid vendors who don't support this out of the box, but it's not difficult to make it work with a random application.

As a sidenote, this should be modded 'clueless', not 'informative'.

That is why you can't just install Windows or Linux on a Flash card, and have it work more than a couple of days. The virtual memory gets written over and over again.

Then put 512 MB of RAM in your machine and turn off the swap file. If you're on stock GNU/Linux, you can throw in JFFS2 or another wear-leveling file system for good measure.

I would have to agree that installing a package as soon as it hits unstable is a bad idea. You can go to packages.qa.debian.org to see how long it's been since a package was uploaded, along with any pending issues with it.

No, Debian GNU/Linux. It's perfectly fine for the name of the entire distribution to be called 'Debian.' It's not perfectly fine to call Linux just Linux when refering to the Linux kernel being bundled with a distribution of software. If you are refering to the 'Linux kernel' by itself it is ok, to refer to it as Linux.

Also, you can have 100% Linux-free Debian--that's why saying Debian Linux is stupid.

I think a lot of the complaints about the GFDL are overblown. Personally, I've never even run across a GFDL'd document that contains any invariant sections, etc.

Several GNU manuals include the GNU Manifesto as an invariant section -- in fact, I can't back this up, but it certainly appears that the main motivation for the invariant section clause was specifically to prevent people from removing the GNU Manifesto from GNU manuals.

As others have said, there are quite a few onerous and ambiguous clauses in the GFDL; it's not all about invariant sections. Some of these seem to be mere bugs in the license text, rather than in the intent. Others, like the requirement to cram the whole text of the GFDL onto anything (even, say, a reference card) derived from GFDL'd works, are annoying but not necessarily non-free.

Certainly, the non-modifiable sections of a GFDL work cause the most fear and loathing. If you really think none of those problems could happen in practice, please see this message for a scenario I find very believable.

But anyway, if Debian doesn't like the GFDL, what does it like better? The CC share-alike license? Would the CC share-alike-attribution license be ok?

Creative Commons (in particular the Attribution license) seems to have its heart in the right place. Depending on whom you ask, there are a few "bugs" in that one too, but they seem to be relatively minor nits. As such, there is hope that the Debian legal eagles can negotiate with Creative Commons to iron out problems for future editions of the CC licenses. Certainly the two groups are talking to each other.

Meanwhile, there's no reason you can't use your code license for documentation -- be that the GPL, or some BSD-like thing, or what have you.

And in the meantime, what does Debian plan to do about documentation that is already GFDL'd?

Consensus seems to be that the GFDL has enough problems that even without invariant sections, it's not a free license. As such, the convenience to the user doesn't outweigh sticking to principles of freedom. Just as it did not in the case of Netscape 4.x, which was by far the best graphical web browser for Debian platforms in its day, but didn't ship with source code. If users want manuals, they'll have to point their /etc/apt/sources.list at the non-free section of the archive. In practice, including "non-free" in your downloads is really no inconvenience at all, unless you've only got Debian CDs and no net access, and the CD vendor chose not to include documentation packages from non-free. (This is something a vendor can choose to do, if they wish to take the trouble to comb through the non-free archive to see what they can legally ship at all.)

Curiously enough, practical problems of documentation are mitigated a little bit by a completely unrelated issue. The GNU Project tends to spurn "man pages" as a documentation format, so most GFDL documents are other format documents, such as info pages. The Debian Project still likes man pages, so there are a number of contributed man pages in GNU packages in Debian which were not from the GNU upstream.

I think a lot of the complaints about the GFDL are overblown. Personally, I've never even run across a GFDL'd document that contains any invariant sections, etc.

Several GNU manuals include the GNU Manifesto as an invariant section -- in fact, I can't back this up, but it certainly appears that the main motivation for the invariant section clause was specifically to prevent people from removing the GNU Manifesto from GNU manuals.

As others have said, there are quite a few onerous and ambiguous clauses in the GFDL; it's not all about invariant sections. Some of these seem to be mere bugs in the license text, rather than in the intent. Others, like the requirement to cram the whole text of the GFDL onto anything (even, say, a reference card) derived from GFDL'd works, are annoying but not necessarily non-free.

Certainly, the non-modifiable sections of a GFDL work cause the most fear and loathing. If you really think none of those problems could happen in practice, please see this message for a scenario I find very believable.

But anyway, if Debian doesn't like the GFDL, what does it like better? The CC share-alike license? Would the CC share-alike-attribution license be ok?

Creative Commons (in particular the Attribution license) seems to have its heart in the right place. Depending on whom you ask, there are a few "bugs" in that one too, but they seem to be relatively minor nits. As such, there is hope that the Debian legal eagles can negotiate with Creative Commons to iron out problems for future editions of the CC licenses. Certainly the two groups are talking to each other.

Meanwhile, there's no reason you can't use your code license for documentation -- be that the GPL, or some BSD-like thing, or what have you.

And in the meantime, what does Debian plan to do about documentation that is already GFDL'd?

Consensus seems to be that the GFDL has enough problems that even without invariant sections, it's not a free license. As such, the convenience to the user doesn't outweigh sticking to principles of freedom. Just as it did not in the case of Netscape 4.x, which was by far the best graphical web browser for Debian platforms in its day, but didn't ship with source code. If users want manuals, they'll have to point their /etc/apt/sources.list at the non-free section of the archive. In practice, including "non-free" in your downloads is really no inconvenience at all, unless you've only got Debian CDs and no net access, and the CD vendor chose not to include documentation packages from non-free. (This is something a vendor can choose to do, if they wish to take the trouble to comb through the non-free archive to see what they can legally ship at all.)

Curiously enough, practical problems of documentation are mitigated a little bit by a completely unrelated issue. The GNU Project tends to spurn "man pages" as a documentation format, so most GFDL documents are other format documents, such as info pages. The Debian Project still likes man pages, so there are a number of contributed man pages in GNU packages in Debian which were not from the GNU upstream.

Will "sarge" become "stable" under the new leader?

The DPL does not have near as much control as someone might imagine. The single most important power of the DPL is the power to appoint developers to admin positions. Debian is less of a democracy than it is a bureaucracy.

The Debian Constitution specifies how certain positions are appointed, and if you read carefully you'll see that many of these positions are completely immune to the DPL. The Project Secretary, for instance, has to agree with the DPL for a new Project Secretary to be appointed. OTOH, the Project Secretary can "delegated authority for a decision" without any outside review. They could, in fact, keep the title and appoint whoever they want to do the actual work.

The Technical Committe is another group with no meaningful outside review. The DPL can only appoint Developers to the Technical Committe when the Committe itself recommends them. If the DPL refuses to appoint the members they recommend for so long that the committe gets down to 5 members, the committe can appoint new members without any input from the DPL.

What about the other delegated positions? Technically the DPL appoints and removes these people without restrictions, but in reality his control over every single delegated position is limited. The Constitution states explicitly, "The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made." Ok, so he can't fire someone because he disagrees with their decisions. But the constitution says delegates "may be replaced by the Leader at the Leader's discretion", so what does that mean? Quite simply it means that delegates are appointed for life. New DPL's don't get to appoint new delegates. To get rid os a delegate the DPL would have to come up with precise reasons for removing them that are unrelated to the technical decisions the delegate has made.

And where do you really see this in action? The single delegate most often complained about is the DAM. He has complete veto power over who gets to join the project and can kick any developer out of the project. For up to six months at a stretch the DAM will refuse to do any work related to the position he has been delegated. In fact, it got so bad recently that the DAM allowed another developer to take over all of the actual DAM work while still remaining in the DAM slot.

And where do the unacountable delegated positions fit into the organization of Debian? Everything that Debian does gets passed through a delegate at some point. The FTP-Masters have veto power over every package. The DAM has veto power over who gets to join the project. The Technical Committe has veto power over policy decisions. And even worse than that, many of the different delegate positions are held by the exact same people. Pick a few members out of the organizational list and look at all of the different positions they hold....now try to imagine any DPL attempting to oust one of these developer from one of their delegated positions.

So....will a new DPL be able to work harder and get Sarge out the door? Of course not. They can beg or whine about it, but Debian's bureaucracy holds all the real power to make things happen. The DPL title is a little perk that core members of the bureaucracy pass around from time to time.

Don't get me wrong. I'm not trying to suggest that all of the delegates in Debian are evil people or anything like that. I'm simply pointing out that voting != democracy and DPL != control.

Will "sarge" become "stable" under the new leader?

The DPL does not have near as much control as someone might imagine. The single most important power of the DPL is the power to appoint developers to admin positions. Debian is less of a democracy than it is a bureaucracy.

The Debian Constitution specifies how certain positions are appointed, and if you read carefully you'll see that many of these positions are completely immune to the DPL. The Project Secretary, for instance, has to agree with the DPL for a new Project Secretary to be appointed. OTOH, the Project Secretary can "delegated authority for a decision" without any outside review. They could, in fact, keep the title and appoint whoever they want to do the actual work.

The Technical Committe is another group with no meaningful outside review. The DPL can only appoint Developers to the Technical Committe when the Committe itself recommends them. If the DPL refuses to appoint the members they recommend for so long that the committe gets down to 5 members, the committe can appoint new members without any input from the DPL.

What about the other delegated positions? Technically the DPL appoints and removes these people without restrictions, but in reality his control over every single delegated position is limited. The Constitution states explicitly, "The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made." Ok, so he can't fire someone because he disagrees with their decisions. But the constitution says delegates "may be replaced by the Leader at the Leader's discretion", so what does that mean? Quite simply it means that delegates are appointed for life. New DPL's don't get to appoint new delegates. To get rid os a delegate the DPL would have to come up with precise reasons for removing them that are unrelated to the technical decisions the delegate has made.

And where do you really see this in action? The single delegate most often complained about is the DAM. He has complete veto power over who gets to join the project and can kick any developer out of the project. For up to six months at a stretch the DAM will refuse to do any work related to the position he has been delegated. In fact, it got so bad recently that the DAM allowed another developer to take over all of the actual DAM work while still remaining in the DAM slot.

And where do the unacountable delegated positions fit into the organization of Debian? Everything that Debian does gets passed through a delegate at some point. The FTP-Masters have veto power over every package. The DAM has veto power over who gets to join the project. The Technical Committe has veto power over policy decisions. And even worse than that, many of the different delegate positions are held by the exact same people. Pick a few members out of the organizational list and look at all of the different positions they hold....now try to imagine any DPL attempting to oust one of these developer from one of their delegated positions.

So....will a new DPL be able to work harder and get Sarge out the door? Of course not. They can beg or whine about it, but Debian's bureaucracy holds all the real power to make things happen. The DPL title is a little perk that core members of the bureaucracy pass around from time to time.

Don't get me wrong. I'm not trying to suggest that all of the delegates in Debian are evil people or anything like that. I'm simply pointing out that voting != democracy and DPL != control.

Will "sarge" become "stable" under the new leader?

The DPL does not have near as much control as someone might imagine. The single most important power of the DPL is the power to appoint developers to admin positions. Debian is less of a democracy than it is a bureaucracy.

The Debian Constitution specifies how certain positions are appointed, and if you read carefully you'll see that many of these positions are completely immune to the DPL. The Project Secretary, for instance, has to agree with the DPL for a new Project Secretary to be appointed. OTOH, the Project Secretary can "delegated authority for a decision" without any outside review. They could, in fact, keep the title and appoint whoever they want to do the actual work.

The Technical Committe is another group with no meaningful outside review. The DPL can only appoint Developers to the Technical Committe when the Committe itself recommends them. If the DPL refuses to appoint the members they recommend for so long that the committe gets down to 5 members, the committe can appoint new members without any input from the DPL.

What about the other delegated positions? Technically the DPL appoints and removes these people without restrictions, but in reality his control over every single delegated position is limited. The Constitution states explicitly, "The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made." Ok, so he can't fire someone because he disagrees with their decisions. But the constitution says delegates "may be replaced by the Leader at the Leader's discretion", so what does that mean? Quite simply it means that delegates are appointed for life. New DPL's don't get to appoint new delegates. To get rid os a delegate the DPL would have to come up with precise reasons for removing them that are unrelated to the technical decisions the delegate has made.

And where do you really see this in action? The single delegate most often complained about is the DAM. He has complete veto power over who gets to join the project and can kick any developer out of the project. For up to six months at a stretch the DAM will refuse to do any work related to the position he has been delegated. In fact, it got so bad recently that the DAM allowed another developer to take over all of the actual DAM work while still remaining in the DAM slot.

And where do the unacountable delegated positions fit into the organization of Debian? Everything that Debian does gets passed through a delegate at some point. The FTP-Masters have veto power over every package. The DAM has veto power over who gets to join the project. The Technical Committe has veto power over policy decisions. And even worse than that, many of the different delegate positions are held by the exact same people. Pick a few members out of the organizational list and look at all of the different positions they hold....now try to imagine any DPL attempting to oust one of these developer from one of their delegated positions.

So....will a new DPL be able to work harder and get Sarge out the door? Of course not. They can beg or whine about it, but Debian's bureaucracy holds all the real power to make things happen. The DPL title is a little perk that core members of the bureaucracy pass around from time to time.

Don't get me wrong. I'm not trying to suggest that all of the delegates in Debian are evil people or anything like that. I'm simply pointing out that voting != democracy and DPL != control.

RMS plays an important part in the free software world, but he would not be suited to a role such as leading Debian. Leadership of such a project requires compromise, and RMS freely admits that he is not going to compromise his Free Software ideals (and he is right not to).

Neither is Debian. There are The Debian Free Software Guidelines. (BTW, please read them and then read the OSI's novel open source definition and compare them, I urge you.)

Debian GNU/Linux 3.0 (a.k.a. woody) was released on 19th of July, 2002.

Don't let that stop you trolling, though.

Guess that depends on what you mean by freedom. Richard Stallman disagrees quite publicly with the Debian Project in the matter of the GNU Free Documentation License the Project does not consider it sufficiently free.

Some of you will think it is heresy to regard a license from the Free Software Foundation as insufficiently free. Heresy or not, though, I agree with the Debian Project: the GFDL imposes some onerous restrictions on what users can do with the licensed work, and Stallman seems unwilling to drop some of these restrictions.

As it happens (bringing us back on topic), the first nominee for Debian Project Leader 2005, Matthew Garrett, features prominently in the above document detailing why RMS's documentation license is not free enough.

To be fair though, the entire OS isn't based on BSD--there's a bit of GNU, and a small amount of NeXTSTEP, too.

As someone who have been suggesting it for years, I am really glad that they have finally made the store. This is a much better way to support a project like this, because people are generally more likely to buy cool merchandise (like on Amazon) than to send money not getting anything in return (like lobbying). I hope a portion of the revenus stream will go towards the development of Debian GNU/NetBSD because there is a lot of platforms I want to have Debian on, and it doesn't seem that Linux--or even HURD--will be nearly as portable as NetBSD any time soon, and as a long-time GNU supporter I must admit that I say it with a great deal of jealousy and at least an equal amount of admiration. For those who are not familiar with NetBSD's exceptional portability, or those who think that their pathetic operating system (Micro$oft) is portable because it supports Intel and AMD, here is a list of platforms that a really portable operating system should support: acorn26, acorn32, algor, alpha, amd64, amiga, amigappc, arc, atari, bebox, cats, cesfic, cobalt, dreamcast, evbarm, evbmips, evbppc, walnut, evbsh3, evbsh5, hp300, hp700, hpcarm, hpcmips, hpcsh, i386, iyonix, luna68k, mac68k, macppc, mipsco, mmeye, mvme68k, mvmeppc, netwinder, news68k, newsmips, next68k, ofppc, pc532, playstation2, pmax, pmppc, prep, sandpoint, sbmips, sgimips, sh3, sh3eb,

As someone who have been suggesting it for years, I am really glad that they have finally made the store. This is a much better way to support a project like this, because people are generally more likely to buy cool merchandise (like on Amazon) than to send money not getting anything in return (like lobbying). I hope a portion of the revenus stream will go towards the development of Debian GNU/NetBSD because there is a lot of platforms I want to have Debian on, and it doesn't seem that Linux--or even HURD--will be nearly as portable as NetBSD any time soon, and as a long-time GNU supporter I must admit that I say it with a great deal of jealousy and at least an equal amount of admiration. For those who are not familiar with NetBSD's exceptional portability, or those who think that their pathetic operating system (Micro$oft) is portable because it supports Intel and AMD, here is a list of platforms that a really portable operating system should support: acorn26, acorn32, algor, alpha, amd64, amiga, amigappc, arc, atari, bebox, cats, cesfic, cobalt, dreamcast, evbarm, evbmips, evbppc, walnut, evbsh3, evbsh5, hp300, hp700, hpcarm, hpcmips, hpcsh, i386, iyonix, luna68k, mac68k, macppc, mipsco, mmeye, mvme68k, mvmeppc, netwinder, news68k, newsmips, next68k, ofppc, pc532, playstation2, pmax, pmppc, prep, sandpoint, sbmips, sgimips, sh3, sh3eb,

When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security features, which have already been implemented in the 1970s, only better and with no strings attached. Those TCPA zealots are usually completely ignorant of the existance of such operating systems as KeyKOS or EROS with formal proofs of correctness without all of the silliness.) Are there any plans to have a real capability-based security model available in the Hurd?

Debian is the only OS anyone should use.

A good discussion of this appears here. One point made is that the headers to the library may be covered by the GPL, and those headers *are* part of the application code. There was some discussion about releasing the *headers* as public domain, which may release any linked code from the GPL, but at that point you'd be better off releasing the library under LGPL.

True. Documentation for Linux is still pretty sparse in distributions.

Um. 27,000 pages of documentation (typical install) isn't sufficient? 60,000 manpages (all of Debian unstable) is "sparse?

I call massive bullshit.

Under Debian (or Debian-based distros: Ubuntu, Linspire, Lycoris, Xandros, Progeny, etc.), install dwww and you'll have a system documentation browser at http://localhost/dwww, including a menu. Oh, and search. Need more? your /usr/share/doc/ directory is also accessible. By the way, this stuff is also available online, for those readers not fortunate enough to be reading on a Debian system. The point I'm hammering home here is that the information is on the system.

Sure, but that's the raw stuff. How about books or guides? Well, there's HOWTOs (that's your TLDP, BTW), Rute User's Tutorial and Exposition, and hundreds of other docs.

Bugs? Your distro should have a queryable bug-tracking system.

PDFs suck for online readability. Web content is far more accessible, and it's somewhat ironic that manpages actually translate well to HTML (better than info pages).

Yes, I've harped on man pages a lot. Arcane, difficult to read, you have to know what you're looking for. But (under Debian), Policy requires every system executable have a manpage. What's the value in that? Well... I've watched a $50/15 min Windows consultant try tracking down processes on a suspect Win2K server. By typing the names from the Task Manager into MSIE and looking them up on Google. You want to know what something is in Linux? man command. No manpage? If it's a system command, file a bug. If it's not, you've got something to look at -- a possible security exploit. Note too that other distros and projects, GNOME and GNU in particular, deprecate manpages. This is not only wrong, but dangerous.

Your MP3 player should should show up in an apropos query: apropos mp3. And yes, users should know how to search for things, though the system should also assist in this. Though if you're not accessing the commandline:

• Accessing an MP3 file should launch your MP3 file player.
• Linux app design tends not to be format-specific as Windows tools are. Your audio player should be indifferent to MP3s, Oggs, WAVs, AUs, or other sound formats.

Hope that helps.

True. Documentation for Linux is still pretty sparse in distributions.

Um. 27,000 pages of documentation (typical install) isn't sufficient? 60,000 manpages (all of Debian unstable) is "sparse?

I call massive bullshit.

Under Debian (or Debian-based distros: Ubuntu, Linspire, Lycoris, Xandros, Progeny, etc.), install dwww and you'll have a system documentation browser at http://localhost/dwww, including a menu. Oh, and search. Need more? your /usr/share/doc/ directory is also accessible. By the way, this stuff is also available online, for those readers not fortunate enough to be reading on a Debian system. The point I'm hammering home here is that the information is on the system.

Sure, but that's the raw stuff. How about books or guides? Well, there's HOWTOs (that's your TLDP, BTW), Rute User's Tutorial and Exposition, and hundreds of other docs.

Bugs? Your distro should have a queryable bug-tracking system.

PDFs suck for online readability. Web content is far more accessible, and it's somewhat ironic that manpages actually translate well to HTML (better than info pages).

Yes, I've harped on man pages a lot. Arcane, difficult to read, you have to know what you're looking for. But (under Debian), Policy requires every system executable have a manpage. What's the value in that? Well... I've watched a $50/15 min Windows consultant try tracking down processes on a suspect Win2K server. By typing the names from the Task Manager into MSIE and looking them up on Google. You want to know what something is in Linux? man command. No manpage? If it's a system command, file a bug. If it's not, you've got something to look at -- a possible security exploit. Note too that other distros and projects, GNOME and GNU in particular, deprecate manpages. This is not only wrong, but dangerous.

Your MP3 player should should show up in an apropos query: apropos mp3. And yes, users should know how to search for things, though the system should also assist in this. Though if you're not accessing the commandline:

• Accessing an MP3 file should launch your MP3 file player.
• Linux app design tends not to be format-specific as Windows tools are. Your audio player should be indifferent to MP3s, Oggs, WAVs, AUs, or other sound formats.

Hope that helps.

True. Documentation for Linux is still pretty sparse in distributions.

Um. 27,000 pages of documentation (typical install) isn't sufficient? 60,000 manpages (all of Debian unstable) is "sparse?

I call massive bullshit.

Under Debian (or Debian-based distros: Ubuntu, Linspire, Lycoris, Xandros, Progeny, etc.), install dwww and you'll have a system documentation browser at http://localhost/dwww, including a menu. Oh, and search. Need more? your /usr/share/doc/ directory is also accessible. By the way, this stuff is also available online, for those readers not fortunate enough to be reading on a Debian system. The point I'm hammering home here is that the information is on the system.

Sure, but that's the raw stuff. How about books or guides? Well, there's HOWTOs (that's your TLDP, BTW), Rute User's Tutorial and Exposition, and hundreds of other docs.

Bugs? Your distro should have a queryable bug-tracking system.

PDFs suck for online readability. Web content is far more accessible, and it's somewhat ironic that manpages actually translate well to HTML (better than info pages).

Yes, I've harped on man pages a lot. Arcane, difficult to read, you have to know what you're looking for. But (under Debian), Policy requires every system executable have a manpage. What's the value in that? Well... I've watched a $50/15 min Windows consultant try tracking down processes on a suspect Win2K server. By typing the names from the Task Manager into MSIE and looking them up on Google. You want to know what something is in Linux? man command. No manpage? If it's a system command, file a bug. If it's not, you've got something to look at -- a possible security exploit. Note too that other distros and projects, GNOME and GNU in particular, deprecate manpages. This is not only wrong, but dangerous.

Your MP3 player should should show up in an apropos query: apropos mp3. And yes, users should know how to search for things, though the system should also assist in this. Though if you're not accessing the commandline:

• Accessing an MP3 file should launch your MP3 file player.
• Linux app design tends not to be format-specific as Windows tools are. Your audio player should be indifferent to MP3s, Oggs, WAVs, AUs, or other sound formats.

Hope that helps.

Well, I got the idea from Here, where the OSI decided to create a different definition than any of the Free Software definitions, including both the Debian Free Software Guidelines (DFSG) upon which the OSI definition was derived from and the FSF's Free Software Definition

If the weren't different, the OSI wouldn't be making up different definitions, would they?

as for the rest, I'm not talking about GUIs. I'm talking about support for the whole system.

much open-source software is already signed by the creator / distributor, so you know that the binary you got was actually made by him.

Sure, you can sign binaries. But if you give that binary to someone, and he later demands the source code from you, you'd better include the private key along with it.

Well, I was under the assumption that you had several machines to install this on. If you're making the CD for just one computer then yeah, it might be too much work. But if you're installing the same thing on 50 computers (i.e., clients), it would be worth it. Besides, Catalyst is supposed to make it "easy" to make liveCDs (but I've never used it so I don't know if that's actually true).

Although, now that I think about it, the greatest strength of Gentoo is how easy it is to upgrade-in-place, so liveCD Gentoo would be vastly inferior to actually installing it on the hard drive.

In any case, although I forgot to mention it before, there's Debian From Scratch as well....

Perhaps Debian From Scratch is what you are looking for?

I chose Debian, because it is usable both on server and workstation (and I wanted to provide help on both).

It is best to have the same distribution in whole institution, so I have unstable on workstations and stable on servers. I can have the same local packages with custom debianized software for both environments.

And automatic package management facilities are most advanced... (Think apt-get 0.6.25 w/crypto package verification, auto-apt or dlocate.)

And if debian is not for you - you can always choose debian-based distro.

I chose Debian, because it is usable both on server and workstation (and I wanted to provide help on both).

It is best to have the same distribution in whole institution, so I have unstable on workstations and stable on servers. I can have the same local packages with custom debianized software for both environments.

And automatic package management facilities are most advanced... (Think apt-get 0.6.25 w/crypto package verification, auto-apt or dlocate.)

And if debian is not for you - you can always choose debian-based distro.

I chose Debian, because it is usable both on server and workstation (and I wanted to provide help on both).

It is best to have the same distribution in whole institution, so I have unstable on workstations and stable on servers. I can have the same local packages with custom debianized software for both environments.

And automatic package management facilities are most advanced... (Think apt-get 0.6.25 w/crypto package verification, auto-apt or dlocate.)

And if debian is not for you - you can always choose debian-based distro.

I chose Debian, because it is usable both on server and workstation (and I wanted to provide help on both).

It is best to have the same distribution in whole institution, so I have unstable on workstations and stable on servers. I can have the same local packages with custom debianized software for both environments.

And automatic package management facilities are most advanced... (Think apt-get 0.6.25 w/crypto package verification, auto-apt or dlocate.)

And if debian is not for you - you can always choose debian-based distro.

http://www.debian.org/consultants/

If you had said UNIX I would have answeared FreeBSD or NetBSD. However, you asked for Linux so I guess I have to say:

Debian Linux, or maybe Debian BSD, just to be rude :P

This is in some ways similar to how Apache Software Foundation projects work:

http://www.apache.org/foundation/how-it-works.html #meritocracy

I think it's a pretty sensible way of doing things.

Compare this with the rather more beaurocratic Debian procedure for adding new maintainers:

http://www.debian.org/devel/join/newmaint

All three are certainly different projects, that require different kinds of talent and abilities, so it's likely that what works for one may not work for the others, but I think it's instructive to compare and contrast.

As far as openness, the 'meritocracy' system works fairly well if those on the inside are inclined to add others. Nothing prevents J Random Hacker from making patches or writing code. Do that successfully for a time, and you will be invited to participate.

IMPORTANT UPDATE: Please show your support for Ceren in this poll of Geek Babes!

Is it any wonder people think Linux users are a bunch of flaming homosexuals when its fronted by obviously gay losers like these?! BSD has a mascot who leaves us in no doubt that this is the OS for real men! If Linux had more hot chicks and gorgeous babes then maybe it would be able to compete with BSD! Hell this girl should be a model!

Linux is a joke as long as it continues to lack sexy girls like her! I mean just look at this girl! Doesn't she excite you? I know this little hottie puts me in need of a cold shower! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little minx. Don't you wish the guy in this pic was you? Are you telling me you wouldn't like to get your hands on this ass?! Wouldn't this just make your Christmas?! Yes doctor, this uber babe definitely gets my pulse racing! Oh how I envy the lucky girl in this shot! Linux has nothing that can possibly compete. Come on, you must admit she is better than an overweight penguin or a gay looking goat! Wouldn't this be more liklely to influence your choice of OS?

With sexy chicks like the lovely Ceren you could have people queuing up to buy open source products. Could you really refuse to buy a copy of BSD if she told you to? Personally I know I would give my right arm to get this close to such a divine beauty!

Don't be a fag! Join the campaign for more cute open source babes today!

$Id: ceren.html,v 9.0 2004/08/01 16:01:34 ceren_rocks Exp $

Sounds like pure hyperbole to me. Seems like OS development is inherently pretty decentralized.