I basically agree with you, but I can see how a draconian scheme like Palladiium could end spam. Spam inherently relies on deception and anonymity. Imagine that every message in your inbox has a full name next to it like "Robert H. Smith". The message was signed through a Microsoft-issued key; otherwise it would never make it to your inbox. If you click on "Robert H. Smith" you see his driver's license picture and address. You're in a good position to sue this guy, because you don't have to spend much effort figuring out who he is. Maybe Microsoft gives you a button to report the sender for abuse. A few thousand clicks later, Robert H. Smith is suspended from Palladium email for 90 days.
There's more - each message would probably have to be individually encrypted and signed. This might be too burdensome for spammers. Also, would their spamware be "trusted" under Palladium? For a really ambitious idea, Microsoft could issue each user 100 "stamps" per month. When you send someone a message, you give him your stamp. So if a spammer wants to send 8 million messages, like Ronnie Scelson, he'd need 8 million inbound messages first.
Of course, these measures would impact legitimate mailing lists. Microsoft could sell "enterprise certificates" to big corporations. And if the LKML is a casualty in this "war on spam" I don't think Microsoft would be too upset.
I think the hardware will decrypt content. So, Alice wants to download a song. The OS asks the hardware for its "identity" - a file with a serial number and a RSA public key. The whole identity file is signed by Microsoft. The OS sends this file to the music server, which verifies the signature. The music server prepares a music file containing the mp3 and some DRM rules and encrypts this file with the public key it got from the client. The music server sends the music file to the client.
Whenever Alice plays the song, the OS simply tells the hardware to play it. If the hardware is satisfied with the security of the machine (no unsafe code running), it decrypts the file on the fly and sends it to the ADC. Maybe the mp3 decoder will be in hardware - maybe it will be a special piece of software signed at a higher trust level than the rest of the OS because it can touch (gasp) plaintext audio.
As for your idea: let's say you stick a Palladium OS distribution CD in a Linux box and start playing with it. First, the whole CD might be encrypted, ala DVD, with a set of keys issued to various CPU makers. In which case, it will be virtually impossible to get at the Palladium machine language. Remember, DVD-CSS was cracked only because they allowed software implementations.
Assuming that it's not encrypted, you might be able to get Palladium OS to boot in a virtual machine. But the VM would not have a valid "identity" file as described above, so while you could fool the OS you couldn't fool any outside parties like the music server.
As for the firmware and microcode updates, obviously those would be digitally signed by the hardware maker and the hardware would not accepted unsigned updates.
Also remember, distributing tools to circumvent any of this is a felony violation of the DMCA. The Hollings bill, if it passes, will add more penalties.
Microsoft could make it clear to CPU makers that any compromised keys will be revoked. So if VIA rushes through their Palladium implementation and sells a series of chips with unintended holes in them, as soon as the news leaks those keys are revoked and VIA has a lot of explaining to do, as their customers are unable to view copyrighted content from the internet. I think this threat would induce the chipmakers to implement securely.
The attempt to tie Palladium to 'security', in the sense we understand it, is dishonest. Palladium is a scheme to shift power from computer owners to Microsoft and content owners.
O'Reilly hit the nail on the head. Microsoft has been deliberately generating confusion between their interests and their customers'. O'Reilly rightly draws a distinction between software vendors and users.
However, I think a further distinction needs to be drawn: software vendor/system owner/user. What O'Reilly calls users are really government agencies and corporations - not users in the Stallmanish sense. I think the current trend is shifting power from the software vendor to the system owner (agency/corp/isp) but not to the end user.
In fact, Free Software provides a rich array of tools for system owners to restrict and monitor the actual users. Is a clerk at Burlington Coat Factory in any way empowered by the fact that his terminal runs Linux? Does he even know it runs Linux? I guess not.
The irony is that Free Software is far more useful to technically sophisticated organizations than to normal human beings. AOL apparently convinced many AOL users that Usenet was part of AOL. Likewise, there seems to be an increasing role for these intermediary "spoon feeders" who will hide the complexity of Free Software from customers/employees/students and present them with a shiny, smooth, tamperproof interface, with all the confusing names, licenses and versions ground off.
I am very glad that the power of the software vendors is waning; however we must be alert to the new forms of power being wielded against the actual users.
The less money a company spends to keep track of what its employees are wasting, the more money they have to remain solvent.
Exactly. Sometimes the tracking becomes more expensive than the resource being consumed. A manufacturing company was experiencing shrinkage of certain parts, like screws, nuts and electrical connectors. They gradually increased the level of control of parts issue, until the assembling employee had to request and sign for a "kit of parts" from a warehouse clerk. Their cost of production increased, and the shrinkage only decreased a little. No matter how tight they made the controls, some parts were being stolen. There must have been collusion between different employees.
Then they tried a completely different system. They put 55 gallon steel drums in the manufacturing area and filled each one to the brim with one part. They abolished all tracking and controls. In the first week, some of the drums went down to 50%. Over time, however, the shrinkage (measured on a coarse scale now) has decreased nearly to zero.
I'm not sure if or how this can be applied to corporate bandwidth usage.
Good advice. Let me add: Have a box on the internet that is not associated with your employer. Any recreational internet activities should flow through ssh to this box. Be sparing of the employer's bandwidth, especially during business hours.
As for clothes, I guess it varies from one area to another. Here in Silicon Valley the Gap look is a little too much, unless you're a vice president or something. Jeans and a t-shirt are fine. Just make sure you don't smell. I'm not sure about the impact of black t-shirts, but you could be right.
Of course, I'm not looking for promotions. Neither are any of my peers, as far as I know. Everyone who has gone from programmer to manager seems very unhappy with the added stresses and reduced chance to architect and code.
As for "network gods", I don't know what to think. I have continued to find rewarding work that does not involve Microsoft. It seems to me that if you're being asked to admin Unix and Windows, you're in too small a company. Larger companies have separate groups. As a programmer I have pursued the kind of work that interests me - I have never applied for or been offered a job that directly involves Microsoft software. I tend to think (knock on wood) that those accepting such compromises are limiting their job search in some other way - perhaps geographically.
Reporters: If you don't know what a word means, please don't use it. The volt is a unit of potential difference, not power.
Discovery of one acute vulnerability -- in a data transmission standard known as ASN.1, short for Abstract Syntax Notification...
Abstract Syntax Notation is a way of defining packed representations of data. It is analogous to XML. How could there be a vulnerability in the specification itself?
Much of the technical information required to penetrate these systems is widely discussed in the public forums of the affected industries...
Implication: we should seek security through obscurity by hiding such technical information. That is a very naive idea. A railroad signalling system, for example, is probably sold both to US railroads and to third world railroads. The third world engineers who maintain these systems may have good reasons to attack the US or to aid those planning the attacks.
They told the president that researchers in Finland had identified a serious security hole in the Internet's standard language for routing data through switches...Bush ordered the Pentagon and key federal agencies to patch their systems. But most of the vulnerable networks were not government- owned.
I don't understand. As with the ASN example, if the problem was inherent in a language, then the language would need to be modified. If the problem was solved by patching software, then the problem must have been in a specific implementation rather than the language. But what is this person talking about? Does he mean IP, or BGP? Does he even know what he means? The problem is not just that the article lacks information, it's that this reporter does not seem to think clearly.
Token-based authentication won't help much -- "Hi, this is system security, we're upgrading the smart card system, could you please help us test by inserting your card and going to this URL?"
In which case the owner of that URL learns nothing useful about the token. Assuming that the token has a crypto processor on board capable of public-key signature, it neatly prevents this attack. The web server sends a random string, the token signs the string with its private key, and the web server validates the signature with the token's public key. The web server does not gain the ability to impersonate the token.
Just to clarify, the complaint is NOT that the operator requested high power levels and the machine delivered. The complaint is that the operator requested correct power levels, but in the course of editing pressed some cursor control keys in an unanticipated way, causing the machine to mysteriously fry the patients.
I'd only started using Audio Galaxy a week ago, via OpenAG. I was amazed at the depth, speed and reliability. I found pretty much everything I looked for. It was like the heyday of Napster.
It was good while it lasted. Thanks, Audio Galaxy people - you made one of the truly worthwhile things on the internet.
Don't you think it's possible that David is withholding some pieces of the puzzle? It seems like he is only admitting to things that are legal or were already known (stealing smoke detectors). Given his huge appetite for nuclear materials, he may have gone a lot further. In any event, antiques were not the only source of nuclear material cited. Of course it could be fake. But I think we should assume that we are hearing a carefully spun version of the story that is influenced by the chance of criminal prosecution.
This kid is a walking advertisement for the Darwin Awards...
That meme irritates me a bit - it seems to imply that evolution never favors risk-taking. Actually, evolution favors a good balance between risk-taking and fear. If you are paralyzed by fear you won't win any "Darwin Awards" on the internet, but you won't get any rewards from life either.
I think most people who talk about "Darwin Awards" are overlooking the fact that death by excessive risk-taking is not the only kind of death - starvation awaits those who do not take enough risks.
You are correct. The source code for these types of sensitive niche programs probably should be under lock and key, as the only people interested in taking a look at the source are those people who are looking for holes that they can exploit.
That's reasonable, but what if the niche program is open source and the government offers prizes for anyone who can find exploits? There would be a defined time period between exploit notification and publication - adequate to roll out a patched version. This would give lots of people incentive to read the code, as well as incentive not to immediately publish or use the exploits found.
I think the NSA gets close to this level of scrutiny right now by having completely independent groups attack security systems internally.
Its not like there's all this naturally growing software out there that Microsoft is trying to charge us to access...
Actually, it sometimes is like that, especially when Microsoft swallows BSD-licensed code. For example, Microsoft took the free-as-in-air BSD TCP/IP code, mixed in their "colored smoke and fumes" and sold it to their uninformed user base as their own creation. This is why they complain about the GPL being "viral" - they really want to repeat that exploit.
Of course an active, adventurous person could track down and use the code without Microsoft - they have no way to really restrict it - but this is the same as saying that an active, adventurous denizen of the cave could climb up and find an uncontrolled fresh air gap.
Do you think the Bowie machine has the power to make the music industry see the light?
The music industry has seen the light with great clarity for quite a while. That's why we got the DMCA and why we're getting the too-long-to-pronounce law. Don't phrase this as a matter of clueless old farts who should "see the light" and join the internet age. It's a matter of an entrenched, wealthy, intelligent elite which will fight to the death to preserve and enhance its privileges and income.
The implication of this "see the light" comment is that the music industry should adapt to changing conditions. But an excellent quote which I can't find right now says, in effect: "Individual organisms do not adapt to changing conditions - the species adapts via the death of ill-adapted organisms".
Actually, it's pretty reasonable. You think it's expensive because you're comparing it to "equivalent" consumer bandwidth. However when you pay for the T1 you are paying for N bits per second - when you pay for consumer bandwidth you're paying for the right to use up to N bits per second if they're available. Naturally, anyone selling consumer bandwidth oversells relative to the real bandwidth he bought. At an oversell ratio of 10:1, which I think is common for consumer bandwidth, you could sell 40 384k connections out of this T1.
Without temporary monopolies to recoup R&D and Deployment, what incentive is there for a company to invest butt-loads of money into something like a broadband network?
I don't understand this argument, but I see it a lot. Opening the network to competition should not mean that AT&T fails to make a profit on the infrastructure they've built. Look at it this way: AT&T builds a railroad to carry minerals from a mine they own. They have two different investments: the mine and the railroad. Now other mine operators want to use the railroad. Naturally, they expect to pay. But AT&T refuses to carry their cargo at all. Under the DSL rules, AT&T would be compelled to provide transport for the other mine operators - not at a loss, but at a reasonable profit. This should not harm their ability to recoup on any investment in the railroad. If it harms their ability to recoup on the mine, then the mine was badly planned.
In any event, the last-mile wiring infrastructure remains a monopoly. The issue is whether that facility should be rented (not given away) to all parties on a non-discriminatory basis, or whether the owner of the infrastructure can leverage its monopoly in last-mile transport to create a monopoly in a totally different market, ISP services and upstream transport.
To me the answer is clear; in fact I believe that any company granted monopoly privileges to provide last-mile transit should be banned from providing upstream internet access - they should merely rent capacity to ISPs who would sell the complete package to customers. That would eliminate the current blatant conflict of interest. I don't see how it would prevent investors in such last-mile infrastructure from recouping investment.
The advances mentioned in the article seem to be improvements in grinding substances finely. The article claims that there is some kind of continuum from this grinding to actual nanotech machines, and that cautious investors are starting at the easy end of the continuum.
I don't see how this could be. It seems that if you want to approach the kind of nanotech described in Stepehenson's The Diamond Age you would probably work with tiny machines and assembly techniques and gradually push the size envelope downwards - which is how it happened with silicon. Or work with subtractive etching techniques that could remove material to leave behind movable parts. Merely grinding up tiny nondescript particles - in other words soot or dust - doesn't seem like a step on this road at all.
Of course my understanding of nanotechnology is firmly grounded in science fiction.
That was interesting, and I hope it gets modded up. I think you touched on something that makes me uneasy about "software design" - design seems to imply redundancy. It's easier to design a bridge than to make one. The drawing package for a bridge is a more compact representation of the underlying structure than the bridge itself.
Repetitive work may be needed in the physical world, but should be automated in the computer world. If a piece of software can be "designed", isn't the design document itself a program? And shouldn't it be run through a preprocessor/compiler/whatever to generate the next stage?
Of course a real engineered artifact might have higher-level design documents which do not contain sufficient detail to build the artifact, but containt sufficient detail that a qualified engineer could use them to develop the detailed design. Maybe within that context it is acceptable to speak of software design or engineering.
I haven't found flowcharts to be useful recently - they take a lot of space to cover simple things, and they implicitly describe "spaghetti" code - code which uses jumps or gotos for flow control. For small programs, I generally write the main() function first, keeping it short and clear and invoking a bunch of unwritten functions. At this point I effectively have the interface to those lower functions defined. If the program has to parse a source or config file, I may fill in dummy functions for some of the lower level and test the parser.
Then I flesh in the lower level functions, creating even lower ones where needed. I try to keep each function fairly short - going over 40 lines, let's say, could indicate that an unexpressed function is "swallowed" in your function. Longer functions are sometimes OK, and sometimes it's possible to factor out very short functions that have a clearcut, reusable purpose.
When I code in C, I often start by defining the data structures, but in Perl I haven't felt a need to do this since Perl's data structures are dynamic.
Tcpflow - read contents of tcp traffic in real time. Great for watching browser/webserver interactions.
Netcat - connect Unix pipes to TCP sockets. Should have been part of Unix since the advent of TCP/IP. Great for rigging a temporary "server" to see if a client is connecting as advertised: nc -lp 80.
X Resources (as seen in ~/.Xdefaults) - you can make xterms really dark, even when running colored apps like mutt, with dark Xresources like: XTerm*color9: #690000 - man xterm for meanings of color0-15. xrdb -merge.darkXres to use.
Xmessage - useful in crontabs to remind you of periodic things - like remembering to go home. With the right params, it can take over the whole screen, which is hard to ignore.
perl -pi.bak -e's/chocolate/vanilla/g' *.recipe - change a bunch of files, leaving backups.
How fortunate that your amazing speed-reading powers allowed you to fully digest, analyze, and dismiss the entire 550-page book while "looking at" it in a store. It's a shame the several tens of thousands of people who actually bought and read the book, gave it a 4.5-star rating on Amazon, and made it one of the top 10 best-selling books in the O'Reilly catalog last year, did not have the benefit of your astounding mental powers.
You cite volume of sales as a figure of merit. So which do you believe is typical of a person who purchased the book?
He looked at the book before buying, in enough depth that he was fairly sure he liked the book. Implication: the typical purchaser had "astounding mental powers" - or is it less astounding to form a positive opinion?
He did not read much of the book before buying. Implication: the purchase was based on other factors than the content of the book; therefore the book's standing as a best-selling book is not relevant to its merits.
The book does not say this; it says something similar but different, which you have misquoted and presented out of context.
I don't have the book - you presumably do. Instead of complaining about my bad paraphrase and offering your paraphrase, you could have (and still can) set the record straight with the actual text.
Inasmuch as it helps people to actually understand what they're proposing to do, and its possible consequences (including being reprimanded or fired for deliberately flouting corporate network policy), I think my responses on the topic have been quite helpful.
Certainly that's a good idea, and you've been helpful in another sense - merely having the patience to answer this type of question repeatedly. However, what I meant by "unhelpful" is not helping the querent reach his goal. Browsing again through your posts on the topic, I realize that most of them may have been made before any keepalive[1] patch was available - so you were probably correct in writing "There is no good way around this at the moment."
However there are good ways around this today, and I think they should be the first answer to someone experiencing mysterious connection failures. There is an accelerating assumption that "the internet" == "the web" and this affects how businesses adopt firewalls. Microsoft is both reacting to and strengthening this mindset with SOAP, which uses pseudo-web traffic. I think ssh clients should be distributed with keepalives enabled. They do no harm when there is no firewall/NAT involved, and they circumvent an increasingly frequent problem. I find the "NAT shortage" theory fairly removed from current reality, given that ssh users are generally a tiny minority. I realize that you may have seen environments where it applies.
Anyhow, my reaction to the book was highly colored by this issue. [1] The useful kind, that actually keeps the connection alive.
I looked at this book in the bookstore, and everything was either obvious or useless. Maybe this book would have helped me when I didn't know anything about ssh, but between the man pages and Google groups everything you need is available. What really irritated me was the authors' handling of timeouts and keepalives. It's quite common to be stuck behind a firewall that closes all idle TCP connections. The ssh keepalive functionality does not address this - it's for disconnecting dead sessions, not keeping sessions alive. You need to send some "filler" packets through the TCP connection when it's idle.
This is a frequently asked question. The answer of this book is that you shouldn't send keepalive packets because if "the sysadmin" configured a firewall to kill idle connections, you should just accept this restriction. I hope I don't have to explain how completely wrong this is. Increasingly big organizations have a firewall configured by people who are totally unresponsive.
Anyway, I solved the problem by applying this patch.
One of the book's authors responds to this question on Usenet with the same unhelpful answer found in the book.
Want a standards-based SMTP server with server-side calendaring that works nicely with Outlook and the plethora of email clients? You want this affordable Intel based application!
Steltor, whose site seems to be broken, makes good scheduling apps that can connect to Outlook. Their server runs on lots of OS's, including Linux. I know one customer, and he's happy.
Slashdot Mirror
I basically agree with you, but I can see how a draconian scheme like Palladiium could end spam. Spam inherently relies on deception and anonymity. Imagine that every message in your inbox has a full name next to it like "Robert H. Smith". The message was signed through a Microsoft-issued key; otherwise it would never make it to your inbox. If you click on "Robert H. Smith" you see his driver's license picture and address. You're in a good position to sue this guy, because you don't have to spend much effort figuring out who he is. Maybe Microsoft gives you a button to report the sender for abuse. A few thousand clicks later, Robert H. Smith is suspended from Palladium email for 90 days.
There's more - each message would probably have to be individually encrypted and signed. This might be too burdensome for spammers. Also, would their spamware be "trusted" under Palladium? For a really ambitious idea, Microsoft could issue each user 100 "stamps" per month. When you send someone a message, you give him your stamp. So if a spammer wants to send 8 million messages, like Ronnie Scelson, he'd need 8 million inbound messages first.
Of course, these measures would impact legitimate mailing lists. Microsoft could sell "enterprise certificates" to big corporations. And if the LKML is a casualty in this "war on spam" I don't think Microsoft would be too upset.
I think the hardware will decrypt content. So, Alice wants to download a song. The OS asks the hardware for its "identity" - a file with a serial number and a RSA public key. The whole identity file is signed by Microsoft. The OS sends this file to the music server, which verifies the signature. The music server prepares a music file containing the mp3 and some DRM rules and encrypts this file with the public key it got from the client. The music server sends the music file to the client.
Whenever Alice plays the song, the OS simply tells the hardware to play it. If the hardware is satisfied with the security of the machine (no unsafe code running), it decrypts the file on the fly and sends it to the ADC. Maybe the mp3 decoder will be in hardware - maybe it will be a special piece of software signed at a higher trust level than the rest of the OS because it can touch (gasp) plaintext audio.
As for your idea: let's say you stick a Palladium OS distribution CD in a Linux box and start playing with it. First, the whole CD might be encrypted, ala DVD, with a set of keys issued to various CPU makers. In which case, it will be virtually impossible to get at the Palladium machine language. Remember, DVD-CSS was cracked only because they allowed software implementations.
Assuming that it's not encrypted, you might be able to get Palladium OS to boot in a virtual machine. But the VM would not have a valid "identity" file as described above, so while you could fool the OS you couldn't fool any outside parties like the music server.
As for the firmware and microcode updates, obviously those would be digitally signed by the hardware maker and the hardware would not accepted unsigned updates.
Also remember, distributing tools to circumvent any of this is a felony violation of the DMCA. The Hollings bill, if it passes, will add more penalties.
Microsoft could make it clear to CPU makers that any compromised keys will be revoked. So if VIA rushes through their Palladium implementation and sells a series of chips with unintended holes in them, as soon as the news leaks those keys are revoked and VIA has a lot of explaining to do, as their customers are unable to view copyrighted content from the internet. I think this threat would induce the chipmakers to implement securely.
The attempt to tie Palladium to 'security', in the sense we understand it, is dishonest. Palladium is a scheme to shift power from computer owners to Microsoft and content owners.
O'Reilly hit the nail on the head. Microsoft has been deliberately generating confusion between their interests and their customers'. O'Reilly rightly draws a distinction between software vendors and users.
However, I think a further distinction needs to be drawn: software vendor/system owner/user. What O'Reilly calls users are really government agencies and corporations - not users in the Stallmanish sense. I think the current trend is shifting power from the software vendor to the system owner (agency/corp/isp) but not to the end user.
In fact, Free Software provides a rich array of tools for system owners to restrict and monitor the actual users. Is a clerk at Burlington Coat Factory in any way empowered by the fact that his terminal runs Linux? Does he even know it runs Linux? I guess not.
The irony is that Free Software is far more useful to technically sophisticated organizations than to normal human beings. AOL apparently convinced many AOL users that Usenet was part of AOL. Likewise, there seems to be an increasing role for these intermediary "spoon feeders" who will hide the complexity of Free Software from customers/employees/students and present them with a shiny, smooth, tamperproof interface, with all the confusing names, licenses and versions ground off.
I am very glad that the power of the software vendors is waning; however we must be alert to the new forms of power being wielded against the actual users.
Exactly. Sometimes the tracking becomes more expensive than the resource being consumed. A manufacturing company was experiencing shrinkage of certain parts, like screws, nuts and electrical connectors. They gradually increased the level of control of parts issue, until the assembling employee had to request and sign for a "kit of parts" from a warehouse clerk. Their cost of production increased, and the shrinkage only decreased a little. No matter how tight they made the controls, some parts were being stolen. There must have been collusion between different employees.
Then they tried a completely different system. They put 55 gallon steel drums in the manufacturing area and filled each one to the brim with one part. They abolished all tracking and controls. In the first week, some of the drums went down to 50%. Over time, however, the shrinkage (measured on a coarse scale now) has decreased nearly to zero.
I'm not sure if or how this can be applied to corporate bandwidth usage.
Good advice. Let me add: Have a box on the internet that is not associated with your employer. Any recreational internet activities should flow through ssh to this box. Be sparing of the employer's bandwidth, especially during business hours.
As for clothes, I guess it varies from one area to another. Here in Silicon Valley the Gap look is a little too much, unless you're a vice president or something. Jeans and a t-shirt are fine. Just make sure you don't smell. I'm not sure about the impact of black t-shirts, but you could be right.
Of course, I'm not looking for promotions. Neither are any of my peers, as far as I know. Everyone who has gone from programmer to manager seems very unhappy with the added stresses and reduced chance to architect and code.
As for "network gods", I don't know what to think. I have continued to find rewarding work that does not involve Microsoft. It seems to me that if you're being asked to admin Unix and Windows, you're in too small a company. Larger companies have separate groups. As a programmer I have pursued the kind of work that interests me - I have never applied for or been offered a job that directly involves Microsoft software. I tend to think (knock on wood) that those accepting such compromises are limiting their job search in some other way - perhaps geographically.
Reporters: If you don't know what a word means, please don't use it. The volt is a unit of potential difference, not power.
Abstract Syntax Notation is a way of defining packed representations of data. It is analogous to XML. How could there be a vulnerability in the specification itself?
Implication: we should seek security through obscurity by hiding such technical information. That is a very naive idea. A railroad signalling system, for example, is probably sold both to US railroads and to third world railroads. The third world engineers who maintain these systems may have good reasons to attack the US or to aid those planning the attacks.
I don't understand. As with the ASN example, if the problem was inherent in a language, then the language would need to be modified. If the problem was solved by patching software, then the problem must have been in a specific implementation rather than the language. But what is this person talking about? Does he mean IP, or BGP? Does he even know what he means? The problem is not just that the article lacks information, it's that this reporter does not seem to think clearly.
In which case the owner of that URL learns nothing useful about the token. Assuming that the token has a crypto processor on board capable of public-key signature, it neatly prevents this attack. The web server sends a random string, the token signs the string with its private key, and the web server validates the signature with the token's public key. The web server does not gain the ability to impersonate the token.
Just to clarify, the complaint is NOT that the operator requested high power levels and the machine delivered. The complaint is that the operator requested correct power levels, but in the course of editing pressed some cursor control keys in an unanticipated way, causing the machine to mysteriously fry the patients.
I'd only started using Audio Galaxy a week ago, via OpenAG. I was amazed at the depth, speed and reliability. I found pretty much everything I looked for. It was like the heyday of Napster.
It was good while it lasted. Thanks, Audio Galaxy people - you made one of the truly worthwhile things on the internet.
Don't you think it's possible that David is withholding some pieces of the puzzle? It seems like he is only admitting to things that are legal or were already known (stealing smoke detectors). Given his huge appetite for nuclear materials, he may have gone a lot further. In any event, antiques were not the only source of nuclear material cited. Of course it could be fake. But I think we should assume that we are hearing a carefully spun version of the story that is influenced by the chance of criminal prosecution.
That meme irritates me a bit - it seems to imply that evolution never favors risk-taking. Actually, evolution favors a good balance between risk-taking and fear. If you are paralyzed by fear you won't win any "Darwin Awards" on the internet, but you won't get any rewards from life either.
I think most people who talk about "Darwin Awards" are overlooking the fact that death by excessive risk-taking is not the only kind of death - starvation awaits those who do not take enough risks.
That's reasonable, but what if the niche program is open source and the government offers prizes for anyone who can find exploits? There would be a defined time period between exploit notification and publication - adequate to roll out a patched version. This would give lots of people incentive to read the code, as well as incentive not to immediately publish or use the exploits found.
I think the NSA gets close to this level of scrutiny right now by having completely independent groups attack security systems internally.
Actually, it sometimes is like that, especially when Microsoft swallows BSD-licensed code. For example, Microsoft took the free-as-in-air BSD TCP/IP code, mixed in their "colored smoke and fumes" and sold it to their uninformed user base as their own creation. This is why they complain about the GPL being "viral" - they really want to repeat that exploit.
Of course an active, adventurous person could track down and use the code without Microsoft - they have no way to really restrict it - but this is the same as saying that an active, adventurous denizen of the cave could climb up and find an uncontrolled fresh air gap.
The music industry has seen the light with great clarity for quite a while. That's why we got the DMCA and why we're getting the too-long-to-pronounce law. Don't phrase this as a matter of clueless old farts who should "see the light" and join the internet age. It's a matter of an entrenched, wealthy, intelligent elite which will fight to the death to preserve and enhance its privileges and income.
The implication of this "see the light" comment is that the music industry should adapt to changing conditions. But an excellent quote which I can't find right now says, in effect: "Individual organisms do not adapt to changing conditions - the species adapts via the death of ill-adapted organisms".
Actually, it's pretty reasonable. You think it's expensive because you're comparing it to "equivalent" consumer bandwidth. However when you pay for the T1 you are paying for N bits per second - when you pay for consumer bandwidth you're paying for the right to use up to N bits per second if they're available. Naturally, anyone selling consumer bandwidth oversells relative to the real bandwidth he bought. At an oversell ratio of 10:1, which I think is common for consumer bandwidth, you could sell 40 384k connections out of this T1.
I don't understand this argument, but I see it a lot. Opening the network to competition should not mean that AT&T fails to make a profit on the infrastructure they've built. Look at it this way: AT&T builds a railroad to carry minerals from a mine they own. They have two different investments: the mine and the railroad. Now other mine operators want to use the railroad. Naturally, they expect to pay. But AT&T refuses to carry their cargo at all. Under the DSL rules, AT&T would be compelled to provide transport for the other mine operators - not at a loss, but at a reasonable profit. This should not harm their ability to recoup on any investment in the railroad. If it harms their ability to recoup on the mine, then the mine was badly planned.
In any event, the last-mile wiring infrastructure remains a monopoly. The issue is whether that facility should be rented (not given away) to all parties on a non-discriminatory basis, or whether the owner of the infrastructure can leverage its monopoly in last-mile transport to create a monopoly in a totally different market, ISP services and upstream transport.
To me the answer is clear; in fact I believe that any company granted monopoly privileges to provide last-mile transit should be banned from providing upstream internet access - they should merely rent capacity to ISPs who would sell the complete package to customers. That would eliminate the current blatant conflict of interest. I don't see how it would prevent investors in such last-mile infrastructure from recouping investment.
The advances mentioned in the article seem to be improvements in grinding substances finely. The article claims that there is some kind of continuum from this grinding to actual nanotech machines, and that cautious investors are starting at the easy end of the continuum.
I don't see how this could be. It seems that if you want to approach the kind of nanotech described in Stepehenson's The Diamond Age you would probably work with tiny machines and assembly techniques and gradually push the size envelope downwards - which is how it happened with silicon. Or work with subtractive etching techniques that could remove material to leave behind movable parts. Merely grinding up tiny nondescript particles - in other words soot or dust - doesn't seem like a step on this road at all.
Of course my understanding of nanotechnology is firmly grounded in science fiction.
That was interesting, and I hope it gets modded up. I think you touched on something that makes me uneasy about "software design" - design seems to imply redundancy. It's easier to design a bridge than to make one. The drawing package for a bridge is a more compact representation of the underlying structure than the bridge itself.
Repetitive work may be needed in the physical world, but should be automated in the computer world. If a piece of software can be "designed", isn't the design document itself a program? And shouldn't it be run through a preprocessor/compiler/whatever to generate the next stage?
Of course a real engineered artifact might have higher-level design documents which do not contain sufficient detail to build the artifact, but containt sufficient detail that a qualified engineer could use them to develop the detailed design. Maybe within that context it is acceptable to speak of software design or engineering.
By the way, why don't you create an account?
or this:
Couldn't resist.
I haven't found flowcharts to be useful recently - they take a lot of space to cover simple things, and they implicitly describe "spaghetti" code - code which uses jumps or gotos for flow control. For small programs, I generally write the main() function first, keeping it short and clear and invoking a bunch of unwritten functions. At this point I effectively have the interface to those lower functions defined. If the program has to parse a source or config file, I may fill in dummy functions for some of the lower level and test the parser.
Then I flesh in the lower level functions, creating even lower ones where needed. I try to keep each function fairly short - going over 40 lines, let's say, could indicate that an unexpressed function is "swallowed" in your function. Longer functions are sometimes OK, and sometimes it's possible to factor out very short functions that have a clearcut, reusable purpose.
When I code in C, I often start by defining the data structures, but in Perl I haven't felt a need to do this since Perl's data structures are dynamic.
I hope this helps.
xrdb -merge
You cite volume of sales as a figure of merit. So which do you believe is typical of a person who purchased the book?
- He looked at the book before buying, in enough depth that he was fairly sure he liked the book. Implication: the typical purchaser had "astounding mental powers" - or is it less astounding to form a positive opinion?
- He did not read much of the book before buying. Implication: the purchase was based on other factors than the content of the book; therefore the book's standing as a best-selling book is not relevant to its merits.
I don't have the book - you presumably do. Instead of complaining about my bad paraphrase and offering your paraphrase, you could have (and still can) set the record straight with the actual text.Certainly that's a good idea, and you've been helpful in another sense - merely having the patience to answer this type of question repeatedly. However, what I meant by "unhelpful" is not helping the querent reach his goal. Browsing again through your posts on the topic, I realize that most of them may have been made before any keepalive[1] patch was available - so you were probably correct in writing "There is no good way around this at the moment."
However there are good ways around this today, and I think they should be the first answer to someone experiencing mysterious connection failures. There is an accelerating assumption that "the internet" == "the web" and this affects how businesses adopt firewalls. Microsoft is both reacting to and strengthening this mindset with SOAP, which uses pseudo-web traffic. I think ssh clients should be distributed with keepalives enabled. They do no harm when there is no firewall/NAT involved, and they circumvent an increasingly frequent problem. I find the "NAT shortage" theory fairly removed from current reality, given that ssh users are generally a tiny minority. I realize that you may have seen environments where it applies.
Anyhow, my reaction to the book was highly colored by this issue.
[1] The useful kind, that actually keeps the connection alive.
I looked at this book in the bookstore, and everything was either obvious or useless. Maybe this book would have helped me when I didn't know anything about ssh, but between the man pages and Google groups everything you need is available.
What really irritated me was the authors' handling of timeouts and keepalives. It's quite common to be stuck behind a firewall that closes all idle TCP connections. The ssh keepalive functionality does not address this - it's for disconnecting dead sessions, not keeping sessions alive. You need to send some "filler" packets through the TCP connection when it's idle.
This is a frequently asked question. The answer of this book is that you shouldn't send keepalive packets because if "the sysadmin" configured a firewall to kill idle connections, you should just accept this restriction. I hope I don't have to explain how completely wrong this is. Increasingly big organizations have a firewall configured by people who are totally unresponsive.
Anyway, I solved the problem by applying this patch.
One of the book's authors responds to this question on Usenet with the same unhelpful answer found in the book.
From http://www.bynari.net/bynari/products.html.
The server runs on Linux, of course.
Unfortunately, the linked page does not render for me in Netscape/Linux.
Steltor, whose site seems to be broken, makes good scheduling apps that can connect to Outlook. Their server runs on lots of OS's, including Linux. I know one customer, and he's happy.