Shuttleworth is the Zuckerberg of free software. Since the Linux crowd has been gullible enough to believe you don't have to pay for advanced software tools, now he's out to sell your data. What is the poor man to do, if he wants a little profit? Surely, he can't keep paying his employees, dedicated full time to fixing Debian's shortcomings, out of his own pocket, can he? So he's gonna sell YOU.

All should be well in your philosophy, because Free Software is made effortlessly. The only people that have to pay for their own tools are the 99% of non-TI workers: the doctors, the carpenters, the farmers. They must buy microscopes, endoscopes, a wood saw, a truck, a tractor. But people who need compilers must not. Software falls off a tree. Or it's magically made by the Debian packagers. Wait...But what do they "package"? Oh, that's right! Software made by other people! Oh, my! I'm so confused...

The part I don't really grasp is...do you *actually* pay for hardware ?! If so, then why?! Why don't you just grab a notebook and run out of the store?!

Kids who've got no important data, no important software they're writing, no important network set-up, that is, kids who just sit at mom and pop's basement, with a Windows machine by their side, keep recommending that you reinstall all the time.

WTF do you want? You do not want to pay for software, you want it free, but since the Free Software crowd in Linux is unable to deliver a decent experience, you've welcomed Mr. Shuttleworth's Wonderful Piggybacking Adventure in Debianland. Now, how do you expect he should pay his employees and run a business?

This is what happens, kids. You've been told you are to pay for nothing. You've been told that advanced software should be free. Never mind that you still pay for hardware, or cars, or power tools at your garage (a contractor pays much more for his tools than you have come to expect to pay for yours, although most of your tools are offshoots or direct products of PhDs). But software! Hey, software should be free as shit is free! You've been told supporting businesses is illegal - almost - or at least immoral. Now you get what you pay for.

So, stop complaining and quit with the whining. Or face the fact that free as in "libre" software is only free because someone else is freeing up the costs for you (by either entering the GPL/proprietary double-blind cynical scheme, or using a business-friendly license). There is no free lunch. There is no pool of full time experts in free software. Experts don't work for nothing. Only the low-skilled works for nothing. Everybody's gotta eat, and not everyone is a lonely celibate as Stallman, that can just go around collecting money for his Church.

You keep kidding yourselves that Linux is the victor of Free Software, when all it was was part of an IBM backed-up business plan to kill proprietary Unixen. Linux is driven by corporations, and now you will begin to eat each other's livers. All that will remain is going to be Shuttleworth's Spyware Machine and Red Hat's per seat licenses. Debian sucks, Fedora is the RedHat dump site, Mandriva is moronically managed, SuSE - wtf is SuSE?, and all the small distros are insignificant. You thought being business-hostile was good, but you've embrace hypocrisy to the utmost, while deriding the BSD distros, which never claimed to ride such high horses of morality and always supported businesses.

You want it all, but you can't have it...

Emacs is great for doing some text processing text you might otherwise do with, say, a Perl (or whatever) script.

I'm not talking about the equivalent stuff you can do in Vim too. AFAIK, you can do "batch text processing" with Vim, but it's not nearly as sophisticated as Emacs, simply because emacs has emacs lisp, with its huge number of primitives for text processing. It's not a coincidence that, whenever someone wants an editor to understand the syntax of their new, "crazy" (or maybe "cutting edge"), programming language somebody writes an Emacs mode for it.

Emacs power user Xah Lee has many examples for Emacs in the context of text processing at his site:

http://ergoemacs.org/emacs/elisp.html

Although Vim is a powerful editor, it certainly is a primitive experience writing code in it, in particular when you compare it with the syntax and error checking today's best tools can do (such as the awesome Xcode). So, I can see why people like Vim (it's very ergonomical) but, down the road, I don't see people programming with it for much longer.

