Slashdot Mirror

Well, first of all, I'd call Windows XP SP2 their latest release.

Well then, if you are going to count minor versions of the same release, then the latest update to Debian 3.0 was released on January 1st, 2005! Call it "Service Pack 4" if you like, we call it Debian GNU/Linux 3.0r4.

Running a 2002 release of Windows XP doesn't prevent you from installing the lastest version of Mozilla, Firefox or . The version of Mozilla in Debian stable is currently 1.0.0, and Firefox isn't even there!

Get real! Do you install Mozilla, Firefox, etc from WindowsUpdate.com? I think not! Nothing stops you installing the above mentioned software on either Debian "stable" or Windows XP. As with Windows, Debian "stable" users can download it from mozilla.org or other 3rd party sites.

Okay. So, again, why did it take three releases to realize something was wrong?

you and other Debian people have thrown up your hands and said, "augh, look at this mess, it's huge, complex! We can't possibly fix this mess!

If it's so hard to make a useful distribution, why did we see a veritable explosion of distributions (some of them based off Debian) in the time Debian hasn't released a single stable version?

Question- why did it take, oh, 3 years for them to finally come to terms with the fact that their iguana was turning into a dinosaur? It's like they've all been collectively in denial.

I understand the need for stability, but that means you put more effort into QA, not that you sit on your ass because what you've got works.

Sarge is /finally/ almost ready. I've started putting it into pre-production, and haven't had any problems. Go burn an ISO of the pre-release installer to CD, do a network install, and you'll be running quite a nice OS, I think. Nits I have is that they default to 2.4 (come on, an out of date kernel on a brand new release?!), but that's easily rectified. The breadth of package selection can't be beat, and really saves huge amounts of time, unless you run really simple setups. Good sysadmins should all know how to install from source, and they should also try to avoid doing so unless it's really necessary. There are much better (and more fun) ways to spend your time. Anyway, start with the netinst CD image from here:

http://www.debian.org/devel/debian-installer/

That said, if debian *doesn't* fix their release schedule, I think it may be curtains time, at least in commercial environments, and that would be sad. The support from the debian community and the quality, breadth, and management of debian's package selection beats that from the corporatized linux distros hands down. There's really no reason why the same principles that drive the success of free software generally don't equally apply to the production of a quality distribution. It just needs to Get Out the Door. For my part, I am certainly going to find a way to help; clearly help is needed.

There is always BSD...

You might try apt-get install gcjwebplugin

It works on a few of the java applets that I have tried it with, and failed on a few others... it is still in development but is something to watch in the future.

It could be quite a wait for it to be uploaded to unstable. However, the Debian KDE team already has some quality packages available:

http://pkg-kde.alioth.debian.org/docs/install.html

I think your ordering of stable, testing and unstable is wrong. Stable is more stable than testing, which is more stable than unstable as this page describes.

If you've run unstable for a year with no problems, that's pretty good!

I used to run testing/unstable but switched to FC3 a few months ago (just for a change). I don't find one much better than the other, though.

Matt

All the more reason to use Debian on PPC. There is a gentoo port too these days. Personally I prefer OS X on this hardware, but there are still a few linux choices out there.

Software that has non-commercial-only restrictions is not free software by anyone's definition.

http://people.debian.org/~dexter/dists/php5/woody/

Works great.

Look at the shoot-out with only tests that are all available for C, C++ and O'Caml are included and weighted for both CPU and Memory. It paints quite another picture.

Bullshit. The reason you can't statically link Glibc because the developers don't think it's worth their time to solve the NSS dynamic module version skew problem (read the Glibc FAQ for details).

But why does it matter? Libc6's ABI/API has been stable for ages. Link against something old like 2.1, and your binary will work almost everywhere. You say you need to link against libc5; I don't know about that, but AFAIK, every distribution moved to Glibc years ago.

A new binary every month? Please. Here's a hint--you can pick between static/dynamic linking for each library you link to! If you want to use experimental/unstable library libvolitile, you can link that in statically, while still dynamically linking to Glibc and other stable libraries.

This came up recently on debian-devel; read http://lists.debian.org/debian-devel/2005/03/msg00 347.html for more.

