Slashdot Mirror

This one bit me bad the other day:

http://lists.debian.org/debian-user/2006/01/msg004 08.html

However, the "issued patch" solved the problem. And better yet, I could patch it myself by editing one text file and rebooting.

So yes; patches can and do break stuff in linux.

That being said, a similar issue in would have required a reinstall.

Like the three win2k machines I have here right now which *refuse* to actually use windows update. I'm having to download all patches by hand and force feed them one at a time.

Yeah, I can see how 8 days is slacking.

I don't think you do. If you did you wouldn't waste electricity posting reasons why Microsoft can't compete with Open Source Software as excuses for the delay.

Help Microsoft deal with its security problems, migrate to Linux today!

Well even Wal-mart was selling XBox 360s, so I guess you could check there first. Or maybe Best Buy, they also were stocking them.

Who was talking about XP, we were talking about NT. Besides the fact that these architectures are not even supported by the hardware makers anymore, do you really think MS should do a full XP port to them? Brilliant...

Yes currently available... So show me where I can buy RedHat or SuSE for RISC or ALPHA then, or show me where I can Buy the embedded version of SuSE to put into a router I'm developing?

Sigh. Really: You don't need *all* of those hamm CD images on your hard drive.

At least delete the m68k binaries you never used anyway. If they're so important to you, burn them to DVD or something. ;)

All the bugs I find and report which result in Advisories are as a result of source code auditing.

It looks like I made the CERT list a couple of times, e.g. uw-imapproxy.

But these bugs are trivial things in applications which are either "extra", or not typically installed.

Fixing bugs in programs is important, but having a list of 500 simple buffer overflows in rarely used games (for example) on Linux says nothing about the relative security of Linux vs. Windows.

The worlds are too different, comparing every application included in Debian, say, against Windows would only make sense if you installed every single shareware/freeware/optional piece of software on the windows machine - and that clearly isn't a real world scenario.

He meant the software industry as a whole. He is a smart guy, and an former NASA software developer. But he has been brainwashed by Microsoft, and is not questioning the order to use C# for our realtime embedded system.

Grab some benchmark sources from here in http://shootout.alioth.debian.org/. Run the C#/Mono code under the .Net runtime (Microsoft won't allow published benchmarks). Compare the test results against Java/C++ etc.

Show your boss the tests and he may change his mind, our PHB did.

Enjoy.

Of course, that's even easier. I wouldn't exactly call 'nv' open source though. It sounds like they are pretty much unmaintainable by people who don't work for Nvidia... see the thread starting at http://lists.debian.org/debian-legal/2005/02/msg00 309.html and continuing to the next month (URL:http://lists.debian.org/debian-legal/2005/03/ threads.html)

So specifically what we've been doing is taking every binary in the system and assigning it a layer number, which is a rank in a directed acyclic graph. There's about 5,500 binaries in the system.

Right here
No need to thank me :D

Why use LILO at all, then ? You can use mbr (http://packages.debian.org/stable/base/mbr), or even the dos / windows one (fdisk /mbr), which will silently boot the active partition, that you will set to the one containing the secondary boot loader you're using.

right, but, this way is funny.

"Removing" a bootloader from the MBR isn't quite the same as removing a file. It's more a case of overwriting an old MBR with a new one. So if you want a bootloader to have this feature, the bootloader would have to have some concept of what to replace itself with.

Debian provides an "mbr" package that can be used as a generic MBR for almost any OS. The idea is that you install LILO/GRUB/whatever into the boot sector of the bootable partition rather than into the MBR itself; the generic MBR then just loads that rather than being a full bootloader in its own right. This may also be what the MBR written by "fdisk /mbr" does, but I'm not a Windows expert, so I don't know.

-Stephen

> Install Grub on the Linux partition, and use Lilo to load it.

Why use LILO at all, then ? You can use mbr (http://packages.debian.org/stable/base/mbr), or even the dos / windows one (fdisk /mbr), which will silently boot the active partition, that you will set to the one containing the secondary boot loader you're using.

Debian does exactly what you describe; the most recent update to the stable release (3.1r1) rolled in all the security updates and critical bug fixes since the release of 3.1r0 last summer. So if you order a new set of CDs every few months then you can keep your machine up to date via snail-mail. :)

Debian does exactly what you describe; the most recent update to the stable release (3.1r1) rolled in all the security updates and critical bug fixes since the release of 3.1r0 last summer. So if you order a new set of CDs every few months then you can keep your machine up to date via snail-mail. :)

