These guys can do some pretty amazing things with their equipment, check out the "Produktbeispiel" (product examples). They cut and fold metals with lasers, drills and water jets. No idea what they charge, but you give them an Autocad file and they turn it into something real (if it's creatable). Last time I visited they were doing cases for large-scale image scanners (a-la 10ft by 5 ft).
"this key wil be changed and given out to manufacturers anyway, it's not like it's going to be highly protected."
Makes you wonder why they bother in the first place. Sounds like a lot of effort, infrastructure and middlemen to construct something that's obviously going to be bypassed very shortly. Ah, the middle men, that's where it came from....
I'd guess that popular services like gmail and hotmail see a contant stream of traffic trying to guess usernames and passwords. Certainly, even my ssh server at *home* sees this kind of traffic. With a large enough army of drones I'm sure you'd get the occasional hit. Strong passwords that are well hidden/encrypted/protected are our current best hope.
A good way of doing public key authentication would go a long way to solving most of these problems (stolen backups of servers included, as the private key wouldn't exist anywhere but with the user).
It does more than reduce the ability to run dictionary attacks. It effectively limits *any* kind of attack. Heck, if the shadow system is properly in place, the password need not even be stored in ciphertext.
Shadows password files are a defense against the rate-of-attack, not the style-of-attack. They effectively limit you to a brute force attack, and a rate-limited one at that. It's also a technique to future-proof your ciphertext. If it's never exposed, there's never a risk that it'll be cracked by some weakness in the algorithm.
As with any security system, you need to identify all the attack vectors, and put defences in place for them. A shadow file rate limits brute force attacks under normal circumstances. Should the password database be compromised, you want another defence in place, and that is typically to store the passwords as some kind of ciphertext that are no good on their own. However, the rate at which attacks can now be mounted on a password has increased, opening the door for dictionary attacks, and attacks on the ciphertext algorithm.
Combining the use of a hardware token is a further defence against any of these attacks, and is becoming a popular third layer of protection that'll help when everything else has been compromised.
Actually, you can have a pretty secure password that's not dictionary based and easy to remember. So long as you have enough characters, it'll be difficult to break.
Take a look at password generation tools like "apg" and "pwgen". They use tools like trigraphs, triphthongs, diphthongs to make easy-to-remember, non-dictionary passwords. Sure, using these techniques reduces the keyspace for a brute force attack, but keyspace size and easy-to-remember are pretty much mutually exclusive.
That's exactly the setup I've put in place in a couple of places. Works brilliantly. Non-technical and recalcitrant users simply get another folder that they can drag-and-drop files to. MS-Word and many other tools understand WebDAV and will issue LOCK commands, so other users know when files are being worked on and won't conflict. There are the occasional "drop new copy over the top of updated one" type-errors, but that's the trade-off for ease-of-use. Pick what's more important to you.
I've always wondered about this. Has anyone ever sued a financial organisation for failing to properly identify them when performing transactions?
In the case of fraudulent transactions on accounts, IMO, it's the fault of the financial organisations for not properly ensuring that it's the real account holder that is performing the transaction. If someone could set a precendent in law for that, then we might start to see some change (although I have a vague, sinking feeling that all of a sudden we'll all be required to do everything in person and give blood samples...).
I'm not sure I agree with the "important because they're compact, not because they're pre-prepared" argument.
Some rough numbers. If my maths is wrong, I'll take it all back:-)
TFA quotes 33,705 WHr/gallon as the energy in todays fuels. If you get 0.02 gallon/mile (50 mpg) at 50 m/h, that's a constant output of 33kW. The sun gives us around 1.3kW/m^2 at peak delivery. So you need a 100% efficient, 25m^2 solar collector to drive around at 50 m/h.
Stupid assumption there is that cars will continue to get 50mpg when they're all solar powered. But that kind of counters your other point about "Reducing energy use is a good measure to give us more time, but it's not viable long term". Reducing energy consumption *is* the only way to go, unless you want to end up living on a giant solar panel for a planet. We expend far more energy than is necessary go get things done at the moment, and that will need to change. I guess it all comes down to which is easier: reduce the rate of consumption, or increase the rate of production.
For cars, I think we can be smarter about reducing the amount of energy it takes us to get around, rather than looking for new, highly dense sources of energy.
"...it is likely that the United States, with one of the highest per capita energy demands of any country, does not have enough arable land to fuel all of the nation's vehicles.", and that's if you use all the land that's currently being used to grow food. When it comes down to it, production of oil from plants is pretty much just an inefficient (for our needs) way to gather solar power (all that energy wasted producing seeds, growing upwards, looking pretty, etc). Much more efficient to have a solar gathering mechanism that is not distracted by reproduction and evolution.
It all depends on the length of the term you look at. In the long-term (read, hundreds of years), it's likely that the only source of energy that'll keep arriving is energy radiated from the sun. So at some point, on average, we're going to have to match our consumption with that incoming rate (factored by how efficiently we can harvest that energy). The amount of energy the earth recieves from the sun is pretty big. A quick search finds info on just one country (India):
I couldn't find a calculation for the global energy from the sun value to compare with. Numbers are probably very different for highly industrialised nations. We probably don't want to absorb all the energy from the sun for our own purposes though, it does all kinds of useful things, like makes plants grow (which we eat) and keeps things warm (admittedly most energy we consume will probably be re-emmitted as heat and will keep us warm anyway, energy in = energy out and all that).
Things like oil represent long-term storage of energy gathered from the sun. We're reaping the benefits of having these pre-prepared batteries lying around at the moment, but when we've used them all up, it'll be back to only using as much as is being supplied.
My prediction is that we're going to have to back-off on our energy consumption. Short term solutions might arrive for a while (new oil reserves, nuclear power material deposits, etc), but long-term, it'll be back to depending on the Sun (and even that'll run out in a few billion years).
Best to prepare for it now I say. Stop living so far from what you need, don't expect to be able to travel where you want and when. Don't live in a manner that demands lots of energy and you won't be affected as much when there isn't as much energy to go around (live in a village, not a city, grow your own food, don't truck it in from Brazil. You *don't* need to eat bananas in Canada in the middle of winter).
If you require access to a remote resource that wants some kind of credentials presented, and you don't want to get a human involved, then you have little choice other than to store something that someone could take a copy of and use to impersonate your system.
Set file permissions properly. Make password-containing config files only readable by the processes that need to read them. chmod 0400. Keep each of your apps separated in this way so that a compromise of one doesn't affect the others. This is the best you can do. Password obfuscation can always be broken.
If your system can automatically authenticate against a remote secure resource, then someone who compromises your system can make it do it again. The only other thing you can do would be to require human intervention every time a password is required (or a collection of passwords).
Homocides due to guns (1998): 57 people in Australia 11,829 people in the US
295,734,134 US population 20,090,437 Australian population
So Australia has roughly 1 gun related homocide per 354,000 people per year. US has roughly 1 gun related homocide per 25,000 people per year.
So, you're about 15 times more likely to be shot intentionally in the US than you are in Australia (unintentional shooting statistics appear to favour Australia even more).
Of course, statistics like "15 times more likely" aren't actually that meaningful, especially when you're talking about 0.004% (US) vs 0.0002% (AUS), the odds are still pretty low that you'll get shot.
Compare this to the chance of getting killed in a car accident. Personally, I don't think it's a real thing you should worry about every day.
This may or may not be a problem. If all of a sudden, the spammers had to spend more to actually send all that crap, then you might find that it'd die down proportionally.
Of course, this doesn't mean a lot for spam coming from (insert spammy foreign country here).
And what exactly is the difference between "stream in full quality" and "downloaded to the computer"?
And how exactly is "with enough users, each one being a sort of node" different to the Internet? There's nothing stopping you establishing a direct connection to any other user anywhere else other than geography and politics. P2P apps that open sockets to various places already simulate exactly this kind of ad-hoc network.
Read-only unfortunately, but actually, that's quite useful for publishing a subversion repository to a webserver and *forcing* people to check changes into the repository to make them go live.
I agree and disagree at the same time. Anybody who produces
a product has the right to charge whatever they want for it.
If the market will pay high prices (and in this case, people do),
why should they lower it? It's obviously worth the price (otherwise
people wouldn't pay).
However, the DNS system is not really a product, per se. Verisign
just happen to be in control of the root nameservers that everyone
just happens to use. Fair enough, they have the right to charge anyone
whatever they want for adding entries to their DNS system. They lucked
into the position basically by being first (or at least, very early).
To counter their price-grabbery, there is nothing stopping everyone
moving to an alternative set of root DNS servers with a less draconian
pricing model, except for the fact that doing that would be really hard
to co-ordinate. While it's probably been a nice ride having a single, sane
set of root DNS servers for the last 20 years, there is nothing that forces
it to be that way, it's just the most efficient way right now. If the price
of playing is set too high, then something more efficient will happen, like
a fracturing of the DNS system (where more efficiency means dollars vs "effort
to get to a particular host").
Like many monopolies, someone is one day going to come up with an
alternative that takes hold and this "problem" will fizzle.
Unfortunately there are a whole bunch of scams selling "fake" bracelets, or overcharging (note that the Lance Armstrong foundation sets a price of $1 each).
Slashdot Mirror
Shameless plug for a family friend: http://www.l-m-w.de/, based in Germany.
These guys can do some pretty amazing things with their equipment, check out the "Produktbeispiel" (product examples). They cut and fold metals with lasers, drills and water jets. No idea what they charge, but you give them an Autocad file and they turn it into something real (if it's creatable). Last time I visited they were doing cases for large-scale image scanners (a-la 10ft by 5 ft).
"this key wil be changed and given out to manufacturers anyway, it's not like it's going to be highly protected."
Makes you wonder why they bother in the first place. Sounds like a lot of effort, infrastructure and middlemen to construct something that's obviously going to be bypassed very shortly. Ah, the middle men, that's where it came from....
I'd guess that popular services like gmail and hotmail see a contant stream of traffic trying to guess usernames and passwords. Certainly, even my ssh server at *home* sees this kind of traffic. With a large enough army of drones I'm sure you'd get the occasional hit. Strong passwords that are well hidden/encrypted/protected are our current best hope.
A good way of doing public key authentication would go a long way to solving most of these problems (stolen backups of servers included, as the private key wouldn't exist anywhere but with the user).
It does more than reduce the ability to run dictionary attacks. It effectively limits *any* kind of attack. Heck, if the shadow system is properly in place, the password need not even be stored in ciphertext.
Shadows password files are a defense against the rate-of-attack, not the style-of-attack. They effectively limit you to a brute force attack, and a rate-limited one at that. It's also a technique to future-proof your ciphertext. If it's never exposed, there's never a risk that it'll be cracked by some weakness in the algorithm.
As with any security system, you need to identify all the attack vectors, and put defences in place for them. A shadow file rate limits brute force attacks under normal circumstances. Should the password database be compromised, you want another defence in place, and that is typically to store the passwords as some kind of ciphertext that are no good on their own. However, the rate at which attacks can now be mounted on a password has increased, opening the door for dictionary attacks, and attacks on the ciphertext algorithm.
Combining the use of a hardware token is a further defence against any of these attacks, and is becoming a popular third layer of protection that'll help when everything else has been compromised.
Actually, you can have a pretty secure password that's not dictionary based and easy to remember. So long as you have enough characters, it'll be difficult to break.
p
Take a look at password generation tools like "apg" and "pwgen". They use tools like trigraphs, triphthongs, diphthongs to make easy-to-remember, non-dictionary passwords. Sure, using these techniques reduces the keyspace for a brute force attack, but keyspace size and easy-to-remember are pretty much mutually exclusive.
http://pwgen.org/
http://www.puroga.com/webtools/apgonline/index.ph
That's exactly the setup I've put in place in a couple of places. Works brilliantly. Non-technical and recalcitrant users simply get another folder that they can drag-and-drop files to. MS-Word and many other tools understand WebDAV and will issue LOCK commands, so other users know when files are being worked on and won't conflict. There are the occasional "drop new copy over the top of updated one" type-errors, but that's the trade-off for ease-of-use. Pick what's more important to you.
VMWare ESX runs without an underlying OS (it provides one of its own). It might be overkill for your needs though....
http://www.vmware.com/products/esx/
"Things you should never do, Part 1": http://www.joelonsoftware.com/articles/fog00000000 69.html
I've always wondered about this. Has anyone ever sued a financial organisation for failing to properly identify them when performing transactions?
In the case of fraudulent transactions on accounts, IMO, it's the fault of the financial organisations for not properly ensuring that it's the real account holder that is performing the transaction. If someone could set a precendent in law for that, then we might start to see some change (although I have a vague, sinking feeling that all of a sudden we'll all be required to do everything in person and give blood samples...).
I'm not sure I agree with the "important because they're compact, not because they're pre-prepared" argument.
:-)
Some rough numbers. If my maths is wrong, I'll take it all back
TFA quotes 33,705 WHr/gallon as the energy in todays fuels. If you get 0.02 gallon/mile (50 mpg) at 50 m/h, that's a constant output of 33kW. The sun gives us around 1.3kW/m^2 at peak delivery. So you need a 100% efficient, 25m^2 solar collector to drive around at 50 m/h.
Stupid assumption there is that cars will continue to get 50mpg when they're all solar powered. But that kind of counters your other point about "Reducing energy use is a good measure to give us more time, but it's not viable long term". Reducing energy consumption *is* the only way to go, unless you want to end up living on a giant solar panel for a planet. We expend far more energy than is necessary go get things done at the moment, and that will need to change. I guess it all comes down to which is easier: reduce the rate of consumption, or increase the rate of production.
For cars, I think we can be smarter about reducing the amount of energy it takes us to get around, rather than looking for new, highly dense sources of energy.
Unfortunately, your vegetable oil utopia is unlikely to arrive.
_ and_Economic_Arguments
r .htm
. asp?nonoecd=India&SubmitC=Submit&COUNTRY_LONG_NAME =India
http://en.wikipedia.org/wiki/Biodiesel#Efficiency
"...it is likely that the United States, with one of the highest per capita energy demands of any country, does not have enough arable land to fuel all of the nation's vehicles.", and that's if you use all the land that's currently being used to grow food. When it comes down to it, production of oil from plants is pretty much just an inefficient (for our needs) way to gather solar power (all that energy wasted producing seeds, growing upwards, looking pretty, etc). Much more efficient to have a solar gathering mechanism that is not distracted by reproduction and evolution.
It all depends on the length of the term you look at. In the long-term (read, hundreds of years), it's likely that the only source of energy that'll keep arriving is energy radiated from the sun. So at some point, on average, we're going to have to match our consumption with that incoming rate (factored by how efficiently we can harvest that energy). The amount of energy the earth recieves from the sun is pretty big. A quick search finds info on just one country (India):
Energy from Sun: 5000 trillion kWh/year
http://www.auroville.org/research/ren_energy/sola
Current energy production: 5.3 trillion kWh/year
http://www.iea.org/Textbase/stats/nmcbalancetable
I couldn't find a calculation for the global energy from the sun value to compare with. Numbers are probably very different for highly industrialised nations. We probably don't want to absorb all the energy from the sun for our own purposes though, it does all kinds of useful things, like makes plants grow (which we eat) and keeps things warm (admittedly most energy we consume will probably be re-emmitted as heat and will keep us warm anyway, energy in = energy out and all that).
Things like oil represent long-term storage of energy gathered from the sun. We're reaping the benefits of having these pre-prepared batteries lying around at the moment, but when we've used them all up, it'll be back to only using as much as is being supplied.
My prediction is that we're going to have to back-off on our energy consumption. Short term solutions might arrive for a while (new oil reserves, nuclear power material deposits, etc), but long-term, it'll be back to depending on the Sun (and even that'll run out in a few billion years).
Best to prepare for it now I say. Stop living so far from what you need, don't expect to be able to travel where you want and when. Don't live in a manner that demands lots of energy and you won't be affected as much when there isn't as much energy to go around (live in a village, not a city, grow your own food, don't truck it in from Brazil. You *don't* need to eat bananas in Canada in the middle of winter).
Good prediction. Looks like the 2.16Ghz version of the 15" is quietly gone from their store.
A ppleStore.woa/wo/0.RSLID?mco=608880DF&nclm=MacBook Pro
http://store.apple.com/1-800-MY-APPLE/WebObjects/
Don't be so soft: Check these guys out. Great story about a guy there who cycles to work all year round in Ottawa, ON.
Which is why I said "It's the best you can do".
If you require access to a remote resource that wants some kind of credentials
presented, and you don't want to get a human involved, then you have little choice
other than to store something that someone could take a copy of and use to impersonate
your system.
Set file permissions properly. Make password-containing config files only readable by the processes that need to read them. chmod 0400. Keep each of your apps separated in this way so that a compromise of one doesn't affect the others. This is the best you can do. Password obfuscation can always be broken.
If your system can automatically authenticate against a remote secure resource, then someone who compromises your system can make it do it again. The only other thing you can do would be to require human intervention every time a password is required (or a collection of passwords).
WRT shootings, I think the grandparent was referring to the fact that (from http://www.ichv.org/Statistics.htm):
Homocides due to guns (1998):
57 people in Australia
11,829 people in the US
295,734,134 US population
20,090,437 Australian population
So Australia has roughly 1 gun related homocide per 354,000 people per year.
US has roughly 1 gun related homocide per 25,000 people per year.
So, you're about 15 times more likely to be shot intentionally in the US than you are in Australia (unintentional shooting statistics appear to favour Australia even more).
Of course, statistics like "15 times more likely" aren't actually that meaningful, especially when you're talking about 0.004% (US) vs 0.0002% (AUS), the odds are still pretty low that you'll get shot.
Compare this to the chance of getting killed in a car accident. Personally, I don't think it's a real thing you should worry about every day.
This may or may not be a problem. If all of a sudden, the spammers had to spend more to actually send all that crap, then you might find that it'd die down proportionally.
Of course, this doesn't mean a lot for spam coming from (insert spammy foreign country here).
And what exactly is the difference between "stream in full quality" and "downloaded to the computer"?
And how exactly is "with enough users, each one being a sort of node" different to the Internet? There's nothing stopping you
establishing a direct connection to any other user anywhere else other than geography and politics. P2P apps that open sockets
to various places already simulate exactly this kind of ad-hoc network.
http://www.apple.com/au/macosx/features/ichat/
Bandwidth will become a bit of an issue, as you need to serve your stream out to everyone involved, as well as downloading theirs.
http://svn.haxx.se/users/archive-2005-04/0210.shtm l
Read-only unfortunately, but actually, that's quite useful for publishing a subversion repository to a webserver and *forcing* people to check changes into the repository to make them go live.
I agree and disagree at the same time. Anybody who produces a product has the right to charge whatever they want for it. If the market will pay high prices (and in this case, people do), why should they lower it? It's obviously worth the price (otherwise people wouldn't pay).
However, the DNS system is not really a product, per se. Verisign just happen to be in control of the root nameservers that everyone just happens to use. Fair enough, they have the right to charge anyone whatever they want for adding entries to their DNS system. They lucked into the position basically by being first (or at least, very early).
To counter their price-grabbery, there is nothing stopping everyone moving to an alternative set of root DNS servers with a less draconian pricing model, except for the fact that doing that would be really hard to co-ordinate. While it's probably been a nice ride having a single, sane set of root DNS servers for the last 20 years, there is nothing that forces it to be that way, it's just the most efficient way right now. If the price of playing is set too high, then something more efficient will happen, like a fracturing of the DNS system (where more efficiency means dollars vs "effort to get to a particular host").
Like many monopolies, someone is one day going to come up with an alternative that takes hold and this "problem" will fizzle.
Easy, build one of these.
Of course, you could also cover your body with aluminium foil, that way, you'll be protected when you leave your house too!
svn co repos/trunk
/trunk is ready to go live:
svn commit
When
svn rm repos/livetag
svn cp repos/trunk repos/livetag
Then, on the live servers:
svn update (where they have working copies of repos/livetag)
OR, you could do:
svn cp repos/trunk repos/tag-20050403
(i.e. create a unique tag for each release)
then, on the live machines do:
svn switch repos/tag-20050403
Either way should do the trick. And as other posters have pointed out, have you asked this question on the Subversion mailing list?
Hey, those yellow bracelets are supposed to be a fundrasing exercise.
See http://www.livestrong.org/
Unfortunately there are a whole bunch of scams selling "fake" bracelets, or overcharging (note that the Lance Armstrong foundation sets a price of $1 each).