Perl's still more convenient for text processing than Python, because regular expressions are part of the language instead of being in a module, as in Python. But, since there are lots of people who don't do text processing, that's not much of a disadvantage.
Java hackers should take a look at JPython, a 100% Pure Java reimplementation of Python that's an astoundingly cool tool for prototyping and testing Java code.
People interested in the Web should look at the recently freed Zope; the documentation still needs work, and lots, lots more examples, but it's also a very powerful publishing system.
That's not really a new thing; their Linux books seem to use old-style drawings of cowboys (Running Linux, Olaf Kirch's networking book), and their Java books use digitally manipulated stock photos. Didn't one security-related book in the Nutshell series use an image of a lock and key?
Well, there was that one issue of the Python Journal that came out a while back, but I'm not sure what the status is at the moment. (On the other hand, setting a deadline for the next issue would mean I'd have to finish my article. Hmm... decisions, decisions.)
O'Reilly also pays Larry Wall, and now Brian Behlendorf. They've flown people like Guido van Rossum to their summits, and they're encouraging people to write more books (and providing the requisite editorial assistance, which is no trivial thing). O'Reilly also mostly documents free software, which encourages more people to use it. What's to complain about?
(Yes, I agree with RMS that free manuals would be better, but not many people work on writing them.)
Why bash Digital Creations? They've modified their license, changing the attribution from a requirement to a request that can be ignored if you like. DC staff, most notably Jim Fulton, have contributed various things to the Python distribution, which is free software. While the whole attribution thing was ill-advised, and I still think it shouldn't be in the license (why not just leave it in a README?), claims that they're "starting to twist free software" are utterly bogus.
I once wrote a review of the Unix-Haters Handbook. Briefly, my opinion was that many of the complaints were about little buglets that could be fixed if you had the source code (and some of them *are* fixed in current GNU/Linux distributions), some were valid criticisms (X Windows, poor security model), and some were religious issues (filenames being case-sensitive).
If you really can't handle Perl, Python is probably your next best bet. It is ultra-clean in design, and ultra OO. But waaaaay less fun.
Actually, I've found it great fun; the user community is generally quite clever, and comp.lang.python is my counterexample whenever someone claims that all Usenet newsgroups are swamped in noise. Tim Peters's postings alone are worth the price of admission. (Recently I've noticed a sharply increasing number of simple questions from newbies on c.l.p; while that's good because it means the language is becoming more popular, I hope it doesn't change the newgroup's chemistry too much.)
Also, try attending one of the Python conferences; they've been great fun for techies. At IPC7, the most recent conference, guess which presentation sparked the longest question-and-answer session? Ivan van Laningham's talk on the Mayan calendar. The session on parsers also interested a lot of people, and I netted a bunch of quotations for my Python quotation file; lots of Python users seem to be parser geeks, too.
IPC7 also featured David Beazley's hilarious talk on Python and supercomputing, another audience favorite. Since he also talked a good deal about LLNL's Beowulf system, it would be on-topic for a Linux conference; someone should invite Beazley to Linux Expo. (Hint, hint...)
I think O'Reilly's point was that, originally, hardware was the most important thing; you bought an IBM System 360, or a PDP-11, or whatever. Then the focus shifted to software; you now buy Windows or Unix, in order to run Excel or Oracle. Whether it runs on a chip made by Intel or AMD, Sun or Digital, isn't the focus. The way O'Reilly mentions infoware, he's forseeing a shift away from software, where you run little snippets of code inside a browser or Web server, which perform useful operations with a large data collection, such as the purchasing patterns of Amazon's customers. *Which* browser or Web server would, presumably, become irrelevant over time.
And open source, because of the peer review which it allows, has often been compared to the process by which science refines its results and corrects errors, so the comparison isn't that far-fetched.
Not a solution. Copyrights, like munitions trading, are also subject to international agreements between countries. It's only a matter of time before attempts are made to harmonize duration of copyright across countries, much as the Wassenaar agreement attempted to harmonize crypto export rules. If that happens, switching countries won't help. (But I do hope that we can manage to prevent Canada from doing this.)
better-than-ever-before VM system?
on
Batch o Quickees
·
· Score: 1
As far as I can tell, it's not a massive rewrite from the ground up, or anything like that, just lots and lots of little tuning tweaks: a change to how priority is calculated here, swap out pages slightly differently there. Most of the improvement seems to be from smarter swapping; one person reported a compile in 128MB going from 280sec down to 119sec. Poking through the list archives at the Linux-MM page will produce lots of info.
But yes, it is surprising that it's being done this late, at the 2.2pre stage. I suppose the potential improvement is so significant that Linus feels that getting it in for 2.2 is worth the risk.
One obvious course of failure is to argue endlessly on mailing lists and then not write any code, as Alan Cox pointed out in his "Town Council and the Bazaar" editorial on/.
A related failure is being too ambitious at the start, something I've noticed a lot in the Python community. Someone has a simple idea, and asks for suggestions; people then point out all sorts of special cases that should be handled (what if you're on Windows or Mac? what if you're building a really large system? what if...). This makes the implementation job look so difficult and frightening, so no one does it.
OSS also needs to have the right architecture, I think. It has to be either small, or large but strongly modularized so people can contribute little things. For example, it's relatively easy to write a single device driver, Python extension, GIMP plug-in, or Emacs mode; let enough people nibble away for a few years, and you wind up with a very capable system. Something like Samba or Wine may be so monolithic and large, by the very nature of the problem being solved, that it's difficult for people to contribute. The initial Mozilla code was tangled, having many complex interdependencies between modules, but they've been successfully working on cleaning up the code base.
This may be another OSS benefit; to succeed, projects have to pay more attention to software engineering virtues such as modularity and clarity. Badly-structured commercial projects may just barrel ahead anyway, because they have outside forces pushing them onward; badly-structured OSS projects probably just die.
Offhand, I can't think of other OSS projects that have sputtered along, failed, or fallen into decay; can anyone think of more?
Parallel port scanners are difficult to support because the protocols are specific to each model, and often companies don't release the info so someone can write a driver. This is similar to video cards, where companies are also reluctant to release programming info; most of the video card manufacturers such as Diamond and Matrox are cluing in, and maybe scanner manufacturers will figure it out, too.
SCSI scanners, on the other hand, are much easier to support, because there's a generic spec for scanning over SCSI. I've also noticed USB scanners appearing in stores; judging by the USB device class documents, USB scanners will be closer to SCSI than parallel-port. While there's no document on that page which mentions scanners, USB does seem to work by having different devices supporting the same interface. So maybe, once USB replaces the parallel port at the low end, we won't have to worry about getting stuck with a scanner that doesn't work.
Slashdot Mirror
Anyway, most things can be found on www.python.org. Many people started off with GvR's tutorial; O'Reilly's "Learning Python" book is currently scheduled for release in April.
Java hackers should take a look at JPython, a 100% Pure Java reimplementation of Python that's an astoundingly cool tool for prototyping and testing Java code.
People interested in the Web should look at the recently freed Zope; the documentation still needs work, and lots, lots more examples, but it's also a very powerful publishing system.
That's not really a new thing; their Linux books seem to use old-style drawings of cowboys (Running Linux, Olaf Kirch's networking book), and their Java books use digitally manipulated stock photos.
Didn't one security-related book in the Nutshell series use an image of a lock and key?
Well, there was that one issue of the Python Journal that came out a while back, but I'm not sure what the status is at the moment. (On the other hand, setting a deadline for the next issue would mean I'd have to finish my article. Hmm... decisions, decisions.)
(Yes, I agree with RMS that free manuals would be better, but not many people work on writing them.)
Why bash Digital Creations? They've modified their license, changing the attribution from a requirement to a request that can be ignored if you like. DC staff, most notably Jim Fulton, have contributed various things to the Python distribution, which is free software. While the whole attribution thing was ill-advised, and I still think it shouldn't be in the license (why not just leave it in a README?), claims that they're "starting to twist free software" are utterly bogus.
I don't believe it's possible to open a US bank account without an SSN; when I moved to the US, I had to get one before doing any banking.
I once wrote a review of the Unix-Haters Handbook. Briefly, my opinion was that many of the complaints were about little buglets that could be fixed if you had the source code (and some of them *are* fixed in current GNU/Linux distributions), some were valid criticisms (X Windows, poor security model), and some were religious issues (filenames being case-sensitive).
Actually, I've found it great fun; the user community is generally quite clever, and comp.lang.python is my counterexample whenever someone claims that all Usenet newsgroups are swamped in noise. Tim Peters's postings alone are worth the price of admission. (Recently I've noticed a sharply increasing number of simple questions from newbies on c.l.p; while that's good because it means the language is becoming more popular, I hope it doesn't change the newgroup's chemistry too much.)
Also, try attending one of the Python conferences; they've been great fun for techies. At IPC7, the most recent conference, guess which presentation sparked the longest question-and-answer session? Ivan van Laningham's talk on the Mayan calendar. The session on parsers also interested a lot of people, and I netted a bunch of quotations for my Python quotation file; lots of Python users seem to be parser geeks, too.
IPC7 also featured David Beazley's hilarious talk on Python and supercomputing, another audience favorite. Since he also talked a good deal about LLNL's Beowulf system, it would be on-topic for a Linux conference; someone should invite Beazley to Linux Expo. (Hint, hint...)
And open source, because of the peer review which it allows, has often been compared to the process by which science refines its results and corrects errors, so the comparison isn't that far-fetched.
Not a solution. Copyrights, like munitions trading, are also subject to international agreements between countries. It's only a matter of time before attempts are made to harmonize duration of copyright across countries, much as the Wassenaar agreement attempted to harmonize crypto export rules. If that happens, switching countries won't help. (But I do hope that we can manage to prevent Canada from doing this.)
But yes, it is surprising that it's being done this late, at the 2.2pre stage. I suppose the potential improvement is so significant that Linus feels that getting it in for 2.2 is worth the risk.
One obvious course of failure is to argue endlessly on mailing lists and then not write any code, as Alan Cox pointed out in his "Town Council and the Bazaar" editorial on /.
A related failure is being too ambitious at the start, something I've noticed a lot in the Python community. Someone has a simple idea, and asks for suggestions; people then point out all sorts of special cases that should be handled (what if you're on Windows or Mac? what if you're building a really large system? what if ...). This makes the implementation job look so difficult and frightening, so no one does it.
OSS also needs to have the right architecture, I think. It has to be either small, or large but strongly modularized so people can contribute little things. For example, it's relatively easy to write a single device driver, Python extension, GIMP plug-in, or Emacs mode; let enough people nibble away for a few years, and you wind up with a very capable system. Something like Samba or Wine may be so monolithic and large, by the very nature of the problem being solved, that it's difficult for people to contribute. The initial Mozilla code was tangled, having many complex interdependencies between modules, but they've been successfully working on cleaning up the code base.
This may be another OSS benefit; to succeed, projects have to pay more attention to software engineering virtues such as modularity and clarity. Badly-structured commercial projects may just barrel ahead anyway, because they have outside forces pushing them onward; badly-structured OSS projects probably just die.
Offhand, I can't think of other OSS projects that have sputtered along, failed, or fallen into decay; can anyone think of more?
SCSI scanners, on the other hand, are much easier to support, because there's a generic spec for scanning over SCSI. I've also noticed USB scanners appearing in stores; judging by the USB device class documents, USB scanners will be closer to SCSI than parallel-port. While there's no document on that page which mentions scanners, USB does seem to work by having different devices supporting the same interface. So maybe, once USB replaces the parallel port at the low end, we won't have to worry about getting stuck with a scanner that doesn't work.