Actually, let's say it's an early version of a tinfoil hat - lacking hat-ness, though it may contain tinfoil.
The extra had obviously heard that photographic film can steal one's soul. The object is a shield to protect the face against this threat.
In any case, no doubt someone else has noted that a cell phone wouldn't work in the 1920s. There are no towers to connect to the wired system. There's no one to speak to on this alleged "cell phone." Old Twilight Zone episodes notwithstanding, no one has reliably communicated with the past or future using radio waves.
I encountered Bing about a year ago after buying a new Dell laptop. By default, IE of course takes you to Bing. When I tried to find a copy of Firefox, Bing directed me to places like "DownloadFirefoxHere.com" instead of mozilla. I don't know if they intentionally suppress competing sites (i.e. mozilla competing with IE), but I have to wonder what sort of adware and other garbage one gets from third party Firefox download sites.
I wouldn't mind if they gave me "as good as but different" results. I draw the line when they give me egregiously bad results, apparently for their own benefit.
The term "perfect forward secrecy" has been used for about a decade in the Internet security protocol community to talk about key management protocols in which the current state of a crypto secret can't be used to uncover future secrets.
This paper uses the term "backward security" to mean something similar but subtly different about future secrets. The paper's matching term "forward security" talks about keeping older secrets secure.
The paper claims that this terminology is "common." I guess it depends on what community you're in.
This is obviuosly a marketing ploy by a company that can track eye movements, and they're looking for a killer app. This isn't it.
Shoulder surfing is just one of, oh, maybe a dozen ways to hack a password. It's not even the most common.
If you're going to buy expensive devices for authentication, there are lots of products that actually improve security: SecurID, SafeWord, those guys. Or buy a USB token with embedded challenge-response based on a public/private key pair.
Passwords and biometrics are both too easy to spoof and replay on networks.
I worked with some of Willie's assembly language code when working on Pluribus software back in the late '70s. He'd moved on to PARC or Stanford or something, and left behind some intricate 16-bit assembly code that took care of part of the Arpanet protocols. As a colleague said, "Willie's code is hard to read because he'd optimize as he wrote."
I'm no fan of Microsoft, but let's get real folks.
If a trojan has penetrated your system with administrative privileges, then it doesn't really matter what protocol gets used to piggyback additional malware into the penetrated system. If the malware has admin privileges, it can bypass any download security and filtering protocol you invent. Period.
It's like putting more and more money into a safe after the thieves have tunneled through and built a secret back door. The vault door locks just fine, but the money disappears anyway.
This is why I'm generally logged in as a user and not as an admin, even with home machines. It doesn't make you invulnerable but it reduces your risk profile a lot. It's something that Vista (finally) is trying to do right, tho' I think OS/X does a tolerable job of it already.
I've been getting e-mails from financial organizations for at least five years whose contents suggest a phishing scam. Most of the time the e-mail matches the indicators given in the organizations' own anti-fraud recommendations on their own corporate web sites.
The problem is that corporations don't have consistent policies on how to use e-mails. The anti-fraud people write up a policy and the marketeers ignore it.
FINALLY there is something akin to policy enforcement at a corporate level.
A couple of weeks ago the local hospital lost all inbound phone service for over two hours. They had Comcast. According to rumor, the tech heard that they still had outbound service and figured that that made it less of a priority.
OK, I grew up in the 60s around people encoraging artsy organic crap, and I tried to submerge my inate geekness. After some college it finally broke free and I signed up for a FORTRAN course. Before I could punch my first card, though, a physics prof taught me enough about the school's interactive BASIC system so that I could write myself my own Blackjack game.
My dad had started with computers in the '40s. When he heard I'd started trying out programming, he sat me down for a serious talk - "Rick, realize this: you'll work really hard on your first program, you'll think it's perfect, but then it WON'T WORK." He was right, but I kept at it anyway.
My first "own" computer was a Heath H89 that I bought from a guy who was given an early model by Heath to see if its assembly was in fact possible. After several months I essentially discarded the Heath operating system and replaced it with my own version of Forth.
A few years later my grad school advisor let me her 128K Mac (upgraded to 512) and I got the phonebook edition of Inside Macintosh. I was hooked, again, and I bought myself a Mac Plus.
1. No password should be based on personal information, unless it lives inside a protected perimeter (your house) and the password can't be used remotely to access the system. But if that's the case, then maybe you don't need a password at all!
2. Passwords for high-end web sites should be hard to guess (1 chance in a thousand), if you are confident that the web site will detect attempts at trial-and-error attacks against your account. Unfortunately, it's hard to tell what sites do when they get bad password attempts.
3. If you're using Microsoft domain authentication, or a web site that's not going to detect trial-and-error attacks, you're screwed. You have to pick a really nasty, impossible to remember password. This is because it's possible to do on-line trial and error guessing through things like the SMB protocol. I use two longish words with a comma in between - that defeats on-line and off-line attacks.
4. If you are really protecting important information, then spend a hundred or two dollars per computer and put in something serious, like smart card authentication based on a public/private key pair.
This is based on types of classified systems I've worked on myself, and more than a little experience dealing with computer security requirements. It sounds like your first problem is to identify equipment, so focus on that for now. Procedural things, like the handling of CDs and USB drives, can be left to work out with the Defense Security Service, or whoever it is who ends up certifying your setup.
Here's the easiest thing to do:
Buy a laptop and a printer that are small enough to fit in file cabinet drawers.
Do NOT tell the vendor that the device is for classified processing!!
If you need a large screen, you should be able to leave that outside the file cabinet and just hook it up when you take out the laptop. It doesn't have to be anything special, assuming it's LCD. Ditto for separate keyboard and mouse, but DO NOT use a wireless KB or mouse! If you need extra hard drive space, be sure there's room for an external HD in the cabinet.
Now, of course this file cabinet has to be a GSA approved container for Secret information.
I doubt that the DSS will allow you to leave a generic PC out unprotected even if it has a removable hard drive. The laptop is more likely to be approved.
Ultimately the right thing to do is set up a "closed" area where the equipment can sit out. That's a secured room with an approved combination lock or other approved lock. Then when you have to take a break you don't have to shut everything down, load it into the safe, and lock it up.
Plan for the laptop near term if there's a deadline to get started, but be sure your boss understands how important it will be to set up a closed area. Developers will spend half their time booting, shutting down, and assembling their workstations.
This sounds like the type of situation you get into when you are trying to do quantum cryptanalysis. You start with the ciphertext, which is partial information about the plaintext (unless it's a one time pad) and you're using the quantum cloud to find the actual plaintext.
Let's predict that this drives a stake through the heart of quantum cryptanalysis.
At least, when I used to do device drivers (ok, it was around the time the earth's crust cooled) you really had to know how to trace connections and decode explanations of chip logic, since that's really all there was.
Given the short product cycle times, few product developers have the time to figure out what their product really does before it is shipped and then replaced with a new and different model.
One thing that annoys me about contemporary film transfers is that the film owners don't always seem to have the rights or the necessary incentives to reproduce the original production.
The "restored" film may contain different music or have various trademarked goods wiped out.
I've never watched "Roswell" but I've read that the DVD version of the show has different music than the broadcast version. That's pretty bad.
I own a DVD copy of "Breakfast at Tiffany's" and a copy of "Seventeen" magazine in Holly's apartment has been retouched to be a nondescript "Fashion" magazine.
And of course there's the whole thing about manufacturing a "wide screen" version to sell to pretentious suckers when the original production was in small screen format. Usually they just strip off the bottom and top of the image, much like TV producers would discard the edges of wide-screen movies.
I LOVE the idea of selling all these papers off. We perceive these papers as valuable because lots of people have already read reprints of them. They already belong to the fabric of science and technology. It's not important if we sell off the paper they're printed on.
I think we make things better when we distribute them into the community of enthusiasts. I think we make people appreciate these things better when more people own copies of them (and I think they're far more affordable than Christie's is trying to make us think). For another thing, there are obvious risks to keeping all eggs in one basket, as in one museum.
Anyway, I have lots of this stuff myself and would love to get lots more. I've given a lot to the Charles Babbage Institute for the History of Computing already, and the Computer Museum, but there's still a lot of material out there worth collecting.
I've been following computing history items on eBay and ABE Books for years now, and I'm convinced that most of the electronic computing items won't go for a fraction of Christie's estimated price ranges.
There are a handful of truly rare items in there, but most of it is fairly common material with absurd prices.
"High Speed Computing Devices" by ERA with the "rare" paper covers. Puhleeze. I bought a copy through ABE for $20 maybe 3 years ago, and I got to choose from among several sellers. Christie's says it's worth $800-1200.
I don't know much about the autograph market but I remember hearing that Grace Hopper's autograph wasn't worth more than a hundred bucks or so. I doubt any of the other Giants are worth 10-100 times as much.
Also, lots of the items are REPRINTS of articles. Lot 211 a major "Von Neumann" paper that forms the foundation of computer architecture. Oh, by the way, it's really a decades-later reprint from DATAMATION, a trade rag, but never mind, Christies says it's worth $2-3K. A copy once sat in just about every DP manager's office in the country. Rare? Hardly.
I'd love to be wrong, though - it would mean that this junk I've collected over the past few decades is really worth a lot. But that would make it much harder to clean the trash out of my bookshelves.
My dad visited the ENIAC, the first successful electronic computer, during its brief lifetime of productivity, and was a government project officer on MIT's first computer, Whirlwind. This was a bit before I was born, but it meant I'd have an earlier peek at computers than others of my generation.
The first computer I physically encountered was LARC, an early supercomputer. Later, in junior high, my dad brought home some assembly language programming manuals and I tried my hand at programming. I don't think the programs were ever run, but I sort of liked doing it.
I didn't get back to computers till I did FORTRAN in college. FORTRAN quickly led to time shared BASIC and then to a couple flavors of assembly language. By then there was no going back.
It makes me think that some people are simply destined to be programmers and such. Some of us have a particular quality of patience combined with curiosity and tenacity that yields working programs. I don't think the early introduction actually matters that much, as far as programming aptitude goes.
My main complaint with the ACM's proposed policy statement is that it includes hyperlinks to statements by organizations both in favor and opposed to the policy.
The whole point of presenting a statement is to control what you're saying. You can't do that if you're linking to what others say. Presumably the links were included to indicate what 'responsible' organizations were saying both in favor of and in opposition to the policy.
What if one of the organizations rearranges their web site and the URL moves? What if the organization changes its statement to include bogus facts that most ACM members would disagree with?
The ACM should not have included the external URLs in their statement. There are more reliable ways of getting the desired result.
We all know, of course, that Mozart was much too young and unsophisticated to write any of that music attributed to him. Wasn't it all really stolen from someone else?
Just kidding.
Even the most trivial of Mozart's familiar works shows more creativity and genius than any derivitive Unix-like kernel. Reimplementing the kernel is NOT rocket science. It takes some taste, sophistication, skill, and LOTS of time on your hands, but it doesn't require some exceptional degree of genius (well, it needs that 99% perspiration part). That's why there are at least a half-dozen Unix kernel clones out there right now.
"Elgible Receiver" was a classic cyber wargame that took place a few years ago. The memory still gives nightmares to folks in the Pentagon.
There have only been a handful of public statements on the results of Elgible Receiver, and they indicate that the attacks reached classified systems.
The red team (the attackers from NSA) developed their attacks by cruising the Internet and collecting the most recent attack tools and discussions of attack techniques. They didn't use anything top secret, nor did they need government endorsed back doors. The red team was so successful that very few details have ever been released.
I have no doubt a red team can do as well today as they did back then, even if they start from scratch again. The main advantage the red team might have over a real cyberterrorist is a bit of insider knowledge about the networks under attack.
There's a technological arms race between the federal and state taxing authorities and the taxpayers. We look for tax savings by gaming the system through our tax software while they look for new ways of inferring details about our finances from the dozens (thousands) of finance numbers we provide.
I just wish there was open source tax software that would generate submittable forms.
The old Rock Hudson movie, A Gathering of Eagles had some footage from inside a Titan I site. There's a scene inside one of the large domes and, of course, one of a silo containing a big missile.
About 20 years ago I exchanged some newsgroup postings with someone who "spelunked" some mysterious site in Colorado which had 3 silos (filled with water) that sounded just like a Titan I site. I couldn't tell which site it was.
There's a Titan II site open to the public, the Titan Missile Museum in Arizona . But those sites only had one silo instead of 3, and there's only one (smaller) domed area without the separate power house.
No, they're not going to do a Common Criteria evaluation for everyone else.
Anything at EAL-4 or higher (like EAL-5) requires that you keep the source code consistent with a set of obsessively-written design specifications, and that's not exactly part of the open-source coding discipline.
NSA currently uses SE Linux when they're building systems for internal use that have stringent security requirements (keeping astronomically classified information separate from mere, pedestrian TOP SECRET stuff, for example). They would use their own package of assurance documentation that they use for internal certifications.
When Intel says security for wireless USB will be "the same as" wired USB, they're asserting a marketing objective. They're not describing a technical feature.
In fact, a lot of the security inherent in wired USB is tied to its inconvenience. Effective security requires that you "introduce" the two devices (the computer and the peripheral) to one another such that there's no ambiguity. If the two float out of range and float back in again, they have to pick each other up correctly.
With wired USB, it's clear how you switch a peripheral from one computer to another: I either switch the cables back and forth or plug in to a USB switch. What would a wireless USB switch look like? You can't automatically glom onto whichever device is closest, especially if you're in the middle of something like disk defragmentation or burning a CD.
None of these problems are unsolvable, but the solutions won't yield a wireless USB technology that's a transparent replacement for wired USB.
Is "Linux x86 assembly" any different to any other kind of "x86 assembly"?
Historically, assembly languages have varied in two dimensions: the underlying instruction set (x86 vs PowerPC vs Vax vs 360/370/etc) and the assembler's syntax itself.
In my experience, the challenge of changing "assemblers" came in when you changed instruction sets, and especially when moving between larger and smaller word sizes. Doing 32-bit arithmetic with 8-bit registers required a different approach than you take if you have 32-bit registers.
The other dimension dealt with the question of how you would actually write up the instructions in your program. For example, you know that the program needs an instruction to move data from a storage location to a particular machine register: you need to code the instruction according to the rules for the "assembler" program you're using (think of the "assembler" as being the "compiler" for assembly language).
In the olden days, most people used the assembler written by the computer's manufacturer: IBM's assembler, DEC's assembler, etc. So if you knew "assembly language" for a machine, there was a particular assembler (or family of assemblers) you used. This broke down in the DEC world farily early, partly because much of their early software really sucked. But even then, third-party assemblers tended to be 'culturally compatible' with the manufacturer's version.
Unix assemblers diverged somewhat from the standard DEC assemblers for the same CPUs, but I think the worst divergence emerged when the Zilog Z80 came out in competition with the Intel 8080. The Z80 had a 'compatible instruction set' but the assembler syntax was completely different. The languages used different opcodes and different ordering for operands. It was almost like using two incompatible machines.
Assemblers also differed from one another in how they defined symbols to establish storage locations and memory layouts. Some used predefined fields (IBM) while others used syntactic markers like colons (DEC). In general, the assemblers always gave you ways to define both absolute and relative storage areas.
A final feature that varies is in the 'macro' facilities. Full-featured assemblers provide ways to define blocks of instructions to plunk into a program, generally with parameters to control how and which instructions appear.
Slashdot Mirror
Actually, let's say it's an early version of a tinfoil hat - lacking hat-ness, though it may contain tinfoil.
The extra had obviously heard that photographic film can steal one's soul. The object is a shield to protect the face against this threat.
In any case, no doubt someone else has noted that a cell phone wouldn't work in the 1920s. There are no towers to connect to the wired system. There's no one to speak to on this alleged "cell phone." Old Twilight Zone episodes notwithstanding, no one has reliably communicated with the past or future using radio waves.
I encountered Bing about a year ago after buying a new Dell laptop. By default, IE of course takes you to Bing. When I tried to find a copy of Firefox, Bing directed me to places like "DownloadFirefoxHere.com" instead of mozilla. I don't know if they intentionally suppress competing sites (i.e. mozilla competing with IE), but I have to wonder what sort of adware and other garbage one gets from third party Firefox download sites.
I wouldn't mind if they gave me "as good as but different" results. I draw the line when they give me egregiously bad results, apparently for their own benefit.
This paper uses the term "backward security" to mean something similar but subtly different about future secrets. The paper's matching term "forward security" talks about keeping older secrets secure.
The paper claims that this terminology is "common." I guess it depends on what community you're in.
This is obviuosly a marketing ploy by a company that can track eye movements, and they're looking for a killer app. This isn't it.
Shoulder surfing is just one of, oh, maybe a dozen ways to hack a password. It's not even the most common.
If you're going to buy expensive devices for authentication, there are lots of products that actually improve security: SecurID, SafeWord, those guys. Or buy a USB token with embedded challenge-response based on a public/private key pair.
Passwords and biometrics are both too easy to spoof and replay on networks.
Rick.
I worked with some of Willie's assembly language code when working on Pluribus software back in the late '70s. He'd moved on to PARC or Stanford or something, and left behind some intricate 16-bit assembly code that took care of part of the Arpanet protocols. As a colleague said, "Willie's code is hard to read because he'd optimize as he wrote."
I'm no fan of Microsoft, but let's get real folks.
If a trojan has penetrated your system with administrative privileges, then it doesn't really matter what protocol gets used to piggyback additional malware into the penetrated system. If the malware has admin privileges, it can bypass any download security and filtering protocol you invent. Period.
It's like putting more and more money into a safe after the thieves have tunneled through and built a secret back door. The vault door locks just fine, but the money disappears anyway.
This is why I'm generally logged in as a user and not as an admin, even with home machines. It doesn't make you invulnerable but it reduces your risk profile a lot. It's something that Vista (finally) is trying to do right, tho' I think OS/X does a tolerable job of it already.
I've been getting e-mails from financial organizations for at least five years whose contents suggest a phishing scam. Most of the time the e-mail matches the indicators given in the organizations' own anti-fraud recommendations on their own corporate web sites.
The problem is that corporations don't have consistent policies on how to use e-mails. The anti-fraud people write up a policy and the marketeers ignore it.
FINALLY there is something akin to policy enforcement at a corporate level.
A couple of weeks ago the local hospital lost all inbound phone service for over two hours. They had Comcast. According to rumor, the tech heard that they still had outbound service and figured that that made it less of a priority.
OK, I grew up in the 60s around people encoraging artsy organic crap, and I tried to submerge my inate geekness. After some college it finally broke free and I signed up for a FORTRAN course. Before I could punch my first card, though, a physics prof taught me enough about the school's interactive BASIC system so that I could write myself my own Blackjack game.
My dad had started with computers in the '40s. When he heard I'd started trying out programming, he sat me down for a serious talk - "Rick, realize this: you'll work really hard on your first program, you'll think it's perfect, but then it WON'T WORK." He was right, but I kept at it anyway.
My first "own" computer was a Heath H89 that I bought from a guy who was given an early model by Heath to see if its assembly was in fact possible. After several months I essentially discarded the Heath operating system and replaced it with my own version of Forth.
A few years later my grad school advisor let me her 128K Mac (upgraded to 512) and I got the phonebook edition of Inside Macintosh. I was hooked, again, and I bought myself a Mac Plus.
1. No password should be based on personal information, unless it lives inside a protected perimeter (your house) and the password can't be used remotely to access the system. But if that's the case, then maybe you don't need a password at all!
2. Passwords for high-end web sites should be hard to guess (1 chance in a thousand), if you are confident that the web site will detect attempts at trial-and-error attacks against your account. Unfortunately, it's hard to tell what sites do when they get bad password attempts.
3. If you're using Microsoft domain authentication, or a web site that's not going to detect trial-and-error attacks, you're screwed. You have to pick a really nasty, impossible to remember password. This is because it's possible to do on-line trial and error guessing through things like the SMB protocol. I use two longish words with a comma in between - that defeats on-line and off-line attacks.
4. If you are really protecting important information, then spend a hundred or two dollars per computer and put in something serious, like smart card authentication based on a public/private key pair.
This is based on types of classified systems I've worked on myself, and more than a little experience dealing with computer security requirements. It sounds like your first problem is to identify equipment, so focus on that for now. Procedural things, like the handling of CDs and USB drives, can be left to work out with the Defense Security Service, or whoever it is who ends up certifying your setup.
Here's the easiest thing to do:
Buy a laptop and a printer that are small enough to fit in file cabinet drawers.
Do NOT tell the vendor that the device is for classified processing!!
If you need a large screen, you should be able to leave that outside the file cabinet and just hook it up when you take out the laptop. It doesn't have to be anything special, assuming it's LCD. Ditto for separate keyboard and mouse, but DO NOT use a wireless KB or mouse! If you need extra hard drive space, be sure there's room for an external HD in the cabinet.
Now, of course this file cabinet has to be a GSA approved container for Secret information.
I doubt that the DSS will allow you to leave a generic PC out unprotected even if it has a removable hard drive. The laptop is more likely to be approved.
Ultimately the right thing to do is set up a "closed" area where the equipment can sit out. That's a secured room with an approved combination lock or other approved lock. Then when you have to take a break you don't have to shut everything down, load it into the safe, and lock it up.
Plan for the laptop near term if there's a deadline to get started, but be sure your boss understands how important it will be to set up a closed area. Developers will spend half their time booting, shutting down, and assembling their workstations.
Good luck.
This sounds like the type of situation you get into when you are trying to do quantum cryptanalysis. You start with the ciphertext, which is partial information about the plaintext (unless it's a one time pad) and you're using the quantum cloud to find the actual plaintext.
Let's predict that this drives a stake through the heart of quantum cryptanalysis.
At least, when I used to do device drivers (ok, it was around the time the earth's crust cooled) you really had to know how to trace connections and decode explanations of chip logic, since that's really all there was.
Given the short product cycle times, few product developers have the time to figure out what their product really does before it is shipped and then replaced with a new and different model.
One thing that annoys me about contemporary film transfers is that the film owners don't always seem to have the rights or the necessary incentives to reproduce the original production.
The "restored" film may contain different music or have various trademarked goods wiped out.
I've never watched "Roswell" but I've read that the DVD version of the show has different music than the broadcast version. That's pretty bad.
I own a DVD copy of "Breakfast at Tiffany's" and a copy of "Seventeen" magazine in Holly's apartment has been retouched to be a nondescript "Fashion" magazine.
And of course there's the whole thing about manufacturing a "wide screen" version to sell to pretentious suckers when the original production was in small screen format. Usually they just strip off the bottom and top of the image, much like TV producers would discard the edges of wide-screen movies.
NOT!
I LOVE the idea of selling all these papers off. We perceive these papers as valuable because lots of people have already read reprints of them. They already belong to the fabric of science and technology. It's not important if we sell off the paper they're printed on.
I think we make things better when we distribute them into the community of enthusiasts. I think we make people appreciate these things better when more people own copies of them (and I think they're far more affordable than Christie's is trying to make us think). For another thing, there are obvious risks to keeping all eggs in one basket, as in one museum.
Anyway, I have lots of this stuff myself and would love to get lots more. I've given a lot to the Charles Babbage Institute for the History of Computing already, and the Computer Museum, but there's still a lot of material out there worth collecting.
I've been following computing history items on eBay and ABE Books for years now, and I'm convinced that most of the electronic computing items won't go for a fraction of Christie's estimated price ranges.
There are a handful of truly rare items in there, but most of it is fairly common material with absurd prices.
"High Speed Computing Devices" by ERA with the "rare" paper covers. Puhleeze. I bought a copy through ABE for $20 maybe 3 years ago, and I got to choose from among several sellers. Christie's says it's worth $800-1200.
I don't know much about the autograph market but I remember hearing that Grace Hopper's autograph wasn't worth more than a hundred bucks or so. I doubt any of the other Giants are worth 10-100 times as much.
Also, lots of the items are REPRINTS of articles. Lot 211 a major "Von Neumann" paper that forms the foundation of computer architecture. Oh, by the way, it's really a decades-later reprint from DATAMATION, a trade rag, but never mind, Christies says it's worth $2-3K. A copy once sat in just about every DP manager's office in the country. Rare? Hardly.
I'd love to be wrong, though - it would mean that this junk I've collected over the past few decades is really worth a lot. But that would make it much harder to clean the trash out of my bookshelves.
My dad visited the ENIAC, the first successful electronic computer, during its brief lifetime of productivity, and was a government project officer on MIT's first computer, Whirlwind. This was a bit before I was born, but it meant I'd have an earlier peek at computers than others of my generation.
The first computer I physically encountered was LARC, an early supercomputer. Later, in junior high, my dad brought home some assembly language programming manuals and I tried my hand at programming. I don't think the programs were ever run, but I sort of liked doing it.
I didn't get back to computers till I did FORTRAN in college. FORTRAN quickly led to time shared BASIC and then to a couple flavors of assembly language. By then there was no going back.
It makes me think that some people are simply destined to be programmers and such. Some of us have a particular quality of patience combined with curiosity and tenacity that yields working programs. I don't think the early introduction actually matters that much, as far as programming aptitude goes.
My main complaint with the ACM's proposed policy statement is that it includes hyperlinks to statements by organizations both in favor and opposed to the policy.
The whole point of presenting a statement is to control what you're saying. You can't do that if you're linking to what others say. Presumably the links were included to indicate what 'responsible' organizations were saying both in favor of and in opposition to the policy.
What if one of the organizations rearranges their web site and the URL moves? What if the organization changes its statement to include bogus facts that most ACM members would disagree with?
The ACM should not have included the external URLs in their statement. There are more reliable ways of getting the desired result.
We all know, of course, that Mozart was much too young and unsophisticated to write any of that music attributed to him. Wasn't it all really stolen from someone else?
Just kidding.
Even the most trivial of Mozart's familiar works shows more creativity and genius than any derivitive Unix-like kernel. Reimplementing the kernel is NOT rocket science. It takes some taste, sophistication, skill, and LOTS of time on your hands, but it doesn't require some exceptional degree of genius (well, it needs that 99% perspiration part). That's why there are at least a half-dozen Unix kernel clones out there right now.
Rick.
"Elgible Receiver" was a classic cyber wargame that took place a few years ago. The memory still gives nightmares to folks in the Pentagon.
There have only been a handful of public statements on the results of Elgible Receiver, and they indicate that the attacks reached classified systems.
The red team (the attackers from NSA) developed their attacks by cruising the Internet and collecting the most recent attack tools and discussions of attack techniques. They didn't use anything top secret, nor did they need government endorsed back doors. The red team was so successful that very few details have ever been released.
I have no doubt a red team can do as well today as they did back then, even if they start from scratch again. The main advantage the red team might have over a real cyberterrorist is a bit of insider knowledge about the networks under attack.
There's a technological arms race between the federal and state taxing authorities and the taxpayers. We look for tax savings by gaming the system through our tax software while they look for new ways of inferring details about our finances from the dozens (thousands) of finance numbers we provide.
I just wish there was open source tax software that would generate submittable forms.
About 20 years ago I exchanged some newsgroup postings with someone who "spelunked" some mysterious site in Colorado which had 3 silos (filled with water) that sounded just like a Titan I site. I couldn't tell which site it was.
There's a Titan II site open to the public, the Titan Missile Museum in Arizona . But those sites only had one silo instead of 3, and there's only one (smaller) domed area without the separate power house.
Rick.
No, they're not going to do a Common Criteria evaluation for everyone else.
Anything at EAL-4 or higher (like EAL-5) requires that you keep the source code consistent with a set of obsessively-written design specifications, and that's not exactly part of the open-source coding discipline.
NSA currently uses SE Linux when they're building systems for internal use that have stringent security requirements (keeping astronomically classified information separate from mere, pedestrian TOP SECRET stuff, for example). They would use their own package of assurance documentation that they use for internal certifications.
In fact, a lot of the security inherent in wired USB is tied to its inconvenience. Effective security requires that you "introduce" the two devices (the computer and the peripheral) to one another such that there's no ambiguity. If the two float out of range and float back in again, they have to pick each other up correctly.
With wired USB, it's clear how you switch a peripheral from one computer to another: I either switch the cables back and forth or plug in to a USB switch. What would a wireless USB switch look like? You can't automatically glom onto whichever device is closest, especially if you're in the middle of something like disk defragmentation or burning a CD.
None of these problems are unsolvable, but the solutions won't yield a wireless USB technology that's a transparent replacement for wired USB.
Sorry, Intel, but wireless is different.
Historically, assembly languages have varied in two dimensions: the underlying instruction set (x86 vs PowerPC vs Vax vs 360/370/etc) and the assembler's syntax itself.
In my experience, the challenge of changing "assemblers" came in when you changed instruction sets, and especially when moving between larger and smaller word sizes. Doing 32-bit arithmetic with 8-bit registers required a different approach than you take if you have 32-bit registers.
The other dimension dealt with the question of how you would actually write up the instructions in your program. For example, you know that the program needs an instruction to move data from a storage location to a particular machine register: you need to code the instruction according to the rules for the "assembler" program you're using (think of the "assembler" as being the "compiler" for assembly language).
In the olden days, most people used the assembler written by the computer's manufacturer: IBM's assembler, DEC's assembler, etc. So if you knew "assembly language" for a machine, there was a particular assembler (or family of assemblers) you used. This broke down in the DEC world farily early, partly because much of their early software really sucked. But even then, third-party assemblers tended to be 'culturally compatible' with the manufacturer's version.
Unix assemblers diverged somewhat from the standard DEC assemblers for the same CPUs, but I think the worst divergence emerged when the Zilog Z80 came out in competition with the Intel 8080. The Z80 had a 'compatible instruction set' but the assembler syntax was completely different. The languages used different opcodes and different ordering for operands. It was almost like using two incompatible machines.
Assemblers also differed from one another in how they defined symbols to establish storage locations and memory layouts. Some used predefined fields (IBM) while others used syntactic markers like colons (DEC). In general, the assemblers always gave you ways to define both absolute and relative storage areas.
A final feature that varies is in the 'macro' facilities. Full-featured assemblers provide ways to define blocks of instructions to plunk into a program, generally with parameters to control how and which instructions appear.