<Netsnipe> by Mr.Progressive (812475) Alter Relationship on 09:39 AM -- Tuesday March 15 2005 (#11937706)
<Netsnipe> I first read that as "Debian Release Mgr. Proposes Dropping Some Acid"
<Netsnipe> vorlon: so have you?
<nwp> vorlon: so, how drunk did you have to get before daring to post it? ;-)
<gravity> Netsnipe: Yeah, I liked that one too :-)
<vorlon> Netsnipe: there was no mention of databases in the proposal
<gravity> It's the only worthwhile comment in the whole thing
<vorlon> nwp: stone cold sober. The drinking comes when we actually pull off a release
<Netsnipe> vorlon: so how much acid have you been substituting in place of the alcohol?
* GyrosGeier waits for somebody to submit it to slashdot
<vorlon> Netsnipe: as Isaid, no databases were harmed in the preparation of this proposal
<Netsnipe> vorlon: you're no fun.

Hey, if you guys would just read the actual announcement from Steve: http://lists.debian.org/debian-devel-announce/2005 /03/msg00012.html

You would see that support is NOT being dropped. Rather, the proposal just allows the common architectures to be released before the uncommon ones are fully tested. This seems like an excellent plan, rather than having to wait forever for Debian releases.

The way I understood it was that each architecture would continue to be included in unstable, but when time came to release stable, the architectures that were not up to snuff would not be included in stable. In other words, they are not going to hold off on releasing stable for the architectures that are ready just because some other, less actively devloped ones are not. This seems fair. If someone wants their favorite architecture to be included in the next stable release then they can volenteer to get it up to stable quality, or commit themselves to maintaining it (security patches) after it is released. Otherwise they can just keep using the unstable. This is better than forcing everyone to use unstable, by holding debian back from releasing stable on a timely basis.

The second set of requirements (for SCC) also make sense. If you have less than 50 users, or cannot support the infrastructure needed make mirrors, there is no reason that all the ftpmasters should have to mirror a full branch of code for you - it is overkill. Those 50 people can get together set up their own apt-get repository for their binary packages.

There are several things that I did not like about this plan however, like the non-merit-based requirement, of requiring a machine to be purchasable new. If there are people that are willing to do the work, who cares if the machine is in production or not.

I also don't like the fact that there is no official option for the less active arch's to make stable releases uncoupled from the main stable timescale. Suppose that a minor arch, has enough support to do a stable release every 3 years compared to the x86's 18 month cycle. Choosing to target every other stable release won't work because while there is twice as much time between releases the bottleneck is the time between feature freeze and release, and that will still be determined by the x86 team's (faster) schedule. Furthermore, all the stable releases for all the architectures really should have the same package versions. This will save effort supporting the releases in the future (security patches etc), and keep user confusion down to a minimum. One possible solution would be if they kept the requirements listed, but did not require them to be met at the same time as the x86 branch - let the architectures enter stable when they are ready, with a time limit of say 2 or 3 release cycles of the x86 branch.

In general, requiring all the architectures to walk in lockstep is a real problem that debian needs to fix, but they should do so in a manner that allows the less active architectures to continue to have stable releases at their own pace, while not holding back the x86 line.

Although apt is great, the Debian Policy Manual is what makes apt (and everything else on Debian) Just Work(TM). Apt and various other dependency management tools are available for other distributions, but without a consistently applied policy no automatic tool can work the miracles that Debian's apt can.

Rather than believing this silly FUD, why not read the actual annoucement by Steve Langasek, which explicitly states that support WILL NOT be dropped.

http://lists.debian.org/debian-devel-announce/2005 /03/msg00012.html

Why bother keeping IA-64? Debian has more alpha users than ia64. There are more SPARC users. Heck, there are even more HPPA users than ia64 users. All the details are available at the Debian Popularity Contest.

Original email

They seem to imply it is a proposal to drop the actual releasing after sarge .. They will still have support for the other architectures, but seem to imply it must meet certain criteria to be considered for release.

IMHO: requiring a level of 98% is too high and only releasing if you can still buy is rediculous. Debian still mostly compiles for 386(on x86) and it's hard to buy a 386 these days.

