Why hasn't anyone else picked up on this? The thumbnail versions of the diagrams explaining anti-aliasing were created using subsampling, and as a result look absolutely horrible. This is really bad design under any circumstances, and absolutely inexcusable in this context!
In case you missed it, the bad-looking thumbnail images are here and here.
I have put properly anti-aliased versions of the same images here and here. (Isn't that much, much better?) These were created with 'pnmscale', a free (speech, beer, and everything else) tool that has been around for a decade now.
Moreover, most of the problems I've seen with bad memory have been intermittent random failures related (apparently) to thermal stress and/or specific timing patterns, not fixed "sticky bits".
I thought it was already relatively common for RAM manufacturers to test for single bit errors in the factory and route around the affected cell, which would negate the economic value of doing this in software. (They should certainly be incented to do this, otherwise they'd have terrible yield issues.)
This sounds like the "bad block" detectors that used to be necessary for hard drives, but aren't any longer (hard drives these days remap bad blocks internally)...
Re:The ROPOD is ok, but the HipKnowTron is cooler!
on
Illusionary LED clock
·
· Score: 2
Can the Hyp-Know-Tron actually display images? All the photos are just pictures of swirly displays; the ROPOD and even the various clock displays are actual "displays" rather than big light shows.
If you thought this was cool, check out the ROPOD!
on
Illusionary LED clock
·
· Score: 4
The ROPOD (ROtating POlar Display) is a similar device, only the screen is a spinning disc rather than a rotating cylinder, making this one of the few displays to use a polar coordinate system. It's also capable of quite a bit more than telling time; the resolution is much higher, and the author has software that can decode a compressed animation format for video display. Follow the link for photos etc..
The coolest thing about the ROPOD is that it's this huge, whirling, rickety contraption that makes bystanders fear for their lives...
1. This is not open source; it's an open source wrapper around a proprietary "HAL" library which Matrox distributes in binary-only form. This bad, not only for philosophical reasons, but because it leaves non-x86 users out in the cold.
2. The G400 Dual-Head card does support acceleration on the second head, but the Windows drivers do not, which creates the common misconception that the second head is unaccelerated. Both heads share the same video RAM, and the accelerator can be used to write to either one. I don't know if the Linux drivers support acceleration on the second head.
3. If you're looking for 3D, you can apparently get DRI drivers, or at least information about them, from dri.sourceforge.net.
With a stock XF86 4.0.1 (without this driver!), I have DRI working on my G400. It's not terribly fast, but it's cute (accelerated 3D in a window!).
4. These drivers crashed my machine! It seems that no matter what I do, as soon as I launch X with this.o file, my machine locks solid. I have one G400 dualhead and one MII (which I've been using to drive the second head, waiting for dualhead support). Has anyone had the same experience?
I won the last year's competition -- here's how...
on
Rock-Paper-Scissors
·
· Score: 5
My submission, Iocaine Powder, won last year's competition. Follow the link to see a complete description of how it works. The competition results from last year describe some of the other strategies that did well (and some that did not-so-well).
This competition is more complex than it seems; not only are there deliberate "dumb robots", but many of the real entries are quite predictable. A random player wouldn't have made it close to winning, and stalemates were rare.
What does this year hold in store? We'll just have to see!
Halfbakery.com is similar to shouldexist, but less full of itself, more active (but that will probably change) and with a somewhat different structure. There are a lot more interesting ideas on halfbakery right now; it's worth checking out. Specifically, the proprietors of shouldexist will need to watch out for some of the problems popularity has brought to halfbakery. (Stupid people posting lots of stupid ideas; flamewars; discussions that go off-topic; duplication; difficulty sorting and categorizing the ideas...)
Ideas are fun to banter around, but people shouldn't kid themselves that a good idea is really worth something. A good idea (vision) and lots and lots of effort implementing it is worth something. "99% perspiration" and all that.
Venture capitalists, for example, must constantly educate people that they don't fund ideas, they fund companies -- and there's a lot more to a company than an idea. Ideas, I'm sad to say, are a dime a dozen; people willing, able, and committed to carrying them out are much more rare.
I imagine sites like halfbakery and shouldexist are more useful not as "think tanks" but as ways for people interested in new ideas to meet each other.
Articles on quantum searching are always confusing. For example, they say that "a conventional database (with 1,000,000 items) would have to search 500,000 items to find the one desired". Well, that's only true if the conventional database has no index whatsoever! Adding a few simple indexes makes searches much, much faster.
Besides, surely the time to search 1,000,000 records is bounded by the time needed to load them all into the QC? Or, if they're already loaded into some kind of quantum soup, isn't this just some weird new kind of index?
Furthermore, I totally fail to see how this could improve Web searches. All it seems to do is allow you to add probabilistic search terms -- and existing search engines could handle those now if they wanted to, but they don't because no user would ever use it. Most of their scenarios require access to structured data (such as a phone book), but Web searches aren't structured.
Does anyone really know what's going on? Can they explain the technology in hype- (and condescension-) free terms?
As of Friday's close, RHAT had a valuation of almost $3,000,000,000. What fraction of Red Hat's worth is threatened by the possibility of media cartels like the RIAA and MPAA locking free software out of content? How about the possibility of making reverse engineering illegal (no more SAMBA)?
How much? 50%? 5%? 1%? 0.1%? Try 0.002% -- that's apparently Red Hat's estimate. Pretty generous, wouldn't you say?
But for that 0.002% of their company, in return they get a gushy Slashdot article and lots of praise and "gosh, I'm so glad they're giving back to the community, I wish those other Linux companies would". There's a PR coup for you. Most companies would *jump* at the chance to have such an utterly positive article in Slashdot for a mere $70K.
I'd like to second this, and expand on it; it's one of the most interesting questions so far.
The GPL was designed in a world when networks were slow and software almost always had to be installed at the site where it was used. Because of this, the GPL attaches all its requirements to the concept of ``distribution''.
These days, however, software can often be ``distributed'' without distributing it at all, by operating a Web service. Currently, free software can be effectively turned into proprietary software by ASPs. (Or is this not true? If so, I'm pretty sure a lot of people misunderstand the GPL, and could use some clarification.)
Is this OK with you? I could imagine a world where the good news is that all the software on our desktop is free, but the bad news is that that software is little more than a dumb terminal used to communicate with the ``real'' software that does all the actual work -- software that's built on the back of free software, but which has had modifications kept proprietary by service providers looking to protect their market advantage.
Does the GPL need revision, or am I wrong about the GPL, or am I wrong about your intent?
Templates are one of the most powerful features of C++, and the standard library uses them extensively. However, they're very difficult to implement using the object file/linker system most compilers work with. Most current compiler implementations offer a set of more or less distasteful hacks, each of which has problems (long compilation times, large intermediate files, large output files, complex and fragile "repositories" that parallel the object files).
For example, the GNU C Compiler's FAQ includes an entry detailing the available workarounds. Other compilers are similar (in fact, the GCC FAQ entry makes reference to other implementations).
A number of development shops I've worked in have avoided templates precisely because of these problems, despite their benefits. Code reusability suffers as a result.
Presumably you didn't have this sorry state of affairs in mind when you were working on the specification. What did you imagine people would do? Abandon object files in favor of some other incremental-compilation scheme? (If so, what?) Are there any compilers that get this "right" in your estimation? In retrospect, would you have done anything differently to encourage compiler vendors to do the "right thing"?
Speaking as a coder, I actually like to draw pretty pictures (it takes a lot of time, though). Graphical visualization is indeed a great tool.
However, until recently, the tools haven't been there. Sure, we have GIMP for pixel editing, but nothing comparable for diagram use -- nothing like Visio or Illustrator that lets you reuse components, make connections, output to a variety of formats, have a generally nice UI, etc.. (Xfig doesn't count, though it's better than nothing.)
However, there's a lot of promising work in this area; there are several open-source projects (Dia [my favorite], Sketch, KIllustrator, Gill, etc.) hoping to remedy the problem. Even more importantly, the SVG standard from the W3C offers the promise of a common data format for interchange between these products -- and a common data format is vital to something like the LDP.
... though it doesn't get nearly as much press, it has a lot of interesting features in its own right (like asynchronous table layout, background downloading, and a UI which I much prefer to w3m's).
It still lacks some things (like cookie support), though. See the home page for more info.
It's not that hard to load up a PDA with lots of features (ARM processor, lots of RAM, color LCD, etc); just look at the Itsy or lots of prototype 'wearables'. The trick is keeping power consumption down.
Note that while they have given it a big ol' 1400mAh battery, information about battery lifetime is conspicuously absent from Samsung's page. G-MATE claims "In normal use, CHOPIN can operate continuously for about 8 weeks with Li-ion rechargeable battery"... maybe if "normal use" is one minute a day.
I like Links. Like w3m, it has real layout with table support and color; it also has incremental rendering, background downloading, mouse support, and various other niceties. I prefer its UI to w3m's, but that's a matter of taste.
I work for a startup company, "XYZ Find" (www.xyzfind.com). We have nothing available yet, but we are developing an XML-based "search engine" that allows parametric search of data (in any XML schema!) on the Web. This will combine the advantages of full-text search engines (broad coverage, simple interface) with database query (precise parametric search, highly relevant results).
This does require that database-driven sites expose their data as XML, but this is starting to happen already (look at RSS), and we believe (and hope!) that it is an increasing trend -- and one that will take off once XML search engines llike ours are available. (We're not the only ones doing this, though our solution will of course be the best.)
The current policies of SETI@Home are clearly wrongheaded; security-through-binary-obscurity is not the right way to protect the integrity of their project, and they're falling into the same close-minded trap the DVD Forum did. Obviously, they should open source the client (and the server!), but maintain an "official" binary distribution with an embedded signing key; their servers would only accept input from blessed binaries. (Yeah, it's possible to extract the key [though this can be made difficult]; you'd want to send a different key with each download, so you could easily revoke one. The point is that this policy would allow well-meaning contributors to play with the client source and submit optimizations for review.)
Furthermore, they'd get people making not only performance improvements, but bug fixes. Do they really think that by working alone they have better QC than if everyone could review the code?
That's not my point, though.
Normally, when the community at large is faced with someone taking a clearly broken licensing approach, we can react by making our own version free of encumbrance. Here, however, we're tied to SETI's data source -- few of us own large radio telescopes.
Is it possible to gain access to SETI's raw data feed? (Of course it is; they send data blocks to everyone for processing!) Is it possible to come up with our own code for analyzing that data and processing it elsewhere -- with or without the cooperation of the S@H administration? I don't think they'd be happy; but could they stop it? (Surely not without causing even more ill-will.)
...
Tangent: What if the ETs use ultra-wideband (UWB) techniques (see http://www.uwb.org/, http://www.time-domain.com/)? Won't FFT-based analysis totally miss such signals?
I have a Ricochet modem, and it works fine with Linux. (In fact, it works fine with just about anything, since it connects to a serial port and emulates a Hayes-compatible modem. You give it "ATDT777" and it gives you a PPP handshake back.)
However, Ricochet's microcellular network architecture, while it has many advantages, means that your packets must travel many "hops" to get to a wired network access point. This makes latency terrible, even compared to analog modems. (I often see 1000ms ping times, and TCP connections frequently lag.) This won't bother a Web surfer as much, but it makes ssh connections painful at best.
Furthermore, Ricochet usually works extremely poorly from a moving vehicle. They have a small cell size, low-power transmitters, multipath issues, and take a little while to perform handoff. Unless you have a really unobstructed view, a Ricochet will more or less stop working above 30mph. This made me wonder how they would ever get it to work in a taxicab.
Now, Ricochet supposedly has a next-generation system, Ricochet2, in development/testing that will yield higher bandwidth (and hopefully lower latency). I don't know if it will support operation at speed, or much of anything else about it.
It sounds like Roblimo plans to get a CDPD modem, which uses a completely different technology (using the digital cellular network). I've never used CDPD, but it should have coverage and velocity characteristics similar to cellular phones. Unlike Ricochet, compatibility may prove more difficult. I've never actually seen a CDPD modem in operation, though, so I can't say for sure.
(CDPD also has much better coverage than Ricochet.)
The official site has a transcription of the section of Nobel's will by which Nobel established the original prizes (physics, chemistry, physiology or medicine, literature, and peace). He asks that the prizes be awarded to those that "conferred the greatest benefit of mankind", but for whatever reason he chose to leave out mathematics, much of biology (though you can interpret "physiology" generously) and most kinds of engineering, among others.
I'm sure biographers have had a wonderful time guessing what influences in his life led him to favor those particular five fields.
In any case, Nobel himself specified it that way; you can't just add another prize for your favorite field. At best, you could try to establish another "memorial" prize, like the one for economics. This is probably good: if you could, everyone would be agitating for their favorite hero to get the coveted Nobel prize. And if they succeeded, then the prize wouldn't exactly be coveted any more...
I think OSS operates on a model that is neither democratic nor autocratic but (little-r) republican.
Individuals vote (by using software, by advocating it, by testing it, and above all by contributing to it) for *people* (project leaders), not individual decisions. Members of most "democratic" nations don't vote on every law; similarly, "members" of open source projects entrust authority with leaders who make the decisions.
Yes, Linus is an autocrat. But he's an autocrat the users and developers of Linux support, and his decisions are generally popular. If he started abusing his power and making widely-unpopular decisions, someone else could start a fork and hope to gain more support. (Consider this a form of "impeachment", maybe?)
This seems to me like a pretty ideal mixture of the accountability of democracy with the strong leadership required for conceptual integrity and direction. Saying "OSS isn't democratic because Linus calls the shots" misses the point.
I've done this before myself. It works great on a small installation with one printer, less well when you have many printers with different characteristics (your end-user software has to understand all of them; if you add a new one, you have to reconfigure the "print" script on every client machine).
Of course, the real problem is that there are M different formats people want to output to the printer (in some sense, many GUI applications have their own internal format which you can include in the M) and N different printers you want to render those formats to.
The traditional Unix answer has been to declare PostScript the intermediate language: turn all M into PS, then figure out how to render PS on all N. It makes sense to put the first step as close to the user as possible (since it's the user that cares about what kind of data they're printing) and the second as close to the printer as possible (to make it easy to add new printers).
(Is PS the right intermediate? *shrug*)
This is, of course, what almost no currently operating system does -- they mostly put _all_ the logic on the server side (a la CUPS or magicfilter) or all the logic on the client side (your solution, or the default Unix behavior of just giving raw access to the printer via 'lpr'). From what I hear, the X printing stuff might be a step in that direction... CUPS is not, AFAICT.
Actually, CUPS does indeed address this issue. One of the big selling points of IPP (the HTTP-based protocol you can use to talk to the server) is that it lets applications query printers to discover their capabilities and configure the print job (and the data they send) appropriately. They make basically the same arguments you do, and cite this as a requirement for "printing in real world applications".
Of course, few (if any) applications use this currently, but if IPP catches on they might start.
(On the other hand, it's arguable that the mode of operation that requires applications to be able to directly control the placement of every pixel on the screen and every inkblot on the page is obsolete; perhaps we should instead be looking for printer drivers that accept something like HTML, and render it as they see fit for the target device. But that's another issue, and much more controversial.)
Since I hate stock lpr (who doesn't?), I recently tried a late beta of CUPS. They may have fixed all the problems I encountered, but while I was thrilled by the idea, I found the execution poor. In particular, the server had a tendency to crash with a segmentation fault whenever anything slightly strange happenned; and in the course of blundering about trying to set it up, I managed to cause many slightly strange things.
Trying to figure out why, I started looking at the source... and discovered that in many places they lack even elementary error checking. NULL pointers are passed to functions that don't check for it, system calls are made with no return value tests, etc.
Now, as I mentioned, it's quite plausible that they fixed the specific bugs I ran into (e.g. when I tried to enable a printer class, instead of a specific printer, it died). It's also possible that the code examples I saw were an aberration, and that most of the project has much better quality code.
Still, I was very taken aback; remember, this is code that is implementing a network service directly -- sloppiness often leads to security holes.
Based on this experience, I instead chose to use LPRng: http://www.astart.com/lprng/LPRng.html. It took more effort to set up, and didn't work "magically" out of the box the way CUPS did (I had to install a version of apsfilter myself, for example), but in the end it did most of the same things -- and didn't crash all the time.
Unfortunately, LPRng has "yet another wacky license", which they claim is "Open Source", but which may have restrictions on commercial use. But if you're interested in CUPS, you should check out LPRng too.
Slashdot Mirror
Why hasn't anyone else picked up on this? The thumbnail versions of the diagrams explaining anti-aliasing were created using subsampling, and as a result look absolutely horrible. This is really bad design under any circumstances, and absolutely inexcusable in this context!
In case you missed it, the bad-looking thumbnail images are here and here.
I have put properly anti-aliased versions of the same images here and here. (Isn't that much, much better?) These were created with 'pnmscale', a free (speech, beer, and everything else) tool that has been around for a decade now.
Moreover, most of the problems I've seen with bad memory have been intermittent random failures related (apparently) to thermal stress and/or specific timing patterns, not fixed "sticky bits".
I thought it was already relatively common for RAM manufacturers to test for single bit errors in the factory and route around the affected cell, which would negate the economic value of doing this in software. (They should certainly be incented to do this, otherwise they'd have terrible yield issues.)
This sounds like the "bad block" detectors that used to be necessary for hard drives, but aren't any longer (hard drives these days remap bad blocks internally)...
Can the Hyp-Know-Tron actually display images? All the photos are just pictures of swirly displays; the ROPOD and even the various clock displays are actual "displays" rather than big light shows.
The ROPOD (ROtating POlar Display) is a similar device, only the screen is a spinning disc rather than a rotating cylinder, making this one of the few displays to use a polar coordinate system. It's also capable of quite a bit more than telling time; the resolution is much higher, and the author has software that can decode a compressed animation format for video display. Follow the link for photos etc..
The coolest thing about the ROPOD is that it's this huge, whirling, rickety contraption that makes bystanders fear for their lives...
There's a lot of confusion around here...
1. This is not open source; it's an open source wrapper around a proprietary "HAL" library which Matrox distributes in binary-only form. This bad, not only for philosophical reasons, but because it leaves non-x86 users out in the cold.
2. The G400 Dual-Head card does support acceleration on the second head, but the Windows drivers do not, which creates the common misconception that the second head is unaccelerated. Both heads share the same video RAM, and the accelerator can be used to write to either one. I don't know if the Linux drivers support acceleration on the second head.
3. If you're looking for 3D, you can apparently get DRI drivers, or at least information about them, from dri.sourceforge.net. With a stock XF86 4.0.1 (without this driver!), I have DRI working on my G400. It's not terribly fast, but it's cute (accelerated 3D in a window!).
4. These drivers crashed my machine! It seems that no matter what I do, as soon as I launch X with this .o file, my machine locks solid. I have one G400 dualhead and one MII (which I've been using to drive the second head, waiting for dualhead support). Has anyone had the same experience?
My submission, Iocaine Powder, won last year's competition. Follow the link to see a complete description of how it works. The competition results from last year describe some of the other strategies that did well (and some that did not-so-well).
This competition is more complex than it seems; not only are there deliberate "dumb robots", but many of the real entries are quite predictable. A random player wouldn't have made it close to winning, and stalemates were rare.
What does this year hold in store? We'll just have to see!
Halfbakery.com is similar to shouldexist, but less full of itself, more active (but that will probably change) and with a somewhat different structure. There are a lot more interesting ideas on halfbakery right now; it's worth checking out. Specifically, the proprietors of shouldexist will need to watch out for some of the problems popularity has brought to halfbakery. (Stupid people posting lots of stupid ideas; flamewars; discussions that go off-topic; duplication; difficulty sorting and categorizing the ideas...)
Ideas are fun to banter around, but people shouldn't kid themselves that a good idea is really worth something. A good idea (vision) and lots and lots of effort implementing it is worth something. "99% perspiration" and all that.
Venture capitalists, for example, must constantly educate people that they don't fund ideas, they fund companies -- and there's a lot more to a company than an idea. Ideas, I'm sad to say, are a dime a dozen; people willing, able, and committed to carrying them out are much more rare.
I imagine sites like halfbakery and shouldexist are more useful not as "think tanks" but as ways for people interested in new ideas to meet each other.
Articles on quantum searching are always confusing. For example, they say that "a conventional database (with 1,000,000 items) would have to search 500,000 items to find the one desired". Well, that's only true if the conventional database has no index whatsoever! Adding a few simple indexes makes searches much, much faster.
Besides, surely the time to search 1,000,000 records is bounded by the time needed to load them all into the QC? Or, if they're already loaded into some kind of quantum soup, isn't this just some weird new kind of index?
Furthermore, I totally fail to see how this could improve Web searches. All it seems to do is allow you to add probabilistic search terms -- and existing search engines could handle those now if they wanted to, but they don't because no user would ever use it. Most of their scenarios require access to structured data (such as a phone book), but Web searches aren't structured.
Does anyone really know what's going on? Can they explain the technology in hype- (and condescension-) free terms?
What does that fund, one day in court?
As of Friday's close, RHAT had a valuation of almost $3,000,000,000. What fraction of Red Hat's worth is threatened by the possibility of media cartels like the RIAA and MPAA locking free software out of content? How about the possibility of making reverse engineering illegal (no more SAMBA)?
How much? 50%? 5%? 1%? 0.1%? Try 0.002% -- that's apparently Red Hat's estimate. Pretty generous, wouldn't you say?
But for that 0.002% of their company, in return they get a gushy Slashdot article and lots of praise and "gosh, I'm so glad they're giving back to the community, I wish those other Linux companies would". There's a PR coup for you. Most companies would *jump* at the chance to have such an utterly positive article in Slashdot for a mere $70K.
Here's a real link for your clicking pleasure. Sorry about that! (I swear I selected "HTML Formatted"...)
This site at
JPL</a> has more information on imaging asteroids
with radar. This has only become practical
relatively recently with newly installed equipment
at Arecibo and (to a lesser extent) NASA's
Goldstone radar telescope.
It looks like asteroids come in two shapes: "long
and thin" (a la the "dog bone" Kleopatra or "shoe"
Eros), or the more classic lumpy-round-thing look.
They seem to be about equally common, at least
among the asteroids we've imaged.
I think game designers and movie special-effects
people may need to make some revisions! But what
radio telescopes can't tell us is what happens to
a long-thin asteroid when you blast it; does it
turn into smaller long-thin rocks, or fragment
into roughly spherical chunks? I demand accuracy
in my arcade games!
I'd like to second this, and expand on it; it's one of the most interesting questions so far.
The GPL was designed in a world when networks were slow and software almost always had to be installed at the site where it was used. Because of this, the GPL attaches all its requirements to the concept of ``distribution''.
These days, however, software can often be ``distributed'' without distributing it at all, by operating a Web service. Currently, free software can be effectively turned into proprietary software by ASPs. (Or is this not true? If so, I'm pretty sure a lot of people misunderstand the GPL, and could use some clarification.)
Is this OK with you? I could imagine a world where the good news is that all the software on our desktop is free, but the bad news is that that software is little more than a dumb terminal used to communicate with the ``real'' software that does all the actual work -- software that's built on the back of free software, but which has had modifications kept proprietary by service providers looking to protect their market advantage.
Does the GPL need revision, or am I wrong about the GPL, or am I wrong about your intent?
For example, the GNU C Compiler's FAQ includes an entry detailing the available workarounds. Other compilers are similar (in fact, the GCC FAQ entry makes reference to other implementations).
A number of development shops I've worked in have avoided templates precisely because of these problems, despite their benefits. Code reusability suffers as a result.
Presumably you didn't have this sorry state of affairs in mind when you were working on the specification. What did you imagine people would do? Abandon object files in favor of some other incremental-compilation scheme? (If so, what?) Are there any compilers that get this "right" in your estimation? In retrospect, would you have done anything differently to encourage compiler vendors to do the "right thing"?
However, until recently, the tools haven't been there. Sure, we have GIMP for pixel editing, but nothing comparable for diagram use -- nothing like Visio or Illustrator that lets you reuse components, make connections, output to a variety of formats, have a generally nice UI, etc.. (Xfig doesn't count, though it's better than nothing.)
However, there's a lot of promising work in this area; there are several open-source projects (Dia [my favorite], Sketch, KIllustrator, Gill, etc.) hoping to remedy the problem. Even more importantly, the SVG standard from the W3C offers the promise of a common data format for interchange between these products -- and a common data format is vital to something like the LDP.
It still lacks some things (like cookie support), though. See the home page for more info.
Note that while they have given it a big ol' 1400mAh battery, information about battery lifetime is conspicuously absent from Samsung's page. G-MATE claims "In normal use, CHOPIN can operate continuously for about 8 weeks with Li-ion rechargeable battery"... maybe if "normal use" is one minute a day.
But hey, we'll see!
I like Links. Like w3m, it has real layout with table support and color; it also has incremental rendering, background downloading, mouse support, and various other niceties. I prefer its UI to w3m's, but that's a matter of taste.
I work for a startup company, "XYZ Find" (www.xyzfind.com). We have nothing available yet, but we are developing an XML-based "search engine" that allows parametric search of data (in any XML schema!) on the Web. This will combine the advantages of full-text search engines (broad coverage, simple interface) with database query (precise parametric search, highly relevant results).
.)
This does require that database-driven sites expose their data as XML, but this is starting to happen already (look at RSS), and we believe (and hope!) that it is an increasing trend -- and one that will take off once XML search engines llike ours are available. (We're not the only ones doing this, though our solution will of course be the best
The current policies of SETI@Home are clearly wrongheaded; security-through-binary-obscurity is not the right way to protect the integrity of their project, and they're falling into the same close-minded trap the DVD Forum did. Obviously, they should open source the client (and the server!), but maintain an "official" binary distribution with an embedded signing key; their servers would only accept input from blessed binaries. (Yeah, it's possible to extract the key [though this can be made difficult]; you'd want to send a different key with each download, so you could easily revoke one. The point is that this policy would allow well-meaning contributors to play with the client source and submit optimizations for review.)
Furthermore, they'd get people making not only performance improvements, but bug fixes. Do they really think that by working alone they have better QC than if everyone could review the code?
That's not my point, though.
Normally, when the community at large is faced with someone taking a clearly broken licensing approach, we can react by making our own version free of encumbrance. Here, however, we're tied to SETI's data source -- few of us own large radio telescopes.
Is it possible to gain access to SETI's raw data feed? (Of course it is; they send data blocks to everyone for processing!) Is it possible to come up with our own code for analyzing that data and processing it elsewhere -- with or without the cooperation of the S@H administration? I don't think they'd be happy; but could they stop it? (Surely not without causing even more ill-will.)
...
Tangent: What if the ETs use ultra-wideband (UWB) techniques (see http://www.uwb.org/, http://www.time-domain.com/)? Won't FFT-based analysis totally miss such signals?
I have a Ricochet modem, and it works fine with Linux. (In fact, it works fine with just about anything, since it connects to a serial port and emulates a Hayes-compatible modem. You give it "ATDT777" and it gives you a PPP handshake back.)
However, Ricochet's microcellular network architecture, while it has many advantages, means that your packets must travel many "hops" to get to a wired network access point. This makes latency terrible, even compared to analog modems. (I often see 1000ms ping times, and TCP connections frequently lag.) This won't bother a Web surfer as much, but it makes ssh connections painful at best.
Furthermore, Ricochet usually works extremely poorly from a moving vehicle. They have a small cell size, low-power transmitters, multipath issues, and take a little while to perform handoff. Unless you have a really unobstructed view, a Ricochet will more or less stop working above 30mph. This made me wonder how they would ever get it to work in a taxicab.
Now, Ricochet supposedly has a next-generation system, Ricochet2, in development/testing that will yield higher bandwidth (and hopefully lower latency). I don't know if it will support operation at speed, or much of anything else about it.
It sounds like Roblimo plans to get a CDPD modem, which uses a completely different technology (using the digital cellular network). I've never used CDPD, but it should have coverage and velocity characteristics similar to cellular phones. Unlike Ricochet, compatibility may prove more difficult. I've never actually seen a CDPD modem in operation, though, so I can't say for sure.
(CDPD also has much better coverage than Ricochet.)
I'm sure biographers have had a wonderful time guessing what influences in his life led him to favor those particular five fields.
In any case, Nobel himself specified it that way; you can't just add another prize for your favorite field. At best, you could try to establish another "memorial" prize, like the one for economics. This is probably good: if you could, everyone would be agitating for their favorite hero to get the coveted Nobel prize. And if they succeeded, then the prize wouldn't exactly be coveted any more...
I think OSS operates on a model that is neither democratic nor autocratic but (little-r) republican.
Individuals vote (by using software, by advocating it, by testing it, and above all by contributing to it) for *people* (project leaders), not individual decisions. Members of most "democratic" nations don't vote on every law; similarly, "members" of open source projects entrust authority with leaders who make the decisions.
Yes, Linus is an autocrat. But he's an autocrat the users and developers of Linux support, and his decisions are generally popular. If he started abusing his power and making widely-unpopular decisions, someone else could start a fork and hope to gain more support. (Consider this a form of "impeachment", maybe?)
This seems to me like a pretty ideal mixture of the accountability of democracy with the strong leadership required for conceptual integrity and direction. Saying "OSS isn't democratic because Linus calls the shots" misses the point.
I've done this before myself. It works great on a small installation with one printer, less well when you have many printers with different characteristics (your end-user software has to understand all of them; if you add a new one, you have to reconfigure the "print" script on every client machine).
Of course, the real problem is that there are M different formats people want to output to the printer (in some sense, many GUI applications have their own internal format which you can include in the M) and N different printers you want to render those formats to.
The traditional Unix answer has been to declare PostScript the intermediate language: turn all M into PS, then figure out how to render PS on all N. It makes sense to put the first step as close to the user as possible (since it's the user that cares about what kind of data they're printing) and the second as close to the printer as possible (to make it easy to add new printers).
(Is PS the right intermediate? *shrug*)
This is, of course, what almost no currently operating system does -- they mostly put _all_ the logic on the server side (a la CUPS or magicfilter) or all the logic on the client side (your solution, or the default Unix behavior of just giving raw access to the printer via 'lpr'). From what I hear, the X printing stuff might be a step in that direction... CUPS is not, AFAICT.
Actually, CUPS does indeed address this issue. One of the big selling points of IPP (the HTTP-based protocol you can use to talk to the server) is that it lets applications query printers to discover their capabilities and configure the print job (and the data they send) appropriately. They make basically the same arguments you do, and cite this as a requirement for "printing in real world applications".
Of course, few (if any) applications use this currently, but if IPP catches on they might start.
(On the other hand, it's arguable that the mode of operation that requires applications to be able to directly control the placement of every pixel on the screen and every inkblot on the page is obsolete; perhaps we should instead be looking for printer drivers that accept something like HTML, and render it as they see fit for the target device. But that's another issue, and much more controversial.)
Since I hate stock lpr (who doesn't?), I recently tried a late beta of CUPS. They may have fixed all the problems I encountered, but while I was thrilled by the idea, I found the execution poor. In particular, the server had a tendency to crash with a segmentation fault whenever anything slightly strange happenned; and in the course of blundering about trying to set it up, I managed to cause many slightly strange things.
Trying to figure out why, I started looking at the source... and discovered that in many places they lack even elementary error checking. NULL pointers are passed to functions that don't check for it, system calls are made with no return value tests, etc.
Now, as I mentioned, it's quite plausible that they fixed the specific bugs I ran into (e.g. when I tried to enable a printer class, instead of a specific printer, it died). It's also possible that the code examples I saw were an aberration, and that most of the project has much better quality code.
Still, I was very taken aback; remember, this is code that is implementing a network service directly -- sloppiness often leads to security holes.
Based on this experience, I instead chose to use LPRng: http://www.astart.com/lprng/LPRng.html. It took more effort to set up, and didn't work "magically" out of the box the way CUPS did (I had to install a version of apsfilter myself, for example), but in the end it did most of the same things -- and didn't crash all the time.
Unfortunately, LPRng has "yet another wacky license", which they claim is "Open Source", but which may have restrictions on commercial use. But if you're interested in CUPS, you should check out LPRng too.