Slashdot Mirror

Just take a brief look at this list.

http://www.debian.org/users/

the debian that can be installed in 40 minutes is not the true debian.

Debian was NEVER supposed to be "difficult to use". This is something that has happened with the time - other distros became desktop-oriented and debian kept being power user-oriented.

It just happened, but that doesn't means that you shouldn't be able to install debian in 20 minutes. From the Debian social contract

4. Our priorities are our users and free software: We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments.

Debian users are asking for an easy to install/use, desktop oriented distro. The Debian project is just not providing such thing, so they go and choose other distros that actually listen to them, like ubuntu.

http://www.debian.org/vote/2007/platforms/sho
(it seems his spiffy website was recently redirected to debian voting page)

Although there is no *remote* exploit in the Linux *kernel*, there is a distribution that has a remote root exploit.
http://www.debian.org/News/2006/20060713.en.html

That's understating. When my Compaq V2000 arrived it was absolutely fettered with junk that filled nearly 20 gigs of the HD. A smooth reinstallation--careful to update drivers and not actually run vendor installs which often dump on the crapware--had the XP install to around 2 gigs and system performance was much more responsive. Not that the responsiveness of the XP install was the main point. The main point was to take back the HD space for LFS and Debian.

Precisely. The glibc update to fix timezones was pushed out on February 18, according to debian.org.

Give the Debian Popularity Contest a shot. It's an opt-in thing that reports what packages you have installed back up to a central server, which then produces stats on the popularity of packages. This won't necessarily tell you what package is *better*, but it will tell you which one is more widely used (and hence probably more supported).

http://popcon.debian.org/

I agree that different packages that do roughly the same thing are sometimes hard to compare without installing all of them to try out (and who really wants to do that?). What I tend to do is check their buglist, and if I'm still curious, there's a beast of a list ranking how "popular" each package is. You can get a gist for how many other people installed and have used certain packages (or files in them). Of course that doesn't have to correlate with quality, but quality is usually a subjective measure based on one's own needs.

I agree that different packages that do roughly the same thing are sometimes hard to compare without installing all of them to try out (and who really wants to do that?). What I tend to do is check their buglist, and if I'm still curious, there's a beast of a list ranking how "popular" each package is. You can get a gist for how many other people installed and have used certain packages (or files in them). Of course that doesn't have to correlate with quality, but quality is usually a subjective measure based on one's own needs.

My recommendation for today is tzdata - I upgraded/installed this on several servers today to address the DST issue. Apparently it used to be part of the libc package in sarge, so you might look at updating that instead if you're a die-hard sarge user.

Bug reports are actually sent to bugs.debian.org
ATM there's only 72 rc-bugs to be squashed before Etch will be ready (Debian-installer rc2 will be out soon too). Soon enough the most stable Linux distribution ever is released. Thanks to all debian developers around the world.

Just to make things clear, this isn't an official Debian project webpage. The debian.net subdomains are available to Debian Developers to do their own thing, and occasionally sites will migrate from debian.net to debian.org, if they get accepted by the community as "official". Debian Planet started out this way, at least.

Get your software packaged by Debian

How? I have two floss projects that I would like to do that with. Got a link?

Yeah, like Linux never loses mail. One of the grave RC bugs of Debian Etch has been bug 321102/332473/350851 where KMail will nuke your disconnected IMAP folder under certain conditions. It's closed now and due for archiving today, but they're still listed here. I haven't been checking Thunderbird, Evolution but I doubt they're a symbol of perfection either. Wouldn't you just love to have some smug Microsoftie drop by your support thread to spread the One Microsoft Way?

Here you go.

So, we should be pronuncing it like "etch"?

Won't that be confusing in a couple of years?

Here's the interesting thing: it does not really matter anymore, if all we care about are other interpreted, programmer-friendly scripting languages.

If we're concerned about using this against Perl, Python, PHP, Smalltalk or Ruby, using the great language shooutout benchmark*, Java is about on par, if not better overall based on CPU time alone.

My understanding of the jvm, which may be flawed, is that it first interprets the bytecode and eventually gets around to compiling it into native machine code - meaning that over the life time of large apps it has a negligible performance hit. So, in theory, Java can only ever be, at worst, as slow as any other interpreted language.

This is something we've come to accept; linux installers are built on python, large websites on ruby and we constantly call perl scripts from our command lines. It's not really that terrible as for the majority of apps these languages are fast enough.

The same should apply to groovy. It also seems that groovy is intended for current Java devs for quick prototyping, so it's not like they don't have to load the jvm constantly anyways.

