My understanding of the teleportation vs heisenberg issue (which is limited I'm well aware) was that it was possible to teleport, with the caveat that the original is destroyed. In other words, you can't observe the velocity and position of a particle both perfectly UNLESS you destroy the particle completely in the process of measuring it. So... I was under the impression that if our technology ever reached this stage, it would be possible to deconstruct a complex object into perfect information and then reconstruct it elsewhere. What is it that prevents this?
Well, the standard tinfoil hat answer (and not a bad one) is that we don't really know what the NSA's capabilities are. In the past they have been large leaps ahead of the public in cryptography and cryptoanalysis. If you're really worried about the NSA wanting to see your data, you have to assume that they may have new mathematical methods available to them that we are unaware of, which is a whole different ballgame than just fast brute force hardware. There's a remote possibility that the NSA already solved the factoring problem in O(3N) time or something like that. Or that they maybe didnt figure out factoring in general, but have found a flaw in the specifics of how it's used in RSA with the modulus and all. Or that they've already got quantum computing up and running well enough to insta-factor with it. These are all remote possibilities, especially considering that in the newer more open era the gap has probably closed a bit between the NSA and the public - but if someone were actually worried about NSA snooping, they have to consider such things. They are (and have been for a long time) the world's largest single employer of mathematicians after all.
Of course in a practical sense, there's no point worrying about the technical stuff. If the NSA wants your data, you better have some better way of hiding it that cryptography. They're gonna come after you and your family with a rubber hose for it. The best bet is probably knowing some secret they don't want the public to know, and setting up a dead man switch to release that information. Then you might have a playing field on which to negotiate the privacy of your data with them.
Does anyone else see this as the end of SCO (Caldera) like I do? I certainly will never use anything from them ever again
IMHO, Caldera, like their father SCO before, have always sucked. It was probably a good business move for them to start litigating, as it's the only shot they have left at turning a buck. I don't know too many people who ever respected them enough to buy their products anyways.
First off, it's entirely possible to build a drive that reads CDs, DVDs, and GDROM. Also, for cartridges they'd probably have adapter modules to put them all into a generic slot. Maybe even at extra cost. Don't forget that the further you go back, the easier it becomes to emulate. They could also bump their total by including games virtually nobody even owns the cartridgse to anymore, like Ataris and Odysseys and stuff. I'm sure you can come up with 32k emulated console games out there one way or another.
And we're not talking about them distributing these games, we're talking about them letting you buy them yourself from the manufacturer and run them, or re-use them if you already owned them from your old console. There's no legal issue there because you aren't actually selling Nintendo or Sony's code. The emulator thing is a whole other legal issue of course. I'm sure if this were the case Sony and/or Nintendo would try to sue and say it was illegal, but I think the prevailing court (and certainly public) opinion is that once you buy the cartridge legally, nobody can stop you from using it in an emulator. There haven't been many test cases for prosecuting the manufacturer of a commercial emulator as opposed to the users though.
There was local news coverage here in Houston on the SimDesk issue a while back, that went into some more interesting details. Of course first off, it was primarily chosen as a user interface for public-access computer in public libraries and whatnot. I don't think it was chosen for actual city computers, but for the computers they let the technology-less use at the libraries so they can surf and have email and type resumes, basically.
More importantly, there was a big uproar in Houston over how SimDesk got the contract. Apparently whoever owns SimDesk has some insider relations of some sort to the people making the decisions, and there was absolutely no bid process at all (no other local competition, no Microsoft, etc... ). Basically somebody's brother got the contract, and because it flies in MS face it made the news here as a big MS letdown. MS didn't stand a chance no matter who they are.
The answer to the 32k games statement seems pretty obvious to me. I think that in addition to having a small set of games written for and optimized for their supposedly powerful platform, they will put emulators in the box by default. Boot code will detect a disc/cartridge of Type X and load the appropriate emulator from rom. They could easily emulate NES, SNES, N64, PS1, Sega up through Dreamcast, and maybe PS2 althought I'm not entirely sure on that. The 32k games will be other consoles' games that you can replay on this one. It's the only way that number can make sense.
Sounds like he knows his stuff. The world needs more asm-aware programmers. High level languages and all the trickery that is "keep the source simple, waste the abundant cycles" and all are important things. The problem IMHO is that these are techniques to be applied by a fully-fledged programmer, who is capable of doing it the hard way in C or even asm - but too many modern programmers have only ever know the world of OO languages. The Leaky Abstractions paper applies here too.
This is not good enough. Merely Zeroing the data prevents "undeletes" and reading raw sector data in conventional ways, but there are tools to recover data that was been zeroed.
A simplistic way of think about it is this (this isn't remotely close to what really happens, but it's sufficient to get the point across): Each bit on the drive can have a real value of 1-100. 1-50 is interpreted as zero, 51-100 is a one. However, changing a bit from one to zero doesn't usually apply enough magnetic force to move it a full 100 points. Therefore it's common that if you zero a bit that used to be a zero, it will end up being very very low, but if you zero a bit that used to be a one, it will be in the higher one range, say a 40. Based on this, data recovery experts can get a pretty good picture of what the data used to be.
The US DoD has a standard they established way back when for fully erasing data against these sorts of recovery techniques. I don't know how old it was, but it was well-known in the early 90's for sure. It may not be safe any more. It specified overwriting the data a total of 7 times with specific patterns (something like 00, FF, 77, 11, EE, 77, 00, FF.... I don't remember the actual sequence).
The moral of the story is, don't trust any software method for destroying data. Use a blowtorch or an electric sander on the raw platter surfaces after removing them from the drive casing. While you're at it hit the electronics and the heads too. Or throw the whole thin in an incinerator that's hot enough to melt case platters and all into a lump of metal.
It may be impressive in the sense that ferro-electric might have decent seek and transfer times, but it's certainly not very impressive in terms of raw storage capacity. 47 DVDs in a square inch. Think of how thin the actual storage layer on a DVD is (not the plastic cover), and it seems pretty easy to reach that number or higher with DVD storage technology recnofigured into a cube of layers.
I can see the angle you come from, but I'm of a different opinion on the matter. Good asm demos (original and mind-bendingly efficient code) are the pinnacle of coding. People who can pull off the kinds of tricks neccesary to do these things can pull off just about anything else in the programming world with a reference book and a little time. It's hard to say that of any other area. Algorithm Design, Concurrent Programming, Compiler-Writing, and many other "tough" areas of programming involve a lot of the same skills that the demo coder employs, surprisingly. Top demo writers are doing very heavy math in their code, often inventing custom algorithms, and writing what amounts to scripting languages that are efficiently encoded as bytestreams to play the demo. Concurrency is a little iffy, but even then I think some of the things a demo writer deals with on interrupt handling and DMA transfers come close enough to get you in the ballpark.
Sure there's lots of programming tasks that have nothing to do with demo writing - but very very few people have ever mastered the art of the asm demo (like fine works of art, incredible demos are rare). Those people are the "born to code" types who can accomplish just about anything else as well. Demos are the way they show off, in a way that even non-coders can appreciate (although sometimes only a coder can truly feel the amazement at what was accomplished).
And yes, I'll concede that writing "stupid little assembly demos" is where a lot of people start (hey I did too), but that's a whole different thing from writing really good ones, or really being a demo scene kinda guy. Just as programmers are a small elite pool of the general computer population, good-demo-level coders are a small elite pool of the general coder population. Therefore, I don't think your average computer user who isn't yet a programmer should really be aiming there, most likely if they were that kind of natural they'd already be coding something.
If you were the programmer type, it would've already struck you that you were during your years of computer use. Demos (I'm thinking of course of good old ASM demo writing) are the pinnacle of raw programmer talent display. Winning a demo competition is basically saying "I am a very unique, gifted, exceptional programmer who can kick other programmers' asses". The odds of a regular computer user with no previous programming experience managing to churn out an original demo, even with a library of related books on-hand, is slim.
Well yes, dynamic content can't be effectively cached. The solution with existing protocols is to isolate dynamic content from static content. This is already acheived to a large degree by the nature of images. In the case of a dynamic page containing several static references, the images are still effectively cached and HEADed while the dynamic html content itself is re-served. You could extend that a bit by, for instance, putting the 95% of your front page that's static into a seperate static html file, and using IFRAMEs or some other method to load in dynamic snippets where appropriate.
There are already methods in the existing HTTP protocols implemented by popular browsers and servers to do this, but not by sending the data to the server. The HEAD method (as opposed to GET) requests from the server the last-modified date and a hash of the requested URL. Smart browsers first use their cache if it hasn't expired yet - then if they have the request in cache they send a HEAD request to see if it ever changed on the server - if not display cache, if so download new page.
Of course the other ignorant 50% who voted for the other equally moronic candidate, and still think his forieng and economic policies are good for out country probably are hippocritical idiots that can't see the big picture of politics or use words with more than two syllables.
Any American with a remote interest in politics really needs to understand a few basic truths:
1) Most of the public is ignorant 2) All the political parties are out for their own gain, and their policies are no good for any of us. 3) The only way out is a third party rising that won't behave like the current two (unlikely), popular revolt (unlikely), or complete failure of our system (likely, but we've probably got a couple decades left).
Fair enough. I was quick to reply, and ulimit cpu limits aren't quite what the guy is looking for. I bet if there was sufficient demand for such a thing, this could be hacked in as another setrlimit (ulimit) value with minimal effort.
Just to continue being a "12 year old microsoft basher" as the AC response put it: Maybe we haven't seen a need in unix because schedulers work better there, and apps are better behaved?
1) AC go home. Bring an idea to the table or stfu, and why don't you leave your name while you're at it.
2) It's not cryptography. It's just hashing for translucency. I'm not perfect, and that was an off-the-cuff slashdot post. Feel free to argue it's merits with me, but don't just post an unfounded "you suck".
I believe I already brought this up and gave estimates on the complexity above, as well as solutions for the problem. Did you only read my first paragraph?
Oh and I might add that this won't work over an IP connection only (e.g. across the net). You need to be on the same ethernet segment as the target. This greatly limits the usefulness again. While we're at it, if you were on their segment, and it's not switched, you likely already are seeing every packet the target machine transmits anyways. Oh and by the way, there's exploits out there already to make most switches give up this data as well, so in all likelyhood this gained you nothing.
This is another example of a so called "security team" finding a minor problem and trumping it up to sound like Armageddon is upon us in an attempt to boost their own visibility and credibility.
Executive Summary of Bug:
Many ethernet drivers on many OSs exhibit this problem. It is possible to send a packet to the target machine which triggers the target machine to send back a very short reply packet. Inside this very short reply packet, there maybe be as many as 30 or so bytes of data that should have been zeros. This data is from some other packet recently sent out by the target machine. This data is: (1) unlikely to be the data you were looking for (2) extremely short (3) probably was encrypted before being transmitted the first time if it was truly sensitive information
In the real world, there will probably be many better avenues of attacking a machine than attempting to leverage this exploit. Leveraging this exploit will require a lot of patience and good luck, as well as poor security practices on the target's side to begin with. You have many better things to worry about, move along please.
Re:Huh? (was Re:SGI is still in business?)
on
New SGI Altix 3000
·
· Score: 2
ALl these years you actually have, he is correct. For a variety of reasons, most centering around their own personal and corporate gain in the long term, analysts almost always overrate companies. Here's the usual rundown:
1) When you see a Strong Buy rating, that means they are directly benefitting from this company's performance, and would like you to make them richer please. Sometimes it actually means the company will do well, or some mix of the two, but it's hard to tell.
2) When you see a regular Buy rating, that means the company is pretty neutral with a possibly good outlook maybe. Translate this as a hold leaning towards a buy.
3) When you see a Hold rating, that means dump this stock like the plague.
4) When you see a Sell rating, if you're still holding the stock you're already screwed and it doesn't matter when you do at this point.
How many DECADES have unices had ulimit support working by default? Wake up Micro$loth, here's another innovation you're completely missed the boat on.
Slashdot Mirror
My understanding of the teleportation vs heisenberg issue (which is limited I'm well aware) was that it was possible to teleport, with the caveat that the original is destroyed. In other words, you can't observe the velocity and position of a particle both perfectly UNLESS you destroy the particle completely in the process of measuring it. So... I was under the impression that if our technology ever reached this stage, it would be possible to deconstruct a complex object into perfect information and then reconstruct it elsewhere. What is it that prevents this?
Well, the standard tinfoil hat answer (and not a bad one) is that we don't really know what the NSA's capabilities are. In the past they have been large leaps ahead of the public in cryptography and cryptoanalysis. If you're really worried about the NSA wanting to see your data, you have to assume that they may have new mathematical methods available to them that we are unaware of, which is a whole different ballgame than just fast brute force hardware. There's a remote possibility that the NSA already solved the factoring problem in O(3N) time or something like that. Or that they maybe didnt figure out factoring in general, but have found a flaw in the specifics of how it's used in RSA with the modulus and all. Or that they've already got quantum computing up and running well enough to insta-factor with it. These are all remote possibilities, especially considering that in the newer more open era the gap has probably closed a bit between the NSA and the public - but if someone were actually worried about NSA snooping, they have to consider such things. They are (and have been for a long time) the world's largest single employer of mathematicians after all.
Of course in a practical sense, there's no point worrying about the technical stuff. If the NSA wants your data, you better have some better way of hiding it that cryptography. They're gonna come after you and your family with a rubber hose for it. The best bet is probably knowing some secret they don't want the public to know, and setting up a dead man switch to release that information. Then you might have a playing field on which to negotiate the privacy of your data with them.
IMHO, Caldera, like their father SCO before, have always sucked. It was probably a good business move for them to start litigating, as it's the only shot they have left at turning a buck. I don't know too many people who ever respected them enough to buy their products anyways.
First off, it's entirely possible to build a drive that reads CDs, DVDs, and GDROM. Also, for cartridges they'd probably have adapter modules to put them all into a generic slot. Maybe even at extra cost. Don't forget that the further you go back, the easier it becomes to emulate. They could also bump their total by including games virtually nobody even owns the cartridgse to anymore, like Ataris and Odysseys and stuff. I'm sure you can come up with 32k emulated console games out there one way or another.
And we're not talking about them distributing these games, we're talking about them letting you buy them yourself from the manufacturer and run them, or re-use them if you already owned them from your old console. There's no legal issue there because you aren't actually selling Nintendo or Sony's code. The emulator thing is a whole other legal issue of course. I'm sure if this were the case Sony and/or Nintendo would try to sue and say it was illegal, but I think the prevailing court (and certainly public) opinion is that once you buy the cartridge legally, nobody can stop you from using it in an emulator. There haven't been many test cases for prosecuting the manufacturer of a commercial emulator as opposed to the users though.
EMP weapons have been in practical use for years. This is not your mother's EMP weapon, it's a microwave beam.
There was local news coverage here in Houston on the SimDesk issue a while back, that went into some more interesting details. Of course first off, it was primarily chosen as a user interface for public-access computer in public libraries and whatnot. I don't think it was chosen for actual city computers, but for the computers they let the technology-less use at the libraries so they can surf and have email and type resumes, basically.
More importantly, there was a big uproar in Houston over how SimDesk got the contract. Apparently whoever owns SimDesk has some insider relations of some sort to the people making the decisions, and there was absolutely no bid process at all (no other local competition, no Microsoft, etc... ). Basically somebody's brother got the contract, and because it flies in MS face it made the news here as a big MS letdown. MS didn't stand a chance no matter who they are.
The answer to the 32k games statement seems pretty obvious to me. I think that in addition to having a small set of games written for and optimized for their supposedly powerful platform, they will put emulators in the box by default. Boot code will detect a disc/cartridge of Type X and load the appropriate emulator from rom. They could easily emulate NES, SNES, N64, PS1, Sega up through Dreamcast, and maybe PS2 althought I'm not entirely sure on that. The 32k games will be other consoles' games that you can replay on this one. It's the only way that number can make sense.
Sounds like he knows his stuff. The world needs more asm-aware programmers. High level languages and all the trickery that is "keep the source simple, waste the abundant cycles" and all are important things. The problem IMHO is that these are techniques to be applied by a fully-fledged programmer, who is capable of doing it the hard way in C or even asm - but too many modern programmers have only ever know the world of OO languages. The Leaky Abstractions paper applies here too.
This is not good enough. Merely Zeroing the data prevents "undeletes" and reading raw sector data in conventional ways, but there are tools to recover data that was been zeroed.
A simplistic way of think about it is this (this isn't remotely close to what really happens, but it's sufficient to get the point across): Each bit on the drive can have a real value of 1-100. 1-50 is interpreted as zero, 51-100 is a one. However, changing a bit from one to zero doesn't usually apply enough magnetic force to move it a full 100 points. Therefore it's common that if you zero a bit that used to be a zero, it will end up being very very low, but if you zero a bit that used to be a one, it will be in the higher one range, say a 40. Based on this, data recovery experts can get a pretty good picture of what the data used to be.
The US DoD has a standard they established way back when for fully erasing data against these sorts of recovery techniques. I don't know how old it was, but it was well-known in the early 90's for sure. It may not be safe any more. It specified overwriting the data a total of 7 times with specific patterns (something like 00, FF, 77, 11, EE, 77, 00, FF
The moral of the story is, don't trust any software method for destroying data. Use a blowtorch or an electric sander on the raw platter surfaces after removing them from the drive casing. While you're at it hit the electronics and the heads too. Or throw the whole thin in an incinerator that's hot enough to melt case platters and all into a lump of metal.
It may be impressive in the sense that ferro-electric might have decent seek and transfer times, but it's certainly not very impressive in terms of raw storage capacity. 47 DVDs in a square inch. Think of how thin the actual storage layer on a DVD is (not the plastic cover), and it seems pretty easy to reach that number or higher with DVD storage technology recnofigured into a cube of layers.
I can see the angle you come from, but I'm of a different opinion on the matter. Good asm demos (original and mind-bendingly efficient code) are the pinnacle of coding. People who can pull off the kinds of tricks neccesary to do these things can pull off just about anything else in the programming world with a reference book and a little time. It's hard to say that of any other area. Algorithm Design, Concurrent Programming, Compiler-Writing, and many other "tough" areas of programming involve a lot of the same skills that the demo coder employs, surprisingly. Top demo writers are doing very heavy math in their code, often inventing custom algorithms, and writing what amounts to scripting languages that are efficiently encoded as bytestreams to play the demo. Concurrency is a little iffy, but even then I think some of the things a demo writer deals with on interrupt handling and DMA transfers come close enough to get you in the ballpark.
Sure there's lots of programming tasks that have nothing to do with demo writing - but very very few people have ever mastered the art of the asm demo (like fine works of art, incredible demos are rare). Those people are the "born to code" types who can accomplish just about anything else as well. Demos are the way they show off, in a way that even non-coders can appreciate (although sometimes only a coder can truly feel the amazement at what was accomplished).
And yes, I'll concede that writing "stupid little assembly demos" is where a lot of people start (hey I did too), but that's a whole different thing from writing really good ones, or really being a demo scene kinda guy. Just as programmers are a small elite pool of the general computer population, good-demo-level coders are a small elite pool of the general coder population. Therefore, I don't think your average computer user who isn't yet a programmer should really be aiming there, most likely if they were that kind of natural they'd already be coding something.
If you were the programmer type, it would've already struck you that you were during your years of computer use. Demos (I'm thinking of course of good old ASM demo writing) are the pinnacle of raw programmer talent display. Winning a demo competition is basically saying "I am a very unique, gifted, exceptional programmer who can kick other programmers' asses". The odds of a regular computer user with no previous programming experience managing to churn out an original demo, even with a library of related books on-hand, is slim.
Well yes, dynamic content can't be effectively cached. The solution with existing protocols is to isolate dynamic content from static content. This is already acheived to a large degree by the nature of images. In the case of a dynamic page containing several static references, the images are still effectively cached and HEADed while the dynamic html content itself is re-served. You could extend that a bit by, for instance, putting the 95% of your front page that's static into a seperate static html file, and using IFRAMEs or some other method to load in dynamic snippets where appropriate.
check my journal.
There are already methods in the existing HTTP protocols implemented by popular browsers and servers to do this, but not by sending the data to the server. The HEAD method (as opposed to GET) requests from the server the last-modified date and a hash of the requested URL. Smart browsers first use their cache if it hasn't expired yet - then if they have the request in cache they send a HEAD request to see if it ever changed on the server - if not display cache, if so download new page.
Of course the other ignorant 50% who voted for the other equally moronic candidate, and still think his forieng and economic policies are good for out country probably are hippocritical idiots that can't see the big picture of politics or use words with more than two syllables.
Any American with a remote interest in politics really needs to understand a few basic truths:
1) Most of the public is ignorant
2) All the political parties are out for their own gain, and their policies are no good for any of us.
3) The only way out is a third party rising that won't behave like the current two (unlikely), popular revolt (unlikely), or complete failure of our system (likely, but we've probably got a couple decades left).
You can accomplish all of the above that way.
Fair enough. I was quick to reply, and ulimit cpu limits aren't quite what the guy is looking for. I bet if there was sufficient demand for such a thing, this could be hacked in as another setrlimit (ulimit) value with minimal effort.
Just to continue being a "12 year old microsoft basher" as the AC response put it: Maybe we haven't seen a need in unix because schedulers work better there, and apps are better behaved?
1) AC go home. Bring an idea to the table or stfu, and why don't you leave your name while you're at it.
2) It's not cryptography. It's just hashing for translucency. I'm not perfect, and that was an off-the-cuff slashdot post. Feel free to argue it's merits with me, but don't just post an unfounded "you suck".
3) You suck.
I believe I already brought this up and gave estimates on the complexity above, as well as solutions for the problem. Did you only read my first paragraph?
Questionnaire:
1) How happy have you, your friends, and your relatives been with licensed auto mechanics in the past?
2) How happy have you, your friends, and your relatives been with licensed hairdressers in the past?
3) Do you now think government licensing has anything to do with customer satisfaction?
Oh and I might add that this won't work over an IP connection only (e.g. across the net). You need to be on the same ethernet segment as the target. This greatly limits the usefulness again. While we're at it, if you were on their segment, and it's not switched, you likely already are seeing every packet the target machine transmits anyways. Oh and by the way, there's exploits out there already to make most switches give up this data as well, so in all likelyhood this gained you nothing.
This is another example of a so called "security team" finding a minor problem and trumping it up to sound like Armageddon is upon us in an attempt to boost their own visibility and credibility.
Executive Summary of Bug:
Many ethernet drivers on many OSs exhibit this problem. It is possible to send a packet to the target machine which triggers the target machine to send back a very short reply packet. Inside this very short reply packet, there maybe be as many as 30 or so bytes of data that should have been zeros. This data is from some other packet recently sent out by the target machine. This data is:
(1) unlikely to be the data you were looking for (2) extremely short
(3) probably was encrypted before being transmitted the first time if it was truly sensitive information
In the real world, there will probably be many better avenues of attacking a machine than attempting to leverage this exploit. Leveraging this exploit will require a lot of patience and good luck, as well as poor security practices on the target's side to begin with. You have many better things to worry about, move along please.
ALl these years you actually have, he is correct. For a variety of reasons, most centering around their own personal and corporate gain in the long term, analysts almost always overrate companies. Here's the usual rundown:
1) When you see a Strong Buy rating, that means they are directly benefitting from this company's performance, and would like you to make them richer please. Sometimes it actually means the company will do well, or some mix of the two, but it's hard to tell.
2) When you see a regular Buy rating, that means the company is pretty neutral with a possibly good outlook maybe. Translate this as a hold leaning towards a buy.
3) When you see a Hold rating, that means dump this stock like the plague.
4) When you see a Sell rating, if you're still holding the stock you're already screwed and it doesn't matter when you do at this point.
How many DECADES have unices had ulimit support working by default? Wake up Micro$loth, here's another innovation you're completely missed the boat on.