Emacs OTOH has a whole lot more to offer. And every once in a while talks of re-writing Emacs in Common Lisp come up. Now that would be something!, because you would potentially end up with an excellent tool with GUI capabilities (see: http://en.wikipedia.org/wiki/Common_Lisp_Interface_Manager), that would simply rock for the creation of more & better non-proprietary IDE tools. Of course, that involves re-implementing CLIM (available on proprietary Common Lisp IDEs, so no-one really cares to), because of the GPL license (yet another example on how the GPL is counter-productive).

My left hand prefers Emacs, but my right hand like Vi.

I'm not sure, but there might be non-C system code in OS X (Objective-C) and Windows (C++, C#). In FreeBSD, there's Forth in the bootloader (does that count?).

I think you meant: Linux developers only use C for system programming.

Sounds like you are unaware of the algorithm benchmarks regarding Lua's register-based JIT.

Sounds like you are unaware that heavy-players in the video game industry *all* mix & match Lua and C++ for their engines.

Wow! You must know something we don't! Why don't you get a job in a big software house in the games industry and tell them how *wrong* they all are?

Apparently, a lot of people in the software business have trouble with pointers. That includes Linux, and its many, many security breaches and flaws in its history. Of course, I'm not calling people stupid. I'm simply stating what is widely known. Safe programming is hard. Pointers are error-prone. People who deny that are either superbly arrogant or ignorant of the many serious events in the software industry. If you can avoid unsafe code by using a safer language, than you ought to. You don't seem to have read this bit: "No access to kernel memory, -functions but through predefined binding."

Your assuming NetBSD developers are morons shows how ignorant you are. Have you ever even looked at *BSD system code?!

So Smalltalk is not OOP, right?

The problem is that people look at Perl - without having learned it - and say "unreadable!"
That really is the kind of circular thought only stupid people can achieve - "I dunno Perl, so I can't read Perl, so I don't know Perl, so I think it's unreadable (...)"
Now, anybody seriously considering reading large arrays into Perl can ask the Bioinformatic guys how Perl is cutting it for them, or also choose to use the Perl Data Language which seems good enough for some guys in an Astrophysics department.

Perl is not black magic. It just takes reading the Camel book.
Now, if you don't, you will see consctructs that will make you go "Wow, how did he come up with that?!".
Some people don't want to read...There's nothing Perl or Larry Wall can do about that...

When you say "Perl is scary" I take it you mean that you don't like TIMTOWDI.
I have often pondered about this. It seems a simple design has its advantages - you quickly pick up the simple rules, and away you go. Now, there's an aspect of engineering. Java, Python, they might be better for the larger software houses, in the sense that they facilitate things for the "code monkey". There's nothing wrong with that job position, although the term is derrogatory. Eiffel, for example, is a well-designed language that takes that approach very explicitly (they even say there's no space for the "language guru" in Eiffel).
But Perl is no more scary then C++. C++ is large, complex, full of hidden gotchas. That never stopped it from being used at a very large scale.
I really feel most arguments against Perl are lazy and not well thought out.
Let's say Perl is "complex", like, say Common Lisp is "large and complex". I tend to think these complex languages are the languages of the experts, the power-users. The language bend and twist to the expert's desires. This makes them achieve great productivity.
The point being, there's a learning curve to Perl (not much, it takes reading the Camel book) and other "complex" languages, but there's a pot at the end of the rainbow in personal satisfaction and productivity.

Exactly...WTF!
Perl and Perl's hacker community, when you think about it, did amazing feats, bending Perl to take whatever shape they wanted/needed.
People wanted OOP - Perl's closures allowed that. Perl's OOP is better than most would think. (Read: Object-Oriented Perl).
Want to program in functional-style? They proved you could do a lot of FP stuff in Perl. (Read: Higher-Order Perl).
They even went ahead and gave Perl a Meta-Object Protocol, sort of CLOS-style (CLOS = Common Lisp Object System, which some would argue is the most advanced out there).
And Perl is pretty fast, when compared to Python or Ruby.With a huge number of libraries (CPAN).
So Perl is pretty successful and has held its own as one very flexible language. The fact that the language did not change much, and yet achieved so much, is really a testament to its happy, fortuitous design.

IMHO some mistakes were made in not supporting things that are not Perl per se, but would be crucial in a modern programming language:
- Perl is a PITA for C-interoperability and a lot of Python these days is about, in fact, using a deeper C layer (why not more Lua, then?). C is crucial for speed (that means number-crunching and graphics), for software re-use, and its *the* lingua franca of software.
- Some sort officially-sanctioned GUI should've been adopted. Again, this isn't Perl per se, but having mult-platform GUI support could've secured a better position at the desktop space (but most Perl people work at the data center/server level).

And then there's Perl6...Perl6 was supposed to be great - its design is great - but IMHO the developers made the mistake of forgetting the lessons of the past, forsaking an advanced functional language for the implementation of complex language features - this despite Audrey Tang's effort - and then got caught in a labyrinth they can't get seem to get out of. And this move might have been caused by pure prejudice against Haskell or sheer stubborness, I don't know.

Whatever the reasons (and to be fair, one got tired of following the slow progress of Perl6), letting Pugs die when Audrey had done so much by herself just didn't seem rational at all. Maybe it was, maybe it wasn't, but if the history of programming languages servers as a parameter, the odds were in favor of a Haskell (or SML, or Ocaml, etc.) implementation, because the advanced features Perl6 was aiming for, to my knowledge, were never decently implemented with the usual bag of C-oid tools (the olnly thing that comes to mind is Mathematica, which was very buggy in its initial version, when compared to Maple). Smalltalk, Lisp, etc. They all seem to built some sort of interpreter or language kernel and grow the language from there. It doesn't seem that was what the Perl6 implementors were doing. It's almost as if they were emulating the Java developers - and we know how long it took then to implement a modicum of advanced language features over there...

I agree with him. Paypal has a terrible track record, and if a moderately successful fundraiser can cause them to seize funds. Since the shelter isn't a business with a track record of sales, it could take significant effort to get access to those funds. And since Paypal isn't a regulated bank, there's no recourse other than taking them to court.

Paypal is convenient, and is only worth the risk if you can afford to lose the transaction.