I've moderated my opinion on Gaiman over time; though my opinion about specific stories have shifted, I still think Sandman is excellent. (For example, while "Brief Lives" was coming out month-by-month, I thought the arc was far too scattered and diffuse. Re-reading the TPB, it hung together better.) But nothing of Gaiman's other work has been anywhere near that level; Angels and Visitations, while some of the stories were reasonably good, left me cold, and most anthologized Gaiman stories have been unremarkable, Signal to Noise was underwhelming, etc. The faux-Dunsanian prose of Stardust was a notable exception that I loved, and I haven't gotten around to Neverwhere, though I really should.
So, I think of Gaiman the same way I think of Mike Oldfield or Peter Greenaway -- they're all people who can do incredibly good work, but who seem to have moved in directions that I don't like much. Oldfield tries to write pop tunes; Greenaway turns his back on characterization; Gaiman writes stories that rarely have much emotional impact.
Millennial hysteria in 1000
on
The Year 1000
·
· Score: 3
Peter N. Stearns wrote a good book called "Millennium III, Century XXI", on how people react to artificial calendrical times of transition. One thing he points out is that the idea of widespread hysteria in the year 1000 is a myth. Several different calendrical systems were still in use at the time, and the current system wasn't the most common one. (As late as the 14th century, people were still often dating things as "In year X of King Y's reign", for example.)
So where did the idea of panic in the year 1000 come from? Mostly it came from Enlightenment-era historians, who were often anti-religious; ISTR that Stearns points at Jules Michelet as originating the story in his history of France, Because it agreed with their prejudices, other historians gave Michelet's stories wide exposure, but there doesn't seem to be any actual historical evidence for them.
I don't know. It's far more complicated, but it also does a lot more, and has different design criteria. XML-RPC is just that, remote procedure calls. Finding the right XML-RPC server, determining what methods it supports, and similar resource discovery are all outside of XML-RPC's province; you'd have to invent your own techniques on top of it. E-speak provides a lot more, but this exacts a cost in increased complexity. We'll see how it turns out.
It seems to be a set of APIs for writing components that either provide a service of some sort, or access some such service. This sort of thing is greatly needed, as shown by all the various efforts that have been springing up - XML-RPC is one, SOAP another, and E-speak yet another. E-speak seems far more complex than the others -- my head exploded a few times while trying to read the architecture document -- but then it's tackling the problem at a much higher level than the other protocols. Maybe I need to try struggling through the docs again. (You have to register as a developer to get your paws on the programming docs, but it's free.)
Note that HP has a bunch of RFPs on Source Exchange that are related to E-speak.
You're a bit overoptimistic about the re module's performance; current Perl versions have all sorts of optimizations that the underlying PCRE library doesn't have yet. But this also makes the Perl regex engine's code very hard to understand, and effectively impossible to divorce from the rest of the Perl interpreter. (I'd love to see someone prove me wrong and create a perlre.a, but it seems unlikely to happen.)
Ah, Modula-3; my favorite counterexample to the idea that hackers always choose tools because of technical merit. Modula-3's been around since about 1990, and in having garbage collection, integrated threading features, runtime checking, exception handling, and OO, it's an important precursor to Java, in addition to influencing Python's design. (The first time I read about Java, I thought "This is a lot like Modula-3, just using C syntax.") M3 came as a freely available compiler (a patched version of GCC) that compiled to native code; no one ever proposed a Modula-3 VM. People at DEC SRC experimented with GUIs and distributed computing using M3. You could have had most of the features of Java in the early 90s using free software, yet M3 never caught on, mostly because of the superficial syntactic issue of being a Pascal/Modula-derived language, not a C-like one. M3 also produced rather large binaries because of the supporting libraries, but Java VMs are even larger today, and much slower. Pity, really; I hope an M3 front-end finds its way into EGCS, giving this language another chance.
Also, if you read LinuxToday, you might have noticed the recent announcement of the Python Consortium being formed. HP is one of the initial members, and they're hardly an insignificant company.
with more and more sites using Open Directory data, it's making portals look more and more similar. I wouldn't say that this is neccesarily a Good Thing?
I think this is good. Most general-audience portals wind up looking pretty similar anyway, and there's the vast duplication of effort of having different people maintain their collections of links. (Specialized portals aiming at a given target market can always beat the generalized portals, of course.)
A second effect is that this makes dmoz.org's data more important, and may make it worthwhile for companies to help maintain the database. For example, at work we've been considering helping maintain the Science:Engineering:MEMS section on dmoz.org, because we can re-use the data on our site, and this results in better information for the MEMS community, even if they use Excite or, now, Altavista. I hope Excite or Altavista will pay for a few staffers to be ODP editors.
Solid's a fairly nice database, though it lacks advanced features such as triggers. (It does have transactions, though, which is all that I really need.) However, Solidtech reworked their business plan about 6-9 months ago, and they're now mostly interested in customers who want to embed their database in an application and redistribute it 10,000 times; they're not very interested in supporting individual users who just want a single installation for running a Web site. This change caused a lot of bitterness on the solid-list mailing list, and many users, who'd gone out on a limb by recommending Solid instead of Oracle, were very angry. Most of them seem to be drifting away to other databases now.
I sit in front of an 300 MHz Ultra 10 all day. It was purchased around the same time I bought a 266MHz machine from VA Research. Both machines feel about the same speed, with maybe a slight advantage to the Linux box. The major differences are that the Sun cost twice as much, comes with far less interesting software, and occasionally the CD-ROM will lock up, requiring a reboot to fix it. I can't see any reason to purchase a Sun workstation for your desktop, unless there's some Solaris-only application you must run. I'm not negative about Sun for high-end servers, but at the low-end I see no reason to bother with a Sun box.
At the last Python conference, Paul Dubois of LLNL talked about a package that let you write Python extension modules in C++. What was really neat about this was that, because of operator overloading, the C++ code looked a lot more like the corresponding Python code. For example, instead of writing PyDict_GetItemString(dict,"foo"), you could code dict["foo"]. Instead of checking for a NULL return value, it would raise an exception that you could catch, so the code was simpler and easier to read. GvR found this pretty impressive, and said he'd keep this in mind if/when the interpreter is ever rewritten from the ground up.
So, I'd expect a similar design decision was made for Topaz. In interpreters you have to deal with data structures that represent scalars, arrays, dictionaries, etc., so an OO approach might let you avoid hard-wiring an expected type, in favor of an expected interface. Whether this will pay off significantly is the purpose of the experiment.
They've also prevented translations to other languages. Someone wanted to translate the code into Modula-3, keeping equivalent function signatures; he was told that the authors considered the function signatures to be a copyrighted interface, and would not permit the translation. (This argument seems bogus; if it was correct, AT&T/Novell/whoever could sue the authors of Linux and *BSD for providing similar interfaces to their product.)
Literate programming is a brilliant idea, but CWEB is not, IMHO, a winning implementation of it. When I've experimented with a similar system for writing a literate C program, I found it difficult to keep two separate orderings accurate. One ordering is the sequence of the text. The other ordering is the parts of a C file: #includes first, some function prototypes, then the actual functions. It was tedious to get the generated code to have the pieces in the right order to avoid compiler warnings, and required uninteresting sections containing only references to subsections. IMHO, you'd need a smarter tangler (the program that goes through your input and generates the compilable code) that could recognize #includes and put them up top, automatically generate prototypes for you from your function definitions, and handle such bookkeeping for you.
Literate programming is also best suited for explaining code that requires complex algorithmic or logical reasoning; I can't imagine writing a literate CGI script, for example, because most of the text would be uninteresting, "here we check if the 'run' form variable is set...". LP would be great for compilers and optimizers, regex engines, numerical software, and other programs where the logic of the code is complex and involves external information such as proofs.
Note that David S. Miller, who did lots of TCP and MIPS porting work, was employed by Cobalt for a while, so they've already made some contributions. Most of the non-x86 ports require patches to Linus' kernel tree, so the MIPS port isn't unusual in that respect.
Albert Pisano, the outgoing DARPA program manager for MEMS, likes to talk about building a MEMS dandelion seed, a few mm in diameter. (I saw him deliver the talk at GWU, and he's also given it at NIST.) With current process technology, an old processor like the 8088 would easily fit in that space; in fact, you could get a few hundred 8088s in that space, so computational power isn't a problem. Add power generation, sensors, and radio communications, and you're on to something!
I work on software for a MEMS-related project (the MEMS Exchange). It's an interesting field, and one that's already having an impact in specialized areas like accelerometers, and is very close to becoming widespread.
Umm... someone has already done this and called it Alice; take a look at the Alice tutorial. This is one of the inspirations for the CP4E effort, because it's been really successful at letting non-programmers do interesting things.
This project is at least partially inspired by Randy Pausch's use of Python in Alice, a 3D VR system for non-programmers (unfortunately Windows-only, but well worth checking out). Pausch gave an interesting talk at work about Alice, and showed some spectacular demos; it was impressive to see an Akira-inspired motorcycle ride through a cityscape, implemented by people after a single-semester course. Alice is used in a virtual-worlds course at CMU; students with no previous programming experience are expected to present their first VR environment two weeks after the start of the course.
The Alice developers modified Python in a few way to make it easier for their intended audience. The major changes were:
Case-insensitivity: Pausch said that having 'Fred', 'fred', and 'FRED' be different variable names was confusing to their students.
Python's numeric types work like C's; 3.0/2 is 1.5, but 3/2 is 1 (because both inputs are integers, therefore the result is also an integer). This is hopelessly confusing, so in Alice 3/2 is 1.5.
Those are the only changes I can remember from the talk, and it's a remarkably short list. They also avoided using XYZ coordinates, instead using object positions and directions. For example, you can say rabbit.lookAt(copter), after which an Energizer bunny object will always stare at a helicopter, no matter where the copter object is moved. People had no trouble with the idea of objects, but little things like case-sensitivity threw them.
Correction: ABC was a language designed by Steven Pemberton, on which GvR worked as an implementor. ABC's original goal was as a teaching language, and apparently they did actual human-factors research before creating the language, leading to the language's use of whitespace, among other things.
One lesson GvR took away from ABC was the importance of OS interfaces; in ABC you couldn't walk through directories or open files, though it provided persistent variable storage that was an abstraction on top of files. This made ABC a nice sandbox to play in, but you couldn't get out of it, and ultimately this proved too confining.
Actually it's because implementing table support in Lynx would be really hard, because it requires a re-entrant parser. Unfortunately, having been written long before tables were around, Lynx's parser uses lots of global variables; to make the parser re-entrant, you'd have to put all these globals in a structure, and change the signatures of lots of functions to pass such structures around. No one has yet stepped up to the plate to do this because it would be so much work.
No technology is self-sufficient, and ignoring the entire CORBA/Enterprise Java Beans space was a major mistake.
Zope's predecessors, Principia and Bobo, date back to 1996, long before EJB (or even JavaBeans) existed, so it's not surprised that they're not supported. If anyone actually cares about EJB, I'm sure people will work on bridging to them.
Correct. For example, Fredrik Lundh's Python Imaging Library can output GIFs (along with a bunch of other formats), but the GIFs are really large because the image data isn't compressed. Apparently at one point he contacted Unisys to ask if he could get a licence for the patent, but Unisys wanted a per-sales fee and reacted uncomprehendingly to the words "free software". If, as another poster claims, Unisys is now accepting a one-time fee for unlimited use, then at least that's a baby step in the right direction.
Indeed. Looking at the mailing list, the blow-up happened in November 1998, with message 1 and message 2. It looks like Mr. J is quite responsive to user questions and has time to actively maintain the code and from the mailing list archives, seems a fairly reasonable guy. (His interactions with Mr. JQH are rather prickly, though.)
This reminds me of the ESR/TED battle over ncurses; when ESR started taking offense, TED had been issuing weekly patch sets for some months, answering questions on the mailing list and Usenet, and being generally very responsive, while ESR hadn't issued any releases in months and wasn't very visible at the ncurses maintainer. I was surprised when ESR suddenly re-emerged and started complaining about TED hijacking the code. People don't take over control of packages lightly; they do so only when forced to because the original maintainer appears to be inactive.
There's an obvious dividing line: the system call gateway. Anything that implements a system call is part of the kernel; anything else is userspace and hence is unaffected by the kernel's licence. By this definition, glibc is an application just as much as Oracle is. (It's just an application used by practically all other applications. You can envision writing a system call interface for another language, such as Java or M3, and then writing the userspace code completely in that language, with no C code or library at all.) Amiga can therefore build anything on top of the kernel that they want, and can use any licence they want for the components.
Slashdot Mirror
So, I think of Gaiman the same way I think of Mike Oldfield or Peter Greenaway -- they're all people who can do incredibly good work, but who seem to have moved in directions that I don't like much. Oldfield tries to write pop tunes; Greenaway turns his back on characterization; Gaiman writes stories that rarely have much emotional impact.
So where did the idea of panic in the year 1000 come from? Mostly it came from Enlightenment-era historians, who were often anti-religious; ISTR that Stearns points at Jules Michelet as originating the story in his history of France, Because it agreed with their prejudices, other historians gave Michelet's stories wide exposure, but there doesn't seem to be any actual historical evidence for them.
Bzzt! Wrong, thank you for playing, but Daniel Defoe wrote Robinson Crusoe, while Jonathan Swift wrote Gulliver's Travels.
I don't know. It's far more complicated, but it also does a lot more, and has different design criteria. XML-RPC is just that, remote procedure calls. Finding the right XML-RPC server, determining what methods it supports, and similar resource discovery are all outside of XML-RPC's province; you'd have to invent your own techniques on top of it. E-speak provides a lot more, but this exacts a cost in increased complexity. We'll see how it turns out.
Note that HP has a bunch of RFPs on Source Exchange that are related to E-speak.
You're a bit overoptimistic about the re module's performance; current Perl versions have all sorts of optimizations that the underlying PCRE library doesn't have yet. But this also makes the Perl regex engine's code very hard to understand, and effectively impossible to divorce from the rest of the Perl interpreter. (I'd love to see someone prove me wrong and create a perlre.a, but it seems unlikely to happen.)
Ah, Modula-3; my favorite counterexample to the idea that hackers always choose tools because of technical merit. Modula-3's been around since about 1990, and in having garbage collection, integrated threading features, runtime checking, exception handling, and OO, it's an important precursor to Java, in addition to influencing Python's design. (The first time I read about Java, I thought "This is a lot like Modula-3, just using C syntax.") M3 came as a freely available compiler (a patched version of GCC) that compiled to native code; no one ever proposed a Modula-3 VM. People at DEC SRC experimented with GUIs and distributed computing using M3. You could have had most of the features of Java in the early 90s using free software, yet M3 never caught on, mostly because of the superficial syntactic issue of being a Pascal/Modula-derived language, not a C-like one. M3 also produced rather large binaries because of the supporting libraries, but Java VMs are even larger today, and much slower. Pity, really; I hope an M3 front-end finds its way into EGCS, giving this language another chance.
Also, if you read LinuxToday, you might have noticed the recent announcement of the Python Consortium being formed. HP is one of the initial members, and they're hardly an insignificant company.
I think this is good. Most general-audience portals wind up looking pretty similar anyway, and there's the vast duplication of effort of having different people maintain their collections of links. (Specialized portals aiming at a given target market can always beat the generalized portals, of course.)
A second effect is that this makes dmoz.org's data more important, and may make it worthwhile for companies to help maintain the database. For example, at work we've been considering helping maintain the Science:Engineering:MEMS section on dmoz.org, because we can re-use the data on our site, and this results in better information for the MEMS community, even if they use Excite or, now, Altavista. I hope Excite or Altavista will pay for a few staffers to be ODP editors.
Solid's a fairly nice database, though it lacks advanced features such as triggers. (It does have transactions, though, which is all that I really need.) However, Solidtech reworked their business plan about 6-9 months ago, and they're now mostly interested in customers who want to embed their database in an application and redistribute it 10,000 times; they're not very interested in supporting individual users who just want a single installation for running a Web site. This change caused a lot of bitterness on the solid-list mailing list, and many users, who'd gone out on a limb by recommending Solid instead of Oracle, were very angry. Most of them seem to be drifting away to other databases now.
I sit in front of an 300 MHz Ultra 10 all day. It was purchased around the same time I bought a 266MHz machine from VA Research. Both machines feel about the same speed, with maybe a slight advantage to the Linux box. The major differences are that the Sun cost twice as much, comes with far less interesting software, and occasionally the CD-ROM will lock up, requiring a reboot to fix it. I can't see any reason to purchase a Sun workstation for your desktop, unless there's some Solaris-only application you must run. I'm not negative about Sun for high-end servers, but at the low-end I see no reason to bother with a Sun box.
So, I'd expect a similar design decision was made for Topaz. In interpreters you have to deal with data structures that represent scalars, arrays, dictionaries, etc., so an OO approach might let you avoid hard-wiring an expected type, in favor of an expected interface. Whether this will pay off significantly is the purpose of the experiment.
They've also prevented translations to other languages. Someone wanted to translate the code into Modula-3, keeping equivalent function signatures; he was told that the authors considered the function signatures to be a copyrighted interface, and would not permit the translation. (This argument seems bogus; if it was correct, AT&T/Novell/whoever could sue the authors of Linux and *BSD for providing similar interfaces to their product.)
Literate programming is also best suited for explaining code that requires complex algorithmic or logical reasoning; I can't imagine writing a literate CGI script, for example, because most of the text would be uninteresting, "here we check if the 'run' form variable is set...". LP would be great for compilers and optimizers, regex engines, numerical software, and other programs where the logic of the code is complex and involves external information such as proofs.
Note that David S. Miller, who did lots of TCP and MIPS porting work, was employed by Cobalt for a while, so they've already made some contributions. Most of the non-x86 ports require patches to Linus' kernel tree, so the MIPS port isn't unusual in that respect.
Albert Pisano, the outgoing DARPA program manager for MEMS, likes to talk about building a MEMS dandelion seed, a few mm in diameter. (I saw him deliver the talk at GWU, and he's also given it at NIST.) With current process technology, an old processor like the 8088 would easily fit in that space; in fact, you could get a few hundred 8088s in that space, so computational power isn't a problem. Add power generation, sensors, and radio communications, and you're on to something!
I work on software for a MEMS-related project (the MEMS Exchange). It's an interesting field, and one that's already having an impact in specialized areas like accelerometers, and is very close to becoming widespread.
Umm... someone has already done this and called it Alice; take a look at the Alice tutorial. This is one of the inspirations for the CP4E effort, because it's been really successful at letting non-programmers do interesting things.
The Alice developers modified Python in a few way to make it easier for their intended audience. The major changes were:
Those are the only changes I can remember from the talk, and it's a remarkably short list. They also avoided using XYZ coordinates, instead using object positions and directions. For example, you can say rabbit.lookAt(copter), after which an Energizer bunny object will always stare at a helicopter, no matter where the copter object is moved. People had no trouble with the idea of objects, but little things like case-sensitivity threw them.
One lesson GvR took away from ABC was the importance of OS interfaces; in ABC you couldn't walk through directories or open files, though it provided persistent variable storage that was an abstraction on top of files. This made ABC a nice sandbox to play in, but you couldn't get out of it, and ultimately this proved too confining.
Actually it's because implementing table support in Lynx would be really hard, because it requires a re-entrant parser. Unfortunately, having been written long before tables were around, Lynx's parser uses lots of global variables; to make the parser re-entrant, you'd have to put all these globals in a structure, and change the signatures of lots of functions to pass such structures around. No one has yet stepped up to the plate to do this because it would be so much work.
Correct. For example, Fredrik Lundh's Python Imaging Library can output GIFs (along with a bunch of other formats), but the GIFs are really large because the image data isn't compressed. Apparently at one point he contacted Unisys to ask if he could get a licence for the patent, but Unisys wanted a per-sales fee and reacted uncomprehendingly to the words "free software". If, as another poster claims, Unisys is now accepting a one-time fee for unlimited use, then at least that's a baby step in the right direction.
So, kind of like NYC or some sections of Washington DC, then?
This reminds me of the ESR/TED battle over ncurses; when ESR started taking offense, TED had been issuing weekly patch sets for some months, answering questions on the mailing list and Usenet, and being generally very responsive, while ESR hadn't issued any releases in months and wasn't very visible at the ncurses maintainer. I was surprised when ESR suddenly re-emerged and started complaining about TED hijacking the code. People don't take over control of packages lightly; they do so only when forced to because the original maintainer appears to be inactive.
There's an obvious dividing line: the system call gateway. Anything that implements a system call is part of the kernel; anything else is userspace and hence is unaffected by the kernel's licence. By this definition, glibc is an application just as much as Oracle is. (It's just an application used by practically all other applications. You can envision writing a system call interface for another language, such as Java or M3, and then writing the userspace code completely in that language, with no C code or library at all.) Amiga can therefore build anything on top of the kernel that they want, and can use any licence they want for the components.