I like this plan. Enforceable penalties for violating copyright law OR anti-consumer methods/devices designed to prevent copying. I'd even let you keep the protections for derivative works and commercial reproduction, so long as you gave up the rights protecting non-commerical reproduction and distribution. That would prevent commercial pirates from devaluing published material, while still letting individuals do as they will.
But all such systems require a trusted third-party or pre-shared secrets to establish trusted authentication in the first place. Encryption not seamless and zero-configuration on your phone, it's just pre-configured before you get it.
You're inventing a problem. It's pretty trivial to count the number of colons before the first slash and then decide how to parse the hostname/protocol/port bit.
Is there some reason I couldn't code with my kids, code for my hobbies, or code to volunteer at a charity? I certainly agree that you shouldn't work 24/7, but I have hobbies that involve some programming, and I find them more fulfilling because of it. And I've often volunteered my technical skills to worthy causes; my technical skills are much more valuable than my construction skills, and I like doing it more, so why would I volunteer to do something where I'm less productive and less happy?
Would you tell a physician they shouldn't volunteer their medical training outside of work hours because that will keep them from being well-rounded and happy?
Adding checksumming adds another place for errors to occur though -- if data is written correctly but the checksum is-miscalculated, either before it is stored or when the data is being verified -- you'll end up throwing out perfectly good data. If you also have redundancy you're probably willing to live with that, but if you're running on single disk ZFS is just adding more opportunities for data corruption in RAM.
Authentication is great. But given that the alternative -- no encryption and no authentication -- allows passive sniffing, MitM, and a whole slew of other attacks, but does *not* include a warning makes it seem awfully silly to warn extensively about a connection that is *only* vulnerable to MitM attacks.
I agree that authenticated connections should be treated differently than unauthenticated connections. But I don't see why an increase in security to unauthenticated encryption is treated worse than totally unencrypted, unauthenticated connections.
You *should* create keys that require a passphrase. In fact, that's the default -- you're prompted to enter one when creating a key on every system I've ever used.
Not only that, but even if you compromise a system that has unencrypted keys, you still have to know where those keys work. In the past known_hosts could help with that, but now that is hashed, so you'd have to both break into a workstation with unencrypted keys AND know where those keys work to do anything useful -- that's probably still a net gain over passwords.
Any sort of stored password, encrypted or otherwise, is subject to attack. If your computer can recover the plaintext without you providing some sort of key, then an attacker could do it too. There's maybe some slight complication to obfuscating on-disk passwords, but unless they keystore is encrypted against an actual secret -- something you type -- then it's only marginally better than storing plain-text passwords.
That being said, there are a number of solutions for securely storing passwords in a wallet/keychain/etc. that are *not* readable by an attacker without your secret, and which require some amount of authentication to use even when unlocked, at the cost of having to type your password once per session, and subversion could easily use one of these.
First, the server signature would change, unless the attacker already has root access and can copy the private key, in which case the port number is irrelevant. Any decent SSH client whines quite a bit about such changes.
Second, there are several auth methods you could use that do not expose any private data, including pubkey and kerberos. One of the purposes of such auth methods is to prevent re-used even if an attacker gets your session credentials.
Personally I want super-dermal armor -- I'm sure sub-dermal armor would protect me from bullets, but it doesn't sound like it would do much to protect me from cuts and bruises, which is something I encounter much more often.
It might be bad. Or it might be better. Maybe your arteries are only flexible because your stupid heart can't provide a steady pressure, and you needed to have flexible blood vessels to help even out the dramatic change in pressures that could damage more sensitive tissues. Maybe plaque buildup is a result of the flexing, and would decreased if the arteries walls didn't contract and trap small bits of plaque. Maybe it is bad for artery health, but your brain and mussels function 47% better so you're willing to put up with it.
Since no one has lived very long on a continuous-flow heart I think any supposed side-effects (detrimental or otherwise) would just be wild speculation. In any case, given the much longer equipment lifetimes it seems like this technology is at least worth investigating; we're hoping to install it in people who would otherwise be dead, and there's a whole slew of detrimental side-effects that otherwise-dead people are willing to live with for the sake of not being dead.
For all the annoyances for Windows Mobile, being locked to a specific application vendor is not one of them. Being locked into ActiveSync and the like might be a problem if you don't run Windows on your desktop, but even at that you can install programs by downloading them from any web site in the built-in browser and launching the CAB file.
What makes you think that WW2 stopped the normal killing -- I'd suggest that we killed 1.5 million/year for all 100 years, and just killed and extra 8.5 million/year during WW2.
The iTunes store is already available for use with an MP4-capable device. It is fundamentally incompatible with MP3-only devices, as they do not sell MP3 data files. When DRM was required (primarily by suppliers) you might have had a point with the iTMS, but that is no longer the case, and there's nothing stopping you from buying MP4s from the iTMS and loading them on whatever MP4 player you like.
While I agree it would be nice if iTunes was more tolerant of non-Apple devices -- particularly if those devices make an effort to work like an iPod -- I don't understand why it's so hard for another device manufacturer to provide their own syncing, or why Apple should be forced to do it for them. Even if you want to use iTunes as a front-end so your users don't have to switch, Apples provides APIs suitable to allow third-party programs to use the iTunes library for synchronization. It's trivial to get play list and file paths out of iTunes; why would you bother trying to simulate an iPod rather than just writing a stub that sits between iTunes and your device?
Obviously Apple is all about exploiting their dominant market position and controlling the ways in which people use their products. But I don't see why that means they should have to support third-party hardware -- are we going to require that GM support Ford engines in all their cars?
It's been mentioned a couple of times, but mostly with -1 scores, so it's easy to miss: Radmind. It's a very powerful deployment tool with a totally transparent mechanism so you can tweak it to do *exactly* what you want in terms of mucking with files on the disk. I've seen people complain about it being hard to use, but I thought it was pretty straightforward -- install an app, run the change detector, tweak as desired (if at all), build an app image, deploy.
Because there are a limited number of dollars to be spent on improving the entire set of energy-consuming devices/processes; you should generally fund the project with the most impact first (assuming it is affordable), and consider others only if additional funds are available.
It would be great to do both, if it's viable, But if you always just do the first one that comes along you're likely to find yourself without the funds to do more meaningful projects down the road.
/ Not that I expect anyone to apply basic economics to environmental projects
You can't get fired from the state. At best you can get put into a job with no responsibilities. But you'd have to burn down the building before they'd even consider firing you.
That article says both: A) Most people probably couldn't tell the different between a high-end modern instrument and a Strad. B) That they didn't actually do any tests on any instruments, but they think (pure conjecture) that many people could tell the difference between a modern, mass-produced violin and a Strad.
You're right, the BBC collects their license fee. Under force of law, from anyone receiving broadcast TV, whether they use BBC services or not. You're being intentionally ignorant if you claim that's not a government-mandated tax.
Why wouldn't you just sink it in the middle of the ocean, rather than on the coast of some other nation? This ship was only 30 miles from the nation it was leaving; if they were willing to sail 1000 miles instead of 30 why would they bother ending that voyage just off some other nation, rather than in the middle of nowhere? It's not like you'd like to make landfall in Somolia after sinking your ship.
You won't have to drive there. If car makers really do deliver readable computers only to MA I'm sure someone in MA would be happy to act as your agent and take original delivery of the car in MA, then see that it gets to wherever you are. So long as they can do that for less than the estimated savings in repair it's a pretty easy, safe business to be in.
Is there some reason you couldn't simply document your off-road usage and file for a deducation/refund? That same system seems to work just fine for all our other taxes (income, sale, etc.).
Slashdot Mirror
Because outdoor antennas are necessarily high gain?
I like this plan. Enforceable penalties for violating copyright law OR anti-consumer methods/devices designed to prevent copying. I'd even let you keep the protections for derivative works and commercial reproduction, so long as you gave up the rights protecting non-commerical reproduction and distribution. That would prevent commercial pirates from devaluing published material, while still letting individuals do as they will.
But all such systems require a trusted third-party or pre-shared secrets to establish trusted authentication in the first place. Encryption not seamless and zero-configuration on your phone, it's just pre-configured before you get it.
You're inventing a problem. It's pretty trivial to count the number of colons before the first slash and then decide how to parse the hostname/protocol/port bit.
Is there some reason I couldn't code with my kids, code for my hobbies, or code to volunteer at a charity? I certainly agree that you shouldn't work 24/7, but I have hobbies that involve some programming, and I find them more fulfilling because of it. And I've often volunteered my technical skills to worthy causes; my technical skills are much more valuable than my construction skills, and I like doing it more, so why would I volunteer to do something where I'm less productive and less happy?
Would you tell a physician they shouldn't volunteer their medical training outside of work hours because that will keep them from being well-rounded and happy?
Adding checksumming adds another place for errors to occur though -- if data is written correctly but the checksum is-miscalculated, either before it is stored or when the data is being verified -- you'll end up throwing out perfectly good data. If you also have redundancy you're probably willing to live with that, but if you're running on single disk ZFS is just adding more opportunities for data corruption in RAM.
Authentication is great. But given that the alternative -- no encryption and no authentication -- allows passive sniffing, MitM, and a whole slew of other attacks, but does *not* include a warning makes it seem awfully silly to warn extensively about a connection that is *only* vulnerable to MitM attacks.
I agree that authenticated connections should be treated differently than unauthenticated connections. But I don't see why an increase in security to unauthenticated encryption is treated worse than totally unencrypted, unauthenticated connections.
If one hit every 3 seconds looks like a DOS attack you need to stop using Altair hardware for your web servers.
You *should* create keys that require a passphrase. In fact, that's the default -- you're prompted to enter one when creating a key on every system I've ever used.
Not only that, but even if you compromise a system that has unencrypted keys, you still have to know where those keys work. In the past known_hosts could help with that, but now that is hashed, so you'd have to both break into a workstation with unencrypted keys AND know where those keys work to do anything useful -- that's probably still a net gain over passwords.
Any sort of stored password, encrypted or otherwise, is subject to attack. If your computer can recover the plaintext without you providing some sort of key, then an attacker could do it too. There's maybe some slight complication to obfuscating on-disk passwords, but unless they keystore is encrypted against an actual secret -- something you type -- then it's only marginally better than storing plain-text passwords.
That being said, there are a number of solutions for securely storing passwords in a wallet/keychain/etc. that are *not* readable by an attacker without your secret, and which require some amount of authentication to use even when unlocked, at the cost of having to type your password once per session, and subversion could easily use one of these.
First, the server signature would change, unless the attacker already has root access and can copy the private key, in which case the port number is irrelevant. Any decent SSH client whines quite a bit about such changes.
Second, there are several auth methods you could use that do not expose any private data, including pubkey and kerberos. One of the purposes of such auth methods is to prevent re-used even if an attacker gets your session credentials.
Personally I want super-dermal armor -- I'm sure sub-dermal armor would protect me from bullets, but it doesn't sound like it would do much to protect me from cuts and bruises, which is something I encounter much more often.
It might be bad. Or it might be better. Maybe your arteries are only flexible because your stupid heart can't provide a steady pressure, and you needed to have flexible blood vessels to help even out the dramatic change in pressures that could damage more sensitive tissues. Maybe plaque buildup is a result of the flexing, and would decreased if the arteries walls didn't contract and trap small bits of plaque. Maybe it is bad for artery health, but your brain and mussels function 47% better so you're willing to put up with it.
Since no one has lived very long on a continuous-flow heart I think any supposed side-effects (detrimental or otherwise) would just be wild speculation. In any case, given the much longer equipment lifetimes it seems like this technology is at least worth investigating; we're hoping to install it in people who would otherwise be dead, and there's a whole slew of detrimental side-effects that otherwise-dead people are willing to live with for the sake of not being dead.
For all the annoyances for Windows Mobile, being locked to a specific application vendor is not one of them. Being locked into ActiveSync and the like might be a problem if you don't run Windows on your desktop, but even at that you can install programs by downloading them from any web site in the built-in browser and launching the CAB file.
What makes you think that WW2 stopped the normal killing -- I'd suggest that we killed 1.5 million/year for all 100 years, and just killed and extra 8.5 million/year during WW2.
The iTunes store is already available for use with an MP4-capable device. It is fundamentally incompatible with MP3-only devices, as they do not sell MP3 data files. When DRM was required (primarily by suppliers) you might have had a point with the iTMS, but that is no longer the case, and there's nothing stopping you from buying MP4s from the iTMS and loading them on whatever MP4 player you like.
While I agree it would be nice if iTunes was more tolerant of non-Apple devices -- particularly if those devices make an effort to work like an iPod -- I don't understand why it's so hard for another device manufacturer to provide their own syncing, or why Apple should be forced to do it for them. Even if you want to use iTunes as a front-end so your users don't have to switch, Apples provides APIs suitable to allow third-party programs to use the iTunes library for synchronization. It's trivial to get play list and file paths out of iTunes; why would you bother trying to simulate an iPod rather than just writing a stub that sits between iTunes and your device?
Obviously Apple is all about exploiting their dominant market position and controlling the ways in which people use their products. But I don't see why that means they should have to support third-party hardware -- are we going to require that GM support Ford engines in all their cars?
It's been mentioned a couple of times, but mostly with -1 scores, so it's easy to miss: Radmind. It's a very powerful deployment tool with a totally transparent mechanism so you can tweak it to do *exactly* what you want in terms of mucking with files on the disk. I've seen people complain about it being hard to use, but I thought it was pretty straightforward -- install an app, run the change detector, tweak as desired (if at all), build an app image, deploy.
http://rsug.itd.umich.edu/software/radmind/
Because there are a limited number of dollars to be spent on improving the entire set of energy-consuming devices/processes; you should generally fund the project with the most impact first (assuming it is affordable), and consider others only if additional funds are available.
It would be great to do both, if it's viable, But if you always just do the first one that comes along you're likely to find yourself without the funds to do more meaningful projects down the road.
/ Not that I expect anyone to apply basic economics to environmental projects
When was the last time we elected an intellectual? 1912?
You can't get fired from the state. At best you can get put into a job with no responsibilities. But you'd have to burn down the building before they'd even consider firing you.
That article says both:
A) Most people probably couldn't tell the different between a high-end modern instrument and a Strad.
B) That they didn't actually do any tests on any instruments, but they think (pure conjecture) that many people could tell the difference between a modern, mass-produced violin and a Strad.
You're right, the BBC collects their license fee. Under force of law, from anyone receiving broadcast TV, whether they use BBC services or not. You're being intentionally ignorant if you claim that's not a government-mandated tax.
Why wouldn't you just sink it in the middle of the ocean, rather than on the coast of some other nation? This ship was only 30 miles from the nation it was leaving; if they were willing to sail 1000 miles instead of 30 why would they bother ending that voyage just off some other nation, rather than in the middle of nowhere? It's not like you'd like to make landfall in Somolia after sinking your ship.
You won't have to drive there. If car makers really do deliver readable computers only to MA I'm sure someone in MA would be happy to act as your agent and take original delivery of the car in MA, then see that it gets to wherever you are. So long as they can do that for less than the estimated savings in repair it's a pretty easy, safe business to be in.
Is there some reason you couldn't simply document your off-road usage and file for a deducation/refund? That same system seems to work just fine for all our other taxes (income, sale, etc.).