1) They want everything to just work instantly. Windows does this, as far as the average user can tell.
ROTFLMAO. The last two times I installed Windows XP it wouldn't load the driver for a simple RealTek NIC. The Device Manager would just say "Ethernet Device" and not say what type it was. If I manually specified the driver for it, it would say "Error 0: Device refuses to start".
In contrast, SuSE loaded the correct module without any input on my part, DHCP'd from the router, and I didn't have to think about it.
Same thing with sound cards. I had a Vortex soundcard that Windows simply wouldn't load a driver for. I grovelled through newsgroups and vendor websites for weeks looking for a workable driver. None of them worked. The sound card works fine in Linux.
Windows apologists can say til Kingdom Come that Windows is better with hardware, but the simple fact is that if that were true I would never have switched to Linux. I switched to Linux because it supported hardware without a headache, and Windows wouldn't.
Windows is less user friendly on the install than most Linux distros -- but most users don't install Windows. Give them a pre-installed Linux and they'll be just as happy. Happier, in fact, if they ever need to change hardware.
I like OS X, but every time I've used it I am amazed that Home/End doesn't work properly. What the fuck was Jobs thinking?
From what I've seen of Macs, I'd guess he was thinking "It is my continuing mission to keep users from thinking about computers as tools for manipulating text files."
In a simple loop it doesn't matter, but as soon as you start nesting loops i, j, k, ii, jj and so on become very difficult to follow.
I usually avoid "j" for orthographic reasons (except in Forth, where "i" and "j" are defined by the language as the indexes of the two innermost "for" loops), but I use i or k for every for loop I have... and if I'm nesting more than 2 loops that means I've let this function get too complex.
First, I'm glad to see at least a few people got the joke.
Secondly, I definitely agree with you. I think both go and chess programs are taking the less interesting route by doing dictionary / exhaustion algorithms, since that's not how humans play either game (in most circumstances -- openings and endgames are another matter).
Sticking with chess (since I know it better, and I think the lesson carries over), I think Kasparov really exposed this flaw in his second game against Fritz. If you completely seize the initiative from an algorithm based on exhaustive move analysis, it is helpless until you make a mistake. Even the most amateur human player would have said "he's making me look stupid; I have to do something". People play games like go and chess by setting out objectives and performing a basic analysis on the moves that further those objectives, calculating risks based on that analysis, and choosing the next move. I would love to see a go- or chess-playing program based on that model.
It's nice that AI and computer science research is going into popular and well-known games like go, but a lot more complexity and interesting research can be found in a less-known game called chess
For such a hash function, it would be very difficult to construct (for example) two similarly worded contracts, such that one could easily substitute another after the signing process, and not have it be blatantly obvious that a change had been made.
Yeah, and it still is very difficult. It's just that they've found a way somewhat faster than brute force to find essentially random data (NOT "data with any particular characteristics" -- that would be useful to an attacker, at least) that hashes the same as the piece of data in question.
All you can really do with this is replace any message verified by a hash with garbage. Perhaps useful in a DoS attack if the hash verification is a step of the routing, but hard to imagine another use for it.
You're mixing up economics models. Price in a monopoly is what the market will bear ( == high). Price in a free market is marginal cost ( == low). Here is a brief summary.
That's like saying you should get a co-located computer for free because you're paying $49.95 a month for bandwidth.
Umm... that's how my colo is. I don't own the server or anything but I can do whatever I want with it as long as I keep paying them $45 a month. If I leave the contract they keep the box, since they paid for it, and they make the cost of the box back on margins.
I agree on the one hand that they will charge whatever they can get away with. However, it's pretty firmly proven that in an efficient free market the price of a good or service is equal to its marginal cost; that means once this market gets free and efficient the clients will be gratis and the cash transfer will be the subscription fees.
Upon purchase, the source code would be freely available, modifiable, and so on.
That's the GPL. You don't have to give away your sources and binaries for free, you just have to include the sources (and the right to modify, redistribute, etc.) to all parties who receive the binaries from you. Hell, RMS used to charge $100 just for emacs, and they still charge more than a grand for GNU.
Except in certain specific circumstances involving derivative works, the GPL never requires you to distribute binaries and sources to anyone in particular; you alone decide the criteria for distributing your work. If you want to charge $3000 for your GPLd CRM solution, feel free. You don't have to offer free downloads or sources to people who haven't bought them from you.
So, again, what would you change about the GPL to make it "commercial", since you can already make the receipt of sources and binaries contingent on purchase?
Re:So the concern is.....
on
SHA-1 Broken
·
· Score: 2, Informative
they could concievably glean the cleartext
No. Hashes like SHA-1 are lossy; there is less information in the hash than in the plaintext. Lost information like that cannot be recovered unless just about everything we know from information theory (and thermodynamics) is wrong.
Re:Not a problem (yet)
on
SHA-1 Broken
·
· Score: 1
This (theoretically) means I can make two contracts that hash the same, and digitally sign them both.
True, though any attack like that is very very theoretical. The chances that two colliding plaintexts would both be intelligible seems vanishingly small; if I drew up a legal contract and then brute-forced a file with the same hash, it would almost certainly just be gibberish 0s and 1s. The only feasible attack I can think of would be to replace important files / messages / etc. with gibberish without attracting the attention of a hash-based intrusion detector.
This is, however, a good time to remember 2 important rules of signing data:
Don't sign arbitrary files from unknown parties
Whenever possible make cosmetic changes to any file before signing it
Those guidelines would pretty much foil attacks based on these collisions.
OpenSSL, while nice, is transport-level. The secure communication provided by OSSL does nothing to authenticate a given user or service. Now, Kerberos has and needs transport-level security, it just doesn't use OpenSSL to do it. You could, conceivably, re-write something like Kerberos using the public-private key model (which would solve some of the dilemmas in Kerberos design and introduce new ones), but that would be re-inventing a pretty big wheel.
Personally, I use SSL to fake authorization on my network (this assumes secure hardware and some other things; no solution is foolproof; YMMV; etc.), so you can see where I fall on that debate.
In the same way that apples compare to oranges. Asterisk is a PBX replacement: go into the phone closet at your office and look for something that looks like a really big motherboard with ridiculously huge PCI cards on it and a bunch of phone lines going into them. An asterisk box is meant to replace that: it can run digital and analog telephony, and VOIP to if you want it to.
Or a yard of GM grass that won't allow it to start growing in the firstplace?
Because the grass will pollinate normal grass, too. Then we'll have no weeds anywhere. No weeds mean we suffer about 25% extinction among hymenopterans and lepidopterans. That translates into a 10% extinction among avians. You see where this goes?
Should we focus our money on massively increasing food production
Why? We already produce about 5 times the world's caloric intake with current agricultural techniques. This is one of Monsatan's huge lies: that people are starving because not enough food is being made.
Lack of food production is not why people are starving. People are starving because corrupt government use food as a weapon against their own population. Increasing food production won't help that; it may even make it worse because the food supply will be even more centrally controlled.
And what should they do the first time OpenOffice doesn't open a document from an uber important customer properly?
Same thing I do when I can't open something from an uber important client using MS Office (this happens too): point him to Adobe's "make a pdf" website.
Then again, our uber-important clients don't know jack about technology and don't mind hearing stuff like that (the last Word document that wouldn't open, for instance, was messed up because the VP writing the report tried to embed some weird OLE object in another weird OLE object: we told him to stop doing crap like that, and he was fine with that)
Why bother with tainting when you can just do rigorous validation with things like struts?
Why bother with that when you can do rigorous validation of data without a managed VM?
Here's a little thing people seem to be forgetting: buffer overruns and smashable stacks aren't being written by applications developers. These vulnerabilities are found (increasingly rarely) in core libraries. Check bugtraq and vulndev: most exploits being found now are not overrunnable buffers and such; they're SQL insertion and format string exploits. These can be checked for even in plain-old C but people don't check for them and these managed VMs are setting up a mental Maginot line that makes developers even less willing to check for them.
Or telling them to go to Bob's Discount Linux Shop when they can get the same computer with an OS they allready know
I agree with all of your points except that one. Everybody who doesn't want to switch to Linux says "but I know Windows and I don't know Linux". In fact, most of the people I've talked to *don't* know Windows; they know by rote 4 or 5 tasks they use for their job or personal life. They are just as clueless about using Windows as they are about Linux. And thanks to Knoppix, I have now proven time after time that the learning curve for everyone I've shown it to has been about half an hour.
It can be irritating, but people need to accept the fact that if they can't use Linux they probably can't use Windows either.
Slashdot Mirror
ROTFLMAO. The last two times I installed Windows XP it wouldn't load the driver for a simple RealTek NIC. The Device Manager would just say "Ethernet Device" and not say what type it was. If I manually specified the driver for it, it would say "Error 0: Device refuses to start".
In contrast, SuSE loaded the correct module without any input on my part, DHCP'd from the router, and I didn't have to think about it.
Same thing with sound cards. I had a Vortex soundcard that Windows simply wouldn't load a driver for. I grovelled through newsgroups and vendor websites for weeks looking for a workable driver. None of them worked. The sound card works fine in Linux.
Windows apologists can say til Kingdom Come that Windows is better with hardware, but the simple fact is that if that were true I would never have switched to Linux. I switched to Linux because it supported hardware without a headache, and Windows wouldn't.
Windows is less user friendly on the install than most Linux distros -- but most users don't install Windows. Give them a pre-installed Linux and they'll be just as happy. Happier, in fact, if they ever need to change hardware.
From what I've seen of Macs, I'd guess he was thinking "It is my continuing mission to keep users from thinking about computers as tools for manipulating text files."
I usually avoid "j" for orthographic reasons (except in Forth, where "i" and "j" are defined by the language as the indexes of the two innermost "for" loops), but I use i or k for every for loop I have ... and if I'm nesting more than 2 loops that means I've let this function get too complex.
What's a better name for an index (which usually translates into a table or array subscript) than "i"?
Actually you don't need 1.0.1 to see how it works; spoofstick on 1.0 displays the bogus URL as xn--blah-blah-blah...
You are forgiven. Now go forth and bite at trolls no more.
First, I'm glad to see at least a few people got the joke.
Secondly, I definitely agree with you. I think both go and chess programs are taking the less interesting route by doing dictionary / exhaustion algorithms, since that's not how humans play either game (in most circumstances -- openings and endgames are another matter).
Sticking with chess (since I know it better, and I think the lesson carries over), I think Kasparov really exposed this flaw in his second game against Fritz. If you completely seize the initiative from an algorithm based on exhaustive move analysis, it is helpless until you make a mistake. Even the most amateur human player would have said "he's making me look stupid; I have to do something". People play games like go and chess by setting out objectives and performing a basic analysis on the moves that further those objectives, calculating risks based on that analysis, and choosing the next move. I would love to see a go- or chess-playing program based on that model.
It's nice that AI and computer science research is going into popular and well-known games like go, but a lot more complexity and interesting research can be found in a less-known game called chess
Yeah, and it still is very difficult. It's just that they've found a way somewhat faster than brute force to find essentially random data (NOT "data with any particular characteristics" -- that would be useful to an attacker, at least) that hashes the same as the piece of data in question.
All you can really do with this is replace any message verified by a hash with garbage. Perhaps useful in a DoS attack if the hash verification is a step of the routing, but hard to imagine another use for it.
You're mixing up economics models. Price in a monopoly is what the market will bear ( == high). Price in a free market is marginal cost ( == low). Here is a brief summary.
Umm... that's how my colo is. I don't own the server or anything but I can do whatever I want with it as long as I keep paying them $45 a month. If I leave the contract they keep the box, since they paid for it, and they make the cost of the box back on margins.
I agree on the one hand that they will charge whatever they can get away with. However, it's pretty firmly proven that in an efficient free market the price of a good or service is equal to its marginal cost; that means once this market gets free and efficient the clients will be gratis and the cash transfer will be the subscription fees.
That's the GPL. You don't have to give away your sources and binaries for free, you just have to include the sources (and the right to modify, redistribute, etc.) to all parties who receive the binaries from you. Hell, RMS used to charge $100 just for emacs, and they still charge more than a grand for GNU.
Except in certain specific circumstances involving derivative works, the GPL never requires you to distribute binaries and sources to anyone in particular; you alone decide the criteria for distributing your work. If you want to charge $3000 for your GPLd CRM solution, feel free. You don't have to offer free downloads or sources to people who haven't bought them from you.
So, again, what would you change about the GPL to make it "commercial", since you can already make the receipt of sources and binaries contingent on purchase?
No. Hashes like SHA-1 are lossy; there is less information in the hash than in the plaintext. Lost information like that cannot be recovered unless just about everything we know from information theory (and thermodynamics) is wrong.
True, though any attack like that is very very theoretical. The chances that two colliding plaintexts would both be intelligible seems vanishingly small; if I drew up a legal contract and then brute-forced a file with the same hash, it would almost certainly just be gibberish 0s and 1s. The only feasible attack I can think of would be to replace important files / messages / etc. with gibberish without attracting the attention of a hash-based intrusion detector.
This is, however, a good time to remember 2 important rules of signing data:
- Don't sign arbitrary files from unknown parties
- Whenever possible make cosmetic changes to any file before signing it
Those guidelines would pretty much foil attacks based on these collisions.OpenSSL, while nice, is transport-level. The secure communication provided by OSSL does nothing to authenticate a given user or service. Now, Kerberos has and needs transport-level security, it just doesn't use OpenSSL to do it. You could, conceivably, re-write something like Kerberos using the public-private key model (which would solve some of the dilemmas in Kerberos design and introduce new ones), but that would be re-inventing a pretty big wheel.
Personally, I use SSL to fake authorization on my network (this assumes secure hardware and some other things; no solution is foolproof; YMMV; etc.), so you can see where I fall on that debate.
In the same way that apples compare to oranges. Asterisk is a PBX replacement: go into the phone closet at your office and look for something that looks like a really big motherboard with ridiculously huge PCI cards on it and a bunch of phone lines going into them. An asterisk box is meant to replace that: it can run digital and analog telephony, and VOIP to if you want it to.
As far as I've seen, actually, even the most primitive societies were aware that the earth is spherical.
Because your GM short grass and nice trees pollinate my real grass and real trees and screw up my ecosystem.
Because the grass will pollinate normal grass, too. Then we'll have no weeds anywhere. No weeds mean we suffer about 25% extinction among hymenopterans and lepidopterans. That translates into a 10% extinction among avians. You see where this goes?
Congratulations. You just re-invented the mulch pile.
Why? We already produce about 5 times the world's caloric intake with current agricultural techniques. This is one of Monsatan's huge lies: that people are starving because not enough food is being made.
Lack of food production is not why people are starving. People are starving because corrupt government use food as a weapon against their own population. Increasing food production won't help that; it may even make it worse because the food supply will be even more centrally controlled.
Never without rolling my eyes.
Same thing I do when I can't open something from an uber important client using MS Office (this happens too): point him to Adobe's "make a pdf" website.
Then again, our uber-important clients don't know jack about technology and don't mind hearing stuff like that (the last Word document that wouldn't open, for instance, was messed up because the VP writing the report tried to embed some weird OLE object in another weird OLE object: we told him to stop doing crap like that, and he was fine with that)
Why bother with that when you can do rigorous validation of data without a managed VM?
Here's a little thing people seem to be forgetting: buffer overruns and smashable stacks aren't being written by applications developers. These vulnerabilities are found (increasingly rarely) in core libraries. Check bugtraq and vulndev: most exploits being found now are not overrunnable buffers and such; they're SQL insertion and format string exploits. These can be checked for even in plain-old C but people don't check for them and these managed VMs are setting up a mental Maginot line that makes developers even less willing to check for them.
I agree with all of your points except that one. Everybody who doesn't want to switch to Linux says "but I know Windows and I don't know Linux". In fact, most of the people I've talked to *don't* know Windows; they know by rote 4 or 5 tasks they use for their job or personal life. They are just as clueless about using Windows as they are about Linux. And thanks to Knoppix, I have now proven time after time that the learning curve for everyone I've shown it to has been about half an hour.
It can be irritating, but people need to accept the fact that if they can't use Linux they probably can't use Windows either.