Don't use borken OSes?

But this makes a very good IE removal tool.

The problem with the free tools:

Jorg Schilling is damage

cdrtools aren't as free as they should be either. Competition is good. What they should do is release a GPL NeroAPI implementation for linux. libschilly is crap. libburn was a start, but it's currently stalled.

The free unrar in Debian main can only handle older versions of RAR. Use the non-free (shareware) rar instead.

Other side of the coin:

$distributors were given money by investors to convince business to switch to this solution. Business still have a choice of going with $distributor and having support etc. or running an OS without a company backing it. Businesses like having someone they can call when something goes wrong.

If the products were all the same, then business, or rather, "the market" would gravitate towards the free solution. But there's a reason everyone didn't just go to Debian.org and get what they needed. Hell, you can BUY Debian if you want. To someone, it is worth $14.99, and there's a business model based on it.

It would be an entirely other thing if $distributor tried to pretend that $free_version didn't exist, but as far as I know, that hasn't been the case.

While there are Free rar unpackers, the primary packer/unpacker has a proprietary license. He is catering to open source developers. It is a poor choice.

md5 probably provides enough integrity checking for test data & split/cat make splitting/reassembling ANYTHING easy.

RAR doesn't have a monopoly on integrating these, though. 7zip certainly has many of the service features available in rar.

http://merkel.debian.org/~joeyh/testing-security.h tml

Sure.

The Ackermann test, Java wins by a small margin.

Also look at takfp. The interesting thing about takfp can be seen here in the side by side results The slope of the red line (Java) is not as steep as N increase so even though it starts slower, it wins in the end and continues to do beat ther performance of c and c++ even though it's start time was a lot slower (these numbers include startup time). Saw this in some other tests too, like reverse-file. This is mostly in comparison to c++ but it shows how JIT compiling could help.

I didn't go through all the gcc parameters but each program was compiled for the machine it ran on. In shrink wrap software, or even in the data center, you're not going to compile the code on each machine and it has to be tuned to the lowest common denominator. With JIT you don't have to worry about that as the VM will do the necessary optimizations for you. The benefits can be seen in some of these tests.

There are a lot of cases where it's close as well. In other tests I've seen Java in some cases outperformed C++ and C under large usage when the gcc binaries were optimized for the lowest common denominator. Anyway... the potention for VM's JIT compiling and all that is not just theoretical. It needs to be improved, but that's no reason to give up on it.

In other test, the lines of code are dramatically different. Would I rather write a 178 line spell checker in C and have it run in about half a second? Or write a 23 line Java spellchecker that runs in about 2 seconds? When you go past just number crunching and into real applications like web applications, you'll see a big savings in time and development.

There's a place for high level languages like Python, Ruby and Java and a place for languages like C. The real power language seems to be OCaml. It seems to do really well on both loc, memory and cpu time.

This was really cool to look at, thanks for the link. I looked up some other stuff as well. I'm tired of hearing how Java is slower than PHP since in my own benchmarks I haven't seen what people are talking about. Most of the side by side graphs look very much like this where it seems that PHP doesn't scale under load compared to java, c or c++.

Sure.

The Ackermann test, Java wins by a small margin.

Also look at takfp. The interesting thing about takfp can be seen here in the side by side results The slope of the red line (Java) is not as steep as N increase so even though it starts slower, it wins in the end and continues to do beat ther performance of c and c++ even though it's start time was a lot slower (these numbers include startup time). Saw this in some other tests too, like reverse-file. This is mostly in comparison to c++ but it shows how JIT compiling could help.

I didn't go through all the gcc parameters but each program was compiled for the machine it ran on. In shrink wrap software, or even in the data center, you're not going to compile the code on each machine and it has to be tuned to the lowest common denominator. With JIT you don't have to worry about that as the VM will do the necessary optimizations for you. The benefits can be seen in some of these tests.

There are a lot of cases where it's close as well. In other tests I've seen Java in some cases outperformed C++ and C under large usage when the gcc binaries were optimized for the lowest common denominator. Anyway... the potention for VM's JIT compiling and all that is not just theoretical. It needs to be improved, but that's no reason to give up on it.

