Slashdot Mirror

Java is often at least an order of magnitude faster than python, barring startup costs. They're not even comparable from a very high-level.

Python is compiled down to bytecode, but as far as I know, there is no further compilation to native code by the python vm. Python is amazingly fast for some things, when you're using mainly highly optimized c modules. (If you ever compare sed vs. doing regex search-and-replace via python, you'll be blown away at just how much faster the python is than the sed. The difference is the io, which is incredibly optimized c code in python.)

Java is not interpreted, and hasn't been for many years now. The vm compiles the hotspots (the code sections that are expensive enough and used enough to be worth compiling) to native code, and performs many optimizations that a static compiler cannot make, since the vm has much more information available with which to optimize than can be known at compile-time.

Nobody with any sense in the free software world has touched Mono

Right, that is why Debian GNU/Linux was the first to not only package Mono, include it in the distribution but also write a spec describing how packages using Mono can integrate right into the core of the system.

I won't go into how the gtk-sharp toolkit is one of the best maintained and most active language bindings for the gtk+ GUI toolkit incuded in GNOME today.

Free Software developers who haven't touched Microsoft Windows in years or who come from a completely UNIX background are happily writing desktop applications, system daemons and web applications using Mono today.

So, Bruce Perens, what on earth are you talking about?

Nobody with any sense in the free software world has touched Mono

Right, that is why Debian GNU/Linux was the first to not only package Mono, include it in the distribution but also write a spec describing how packages using Mono can integrate right into the core of the system.

I won't go into how the gtk-sharp toolkit is one of the best maintained and most active language bindings for the gtk+ GUI toolkit incuded in GNOME today.

Free Software developers who haven't touched Microsoft Windows in years or who come from a completely UNIX background are happily writing desktop applications, system daemons and web applications using Mono today.

So, Bruce Perens, what on earth are you talking about?

Nobody with any sense in the free software world has touched Mono

Right, that is why Debian GNU/Linux was the first to not only package Mono, include it in the distribution but also write a spec describing how packages using Mono can integrate right into the core of the system.

I won't go into how the gtk-sharp toolkit is one of the best maintained and most active language bindings for the gtk+ GUI toolkit incuded in GNOME today.

Free Software developers who haven't touched Microsoft Windows in years or who come from a completely UNIX background are happily writing desktop applications, system daemons and web applications using Mono today.

So, Bruce Perens, what on earth are you talking about?

The benchmarks at the shootout suggest otherwise. C# and Mono beats Java for memory usage in just about every case, usually by a factor of 2.

I program in Java and wouldn't touch Mono with a 10' pole, but Java really is a bloated pig at runtime.

Most modern distro installers will try to enable DMA. It makes the install process a lot faster. Some hardware doesnt like this (its pretty rare however) which is why if you pass the kernel option nodma (I think thats it. Dont quote me) then it wont try enabling DMA and it'll install fine. Your blaming the kernel developers when you just didnt RTFM.