Finally, as far web apps are concerned, I know for a fact that Java is used all over the place in companies for stuff like that, and that it's a popular backend language. I can only imagine that all of these apps find *someway* of keeping the JVM alive long enough to get that amortized reduced performance cost. It'd just be silly not to.

*disregarding, of course, all of the obvious problems with using that benchmark. We're doing back of the envelop stuff here, nothing too serious.

Here's the interesting thing: it does not really matter anymore, if all we care about are other interpreted, programmer-friendly scripting languages.

If we're concerned about using this against Perl, Python, PHP, Smalltalk or Ruby, using the great language shooutout benchmark*, Java is about on par, if not better overall based on CPU time alone.

My understanding of the jvm, which may be flawed, is that it first interprets the bytecode and eventually gets around to compiling it into native machine code - meaning that over the life time of large apps it has a negligible performance hit. So, in theory, Java can only ever be, at worst, as slow as any other interpreted language.

This is something we've come to accept; linux installers are built on python, large websites on ruby and we constantly call perl scripts from our command lines. It's not really that terrible as for the majority of apps these languages are fast enough.

The same should apply to groovy. It also seems that groovy is intended for current Java devs for quick prototyping, so it's not like they don't have to load the jvm constantly anyways.

Finally, as far web apps are concerned, I know for a fact that Java is used all over the place in companies for stuff like that, and that it's a popular backend language. I can only imagine that all of these apps find *someway* of keeping the JVM alive long enough to get that amortized reduced performance cost. It'd just be silly not to.

*disregarding, of course, all of the obvious problems with using that benchmark. We're doing back of the envelop stuff here, nothing too serious.

Here's the interesting thing: it does not really matter anymore, if all we care about are other interpreted, programmer-friendly scripting languages.

If we're concerned about using this against Perl, Python, PHP, Smalltalk or Ruby, using the great language shooutout benchmark*, Java is about on par, if not better overall based on CPU time alone.

My understanding of the jvm, which may be flawed, is that it first interprets the bytecode and eventually gets around to compiling it into native machine code - meaning that over the life time of large apps it has a negligible performance hit. So, in theory, Java can only ever be, at worst, as slow as any other interpreted language.

This is something we've come to accept; linux installers are built on python, large websites on ruby and we constantly call perl scripts from our command lines. It's not really that terrible as for the majority of apps these languages are fast enough.

The same should apply to groovy. It also seems that groovy is intended for current Java devs for quick prototyping, so it's not like they don't have to load the jvm constantly anyways.

Finally, as far web apps are concerned, I know for a fact that Java is used all over the place in companies for stuff like that, and that it's a popular backend language. I can only imagine that all of these apps find *someway* of keeping the JVM alive long enough to get that amortized reduced performance cost. It'd just be silly not to.

*disregarding, of course, all of the obvious problems with using that benchmark. We're doing back of the envelop stuff here, nothing too serious.

Here's the interesting thing: it does not really matter anymore, if all we care about are other interpreted, programmer-friendly scripting languages.

If we're concerned about using this against Perl, Python, PHP, Smalltalk or Ruby, using the great language shooutout benchmark*, Java is about on par, if not better overall based on CPU time alone.

My understanding of the jvm, which may be flawed, is that it first interprets the bytecode and eventually gets around to compiling it into native machine code - meaning that over the life time of large apps it has a negligible performance hit. So, in theory, Java can only ever be, at worst, as slow as any other interpreted language.

This is something we've come to accept; linux installers are built on python, large websites on ruby and we constantly call perl scripts from our command lines. It's not really that terrible as for the majority of apps these languages are fast enough.

The same should apply to groovy. It also seems that groovy is intended for current Java devs for quick prototyping, so it's not like they don't have to load the jvm constantly anyways.

Finally, as far web apps are concerned, I know for a fact that Java is used all over the place in companies for stuff like that, and that it's a popular backend language. I can only imagine that all of these apps find *someway* of keeping the JVM alive long enough to get that amortized reduced performance cost. It'd just be silly not to.

*disregarding, of course, all of the obvious problems with using that benchmark. We're doing back of the envelop stuff here, nothing too serious.

Here's the interesting thing: it does not really matter anymore, if all we care about are other interpreted, programmer-friendly scripting languages.

If we're concerned about using this against Perl, Python, PHP, Smalltalk or Ruby, using the great language shooutout benchmark*, Java is about on par, if not better overall based on CPU time alone.

My understanding of the jvm, which may be flawed, is that it first interprets the bytecode and eventually gets around to compiling it into native machine code - meaning that over the life time of large apps it has a negligible performance hit. So, in theory, Java can only ever be, at worst, as slow as any other interpreted language.

