Actually, since the client doesn't initially know that the server is a HTTP/1.1 server, the Keep-Alive header is required to handle cases where the server is a compliant HTTP/1.0 server, which has to ignore Connection, and follow Keep-Alive. Of course, if the client has determined the server to be a correct 1.1 server, it can skip both headers (and, in fact, it might be best to first try without them, and, if the server misbehaves or turns out to be a 1.0 server, use the headers in the future, or use 1.0).
It's not my server to fix, so I can't fix the server. Furthermore, the server maintainer doesn't have any incentive to fix it due to my browser not being able to use it.
In any case, in several cases a strictly complient client is required to deal with server bugs by the specification. E.g.:
3.4.1 Missing Charset
Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean "recipient should guess." Senders wishing to defeat this behavior MAY include a charset parameter even when the charset is ISO-8859-1 and SHOULD do so when it is known that it will not confuse the recipient.
The XML specification has a section on how to get HTML clients to parse XHTML correctly, and there is intentional support in the standard for letting this work (allowing a space before the slash in an empty tag, in particular).
The real need is for fault isolation. The problem is that when a single thing goes wrong, the whole thing collapses. With bridges or airplanes, for example, if one thing fails, that's fine; a series of several failures are needed in order to cause a significant collapse, and the parts that are most likely to fail (like the road surface or the tray tables) do not lead to disaster. In contrast, a little display bug is likely to propagate to taking the whole application down.
Of course, fault isolation is really hard in computer programming, due to the fact that a program is information manipulating information; there's no way to tell when something is misbehaving, because all of the parts are essentially made of the same stuff: CPU instructions and bytes.
Java does have some advantages, in that the runtime system can prevent code from running as if an object was a different class and behaving in a particularly chaotic way, and the exception mechanism is similarly beneficial; you can just catch Throwable and log an error message, and the whole program won't crash because of a null pointer.
Of course, it is theoretically possible to write a C compiler that actually does most of this; there are limits in the C specification such that the program could check that what it was doing was actually legal, and avoid serious problems, but it would be a very unconventional C compiler. (For that matter, you could run your programs under valgrind, with modifications to let it recover from memory errors in addition to logging them; it would be relatively slow, but there's plenty of extra processor power these days).
A compliant browser SHOULD handle non-compliant servers, and a compliant server SHOULD handle non-compliant browsers. An important property of a good specification is that old and broken programs may be handled gracefully without violating the standard.
Games are good for productivity if they help you to say relaxed. However, you need games that don't demand that you play them continuously, and that aren't too intellectually challenging. Playing System Shock at work is sure to keep you from doing any work, and playing StarCraft is going to distract you for long periods of time, but playing solitaire is a good way to stay alert while you don't have anything you can work on for a minute or two. Similarly, reading slashdot is good for productivity but reading a novel is not.
There's no reason you couldn't have the programmer-visible connection objects separated from the IPC connections with slow initialization. Nothing that's available to the programmer is pooled, just the underlying resources. In particular, if you close a java.sql.Connection and open another one, you're likely to get the same connection to the database, but the object will be new (and the specification doesn't permit this object to be reused).
So not only is it bad for performance to have pools of Java objects, but, if it's good to have pools of something, it isn't necessary to have this influence the API.
What are these other media outlets you speak of? I sometimes see newspaper headlines or local news show previews, but that's about it. I guess google sometimes carries CNN online stories...
Who uses 44+ volts DC for anything? It seems like just going with 5V would be better, and less likely to fry stuff with shorts in the cable; if a 5V line shorts to a signal line, the signal is held high, and your cable just doesn't work, without taking anything out of spec. Of course, 350mA at 5V is too little power, but increasing the current a bit would be reasonable with a 10-fold decrease in voltage.
What exactly are they planning to power with this? Embedded devices and PDA-level devices (like wireless access points) don't need nearly that much power.
(I have personally modified a cheap hub to let me run 5V over ethernet, so I know it's reasonable; it works fine for essentially any device that you might run off of batteries if you could keep the batteries charged)
I suspect that progress is stiffled by the machines. For one thing, there probably aren't actually any scientists or engineers would are actual people; the jobs are filled by simulations, and they don't come up with anything new. When people figure things out and write them down, the paper gets lost or the computer loses the file. Everybody's working a mindless, dead-end job that doesn't get anywhere.
Of course, the simulation can't improve too much, because then the people could break out of it by developing AIs which could outsmart the machines even though they're simulated.
If you're carrying around a full-size keyboard, you might as well have a laptop. These are good for when you're in a situation where you don't have a surface to put the device on, so you're limited to holding it with one hand and writing with the other, or holding it with both hands and using your thumbs.
That's how you can really identify a PDA, I think. If you can use it while holding it, it's a PDA.
Because there's a ton of code which is "optimized" to do things in a way that Java is bad at. I mean, old objects referencing new objects is bad for modern GCs, and creating temporary objects is no problem (and happens constantly anyway). So why would you ever want to have a pool of preallocated objects which get recycled? It hurts performance, and complicates the program. Yet it's a common pattern in J2EE. You'd think that Sun would have some clue about Java...
Meanwhile, the EU has banned GM crops, in part due to health concerns, but also due to fears that their crops might be contaminated by crops with IP restrictions, which would lead to farmers being sued by seed companies. It looks like this is going to contribute significantly to a US trade deficit in the near future and a major loss of revenue for the US agricultural industry, as well as companies like Monsanto.
Intellectual Property: the best way to use lawsuits to drive yourself out of business.
(My new job is teaching me all sorts of things. You learn a lot if you have a commute by car on which to listen to NPR)
Re:What are the odds that Ogg will replace mp3?
on
Ogg Now An RFC
·
· Score: 1
Consumers won't think of Ogg as the normal, expected format for audio. Consumers only pick up the first name for something, and it takes a generation for names to fade. On the other hand, with players using plug-ins and gradually getting Vorbis support, it's likely that people's MP3 collections will soon contain a number of Ogg files, which will be entirely lost on them; they'll call compressed audio files "MP3s" regardless of the codec or format.
We're going to be stuck with the cruft and slowness of X11 until someone does X12, which could simply cut out support for the cruft. This should come sortly after font rendering, anti-aliasing (of everything), transparency, and splines are all settled down (splines were reportedly supposed in by in the original release of X11, but nobody wokring on it knew what kind of splines to support, so they didn't include them). Then the cruft can all get removed (visuals, failed font designs, various image formats that don't make sense for 32-bit directcolor+transparency), and the important extensions can be defined to be part of the core (so you don't need to test for them). There's nothing essential to X about the cruft and the slowness.
If they argue that their direct customers may use the code which SCO owns, but nobody else may, that violates the license under which they received all of the other code they are distributing, which says that customers get all of the code under the GPL.
If Red Hat or debian got a copy of Caldera at some point, SCO has given their code under the GPL to these distributors, who have passed it on to others under the GPL. SCO could argue that they didn't mean to license the code in question to anyone under the GPL (certainly if SCO found that Caldera included Microsoft IP, they should bring this up and let everyone know that the code is not properly licensed). But anything that affects anyone has to affect Caldera users just as much, because SCO isn't allowed to license the code it owns just to its users while linking it with GPL code.
Or they could lose the case, and there would be legal precedent establishing that Linux is free of (at least some) IP entanglements.
If this is the only "IP violation" which comes to light, and SCO never produces an actual IP violation, people will go the other way.
Incidentally, if they are offering only to direct customers licenses for the mythical IP that was supposedly in there, they have violated the GPL (which requires them to license the source under the GPL, with no further restrictions), and everyone from IBM to Red Hat to Linus can sue them for any assets they may still have. If they aren't violating the GPL, anyone whose distribution got a copy of Caldera is safe (except, potentially, for IBM, who might have violated copyright before getting their license to distribute it under the GPL).
NFS isn't a distributed filesystem. However, the original poster doesn't need a distributed filesystem. It's not secure, but the poster (presumably) has a physically-secured network with no untrusted local root users. It doesn't support replicated, but the poster doesn't require that level of reliability.
In short, NFS isn't an answer to the poster's question, but it's a perfectly good solution to the poster's problem. A proper distributed filesystem is a solution to a significantly harder problem than the one at hand.
Where do you find a burrito joint that routinely breaks $100s? Anyway...
I think the worst problem with the current set of new bills is that they all look different from the old ones, but they all look like each other. I think people would do much better with new bills if they formed a logically matched set without being nearly so similar. As a really simple feature, just make the non-black printing on the black side a different color for each denomination. People care about the green back, but who cares that the colored medallion on the front is green? Some feature on the back should also be the denomination-specific color, so the backs look different. Perhaps the numbers, so they'd stand out more, too.
For that matter, they ought to print the bills on different weights of paper; then you could identify bills by feel, and you couldn't just bleach bills and print other values on the paper (make the higher values thicker, so you couldn't shave them down to approximate the feel).
Re:What use is AI without an operating platform
on
AI Going Nowhere?
·
· Score: 1
The issue is that building unique hardware isn't interesting, and never has been. Hardware has to be produced in bulk and be robust and foolproof, especially if the point of your research is not to work on hardware. There's nothing wrong with little autonomous robots, but an endless stream of grad students each building a new robot with the same physical capabilities instead of working on making them smarter doesn't make sense.
A far better idea would be for the lab to call the mechanical engineering department and ask them to design a robot with the appropriate physical capabilities, and then get a dozen of them built, which can be programmed by the next decade of grad students.
The current situation is a bit like when chemists blew their own glassware. Sure, it gave them a great feel for the equipment and a related skill, but it took a lot of time away from working with chemicals, and it didn't involve any new research.
Slashdot's features (interviews and such) are primary. Most of the stories (as I mentioned later) aren't really primary, although they're not really commentary either; they should probably just count as a link to the article they site.
There are relatively few cases where new theories are proposed in commentary (even in the case of Chomsky, he's got dozens of equally radical theories that aren't critiques of other works). Of course, there are probably a lot of primary sources which are in web logs (slashdot linked to one about reliable computing today, for instance). But this just means that a primary source might be embedded in a commenting document, or might be published in a forum which generally contains commentary.
What would actually be interesting would be to have the weblog search attached to the main search, with an attempt to figure out what commenting sources are commenting on. So you get documents which are mainly about the topic (as opposed to being about other documents about the topic) listed, and have a link to "what other people have said about this document".
The real problem with the mass of commentary is that if a lot of tightly linked documents are talking about some document, it's relatively hard to find the document that started the whole thing, and the commentary generally assumes that you've read this document. So google is most helpful if it provides the commentary attached to or after the document that it is about.
One thing that would be really neat would be to annotate the google cache of documents with other documents that refer to each section, so that you see commentary next to the original rather than after it or instead of it.
The way web traffic works, having a few seconds of complete downtime isn't a big deal, especially if you're not closing the listening socket. If you have 1000 hits/minute, and you HUP your web server, and it stops accepting connections (but doesn't reject them) for 6 seconds, killing all of the serving threads after 3 seconds (to let the non-stuck threads finish serving), and restarting them after reading the new configuration, 100 hits will take up to 6 seconds longer than they should, and then you'll have 110% of your average load while it catches up (less than many bursts anyway), and probably nobody will notice, especially if they're remote clients. For web servers and such, completely resetting the "business" portion of the server is fast and not noticeable to the client. About the only thing that would be noticed would be closing the listenning socket with connections open (which, by TCP rules, is supposed to prevent you from openning it again for a long time, and breaks connections and refuses new ones).
It would matter more for protocols where you actually have persistent connections, but such protocols are relatively rare, and are generally designed to be restartable these days (with the exception of ssh, which actually does separate out connections entirely, like you suggest).
Slashdot is great, but do you actually want to get slashdot comments as search results? As far as I can tell, google doesn't index them at all, anyway. To me, it makes sense to separate the search for primary material (like slashdot's links and features) from the commentary on it (the comments). Of course, slashdot's primary material is mainly references to other primary sources, so there's not much for the main google search to get here; the blog search could, however, pick up a lot.
I think the ideal design would be:/**
* The name of this object
*/ private String name;
public String getName(); public setName(String name);
That is, if a method is declared as set* or get*, not declared abstract, and no body is given, the compiler provides the method body to do the obvious thing (and javadoc copies the documentation as appropriate). You should probably be able to drop the return type and maybe the parameter types (although having setName() generate a method with a different signature would be odd). You still get to declare the protection for the methods, though, and any other method attributes you feel like (not that there are any other useful ones right now).
None of these changes will affect an old program compiled with a new compiler (unless it didn't compile before...), nor old class files run against a new library. They've been very careful this time to avoid breaking legacy code. (Unlike in 1.4, where they added a keyword, which broke everybody's testing code, but not the actual programs)
Slashdot Mirror
Actually, since the client doesn't initially know that the server is a HTTP/1.1 server, the Keep-Alive header is required to handle cases where the server is a compliant HTTP/1.0 server, which has to ignore Connection, and follow Keep-Alive. Of course, if the client has determined the server to be a correct 1.1 server, it can skip both headers (and, in fact, it might be best to first try without them, and, if the server misbehaves or turns out to be a 1.0 server, use the headers in the future, or use 1.0).
In any case, in several cases a strictly complient client is required to deal with server bugs by the specification. E.g.:
The XML specification has a section on how to get HTML clients to parse XHTML correctly, and there is intentional support in the standard for letting this work (allowing a space before the slash in an empty tag, in particular).
The real need is for fault isolation. The problem is that when a single thing goes wrong, the whole thing collapses. With bridges or airplanes, for example, if one thing fails, that's fine; a series of several failures are needed in order to cause a significant collapse, and the parts that are most likely to fail (like the road surface or the tray tables) do not lead to disaster. In contrast, a little display bug is likely to propagate to taking the whole application down.
Of course, fault isolation is really hard in computer programming, due to the fact that a program is information manipulating information; there's no way to tell when something is misbehaving, because all of the parts are essentially made of the same stuff: CPU instructions and bytes.
Java does have some advantages, in that the runtime system can prevent code from running as if an object was a different class and behaving in a particularly chaotic way, and the exception mechanism is similarly beneficial; you can just catch Throwable and log an error message, and the whole program won't crash because of a null pointer.
Of course, it is theoretically possible to write a C compiler that actually does most of this; there are limits in the C specification such that the program could check that what it was doing was actually legal, and avoid serious problems, but it would be a very unconventional C compiler. (For that matter, you could run your programs under valgrind, with modifications to let it recover from memory errors in addition to logging them; it would be relatively slow, but there's plenty of extra processor power these days).
A compliant browser SHOULD handle non-compliant servers, and a compliant server SHOULD handle non-compliant browsers. An important property of a good specification is that old and broken programs may be handled gracefully without violating the standard.
Games are good for productivity if they help you to say relaxed. However, you need games that don't demand that you play them continuously, and that aren't too intellectually challenging. Playing System Shock at work is sure to keep you from doing any work, and playing StarCraft is going to distract you for long periods of time, but playing solitaire is a good way to stay alert while you don't have anything you can work on for a minute or two. Similarly, reading slashdot is good for productivity but reading a novel is not.
There's no reason you couldn't have the programmer-visible connection objects separated from the IPC connections with slow initialization. Nothing that's available to the programmer is pooled, just the underlying resources. In particular, if you close a java.sql.Connection and open another one, you're likely to get the same connection to the database, but the object will be new (and the specification doesn't permit this object to be reused).
So not only is it bad for performance to have pools of Java objects, but, if it's good to have pools of something, it isn't necessary to have this influence the API.
What are these other media outlets you speak of? I sometimes see newspaper headlines or local news show previews, but that's about it. I guess google sometimes carries CNN online stories...
Who uses 44+ volts DC for anything? It seems like just going with 5V would be better, and less likely to fry stuff with shorts in the cable; if a 5V line shorts to a signal line, the signal is held high, and your cable just doesn't work, without taking anything out of spec. Of course, 350mA at 5V is too little power, but increasing the current a bit would be reasonable with a 10-fold decrease in voltage.
What exactly are they planning to power with this? Embedded devices and PDA-level devices (like wireless access points) don't need nearly that much power.
(I have personally modified a cheap hub to let me run 5V over ethernet, so I know it's reasonable; it works fine for essentially any device that you might run off of batteries if you could keep the batteries charged)
I suspect that progress is stiffled by the machines. For one thing, there probably aren't actually any scientists or engineers would are actual people; the jobs are filled by simulations, and they don't come up with anything new. When people figure things out and write them down, the paper gets lost or the computer loses the file. Everybody's working a mindless, dead-end job that doesn't get anywhere.
Of course, the simulation can't improve too much, because then the people could break out of it by developing AIs which could outsmart the machines even though they're simulated.
If you're carrying around a full-size keyboard, you might as well have a laptop. These are good for when you're in a situation where you don't have a surface to put the device on, so you're limited to holding it with one hand and writing with the other, or holding it with both hands and using your thumbs.
That's how you can really identify a PDA, I think. If you can use it while holding it, it's a PDA.
Because there's a ton of code which is "optimized" to do things in a way that Java is bad at. I mean, old objects referencing new objects is bad for modern GCs, and creating temporary objects is no problem (and happens constantly anyway). So why would you ever want to have a pool of preallocated objects which get recycled? It hurts performance, and complicates the program. Yet it's a common pattern in J2EE. You'd think that Sun would have some clue about Java...
Meanwhile, the EU has banned GM crops, in part due to health concerns, but also due to fears that their crops might be contaminated by crops with IP restrictions, which would lead to farmers being sued by seed companies. It looks like this is going to contribute significantly to a US trade deficit in the near future and a major loss of revenue for the US agricultural industry, as well as companies like Monsanto.
Intellectual Property: the best way to use lawsuits to drive yourself out of business.
(My new job is teaching me all sorts of things. You learn a lot if you have a commute by car on which to listen to NPR)
Consumers won't think of Ogg as the normal, expected format for audio. Consumers only pick up the first name for something, and it takes a generation for names to fade. On the other hand, with players using plug-ins and gradually getting Vorbis support, it's likely that people's MP3 collections will soon contain a number of Ogg files, which will be entirely lost on them; they'll call compressed audio files "MP3s" regardless of the codec or format.
We're going to be stuck with the cruft and slowness of X11 until someone does X12, which could simply cut out support for the cruft. This should come sortly after font rendering, anti-aliasing (of everything), transparency, and splines are all settled down (splines were reportedly supposed in by in the original release of X11, but nobody wokring on it knew what kind of splines to support, so they didn't include them). Then the cruft can all get removed (visuals, failed font designs, various image formats that don't make sense for 32-bit directcolor+transparency), and the important extensions can be defined to be part of the core (so you don't need to test for them). There's nothing essential to X about the cruft and the slowness.
If they argue that their direct customers may use the code which SCO owns, but nobody else may, that violates the license under which they received all of the other code they are distributing, which says that customers get all of the code under the GPL.
If Red Hat or debian got a copy of Caldera at some point, SCO has given their code under the GPL to these distributors, who have passed it on to others under the GPL. SCO could argue that they didn't mean to license the code in question to anyone under the GPL (certainly if SCO found that Caldera included Microsoft IP, they should bring this up and let everyone know that the code is not properly licensed). But anything that affects anyone has to affect Caldera users just as much, because SCO isn't allowed to license the code it owns just to its users while linking it with GPL code.
Or they could lose the case, and there would be legal precedent establishing that Linux is free of (at least some) IP entanglements.
If this is the only "IP violation" which comes to light, and SCO never produces an actual IP violation, people will go the other way.
Incidentally, if they are offering only to direct customers licenses for the mythical IP that was supposedly in there, they have violated the GPL (which requires them to license the source under the GPL, with no further restrictions), and everyone from IBM to Red Hat to Linus can sue them for any assets they may still have. If they aren't violating the GPL, anyone whose distribution got a copy of Caldera is safe (except, potentially, for IBM, who might have violated copyright before getting their license to distribute it under the GPL).
NFS isn't a distributed filesystem. However, the original poster doesn't need a distributed filesystem. It's not secure, but the poster (presumably) has a physically-secured network with no untrusted local root users. It doesn't support replicated, but the poster doesn't require that level of reliability.
In short, NFS isn't an answer to the poster's question, but it's a perfectly good solution to the poster's problem. A proper distributed filesystem is a solution to a significantly harder problem than the one at hand.
Where do you find a burrito joint that routinely breaks $100s? Anyway...
I think the worst problem with the current set of new bills is that they all look different from the old ones, but they all look like each other. I think people would do much better with new bills if they formed a logically matched set without being nearly so similar. As a really simple feature, just make the non-black printing on the black side a different color for each denomination. People care about the green back, but who cares that the colored medallion on the front is green? Some feature on the back should also be the denomination-specific color, so the backs look different. Perhaps the numbers, so they'd stand out more, too.
For that matter, they ought to print the bills on different weights of paper; then you could identify bills by feel, and you couldn't just bleach bills and print other values on the paper (make the higher values thicker, so you couldn't shave them down to approximate the feel).
The issue is that building unique hardware isn't interesting, and never has been. Hardware has to be produced in bulk and be robust and foolproof, especially if the point of your research is not to work on hardware. There's nothing wrong with little autonomous robots, but an endless stream of grad students each building a new robot with the same physical capabilities instead of working on making them smarter doesn't make sense.
A far better idea would be for the lab to call the mechanical engineering department and ask them to design a robot with the appropriate physical capabilities, and then get a dozen of them built, which can be programmed by the next decade of grad students.
The current situation is a bit like when chemists blew their own glassware. Sure, it gave them a great feel for the equipment and a related skill, but it took a lot of time away from working with chemicals, and it didn't involve any new research.
Slashdot's features (interviews and such) are primary. Most of the stories (as I mentioned later) aren't really primary, although they're not really commentary either; they should probably just count as a link to the article they site.
There are relatively few cases where new theories are proposed in commentary (even in the case of Chomsky, he's got dozens of equally radical theories that aren't critiques of other works). Of course, there are probably a lot of primary sources which are in web logs (slashdot linked to one about reliable computing today, for instance). But this just means that a primary source might be embedded in a commenting document, or might be published in a forum which generally contains commentary.
What would actually be interesting would be to have the weblog search attached to the main search, with an attempt to figure out what commenting sources are commenting on. So you get documents which are mainly about the topic (as opposed to being about other documents about the topic) listed, and have a link to "what other people have said about this document".
The real problem with the mass of commentary is that if a lot of tightly linked documents are talking about some document, it's relatively hard to find the document that started the whole thing, and the commentary generally assumes that you've read this document. So google is most helpful if it provides the commentary attached to or after the document that it is about.
One thing that would be really neat would be to annotate the google cache of documents with other documents that refer to each section, so that you see commentary next to the original rather than after it or instead of it.
I just did a google search for TyStudio, and none of the results was on slashdot. Perhaps they used to index slashdot, but don't any more?
The way web traffic works, having a few seconds of complete downtime isn't a big deal, especially if you're not closing the listening socket. If you have 1000 hits/minute, and you HUP your web server, and it stops accepting connections (but doesn't reject them) for 6 seconds, killing all of the serving threads after 3 seconds (to let the non-stuck threads finish serving), and restarting them after reading the new configuration, 100 hits will take up to 6 seconds longer than they should, and then you'll have 110% of your average load while it catches up (less than many bursts anyway), and probably nobody will notice, especially if they're remote clients. For web servers and such, completely resetting the "business" portion of the server is fast and not noticeable to the client. About the only thing that would be noticed would be closing the listenning socket with connections open (which, by TCP rules, is supposed to prevent you from openning it again for a long time, and breaks connections and refuses new ones).
It would matter more for protocols where you actually have persistent connections, but such protocols are relatively rare, and are generally designed to be restartable these days (with the exception of ssh, which actually does separate out connections entirely, like you suggest).
Slashdot is great, but do you actually want to get slashdot comments as search results? As far as I can tell, google doesn't index them at all, anyway. To me, it makes sense to separate the search for primary material (like slashdot's links and features) from the commentary on it (the comments). Of course, slashdot's primary material is mainly references to other primary sources, so there's not much for the main google search to get here; the blog search could, however, pick up a lot.
I think the ideal design would be: /**
* The name of this object
*/
private String name;
public String getName();
public setName(String name);
That is, if a method is declared as set* or get*, not declared abstract, and no body is given, the compiler provides the method body to do the obvious thing (and javadoc copies the documentation as appropriate). You should probably be able to drop the return type and maybe the parameter types (although having setName() generate a method with a different signature would be odd). You still get to declare the protection for the methods, though, and any other method attributes you feel like (not that there are any other useful ones right now).
None of these changes will affect an old program compiled with a new compiler (unless it didn't compile before...), nor old class files run against a new library. They've been very careful this time to avoid breaking legacy code. (Unlike in 1.4, where they added a keyword, which broke everybody's testing code, but not the actual programs)