To those of you offering technical solutions: stop. You're wasting your energy.
Any time you see "policy" or "auditing," turn off your brain and channel your inner Bill Lumbergh. These tools are all about generating pretty graphs showing how many computers were checked and had the "IT policy enforced and audited." SOX, PCI/DSS, and other auditors get their jollies seeing reports like this. As long as the software generating the report is a name they know (and, preferably, expensive -- because, you see, expensive means it's good), they'll check that box on their report without so much as a second thought, making your C*O happy.
For all the auditors know, this software could be doing nothing other than generating (fake) reports. For them, it doesn't matter; as long as the other auditors are doing it, it's a "best practice" and their butts are covered.
Wouldn't the terrorists just use the unblur and image enhancement filters that I see on CSI and other fine TV shows? We'll need to outlaw that, as well.
(And by "that," I'm not sure if I mean the "technology" or CSI itself...)
You should be using localtime()/gmtime()/strftime() to convert, as it is the only POSIX API guaranteed to implement the correct algorithm. If a program implements its own algorithm, it's broken. (See the US shift in DST rules a couple years back...)
And, yes, you are expected to change your system every time the rules change. Fortunately, it's just a matter of applying an updated set of tzinfo files (again, unless you've gone and reinvented the wheel).
I would agree that if POSIX just ignored leap seconds and let time_t increase monotonically through them, life would be ok. But that's not what it does! It actually goes through some hoops to implement the repeating time_t hiccup and sort through a few edge cases which result.
POSIX got this horribly wrong, making your perfectly logical argument incorrect. Wikipedia has a good illustration of what actually happens: Unix time hiccups and loops back on itself for that second.
TAI time is a count since an epoch, but Unix time is aligned with UTC, not TAI.
Memory in all computers is mapped to address space. I get the idea that these guys are programmers who don't really understand how the hardware works.
I would read their claims about "address space" as "separate address space" -- that is, everything runs in a single address space. Then it makes some sense.
Nobody needs files? How, exactly, can I retrieve a document then? This FA is damned short on details.
I'm guessing you don't "retrieve" documents; they're always there in memory (whether that memory is RAM or disk appears to be irrelevant for this OS; it looks like they're treating it all as a giant instance of virtual memory). Don't ask me how selecting which document to read/edit works; it would seem that lack of files breaks the window-per-open-document model, and I certainly wouldn't want to have a window around for every document I've ever written or received.
Removing the distinction between "document open in memory" vs. "document stored on disk" can be a very powerful metaphor, but it does break down rather easily. There are times when the user does care about where the document resides: e.g. that text file better be on my USB stick so I can transport it to the office.
The only alternative I can think of is a single, global, virtual memory mapping which spans every computer you would ever want to interact with. Interesting idea, but not terribly practical.
I really don't think I'm interested in this OS. TFA didn't point to a single thing about it that would lead me to want it, except for the state saving on shutdown, and I doubt seriously that's going to work. If your data are in memory and not the hard drive when it quits, you'll lose your data. If data are all written instantly to the HD, your PC will be slower than molasses in january.
This isn't all that different from hibernation, which ensures that the entire system state is written out before power is removed. That said, this doesn't mean you can remove power arbitrarily...
The bulk of the expense with a T-1 goes to the 'loop' charge, i.e: the money you are paying the local telco to lease two (or more with certain implementations) pairs on their plant.
The resource usage itself doesn't cost the telco that much. What you're really paying for on these two lines is the aggressive SLA.
Your T1 goes down? The telco has 4 hours to restore it before incurring penalties.
Your cable/DSL goes down? They'll dispatch a tech when convenient (for them).
I agree. I think it would be more beneficial to get these apps either ported fully to Linux (using the native toolkits or WineLib; take your pick), or have them work with the Wine developers to document flaws in their library implementations and help patch it up.
Having dabbled on Wine a looong time ago (I think my last contributions were in 96 or 97?), let me say that this is a very difficult problem to solve. It's easy to get the first 80% done, but the last 20% can be maddening. Trying to bridge between two different rendering models isn't easy, either -- things as simple as drawing a line can have surprising differences in Win32 vs. X (like whether that last pixel is drawn or not!).
Except that what you actually do is promise to paint it red even though you know that you do not have and cannot get any red paint.
It doesn't matter, anyway, because the customer changes his mind mid-project and wants it blue. After it's delivered, they realize they wanted a bicycle, not software. Nonetheless, they attempt to ride it.
While this makes about as much sense as the Chewbacca Defense, this explains a good 50% of the projects I've worked on. Hm. Right, I'll just sob in my tea now...
Imagine if the brakes on your car failed just 1% of the time.
This isn't a correct comparison. They made errors 1% of the time. An error becomes a failure only when it is allowed to cascade through the system.
We had a similar presentation at work (from one of our grizzled engineers who is also an amateur pilot). A commercial flight encounters, on average, two errors. However, this doesn't mean your average flight crashes and burns; these errors are corrected through redundancy. For example, this is why pilots repeat the instructions given to them by air traffic control before carrying them out. ("Set altitute to nineteen thousand" is very different than "set altitute to nine thousand," though they can sound alike!)
I presume some of these actions are trivial otherwise I'd be amazed if anyone survived.
Some are trivial: Mr. Smith got his dinner switched with Ms. Doe. Some are corrected: Dr. Hathaway asked Nurse Jones how Mr. Smith is responding to his meds, which Jones had forgotten to administer but promptly remedied. And the rest... yeah, that's when bad things happen.
It can be hard to institute these sorts of checklists onto an existing system, though. People often take it as an insult to their skills and intelligence ("Yes, I know how to upgrade a server. I've done it a thousand times." "Yes, I know how to perform bypass surgery. I've done it a thousand times."). The trick is finding a way to get people to want to do it.
One tends to be far more careful about allocating memory in C, because the cost is obvious.
Well, I'd replace that with "one hopes that C coders tend to be more careful...":-) Sadly, I've had to deal with C++ code which was extremely sloppy about who-owned-what. A hefty 250 kloc project at the time which bloated to just under a million lines before it shipped, with special code to swallow segfaults so the user never saw a core dump message. It was a nightmare. (And, yes, "lines of code" was a point that management liked to brag about to potential customers... <sigh>)
That's not AOT, though. AOT code is a first pass compilation of the bytecode to native code. The application still runs in the JVM, but the slow startup is alleviated because that first pass JIT never happens. An optimizing JVM can still work its magic.
Ah, then I misunderstood. I don't see how this would alleviate the slow startup; aren't you still taking the time to compile when the JVM starts? Or does this first pass happen outside of the JVM? If the latter, how does the JVM verify that the generated native code matches the Java bytecode (and hasn't been tampered with)?
Compiling Java to unchecked native code takes away all the point of using Java. "As far as you are concerned" doesn't mean a lot when the OS doesn't actually do what you want it to anyway.
We might be using different meanings of "unchecked" here. I don't mean that you would remove the normal runtime checks that Java performs (index bounds, etc.) intentionally. I want those. Those prevent my bugs from becoming catastrophes.
The checks I don't need: having the JVM go in beforehand and look for malicious code (which it normally does for bytecode). For my servers, I already know the origin of the code. This is the code that I compiled myself (and either wrote myself or used an open source library like Jakarta). Thanks to SOX controls we had to write, we have a high degree of confidence that what was deployed to the server matches what's in our build repository (secure hashes match).
Granted, this doesn't work when you're downloading the compiled native code from some untrusted source. I wouldn't do that for C code; I certainly won't do it for Java code.
Right. I'm not trying to claim that C is more or less efficient; I'm just saying that measuring memory usage is a tricky game (regardless of language). This makes trying to determine why, for example, an Oracle database (which has a pool of shared memory mapped into the address space of a ton of processes) is paging incessantly is always a curious game...
I know that implementations of mmap()-based malloc/free exist, but these aren't part of any libc that I'm aware of. However, if you've written a custom allocator, this is a question you face. This is something I saw a lot back when I worked on chip design (EDA) code: when you're dealing with a data set which doesn't fit in memory, memory fragmentation becomes a big deal...
Heh... assuming AOT == ahead of time compilation, I find it funny that they have a term to describe what the rest of the world just calls "compilation.":-)
Yes, AOT can be much faster. Case in point is gcj, which compiles Java code to normal ELF objects -- and, of course, no VM required, so a JVM doesn't even come into the equation. You will lose validation checks (e.g., the code can segfault if it's tweaked), but from my perspective: who cares? Obviously, this isn't something I would want playing in my browser (but, then, who uses browser Java applets anymore?), but for something like Eclipse it's wonderful.
There are some runtime security checks which might go missing, too. As far as I'm concerned, that is the domain of the OS, not a VM I'm starting up myself.
Anyway, yes: I'm keen on seeing Java compiled to native platform binaries. Sadly, this is still a niche rather than the dominant model. I don't see my workplace getting off of Sun JVMs anytime in the near future, for example.
Java is still glacially slow at startup. Even before you get to the JIT stage, it has to decompress the JARs, extract the class files, validate them, and then start executing the bytecode (or incur a JIT compilation cycle and then execute native code). Validation can take a fair amount of time -- doing so requires each method to be simulated (making sure the stack stays coherent no matter how a given instruction is reached, for example) -- though the Hotspot JVM lets you disable this. A fully native application, on the other hand, just maps the files into memory, applies relocations (if that's even necessary these days), and then starts executing.
For server code, I don't care about Java's startup time. I'm usually checking out a number of database connections, catching up on logs, and doing a zillion other things which make the JVM startup tasks insignificant. For a small command-line utility, on the other hand, the difference is very noticeable.
Also, even in native code, Java is performing a number of extra security and boundary checks which equivalent C code usually doesn't have. I consider this a feature.
if you use 300 MB in a C program, it will *always* use 300MB forever after too.
Depends on what you mean by "use." If you mean it will have mapped that much into its memory space, that's usually true if the allocator is sbrk() based. mmap() based allocators, on the other hand, can return the memory to the OS.
However, "use" even in the sbrk() case doesn't mean you've used 300MB of RAM. If you never touch it again, it'll be paged out to swap or, if the allocator is written in this way, not have any memory backed to it whatsoever (one can use mprotect() to indicate a range of memory has no access permissions, for example). Yes, those 300MB will be in your address space, but address space != memory.
It was on Slashdot (and a few other widely read blogs) previously. That forces Amazon's hand: do nothing, and your vendor (the record companies) will make your life miserable -- far more miserable than the loss in sales you're describing.
Touché.:-) You're right, I was being redundant; my intent was to call out the non-DRM-ness of the offering.
Indeed, no, at least that I'm aware of. It is possible to watermark them, but such marks are easily removed by re-encoding the MP3 file. Now, it's possible to use MPEG 1 Layer 3 encoding technologies and layer DRM on top of it, but the result would not be what anyone would consider to be an MP3 file.
Amazon has inked distribution deals with a bunch of record companies -- deals which are certainly not permanent. If anything, given that Amazon is the first major seller of non-DRM-encumbered MP3s, these deals are probably subject to renewal in a short period of time (so that the record companies could pull the plug if need be).
Now a way of circumventing sales -- however obvious and silly -- which places links on Amazon's pages is featured on Slashdot, a fairly well read site. You're Amazon's legal department. Do you decide to: (a) Exert pressure on the authors of this tool to remove it, thus demonstrating to the record companies that you are serious about your agreement with them and make the next round of negotiations easier? If so, turn to page 72.
(b) Do nothing. If so, turn to page 93 -- and prepare to get reamed in the ass when the record labels demand $2.50 per download.
This has nothing to do with public relations and everything to do with vendor relations.
But at least as far as I know, there isn't a device that threatens the mouse as of today.
How about laptops? I'm typing this on a generic, work-issued Dell Latitude. It has a trackpad and a trackpoint, but no mouse. On my commute (a ferry across Puget Sound), I see a number of other folks all wielding mice-less laptops.
Given that laptops are becoming more common purchases than desktops, I can see mice taking less of a market share in the future. Demise, though? Nah.
Ah, you won't get any disagreement from me about the ISP aspect -- they have no business inspecting the packets and should be taking a hands-off approach. They should be clearly setting the terms of the service (peak and average bandwidth) and throttle or reject usage above this limit.
I was just saying that the post office isn't necessarily a good comparison. They certainly should be opening/rejecting anything which will cause physical harm to the carriers or recipients (letter bombs and the like). I'm less pleased with the law enforcement allowances (that's a loophole which can be too easily exploited), but it's there nonetheless. (And, I have to admit, the postal inspectors are rather successful at their mission. They keep a low profile and use discretion, which is a lot more than one could say about many other law enforcement agencies.)
Last I checked, the USPS still asked if you were shipping anything dangerous, flammable, or perishable. They also employed a team of postal inspectors to handle cases of fraud, abuse, and other illegal activities taking place in the postal system.
So, yes; they do have the right to screen your mail.
Keep in mind: you're talking about a processor which doesn't even have integer multiplication, let alone any floating point operations. And you have only three 8-bit registers to perform these operations in. Executing 1k instructions for even a basic FLOP is not inconceivable here.
Radio Shack isn't the same anymore. I did spend a fair amount of time there in the 80s, getting the bits together to put together crystal radios and the like. Sadly, many of their stores don't even carry the supplies to build a crystal radio any longer; it's all consumer throw away gadgets now. (Yes, I'm getting old, and you kids better get off my lawn...:-)
You can order some of those kits from their catalog, but you might as well go with AS&S or another webstore. They're usually cheaper and have a bigger selection.
Slashdot Mirror
To those of you offering technical solutions: stop. You're wasting your energy.
Any time you see "policy" or "auditing," turn off your brain and channel your inner Bill Lumbergh. These tools are all about generating pretty graphs showing how many computers were checked and had the "IT policy enforced and audited." SOX, PCI/DSS, and other auditors get their jollies seeing reports like this. As long as the software generating the report is a name they know (and, preferably, expensive -- because, you see, expensive means it's good), they'll check that box on their report without so much as a second thought, making your C*O happy.
For all the auditors know, this software could be doing nothing other than generating (fake) reports. For them, it doesn't matter; as long as the other auditors are doing it, it's a "best practice" and their butts are covered.
Wouldn't the terrorists just use the unblur and image enhancement filters that I see on CSI and other fine TV shows? We'll need to outlaw that, as well.
(And by "that," I'm not sure if I mean the "technology" or CSI itself...)
You should be using localtime()/gmtime()/strftime() to convert, as it is the only POSIX API guaranteed to implement the correct algorithm. If a program implements its own algorithm, it's broken. (See the US shift in DST rules a couple years back...)
And, yes, you are expected to change your system every time the rules change. Fortunately, it's just a matter of applying an updated set of tzinfo files (again, unless you've gone and reinvented the wheel).
I would agree that if POSIX just ignored leap seconds and let time_t increase monotonically through them, life would be ok. But that's not what it does! It actually goes through some hoops to implement the repeating time_t hiccup and sort through a few edge cases which result.
POSIX got this horribly wrong, making your perfectly logical argument incorrect. Wikipedia has a good illustration of what actually happens: Unix time hiccups and loops back on itself for that second.
TAI time is a count since an epoch, but Unix time is aligned with UTC, not TAI.
Even worse: According to POSIX, 2100 is a leap year.
Memory in all computers is mapped to address space. I get the idea that these guys are programmers who don't really understand how the hardware works.
I would read their claims about "address space" as "separate address space" -- that is, everything runs in a single address space. Then it makes some sense.
Nobody needs files? How, exactly, can I retrieve a document then? This FA is damned short on details.
I'm guessing you don't "retrieve" documents; they're always there in memory (whether that memory is RAM or disk appears to be irrelevant for this OS; it looks like they're treating it all as a giant instance of virtual memory). Don't ask me how selecting which document to read/edit works; it would seem that lack of files breaks the window-per-open-document model, and I certainly wouldn't want to have a window around for every document I've ever written or received.
Removing the distinction between "document open in memory" vs. "document stored on disk" can be a very powerful metaphor, but it does break down rather easily. There are times when the user does care about where the document resides: e.g. that text file better be on my USB stick so I can transport it to the office.
The only alternative I can think of is a single, global, virtual memory mapping which spans every computer you would ever want to interact with. Interesting idea, but not terribly practical.
I really don't think I'm interested in this OS. TFA didn't point to a single thing about it that would lead me to want it, except for the state saving on shutdown, and I doubt seriously that's going to work. If your data are in memory and not the hard drive when it quits, you'll lose your data. If data are all written instantly to the HD, your PC will be slower than molasses in january.
This isn't all that different from hibernation, which ensures that the entire system state is written out before power is removed. That said, this doesn't mean you can remove power arbitrarily...
The bulk of the expense with a T-1 goes to the 'loop' charge, i.e: the money you are paying the local telco to lease two (or more with certain implementations) pairs on their plant.
The resource usage itself doesn't cost the telco that much. What you're really paying for on these two lines is the aggressive SLA.
Your T1 goes down? The telco has 4 hours to restore it before incurring penalties.
Your cable/DSL goes down? They'll dispatch a tech when convenient (for them).
I agree. I think it would be more beneficial to get these apps either ported fully to Linux (using the native toolkits or WineLib; take your pick), or have them work with the Wine developers to document flaws in their library implementations and help patch it up.
Having dabbled on Wine a looong time ago (I think my last contributions were in 96 or 97?), let me say that this is a very difficult problem to solve. It's easy to get the first 80% done, but the last 20% can be maddening. Trying to bridge between two different rendering models isn't easy, either -- things as simple as drawing a line can have surprising differences in Win32 vs. X (like whether that last pixel is drawn or not!).
They're about networking, social skills, and shameless self-promotion.
I've got the networking part down pat. I replaced the 100 Mbit Ethernet switch on my desk with a gigabit switch.
I need to get back to hacking my Wikipedia entry for that self-promotion bit...
A good editor should re-indent the pasted code automatically. In VIM you can use :set ai, si.
Was this taken directly from the sendmail book of configuration file design? Ai! Si, señor!
Except that what you actually do is promise to paint it red even though you know that you do not have and cannot get any red paint.
It doesn't matter, anyway, because the customer changes his mind mid-project and wants it blue. After it's delivered, they realize they wanted a bicycle, not software. Nonetheless, they attempt to ride it.
While this makes about as much sense as the Chewbacca Defense, this explains a good 50% of the projects I've worked on. Hm. Right, I'll just sob in my tea now...
Imagine if the brakes on your car failed just 1% of the time.
This isn't a correct comparison. They made errors 1% of the time. An error becomes a failure only when it is allowed to cascade through the system.
We had a similar presentation at work (from one of our grizzled engineers who is also an amateur pilot). A commercial flight encounters, on average, two errors. However, this doesn't mean your average flight crashes and burns; these errors are corrected through redundancy. For example, this is why pilots repeat the instructions given to them by air traffic control before carrying them out. ("Set altitute to nineteen thousand" is very different than "set altitute to nine thousand," though they can sound alike!)
I presume some of these actions are trivial otherwise I'd be amazed if anyone survived.
Some are trivial: Mr. Smith got his dinner switched with Ms. Doe. Some are corrected: Dr. Hathaway asked Nurse Jones how Mr. Smith is responding to his meds, which Jones had forgotten to administer but promptly remedied. And the rest... yeah, that's when bad things happen.
It can be hard to institute these sorts of checklists onto an existing system, though. People often take it as an insult to their skills and intelligence ("Yes, I know how to upgrade a server. I've done it a thousand times." "Yes, I know how to perform bypass surgery. I've done it a thousand times."). The trick is finding a way to get people to want to do it.
One tends to be far more careful about allocating memory in C, because the cost is obvious.
Well, I'd replace that with "one hopes that C coders tend to be more careful..." :-) Sadly, I've had to deal with C++ code which was extremely sloppy about who-owned-what. A hefty 250 kloc project at the time which bloated to just under a million lines before it shipped, with special code to swallow segfaults so the user never saw a core dump message. It was a nightmare. (And, yes, "lines of code" was a point that management liked to brag about to potential customers... <sigh>)
That's not AOT, though. AOT code is a first pass compilation of the bytecode to native code. The application still runs in the JVM, but the slow startup is alleviated because that first pass JIT never happens. An optimizing JVM can still work its magic.
Ah, then I misunderstood. I don't see how this would alleviate the slow startup; aren't you still taking the time to compile when the JVM starts? Or does this first pass happen outside of the JVM? If the latter, how does the JVM verify that the generated native code matches the Java bytecode (and hasn't been tampered with)?
Compiling Java to unchecked native code takes away all the point of using Java. "As far as you are concerned" doesn't mean a lot when the OS doesn't actually do what you want it to anyway.
We might be using different meanings of "unchecked" here. I don't mean that you would remove the normal runtime checks that Java performs (index bounds, etc.) intentionally. I want those. Those prevent my bugs from becoming catastrophes.
The checks I don't need: having the JVM go in beforehand and look for malicious code (which it normally does for bytecode). For my servers, I already know the origin of the code. This is the code that I compiled myself (and either wrote myself or used an open source library like Jakarta). Thanks to SOX controls we had to write, we have a high degree of confidence that what was deployed to the server matches what's in our build repository (secure hashes match).
Granted, this doesn't work when you're downloading the compiled native code from some untrusted source. I wouldn't do that for C code; I certainly won't do it for Java code.
Right. I'm not trying to claim that C is more or less efficient; I'm just saying that measuring memory usage is a tricky game (regardless of language). This makes trying to determine why, for example, an Oracle database (which has a pool of shared memory mapped into the address space of a ton of processes) is paging incessantly is always a curious game...
I know that implementations of mmap()-based malloc/free exist, but these aren't part of any libc that I'm aware of. However, if you've written a custom allocator, this is a question you face. This is something I saw a lot back when I worked on chip design (EDA) code: when you're dealing with a data set which doesn't fit in memory, memory fragmentation becomes a big deal...
Heh... assuming AOT == ahead of time compilation, I find it funny that they have a term to describe what the rest of the world just calls "compilation." :-)
Yes, AOT can be much faster. Case in point is gcj, which compiles Java code to normal ELF objects -- and, of course, no VM required, so a JVM doesn't even come into the equation. You will lose validation checks (e.g., the code can segfault if it's tweaked), but from my perspective: who cares? Obviously, this isn't something I would want playing in my browser (but, then, who uses browser Java applets anymore?), but for something like Eclipse it's wonderful.
There are some runtime security checks which might go missing, too. As far as I'm concerned, that is the domain of the OS, not a VM I'm starting up myself.
Anyway, yes: I'm keen on seeing Java compiled to native platform binaries. Sadly, this is still a niche rather than the dominant model. I don't see my workplace getting off of Sun JVMs anytime in the near future, for example.
"Java is slow" is a stupid old myth.
Java is still glacially slow at startup. Even before you get to the JIT stage, it has to decompress the JARs, extract the class files, validate them, and then start executing the bytecode (or incur a JIT compilation cycle and then execute native code). Validation can take a fair amount of time -- doing so requires each method to be simulated (making sure the stack stays coherent no matter how a given instruction is reached, for example) -- though the Hotspot JVM lets you disable this. A fully native application, on the other hand, just maps the files into memory, applies relocations (if that's even necessary these days), and then starts executing.
For server code, I don't care about Java's startup time. I'm usually checking out a number of database connections, catching up on logs, and doing a zillion other things which make the JVM startup tasks insignificant. For a small command-line utility, on the other hand, the difference is very noticeable.
Also, even in native code, Java is performing a number of extra security and boundary checks which equivalent C code usually doesn't have. I consider this a feature.
if you use 300 MB in a C program, it will *always* use 300MB forever after too.
Depends on what you mean by "use." If you mean it will have mapped that much into its memory space, that's usually true if the allocator is sbrk() based. mmap() based allocators, on the other hand, can return the memory to the OS.
However, "use" even in the sbrk() case doesn't mean you've used 300MB of RAM. If you never touch it again, it'll be paged out to swap or, if the allocator is written in this way, not have any memory backed to it whatsoever (one can use mprotect() to indicate a range of memory has no access permissions, for example). Yes, those 300MB will be in your address space, but address space != memory.
It was on Slashdot (and a few other widely read blogs) previously. That forces Amazon's hand: do nothing, and your vendor (the record companies) will make your life miserable -- far more miserable than the loss in sales you're describing.
It's a no-win situation.
Is there such a thing as a DRM-encumbered MP3?
Touché. :-) You're right, I was being redundant; my intent was to call out the non-DRM-ness of the offering.
Indeed, no, at least that I'm aware of. It is possible to watermark them, but such marks are easily removed by re-encoding the MP3 file. Now, it's possible to use MPEG 1 Layer 3 encoding technologies and layer DRM on top of it, but the result would not be what anyone would consider to be an MP3 file.
Amazon has inked distribution deals with a bunch of record companies -- deals which are certainly not permanent. If anything, given that Amazon is the first major seller of non-DRM-encumbered MP3s, these deals are probably subject to renewal in a short period of time (so that the record companies could pull the plug if need be).
Now a way of circumventing sales -- however obvious and silly -- which places links on Amazon's pages is featured on Slashdot, a fairly well read site. You're Amazon's legal department. Do you decide to:
(a) Exert pressure on the authors of this tool to remove it, thus demonstrating to the record companies that you are serious about your agreement with them and make the next round of negotiations easier? If so, turn to page 72.
(b) Do nothing. If so, turn to page 93 -- and prepare to get reamed in the ass when the record labels demand $2.50 per download.
This has nothing to do with public relations and everything to do with vendor relations.
But at least as far as I know, there isn't a device that threatens the mouse as of today.
How about laptops? I'm typing this on a generic, work-issued Dell Latitude. It has a trackpad and a trackpoint, but no mouse. On my commute (a ferry across Puget Sound), I see a number of other folks all wielding mice-less laptops.
Given that laptops are becoming more common purchases than desktops, I can see mice taking less of a market share in the future. Demise, though? Nah.
Ah, you won't get any disagreement from me about the ISP aspect -- they have no business inspecting the packets and should be taking a hands-off approach. They should be clearly setting the terms of the service (peak and average bandwidth) and throttle or reject usage above this limit.
I was just saying that the post office isn't necessarily a good comparison. They certainly should be opening/rejecting anything which will cause physical harm to the carriers or recipients (letter bombs and the like). I'm less pleased with the law enforcement allowances (that's a loophole which can be too easily exploited), but it's there nonetheless. (And, I have to admit, the postal inspectors are rather successful at their mission. They keep a low profile and use discretion, which is a lot more than one could say about many other law enforcement agencies.)
Last I checked, the USPS still asked if you were shipping anything dangerous, flammable, or perishable. They also employed a team of postal inspectors to handle cases of fraud, abuse, and other illegal activities taking place in the postal system.
So, yes; they do have the right to screen your mail.
Keep in mind: you're talking about a processor which doesn't even have integer multiplication, let alone any floating point operations. And you have only three 8-bit registers to perform these operations in. Executing 1k instructions for even a basic FLOP is not inconceivable here.
Radio Shack isn't the same anymore. I did spend a fair amount of time there in the 80s, getting the bits together to put together crystal radios and the like. Sadly, many of their stores don't even carry the supplies to build a crystal radio any longer; it's all consumer throw away gadgets now. (Yes, I'm getting old, and you kids better get off my lawn... :-)
You can order some of those kits from their catalog, but you might as well go with AS&S or another webstore. They're usually cheaper and have a bigger selection.