Any useful research involving DES most certainly is not corelated with prime numbers. DES consists entirely of xors, register rotations (for the key schedule), bit duplications, bit swaps, and a set of 8 6x4-bit optimally non-linear lookup tables (S-boxes). There are no additions, multiplications, exponentiations, or thier inverses, involved.
Now, it wouldn't surprise me if she used diffential cryptanalysis (DES is known to be quite weak against diffentiacryptanalsis) to do a lot of precomputation to make cracking crypt (whic is based on DES) passwords much faster. Big deal. Anyone still using crypt passwords deserves to get thier passwords compromised.
That's the dumbest thing I've ever heard. Isn't the whole point of.NET that it's platform-independant and multi-language. If you're sticking to Win32 b/c of.NET, then.NET is one big lie.
There are at east two Open-source.NET implementations in the works One is caled Mono, and I forget the name of the other. Mono has something like 95% of the.NET classes implemented and tested. When the bug reports start comming in, who do you think is going to patch faster?
Okay, so now what's the real reason you're staying with Lose32?
On my RH server, I have it set up every 6 hours to do an up2date followed by an autoupdate. I'm out of sync with the official website on average 3 hours. Granted, it's not a high-traffic site, so I don't have to worry too much even if updates do go awry.
No, older versions of Windows. Oh, and non-professionaly admin'd installs of Linux.
I don't remember the last time a PC crash stopped me in the middle of using my computer--I suspect it was playing UT, which is hardly Windows's fault.
If a user-space app crashes your OS (and a fork bomb brining it to a crawl doesn't truly count as a crash), there's something wrong with the OS. It's a design or implementation flaw somewhere.
It's really hard to administer Linux so poorly that it has stability problems. I've only had Linux crash for two reasons, both being hardware failures. (And when my HD locked up, it didn't even really crash, it just started printing out all of these errors that it couldn't save logs to disk.) In order to have non-hardware stability problems under linux, you need to go download an experimental kernel or kernel module. Sometimes you can't configure X11 and can't get X up and running, but the system still runs. Netscape isn't stable, but there are plenty of stable browsers out there.
I challenge you to find an app that can crash Debian-stable from an unprivledged account. Tell you what, I'm running Debian-testing/unstable. find a program that'll crsh my box from an unprivledged account. Here's one for WinNT/200/XP:
int main() { while(1){ printf("\t\b\b");} return 0;}
Try running it from the command line. (You'll need to include a header file or two, and you may need cygwin to compile it as written.) In NT and 2000, it'll BSOD. In XP they "fixed" the problem by having it autmatically reboot instead of blue-screening. It's a buffer unerflow flaw in the DOS emulation. It believes the DOS emulator is a vitalpart of the system, so it freaks out when it's forced to kill the DOS emulator. Instead of just restarting the DOS emulator and letting all of your DOS apps die, it immediately kills all of your apps and BSODs or restarts. NT 4.0 gets no more bug fixes, so it's a permanent bug in NT 4.0.
Sorry to burst your bubble, but There aren't 'hundreds of Gs on rentry.' Anything over 5 Gs is pretty dangerous, with anything over 10 Gs meaning Certain Death.
Ehh... the best firgter pilots can take 10 Gs for a few seconds before passing out (with G suits). Those guys in the famous rocket sled experiments took many more Gs for fractions of a second.
Note that I was talking about peak forces on nuclear warheads. Yes, if we made piloted nuclear missles, we'd need to give them more gentle flight paths.
When was the last time you heard a kidsay "I want to be a nuclear missle pilot when I grow up, just like you daddy"?
There are several reasons we don't put cockpits on ICBMs.:-P
Reentry peak Gs are greater than the lift phase peak Gs. (At least for the Trident, which isn't intercontinental, but still gets up into space.) The guidance systems on the warheads themselves need to be able to handle more Gs than the guidance systems on the booster/bus (that thing that holds the 3 trident warheads together in a bunch until it starts popping them off). It sounded strange to me too, but the guys designing the replacement tech knew they could replace the boost phase guidance, but they weren't as sure about the guidance systems on the warheads themselves, since reentry subjects the systems to higher loads. (I'd quote you the design numbers I was told, but I think perhaps I'm not even supposed to know that. There were a couple of non-classified things people told me there that they later told me to forget b/c I might be able to deduce some classified info from what they told me.)
Perhaps the warheads need more robust guidance since they are ocassionally dropped. (You think I'm joking. I worked with a guy that did the simulations one time a guy dropped a trident warhead off a forklift to let them know if it was still accurate. They gave him all the info they had on how it was dropped and he ran a bunch of fea simulations. I talked to him while the simulation were running, and never asked later if he said to put the warhead back into sevice. I didn't want to know.) Guidance is really interesting stuff. I didn't really have any moral objections, but a few of my friends that had been working there for a few years started having objections, and it seemed like I might start having the same problems in a few years.
You're right, the several hundred Gs includes the safety factor.
The're mostly complaining about poor design and interfaces, not poor implementation. Bad code can be fixed and doesn't break anything on top of it. (Unless the othercode relied on bugs.)
The entire MicrofSoft security team should be shot for using the LM hash. They should be shot again for not having a salt in the NT hash while they were at it fixing the probles with the LM hash. NT dates can't represent anything in prehistory (which can be useful sometimes). Why the hell are Windows CE passwords stored by xoring with "SUSAGEP" instead of some real security measure or just plaintext?
I've never done any MFC coding, so I don't know about any of thier other design decissions, but I can imagine that a lot of thier other stuff is equally flawed. These are exposed design flaws, not coding flaws. We all make coding mistakes, MS made some HUGE security mistakes that they should have known were mistakes at the time. Crypt passwords have been around since the 70s. For most users' passwords, even the improved NT hash is less secure than crypt. (ASCII passwrds shorter than 9 characters). md5 paswords on *NIX aresuperior in all cases to NT hash passwords. I'm sure there are plenty of other areas where thier design mistakes can only be accounted for by complete ignorance of previous research AND an extreme lack of thinking things through. (Either that or they intnetionally made thiersystems weak, which I don't believe.)
Thier encrypted filesystem is a complete waste as long as both the LM and NT hashes are stored on the filesystm. As long as the user has an all-ASCII password, the filesystem encryption gets weakened to about 37-bit encryption (even with 14-character psswords) due to the password file being so crackable.
I have and Indy, and I actually like the WM. The first UNIX I ever used was IRIX, and the WM gives me that old nostalgic feeling. XFS is also nice.
However, ssh, gzip,/dev/random, and a few other nice modern things would be nice defaults to have on the machine.
I am biased b/c the machine was poorly configured when I got it. There was no "/root" and root was homed at "/". SSH wasn't installed. I reconfigured the box to use DHCP, but for some reason nslookup and traceroute can do DNS lookups on www.yahoo.com, but telnet and netscape cannot. I am baffled beyond belief.
I know this is just a point of personal prefence, but I prefer user homes to be in/home instead of/usr/people/. Having/usr/bin and/usr/sbin merely as symlinks to/bin and/sbin also bothers my aesthetic sense. Of course I realize that I'll get used to these quirks in time, just like any other *NIX's quirks.
The hardware is nice, really nice. If I could buy a dual 600 HMz MIPS machine for the same cost as a P4 3 GHz machine, I'd go for the MIPS box.
Part of me would really like to hunt down some IRIX install media and give it a second chance, if anyone knows where I could find such. However, IRIX certainly seems to have more than its share of crustiness.
You're still probably getting less radiation from your case than a wireless ethernet card puts out.
OTOH, there's no such thing as too much caution when you're talking about the baby beans. I'd put my case back together if I were you, or else get metal boxers.:-)
Umm.. the V2 didn't use regenerative cooling but instead tried to keep a thin film of liquid fuel coating the combustion chamber for evapoative cooling. Sometimes they got hot spots and the film dissapeared in a spot, resulting in cooling loss at the hot spot. They had some problems with burning/melting holes in combustion chambers.
Almost all modern liquid fuel engines use regenerative cooling (a technology developed by amateurs in the US, IRRC).
On the other hand, the V2s used pendular integrating gyroscopic acceleromiters (PIGAs) to shut off the fuel supply once the V2 hit a certain velocity. (One nice thing about PIGAs is you can put a counter on one of the bearings to irectly measure velocity instead of having to integrate acceleration yourself.) PIGAs are still used the US MX ICBMs. A couple of summers ago I worked on some replacement technology, but PIGAs are still the most accurate acceleromiters that can withstand the hundreds of Gs encountered on rentry. (They're also pretty resistant to EMP and radiation degredation from being stored long term near a sphere of plutonium.)
BTW, if you should ever fire electrolytic capicitors out of a 105 mm howitzer, be aware that thier capaitence will go out of spec before they leave the barrel and not get back into spec for a few days afterward.
Yes, at somewhere around 2.4 to 2.5 GHz your system will be putting out microwaves identical to those produced in your microwave oven. However, the power levels are really low.
BTW, your case is already shielded. Look at older Macintosh computers: some of them have plastic cases with aluminum paint on the inside for shielding. Sure, I think the iMac and other clear cases are probably poorly shielded, but for the most part computer cases are somewhat shielded. In any case, your wireless Ethernet card puts out much higher levels of microwave radation.
Also, the article doesn't mention the contingency where a break-in occurs because of a software/hardware issue for which there is no released technical solution (i.e. anyone else who has software X would be susceptible to the same type of break-in). This is not good."
It's almost never in the public's best interest to hide vulnerabilities from them, even if there's no solution. If one person has exploited one system, there are almost certainly other victims and the numbers will almost certainly continue to grow. Most are probably undetected.
Even if there is no fix out there, it gives people the option to reevaluate the need to run the system, and also consider switching solutions/vendors. The "bad guys" are going to know if you say somethign or not, while telling all of the innocent bystanders lets at least some of them protect themselves.
As others have pointed out, the term is "unlawful combatant" (combatant not sactioned by any recognized political state), and Bush didn't make the term up. Also, non-uniformed soldiers are subject to many fewer rigts under the Genieva conventions. (Do non-uniformed soldiers have any Genieva convention rights?)
If you send paratroops in dressed as civilians and force the military to go after people that look like thier own people (and greatly increase the chances of civilian casualties), you don't deserve the same rights as common soldiers.
If you buy a silo home, make sure you contact the Russians and the Chinese and have them un-target your home. I'm also pretty sure that the "fail-safe" mode for military blast doors is to close and never open again. If something in my house breaks, I want to be able to get out of the basement. Your tastes may differ.
It would seem to me that NGPT could be modified easily to run on an NPTL kernel. In any case, I don't see why the o(1) scheduler and 0(1) kernel thread creation code woouldn't be worked into the 2.6 kernels. As far as which Linus likes better, my guess is NPTL, as it drastically improves kernel performance. Linus has shown a willingness to make drastic changes even in a production kernel if he feels the performance gains are substancial. I would guess that (most if not all of) the NPTL kernel mods will make it into Linus's tree. In the end people will go with Linus's decission, so it really comes down to who convinces Linus.
I'd personally like to see the NPTL kernel mods with the NGPT libraries. This would seem to provide the most forward-looking approach, as it offers lots of scalability and flexability.
I personally can't wait for the 2.6 kernel, whichever model wins. Java apps are nice, but they tend to use way too many threads. I really don't know why a select() wasnn't present in the beginning for a langugae designed to be used in a networing environment. Oh well.
Re:my electronic wallet
on
Secure PDAs
·
· Score: 2
There are several different authentication/encryption schemes for GSM cell phones. The most secure of which require a work factor of somewhere in the neighborhood of 2^40 to 2^44 to crack. That translates (the last simulations I did were on a PII 350 using an unoptimized RC6 implementation in C) into cracking time being measured in weeks. (Almost definately less than half a year.) Cellphones aren't really secure enough to ue as wallets.
Really what you want are cryptographic certificates with at least 1024-bit (preferably 2048-bit) signature keys if you're going to be buying stuff. These "secure" PDAs don't really offer much over regular PDAs (with IPSEC-enabled bluetooth) for use as digital wallets. It all depends on the wallet software on the PDA.
I think I may have read something about a faster way to break the GSM crypto, but 2^40 to 2^44 are the estimates for Ross Andersen's original attack, IIRC.
To see how limiting it really is, consider the frequent and often justified claim of Unix command line addicts that GUI's offer them no extra capabilities.
I agree that GUIs are wonderful things, but technically most OS CLIs are Turing complete. It's all a question of difficulty. I think I agree with this point, but you stated it in a false way. It harmful in many circumstances to deny the utility of new paradigms. This is the point I thinkyou were trying to make, but stated improperly.
1. Separation -- or not -- of data and code is a technical issue. The existence of that issue should be invisible to the user. It isn't, because we force users to live in a world that partitions data from applications from operating systems. We force users to play by the rules of the OS, rather than force the OS to play by the rules of the user.
2. Java and Flash aren't especially innovative. One is a traditional programming languge and the other is an overblown graphics package. Users don't care what language someone used to write their software, anymore than drivers care what kind of forge smelted the metal that is in their car. The fact that Flash allows web designers to put moving graphics on their sites is interesting, but brings no new capabilities to the user.
3. "Hashbang" paths in Unix apply only to scripts. But, you can't really be asserting that UNIX shells represent an efective interface paradigm for users? In any case, they depend on the user understanding the same 30-year-old segregation of "data" into "files" that is the problem in the first place.
You saw three of my statements but failed to synthesize them. My point is that the web browser and the UNIX hashbangpaths already offer a way to bridge the data-code barrier. Make all of your data files begin with hasbang paths. Modify all of the interpreters to not puke on a leading hashbang path. Or use a web browser. My point is that these problems are not new, solutions not revolutionary, and we have current ways of solving these problems that aren't being used b/c this new amazing paradigm isn't universally better. We've tried it and we use it where it suits us, but it isn't a mgaical wonderful cure.
4. I never used the word "interpreter", much less proposed an "uber interpreter". I am, in fact, proposing that the entire traditional OS paradigm is outmoded and limiting.
Well, I thought you were suggesting some magical digital entity or set of entities capable of reading and rendering ("interpreting") all of our data for us. I gave a name to this abstract concept of how you were going to magically bridge the data-code barrier. If you had an idea other and an uberinterpreter, please explain it more clearly.
5. Whatever MS is, or is not, doing with Hotmail, javascript, Outlook macros, etc., has nothing to do with my argument. From where I sit, it seems to have a lot to do with sloppy code.
6. "Stupid users" How often have we seen this perjorative tossed out on Slashdot? That egotistical lie is the usual last refuge of developers who can't be bothered to think about how people actually ue computers. If software is hard to use, it isn't the user's problem.
Calm down. "stupid users" was a sarcastical remark poking fun at one of the big problems with completely doing away with the code-data abstraction. Users get confused. Theymodify the system when they think they're just looking at data. If you make a distiction between data that permanently alters the system and that which doesn't, you've simply drawn the code-data line in an ever so slightly different place. JVM applets, protected Python execution environments, and CGI scripts currently push those boundaries.
There are many people (most notable Bruce Schneier) that believe tat at least the safe code-unsafe code distinction should not be done away with. The line is currently drawn in a reasonabe place in most users' minds. Most users don'tknow that JVM applets and Flash files are programs (nor should they need to understand), they believe them to be just like any other data. The simplest way to get the point bout safe data and unsafe data to users is calling it "files" and "programs/executables"
The "jumping to conclusions mat" was also a great revolutionary idea, until you took a step back and looked at it for what it was.
data resides in specific files, acted upon by executable code residing in other files.
This can be the case, but as a statement of the way things are constraind, it is completely false.
Look at Java applets or Flash files. Open up a postrscript file sometime. Decompile a PDF. Run a MS Office macro (virus). This is hardly a visionary notion. We've known about such things for a long time. The problem with this magical Utopia you suggest is that it's actually less flexible than what we have now. It also makes it easier for stupid users to shoot themselves in the foot if you want to give them a gnereal-purpose computer. When viewing data and performing tasks are done in the same way, people get confusdand do the wrong thing (macro viruses, for example).
Someone, or something, must remember the association between data in a given file, the action the user wishes to perform with/on that data, and the name of the file that contains the appropriate executable code.
Interface design attempts to reduce the learning curve associated with command line control of an OS by use of small visual clues that reduce the need to memorize or look up file names and command structures.
The Windows, Mac, X, etc., GUI's follow identical paradigms.
You can start files with hashbang paths under *NIX to take care of the "what program deals with this" problem. If you make one uber interpreter, you actually reduce flexability. You seem to claim that your uber interpreter would make UI interfaces more intuitive. This is definately not an intuitively obvious conclusion. MS is now trying to split data and code back apart (macros disabled by default, hotmail disabling JAvaScript, etc.) because it causes problems for users. X does not have one paradigm. You can certainly find 3D and temporal WMs and data browsers for X11.
I'm sorry, but nothing you've said so far is at all profound or new. There's a reason people have been spouting these ideas for a while and there's a reason they've only been partially adopted.
Of course, if you want to limit the computer to being a web kiosk with Fash and Java applets and no possibility of future expansion, then your statements make a little more sense, but they're sill not new or revolutionary. Somebody bunled up the past, painted a newsmile on it, and lied to you. I'm sorry.
Re:Gnutella2 - The real story!
on
Gnutella2?
·
· Score: 2
Interesting... any way to tell if a site is a TopMoxie affiliate? Any way to set the appropriate TopMoxie information for an order without the official TopMoxie client?
Re:A *real* anti-leech/anti attacker system propos
on
Gnutella2?
·
· Score: 2
Ever signed anyone's PGP key? There are 4 levels of trust. (at least with GPG) Check your facts.
Why should they have rights? Why should people who want to destroy us, and take away our livihood, and remove our liberties have any right? I don't understand why anyone would want them to have rights. Let's support everything we can to stop them.
Noce Troll, you got me. Good idea. If we take away thier right to a torture-free interrogation, we'll find that nearly 100% of the accused criminals confess to their crimes and we can execute them there in the interogation room.
There are reasons you can't take away any of someone's rights until they're convicted by a jury.
Oh, and it's a slippery slope. One day accused terrorists are held for just a month or two without being charged, a few years later they sodomize you until you confess to driving under the influence back in 1973, you dirty scum of a degenerate human you.
Unless you look, most of OSS's most innovative stuffis eiterh half hidden, or elseso pervasive that you forget it's there.
Did someone say something about nothing new comming from the OSS community? It's easy to point at a handful of things and say there's no innovation going on and then forget that if you do the same thing with MS you're stuck looking at WinME, Explorer (not IE, Explorer), Word, and Solitaire. There's a lot of OSS that has become so common that it may have passed below your radar. Pray tell, which non-Free products are Perl, PHP, Python, Ruby, Ocaml, Apache, Zope, SELinux, TrustedBSD, and L4-Hazelnut "exact functional coppies" of? I still don't see Microsoft or Sun's mandatory access controls.
I agree that the OSS community sometimes does things that give the impression that all of the OSS projects are cheap ripoffs. However, I think that at least in terms of operating systems and languages, you'll see that OSS leads the pack in innovation. (No, I don't consider the JVM or the CLR at all innovative. Dis is an innovative non-Free virtual machine, but it's the only one I've seen.)
Oh, and I have an IRIX box. It's a poor excuse for a modern *NIX. (No, I'm not just being a Linux fanboy, Solaris, *BSD, etc. are great *NIXes in thier own ways. (Even Solaris x86). IRIX's only redeaming feature is that it's pretty and I love the hardware.) As soon as I port the code that's on there, it's getting Debianized.
For the record, I'd also like to point out that both MS and Apple's default window managers don't compare favorablywith many of the X11 WMs out there, and it's highly non-trvial to change window managers. (Running X11 doesn't work with most of thier programs, so that doesn't count. Third party WMs for MS OSes suffer stability problems, appearently stemming from an insufficiently reverse-engineered API.)
Re:Proper computing solution superior
on
Indecision 2002
·
· Score: 2
Ron Rivest (same MIT Prof. who created md4/md5 rc2 rc4 rc5/rc6 and co-discovered RSA) had some interesting ideas in a votng system called "Frogs". (It was supposedly named that b/c they found some neat clipart for thier slides.) The basic idea is that you have some cheap proms (maybe with some cheap 8-bit CPUs) the come embedded in a plastic card that's designed tobe seperated into two halves and designed in such a way that modifying the contents after the "Frog" has been split in half is obvious. There's a public/private signing key pair on each Frog. You can have whatever fancy proprietary voting machine you want with closed source and 4 million lines of GUI code to write your preferences to the Frog. Companies get to have thier proprietary solution and keep thier monopolies on voting systems. After your preferences are written to the Frog, you need to go and putyour Frog in a minimilistic, open-source, super-tamper-proof machine that will read your vote to you. (It's probably just ugly terminal text, but it lets you know that the proprietary machine set your vote the way you wanted.) If you like what the open-source machine tells you, you hita button and it performs an electronic signature on your vote and securely overwrites the private key, then cut the Frog in half for you. One half contains your vote and the other contains information that can verify that you voted (but can't be linked to your vote, which is on the other half of the Frog) one half of the Frog goes in one ballot box and the other half in another. For efficiency, you probably want the open-source box to keep count of votes,but note that the Frogs can be counted and recounted just like paper ballots. (Except you don't having haging chads or crooked re-counters with pieces of pencil lead under thier thumbnails to make votes invalid.)
Note that there are all kinds of interesting encryption schemes that can be useful in voting. There's a public key system with the property that multiplying the ciphertexts together has the effect of adding the plaintexts. (This can be used to keep vote counts without being able to read the count. If the private keys were broken up and shared among several officials and the voting machines were randomly permuted, this would prevent officials from easily being able to "malfunction" voting machines from selected districts.) There are several ways of doing threshold encryption where there'sone public key and n private keys and you need m of the n private keys (presumbly given to election officials and the heads of the major parties) working together to decrypt anything encrypted with the public key. The same things can be used for signature keys. This way each Frog public key can be signed by a bunch of mutually distrusting head-honchos.
Of course, after the election you need to account for all of the unused Frogs to prevent vote tampering. If these things were used for every election in the US, you could probaby get 50 or more per dollar due to economies of scale. Also note that due to the elctronic signature and the private key being destroyed, you don't need the Frogs to be terribly temper-resistant.
Which PRNG? Somone replied to one of my other posts, saying something about m68k assembly and squaring of a 128-bit number. I took this to mean a quadratic residue generator.
Blum-Blum-Shub would be vulnerable with only a 128-bit modulus. So it seems that either his company didn't know what they were doing, or he was mistaken about the PRNG. (The person claimed to work on other parts of the code, but to have known about the PRNG.)
Slashdot Mirror
Now, it wouldn't surprise me if she used diffential cryptanalysis (DES is known to be quite weak against diffentiacryptanalsis) to do a lot of precomputation to make cracking crypt (whic is based on DES) passwords much faster. Big deal. Anyone still using crypt passwords deserves to get thier passwords compromised.
There are at east two Open-source .NET implementations in the works One is caled Mono, and I forget the name of the other. Mono has something like 95% of the .NET classes implemented and tested. When the bug reports start comming in, who do you think is going to patch faster?
Okay, so now what's the real reason you're staying with Lose32?
On my RH server, I have it set up every 6 hours to do an up2date followed by an autoupdate. I'm out of sync with the official website on average 3 hours. Granted, it's not a high-traffic site, so I don't have to worry too much even if updates do go awry.
If a user-space app crashes your OS (and a fork bomb brining it to a crawl doesn't truly count as a crash), there's something wrong with the OS. It's a design or implementation flaw somewhere.
It's really hard to administer Linux so poorly that it has stability problems. I've only had Linux crash for two reasons, both being hardware failures. (And when my HD locked up, it didn't even really crash, it just started printing out all of these errors that it couldn't save logs to disk.) In order to have non-hardware stability problems under linux, you need to go download an experimental kernel or kernel module. Sometimes you can't configure X11 and can't get X up and running, but the system still runs. Netscape isn't stable, but there are plenty of stable browsers out there.
I challenge you to find an app that can crash Debian-stable from an unprivledged account. Tell you what, I'm running Debian-testing/unstable. find a program that'll crsh my box from an unprivledged account. Here's one for WinNT/200/XP :
int main() { while(1){ printf("\t\b\b");} return 0;}
Try running it from the command line. (You'll need to include a header file or two, and you may need cygwin to compile it as written.) In NT and 2000, it'll BSOD. In XP they "fixed" the problem by having it autmatically reboot instead of blue-screening. It's a buffer unerflow flaw in the DOS emulation. It believes the DOS emulator is a vitalpart of the system, so it freaks out when it's forced to kill the DOS emulator. Instead of just restarting the DOS emulator and letting all of your DOS apps die, it immediately kills all of your apps and BSODs or restarts. NT 4.0 gets no more bug fixes, so it's a permanent bug in NT 4.0.
Ehh... the best firgter pilots can take 10 Gs for a few seconds before passing out (with G suits). Those guys in the famous rocket sled experiments took many more Gs for fractions of a second.
Note that I was talking about peak forces on nuclear warheads. Yes, if we made piloted nuclear missles, we'd need to give them more gentle flight paths.
When was the last time you heard a kidsay "I want to be a nuclear missle pilot when I grow up, just like you daddy"? There are several reasons we don't put cockpits on ICBMs. :-P
Perhaps the warheads need more robust guidance since they are ocassionally dropped. (You think I'm joking. I worked with a guy that did the simulations one time a guy dropped a trident warhead off a forklift to let them know if it was still accurate. They gave him all the info they had on how it was dropped and he ran a bunch of fea simulations. I talked to him while the simulation were running, and never asked later if he said to put the warhead back into sevice. I didn't want to know.) Guidance is really interesting stuff. I didn't really have any moral objections, but a few of my friends that had been working there for a few years started having objections, and it seemed like I might start having the same problems in a few years.
You're right, the several hundred Gs includes the safety factor.
The entire MicrofSoft security team should be shot for using the LM hash. They should be shot again for not having a salt in the NT hash while they were at it fixing the probles with the LM hash. NT dates can't represent anything in prehistory (which can be useful sometimes). Why the hell are Windows CE passwords stored by xoring with "SUSAGEP" instead of some real security measure or just plaintext?
I've never done any MFC coding, so I don't know about any of thier other design decissions, but I can imagine that a lot of thier other stuff is equally flawed. These are exposed design flaws, not coding flaws. We all make coding mistakes, MS made some HUGE security mistakes that they should have known were mistakes at the time. Crypt passwords have been around since the 70s. For most users' passwords, even the improved NT hash is less secure than crypt. (ASCII passwrds shorter than 9 characters). md5 paswords on *NIX aresuperior in all cases to NT hash passwords. I'm sure there are plenty of other areas where thier design mistakes can only be accounted for by complete ignorance of previous research AND an extreme lack of thinking things through. (Either that or they intnetionally made thiersystems weak, which I don't believe.)
Thier encrypted filesystem is a complete waste as long as both the LM and NT hashes are stored on the filesystm. As long as the user has an all-ASCII password, the filesystem encryption gets weakened to about 37-bit encryption (even with 14-character psswords) due to the password file being so crackable.
However, ssh, gzip, /dev/random, and a few other nice modern things would be nice defaults to have on the machine.
I am biased b/c the machine was poorly configured when I got it. There was no "/root" and root was homed at "/". SSH wasn't installed. I reconfigured the box to use DHCP, but for some reason nslookup and traceroute can do DNS lookups on www.yahoo.com, but telnet and netscape cannot. I am baffled beyond belief.
I know this is just a point of personal prefence, but I prefer user homes to be in /home instead of /usr/people/. Having /usr/bin and /usr/sbin merely as symlinks to /bin and /sbin also bothers my aesthetic sense. Of course I realize that I'll get used to these quirks in time, just like any other *NIX's quirks.
The hardware is nice, really nice. If I could buy a dual 600 HMz MIPS machine for the same cost as a P4 3 GHz machine, I'd go for the MIPS box.
Part of me would really like to hunt down some IRIX install media and give it a second chance, if anyone knows where I could find such. However, IRIX certainly seems to have more than its share of crustiness.
OTOH, there's no such thing as too much caution when you're talking about the baby beans. I'd put my case back together if I were you, or else get metal boxers. :-)
Almost all modern liquid fuel engines use regenerative cooling (a technology developed by amateurs in the US, IRRC).
On the other hand, the V2s used pendular integrating gyroscopic acceleromiters (PIGAs) to shut off the fuel supply once the V2 hit a certain velocity. (One nice thing about PIGAs is you can put a counter on one of the bearings to irectly measure velocity instead of having to integrate acceleration yourself.) PIGAs are still used the US MX ICBMs. A couple of summers ago I worked on some replacement technology, but PIGAs are still the most accurate acceleromiters that can withstand the hundreds of Gs encountered on rentry. (They're also pretty resistant to EMP and radiation degredation from being stored long term near a sphere of plutonium.)
BTW, if you should ever fire electrolytic capicitors out of a 105 mm howitzer, be aware that thier capaitence will go out of spec before they leave the barrel and not get back into spec for a few days afterward.
BTW, your case is already shielded. Look at older Macintosh computers: some of them have plastic cases with aluminum paint on the inside for shielding. Sure, I think the iMac and other clear cases are probably poorly shielded, but for the most part computer cases are somewhat shielded. In any case, your wireless Ethernet card puts out much higher levels of microwave radation.
It's almost never in the public's best interest to hide vulnerabilities from them, even if there's no solution. If one person has exploited one system, there are almost certainly other victims and the numbers will almost certainly continue to grow. Most are probably undetected.
Even if there is no fix out there, it gives people the option to reevaluate the need to run the system, and also consider switching solutions/vendors. The "bad guys" are going to know if you say somethign or not, while telling all of the innocent bystanders lets at least some of them protect themselves.
If you send paratroops in dressed as civilians and force the military to go after people that look like thier own people (and greatly increase the chances of civilian casualties), you don't deserve the same rights as common soldiers.
Check those addresses... that's 3 /24 subnets for MS and 2 /24 subnets for timewarner.
If you buy a silo home, make sure you contact the Russians and the Chinese and have them un-target your home. I'm also pretty sure that the "fail-safe" mode for military blast doors is to close and never open again. If something in my house breaks, I want to be able to get out of the basement. Your tastes may differ.
I'd personally like to see the NPTL kernel mods with the NGPT libraries. This would seem to provide the most forward-looking approach, as it offers lots of scalability and flexability.
I personally can't wait for the 2.6 kernel, whichever model wins. Java apps are nice, but they tend to use way too many threads. I really don't know why a select() wasnn't present in the beginning for a langugae designed to be used in a networing environment. Oh well.
Really what you want are cryptographic certificates with at least 1024-bit (preferably 2048-bit) signature keys if you're going to be buying stuff. These "secure" PDAs don't really offer much over regular PDAs (with IPSEC-enabled bluetooth) for use as digital wallets. It all depends on the wallet software on the PDA.
I think I may have read something about a faster way to break the GSM crypto, but 2^40 to 2^44 are the estimates for Ross Andersen's original attack, IIRC.
I agree that GUIs are wonderful things, but technically most OS CLIs are Turing complete. It's all a question of difficulty. I think I agree with this point, but you stated it in a false way. It harmful in many circumstances to deny the utility of new paradigms. This is the point I thinkyou were trying to make, but stated improperly.
You saw three of my statements but failed to synthesize them. My point is that the web browser and the UNIX hashbangpaths already offer a way to bridge the data-code barrier. Make all of your data files begin with hasbang paths. Modify all of the interpreters to not puke on a leading hashbang path. Or use a web browser. My point is that these problems are not new, solutions not revolutionary, and we have current ways of solving these problems that aren't being used b/c this new amazing paradigm isn't universally better. We've tried it and we use it where it suits us, but it isn't a mgaical wonderful cure.
Well, I thought you were suggesting some magical digital entity or set of entities capable of reading and rendering ("interpreting") all of our data for us. I gave a name to this abstract concept of how you were going to magically bridge the data-code barrier. If you had an idea other and an uberinterpreter, please explain it more clearly.
Calm down. "stupid users" was a sarcastical remark poking fun at one of the big problems with completely doing away with the code-data abstraction. Users get confused. Theymodify the system when they think they're just looking at data. If you make a distiction between data that permanently alters the system and that which doesn't, you've simply drawn the code-data line in an ever so slightly different place. JVM applets, protected Python execution environments, and CGI scripts currently push those boundaries.
There are many people (most notable Bruce Schneier) that believe tat at least the safe code-unsafe code distinction should not be done away with. The line is currently drawn in a reasonabe place in most users' minds. Most users don'tknow that JVM applets and Flash files are programs (nor should they need to understand), they believe them to be just like any other data. The simplest way to get the point bout safe data and unsafe data to users is calling it "files" and "programs/executables"
The "jumping to conclusions mat" was also a great revolutionary idea, until you took a step back and looked at it for what it was.
- "Data" and "Code" are separate and inviolable
- data resides in specific files, acted upon by executable code residing in other files.
This can be the case, but as a statement of the way things are constraind, it is completely false.Look at Java applets or Flash files. Open up a postrscript file sometime. Decompile a PDF. Run a MS Office macro (virus). This is hardly a visionary notion. We've known about such things for a long time. The problem with this magical Utopia you suggest is that it's actually less flexible than what we have now. It also makes it easier for stupid users to shoot themselves in the foot if you want to give them a gnereal-purpose computer. When viewing data and performing tasks are done in the same way, people get confusdand do the wrong thing (macro viruses, for example).
You can start files with hashbang paths under *NIX to take care of the "what program deals with this" problem. If you make one uber interpreter, you actually reduce flexability. You seem to claim that your uber interpreter would make UI interfaces more intuitive. This is definately not an intuitively obvious conclusion. MS is now trying to split data and code back apart (macros disabled by default, hotmail disabling JAvaScript, etc.) because it causes problems for users. X does not have one paradigm. You can certainly find 3D and temporal WMs and data browsers for X11.I'm sorry, but nothing you've said so far is at all profound or new. There's a reason people have been spouting these ideas for a while and there's a reason they've only been partially adopted.
Of course, if you want to limit the computer to being a web kiosk with Fash and Java applets and no possibility of future expansion, then your statements make a little more sense, but they're sill not new or revolutionary. Somebody bunled up the past, painted a newsmile on it, and lied to you. I'm sorry.
Interesting... any way to tell if a site is a TopMoxie affiliate? Any way to set the appropriate TopMoxie information for an order without the official TopMoxie client?
Ever signed anyone's PGP key? There are 4 levels of trust. (at least with GPG) Check your facts.
Noce Troll, you got me. Good idea. If we take away thier right to a torture-free interrogation, we'll find that nearly 100% of the accused criminals confess to their crimes and we can execute them there in the interogation room.
There are reasons you can't take away any of someone's rights until they're convicted by a jury.
Oh, and it's a slippery slope. One day accused terrorists are held for just a month or two without being charged, a few years later they sodomize you until you confess to driving under the influence back in 1973, you dirty scum of a degenerate human you.
Cough... Emacs, X11... Cough.
Cough... Apache, Zope... Cough..
Cough.. Perl, Python, Ruby, Ocaml, PHP... Cough
Cough... Parrot, Zinc... Cough
Cough.. OpenBSD, SELinux, TurstedBSD, ErOS.. Cough..
Cough...L4 nanokernel, persistant processes, HURD... Cough
Cough.. Gnutella, Freenet.. Cough...
Unless you look, most of OSS's most innovative stuffis eiterh half hidden, or elseso pervasive that you forget it's there.
Did someone say something about nothing new comming from the OSS community? It's easy to point at a handful of things and say there's no innovation going on and then forget that if you do the same thing with MS you're stuck looking at WinME, Explorer (not IE, Explorer), Word, and Solitaire. There's a lot of OSS that has become so common that it may have passed below your radar. Pray tell, which non-Free products are Perl, PHP, Python, Ruby, Ocaml, Apache, Zope, SELinux, TrustedBSD, and L4-Hazelnut "exact functional coppies" of? I still don't see Microsoft or Sun's mandatory access controls.
I agree that the OSS community sometimes does things that give the impression that all of the OSS projects are cheap ripoffs. However, I think that at least in terms of operating systems and languages, you'll see that OSS leads the pack in innovation. (No, I don't consider the JVM or the CLR at all innovative. Dis is an innovative non-Free virtual machine, but it's the only one I've seen.)
Oh, and I have an IRIX box. It's a poor excuse for a modern *NIX. (No, I'm not just being a Linux fanboy, Solaris, *BSD, etc. are great *NIXes in thier own ways. (Even Solaris x86). IRIX's only redeaming feature is that it's pretty and I love the hardware.) As soon as I port the code that's on there, it's getting Debianized.
For the record, I'd also like to point out that both MS and Apple's default window managers don't compare favorablywith many of the X11 WMs out there, and it's highly non-trvial to change window managers. (Running X11 doesn't work with most of thier programs, so that doesn't count. Third party WMs for MS OSes suffer stability problems, appearently stemming from an insufficiently reverse-engineered API.)
Note that there are all kinds of interesting encryption schemes that can be useful in voting. There's a public key system with the property that multiplying the ciphertexts together has the effect of adding the plaintexts. (This can be used to keep vote counts without being able to read the count. If the private keys were broken up and shared among several officials and the voting machines were randomly permuted, this would prevent officials from easily being able to "malfunction" voting machines from selected districts.) There are several ways of doing threshold encryption where there'sone public key and n private keys and you need m of the n private keys (presumbly given to election officials and the heads of the major parties) working together to decrypt anything encrypted with the public key. The same things can be used for signature keys. This way each Frog public key can be signed by a bunch of mutually distrusting head-honchos.
Of course, after the election you need to account for all of the unused Frogs to prevent vote tampering. If these things were used for every election in the US, you could probaby get 50 or more per dollar due to economies of scale. Also note that due to the elctronic signature and the private key being destroyed, you don't need the Frogs to be terribly temper-resistant.
Blum-Blum-Shub would be vulnerable with only a 128-bit modulus. So it seems that either his company didn't know what they were doing, or he was mistaken about the PRNG. (The person claimed to work on other parts of the code, but to have known about the PRNG.)