Did you notice where I suggested Linux has lots of workarounds for resolving problems? When I said it was a DMA issue, that diagnosis was from having corrected the issue, sort of. I was able to get both systems to work under 2.6 (albeit with glacial performance, far worse than the Win 2K install) by turning DMA off. Part of the reason it was hard to figure that out was that the same hardware worked fine with DMA on under kernel 2.4 (the same way some people report that hardware that works fine with Windows 98 doesn't work correctly under newer versions).

If you must know: there seems to be a change in the rewrite of the PIIX driver in the 2.6 kernels that causes problems for some subset of people who have older computers based on the 440BX motherboard chipset; I'd direct you to this handy meta-note: http://lists.debian.org/debian-kernel/2006/10/msg0 0505.html where you'll find the following statement and many additional references should you wish to spend some time RTFM'ing:

"This is *not* a hardware problem or a CD problem. This problems has been replicated on different hard disks and on another similar computer...So far I have found it in Ubuntu and Debian distributions. Other MS OS's work fine on these computers...I suspect that it may be related to the Debian support of the southbridge PIIX4 chipset and/or the Intel 440BX and 440LX AGPset."

Here's a complete example of what I was suggesting to my parent post: here's an entire class of older machine that used to be very popular and that work perfectly under many Windows variants, but that plenty of people have reported issues with under recent Linux releases. There is very little difference between this and the Vista situation. The idea that Linux works better on old machines than Windows, especially if the install is done by someone who isn't going to RTFM and find all these little parameters you can tweak, is certainly debatable, and it takes a lot more evidence than "that's what I found" from one person to support such a statement.

The only blame that needs to be assigned here goes to whoever is responsible for you not learning where "your" supposed to put apostrophes at.

Most Linux drivers are in the kernel to begin with so unless you have exotic hardware you never need to recompile kernel modules.

I never said that I was rebuilding kernel modules with each new Linux release, but someone sure is because it has to be done with each release. My suggestion was that I doubt the main kernel developers are prioritizing new code based on backward compatibility tests with ancient hardware any more than Microsoft is.

deb http://terrorism.debian.org/ stable/documentation main contrib non-free

Lua is already faster than most dynamic typed runtimes, add a JIT to lua and it's register based VM becomes competitive with Java and Mono.

I've seen a tamarin "typed" benchmark and heard people say it is slow on eval, ie: code as data in a dynamic language. From this I assume tamarin is stack based and that the VM is not suited to dynamic languages (like javascript). If I'm right, Mozilla have only chosen tamarin because Macrodobe are willing to donate engineering resources. I'd like to see a benchmark and comparison between neko JIT and tamarin, something similar to this comparison between neko and lua.

Lua is already faster than most dynamic typed runtimes, add a JIT to lua and it's register based VM becomes competitive with Java and Mono.

I've seen a tamarin "typed" benchmark and heard people say it is slow on eval, ie: code as data in a dynamic language. From this I assume tamarin is stack based and that the VM is not suited to dynamic languages (like javascript). If I'm right, Mozilla have only chosen tamarin because Macrodobe are willing to donate engineering resources. I'd like to see a benchmark and comparison between neko JIT and tamarin, something similar to this comparison between neko and lua.

Lua is already faster than most dynamic typed runtimes, add a JIT to lua and it's register based VM becomes competitive with Java and Mono.

I've seen a tamarin "typed" benchmark and heard people say it is slow on eval, ie: code as data in a dynamic language. From this I assume tamarin is stack based and that the VM is not suited to dynamic languages (like javascript). If I'm right, Mozilla have only chosen tamarin because Macrodobe are willing to donate engineering resources. I'd like to see a benchmark and comparison between neko JIT and tamarin, something similar to this comparison between neko and lua.

I meant to link this to elaborate on the performance thing, but I fumbled the html.

• add this codesnip to /etc/spamassassin/local.cf

  mimeheader MIME_IMAGE Content-Type =~ /image\/(?:gif|jpeg|png)/
  describe MIME_IMAGE Image in Mime
  score MIME_IMAGE 1.0

  feel free to pump up the score (and dont forget to restart spamd if you use it)
• since the above was not enough , I started using FuzzyOCR , and it works great (the number of image spam went from 10/day to 0/ever); so I am planning to package it for Debian ; but the web page hints that there may be some security problem, so I am investigating.

• threatened Bruce Perens
• vowed to beat Jim Thompson to , simply because he called ESR a liar on teh internets.
• thinks that Western society is literally at war with Islam.
• believes black people are stupider than white people

OpenLaszlo's Legals Project will benefit immensely from this, because the OpenLaszlo compiler will directly target the AVM2 virtual machine that was just released as Open Source! Thanks to AVM2, Firefox will be a much better AJAX application delivery and development platform. OpenLaszlo is in a position to take excellent advantage of that, for the benifit of users as well as developers. Not only will AVM2 make OpenLaszlo applications run faster on Firefox, but opening up the AVM2 virtual machine will make it possible to develop much more powerful debuggers and integrated development environments.

All AJAX applications running on Firefox benefit, but Firefox itself will also benefit from integrating AVM2, because so much of FireFox is written in JavaScript itself.

AVM2 will be a huge improvement, because Firefox's current JavaScript interpreter, SpiderMonkey, is so extremely inefficient and wasteful of memory, that not only does it come in last in the computer language shootout, but it's actually TWICE as band and the next worst language, Smalltalk! (That's REALLY BAD.)

An important feature currently missing from Firefox that I'm looking forward to is a way to load pre-compiled binary bytecode into Firefox (like SWF9 files but without the graphics), instead of parsing and re-compiling the JavaScript source text every time. That's one of Flash's major advantages over browser-based JavaScript: it can quickly load and run pre-compiled AJAX applications much faster, thanks to the fact that it doesn't have to parse and compile huge amounts of JavaScript source code text files every time it starts up.

-Don

What is OpenLaszlo "Legals"?

"Legals" is an OpenLaszlo project to provide a single application environment that supports multiple deployment runtimes. OpenLaszlo 3.x supports Flash 7 and 8 now, but Legals will extend that reach to include DHTML as well as Flash 9. And with the necessary infrastructure in place, we anticipate further runtimes will be developed by the OpenLaszlo community.

The OpenLaszlo "Legals" project began at the start of 2006. We are projecting final availability by the end of the year. Developers interested in helping make Legals a reality are invited to contact us. Developers wishing to get a head-start building applications on top of Legals will be able to do so with our beta release in a few months.

Many people ask about the back story for the project name. The name, Legals, is a tribute to a well-known local restaurant in Boston where a lunch meeting inspired the team to launch this project.

See Legals FAQ for commonly asked questions and answers.

The Architecture

With Legals, the OpenLaszlo architecture is being remodularized into a true multi-runtime platform. OpenLaszlo generates script source that is compatible with ECMAScript Release 3, while leveraging extensions from ECMAScript Release 4. From there, multiple compiler backends generate JavaScript in the native dialect of the destination runtime: ActionScript 2 or 3, JScript 5.6, JavaScript 1.4+, and so on.

The OpenLaszlo runtime library is being refactored into two parts: multiple kernels containing runtime-specific code, and a cross-runtime library written in standard ECMA-3. As part of the runtime library, the OpenLaszlo class system has been rewritten in ECMA-3 and includes several innovative new features.

The OpenLaszlo runtime library delivers a common baseline of functionality across all supported runtimes. This gives the developer a rich environment in which to build full-featured web applications. In addition, Legals will include runtime-specific extensions so t

Why as a matter of fact, yes, somebody HAS profiled SpiderMonkey. And you might be interested in knowing just how fat and slow it is compared to other languages.

The Computer Language Shootout demonstrates that SpiderMonkey JavaScript is not only THE WORST language, in terms of BOTH slow speed and huge size, but also TWICE AS BAD AS THE SECOND WORST. SpiderMonkey loses the Computer Language Shootout by a long shot. Even bigger than the Republicans are going to lose this election!

So the assumption that SpiderMonkey is fat and slow is extremely correct, by a long shot. Just like the assumption that the Republicans are corrupt and incompetent.

-Don

oops, got the jython link wrong. also, if you're into (CPU) performance, it might be useful to take a quick look at a relevant benchmark over at the great language shootout.

http://www.debian.org/News/1997/19970708b works for me.

Debian has had a trip on the shuttle http://www.debian.org/News/1997/shuttle1/

One recent thread about the book (which also comments on why things like functions and OOP appear later in the book than one would think):
http://groups.google.com/group/comp.lang.python/br owse_thread/thread/b8366618c4547978

Also check the Amazon page for reviews and other feedback plus the author even posted a comment:
http://amazon.com/o/ASIN/0132269937

To reply to some previous comments:

- It's *much* faster than it used to be: http://shootout.alioth.debian.org/gp4/python.php

- The indentation only bothers you for 1-4 months. (I didn't like it either at first.)

- It *is* interpreted but byte-compiled like Java to make successive runs faster

- Why ESR likes Python: http://www.linuxjournal.com/article/3882

- Native look-n-feel GUI: http://wxwidgets.org/ and http://wxpython.org/

- Compare to other languages: http://wiki.python.org/moin/LanguageComparisons

- Shopping: http://www.bestbookdeal.com/book/compare/013226993 7 (it seems like Amazon, Buy.com, Bookpool, and Overstock rotate for having best overall price, i.e., no tax [depending on where you live] and free shipping)

- Bad code: Python is attractive to first-time programmers because of its ease, so that's what you may be seeing. Also, bad code is language-independent, regardless; Python does not go out of its way to make this happen. However, Python also attracts long-time programmers because they discover they are more efficient and productive in it.

FWIW, I switched to Python a few years ago (after lots of C/C++, Java, Perl, Tcl, etc.), and I don't want to program in anything else again. The naysayers can pound on me all they like, but from my point of view, I enjoy what I do, I get decent pay, and I can get home on time to feed my kids then hack some more for fun after putting them to bed.

-A.C.

Here!

I'm emailing all my friends this link for Christmas.

"The unix way (besides do one thing and do it well) however is to allow beginners and experts in, and help them leverage themselves so that they can be intelligent and productive in how they work."

That may be the UNIX way, but it's often not the Linux way at all. Hang out on the Debian User Mailing List for a while and you'll see what I mean.

I have an easier application deployment solution. Set up a local apt repository with the software that your business needs, update your repository configuration, then...

# aptitude install openoffice.org

If you want a completely automated process, stick that in a shell script and force defaults:

# aptitude -y install openoffice.org

No licensing woes, installer IDs, registry hell, anything like that. yum works just as well for you rpm fiends.

Fedora on the other hand is free.

Fedora project is obviously intended to look like Debian. But unlike Debian, Fedora is an extremely unequal partnership. "Fedora" is where the community developers are supposed to build Red Hat's product, while the certifications and vendor endorsements are held back for the high-priced "Red Hat Enterprise Linux" brand. This is especially obvious in recent certification announcements: the Common Criteria certification will go to "Red Hat Enterprise Linux", not "Fedora". And of course the entire steering board of the Fedora project are Red Hat employees. Red Hat recently announced a second draft of the leadership structure for Fedora, in which they have eliminated voting, expressing the need to keep control in the hands of Red Hat's management.

But the most ludicrous aspect of the Fedora project is that with Fedora, Red Hat seeks to achieve what Debian did long ago. Because they can't (and shouldn't) control Debian, they decided to re-invent the wheel. It would take them years to achieve a fraction of what Debian already has.

Forth is relatively quick (slower than C but probably faster than Java), but insanely compact. I would bet most forth code compiles to less than 10% the size of similar projects in C.

Forth is relatively quick (slower than C but probably faster than Java), but insanely compact. I would bet most forth code compiles to less than 10% the size of similar projects in C.

Forth is relatively quick (slower than C but probably faster than Java), but insanely compact. I would bet most forth code compiles to less than 10% the size of similar projects in C.

We already have one.

http://packages.debian.org/unstable/net/gcjwebplug in

[alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc]

I just cringed when you were grouping Perl with Java there... For that matter, I'd cringe if anyone would group any language with Java. It's really hard to make comparisons when you know that Java is pretty much always the worst choice in efficiency, speed and transparacy.

I just cringed when you were grouping Perl with Java there... For that matter, I'd cringe if anyone would group any language with Java. It's really hard to make comparisons when you know that Java is pretty much always the worst choice in efficiency, speed and transparacy.

I just cringed when you were grouping Perl with Java there... For that matter, I'd cringe if anyone would group any language with Java. It's really hard to make comparisons when you know that Java is pretty much always the worst choice in efficiency, speed and transparacy.

Absolutely: The Lua interpreter source code is very clean and well written, and wonderfully portable and platform agnostic.

Here's the source code that you can view online -- there isn't much to it! Four global header files, 19 core C files, 19 core header files, 10 library C files, 1 interpreter C file, and 2 compiler C files. Here is the main loop of the virtual machine -- notice that there are only 38 opcodes!

A great example of some interesting code written in Lua is the Auctioneer add-on for World of Warcraft (screenshots, manual). Here's the index of the Lua sources, and an interesing Lua file that calculates statistics on auction items. This code depends on features provided by the WOW client (implemented in C++ or whatever), as well as other Lua scripts loaded into the client.

One important reason to learn and consider using Lua, is that it's by far one of the fastest and smallest of all the interpreted scripting languages, on the Programming Language Shootout. It totally smokes most other scripting languages.

Here are the ratios of interpreted languages compared to compiled C code, in order of SPEED (the number is how many times slower it is than C, smaller is better unless you make your living by wasting time):
Lua: 6.4; Python: 7.4; Pike: 8.3; Tcl: 8.7; Perl: 9.0; Scheme MzScheme: 11; PHP: 13; Icon: 14; Smalltalk GST: 15; Ruby: 16; JavaScript SpiderMonkey: 32;

Here are the ratios of interpreted languages compared to compiled C code, in order of SIZE (the number is how many times bigger it is than C, smaller is better unless you make your living by selling memory):
Lua: 2.5; Haskell GHC: 2.8; SML MLton: 3.4; Python: 4.1; Perl: 4.3; Tcl: 5.1; Icon: 5.4; Ruby: 6.0; C# Mono: 6.3; Pike: 6.8; PHP: 7.1; Oberon-2 OO2C: 7.9; Erlang HiPE: 7.9; Java JDK -server: 9.1; Scheme MzScheme: 9.2; Mozart/Oz: 9.8; Scala: 10; Lisp SBCL: 10; Smalltalk GST: 13; Smalltalk VisualWorks: 15; JavaScript SpiderMonkey: 30;

Lua is even better than several compiled languages (like Java) when it comes to its size! Like Java, Lua also has a "just in time" compiler, but that was not used in these benchmarks (although I presume Java's was, because Java did very well with speed but not memory usage).

I think it's laughable that someone would put their time into learning a faddishly popular language like Ruby, but would then not consider learning a technically superior language like Lua, since Ruby scores so badly on these benchmarks compared to Lua, Lua has been around a lot longer than Ruby, and it had already proven itself in many commercial products (like WOW).

Lua really is far ahead of the pack of other languages in many ways, BECAUSE it's so clean and well designed. Plus its licensing terms are excellent, it's extremely portable, easy to embed and integrate with applications, and SWIG supports it well. So it's definitely well worth learning.

-Don

Absolutely: The Lua interpreter source code is very clean and well written, and wonderfully portable and platform agnostic.

Here's the source code that you can view online -- there isn't much to it! Four global header files, 19 core C files, 19 core header files, 10 library C files, 1 interpreter C file, and 2 compiler C files. Here is the main loop of the virtual machine -- notice that there are only 38 opcodes!

A great example of some interesting code written in Lua is the Auctioneer add-on for World of Warcraft (screenshots, manual). Here's the index of the Lua sources, and an interesing Lua file that calculates statistics on auction items. This code depends on features provided by the WOW client (implemented in C++ or whatever), as well as other Lua scripts loaded into the client.

One important reason to learn and consider using Lua, is that it's by far one of the fastest and smallest of all the interpreted scripting languages, on the Programming Language Shootout. It totally smokes most other scripting languages.

Here are the ratios of interpreted languages compared to compiled C code, in order of SPEED (the number is how many times slower it is than C, smaller is better unless you make your living by wasting time):
Lua: 6.4; Python: 7.4; Pike: 8.3; Tcl: 8.7; Perl: 9.0; Scheme MzScheme: 11; PHP: 13; Icon: 14; Smalltalk GST: 15; Ruby: 16; JavaScript SpiderMonkey: 32;

Here are the ratios of interpreted languages compared to compiled C code, in order of SIZE (the number is how many times bigger it is than C, smaller is better unless you make your living by selling memory):
Lua: 2.5; Haskell GHC: 2.8; SML MLton: 3.4; Python: 4.1; Perl: 4.3; Tcl: 5.1; Icon: 5.4; Ruby: 6.0; C# Mono: 6.3; Pike: 6.8; PHP: 7.1; Oberon-2 OO2C: 7.9; Erlang HiPE: 7.9; Java JDK -server: 9.1; Scheme MzScheme: 9.2; Mozart/Oz: 9.8; Scala: 10; Lisp SBCL: 10; Smalltalk GST: 13; Smalltalk VisualWorks: 15; JavaScript SpiderMonkey: 30;

Lua is even better than several compiled languages (like Java) when it comes to its size! Like Java, Lua also has a "just in time" compiler, but that was not used in these benchmarks (although I presume Java's was, because Java did very well with speed but not memory usage).

I think it's laughable that someone would put their time into learning a faddishly popular language like Ruby, but would then not consider learning a technically superior language like Lua, since Ruby scores so badly on these benchmarks compared to Lua, Lua has been around a lot longer than Ruby, and it had already proven itself in many commercial products (like WOW).

Lua really is far ahead of the pack of other languages in many ways, BECAUSE it's so clean and well designed. Plus its licensing terms are excellent, it's extremely portable, easy to embed and integrate with applications, and SWIG supports it well. So it's definitely well worth learning.

-Don

Well, the first reaction of many people might be
"O no, yet another scripting language finds it way from the obscurity into the lame light". Do we need an extra one if we already have Ruby, Python, Perl, Tcl, Scheme. And I say -- YES, Lua has its place, it is not redundant, it is not "me too" language. And here is why.

I have been expert Ruby coder for the last 5 years using Ruby for data modelling, extensive scripting, wrote load-balancing scripts, Rails Web development, binding C++ libraries to Ruby using SWIG, you name it.

Six month ago I got involved in LUA and I totally fell in love with it.
What does make a beautiful programming language? Lots of features? wealth of libraries? simplicity of it? I think that language design is more art than science and the language beauty is the careful balance of features, simplicity, semantics, uniformity, etc. Like in a masterpiece painting it is the balance of color, shapes, motives and composition.

C, for example, ia a beautiful language in the category of "portable assemblers". In that category C is powerful thanks to its libraries, simple and easily implementable thanks to its syntax and semantics, portable due to very clever and clean hardware abstraction.

I think that Lua is to "high level scripting languages" is what C is to "portable assemblers". Lua has both OO and functional programming very naturally represented in its semantics. All objects are first class (including functions). Lua is small, very fast (in fact fastest scripting language according to http://shootout.alioth.debian.org/), has very good Virtual Machine, incremental Garbage Collector. As far as fundamantals are concerned, Lua is light-years ahead of Ruby. It still lags behind in library support, but the recent progress is very encouraging.

Anyway, give Lua a try. You will love it. Lua is nice, its codebase is tiny (about 10K lines). It runs on anything that support ANSI C compiler including embedded stuff (ARM, Palm, Cell phones, MIPS, x86, etc).

I just discovered Lua and I got my PiL today. Its an fantastic language! It executes faster than perl, php, python and ruby. It is alot smaller, round 200kb, which is less than 1/10 of a minimal php installation and it has a reasonable Licence (MIT).

The main drawback is the lack of good standard libraries and the build system (for lua 5.1) don't support DSO's on linux. Debian has some patches that uses libtool to build it.

There is an interesting projocet named haserl that will allow you to embed lua in html pages.

First Edition of the book is available online

I just discovered Lua and I got my PiL today. Its an fantastic language! It executes faster than perl, php, python and ruby. It is alot smaller, round 200kb, which is less than 1/10 of a minimal php installation and it has a reasonable Licence (MIT).

The main drawback is the lack of good standard libraries and the build system (for lua 5.1) don't support DSO's on linux. Debian has some patches that uses libtool to build it.

There is an interesting projocet named haserl that will allow you to embed lua in html pages.

First Edition of the book is available online

I just discovered Lua and I got my PiL today. Its an fantastic language! It executes faster than perl, php, python and ruby. It is alot smaller, round 200kb, which is less than 1/10 of a minimal php installation and it has a reasonable Licence (MIT).

The main drawback is the lack of good standard libraries and the build system (for lua 5.1) don't support DSO's on linux. Debian has some patches that uses libtool to build it.

There is an interesting projocet named haserl that will allow you to embed lua in html pages.

First Edition of the book is available online

Some of what you write is debatable, but some isn't.

The original patent license terms were not unusual or unreasonable. It was just that a number of persons decided to make an objection in this case to a practice that nobody had objected to for over a decade.

Saying that is ignoring the facts. Both the ASF and the Debian project classified the Microsoft's license for their patent as inherently incompatible with free software. And patents on e-mail standards, unlike patents on many other IT technologies, are a very particular problem because a very large (if not the larger) part of the e-mail server world runs on free software. Go read the ASF's and Debian's explanations, they certainly did do their homework.

Sender-ID is not incompatible with SPF as alleged. The only difference is at the recipient side and the recipient cannot be forced to interpret SPF or Sender-ID in any particular way.

(To be explicit about my motives: I am the one who appealed to the IESG/IAB on behalf of the SPF project about the reuse of "v=spf1" records for the PRA algorithm in the Sender ID specification.)

You correctly point out that a communication standard is little more than a silent agreement between senders and receivers that only works if the receiving party tries their best not to misinterpret what the sending party meant. But then you simply quit the subject, assuming that communication standards will work even with everyone interpreting stuff their way, because, after all, there is no protocol police, thank you. Sorry, but "compatible" means something else to me.

We had agreement in the WG to proceed on a common spec and nobody found any problems until the patent issue was raised.

Again you are missing the facts. Quoting from my appeal to the IESG:

It is also worth noting that at the time the MARID WG was closed [in September 2004], the then-current Sender ID specification draft-ietf-marid-protocol-03 did not include the re-use of "v=spf1" records for PRA checking. This was only introduced in [Microsoft's] individual submission draft-lyon-senderid-core-00 in October 2004. Also did Microsoft's record generation wizards generate only "v=spf2.0/pra" records until the end of October, when they began generating only "v=spf1" records.

Read the appeal. It connects a lot of dots that many do not like to remember.

Look into dchroot and setup a small 32bit chroot environment. On my AMD64 desktop running Ubuntu, I have Firefox, Adobe Acrobat, a 32bit JDK and Mplayer installed and it works like a champ. HOWTO here.

http://www.us.debian.org/CD/vendors/#us

I'll bite...

And yet, Linux continues to be the same impossible-to-use monstrosity it has always been.

My wife and kid do fine with it, thank you very much, and we do a lot more with our computers than most folks I know.

It is truly fascinating how the open source community can stand there like deer in the headlights congratulating themselves on how their most powerful competitor is learning so much from them. Microsoft is now creating open standards, open formats, even open source applications - not one hundred percent of the time, but hey, they're doing it! They're starting to look more and more like us.

You are correct, not 100% of the time. In fact, not even 0.1% of the time. But if they open up at all, that's a good thing. It's not a competition in the traditional sense of snarfing up market. It's a competition to be Free, which is a win-win, always. If they become more Free, good. It's not like Free has to try to be less Free in order to 'compete'.

Hey, wait a minute. Why don't we look more like Microsoft? Where's our readily accessible documentation localised in dozens of languages?

Here.

Where's our toll-free licensing hotline?

Not necessary. We don't compete on their terms! But if you must, this will do...

Where's our reliable and knowledgeable tech support team?

Choose your interface. I like this. BTW, it is very difficult and unwieldy to get MS tech support (human, not website) for the average user. I have never heard anyone say, "Gee, MS tech support is so reliable, knowledgeable, and easy to use!"

Our software assurance subscription that actually sends a disc in the mail when there's an update?

1990 called, they want their software distribution model back!

apt-get update && apt-get upgrade

You know what really bugs me? That last one. I used to pay $4.95 a month for a quarterly package of three major Linux distributions. I liked that. So how come now I only get that from Microsoft?

Apples and oranges. MSDN releases are limited. Linux distributions are free to use as you please.

Honestly, people. Why is Microsoft getting so much better, while *we're* really starting to SUCK?

ROTFLMAO!! We continue to get better all the time, certainly at a faster rate than the 'competition'. I would know, I actually -use- Free software, instead of trolling about it.

And on a more pressing note, just look how much closer those headlights are getting! So how many seconds to *SPLAT*?

There is no splat. Free is pretty tough to make go away.

Another promising app for amateur photographers that I use for all my pictures:
http://www.digikam.org/
Version 0.9 beta includes 16 bits color depth.
Debian packages: http://packages.debian.org/experimental/graphics/d igikam
Better than screenshots: four movies showing whet you can do with Digikam. Movie number 1: http://www.digikam.org/?q=node/124

C and C++ are portable and MUCH faster than perl:
http://shootout.alioth.debian.org/gp4/benchmark.ph p?test=all&lang=gcc&lang2=perl
http://shootout.alioth.debian.org/gp4/benchmark.ph p?test=all&lang=gpp&lang2=perl

And if we are going to go high level then there's no reason to use perl either because there are much more readable/maintainable languages in the same speed class:
http://shootout.alioth.debian.org/gp4/benchmark.ph p?test=all&lang=python&lang2=perl

Case in point - google uses C for their fast stuff and Python for the non-performance related stuff. I am sorry, but you can't make a case for perl to anyone but perl programmers these days whereas languages like ruby and python have strong cases to be made for them.

C and C++ are portable and MUCH faster than perl:
http://shootout.alioth.debian.org/gp4/benchmark.ph p?test=all&lang=gcc&lang2=perl
http://shootout.alioth.debian.org/gp4/benchmark.ph p?test=all&lang=gpp&lang2=perl

And if we are going to go high level then there's no reason to use perl either because there are much more readable/maintainable languages in the same speed class:
http://shootout.alioth.debian.org/gp4/benchmark.ph p?test=all&lang=python&lang2=perl

Case in point - google uses C for their fast stuff and Python for the non-performance related stuff. I am sorry, but you can't make a case for perl to anyone but perl programmers these days whereas languages like ruby and python have strong cases to be made for them.

C and C++ are portable and MUCH faster than perl:
http://shootout.alioth.debian.org/gp4/benchmark.ph p?test=all&lang=gcc&lang2=perl
http://shootout.alioth.debian.org/gp4/benchmark.ph p?test=all&lang=gpp&lang2=perl

And if we are going to go high level then there's no reason to use perl either because there are much more readable/maintainable languages in the same speed class:
http://shootout.alioth.debian.org/gp4/benchmark.ph p?test=all&lang=python&lang2=perl

Case in point - google uses C for their fast stuff and Python for the non-performance related stuff. I am sorry, but you can't make a case for perl to anyone but perl programmers these days whereas languages like ruby and python have strong cases to be made for them.

I haven't followed the guts of the issue, so I'll ask: Is the Debian POV that although someone shouldn't be able to use the trademark (and misrepresent the source of the product), they should be able to create derivative but dissimilar marks? I don't see much other use of a (C)No/(TM)Yes logo.

Yes. Debian comes with over 15,000 packages, all of which are classified into one of three sections:

• 'main' -- packages that comply with the Debian Free Software Guidelines and do not depend on other software which doesn't
• 'contrib' -- packages that comply with the DFSG, but do depend on other software that doesn't
• 'non-free' -- packages that do not comply with the DFSG

The DFSG requires that "The license must allow modifications and derived works". Debian do not want to change the DFSG, according to which over 15,000 packages have been classified, just for Mozilla Corporation, especially since there is absolutely no point in doing so. Mozilla Corporation's trademarks are already trademarked. They do not need to be copyrighted too. Therefore, instead of changing the DFSG, they chose not to use the Firefox logo.

http://lists.debian.org/debian-lex/ No recent posts in this one, but feel free to post something, anything (it can't get worse, can it, you'd be competing against spam:-)

$ objdump -p /usr/lib/firefox/firefox-bin | grep gtk
    NEEDED libgtk-x11-2.0.so.0

$ dpkg --search /usr/lib/libgtk-x11-2.0.so.0
libgtk2.0-0: /usr/lib/libgtk-x11-2.0.so.0

$ dpkg --status libgtk2.0-0 | grep Version
Version: 2.8.20-2

$ firefox /usr/lib/firefox/firefox-bin: undefined reference to gtk_print_new

ftp://ftp.debian.org/debian/pool/main/f/firefox/ Those ending in orig.tar.gz and diff.gz are source files, the .dsc are probably useful as well as it contain build-depends.

http://packages.debian.org/cgi-bin/search_packages .pl?keywords=firefox&searchon=names&subword=1&vers ion=stable&release=all

I don't know what you're talking about. Firefox 1.0.4 seems to still be supported.