This is something we've come to accept; linux installers are built on python, large websites on ruby and we constantly call perl scripts from our command lines. It's not really that terrible as for the majority of apps these languages are fast enough.

The same should apply to groovy. It also seems that groovy is intended for current Java devs for quick prototyping, so it's not like they don't have to load the jvm constantly anyways.

Finally, as far web apps are concerned, I know for a fact that Java is used all over the place in companies for stuff like that, and that it's a popular backend language. I can only imagine that all of these apps find *someway* of keeping the JVM alive long enough to get that amortized reduced performance cost. It'd just be silly not to.

*disregarding, of course, all of the obvious problems with using that benchmark. We're doing back of the envelop stuff here, nothing too serious.

Here's the interesting thing: it does not really matter anymore, if all we care about are other interpreted, programmer-friendly scripting languages.

If we're concerned about using this against Perl, Python, PHP, Smalltalk or Ruby, using the great language shooutout benchmark*, Java is about on par, if not better overall based on CPU time alone.

My understanding of the jvm, which may be flawed, is that it first interprets the bytecode and eventually gets around to compiling it into native machine code - meaning that over the life time of large apps it has a negligible performance hit. So, in theory, Java can only ever be, at worst, as slow as any other interpreted language.

This is something we've come to accept; linux installers are built on python, large websites on ruby and we constantly call perl scripts from our command lines. It's not really that terrible as for the majority of apps these languages are fast enough.

The same should apply to groovy. It also seems that groovy is intended for current Java devs for quick prototyping, so it's not like they don't have to load the jvm constantly anyways.

Finally, as far web apps are concerned, I know for a fact that Java is used all over the place in companies for stuff like that, and that it's a popular backend language. I can only imagine that all of these apps find *someway* of keeping the JVM alive long enough to get that amortized reduced performance cost. It'd just be silly not to.

*disregarding, of course, all of the obvious problems with using that benchmark. We're doing back of the envelop stuff here, nothing too serious.

Don't you worry, Etch will be out soon enough. The number of release-critical bugs is now going down nicely and the final version of the installer, RC2, will probably be announced during this week. But you don't have to wait for the Etch release. You can download and install Etch right now. It has been ready for normal use for several months now.

The Etch release process has also significantly decreased the number of release-critical bugs in Sid -- and Ubuntu has updated their sources from the Debian pool several times during the Feisty release cycle. This means that Feisty will be more solid than several earlier Ubuntu releases, while Feisty+1 will again be a hayride to Hell for Ubuntu when Debian Sid goes bonkers after the Etch release. :-P

The reason is that there are too many release critical bugs open. Now there are a number of things you can do:
- Try to help
- Decide that the bugs don't concern you and install Testing.
- Use another distro and ignore anything related to Debian.
Any of these would probably be better than complaining on Slashdot that Debian is late.

The reason is that there are too many release critical bugs open. Now there are a number of things you can do:
- Try to help
- Decide that the bugs don't concern you and install Testing.
- Use another distro and ignore anything related to Debian.
Any of these would probably be better than complaining on Slashdot that Debian is late.

Well, that is a problem, but overall I'm more concerned with whether they've addressed Debian's criticisms. The GNU criticisms are basically, 'People refer to them vaguely, and you can't use them with our licenses.' The latter is a considerable practical problem, given the mass of GPL material out there. But the issues raised in the Debian criticism are much more serious, as far as I'm concerned. They deal in detail with its vaguenesses, its difficult points, and essentially with how well it can really be used and how free it truly is.

I'm not really sure whether the changes amount to addressing all these issues (where 'addressing' may just mean 'objection noted, but no change'). A diff would be helpful...

You're exaggerating, it's more like 18000, and you can't install all of them at the same time (some conflict with each other).
I've never used k7fftwgel-dev but, since Fast Fourier Transform is very cpu-intensive, I bet it *IS* SO much better (AMD Athlon K7 has 3 FPU's, and does 3dnow! and SSE, IIRC).
Sometimes the libraries that make the programs that you use blindingly fast are a bit "under-the-hood" and not very visible or sexy, but I bet this one helps a lot for programs like gromacs (http://packages.debian.org/testing/science/gromac s-lam) (for e.g. chemical and medicine research).
Besides, I'd like you to think up understandable program names for all the 18605 packages, 'cause I can't. That's why we have synaptic :-)

That is one of the most common mistakes we software engineers make. Design software to be how we want it, not how the users want it. The users want a slow loading flash page with lots of sounds and a delay due to animation every time you click on something.

Functional pages that present information clearly without use of graphics seem to make users think along the lines of "well, this page looks 'good' like all the other ones, it must not have good information."

A site like this just does not resonate with users today, elegant in its simplicity though it may be.

