I don't know of any open source implementations, if that's what you're asking. Usually, it's burned into PROMs anyway, so it's not like you could replace it (I don't know about new Suns or Macs, though, my open firmware experience is all on 32-bit SPARC - I suppose newer machines probably use flash memory for it).
Anyway, that's not really the point. The point is that it is an open, (very well) documented, cross-vendor*, IEEE standardized BIOS. Also, it kicks ass. After I started playing with it on SPARCs, I really wished my x86 machines had it as well. It really is so much nicer to deal with open firmware than an x86 BIOS, those times when you do have to deal with a BIOS at all.
* This is what makes it (IMO) much more open than, say, OpenVMS.
companies can't rely on conventional security methods to protect themselves from serious employee theft.
If security is really important, #1 rule is to make sure you trust the people who have the important data. Someone did this intentionally, either someone at Valve, or one of their partners. That person should probably not have been hired in the first place. OTOH, I don't know how one would go about security checks for this kind of thing. It's not as easy as govt ones (where what they want to know is 1) are you a spy/subversive/etc and 2) how easy can you be blackmailed by someone who is - between those two it covers 99% of the cases where one would wish to leak stuff). This seems like it was done - well, actually, I really don't understand why anyone would do this, except maybe to really fuck their employer.
Maybe you could enhance that security with encryption of the codebase (you can decrypt the parts you need to change and that's it)
Except that you still need to compile it, so unless you put special decryption stuff in the compiler (or in a preprocessor to it), etc, etc, etc it's not going to do you a whole lot of good.
Or maybe somehow watermark the code to each person in a way not easy to detect -- maybe dynamically change their variable names so they're individual-specific...
Would sure as hell make understanding things hard, though. 'Sure, to do such-and-such just increment a4362h' 'What? Do you mean z2314j?' I don't think this would fly.
And what do you base that on? When is the last time they have secretly snuck in anything to their software that did anything to track you, database you, categorize you, spy on you, download your personal records, view your documents, etc?
If it makes you feel better, just think about unintentional holes. I'm sure you can think of one or two security bugs that have shown up in Microsoft products in these last few years, can't you? NT service packs have been known to introduce bugs in the past, and it's unlikely to believe this won't continue with Windows Update, etc. Just because there are no intentional backdoors doesn't mean it's secure.
I'm seriously hoping that this isn't a paper launch.
Why don't you go go buy one from here or here and let us know?
First, we still don't have a mass market consumer OS for native x86-64
Very true. And some of us just don't care. I wanted benchmarks for GCC and OpenSSL and Postgres, and all they showed was 32-bit Windows apps, which nobody but nobody cares about. Well, life is tough, I guess.
I was mistaken: it's five new instructions. They provide DES and 3DES symmetric cryptography, and SHA-1 message digest functions.
Wow, screwy. I've never heard of any chip that did something like this on an instruction level. I don't know about the key length limitations, but I can tell you that I have distributed 168-bit 3DES for years as part of a crypto library and never heard a peep from anyone related to the export laws (many other people continue to host well-known crypto projects out of the US, as well). I am fairly certain the DES and RSA stuff mentioned in the PDF is full strength (ie at least 2048 bit RSA and 3 key 3DES), as one of the options looks like they basically just include an IBM 4078 (? can never remember the number, that looks right) cryptocard with the system.
If you are concerned about the export laws, there are two factors to consider:
1) It's unlikely that these two new instructions would even count as encryption technology. Unfortunately Google couldn't find me anything about the z/990 extensions, but I rather suspect that if it's just those two codes, they're going to be so low-level as to be almost meaningless. The NSA and etc mostly cares about preventing people from getting their hands on useable applications, rather than the base algorithms - seems they didn't realize when they created the restrictions back in the day, that nobody knows how to make a user-friendly crypto app anyway.
If you could specify what these two instructions did, that would make it a little easier. For example, an instruction to fill a register with random bits, or to compute some special function that would only be useful in implementing multiple precision integers, would be very useful to crypto software, but not considered encryption on it's own.
2) They're extensions - only the latest (still unreleased?) S/390 system supports them, and it's likely that it will take at least 6 months to a year before any software uses these codes. So, implement them, test them, but don't release them until you feel sure that you're safe from the long arm of the fedz (whatever that may take).
Honestly though, the odds of a problem in this case seems nil to me (but after all IANAL).
Gasp. A *nix trojan?!? Everything that slashdot has taught me must be untrue!
As far as I can see, it's not a Trojan at all. Maybe a worm (and maybe not). A Trojan would be, say, me sending you this really cool screensaver (or whatever), and you running it.
And, while you might certainly get screwed by a Trojan, on a Unix system nobody else sharing the system will feel it (unless you ran it as root, in which case I feel very sorry for you, after everyone finds out why their stuff got hosed). Regular user accounts can't fake source addresses or generate weird packets, either.
That said, Unix trojans do exist (for example, the OpenSSH trojan from last (?) year).
found a place selling the 240's for just under $300/ea. The 242's are just over $700/ea from the same place.
That's consistent with what's on pricewatch, too. The price jump between 240 and 242 is pretty amazing - I guess they're having fab problems still (which is hardly a surpise this early in the game).
I'm really wanting a nice x86-64 box, but with my limited budget (read: blew it all on booze), I'll probably wait until sometime this fall.
I had read something to the effect that with GCC, if you compile on an x86-64, it'll make 64-bit binaries..
You can compile an x86 GCC to support x86-64 as well (by passing -32/-64 to pick which one you want to compile for). IIRC by default GCC for x86 won't support x86-64, there is an extra flag to enable it at configure time. So your cross compiler will be an easy job.
Which model are you going for? The 1.8 Ghz ones look _nice_, but at $850 a pop they're a bit pricey still...
Ergo we have enough IP addresses for nanotech devices of 43,600 atoms each, in a human-habitable volume completely covering the land-mass of Earth and extending to fill a volume of space above and below the earth's surface for a full 1 km.
Of course, this doesn't leave any room for the people (or air or water or buildings or...).:) If we assume there is "only" 1 billion nanomachines / cubic centimeter in that space, we have 1000 IP addresses for every machine. Filling Jupiter with nanomachines might still be a problem, but for Earth, Mars, Venus, and their moon(s), we'd be set.
Certainly inter-stellar communications which will be limited to a relatively small number of transmitters will scale up with NATs for quite a while, assuming photon-based communications.
Actually, it's most likely that interplanetary communications will use some other protocol - TCP doesn't scale to the latencies we'd see going to anything further than the Moon. Vinton Cerf has been doing some work on this (IIRC it showed up on/. a while back). I can't find the paper he wrote (which was very interesting, BTW), but if you search for "Cerf IP interplanetary Internet" on Google you'll find a number of references.
So, if there won't be a direct TCP/IP link anyway, you could (maybe), simply re-allocate all of those IP address on each planet - giving every planet/moon system it's own set of 2^128 IP addresses, and then doing NAT over the interplanetary internet protocol. I'm not totally sure that this would work, but I don't see, offhand, any reason why not.
they're intending to verify that the holder of the certificate is doe0128935, which is a very different problem.
True, but still fairly spoofable - how to check, for example, that that certificate request actually came from doe0128935 anyway? I suppose they could modify the AOL client so that when they first log in, it generates a private key and a cert reques and sends it to an AOL CA or something.
But in addition, consider that (according to another post), you can also use a Thawte certificate. I wouldn't be suprised if ANY certificate was accepted, in which case I just go out and issue myself a certificate for doe0128935.
Realistically, replacing a protocol that uses plaintext with one that uses crypto is good. But I wouldn't trust encrypted AIM for planning any revolutions, folks. To quote one of the linked pages:
"AIM encryption goes beyond basic Secure Socket Layers (SSL) encryption" and "Although SSL is widely used, it does not provide the best security over a Public Instant Messaging network."
This is a big WARNING SIGN, especially considering that a) they provide zero details about what they are using (big no-no in the first place), and b) WASTE, the only other AOLish crypto I've taken a look at, had some fairly serious problems (this was not just my asessment - check the cryptography@metzdowd.com archives for a rundown). This is not exactly confidence inspiring.
Lastly, are they seriously suggesting rolling out a full PKI for all AIM users? Again, details are light so I'm not sure this is what they mean, but it does seem to be implied. If so, someone needs to inform them of the harsh realities of PKI. Certs for AOL users wouldn't be too hard, since they already have addresses, CC #s, etc to let them (at least with reasonable probability) check on people's identity. But everybody else - forget it.
but I dont see how Rivest Shamir etc profited from their US patent.
They made a lot. A whole lot. I would guess well into 7 figures, maybe even 8. Between the RSA patent, the DH patent, and a couple of others, RSA DSI got money from each and every commercial user of public key cryptography in the United States for nearly 15 years. That is a LOT of dough, and I suspect as founders, they made some pretty good $$$. Rivest most of all, since he is more actively involved in the company -- Shamir and Adleman have remained mostly in the academic world, but I'm sure they get nice checks in the mail every few months.
Actually, though, RSAREF (which WASTE uses) is under a license that is (very) incompatable with the GPL. Nothing stopping you from distributing the source (assuming you don't mind AOL possibly coming after you), but no binaries.
And, oh, my. Just finished reading the last clasues of the RSAREF license. Looks like WASTE violates those, meaning WASTE isn't legal anyway (at least until/unless someone re-writes it w/o RSAREF).
I don't know where you went to school, but most of my chem classes were equations (responding to other poster saying chem classes taught how to make explosives)
Yeah, so were mine. You ever read about 'exothermic' reactions? Or maybe hear anything about oxidizers? With a half-way decent chemistry book, you can make some fairly powerful explosives, easy. And, like another poster, I also ripped off Mg strips from my HS chem lab.:)
Why? Because only the copyright holder can release software like this. Otherwise the license is void, and you are all doing something illegal by distributing the source.
Absolutely true. But, from my brief glance at the source, it looks like all of the files have GPL notices at the top. Either the unauthorized person was very thorough, or this really was supposed to be GPLed - maybe not released right now, but at some point. But that is hardly proof, and while they cannot revoke the GPL, it's hard to prove either way, unless they name the person who supposedly uploaded it without authorization, and file a $$$ lawsuit against him for IP loss.
Either way, WASTE is at this point not really safe for use. For examples, it uses PCBC encryption (broken), MD5 for authentication (!!!), RSAref (slow + unmaintained + bad RNG), and on Windows it doesn't seem to be seeding the RNG with much of anything (on Unix it reads/dev/urandom, which is fine). The NullSoft guys may have interesting ideas, but it seems like they probably should have asked somebody before implementing the crypto in WASTE.
they ended up with something so complicated that nobody has ever implemented it fully (X.509*)
Indeed X.509 is a terrible standard (trust me, I've implemented... oh, maybe 20-30% of it, which is about as much as anyone ever does, or can stomach). Part of the problem does come from the lower levels (ASN.1 and DER/BER), which X.509 can't really do anything about. For example, most of the ASN.1 string types are truly insane, designed for use with Minitel or S/360 or something even stranger.
OTOH, I wouldn't necessarily agree that SSL/TLS is that fantastic either, because basically TLS is just SSLv3 with some tweaks, and SSLv3 was basically whatever Netscape & Co thought was a good idea at the time, leading to some (IMO) fairly bone-headed mistakes. Same with SSH - the IETF standard SSH is quite different from the old ssh.com's SSHv2 implementations.
The really good standards (and, as I've always understood it, the typical IETF way of doing RFCs), is to say "We want something to do X", and let three or four really good independent groups take a crack at it. Then pick the best one, stealing any good ideas from the others along the way.
Hm? Moneydance is a personal finance manager. One of its features is online banking, but that's not all it does.
I know, I know! The point I was making is they are talking like this is the first time a Linux user has been able to do online banking, which is quite plainly wrong.
How about Mozilla? I've been doing all of my banking, and paying my credit card bills, over HTTP/SSL for ~2 years now. Which is exceptionally nice as my bank is a local credit union about 3000 miles away from my current place of residence.
If online banking with Linux is causing people problems, I would highly recommend finding a bank that supports doing this kind of thing over the web.
1) "win95 did not have a multithreaded 'kernel', it's ring-0 code was not reentrant. but this does not mean that 32-bit applications and the set of win16 apps could not be preempted if they were in user code."
2 "it wasn't until the preempt kernel patch that linux operated in precisely that same manner - threads in the kernel would spin before continuing."
If the Win95 kernel was not reentrent, how could it possibly do what Linux does with the preempt patches? The whole point of the Linux patches is that multiple syscalls can be in the process of being done at once. Preemptive multitasking ala Win95 has been around in Unix kernels forever.
Having a lit cigarette in hand, whether or not it contains nicotine, is not going to do much to ween off the psychological addiction.
Actually, this might work for me. My main psychological addition when it comes to smoking is the act of smoking itself. When I don't have any money to buy smokes, I'll smoke cloves or whatever, and feel like I got my fix.
Obviously, 99% of the stuff NSA does is not published publicly. However, there are a few things you can look at. First, as others have noted, NSA has a lot of patents. Secondly, there are a few NSA designed algorithms which have become well known publicly, including: DES, Skipjack, DSA, SHA-1, SHA-256, and SHA-512 (you can find information about all of these on NIST's web page). However, keep the following things in mind: In all cases, the NSA knew that these algorithms would be public, and so they almost certainly didn't use their best tricks in designing the algorithms. Also, to the best that anyone knows, the military still mostly uses stream ciphers. Nobody has ever seen an NSA designed stream cipher.
The only currency in the Open Source market is recognition and peer review.
I agree. But his 'name' is just as valid for peer review purposes as anyone elses. In fact more than most, since he uses PGP signatures to bind his work to that name. The fact that the name he uses isn't the same as the name he uses in the real world doesn't affect the peer review process.
I would add that there are one or two reasonably well known open source developers who I strong suspect are psuedonyms, but since I'm not totally sure I don't want to name names.
Slashdot Mirror
Is it Free as in Freedom? Or open like OpenVMS?
I don't know of any open source implementations, if that's what you're asking. Usually, it's burned into PROMs anyway, so it's not like you could replace it (I don't know about new Suns or Macs, though, my open firmware experience is all on 32-bit SPARC - I suppose newer machines probably use flash memory for it).
Anyway, that's not really the point. The point is that it is an open, (very well) documented, cross-vendor*, IEEE standardized BIOS. Also, it kicks ass. After I started playing with it on SPARCs, I really wished my x86 machines had it as well. It really is so much nicer to deal with open firmware than an x86 BIOS, those times when you do have to deal with a BIOS at all.
* This is what makes it (IMO) much more open than, say, OpenVMS.
companies can't rely on conventional security methods to protect themselves from serious employee theft.
If security is really important, #1 rule is to make sure you trust the people who have the important data. Someone did this intentionally, either someone at Valve, or one of their partners. That person should probably not have been hired in the first place. OTOH, I don't know how one would go about security checks for this kind of thing. It's not as easy as govt ones (where what they want to know is 1) are you a spy/subversive/etc and 2) how easy can you be blackmailed by someone who is - between those two it covers 99% of the cases where one would wish to leak stuff). This seems like it was done - well, actually, I really don't understand why anyone would do this, except maybe to really fuck their employer.
Maybe you could enhance that security with encryption of the codebase (you can decrypt the parts you need to change and that's it)
Except that you still need to compile it, so unless you put special decryption stuff in the compiler (or in a preprocessor to it), etc, etc, etc it's not going to do you a whole lot of good.
Or maybe somehow watermark the code to each person in a way not easy to detect -- maybe dynamically change their variable names so they're individual-specific...
Would sure as hell make understanding things hard, though. 'Sure, to do such-and-such just increment a4362h' 'What? Do you mean z2314j?' I don't think this would fly.
And what do you base that on? When is the last time they have secretly snuck in anything to their software that did anything to track you, database you, categorize you, spy on you, download your personal records, view your documents, etc?
If it makes you feel better, just think about unintentional holes. I'm sure you can think of one or two security bugs that have shown up in Microsoft products in these last few years, can't you? NT service packs have been known to introduce bugs in the past, and it's unlikely to believe this won't continue with Windows Update, etc. Just because there are no intentional backdoors doesn't mean it's secure.
I'm seriously hoping that this isn't a paper launch.
Why don't you go go buy one from here or here and let us know?
First, we still don't have a mass market consumer OS for native x86-64
Very true. And some of us just don't care. I wanted benchmarks for GCC and OpenSSL and Postgres, and all they showed was 32-bit Windows apps, which nobody but nobody cares about. Well, life is tough, I guess.
I was mistaken: it's five new instructions. They provide DES and 3DES symmetric cryptography, and SHA-1 message digest functions.
Wow, screwy. I've never heard of any chip that did something like this on an instruction level. I don't know about the key length limitations, but I can tell you that I have distributed 168-bit 3DES for years as part of a crypto library and never heard a peep from anyone related to the export laws (many other people continue to host well-known crypto projects out of the US, as well). I am fairly certain the DES and RSA stuff mentioned in the PDF is full strength (ie at least 2048 bit RSA and 3 key 3DES), as one of the options looks like they basically just include an IBM 4078 (? can never remember the number, that looks right) cryptocard with the system.
If you are concerned about the export laws, there are two factors to consider:
1) It's unlikely that these two new instructions would even count as encryption technology. Unfortunately Google couldn't find me anything about the z/990 extensions, but I rather suspect that if it's just those two codes, they're going to be so low-level as to be almost meaningless. The NSA and etc mostly cares about preventing people from getting their hands on useable applications, rather than the base algorithms - seems they didn't realize when they created the restrictions back in the day, that nobody knows how to make a user-friendly crypto app anyway.
If you could specify what these two instructions did, that would make it a little easier. For example, an instruction to fill a register with random bits, or to compute some special function that would only be useful in implementing multiple precision integers, would be very useful to crypto software, but not considered encryption on it's own.
2) They're extensions - only the latest (still unreleased?) S/390 system supports them, and it's likely that it will take at least 6 months to a year before any software uses these codes. So, implement them, test them, but don't release them until you feel sure that you're safe from the long arm of the fedz (whatever that may take).
Honestly though, the odds of a problem in this case seems nil to me (but after all IANAL).
Gasp. A *nix trojan?!? Everything that slashdot has taught me must be untrue!
As far as I can see, it's not a Trojan at all. Maybe a worm (and maybe not). A Trojan would be, say, me sending you this really cool screensaver (or whatever), and you running it.
And, while you might certainly get screwed by a Trojan, on a Unix system nobody else sharing the system will feel it (unless you ran it as root, in which case I feel very sorry for you, after everyone finds out why their stuff got hosed). Regular user accounts can't fake source addresses or generate weird packets, either.
That said, Unix trojans do exist (for example, the OpenSSH trojan from last (?) year).
found a place selling the 240's for just under $300/ea. The 242's are just over $700/ea from the same place.
:)
That's consistent with what's on pricewatch, too. The price jump between 240 and 242 is pretty amazing - I guess they're having fab problems still (which is hardly a surpise this early in the game).
I'm really wanting a nice x86-64 box, but with my limited budget (read: blew it all on booze), I'll probably wait until sometime this fall.
Have fun with new box!
I had read something to the effect that with GCC, if you compile on an x86-64, it'll make 64-bit binaries..
You can compile an x86 GCC to support x86-64 as well (by passing -32/-64 to pick which one you want to compile for). IIRC by default GCC for x86 won't support x86-64, there is an extra flag to enable it at configure time. So your cross compiler will be an easy job.
Which model are you going for? The 1.8 Ghz ones look _nice_, but at $850 a pop they're a bit pricey still...
Ergo we have enough IP addresses for nanotech devices of 43,600 atoms each, in a human-habitable volume completely covering the land-mass of Earth and extending to fill a volume of space above and below the earth's surface for a full 1 km.
:)
/. a while back). I can't find the paper he wrote (which was very interesting, BTW), but if you search for "Cerf IP interplanetary Internet" on Google you'll find a number of references.
Of course, this doesn't leave any room for the people (or air or water or buildings or...).
If we assume there is "only" 1 billion nanomachines / cubic centimeter in that space, we have 1000 IP addresses for every machine. Filling Jupiter with nanomachines might still be a problem, but for Earth, Mars, Venus, and their moon(s), we'd be set.
Certainly inter-stellar communications which will be limited to a relatively small number of transmitters will scale up with NATs for quite a while, assuming photon-based communications.
Actually, it's most likely that interplanetary communications will use some other protocol - TCP doesn't scale to the latencies we'd see going to anything further than the Moon. Vinton Cerf has been doing some work on this (IIRC it showed up on
So, if there won't be a direct TCP/IP link anyway, you could (maybe), simply re-allocate all of those IP address on each planet - giving every planet/moon system it's own set of 2^128 IP addresses, and then doing NAT over the interplanetary internet protocol. I'm not totally sure that this would work, but I don't see, offhand, any reason why not.
they're intending to verify that the holder of the certificate is doe0128935, which is a very different problem.
True, but still fairly spoofable - how to check, for example, that that certificate request actually came from doe0128935 anyway? I suppose they could modify the AOL client so that when they first log in, it generates a private key and a cert reques and sends it to an AOL CA or something.
But in addition, consider that (according to another post), you can also use a Thawte certificate. I wouldn't be suprised if ANY certificate was accepted, in which case I just go out and issue myself a certificate for doe0128935.
Realistically, replacing a protocol that uses plaintext with one that uses crypto is good. But I wouldn't trust encrypted AIM for planning any revolutions, folks. To quote one of the linked pages:
"AIM encryption goes beyond basic Secure Socket Layers (SSL) encryption" and "Although SSL is widely used, it does not provide the best security over a Public Instant Messaging network."
This is a big WARNING SIGN, especially considering that a) they provide zero details about what they are using (big no-no in the first place), and b) WASTE, the only other AOLish crypto I've taken a look at, had some fairly serious problems (this was not just my asessment - check the cryptography@metzdowd.com archives for a rundown). This is not exactly confidence inspiring.
Lastly, are they seriously suggesting rolling out a full PKI for all AIM users? Again, details are light so I'm not sure this is what they mean, but it does seem to be implied. If so, someone needs to inform them of the harsh realities of PKI. Certs for AOL users wouldn't be too hard, since they already have addresses, CC #s, etc to let them (at least with reasonable probability) check on people's identity. But everybody else - forget it.
though ESR significantly enhanced the whole effort during the mid-80's and published as a book.
Actually, according to the Jargon file itself, it was GLS who did the editing for the first book: (see here).
but I dont see how Rivest Shamir etc profited from their US patent.
They made a lot. A whole lot. I would guess well into 7 figures, maybe even 8. Between the RSA patent, the DH patent, and a couple of others, RSA DSI got money from each and every commercial user of public key cryptography in the United States for nearly 15 years. That is a LOT of dough, and I suspect as founders, they made some pretty good $$$. Rivest most of all, since he is more actively involved in the company -- Shamir and Adleman have remained mostly in the academic world, but I'm sure they get nice checks in the mail every few months.
as long as it's under the GPL
Actually, though, RSAREF (which WASTE uses) is under a license that is (very) incompatable with the GPL. Nothing stopping you from distributing the source (assuming you don't mind AOL possibly coming after you), but no binaries.
And, oh, my. Just finished reading the last clasues of the RSAREF license. Looks like WASTE violates those, meaning WASTE isn't legal anyway (at least until/unless someone re-writes it w/o RSAREF).
I don't know where you went to school, but most of my chem classes were equations (responding to other poster saying chem classes taught how to make explosives)
:)
Yeah, so were mine. You ever read about 'exothermic' reactions? Or maybe hear anything about oxidizers? With a half-way decent chemistry book, you can make some fairly powerful explosives, easy. And, like another poster, I also ripped off Mg strips from my HS chem lab.
Why? Because only the copyright holder can release software like this. Otherwise the license is void, and you are all doing something illegal by distributing the source.
/dev/urandom, which is fine). The NullSoft guys may have interesting ideas, but it seems like they probably should have asked somebody before implementing the crypto in WASTE.
Absolutely true. But, from my brief glance at the source, it looks like all of the files have GPL notices at the top. Either the unauthorized person was very thorough, or this really was supposed to be GPLed - maybe not released right now, but at some point. But that is hardly proof, and while they cannot revoke the GPL, it's hard to prove either way, unless they name the person who supposedly uploaded it without authorization, and file a $$$ lawsuit against him for IP loss.
Either way, WASTE is at this point not really safe for use. For examples, it uses PCBC encryption (broken), MD5 for authentication (!!!), RSAref (slow + unmaintained + bad RNG), and on Windows it doesn't seem to be seeding the RNG with much of anything (on Unix it reads
they ended up with something so complicated that nobody has ever implemented it fully (X.509*)
Indeed X.509 is a terrible standard (trust me, I've implemented... oh, maybe 20-30% of it, which is about as much as anyone ever does, or can stomach). Part of the problem does come from the lower levels (ASN.1 and DER/BER), which X.509 can't really do anything about. For example, most of the ASN.1 string types are truly insane, designed for use with Minitel or S/360 or something even stranger.
OTOH, I wouldn't necessarily agree that SSL/TLS is that fantastic either, because basically TLS is just SSLv3 with some tweaks, and SSLv3 was basically whatever Netscape & Co thought was a good idea at the time, leading to some (IMO) fairly bone-headed mistakes. Same with SSH - the IETF standard SSH is quite different from the old ssh.com's SSHv2 implementations.
The really good standards (and, as I've always understood it, the typical IETF way of doing RFCs), is to say "We want something to do X", and let three or four really good independent groups take a crack at it. Then pick the best one, stealing any good ideas from the others along the way.
Hm? Moneydance is a personal finance manager. One of its features is online banking, but that's not all it does.
I know, I know! The point I was making is they are talking like this is the first time a Linux user has been able to do online banking, which is quite plainly wrong.
How about Mozilla? I've been doing all of my banking, and paying my credit card bills, over HTTP/SSL for ~2 years now. Which is exceptionally nice as my bank is a local credit union about 3000 miles away from my current place of residence.
If online banking with Linux is causing people problems, I would highly recommend finding a bank that supports doing this kind of thing over the web.
Wait, confused:
1) "win95 did not have a multithreaded 'kernel', it's ring-0 code was not reentrant. but this does not mean that 32-bit applications and the set of win16 apps could not be preempted if they were in user code."
2 "it wasn't until the preempt kernel patch that linux operated in precisely that same manner - threads in the kernel would spin before continuing."
AFAICT, you're talking about
Win95: Preemtive multitasking
Linux: Preemtive syscalls
If the Win95 kernel was not reentrent, how could it possibly do what Linux does with the preempt patches? The whole point of the Linux patches is that multiple syscalls can be in the process of being done at once. Preemptive multitasking ala Win95 has been around in Unix kernels forever.
Having a lit cigarette in hand, whether or not it contains nicotine, is not going to do much to ween off the psychological addiction.
Actually, this might work for me. My main psychological addition when it comes to smoking is the act of smoking itself. When I don't have any money to buy smokes, I'll smoke cloves or whatever, and feel like I got my fix.
Obviously, 99% of the stuff NSA does is not published publicly. However, there are a few things you can look at. First, as others have noted, NSA has a lot of patents. Secondly, there are a few NSA designed algorithms which have become well known publicly, including: DES, Skipjack, DSA, SHA-1, SHA-256, and SHA-512 (you can find information about all of these on NIST's web page). However, keep the following things in mind: In all cases, the NSA knew that these algorithms would be public, and so they almost certainly didn't use their best tricks in designing the algorithms. Also, to the best that anyone knows, the military still mostly uses stream ciphers. Nobody has ever seen an NSA designed stream cipher.
The only currency in the Open Source market is recognition and peer review.
I agree. But his 'name' is just as valid for peer review purposes as anyone elses. In fact more than most, since he uses PGP signatures to bind his work to that name. The fact that the name he uses isn't the same as the name he uses in the real world doesn't affect the peer review process.
I would add that there are one or two reasonably well known open source developers who I strong suspect are psuedonyms, but since I'm not totally sure I don't want to name names.
Somebody contributes to a significant number of GNU projects yet remains anonymous (and therefore unaccountable.)
Unaccountable how, exactly?