In other test, the lines of code are dramatically different. Would I rather write a 178 line spell checker in C and have it run in about half a second? Or write a 23 line Java spellchecker that runs in about 2 seconds? When you go past just number crunching and into real applications like web applications, you'll see a big savings in time and development.

There's a place for high level languages like Python, Ruby and Java and a place for languages like C. The real power language seems to be OCaml. It seems to do really well on both loc, memory and cpu time.

This was really cool to look at, thanks for the link. I looked up some other stuff as well. I'm tired of hearing how Java is slower than PHP since in my own benchmarks I haven't seen what people are talking about. Most of the side by side graphs look very much like this where it seems that PHP doesn't scale under load compared to java, c or c++.

Ok, here's some analysis.

Count words, I just happen to have Michel Abrash's graphics programming black book on the table and it's got a good discussion on count words.

1: The data is static, so it fits you theory.
2: The C version is almost optimal
3: The java version is not comparable to the C version for real world tasks (I haven't bothered to re-write it to be the same as the c version to see if it's performance is better or not).

HeapSort
why not quick sort? don't most languages come with quick sort built in and heap sort is almost identical to quick sort (variants on the binary merge).

Object methods...
1: the C 'object' and the java object are not the same, the java object provides a lot of extra functionality that may well be used in a real world application that has not been put in-place in the c version.
2: He didn't even use final in the Java version, how is using an almost static C 'object' equivalent to using a non-final java object in real world tasks.

I could go on.

Ok, here's some analysis.

Count words, I just happen to have Michel Abrash's graphics programming black book on the table and it's got a good discussion on count words.

1: The data is static, so it fits you theory.
2: The C version is almost optimal
3: The java version is not comparable to the C version for real world tasks (I haven't bothered to re-write it to be the same as the c version to see if it's performance is better or not).

HeapSort
why not quick sort? don't most languages come with quick sort built in and heap sort is almost identical to quick sort (variants on the binary merge).

Object methods...
1: the C 'object' and the java object are not the same, the java object provides a lot of extra functionality that may well be used in a real world application that has not been put in-place in the c version.
2: He didn't even use final in the Java version, how is using an almost static C 'object' equivalent to using a non-final java object in real world tasks.

I could go on.

Perhaps you could name a case where Java is faster than C. The evidence seems to be against you. Maybe you meant C++.

There are a few cases where Java can use optimizations that C cannot. The C pointer problem is well-known. Usually the advantage of using pointers more than offsets the register optimization cited.

When the part one was published, I had severe problems getting Rails to work in Debian. There was a lot of really odd tools that needed to be installed and all that. Rails web page had tons of Ruby packages that I was pretty sure I didn't need...

But one thing has changed since then: Rails is now in Debian unstable!

Please note that security updates for "unstable" distribution are not managed by the security team. Hence, "unstable" does not get security updates in a timely manner.

Stable? [...] It's a marvelous example of what computing should have been in 1997.

Interesting? MOC!

The parent is an obvious troll. Woody (the current Debian Stable) was released in the summer of 2002, so he is demanding that in 1997, the Debian developers should have provided software which would only have been written half a decade later.

LWN.net: VA Linux and Sun Wah Linux Join Forces Around Debian
LinuxWorld.au: VA Linux, Sun Wah team on Debian Linux

Martin Michlmayr(Debian Project Leader)'s comment

There is Linux for PowerPC also.

As opposed to Slackware, Gentoo, Debian, Trustix, Tiny Sofa etc. These are designed for making toast. Why they have everything required for an out-of-the-box LAMP installation is beyond me, I've never had to use PHP to make toast before. Maybe my toaster just has it integrated in firmware?

The GPL version of open source is not going to work, especially if you want an entire system from thousands of different vendors to be 100% open source. It's hard enough to get industry-wide standards adopted WITHOUT requiring everyone to give their products away for free.

How does something that directly contradicts reality get modded insightful ?

The only thing that will work is to either reinvent the wheel from scratch, in your own country, under communism, and hope you'll succeed where no one else has. (China seems to be making progress).

The current scarecrow to throw at your enemies is terrorism, not communism. Please follow your times.

