Most things can be diagnosed in other ways, but a good packet sniffer can make it easy to check a whole bunch of things at once. For example, you plug in a computer and try to print to the network printer. Nothing happens. There are about a dozen things that could be wrong with your configuration, and they're all in different places, and not necessarily easy to see at a glance whether they're right. With a packet sniffer, you can see pretty trivially where things went wrong, even if it's something complicated (the nameserver is returning the printer's address as if you were on the private network, but you're not, and the firewall drops the packets).
For that matter, it could be something like "the network gets really slow at 2:30 PM every day". Obviously, it's something out there doing too much, but you've got no idea what machine.
Given that XFree86 has been distributing later X.org versions than 6.0.0 for ages without renaming things (4.0.2, from 2000, had X11R6.5.1), I doubt they'd change anything. Things might change when they get to X11R7, but there's no sign that they're going to do that any time soon. For that matter, that would probably indicate an incompatible change, in which case you'd want to keep the last R6 around anyway for old programs.
You're also paying a premium for hardware design. The sand-proof controls are a real win. I doubt it would be especially hard to implement the interface (although it was probably hard to design it the first time). As for why, you might want to play ogg files. I'm not entirely sure where the system is actually stored, but you might be able to take one of the minis, remove the hard drive (and sell it for more than the cost of the ipod), and put in a CF 802.11 card. Then you could stream music from your computer or over the internet while wearing it around the house.
It's weird that they would bother with GPS. Cell phones communicate with cell towers (obviously), and communicate in particular with nearby cell towers, and towers these days track the signals from phones so that they can use directional sensing to give better signal. The cell network knows exactly where your phone is at all times (when it's on, at least), and can even send messages directly to it.
GPS, on the other hand, is a broadcast system from satellites which don't get any feedback from the receiver. It can enable you to figure out where you are, but the information would need to be sent somewhere else in order for anybody to track you. And, if your device is sending any information off, that signal can be tracked, regardless of what it is.
If you don't want to be tracked, you need to keep your device from transmitting anything. If you take out the battery, it won't have enough power to do much of anything; if you put it in a chainmail bag, it won't be able to transmit out. But you obviously can't have a cell phone that's both untraceable and functional at the same time.
Haven't you ever read any comic books? All of the cool superpowers come from being exposed to radiation. Spiderman, the Russian woman who can see into the past (and take pictures of it), Japanese telecom. The only way that the US is going to regain its technological superiority is through accidental exposure to radiation, but Americans are far too afraid of it these days.
The 911 system seems to have continued to work correctly, but the regular numbers that calls to 911 get directed to were redirected to a bank. So the issue is really that there aren't safeguards against the wrong phone numbers getting changed accidentally, and the phone lines used by the 911 system aren't immune.
Shouldn't the interface for the system prevent you from accidentally modifying similar but unrelated numbers when you're modifying a set of numbers?
You may note that none of the nuclear power plants in the US or Europe is in a skyscraper. People designing nuclear power plants are well away of the quantity of fissionable material in these buildings, and design them to withstand more impact than an airliner and more heat than burning jet fuel, just because of the energy density inside.
If nuclear plants were actually effective targets for terrorists, I bet that terrorists would actually have attacked one of them, rather than a train station. I bet a terrorist attack against a nuclear power plant would be the best thing yet for the nuclear power industry, because it would validate the industry's safety claims when it survived without any problems.
(Note, also, that the Twin Towers were not actually perfectly safe buildings-- they were exempt from building and safety codes due to the particular semi-governmental status of their owner)
On the monitor I'm sitting at, at 1280x1024 (~96 dpi), I can't see individual pixels as dinguished from diagonally adjacent pixels unless I'm at half my normal viewing distance for the monitor. For printed text, you generally hold the book closer to your face, so you want better resolution.
I think that the relation will actually go the other direction; when you can size windows to fit what you're doing, there will be more call for being able to resolve details in small windows, and therefore call for better monitors. As it is, increasing a monitor's resolution, as you said, makes everything smaller and harder to see, so people wouldn't run their monitors at higher resolutions even if they were available.
It wouldn't be the Gates building if mere occupants had general access to the building and could therefore work unobstructed by administrative policies.
You can store a primitive in a collections object in Java 1.5; haven't you read JSR 201? (Well, okay, it actually automatically boxes them for you, and you have to declare it as "Collection" instead of "Collection", but the compiler error message is reasonably informative, and it's trivially caught at compile time.
I'm personally more worried about people who claim to know Java, but think that it is a good idea to keep pools of objects and reuse them. Aside from all of the programming hassles this creates for anyone trying to use the stuff, it messes up the garbage collector, which can't optimize dealing with objects that live forever and reference a ton of unrelated short-lived stuff over time. The problem is not the people who can't actually write any Java; the problem is the people who can write Java, but just make things slower and harder to maintain.
The slashdot article you reference for situation (b) is actually primarily talking about how people weren't downloading music all that much, and CD sales fell. So all of the articles point to downloading and CD sales being correlated when they go up and when they go down.
Now it's certainly possible that there are mediating factors which cause CD sales and downloading to go up and down together. These might include music quality (who wants to download crappy music or buy it?), legal hassles (who wants to get tracked by the RIAA or support them?), and the economy (who has money to pay for music or bandwidth?).
What self-respecting terrorist would carry out an attack involving an airplane in 2004? That's not only 3 years out of style, but it's all been done before. Blowing planes up from on the plane, blowing them up from the ground, planes just blowing up by themselves, blowing up things with planes, starting conspiracy theories about exploding planes, whatever. Nobody would be impressed if you did something with a plane these days (unless maybe you ran a successful airline that people liked). These days, trains and automobiles are much more in fashion, so airport security is entirely irrelevant.
Once all of the devices are in sysfs, udev should take care of/dev quite nicely. It will essentially put in/dev nodes for all of the devices the system knows about, using naming as determined by the user, and not include anything you don't actually have. It can even do silly things, like have device nodes for the music CDs in your CD-playing drives based on the title of the CD (from CDDB), rather than which drive it's in. More sensibly, it will deal with recognizing different USB storage devices regardless of where you plug them in.
It's weird that people keep proposing, as the next generation network, an old design. He's proposing the telephone system, which is pretty nice for good conditions (not too many calls, reliable hardware, nothing getting blown up), but not suitable for applications where you don't have any information about availability (like when you're using mobile repeaters under enemy fire). How do you make sure that a message is delivered reliably when the connection might get blown up by a rocket in the middle? You don't; you provide for recovery in this situation, which is what TCP/IP does.
They really want three things: a replacement for ethernet which doesn't need static infrastructure and is resistant to interference, a dynamic routing mechanism, and a way of authenticating packets to intermediate devices such that they can make policy descisions (e.g., so that the military repeaters can preferentially route military info).
I assume you have sysfs working, and are finding that/sys/block/hda/dev is a plain file. You should be able to use the information in it to create device nodes yourself, however. (E.g., if it says "3:0", "mknod hda b 3 0") It's not quite so convenient as devfs or udev (which is working better these days), but it's essentially correct. For that matter, you could just use a couple of static device nodes for the particular devices you have.
If you're having further problems with your USB storage device once you've created a device node for it, the kernel developers would probably be eager to hear about it. They need to hear these things in order to get 2.6 ready for mainstream use, since they probably don't have the same device.
USB storage devices really are SCSI devices. They're just connected to the motherboard by USB. It's essentially like having a PCI SCSI card (instead of having SCSI on your motherboard), but USB instead of PCI. Also USB specifies that the devices you use are SCSI and not IDE, so your MP3 player doesn't bother to mention that it's SCSI, since it has to be.
I actually think that RedHat and SuSE are going to have a relatively easy time with 2.6, because they don't use devfs in 2.4, and all of your problems seem to be with devfs.
In the Yellowstone calculation, you should take into account the chance that Yellowstone will erupt in a non-devastating way. If there's a minor eruption, that's no big deal (except for tourism, I guess), and it resets the build-up. I suspect there will be some sort of eruption within my lifetime, but I suspect it won't be anything to worry about.
If you happen to like John Buckman's taste in music, Magnatune.com is perfectly happy to sell to anyone anywhere. You can also feel good about where your money is going, since half goes to the artists and the other half goes to the people who give the first half to the artists.
Functional programming is too far from how most programmers currently think, but I think there are two ways it will gain popularity. The first is that some more mainstream languages, such as Java and Python, are moving that way. The functional programming patterns of creating a lot of temporary structures which are garbage collected has become more common, and producing a chain of derived structures is better optimized. Now that Java has Generics and closures, it can have first class methods, and list operations make sense. I don't think Java is headed towards actually becoming a functional language, but it is headed towards making functional languages more accessible.
The other thing is that functional languages are much better at describing the behavior of massively parallel systems (like computers at the hardware level) than imperative languages are, so they are likely to because important in ASIC and FPGA programming. (This is because monads, the serialization technique used in functional programming, work well for collections of changes to the state with unspecified relative order, while sequential instructions are bad at representing the range of possible variation.
I thought SCO already claimed to have retracted HP's license. Does Novell have a UNIX license? It would be pretty weird to have a license to something you own. My guess is SGI and Microsoft.
Microsoft seems to me to be the perfect target: they are reportedly using Linux and they have UNIX license. SCO (as Caldera) has beaten Microsoft in court before. Microsoft's not as big as, say, IBM. And suing Microsoft might hush the rumors that they're colluding.
Clearly, it's time to adopt the protocol for getting unbiased randomness out of a biases source.
Somebody calls "1st" or "2nd". Flip the coin twice (starting with the same side up each time). If it is first heads, then tails "1st" wins. If it is tails first and heads second, "2nd" wins. Otherwise, repeat.
So this guy has written a long letter to some random programmer he met at a conference (and, possibly unintentionally, to the slashdot community). He's put a whole lot of effort into saying that you shouldn't give away your work, and then... he gave it away. The only thing that makes any sense is if he was paid by some organization to oppose free software, since the recipients are clearly not going to pay for his work. So he's either a hypocrit or a shill, and his advice is suspect in either case.
In favor of a more openly-developed fork of XFree86 4.4rc2, perhaps. The beauty of OSS is that, if the official core team goes so nuts that people can't stand it any more, they can dump the name and the old core team, and continue from the last good point.
I'd suggest that the distributions who aren't going to include versions under the new license start a new project into which they can put their contributions and the contributions of anyone who doesn't want to use the new license. I think they should bump the number of the project, and release XFree87 4.4 shortly.
Slashdot Mirror
Most things can be diagnosed in other ways, but a good packet sniffer can make it easy to check a whole bunch of things at once. For example, you plug in a computer and try to print to the network printer. Nothing happens. There are about a dozen things that could be wrong with your configuration, and they're all in different places, and not necessarily easy to see at a glance whether they're right. With a packet sniffer, you can see pretty trivially where things went wrong, even if it's something complicated (the nameserver is returning the printer's address as if you were on the private network, but you're not, and the firewall drops the packets).
For that matter, it could be something like "the network gets really slow at 2:30 PM every day". Obviously, it's something out there doing too much, but you've got no idea what machine.
Given that XFree86 has been distributing later X.org versions than 6.0.0 for ages without renaming things (4.0.2, from 2000, had X11R6.5.1), I doubt they'd change anything. Things might change when they get to X11R7, but there's no sign that they're going to do that any time soon. For that matter, that would probably indicate an incompatible change, in which case you'd want to keep the last R6 around anyway for old programs.
You're also paying a premium for hardware design. The sand-proof controls are a real win. I doubt it would be especially hard to implement the interface (although it was probably hard to design it the first time). As for why, you might want to play ogg files. I'm not entirely sure where the system is actually stored, but you might be able to take one of the minis, remove the hard drive (and sell it for more than the cost of the ipod), and put in a CF 802.11 card. Then you could stream music from your computer or over the internet while wearing it around the house.
It's weird that they would bother with GPS. Cell phones communicate with cell towers (obviously), and communicate in particular with nearby cell towers, and towers these days track the signals from phones so that they can use directional sensing to give better signal. The cell network knows exactly where your phone is at all times (when it's on, at least), and can even send messages directly to it.
GPS, on the other hand, is a broadcast system from satellites which don't get any feedback from the receiver. It can enable you to figure out where you are, but the information would need to be sent somewhere else in order for anybody to track you. And, if your device is sending any information off, that signal can be tracked, regardless of what it is.
If you don't want to be tracked, you need to keep your device from transmitting anything. If you take out the battery, it won't have enough power to do much of anything; if you put it in a chainmail bag, it won't be able to transmit out. But you obviously can't have a cell phone that's both untraceable and functional at the same time.
Haven't you ever read any comic books? All of the cool superpowers come from being exposed to radiation. Spiderman, the Russian woman who can see into the past (and take pictures of it), Japanese telecom. The only way that the US is going to regain its technological superiority is through accidental exposure to radiation, but Americans are far too afraid of it these days.
The 911 system seems to have continued to work correctly, but the regular numbers that calls to 911 get directed to were redirected to a bank. So the issue is really that there aren't safeguards against the wrong phone numbers getting changed accidentally, and the phone lines used by the 911 system aren't immune.
Shouldn't the interface for the system prevent you from accidentally modifying similar but unrelated numbers when you're modifying a set of numbers?
You may note that none of the nuclear power plants in the US or Europe is in a skyscraper. People designing nuclear power plants are well away of the quantity of fissionable material in these buildings, and design them to withstand more impact than an airliner and more heat than burning jet fuel, just because of the energy density inside.
If nuclear plants were actually effective targets for terrorists, I bet that terrorists would actually have attacked one of them, rather than a train station. I bet a terrorist attack against a nuclear power plant would be the best thing yet for the nuclear power industry, because it would validate the industry's safety claims when it survived without any problems.
(Note, also, that the Twin Towers were not actually perfectly safe buildings-- they were exempt from building and safety codes due to the particular semi-governmental status of their owner)
On the monitor I'm sitting at, at
1280x1024 (~96 dpi), I can't see individual pixels as dinguished from diagonally adjacent pixels unless I'm at half my normal viewing distance for the monitor. For printed text, you generally hold the book closer to your face, so you want better resolution.
I think that the relation will actually go the other direction; when you can size windows to fit what you're doing, there will be more call for being able to resolve details in small windows, and therefore call for better monitors. As it is, increasing a monitor's resolution, as you said, makes everything smaller and harder to see, so people wouldn't run their monitors at higher resolutions even if they were available.
It wouldn't be the Gates building if mere occupants had general access to the building and could therefore work unobstructed by administrative policies.
You can store a primitive in a collections object in Java 1.5; haven't you read JSR 201? (Well, okay, it actually automatically boxes them for you, and you have to declare it as "Collection" instead of "Collection", but the compiler error message is reasonably informative, and it's trivially caught at compile time.
I'm personally more worried about people who claim to know Java, but think that it is a good idea to keep pools of objects and reuse them. Aside from all of the programming hassles this creates for anyone trying to use the stuff, it messes up the garbage collector, which can't optimize dealing with objects that live forever and reference a ton of unrelated short-lived stuff over time. The problem is not the people who can't actually write any Java; the problem is the people who can write Java, but just make things slower and harder to maintain.
The slashdot article you reference for situation (b) is actually primarily talking about how people weren't downloading music all that much, and CD sales fell. So all of the articles point to downloading and CD sales being correlated when they go up and when they go down.
Now it's certainly possible that there are mediating factors which cause CD sales and downloading to go up and down together. These might include music quality (who wants to download crappy music or buy it?), legal hassles (who wants to get tracked by the RIAA or support them?), and the economy (who has money to pay for music or bandwidth?).
What self-respecting terrorist would carry out an attack involving an airplane in 2004? That's not only 3 years out of style, but it's all been done before. Blowing planes up from on the plane, blowing them up from the ground, planes just blowing up by themselves, blowing up things with planes, starting conspiracy theories about exploding planes, whatever. Nobody would be impressed if you did something with a plane these days (unless maybe you ran a successful airline that people liked). These days, trains and automobiles are much more in fashion, so airport security is entirely irrelevant.
Vg nccrnef lbh ner gelvat gb qryrgr vapevzvangvat vasbezngvba. Jbhyq lbh yvxr zr gb znxr vg fyvtugyl qvssvphyg gb ernq nppvqragnyyl?
Once all of the devices are in sysfs, udev should take care of /dev quite nicely. It will essentially put in /dev nodes for all of the devices the system knows about, using naming as determined by the user, and not include anything you don't actually have. It can even do silly things, like have device nodes for the music CDs in your CD-playing drives based on the title of the CD (from CDDB), rather than which drive it's in. More sensibly, it will deal with recognizing different USB storage devices regardless of where you plug them in.
It's weird that people keep proposing, as the next generation network, an old design. He's proposing the telephone system, which is pretty nice for good conditions (not too many calls, reliable hardware, nothing getting blown up), but not suitable for applications where you don't have any information about availability (like when you're using mobile repeaters under enemy fire). How do you make sure that a message is delivered reliably when the connection might get blown up by a rocket in the middle? You don't; you provide for recovery in this situation, which is what TCP/IP does.
They really want three things: a replacement for ethernet which doesn't need static infrastructure and is resistant to interference, a dynamic routing mechanism, and a way of authenticating packets to intermediate devices such that they can make policy descisions (e.g., so that the military repeaters can preferentially route military info).
I assume you have sysfs working, and are finding that /sys/block/hda/dev is a plain file. You should be able to use the information in it to create device nodes yourself, however. (E.g., if it says "3:0", "mknod hda b 3 0") It's not quite so convenient as devfs or udev (which is working better these days), but it's essentially correct. For that matter, you could just use a couple of static device nodes for the particular devices you have.
If you're having further problems with your USB storage device once you've created a device node for it, the kernel developers would probably be eager to hear about it. They need to hear these things in order to get 2.6 ready for mainstream use, since they probably don't have the same device.
USB storage devices really are SCSI devices. They're just connected to the motherboard by USB. It's essentially like having a PCI SCSI card (instead of having SCSI on your motherboard), but USB instead of PCI. Also USB specifies that the devices you use are SCSI and not IDE, so your MP3 player doesn't bother to mention that it's SCSI, since it has to be.
I actually think that RedHat and SuSE are going to have a relatively easy time with 2.6, because they don't use devfs in 2.4, and all of your problems seem to be with devfs.
See whether you can compile the new driver as an external module for your existing kernel?
In the Yellowstone calculation, you should take into account the chance that Yellowstone will erupt in a non-devastating way. If there's a minor eruption, that's no big deal (except for tourism, I guess), and it resets the build-up. I suspect there will be some sort of eruption within my lifetime, but I suspect it won't be anything to worry about.
If you happen to like John Buckman's taste in music, Magnatune.com is perfectly happy to sell to anyone anywhere. You can also feel good about where your money is going, since half goes to the artists and the other half goes to the people who give the first half to the artists.
That's why you don't give tcsh to newbies...
Functional programming is too far from how most programmers currently think, but I think there are two ways it will gain popularity. The first is that some more mainstream languages, such as Java and Python, are moving that way. The functional programming patterns of creating a lot of temporary structures which are garbage collected has become more common, and producing a chain of derived structures is better optimized. Now that Java has Generics and closures, it can have first class methods, and list operations make sense. I don't think Java is headed towards actually becoming a functional language, but it is headed towards making functional languages more accessible.
The other thing is that functional languages are much better at describing the behavior of massively parallel systems (like computers at the hardware level) than imperative languages are, so they are likely to because important in ASIC and FPGA programming. (This is because monads, the serialization technique used in functional programming, work well for collections of changes to the state with unspecified relative order, while sequential instructions are bad at representing the range of possible variation.
I thought SCO already claimed to have retracted HP's license. Does Novell have a UNIX license? It would be pretty weird to have a license to something you own. My guess is SGI and Microsoft.
Microsoft seems to me to be the perfect target: they are reportedly using Linux and they have UNIX license. SCO (as Caldera) has beaten Microsoft in court before. Microsoft's not as big as, say, IBM. And suing Microsoft might hush the rumors that they're colluding.
Clearly, it's time to adopt the protocol for getting unbiased randomness out of a biases source.
Somebody calls "1st" or "2nd". Flip the coin twice (starting with the same side up each time). If it is first heads, then tails "1st" wins. If it is tails first and heads second, "2nd" wins. Otherwise, repeat.
So this guy has written a long letter to some random programmer he met at a conference (and, possibly unintentionally, to the slashdot community). He's put a whole lot of effort into saying that you shouldn't give away your work, and then... he gave it away. The only thing that makes any sense is if he was paid by some organization to oppose free software, since the recipients are clearly not going to pay for his work. So he's either a hypocrit or a shill, and his advice is suspect in either case.
In favor of a more openly-developed fork of XFree86 4.4rc2, perhaps. The beauty of OSS is that, if the official core team goes so nuts that people can't stand it any more, they can dump the name and the old core team, and continue from the last good point.
I'd suggest that the distributions who aren't going to include versions under the new license start a new project into which they can put their contributions and the contributions of anyone who doesn't want to use the new license. I think they should bump the number of the project, and release XFree87 4.4 shortly.