"It requires write permissions to a CD burner drive, or a set[ug]id cdrecord to a user or group with write permissions to a CD burner drive."

I know full well what is required to burn CD's in UNIX. I've gone through the hair pulling getting it working in FreeBSD. In my experience, you have to do both - set suid on cdrecord and the other utilities and set the permissions on the cd devices. And you can paint it anyway you want, but set[ug]id is the equivalent of root, when it comes to the binary in question.

I'm don't use linux, but Google tells me the same is required for it.

Technically, full Administrator rights are not required to burn CD's in Windows either. The proper permissions can be handed down to regular users. I just havn't bothered to do it in Windows, because I do most of my burning from BSD.

No, really that's the answer. Those of you with roll your own Windoze software will probably be able to run them under Wine or crossover office without fuss. Most of your users won't even know the difference and that will be that. Just remember the above next week when 100% of your users are down due to a combination of IM and email worms slamming your network, you have to disconnect and can't get anything done.

As someone who does not use M$ junk, but does have to put up with network congestion, I thank each and every one of you who will liberate their users.

You can take a look here and compare for yourself:
http://shootout.alioth.debian.org/

Further to my previous post - I just didn't believe some of these benchmarks, so I tried them myself. I tried 'nbody', as I have a particular interest in maths:

I compiled the gcc and g++ code with exactly the same optimisations a specified, and I used both -client and -server switches with Java - the lastest Java 1.5.

Here are the results:

1000000 loops
gcc 0.9 seconds
g++ 1.1 seconds
java -client 1.3 seconds
java -server 1.1 seconds

5000000 loops
gcc 4.3 seconds
g++ 5.2 seconds
java -client 6.1 seconds
java -server 4.0 seconds

10000000 loops
gcc 8.6 seconds
g++ 10.4 seconds
java -client 11.4 seconds
java -server 7.6 seconds

Interesting, isn't it? When given enough time to optimise, java -server is even beating raw C.

Mind you, this is a bad general benchmark (most benchmarks are!), but it impresses me. Why don't you try it? The code is simple and easy to run.

I think I am going to re-run more of these benchmarks, and for a longer time - this should make an interesting report.

a few seconds?! even SWTed Eclipse begs to disagree. Many very useful perl batch scripts are done while most Java apps are still loading!

This is true. Java is not an appropriate language for for small apps that only take a few seconds (or milliseconds) to run. However, there are other performance issues with eclipse - SWT is not the fastest of systems.

Which run thoughroughly simplified GUIs and the like. Let's focus on real everyday stuff running on current desktop systems, ok?

This is irrelevant. The point was to show that Hotspot is not a CPU or memory hog. As for 'simplified GUIs', these platforms aren't simple at all - they have 3D drawing APIs, some of which are implemented in pure Java.

You can take a look here and compare for yourself:
http://shootout.alioth.debian.org/

Which I have seen, and is missing the point. As I have already discussed, the optimisation in Java takes some seconds to kick in. Most of what you are dealing with in these benchmarks is the startup time of the JVM. This is like comparing the performance of two different operating systems but neglecting to exclude the boot times.

In a recent Slashdot thread I showed that if you ran benchmarks like this for 5, 25, or 100x longer then Java easily caught up with C in most cases.

Here are some benchmarks that run longer and illustrate what I mean:
http://www.shudo.net/jit/perf/

