That depends on what you answer when asked what type of a network you're on. Public puts the firewall in to lockdown mode, Home and Work are pretty much identical and allow normal local network traffic.
If they're directly internet connected and answered correctly they should be blocking most traffic, but directly connecting a machine to the internet these days is rare due to the general demand for wireless and multiple devices.
Blocking ping outright is pretty dumb overall, IMO. It removes a useful diagnostic tool while only blocking threats from 1996 that have been fixed on anything you should ever consider connecting to the internet. If a machine is still vulnerable to ping-of-death type things, it is trash and should be discarded immediately (as well as finding those responsible for it and beating them severely for leaving that crap around).
Sorry, but the appropriate speed for the road depends on how the road is built, not whether a kindergartner happens to live alongside it.
People automatically tend to drive at a reasonable speed for the road, not the limit. With this in mind, the MUTCD (Manual on Uniform Traffic Control Design, or the big book put out by the Federal Highway Administration that defines the majority the things we see as part of the road system) states that speed limits should be set to an 85th percentile average of how fast people drive anyways. Not all states use the federal MUTCD officially outside of interstate highways, but in general those states' own variant quotes the feds on the main bits. Basically what this means is that by the guidelines that should be used in most areas if the majority of people are speeding on your road it doesn't mean they're in the wrong, it means the speed limit is wrong and needs to be raised.
Just because someone is going fast doesn't mean they're putting others' lives at risk either, get off your high horse.
If you really want people to slow down, look in to traffic calming measures and try to get your responsible government entities interested. The idea is that you rework the road to make it seem less suitable for speed. Narrowing lanes, median islands, tricks with the lines, etc. They cost money, but they're the only way to do it right since they'll actually result in a slowdown 24/7 rather than only when cops are around.
And that's really why the story question is misguided. The underlying architecture has nothing to do with the ISA; Intel can build whatever they want and throw an x86 decoder frontend on it and have a suitable x86 CPU. Killing the x86 ISA doesn't do anything for Intel or their customers.
The problem with that approach as the sole approach (as they've done here) is that you can only do so much to the underlying architecture without having to basically be undoing the work that a compiler is doing to get the binary in the first place. When you can build for the actual architecture rather than a frontend ISA you can optimize much better for the actual CPU rather than for the theoretical x86 CPU its pretending to be.
Isn't this sort of what Transmeta did years ago anyways? VLIW backend with a "code morphing" frontend that makes it expose an x86 ISA (and theoretically any others, I recall a demo that involved Java bytecode). If you need to run multiple instruction sets on the same machine it's great, but coding right to the CPU will always be more efficient.
It is in the bottom of the 2.4Ghz band. (802.11b and up). Hams can use 100 Watts or more, where consumers are limited to Part 15 levels (about half a watt).
We can actually use up to 1500 watts. Technician licensees like myself are limited to 200 watts on the small chunks we're allowed to touch below 50 MHz and even the Extras are limited to 100 watts on the 60 meter band, but everything else including all of our overlap with ISM bands is full power.
Of course we're only supposed to use the minimum necessary power to establish communications, so outside of contests you really shouldn't be running at that sort of power level. I'd also be concerned for my safety being near a 1500w transmitter in that band, considering that's basically a description of a modern microwave oven.
Part 15.5 basically says that unlicensed radio operation is a best-effort thing. If the spectrum you want to use is already taken up to a point that it makes it unusable for you, too bad, you have no right to complain. Where allowed, unlicensed operation is the lowest possible priority. A licensed user can shut you down if you interfere with them, but if someone moves in next door to you with an old cordless phone or crappy microwave which knocks out your WiFi when in use you just have to deal with it.
In general the FCC's priority goes like this:
1. Military 2. Licensed Government 3. Licensed Commercial 4. Licensed Amateur 0. Unlicensed
The military pretty much gets what they want, then below that if there's a conflict between licensed parties where both have privileges on a band it tends to go in the order listed. Unlicensed users are then left to fight amongst themselves over the scraps.
(E.g. [f]irewalls etc. are protecting you, so how should a security flaw _inside_ be a _serious_ problem?)
Ah yes, the hard candy shell/soft creamy filling school of thought on security. Do you allow BYOD in any way? Are company laptops used on public or home networks? Are you *sure* there aren't any vulnerabilities in services you may expose to the world? How secure is your company WiFi? Are there any exposed network ports in public areas which may have a new device sitting near them? What happens when the next $plugin 0-day hits the web?
There are more than enough ways for malware or an attacker to get behind the one firewall most networks have. Delaying internal updates because "the firewalls will protect me" is moronic if there are security implications. Of course if it's a bugfix for something you consider unimportant that's another matter, but vulnerabilities in anything network-accessible should be considered critical unless it can be made completely inaccessible to untrusted machines.
Entirely correct, but nowhere did your parent post mention using RAID as a data backup. The word backup was used in the context of backup hardware, as in a cold spare.
Define 386 support, cause the kernel wont work on a 386 chip, hell its hard to find one that supports a pentium, think 2.4 or somewhere around there was the death of that
You didn't say you liked BB/RIM, but you were responding to someone dissing their product as if it didn't deserve to be considered lesser.
I provided a huge reason why they are objectively inferior, the mandatory use of RIM's network for mobile data access. This isn't a religious issue, it's them doing something positively idiotic which I believe should make anyone who values reliability in a mobile device stay far away.
This "feature" provides two things, push messaging and a sort of VPN-ish link back to a "trusted" network (in that you're forced to trust RIM's network if you use a Blackberry). The first seems to be handled quite well by all the other mobile device platforms without running any other traffic through, and the second can be done on every other platform with a normal VPN service of any kind. Neither require running all traffic through at all times though. The user/administrator can choose to do that if they want, but if their VPN is unavailable they're not stuck with a useless device.
Everyone deserves a fair chance to start, but when a company has a history of doing bad things it's not wrong to dislike them and have low expectations for their future products.
I want competition, I just want it to be somebody other than RIM. Palm should have done better and HP should have handled them better. WebOS was actually interesting and the hardware was pretty nice if slightly underspecced.
I honestly would like to know how you can take seriously as a mobile device vendor a company that thinks it's a good idea to route all mobile data traffic through their servers? The outages Blackberries have had are impossible on any of the other platforms, they're just not that tightly tied to the mothership. My Android and iOS devices depend on nothing more to get to the internet then any other device on the network. I haven't used WinMo since 6 but I know it hasn't changed because Microsoft isn't that fucking stupid.
The structure of the Blackberry system made sense when they first came out as PIMs on slow mobile data networks, but in the world of 3G and WiFi it's an obsolete point of failure which has failed many times. Sure, keep it around for devices that are too old to update for the times, but the fact that devices trying to compete as real full-featured smartphones still use it is absolute insanity.
With that history, they'd have to wow me to a mindboggling level to recover. So far I have yet to see anything even remotely special. Had the Playbook's software not been so gimped initially it may have been a real option in the tablet world, but they managed to bungle that too.
Other than the all-touch models, Blackberries remain excellent mobile e-mail and PIM devices (again other than the idiotic network mandate) but they are terrible smartphones. The touch models are just disappointing all over.
Yes, but that is not what the blurb is stating - they are arguring about patient safty. A Flu vaccine helps you build up an immunity to the virus - in other words, if you are exposed to it, you are less likely to get sick, and if you do, the symptoms are not as bad. Getting a flu vaccine does NOT mean that you will not carry the virus. As such, firing on the grounds that they fired these workers on is not based on science, and as such, there is no grounds for termination. Whether the workers refused the vaccine based on religious grounds or not is moot.
I don't have anything peer reviewed to reference, but this is one of those situations where I feel the "common sense" argument is rather powerful. If you are effectively vaccinated it is less likely that the virus can take hold in your system. This means that if you come in contact with it you can still spread it by then contacting other things, at least until you clean up, but your body will not be producing virus cells on its own.
Effective vaccination reduces the number of sources of the disease in the environment, so logically unless the environment was beyond saturation with sources this will reduce the chance of it spreading.
Less people sick with contagious diseases = less disease spread, all else being equal. Is that really a hard or controversial concept?
Adding another vote for UniFi. I took a shot on them because they were cheap, basically a last chance for Ubiquiti as I had been burned by a lack of support on the RouterStation Pro a few years back. So far it's turned out to be a good choice. I have two customers running six APs each who are very happy with them, another rolling out nine (they're offered in a discounted three-pack, so multiples of three are a matter of convenience).
The "controller" package is only really used for configuration, firmware updates, and running the captive portal as opposed to a traditional wireless controller, but this means it's light on resources even though it's Java-based. It is a properly done Java app at least, and not only runs on all major OSes but even runs well on non-x86 CPUs. Pretty much any server with a bit of spare CPU power can run it, or if there isn't a server around people have run the controller on Raspberry Pi units.
Drag racing hardly qualifies as holding its own. Real race cars have to turn sometimes.
Car and Driver (a magazine known for being fans of the 3 series) ran the M3 Competition Package against a Mustang GT with the Brembo brake package on Streets of Willow Springs in 2011. The amateur driver was 0.55 seconds faster in the Mustang, the pro was 0.09 seconds faster in the BMW. Either way, the oxcart-axled Mustang holds its own against the German benchmark around real tracks with real corners.
I daily drive an E46 3 series, I know what handling means. Realize that the Mustang is no longer a joke.
Bad choice of target for your "hurr american cars use old tech" attack. Even the article you link notes that people mistakenly associate the Corvette suspension system with the setup used on trucks just because it has a leaf, even though the operation is completely different.
A better choice would have been the Mustang for its continued use of a solid axle, though even that holds its own against the M3 so it's hard to call it all bad.
I'm not aware of broadcasts in 50 FPS. AFAIK, they're being evaluated, but basically material is broadcast at 25 or 30 fps, depending on the standard used. These conform to the old PAL/NTSC/SECAM framerates. Interlaced formats, however, can be 50 or 60, but that's because each frame is essentially split into two frames of alternating horizontal lines, "fields".
720p60 is a common broadcast format and a few European broadcasters do 720p50 (presumably to ease upscaling 25 FPS SD content). It seems 1080i50 is more popular over there though (annoyingly, I despise interlacing and would much rather have seen 1080p30 and 1080p25 become the broadcast standards rather than their crappy interlaced counterparts).
You're absolutely correct that if an attacker is performing actions as root you have a big problem, but if that attacker is able to succeed and inject modules in to the kernel you have much bigger problems. Root's actions can still be monitored, logged, etc. where a malicious kernel module can hide any evidence of its existence from the running system.
Having this feature enabled (and of course keeping the private key elsewhere if you build your own modules) means that a root exploit turning in to a rootkitted box requires a kernel bug rather than just insmod.
A read-only OS is called a Live CD (or more generally Live distro, since they're rarely used from CDs anymore). The downside of course is that updates are more challenging.
If you can netboot, you can get the advantages of a read-only system while not being a pain to update by simply making sure the network machines can't write to whatever they're booting from. Admins can still write changes in, then updates become as easy as making the change once and telling people to reboot. Unfortunately this has the obvious downside of being significantly slower than a local system install, especially when SSDs are involved.
I haven't played around with EFI yet, but I'd imagine it may be possible to design an EFI application which could check a remote server for updates to the system image on boot and download updates automatically. At that point it would be simply a matter of making sure the system volume(s) were mounted read-only, maybe with a unioned tmpfs on top so programs that want to write places they shouldn't can run. Not hard for *nixes, no idea on Windows.
I'd imagine any sort of checksumming on boot would slow things enough that the netboot solution would make more sense.
This is a completely valid point, optical drives are cheap as dirt. Throw brute force at the problem if it's that big of a deal, then when done you have a bunch of spares for when/if they die or other PC builds.
But that's also an easier problem to solve than what most DRM tries to do. A simple one-time activation that just saves a "yup, I'm activated" bit in a file or in the registry would solve this, then just make the program act as a demo if it doesn't detect that sort of like an Xbox Live Arcade title. Maybe for disc-based titles do a simple disc check if this activation bit is not set, allowing full offline installation and play if someone so desires. Add a quick way to purchase directly from the demo and you're set. Casual passarounds become distribution of the demo which can then instantly convert in to the full title.
Where things go off the rails is when someone decides that the simple activation needs to defend itself from the user. This almost inevitably results in things happening which are hostile to legitimate users. If someone goes through the trouble of faking your activation bit or mounting a virtual CD image they were going to pirate it anyways. Attempting to detect and defeat these techniques is prone to false positives (I keep ISOs of all my disc-based software on my server and install from them using virtual disc drives for speed and to limit risk to the disc, but this causes some older games to absolutely require cracking as they won't even run at the same time as a virtual disc drive if left unmodified) and never ends up achieving the desired goal in the end.
Just like WEP will stop a casual WiFi-borrower but won't make a hacker flinch, it's trivial to implement a "DRM" system which stops casual Grandma-level copying in its tracks while causing legitimate users none of the problems seen with the hardcore DRM systems some like to use.
Sometimes legacy software has no still-maintained close substitute, and some sort of virtual machine is the answer. True, the OP probably isn't asking about games, but I'll still give an example of a 16-bit app that hasn't been upgraded: Is New Super Mario Bros. Wii for Wii an adequate substitute for an old 16-bit app like Super Mario World for Super NES?
A video game isn't exactly a great analogy, since there's no practical reason for there to be a new Super Mario title which is exactly comparable to the SNES version.
Anything actually important, business software and such, has something comparable as long as the industry it exists for is still around because there's still a market. It may not be the same package you've been using, but if it's so old that we're having this conversation you're well past the point of being able to care. At that point, it's a liability that grows every day to have a business depend on unsupported and unsupportable software. Switching may cost money, but if something goes wrong with the unsupportable system you're going to lose a lot more.
Hit the menu button (or the "..." in the top right corner) and it's in the popup. At least that's where it is on a phone running ICS, I don't feel like finding my tablet to see if it's in the same place there.
Pandora's "stations" are self-defined. You tell it a band or track you like, it creates a station based on that. You then thumb up or thumb down songs it plays and it adapts the station to your preferences.
I think they have a number of predefined base stations these days, but they didn't when I started using it and I haven't really explored them other than one comedy station.
The subscription just gets you higher quality audio, no ads, and a Flash/Flex-based desktop player.
Slashdot Mirror
That depends on what you answer when asked what type of a network you're on. Public puts the firewall in to lockdown mode, Home and Work are pretty much identical and allow normal local network traffic.
If they're directly internet connected and answered correctly they should be blocking most traffic, but directly connecting a machine to the internet these days is rare due to the general demand for wireless and multiple devices.
Blocking ping outright is pretty dumb overall, IMO. It removes a useful diagnostic tool while only blocking threats from 1996 that have been fixed on anything you should ever consider connecting to the internet. If a machine is still vulnerable to ping-of-death type things, it is trash and should be discarded immediately (as well as finding those responsible for it and beating them severely for leaving that crap around).
Sorry, but the appropriate speed for the road depends on how the road is built, not whether a kindergartner happens to live alongside it.
People automatically tend to drive at a reasonable speed for the road, not the limit. With this in mind, the MUTCD (Manual on Uniform Traffic Control Design, or the big book put out by the Federal Highway Administration that defines the majority the things we see as part of the road system) states that speed limits should be set to an 85th percentile average of how fast people drive anyways. Not all states use the federal MUTCD officially outside of interstate highways, but in general those states' own variant quotes the feds on the main bits. Basically what this means is that by the guidelines that should be used in most areas if the majority of people are speeding on your road it doesn't mean they're in the wrong, it means the speed limit is wrong and needs to be raised.
Just because someone is going fast doesn't mean they're putting others' lives at risk either, get off your high horse.
If you really want people to slow down, look in to traffic calming measures and try to get your responsible government entities interested. The idea is that you rework the road to make it seem less suitable for speed. Narrowing lanes, median islands, tricks with the lines, etc. They cost money, but they're the only way to do it right since they'll actually result in a slowdown 24/7 rather than only when cops are around.
And that's really why the story question is misguided. The underlying architecture has nothing to do with the ISA; Intel can build whatever they want and throw an x86 decoder frontend on it and have a suitable x86 CPU. Killing the x86 ISA doesn't do anything for Intel or their customers.
The problem with that approach as the sole approach (as they've done here) is that you can only do so much to the underlying architecture without having to basically be undoing the work that a compiler is doing to get the binary in the first place. When you can build for the actual architecture rather than a frontend ISA you can optimize much better for the actual CPU rather than for the theoretical x86 CPU its pretending to be.
Isn't this sort of what Transmeta did years ago anyways? VLIW backend with a "code morphing" frontend that makes it expose an x86 ISA (and theoretically any others, I recall a demo that involved Java bytecode). If you need to run multiple instruction sets on the same machine it's great, but coding right to the CPU will always be more efficient.
As the hovertext on the comic says, if you're gaming on WiFi you only have yourself to blame.
It is in the bottom of the 2.4Ghz band. (802.11b and up). Hams can use 100 Watts or more, where consumers are limited to Part 15 levels (about half a watt).
We can actually use up to 1500 watts. Technician licensees like myself are limited to 200 watts on the small chunks we're allowed to touch below 50 MHz and even the Extras are limited to 100 watts on the 60 meter band, but everything else including all of our overlap with ISM bands is full power.
Of course we're only supposed to use the minimum necessary power to establish communications, so outside of contests you really shouldn't be running at that sort of power level. I'd also be concerned for my safety being near a 1500w transmitter in that band, considering that's basically a description of a modern microwave oven.
Ham operator and armchair lawyer here.
Part 15.5 basically says that unlicensed radio operation is a best-effort thing. If the spectrum you want to use is already taken up to a point that it makes it unusable for you, too bad, you have no right to complain. Where allowed, unlicensed operation is the lowest possible priority. A licensed user can shut you down if you interfere with them, but if someone moves in next door to you with an old cordless phone or crappy microwave which knocks out your WiFi when in use you just have to deal with it.
In general the FCC's priority goes like this:
1. Military
2. Licensed Government
3. Licensed Commercial
4. Licensed Amateur
0. Unlicensed
The military pretty much gets what they want, then below that if there's a conflict between licensed parties where both have privileges on a band it tends to go in the order listed. Unlicensed users are then left to fight amongst themselves over the scraps.
(E.g. [f]irewalls etc. are protecting you, so how should a security flaw _inside_ be a _serious_ problem?)
Ah yes, the hard candy shell/soft creamy filling school of thought on security. Do you allow BYOD in any way? Are company laptops used on public or home networks? Are you *sure* there aren't any vulnerabilities in services you may expose to the world? How secure is your company WiFi? Are there any exposed network ports in public areas which may have a new device sitting near them? What happens when the next $plugin 0-day hits the web?
There are more than enough ways for malware or an attacker to get behind the one firewall most networks have. Delaying internal updates because "the firewalls will protect me" is moronic if there are security implications. Of course if it's a bugfix for something you consider unimportant that's another matter, but vulnerabilities in anything network-accessible should be considered critical unless it can be made completely inaccessible to untrusted machines.
Entirely correct, but nowhere did your parent post mention using RAID as a data backup. The word backup was used in the context of backup hardware, as in a cold spare.
Define 386 support, cause the kernel wont work on a 386 chip, hell its hard to find one that supports a pentium, think 2.4 or somewhere around there was the death of that
No, this was very recent. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=743aa456c1834f76982af44e8b71d1a0b2a82e21
Sure, most distros compile for 486 or Pentium and above these days, but the kernel itself could still be built for 386 until just over a month ago.
You didn't say you liked BB/RIM, but you were responding to someone dissing their product as if it didn't deserve to be considered lesser.
I provided a huge reason why they are objectively inferior, the mandatory use of RIM's network for mobile data access. This isn't a religious issue, it's them doing something positively idiotic which I believe should make anyone who values reliability in a mobile device stay far away.
This "feature" provides two things, push messaging and a sort of VPN-ish link back to a "trusted" network (in that you're forced to trust RIM's network if you use a Blackberry). The first seems to be handled quite well by all the other mobile device platforms without running any other traffic through, and the second can be done on every other platform with a normal VPN service of any kind. Neither require running all traffic through at all times though. The user/administrator can choose to do that if they want, but if their VPN is unavailable they're not stuck with a useless device.
Everyone deserves a fair chance to start, but when a company has a history of doing bad things it's not wrong to dislike them and have low expectations for their future products.
I want competition, I just want it to be somebody other than RIM. Palm should have done better and HP should have handled them better. WebOS was actually interesting and the hardware was pretty nice if slightly underspecced.
I honestly would like to know how you can take seriously as a mobile device vendor a company that thinks it's a good idea to route all mobile data traffic through their servers? The outages Blackberries have had are impossible on any of the other platforms, they're just not that tightly tied to the mothership. My Android and iOS devices depend on nothing more to get to the internet then any other device on the network. I haven't used WinMo since 6 but I know it hasn't changed because Microsoft isn't that fucking stupid.
The structure of the Blackberry system made sense when they first came out as PIMs on slow mobile data networks, but in the world of 3G and WiFi it's an obsolete point of failure which has failed many times. Sure, keep it around for devices that are too old to update for the times, but the fact that devices trying to compete as real full-featured smartphones still use it is absolute insanity.
With that history, they'd have to wow me to a mindboggling level to recover. So far I have yet to see anything even remotely special. Had the Playbook's software not been so gimped initially it may have been a real option in the tablet world, but they managed to bungle that too.
Other than the all-touch models, Blackberries remain excellent mobile e-mail and PIM devices (again other than the idiotic network mandate) but they are terrible smartphones. The touch models are just disappointing all over.
Yes, but that is not what the blurb is stating - they are arguring about patient safty. A Flu vaccine helps you build up an immunity to the virus - in other words, if you are exposed to it, you are less likely to get sick, and if you do, the symptoms are not as bad. Getting a flu vaccine does NOT mean that you will not carry the virus. As such, firing on the grounds that they fired these workers on is not based on science, and as such, there is no grounds for termination. Whether the workers refused the vaccine based on religious grounds or not is moot.
I don't have anything peer reviewed to reference, but this is one of those situations where I feel the "common sense" argument is rather powerful. If you are effectively vaccinated it is less likely that the virus can take hold in your system. This means that if you come in contact with it you can still spread it by then contacting other things, at least until you clean up, but your body will not be producing virus cells on its own.
Effective vaccination reduces the number of sources of the disease in the environment, so logically unless the environment was beyond saturation with sources this will reduce the chance of it spreading.
Less people sick with contagious diseases = less disease spread, all else being equal. Is that really a hard or controversial concept?
Coming back this year? They've been on the lots here for months.
Adding another vote for UniFi. I took a shot on them because they were cheap, basically a last chance for Ubiquiti as I had been burned by a lack of support on the RouterStation Pro a few years back. So far it's turned out to be a good choice. I have two customers running six APs each who are very happy with them, another rolling out nine (they're offered in a discounted three-pack, so multiples of three are a matter of convenience).
The "controller" package is only really used for configuration, firmware updates, and running the captive portal as opposed to a traditional wireless controller, but this means it's light on resources even though it's Java-based. It is a properly done Java app at least, and not only runs on all major OSes but even runs well on non-x86 CPUs. Pretty much any server with a bit of spare CPU power can run it, or if there isn't a server around people have run the controller on Raspberry Pi units.
Drag racing hardly qualifies as holding its own. Real race cars have to turn sometimes.
Car and Driver (a magazine known for being fans of the 3 series) ran the M3 Competition Package against a Mustang GT with the Brembo brake package on Streets of Willow Springs in 2011. The amateur driver was 0.55 seconds faster in the Mustang, the pro was 0.09 seconds faster in the BMW. Either way, the oxcart-axled Mustang holds its own against the German benchmark around real tracks with real corners.
I daily drive an E46 3 series, I know what handling means. Realize that the Mustang is no longer a joke.
Bad choice of target for your "hurr american cars use old tech" attack. Even the article you link notes that people mistakenly associate the Corvette suspension system with the setup used on trucks just because it has a leaf, even though the operation is completely different.
A better choice would have been the Mustang for its continued use of a solid axle, though even that holds its own against the M3 so it's hard to call it all bad.
I'm not aware of broadcasts in 50 FPS. AFAIK, they're being evaluated, but basically material is broadcast at 25 or 30 fps, depending on the standard used. These conform to the old PAL/NTSC/SECAM framerates. Interlaced formats, however, can be 50 or 60, but that's because each frame is essentially split into two frames of alternating horizontal lines, "fields".
720p60 is a common broadcast format and a few European broadcasters do 720p50 (presumably to ease upscaling 25 FPS SD content). It seems 1080i50 is more popular over there though (annoyingly, I despise interlacing and would much rather have seen 1080p30 and 1080p25 become the broadcast standards rather than their crappy interlaced counterparts).
You're absolutely correct that if an attacker is performing actions as root you have a big problem, but if that attacker is able to succeed and inject modules in to the kernel you have much bigger problems. Root's actions can still be monitored, logged, etc. where a malicious kernel module can hide any evidence of its existence from the running system.
Having this feature enabled (and of course keeping the private key elsewhere if you build your own modules) means that a root exploit turning in to a rootkitted box requires a kernel bug rather than just insmod.
A read-only OS is called a Live CD (or more generally Live distro, since they're rarely used from CDs anymore). The downside of course is that updates are more challenging.
If you can netboot, you can get the advantages of a read-only system while not being a pain to update by simply making sure the network machines can't write to whatever they're booting from. Admins can still write changes in, then updates become as easy as making the change once and telling people to reboot. Unfortunately this has the obvious downside of being significantly slower than a local system install, especially when SSDs are involved.
I haven't played around with EFI yet, but I'd imagine it may be possible to design an EFI application which could check a remote server for updates to the system image on boot and download updates automatically. At that point it would be simply a matter of making sure the system volume(s) were mounted read-only, maybe with a unioned tmpfs on top so programs that want to write places they shouldn't can run. Not hard for *nixes, no idea on Windows.
I'd imagine any sort of checksumming on boot would slow things enough that the netboot solution would make more sense.
This is a completely valid point, optical drives are cheap as dirt. Throw brute force at the problem if it's that big of a deal, then when done you have a bunch of spares for when/if they die or other PC builds.
But that's also an easier problem to solve than what most DRM tries to do. A simple one-time activation that just saves a "yup, I'm activated" bit in a file or in the registry would solve this, then just make the program act as a demo if it doesn't detect that sort of like an Xbox Live Arcade title. Maybe for disc-based titles do a simple disc check if this activation bit is not set, allowing full offline installation and play if someone so desires. Add a quick way to purchase directly from the demo and you're set. Casual passarounds become distribution of the demo which can then instantly convert in to the full title.
Where things go off the rails is when someone decides that the simple activation needs to defend itself from the user. This almost inevitably results in things happening which are hostile to legitimate users. If someone goes through the trouble of faking your activation bit or mounting a virtual CD image they were going to pirate it anyways. Attempting to detect and defeat these techniques is prone to false positives (I keep ISOs of all my disc-based software on my server and install from them using virtual disc drives for speed and to limit risk to the disc, but this causes some older games to absolutely require cracking as they won't even run at the same time as a virtual disc drive if left unmodified) and never ends up achieving the desired goal in the end.
Just like WEP will stop a casual WiFi-borrower but won't make a hacker flinch, it's trivial to implement a "DRM" system which stops casual Grandma-level copying in its tracks while causing legitimate users none of the problems seen with the hardcore DRM systems some like to use.
Sometimes legacy software has no still-maintained close substitute, and some sort of virtual machine is the answer. True, the OP probably isn't asking about games, but I'll still give an example of a 16-bit app that hasn't been upgraded: Is New Super Mario Bros. Wii for Wii an adequate substitute for an old 16-bit app like Super Mario World for Super NES?
A video game isn't exactly a great analogy, since there's no practical reason for there to be a new Super Mario title which is exactly comparable to the SNES version.
Anything actually important, business software and such, has something comparable as long as the industry it exists for is still around because there's still a market. It may not be the same package you've been using, but if it's so old that we're having this conversation you're well past the point of being able to care. At that point, it's a liability that grows every day to have a business depend on unsupported and unsupportable software. Switching may cost money, but if something goes wrong with the unsupportable system you're going to lose a lot more.
Hit the menu button (or the "..." in the top right corner) and it's in the popup. At least that's where it is on a phone running ICS, I don't feel like finding my tablet to see if it's in the same place there.
Pandora's "stations" are self-defined. You tell it a band or track you like, it creates a station based on that. You then thumb up or thumb down songs it plays and it adapts the station to your preferences.
I think they have a number of predefined base stations these days, but they didn't when I started using it and I haven't really explored them other than one comedy station.
The subscription just gets you higher quality audio, no ads, and a Flash/Flex-based desktop player.
On a world scale, yes, yes he is. The US view of "center" is just fucked off to the right by a lot.