Also, if you meant that shared ownership implies communism, it logically follows that any company with more than one shareholder is communistic.

Come up with an open source license that doesn't take away control of finished products from companies who haven't yet had a chance to earn a profit from their work

AFAIK most open source projects are (or at least started as) the work of people, not corporations.

The GPL doesn't work, it requires immediate release of source that can be used by competitors or would-be customers, and eliminates the profit motive.

Um, isn't this exactly what the company releasing its code would want ? That anyone who distributes products based on the code must release any enhancments to the code under GPL as well ?

You do realize that just because you, the original author and copyright holder, released version 1.0 under the GPL, doesn't mean you that you are under any obligation to release version 1.0.1 under any license - assuming, of course, that you own the copyrights to all the code in version 1.0.1 ? Licenses are used togrant rights, under certain terms, to people who don't have the copyright to whatever is being licensed.

Or were you bemoaning over companies inability to take GPL'd code, add some features, and sell the result as their own proprietary product ? If so, keep on lamenting; you won't get any sympathy from me.

Sure, you're going to say Hurd runs. Well, where's the GNU/GNU Distro?

It's right here.

Sure, you're going to say Hurd runs. Well, where's the GNU/GNU Distro?

here

Wrong. (Notice IA64 sitting quite happily in the architecture list)

It's definitely a step in the right direction that Lessig has codified the Creative Commons license...

Creative Commons is a giant step backwards, because it's taken all the people who might have been interested in creating free non-software works, and persuaded them to release their stuff under a non-free, GPL-incompatible license, such that all of us working on free software can't really make any use of it. All of the Creative Commons version 2 licenses are broken and should be avoided, just like the GNU FDL, the OSL, etcetera. You can see a fairly complete summary of all the problems found so far at http://people.debian.org/~evan/ccsummary

This should not come as a great surprise. Have a look at the people responsible for creative commons. Note how they're mostly lawyers and corporate types. This is not a grassroots effort, despite the way they allude to being related.

Creative Commons has shown no interest in fixing their licenses. Consider why that might be.

Hopefully, this will mean a lot more people buying one of these and using something like this, this, this, this or this!

Seriously. Why on Earth are people still putting up with these MS fuckers when Mac OSX and Apple hardware is so damn nice? I like a mix of Sun and Apple gear. The thought of actually deciding on MS just makes me shudder. And MS just keeps giving me more and more reason to hate them and the shit they peddle.

Does the security fix remove internet explorer?

debian.org

easy

You can 'trick' the PC with this.

"You can tell the pioneers by the arrows in their backs, *grin*."

That's great and all, but your management really did a good job pissing off those who spent, literally, *YEARS* stumping to their bosses on your behalf. Perhaps you can send them a message from us?

It's simple really. Each distribution has it's own quirks and "isms". It took us years but we learned RedHat like the back of our hands. We were loyal and knew that RedHat was a good investment of our time. We purchased RedHat support for our critical servers and used the free RedHat OS for our non-critical servers and (of course) desktops. We know how hard it is to upgrade servers, so we want it to happen as little as possible (have you *SEEN* the sheer volume of servers we have to maintain lately???). The boss was happy, we were happy, life was good. Then RedHat announces that there's no more "free lunch" and everyone would have to pay if they wanted anything supported for a sane amount of time. "Aw crap" we said. Our bosses are never going to be willing to spend tens of thousands of dollars for RHL.

Well, time to start learning a new distribution... Let's be careful this time though, let's learn a new distribution that has a true commitment to its users so we don't feel like our valuable time is wasted.

RPM is just doing its job, detecting a failed dependency.

If A.rpm depends on B.rpm, and B.rpm depends on A.rpm, you can install neither A nor B. That is not a failed dependency. That's a fucked up package management system. When I stopped using RPM, I never had to worry about that again.

There's nothing that says a modern package management system has to be wrapped up in a single tool, in this case RPM.

Well, nothing except, say all your competition. But you want to ignore that? Fine. Try this on for size...

Gentoo has never once stomped on a config file. It's package management system includes etc-update, a tool for merging changes in config files when you updated packages. with RPM, you have to hope and pray whoever put the RPM together wouldn't stomp your config files.