decades?! Java itself is barely 2 decades old, JITting is a pretty newer technique and the "Hotspot" compiler has just came out a few years ago. I think you making things up in order to give your arguments some substance they lack...

No, you are misinterpreting me. I am not saying that Hotspot has been around for decades, I am saying that the optimisations it uses have.

The compilation time, the library loading times, the Garbage Collector thread cycles, some eventual runtime introspection techniques... the actual scenario is a lot worse than what you paint it to be.

You simply can't say this without evidence. Repeating that this 'must' impact performance is meaningless unless you can show that it actually does. I have already stated that the compilation time can be over with quickly, and the fact that Java can be used for high-performance real-time applications shows that garbage collection does not have an impact. After all, there are now modern garbage collectors that can be used with C and C++ - they usually have little impact when used in place of 'manual' memory handling, so which should things be any worse for Java?

Which also means the optimizer is up and running and consuming memory and cpu cycles.

Only 'every now and then', and as I have already discussed, the optimiser runs fine and with little impact on performance even in low memory and slow CPU systems.

"It is the use of the '-server' switch that allows Java to easily match the output of most C or C++ compilers in most benchmarks providing code runs for more than a few seconds."

hmm, perhaps this influenced the java benchmarks above? i don't know.

Absolutely. If those benchmarks were run for 10 or 100 times longer, I suspect the results would be very different. When I have tried one or two of them, they certainly have been.

well, then i guess this will likely be the longest running _dialogue_ *nobody* in slashdot has ever witnessed... :)

No - because I always beat opponents in the end - through boredom if nothing else!

"But even within a few seconds, it gets much faster."

a few seconds?! even SWTed Eclipse begs to disagree. Many very useful perl batch scripts are done while most Java apps are still loading!

Yes, eventually it gets a bit faster, but at any one time it needs to load another class or the like, it boggles down with some stuttering...

"Hotspot optimisers run fine even in restricted memory and CPU situations like J2ME."

Which run thoughroughly simplified GUIs and the like. Let's focus on real everyday stuff running on current desktop systems, ok?

"saying that 'the generated code still doesn't run at C/C++.. levels' is simply factually wrong."

You can take a look here and compare for yourself:
http://shootout.alioth.debian.org/

It's just a run against simple algorithms, no libraries involved whatsoever except simple stream IO. So, it doesn't show everyday performance, but even then, even simple algorithms on java don't run as nicely as in C/C++/OCaml...

"Once the Hotspot optimiser has done it's work..."

and when is that exactly? AFAIK, it's always doing its job, trying to optimize even more. And, sure, there are other things involved to make it slower past the runtime: Garbage Collection, for instance.

"This is exactly what pre-compilers do."

they do it *before* compilation and certainly *before* running the code, not while loading it...

"(but in a low-priority background thread that does not impair performance)"

every running code incurs some performance penalty.

"If you wish to insist that Java is slower, you are going to have to explain how all these optimisations actually make code slower,"

" when they have for decades been used to give high performance."

decades?! Java itself is barely 2 decades old, JITting is a pretty newer technique and the "Hotspot" compiler has just came out a few years ago. I think you making things up in order to give your arguments some substance they lack...

"The only difference with Java is that this aggressive optimisation takes place mostly during a short period after the application starts."

The compilation time, the library loading times, the Garbage Collector thread cycles, some eventual runtime introspection techniques... the actual scenario is a lot worse than what you paint it to be.

"The '-client' switch (on by default) says 'start up fast and concentrate on optimising later'. This means that, although the program is pretty fast, heavy optimisation may not happen for a while."

Which also means the optimizer is up and running and consuming memory and cpu cycles.

"It is the use of the '-server' switch that allows Java to easily match the output of most C or C++ compilers in most benchmarks providing code runs for more than a few seconds."

hmm, perhaps this influenced the java benchmarks above? i don't know.

"I'm just getting started...."

well, then i guess this will likely be the longest running _dialogue_ *nobody* in slashdot has ever witnessed... :)