If you are working on a personal blog or something, you can do it however you want. They don't like your design, screw em, they can go somewhere else. But if you are working on a professional site, you do not have that luxury.

Just my opinion at least. I'm not a great web programming, and certainly not a good designer.

Debian solves this in a very simple way : divide the archive in main , contrib and non-free part. Non-free contains stuff that Debian has at least permission to repackage and redistribute from upstream sources (more info here). Redistributors of Debian choose to redistribute whichever best fits their needs and/or moral values. And users alike. So you get both the cake and the fat boy. I fail to see in Alan Cox argument why Fedora could not do the same.

In fact, the jury is still out on whether or not that is actually true. It's an assertion, but it's not gospel.

Ahem..

(Follow-up)

Ahem..

(Follow-up)

Yup, cause the linux just does a better job.

I think I'll randomly pick a distro and list some security advisories.

http://www.debian.org/security/2006/

Oh, look, there's lots there.

Beware: fedora.redhat.com is not the proper cleaning site. The two proper cleaning sites are http://ubuntu.com/ and http://debian.org/.

The only story I want to hear about Vista security is what it fixes. We already know what Microsoft broke.

I've been telling you for years and I'll tell you again. The fix is:

• here
• and here
• and here
• or here

Diversity is the only solution to internet security. The user gains immediate security in the short term. The community gains security in the long term as weak platforms are eliminated and can no longer be used to attack strong ones. Everyone wins when the monoculture ends. Free software provides both transparency and a diversity of hard targets. Confronted with rising costs, criminals will go back to their usual meat space businesses.

You can use the web interface at http://packages.debian.org/ or run 'aptitude download'. Other apt-based software may also have an option to download packages instead of installing them.

That probably wouldn't be too difficult to do using the computer language shootout http://shootout.alioth.debian.org/
You have to figure out the equivalent tasks(Mandelbrot seems to be be one) and then flip between the two benchmark pages.

Yes, Ruby is the current web development flavor of the month, however, don't get caught up in the hype. There are good number of MVC web development frameworks in other languages, including even Lisp and Smalltalk, but most notably Python. In my opinion it makes more sense to learn a Python framework for a number of reasons. Mainly because Python is used in considerably more non-web applications than Ruby, which makes your skills more portable (and you more employable). Ruby on Rails is also very monolythic, while two of the the three most popular Python frameworks, TurboGears and Pylons are very modular (especially Pylons since it's built around the WSGI spec). Finally, Python compiles to bytecode whereas Ruby does not. Hence Python outperforms Ruby in almost every shootout.

Further reading:
Of snakes and rubies; Or why I chose Python over Ruby
TurboGears and Pylons (a technical comparison)
From PHP to Python (my blog)

Performance isn't everything, but then again, when you are 400 times slower than Java... performance starts to matter.

v e r y _ s l o w ?

> And that's one symptom that indicates his views will never
> become a consensus in the Linux community.
> This mania of prepending "GNU/" on the Linux name is considered
> obnoxious by a majority of the people who use and contribute to Linux.

Speak for yourself. I do contribute, and like to call things as they are.
*Flash* Big news for you: there are systems almost identical to
GNU/Linux which do not happen to include Linux!

See http://www.gnusolaris.org/ http://www.debian.org/ports/hurd/
and get a clue.

Users who care about freedom could also just check out Debian in the fist place. I don't really undestand the point of gNewSense when Debian already exists, it seems like wasted effort.

You are not understanding what I am saying. Your problems are with the default 'nv' driver. I am saying that NVIDIA's own installer for their proprietary driver is bad/crap/dangerous/buggy, and that people should use the packages of the proprietary driver that are provided by their own distribution (in Debian's case: http://packages.debian.org/cgi-bin/search_packages .pl?keywords=nvidia&searchon=sourcenames&subword=1 &version=all&release=all).

The difficulty comes later on when you need to install or upgrade something else and the shitty packages built by the idiots at ATI who know nothing about how Debian-based systems are put together break.

Do yourself a favour and stick with the official packages: http://packages.debian.org/src:fglrx-driver

A similar fix would probably work now if anybody cared, but I imagine Sun will fix the hole properly quickly, probably more quickly than IBM fixed theirs back when, and not many people have telnet enabled on Internet-facing machines anymore anyways, but even so, it's amazing to see basically the same hole over ten years later. Linux has had similar problems too -- I believe the root source was Julianne/John F. Haugh's shadow suite back then, and I wonder if it's still the original source here.

If they choose not to redistribute and keep everything secret then that's fine.

But it also lets Windows and Linux applications run at native speed on Apple hardware

Gee, you mean you couldn't run Linux on Macs before?