Slashdot Mirror

BSD (it's not dead, after all!)

This shows a huge amount of ignorance. BSD is alive and fine, in several forms:
- FreeBSD
- NetBSD
- OpenBSD
- DragonFly BSD
These are probably the most important. Take a look at Freebsd Derivates. You'll see there are many commercial products derived from Freebsd too.

Also, there are initiatives of porting different Linux distros on top of the BSD kernel:
- Gentoo/*BSD
- Debian GNU/kFreeBSD
- Debian GNU/NetBSD (abandoned in 2002 it seems)

BSD was, is and will be alive for a long time.

The Debian project does have some fairly strict guidelines: they're just not related to content, so much as they are licensing of content. It must be "free" and unencumbered.

Wrong. They just have separate sections; main, contrib and non-free, all maintained by the Debian project. You can search for non-free packages as easily as with free packages: http://www.debian.org/distrib/packages#search_packages

Sure, they must be legality distributable binaries - or else Debian themselves couldn't put it in the mirror - but it's not required to be free software. Adobe Flash, the proprietary Oracle JDK, non-free firmware, there are plenty of non-free packages in Debian.

Too bad they rarely build the kbuild package for experiential kernels so that users can actually install the needed kernel header packages.

I don't understand why they even upload them when they are not instable due to dependency conflicts. That said, we are talking about experiential so there is not suppose to be a guarantee that it is installable. It really does feel like a strange effort though since anyone using hardware or software that requires a kernel module to be compiled cannot assist with the testing.

The kbuild package in experimental is for 2.6.36 and I remembering being really surprised that that one was there at the time.

http://packages.debian.org/experimental/linux-kbuild-2.6.36

http://www.debian.org/ports/

Debian kicks ass!

The main problem is the applications. You can't just take a random app in Linux and put it on an ARM-based system. Some will cross-compile if the developer wrote very good code or if you're willing to do minor changes, others are written in interpreted languages like Perl. But besides that, the applications are limited.

Yes, but the situation is not so bad if you look here:https://buildd.debian.org/stats/ (compare the line "armel", that's ARM, with "i386" and "amd64"), mainly because this process of cross-compiling and fixing cross-architecture bugs has been going on for *decades* already on Linux.

I have modpoints but as no one bothered to reply to this post and point it's naive, fanboy inconsistencies then I felt the need to do that myself.

First, you've claimed the following:

With the increased speed of both hardware and the JVM since Java first arrived, it's got to the point where I can rarely justify using a language like C or C++ on the grounds of performance.

If by "performance" you mean noticeable lag on your regular GUI operations then your comment is reasonable. The advances in the hardware world brought us in the last decade hardware powerful enough to run a GUI written even in the most bloated interpreted language you can find in a smooth enough way to not notice any lag any more. Yet, java still lags far behind languages such as C and C++ in performance, with some data crunching benchmarks running java at least twice as slow as the C++ program compiled with G++ and and also with the C program compiled with GCC. So, in the end what you said amounts to nothing more than claiming that writing programs in C or C++ instead of Java is rarely justifiable on the grounds of performance if and only if performance is irrelevant for the application you are developing.

Then you moved on to the OO paradigm, where you made another silly claim. You stated that

Java's implementation of OO is so much better than C++ (methods always virtual for example)

This statement is absurd. Do you happen to know what any C++ programmer must do in order to get all the methods in a class to be virtual? Well, he only needs to state that they are virtual. That is it. There is absolutely nothing in C++ that forces any class method to not be virtual. As a side note, not having a method to be virtual by default is a terribly useful feature, particularly in performance terms, as a method can be called without having to waste cycles checking up with a vtable to realize what method to call.

And just to drive the point home, which is that your comment regarding the implementation of the OO paradigm in Java Vs C++ doesn't make sense, let me just mention a single issue plaguing Java that C++ implements just fine: multiple inheritance. That, alone, is a big thorn in the side of the "Java's OO implementation is much better than C++", simply because it makes it just plain wrong.

I have modpoints but as no one bothered to reply to this post and point it's naive, fanboy inconsistencies then I felt the need to do that myself.

First, you've claimed the following:

With the increased speed of both hardware and the JVM since Java first arrived, it's got to the point where I can rarely justify using a language like C or C++ on the grounds of performance.

If by "performance" you mean noticeable lag on your regular GUI operations then your comment is reasonable. The advances in the hardware world brought us in the last decade hardware powerful enough to run a GUI written even in the most bloated interpreted language you can find in a smooth enough way to not notice any lag any more. Yet, java still lags far behind languages such as C and C++ in performance, with some data crunching benchmarks running java at least twice as slow as the C++ program compiled with G++ and and also with the C program compiled with GCC. So, in the end what you said amounts to nothing more than claiming that writing programs in C or C++ instead of Java is rarely justifiable on the grounds of performance if and only if performance is irrelevant for the application you are developing.

Then you moved on to the OO paradigm, where you made another silly claim. You stated that

Java's implementation of OO is so much better than C++ (methods always virtual for example)

This statement is absurd. Do you happen to know what any C++ programmer must do in order to get all the methods in a class to be virtual? Well, he only needs to state that they are virtual. That is it. There is absolutely nothing in C++ that forces any class method to not be virtual. As a side note, not having a method to be virtual by default is a terribly useful feature, particularly in performance terms, as a method can be called without having to waste cycles checking up with a vtable to realize what method to call.

And just to drive the point home, which is that your comment regarding the implementation of the OO paradigm in Java Vs C++ doesn't make sense, let me just mention a single issue plaguing Java that C++ implements just fine: multiple inheritance. That, alone, is a big thorn in the side of the "Java's OO implementation is much better than C++", simply because it makes it just plain wrong.

http://packages.debian.org/lenny/all/firmware-bnx2/download - Download onto a USB stick and insert when prompted, or create your own installation medium with it included.

OR you could not assume that the Debian team is stupid enough to try and prevent you from having working hardware and look at their Squeeze isos *with* non-free firmware.

No, they are shipping a Linux system that doesn't run under any recent hardware.

It runs just fine on all of the hardware that I have. It's not like you can't add non-free to your sources.list and install the non-free firmware.

Not that bad, assuming someone else will write a script that configures the system and loads all proprietary firmware.

It already exists. The whole reason that it took us so long to remove the non-free firmware is because we had to have a mechanism to allow for users who wanted to run on systems which required it to load the firmware. Of course, if the article actually bothered to link to the original blog posting or the announcement e-mail, it would have been obvious to you.

That is just it. Do they have a list of things that are now flat out broken?

Nothing is broken. Debian has been in the process of separating non-DFSG-free kernel items from their main distribution since Etch. All non-free components are still available, but they're in the non-free section, the same section where Adobe's Flash installer lives. That's still fully integrated into the distribution.

The only thing that's new and newsworthy is this: Debian is now also building installer images without the non-free firmware, and defaulting to those images. This mostly affects users with older (Broadcom+) wireless chipsets, they won't be able to access the network during install. Some RAID controllers will no longer work, and 3D acceleration for Radeon cards is missing. For a complete list, see here.

Users that really depend on such hardware during install need to download the installer images that do include the non-free firmware.

Not just Linux, they yanked it out of the kfreebsd kernel too, which is causing problems because you can't just install a firmware-kfreebsd package - yet. I think they were a bit premature pulling the trigger on the kfreebsd kernel. Check out: http://lists.debian.org/debian-bsd/2010/12/msg00046.html and http://bugs.debian.org//cgi-bin/bugreport.cgi?bug=594940

Not just Linux, they yanked it out of the kfreebsd kernel too, which is causing problems because you can't just install a firmware-kfreebsd package - yet. I think they were a bit premature pulling the trigger on the kfreebsd kernel. Check out: http://lists.debian.org/debian-bsd/2010/12/msg00046.html and http://bugs.debian.org//cgi-bin/bugreport.cgi?bug=594940

First thing I on a fresh system (and I install a lot of fresh systems due to testing that goes horribly wrong :) Just put this in your sources.list and your fine. deb http://mirrors.nl.kernel.org/debian/ squeeze main contrib non-free deb-src http://mirrors.nl.kernel.org/debian/ squeeze main contrib non-free deb http://security.debian.org/ squeeze/updates main contrib non-free deb-src http://security.debian.org/ squeeze/updates main contrib non-free deb http://deb.opera.com/opera-beta/ squeeze non-free deb http://www.debian-multimedia.org/ squeeze main non-free After that I down the catalyst drivers from ati. And only then I start using the system. With all my closed-source goodies :D I love it!

First thing I on a fresh system (and I install a lot of fresh systems due to testing that goes horribly wrong :) Just put this in your sources.list and your fine. deb http://mirrors.nl.kernel.org/debian/ squeeze main contrib non-free deb-src http://mirrors.nl.kernel.org/debian/ squeeze main contrib non-free deb http://security.debian.org/ squeeze/updates main contrib non-free deb-src http://security.debian.org/ squeeze/updates main contrib non-free deb http://deb.opera.com/opera-beta/ squeeze non-free deb http://www.debian-multimedia.org/ squeeze main non-free After that I down the catalyst drivers from ati. And only then I start using the system. With all my closed-source goodies :D I love it!

Except one of those 14 packages is a meta-package with about 75 binary firmwares, including microcode for all Radeon cards for example.

Actually, from what I've heard (yeah anecdotal, I know)
Non-free binary-blob firmware in the kernel is fast becoming a non-issue
With the success of Android and other non-x86 Linux based devices, having a closed CPU specific blob is not an option anymore if you want device makers to use your hardware

I think you'll find Debian is doing this now, because now most devices have open firmware code that can be compiled for different architectures

Just look at this
http://packages.debian.org/source/sid/firmware-nonfree
Only 14 packages are in the Debian firmware-nonfree repository
That's nothing

Here's the actual article, as opposed to a link to what I presume is somebody's blog. Took me all of two seconds to find. In any case, as I expected, the "non-free" firmware will be available from the official non-free repository. The only thing we really need now is for someone to provide a minor-variant boot/install disc that includes the non-free network drivers, and everybody should be happy. (No, I'm not volunteering--my hardware works.)

The link to Debian's actual announcement: http://www.debian.org/News/2010/20101215

The code obfuscation competitions won't be good examples - since obfuscated code looks hard to understand, which would make it more noticeable to auditors, or even "normal programmers" looking at the code.

It'll be stuff like "The Underhanded C Contest": http://underhanded.xcott.com/?page_id=17

Or this: http://www.debian.org/security/2008/dsa-1576
Or "accidentally" leave in a few exploitable buffer overflows or other "normal" bugs.

As for over reliance on "many eyes", just relying on it is over-reliance. The "many eyes" claim is not applicable when it comes to _security_ bugs.

There are many eyes, but they're all "watching TV". They'll notice if a bug crashes their DVR or causes image corruption, other than that no.

There are only very few skilled experienced eyes auditing the code, and not all of those are on the "defending" side.

Link for the above DSA: http://lists.debian.org/debian-security-announce/2010/msg00181.html

It was fixed in 4.70, but not in the version currently in debian stable.

Debian has released a DSA and a fixed version for Stable. See Debian Security Advisory DSA-2131-1 and Debian Security .

For many benchmarks, v8 is pretty fast compared to CPython: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=python

http://www.debian.org/releases/stable/i386/apas03.html.en ... If you'll also notice on the distrowatch link.. the default desktop is Gnome you don't really have to do much as far as selecting packages, it will install it. Partitioning can be intimidating for "noobs", but that is the same thing you face with Windows.. If you notice in the Install instructions above there is auto partitioning as well.

You misquoted my " if they want to." as just "."

Sorry - but the rest of your post seemed to contradict the "if they want to": if the VERY_LARGE_VALUE_OF_N choose the bleeding edge release then its probably being mispromoted (e.g. the KDE debacle a while back when several distros pushed a major KDE upgrade when it was only intended for developers).

I think what we're both proposing is basically what many distros (e.g. Debian) already do. You can certainly choose your distro accordingly (e.g. CentOS vs. Fedora). This is really about Ubuntu not doing it this way.

Basically, c.f. http://www.debian.org/ and http://www.ubuntu.com/ - Debian headlines the stable release now 21+ months old, Ubuntu always headlines the latest 6-month release (which I', sure the maintainers regard as "stable" but do tend to introduce major infrastucture changes, unlike the Debian point releases).

> Most real cpu intensive applications applications are written in Fortran

Nobody outside the academia uses Fortran. At least, nobody under retirement age. And that same site also has a comparison of Fortran with C++, and C++ wins hands down. In one case, C++ is 26 times faster.

According to benchmarks, a functional language like Erlang is slower than C++ by an order of magnitude. Sure, it can distribute processing over more cores, which is the only thing that enabled it to win one of the benchmarks. I suspect that was only because it used a core library function that was written in C. So no, if you want to write code with acceptable performance, DON'T use a functional language. All CPU intensive programs, like games, are written in C or C++; think about that.

That's why I'm suspicious about this: dead code probably should not cause an order of magnitude increase in running time.

Actually, that's precisely what a good dead code elimination will cause. Consider this loop in C++:

int main() {
  for (int i = 0; i < 1000000000; ++i) {}
}

A dumb compiler will simply count upwards to 1 billion, which will take a few seconds even on a modern PC. A smart one will remove the loop entirely, since nothing useful is done, and the program will exit immediately as soon as it's run. The difference will be several orders of magnitude!

Haskell had this very problem when it first entered the Language Shootout - most tests were along the same lines, lengthy loops computing something just to throw it away. Turned out that GHC is particularly good at optimizing these sorts of things, and on a number of tests it ended up beating C by a significant margin due to that.

That's what I was trying to say... it is more likely a symptom of cheating (at least some level of catering to the benchmark rather than to the JS code) than it is a symptom of a botched optimizer that can consistently (95% confidence interval: +/- 0.0%) optimize some code down to exactly 1.0 ms, but "somehow" manage to perform far, far worse than other existing browsers when changing the source in a trivial way, and "all of a sudden" become way more inconsistent (95% confidence interval: +/- 1.9%).

Two things of note here.

First, this behavior only shows on one particular function in one specific test of the entire test suite. In fact this is precisely how it was found - the result is so ridiculous (IE 10x faster tan all other browsers!) on that particular test and not on any other - that it immediately stands out, and that immediately prompted an investigation. (If you RTFA, it's actually old news, it just took a while to gather all evidence and officially submit it to MS as a bug report.)

That's not how any sane person would cheat - you'd nib a few milliseconds down here and there, showing advantageous but realistic figures across all tests. Especially with closed source, that is nigh impossible to catch.

Second, it's not "far worse than other existing browsers" when changing the source. It actually still beats FF4 in this test even with the change! Chrome and Opera are faster still, but it's not like the difference there is 2x or even 1.5x.

Ultimately this needs more testing. Best of all would be to try to find some other pattern of dead code that is clearly unrelated to this test (so it couldn't be "wrongly detected" if this is a cheat), but which the optimizer handles in the same way. Finding a few such would definitely prove that this is just optimizer at work, and weird results are likely due to bugs in it (like incorrectly handling "return" as a side effect where it is not). But if no other patterns are found that exhibit this behavior, then this is strong evidence for hardcoding for the test.

Depend on what your doing. Check out some benchmarks

For complex number crunching purposes, Java kills perl. For a website, perl's probably good enough.

These browser benchmarks are significantly worse than the Computer Language Benchmarks Game "benchmarks".

Those programming language "benchmarks" are bad enough as it is, with many dynamic programming language advocates using them to incorrectly "prove" that their programming language of preference is somehow faster than some other language. Of course, that's only true when they write Ruby or Perl code that's so highly optimized and fine-tuned that you'd never see anything like it in any real application. In reality, languages like C, C++ and OCaml end up being the fastest for real-world applications.

At least the creators of the Computer Languages Benchmarks Game go out of their way to indicate that the benchmarks are flawed, and really shouldn't be treated as anything more than a game. We don't see that when dealing with browser or JavaScript implementation benchmarks, though. For whatever reason, too many people actually take them seriously. They incorrectly think that running some JavaScript microbenchmark equates to good performance for everyday browsing, when that clearly isn't the case.

I've been using Firefox 4 Beta 7, and it's very obviously slower than even older releases of browsers like Opera, Chrome, Safari and even IE. The benchmarks can say whatever they want, but reality differs significantly. Instead of aiming for bullshit benchmark scores, the Firefox developers should be making optimizations that'll actually improve the overall browser experience.

Debian has "over 25000". If RHEL6 is "software you can weigh", then Debian must be "software designed to break your scale". :)

(Note: this is not a claim that "Debian is better" or any such nonsense. Merely pointing out that 2000 packages is hardly an impressive or unprecedented feat in itself.)

However, if speed is an issue, Lua's never going to cut it in the same way that Java does.

Maybe not, but LuaJIT is pretty awesome.

Parrot? Is that in the resting on pining for the fjords stage?

At the rate things are going, Javascript has an even better chance become the next thing than Parrot. Seems like everyone and their dog is obsessed with making it faster.

Javascript is not as fast as Java but...

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=java

Seems it's actually not that slow unless you're trying to do stuff like calculate digits of pi.

In contrast stuff like Perl, Python and Ruby don't appear to be getting faster as fast. Javascript is already faster than all these 3. Go figure what the "community" has more interest in.

Don't get me wrong, I'd be happy if Parrot, Perl, Python and Ruby were all much faster (and complete in Parrot's case), but I'm not going to hold my breath.

That's a nice list of scripting languages you've got there. And don't get me wrong, scripting languages are nice. However, if speed is an issue, Lua's never going to cut it in the same way that Java does.

Actually, there is no intrinsic property of scripting languages that make them slower than Java. Obviously it mostly depends on the implementation of the virtual machine:

http://shootout.alioth.debian.org/u64/which-programming-languages-are-fastest.php

For example, take a look at this list. LuaJIT actually seems to be quite competitive with the fastest of the languages. So, no, I can't agree with you. If speed is an issue, your choices may be limited to those languages which have just-in-time compilation for your processor type, but it certainly doesn't mean that Lua et al. can never match the likes of Java.

If you want your anecdotal comparison to have any meaning then you must at least mention what environment you used to run your Java code and what compiler you used to test your C++ code. Moreover, wirting code which is "as close as possible in both languages" means that you've written code in at least one of those languages which sacrificed efficiency for the sake of being "as close as possible" to the other one.

So, in essence, what it means is that your anecdotal evidence is meaningless.

I am tired of getting the occasional java fanboy boasting Java's miraculous performance when compared to any other language, including C and C++. Yet, once they descend into the realm of reality they suddenly are faced with the fact that Java is is slower and hogs up memory when compared with the C++ equivalent compiled with GNU g++, no matter what benchmark you run, no matter what VM you run your benchmarks on. That means that Java fanboy's do the language a disservice by boasting Java's fictitious performance excellence. Java is a great language and it does have it's place but once you try to shoehorn it into domains where it clearly is not the best tool for the job then you are quickly faced with problems and limitations.

"but for the love of God, PLEASE keep network transparency. "

If you know what that is, you don't particularly need Ubuntu.

There is a very nice, but nearly forgotten distro for power users:

http://www.debian.org/

One thing many people aren't aware of is that for several years now (since GCC3), GCC and G++ accept UTF-8 as their default input encoding, and internally store narrow and wide strings as UTF-8 and UTF-32, respectively. It's recoded to the output stream locale when you do any output. This means you can write your source code in Unicode (in strings and comments at least) and it all works perfectly. It has full support in the C and C++ standard libraries. I've been using it for years; it works perfectly. It would be nice to get support for UTF-8 symbols in the linker, so we can have UTF-8 variable names as well. The same applies to Perl, though perl6 even gives you the ability to have Unicode operators, and possibly variable names.

I do routinely use UTF-8 symbols in R (example: "deltaCt" can be replace with the actual Delta symbol [Slashdot ate the Unicode--seriously poor!]). It makes the code more readable, and entry isn't the massive issue people make it out to be. AltGr/compose keys handle the common symbols, and you can look up the few odd ones that aren't in the compose tables.

Having the ability to use Unicode does not in any way detract from the ability to use ASCII. Since ASCII is a strict Unicode subset, the ability to use Unicode imposes zero overhead on those who wish to stick with ASCII, so the extent of the hate seen for wanting a bit of progress is a bit shocking. People pointed out how unreadable code could be made, but the reality is that when used sensibly and judiciously, it can make code more concise and readable.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522776 for information about some of the issues.
Having native Unicode support end-to-end by default is still a goal we want to achieve; the ASCII C locale is the last holdout. Getting a UTF-8 C locale is the last remaining step, though it'll take a few years to get there.

Regarding editing Unicode sources, both Emacs and vim have pretty decent Unicode support, and Linux distributions have had unicode support for a decade now, and really good support for at least six years. Broken tools are no longer an excuse for not using Unicode.

Regards,
Roger

Geocities may have proved online collaboration of a sort, the torrent proves the glaring inadequacy of US networks. Anyone could author a website and that many of those were worth reading. Wikipedia, Facebook and others follow naturally from Geocities and much better things are on the horizon. With tiny copper lines, nasty bandwith caps and even nastier download caps, the average user will take about 15 years to download the collection. That's assuming Time Warner's 5GB/month plan. At the average download speed of half a MB/s, you might see it in a month. The collection is very much worth archiving and indexing. Real knowledge and social history like this should be preserved for anyone who'd like to look. Let's hope libraries make archives and independent indexes to help people research.

Maybe they should make another 'buntu variant (Probuntu? Powerbuntu?)

May I suggest a better name for that 'pro' distribution: debian?

Is Ubuntu eye candy and all hip with tens of thousands of apps that do everything from exercise programs to scanning their airline tickets upc code via their Linux based phones? I do not think so.

Then you would be wrong. Ubuntu is eye candy has been for some time. I would install a dynamic wallpaper, faenza icons, conky colours, and a dark dark theme, get compiz scale/wall working from the bottom corners, and install awn. I'd say use the droid font, but the new Ubuntu font looks amazing...or I could just turn my windows into paper planes.

Linux has always been hip Google think so with Android, Google TV and Chrome...so do Intel/Nokia with Meego. Apple went from hip(sic) to single mum long time ago. I suspect its why the Media and Middle Classes are slowly turning on Apple.

I suspect Linux has enough Apps http://ftp-master.debian.org/users/joerg/pkg-nums not many fart apps or flashlight...but I'd leave them for something like Mixxx http://www.mixxx.org/ try it out you will want to burn iTunes off your hard drive and is a little hipper than itunes ;) and it will work with your OS.

Seriously Ubuntu and Linux has lots faults stick to those

I can't imagine they accept any piece of trash "hello world" app just because it was submitted.)

"Hello World" app in Debian: http://packages.debian.org/lenny/hello :)

Interesting, Debian has chromium-browser (the brand-stripped chrome that lacks some of the phone-home features) in its experimental repository as 7.0.544.0~r61416-1 while Google's apt repository is featuring 7.0.517.41-r62167 as both beta and stable (unstable has moved to 8.0.552.5-r62886). Unless I'm mistaken, those version numbers are composed of [version]~[VCS revision]-[package version] and chromium-browser's versions are pinned to their equivalent google-chrome version. That makes the current versions rather peculiar since Debian's (older) 544 is higher than Google's current 517 while the Debian's VCS revision 61416 is (as expected) earlier than Google's 62167.

What am I missing?

(The Debian chromium-browser package info page for developers is http://packages.qa.debian.org/c/chromium-browser.html)

Interesting, Debian has chromium-browser (the brand-stripped chrome that lacks some of the phone-home features) in its experimental repository as 7.0.544.0~r61416-1 while Google's apt repository is featuring 7.0.517.41-r62167 as both beta and stable (unstable has moved to 8.0.552.5-r62886). Unless I'm mistaken, those version numbers are composed of [version]~[VCS revision]-[package version] and chromium-browser's versions are pinned to their equivalent google-chrome version. That makes the current versions rather peculiar since Debian's (older) 544 is higher than Google's current 517 while the Debian's VCS revision 61416 is (as expected) earlier than Google's 62167.

What am I missing?

(The Debian chromium-browser package info page for developers is http://packages.qa.debian.org/c/chromium-browser.html)

That's it, I'm switching to Hurd.
http://www.debian.org/ports/hurd/.

Wow, you're condescending, ain't you? I'm half convinced you just want to troll, but I'll bite.

Although for the past couple of years my primary desktop has run a BSD, I solely used Linux (mostly Debian, but quite a few others, including some that don't exist anymore) for the twelve years before that (except where required by work). So I'm quite aware of the traditional distinction between "OS" versus "applications." I say traditional because when it comes to Linux—as from your post I'm sure you know—this distinction completely breaks down. Everything is an add-on, an "application," including coreutils, the compiler, awk, Emacs, vi, Firefox, an ftp client, Shotwell, whatever—everything except the kernel. This is, after all, the whole point of a Linux distribution in the first place (Linux from Scratch notwithstanding), to let somebody else assemble a whole system which they then "distribute" and you download. That's fine. That's good, even.

The issue is not that there are multiple distributions; that's fine and good for the software ecosystem. The issue is that, for example, Debian's page for the virtual www-browser package lists no less than twenty-six packages which satisfy installing it. This is what I meant by "being all things to all people." I, the user, should not have to choose between 26 different web browsers. That's simply absurd. (For those people that actually want or need for some reason to install Chimera (the latest date in the copyright notice, by the way, is 1997), well, they're certainly entitled to ./configure && make && make install.) But for most users, this is too much choice. They've already chosen Ubuntu or Debian or Mint or whatever. Why should they then have to decide what web browser, or text editor, or office suite they want? It is the responsibility of distributions to pick reasonable defaults. I'm painting in broad strokes, obviously, but it seems like instead, nobody wants to say "No" so everything just goes in, and then the user chooses. And making the user choose means that Linux distributions will never have the userbase (because people are put off by too many choices) or the polish (because developer effort is dispersed where it could be concentrated) of commercial operating systems. That's my opinion, for what it's worth. Notable counterexamples would be Ubuntu (on the shiny side) and Slackware (on the austere side). But note what both have in common: they both have somebody who can say "No." So I guess they're really not counterexamples at all.

Oh, and to address your strawman: nobody, least of all me, said that an OS should tell a user to "get stuffed" when they try to install something not included with the OS. As I mentioned above, a user can always install from source. Or get someone to. Or application authors can provide statically-linked binaries. Et cetera.

Wow, you're condescending, ain't you? I'm half convinced you just want to troll, but I'll bite.

Although for the past couple of years my primary desktop has run a BSD, I solely used Linux (mostly Debian, but quite a few others, including some that don't exist anymore) for the twelve years before that (except where required by work). So I'm quite aware of the traditional distinction between "OS" versus "applications." I say traditional because when it comes to Linux—as from your post I'm sure you know—this distinction completely breaks down. Everything is an add-on, an "application," including coreutils, the compiler, awk, Emacs, vi, Firefox, an ftp client, Shotwell, whatever—everything except the kernel. This is, after all, the whole point of a Linux distribution in the first place (Linux from Scratch notwithstanding), to let somebody else assemble a whole system which they then "distribute" and you download. That's fine. That's good, even.

The issue is not that there are multiple distributions; that's fine and good for the software ecosystem. The issue is that, for example, Debian's page for the virtual www-browser package lists no less than twenty-six packages which satisfy installing it. This is what I meant by "being all things to all people." I, the user, should not have to choose between 26 different web browsers. That's simply absurd. (For those people that actually want or need for some reason to install Chimera (the latest date in the copyright notice, by the way, is 1997), well, they're certainly entitled to ./configure && make && make install.) But for most users, this is too much choice. They've already chosen Ubuntu or Debian or Mint or whatever. Why should they then have to decide what web browser, or text editor, or office suite they want? It is the responsibility of distributions to pick reasonable defaults. I'm painting in broad strokes, obviously, but it seems like instead, nobody wants to say "No" so everything just goes in, and then the user chooses. And making the user choose means that Linux distributions will never have the userbase (because people are put off by too many choices) or the polish (because developer effort is dispersed where it could be concentrated) of commercial operating systems. That's my opinion, for what it's worth. Notable counterexamples would be Ubuntu (on the shiny side) and Slackware (on the austere side). But note what both have in common: they both have somebody who can say "No." So I guess they're really not counterexamples at all.

Oh, and to address your strawman: nobody, least of all me, said that an OS should tell a user to "get stuffed" when they try to install something not included with the OS. As I mentioned above, a user can always install from source. Or get someone to. Or application authors can provide statically-linked binaries. Et cetera.

Javascript runtimes are way faster then most other scripting languages at the moment.

If you go to the benchmark game you'll see v8 is about 6.5x faster then python and tracemonkey is 3.8x faster.

The only credible "scripting" language runtime that is faster then Javascript is LuaJIT, and Lua has nowhere near the features that JavaScript does.

> Your attempt to belittle Windows because of "biggest patch tuesday ever" seems to have completely backfired for you. Thousands of patches for ubuntu in no more than 5 months. Thats *THOUSANDS*

Yes. And if you would count single commits to all upstreams, it would be even more. Lines changed? Even more. Characters changed? *MORE*.

To cut out the sarcasm: For the 25.000+ packages in Debian, there have been a total of 153 advisories in 2010. http://www.debian.org/security/2010/

From what I remember when I still used Windows, most if not all patches that MS releases are either security fixes or updates for Media Player. But tbh, I don't care enough to look up what the last batch was about.

So yah, apples & oranges.

> > > You are a Linux zealot and are thus completely irrational.

> Saying that you are wrong because you are an ignorant dipshit would be an Ad Hominem.

Fascinating. Anyway, you summed it up nicely:

> Zealots and their faulty logic. Simply amazing.

I am having a problem with Debian and report a bug there, although it remains unfixed. But Ubuntu comes in and fixes the bug which was put on the bug tracker of another system.

Oh don't worry, it happens the other way too. Take this very simple and annoying issue, which Ubuntu hasn't bothered to fix since 2008. Debian fixed it in April.

Here's your bug I think: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/268502

This is maybe an upstream bug, https://bugzilla.kernel.org/show_bug.cgi?id=12045

so it's not Ubuntu's fault. Debian has probably the same issue (hint: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525220)

If you want to get it fixed, go on LKML and bluetooth userspace developer list, reproduce the issue and find the maintainer(s).