http://linuxmafia.com/faq/Debian/package-database- rebuild.html

http://www.debian.org/doc/manuals/reference/exampl es/debian-package-database-rebuild

There was showstopper bug in aMSN (and Tkabber) when using Tcl/Tk compiled with --enable-threads option under linux kernels 2.5+. I believe it is not Debian-specific issue. Is it fixed already?

There was showstopper bug in aMSN (and Tkabber) when using Tcl/Tk compiled with --enable-threads option under linux kernels 2.5+. I believe it is not Debian-specific issue. Is it fixed already?

Ruby is useless to me because it has no unicode support.

In this shootout it was found that Ruby had lower memory consumption, but also ran much more slowly than Java:

http://shootout.alioth.debian.org/benchmark.php?te st=all&lang=java&lang2=ruby&sort=fullcpu

Why oh why do people feel they need to say the same things everytime a discussion about Java starts up. Slow, memory hogging, swing sucks, etc, etc. These arguments simply are not true about modern JVM's

As for Swing's problems: not truly native look & feel (doesn't behave like other Windows/Mac apps),

I love to hear this argument. OK...can you show me what a native windows app should look like? Why don't we take a look at Microsoft Office. You will note that microsoft doesn't even use a consistent L&F between different versions of office. Please repeat after me...there is no such thing as a truly native look and feel. Apple now uses 4 different L&Fs for the applications they write. What is the native L&F on Linux (Motif, KDE, Gnome, etc...what theme?). Look, here's an article that discusses it: http://www.osnews.com/story.php?news_id=10633 In Java, you can set the look and feel to be platform native. The problem is a lot of folks set there app to use the Java L&F (Metal) which does stand out and is down right butt-ugly. This is the developers choice, not a problem with Java.

terrible event model (bad queuing design - pretty much mandates a separate gui thread),

Can you explain to me what's wrong with Java's event queue? I do a great deal of swing programming and I find the event queue very simple to work with. Generally you can ignore it. If you have long running actions (such as long database transactions) you can fire them off in a seperate thread or use SwingWorker or Foxtrot http://foxtrot.sourceforge.net/docs/toc.php. If you don't understand the threading model, just say so, don't rag on it.

slow slow slow, memory hogging, even more increase in startup time.

Here's a few benchmarks:

• Since we're talking about Ruby..let's compare Ruby and Java -> http://shootout.alioth.debian.org/benchmark.php?te st=all&lang=javaclient&lang2=ruby..whoa Ruby got smoked!
• Let's look at a few numerical benchmarks: http://www.osnews.com/story.php?news_id=5602&page= 3. Java doesn't do to hot on the trig part here but on all other parts of the test it's comparible to C++.

I could go on, but for a serious GUI app (e.g. a desktop front-end to a web app) its performance is unacceptable and it is too buggy. In our testing, it was not very cross-platform either. We ended up having a fair amount of platform-specific code.

Them's fighting words!! ;-) Please oh please stop spreading such lies though. Look, I just wrote a database app that's used for annotating video data in real time. Not only is it plenty fast enough but it's cross-platform. There's no platform specific code in it what-so-ever.

p.s. Happy Holidays

Another followup:

your original link is to a benchmark in the 'old' category.

Have a look at the current benchmarks:
http://shootout.alioth.debian.org/

Wherein mostly java is generally no worse than 4x slower than the fastest implementation in any language.

Jacques Surveyor summarizes Doug Bagley's benchmark opus to shed light on this important comparison:

"What emerges from examining the Bagley Benchmarks is that programming languages are breaking out into 3 speed tiers for raw computing power:"

1. Compiled native code languages C, C++, GNAT Ada95, OCaml are the fastest. No surprise there.

2. Byte code engines such as Java, Mono C# and Python average 7-12 times slower than the first tier...

3. Interpreters such as Ruby, JavaScript, PHP and Rexx average 100-200 times slower....

The Xorg server and libraries regently went into Debian testing and have been backported to Debian Sarge as well. I am running the backport on my Sarge laptop since I needed the latest video drivers.

Oh, I was just going off what I got in the mail, but I guess I forgot the details...

Work on Xorg 7.0 for Debian is ongoing, but it's not at the point of going in to experimental yet. 6.9 has been in experimental for months now (the 6.8.99.903 is in fact 6.9 Release Candidate 3), and is very nearly ready to go in to unstable. Hopefully within a week, depending on how much time the holiday season steals away. If you're interested in the modular work, the latest updates are here and here. It's sitting in the X Strike Force subversion repository, and once 6.9 gets all settled in the focus will shift entirely to getting the modular stuff ready to go for etch.

I even went to check the experimental package for Xorg to see if I could prove that they were at least testing Xorg 6.9, but I guess I'm mistaken. Oh well; I'd rather have solid, stable work going on in Debian than dependency nightmares of keeping up to date...

Open source software is even more heavily male dominated than academia. The Debian women project has some ideas about why this might be and how to fix it. (http://women.alioth.debian.org/faqs/)

Also, don't assume that KDE and GNOME are the only options. I personally run Window Maker (with various dockapps), with fspanel, and KeyLaunch, with xtrlock (invoked via keylaunch) as my screen lock. On top of that, I use various shell scripts that I've written over the years.

Desktop systems, especially for certain classes of users, are highly varied. Good luck trying to study them!

And this is the award winning, "User Friendly" distro? Treating your users like idiots, but making them have "guru" skills just to play an mp3 is "friendly"? Good thing the average user only plays vorbis files, eh?

Fuck their "philosophy." Gnome not only does not do what I want it to do but appears to go out of its way to set up roadblocks to keep me from doing it.

PC software applications which incorporate mp3/mp3PRO decoding (player decoder) and software applications incorporating mp3/mp3PRO encoding capabilities (encoder, ripper, recorder, jukebox):
mp3 patent-only license
This patent-only license is needed in case the mp3 software is developed in-house or licensed from a third party
Decoder: US$ 0.75 per unit or US$ 50 000.00 one-time paid-up
Encoder/Codec: US$ 2.50 per unit

kdebase does contain some absolute junk, though. I strongly dispute the claim that kdepasswd (or ktips) is necessary for "a fully functional KDE desktop".

Alright, pray tell which ones ?

On the flawed but amusing computer language shootout page the fastest language is plain straight C, followed by SmartEiffel, which actually translates to C, followed by MLton which also translates to C, followed by D which may or may not have its own compiler, I'm not sure.

Anyway, on that particular benchmark suite, C is the champ, no doubt. Then there is the small matter of actual professional benchmarks, like SPEC, which are all in C.

C is very fast because it has hardly any feature over straight assembly. In some particular case it may turn out that missing features such at a good GC might in fact improve performance, but guess what, you can implement those in C. In fact all the languages listed above are, strangely enough, written in C.

In the meantime what you comment as being "strange and baseless" is in fact rather firmly rooted in fact.

Let's hear something different now, I'm listening. Is there a language that can do better than C in a wide series of situations ?

Debian unstable has weekly snapshots of cvs emacs.
http://packages.debian.org/unstable/editors/emacs- snapshot
I have been using it for some time now and it works like a charm.

The purpose of non-US was to bypass certain laws that prevented the export of cryptographic software from the United States.

Since those laws were nullified after the release of Debian 3.0 (Woody), the repository no longer serves a useful purpose and is now empty.

The non-US section has nothing to do with patents. Debian's patent policy is quite simple: all patents are ignored, except when they are being actively enforced against the creators/distributors/users of Free software; whereupon the patented software is removed from Debian entirely.

Please, have a look at http://www.debian.org/devel/debian-jr/.

We've already seen it in exactly this case.

Not entirely true.

As you can readily verify by looking at the developer information for the kdelibs source package, kde 3.5 has not been uploaded into Debian yet.

The release candidate has been on alioth since mid november. Those packages are considered highly experimental!

On the other hand major KDE releases does seem to get shorter and shorter time between them, and I have a sneaky suspicion that they are cutting features off their roadmaps to get the release out at a certain time and not telling people about it. I can't prove that though.

I do think KDE needs to reconsider how they do quality control, and think more about stability vs. features.

Not entirely true.

As you can readily verify by looking at the developer information for the kdelibs source package, kde 3.5 has not been uploaded into Debian yet.

The release candidate has been on alioth since mid november. Those packages are considered highly experimental!

On the other hand major KDE releases does seem to get shorter and shorter time between them, and I have a sneaky suspicion that they are cutting features off their roadmaps to get the release out at a certain time and not telling people about it. I can't prove that though.

I do think KDE needs to reconsider how they do quality control, and think more about stability vs. features.

It is how all debian based distros start/stop/restart their services (it's common in other BSD like distros). It's basic knowledge, just like elementary school is to your education

You should know it as you should read the faqs of the distros that you're installing. Check http://www.debian.org/doc/FAQ/ch-customizing.en.ht ml#s-booting and http://ubuntuguide.org/.

Perhaps. It isn't clear to me why one would necessarily want to write a "traditional" application (i.e. desktop style application) in a "managed" language. I've been a big Java fan, mainly from the standpoint of someone who came from C++ and could see that Java was much more productive. I even wanted to write high-performance code (and games) in Java. However, the numbers have never really been in Java's favor. Look at the benchmarks at the Great Computer Language Shootout. They're microbenchmarks, where Java should do quite well if it can really stand up to "traditional" languages in efficiency. The short story is, it doesn't. Further, I don't see the JVM/JIT ever catching up with a highly optimizing ahead-of-time compiler, especially in terms of memory efficiency.

In short, I'm planning on using Java for web-oriented programming, but for 'real' desktop apps it'll either be D or Dylan for me. Both are far more expressive, just as safe, just as productive (if not moreso) and both are significantly faster. Oh, one final point...both are available as FOSS.

C/C++ will only be used where bit-banging stuff is needed AND NO ONE will care about except a few grumpy old man...

Both will be around for a *long* time due to legacy code, but I agree for new development a more modern language is desirable. D and Dylan both fit the bill...Java really doesn't hit the same target. Also, both languages have language constructs like operator overloading that're more suitable for HPC/simulation/game programming, and feature very performant C calling interfaces.

"Try to install it on Linux and you realise the advantages of a commercial platform onto which you simply install binary application packages."

How about using tools like bl or ledcontrol for controlling the standard keyboard leds?

I've done this before with bl+kmail for that same purpose and it's quite simple; so everybody can do that right now without having to spend money in a special mouse or keyboard.

Cheers,

How about using tools like bl or ledcontrol for controlling the standard keyboard leds?

I've done this before with bl+kmail for that same purpose and it's quite simple; so everybody can do that right now without having to spend money in a special mouse or keyboard.

Cheers,

LibraNet is a Debian clone that has a very nice added administration package, and also can install Nvidia drivers off the CD. (Granted that most commercial distributions can do that, but a bog-standard Debian Sarge can't, and as a result my screen displays at unacceptably low resolution.

Official NVidia packages in Sarge

LibraNet is a Debian clone that has a very nice added administration package, and also can install Nvidia drivers off the CD. (Granted that most commercial distributions can do that, but a bog-standard Debian Sarge can't, and as a result my screen displays at unacceptably low resolution.

Official NVidia packages in Sarge

What we need is a standard way for X windows to have a thing like 'screen' were you can save your current output and move it to any computer that can handle X windows.

You mean like xmove? Basically xmove starts up a pseudoserver which clients can connect to. At startup clients connecting to the pseudoserver display on the default XServer, but can be moved to any other display on the network.

I agree that a cleaned up easy to use xmove system would be a nice idea though.

Jedidiah.

GCJ's had a plugin for a while now, but I wouldn't recommend it for untrusted applets.