Any judge would view that dodge as the moral equivalent to going around in public all the time with a Zoro mask over your face in order than no-one can conclude that the Zoro mask implies you are up to something.
The same notion shows up in onion routing: you create a fixed rate stream of false traffic (in this case, random sector rewrites under a changed sector key) and valid traffic merely displaces slots in the fake traffic stream, ensuring that there are no shifts in data rate to analyse or correlate.
In a disk scenario, you'd probably want to move the valid sectors around a lot to disguise the active locations. Flash doesn't much like the extra data churn, and harddrives don't like the acess pattern fragmentation. This application is best suited to a "spintronics" solid-state technology (infinite rewrite cycles, fast, low-cost random access). It'll be a while yet before spin reaches the capacities to convincingly front your undeclared eBay earnings with your porn collection.
But, your honour, I happen to like 32x32 icon-base Anime porn!
I once conceived of this in a Russian doll format: each password supplied decrypts half the remaining unencrypted capacity. When questioned, after each broken limb, you reveal another password, but there is always another smaller region where your secret secret secrets reside. Eventually they throw you into the river. If you drown, you were telling the truth that the last password didn't exist.
Russian proverb: Not wise to get into a pissing competition with a rubber hose.
Nah, these dicks are arguing that denial of service isn't a security issue. That's not a semantic argument, that's just straight ignorance.
One man's ignorance is another man's discernment. Not every site has the same security profile. Some systems are availability-critical (typically found within the military, healthcare, aviation industries) and other systems are integrity-critical (such as the IRS taxpayer database). For systems in the second category a DOS is a highly visible irritation, hardly something to lose sleep over. If it happens more than once, network traffic flows to the machine can be captured an analysed for the triggered event. No taxpayer data is compromised. The case of a remote-root is infinitely more troublesome in the context of an integrity-based system. The data might have been altered/forged months ago. It can be a nearly impossible task to reverse audit the damage that might have been done.
Somehow I doubt there are many OpenBSD instances in between a fighter pilot's stick and the aircraft control surfaces. As a network security measure, I bet there are plenty of OpenBSD installed in integrity-critical environments where an untraceable remote root represents a worst case scenario.
But feel free to lump the two scenarios together if you feel good being the world's smartest person incapable of discernment.
In a phrase, the niche is professional coders, rather than hack-a-day cowboys.
Unfortunately, hack-a-day cowboys gained control of both the house, the senate, and the clone army, so hack-a-day coding practices are now the accepted norm, and people look at you funny when you pinch your brow in abject frustration.
The problem with DbC is that the benefits are best understood by an examination of the system as a whole, rather than the culturally ascendant analysis that permits the cable companies and telcos to put forward the view, in all seriousness, that the demise of net neutrality increases their incentive to invest in their network infrastructure, whereas game theory shows that it has precisely the opposite effect. Most people--in any professional context--are heavily invested not in full systems analysis, but careerist analysis whose principle arguments reference the power hierarchy rather than the behaviour of the system in which the power hierarchy is embedded. The careerist analysis that DbC is relatively worthless is accurate enough in its own scope: after all, the cowboys now rule the world.
I incorporated DbC principles into a large and complex C application (at that time still MSDOS based) shortly after the Meyer book was published in 1988. I never believed that DbC can only be practiced in a language that directly supports it (I regard that as outright language bigotry propoganda). DbC is an intellectual practice. What you can't achieve in a language that doesn't support DbC is the imposition of DbC on participants who don't otherwise choose to participate voluntarily. However, managing to impose DbC on a participant who wouldn't do so voluntarily is at best a hollow victory: compliance over enthusiasm rarely produces the best results.
We imposed DbC by a different tactic. Anyone caught tracing through code in the symbolic debugger was subject to anyone walking past making police siren noises. "How am I supposed to concentrate on debugging this code if everyone is making stupid sound effects?" Answer: "If you have to concentrate that hard to understand your code, you aren't doing it right." Time spent in a debugger produces no asset to the code base, yet it requires the greatest level of concentration. How could that be right?
After we instituted DbC principles, we didn't get many bug reports. Over a three year period, about half of all our bug reports pertained to *one* module written before DbC was instituted. No one wanted to rewrite that module because it involved an external file format which needed to remain compatible, but the exact requirements of the file format were hard to reverse engineer from the conceptually-damaged code base.
The other critical aspect of that situation is that I vetoed many design choices where DbC would have been less beneficial. Some design approaches don't mesh well with DbC. You can still go through the motions, but the conditions you can actually express never catch what you really want to catch at the moment it most needs to be caught. For DbC to work well, you need to choose designs where consistency is a local property of your data structures rather than a global property that can only be enforced by some kind of global fsck. If you have sideways paths into a recursive data structure, you have no hope of checking invariants on the nested context you didn't descend through.
When we did have a bug report, it never took us long to find the code responsible. Most of the plausible theories were eliminated immediately because we shipped with the vast majority of DbC assertions enabled. "This bug would result if function foo returned NULL, but wait, there is a live assertion right here that proves this never happens." Then when we did find the right chunk of code, we rarely felt we needed to test the change for a week or more before shipping out the patch to the affected customer: there was so many assertions in so many directions, it was hard to construct a theory
I built a similar machine for myself just recently with a low end Seasonic and Thermaltake Typhoon for noise control. The machine it replaced was a P3, and I still have a number of fanless P2 machines in my network closet that work just fine for the tasks involved. That said, I also live in an apt in a Canadian city with baseboard electrical heat, so whatever heat I do get from these machines is cost free as far as I'm concerned for six months of the year, as it only diverts electricity out of the baseboard heaters.
On a more serious note, if America was more into responsible government, Intel would answering a lot of questions right now about gigawatts of generation capacity compromised by their hideous P4 design, which I refused to purchase. The computer industry ships several hundred million PCs a year. Over the design lifecycle, Intel must have shipped on the order of half a billion P4 systems all consuming (for no good reason) 30 to 60 watts more than necessary. They had a perfectly good alternative to the power-hungry "Netburst" (pron. "juicesucker") proposed in the design stage. That's pretty hard to justify as a use of resources on a crowded planet.
Too bad we don't have the tape recording of the conversation from Enron to Intel exec holding masses of Enron stock: "Isn't that a beautiful thing? Burn, Prescott, burn." Gotta wonder if some former Intel exec is presently shacked up with his hooker girlfriend on the Cayman islands.
One of the biggest problems with PHP is the die-hard adherance to backwards compatibility. Functions don't get deprecated, the API doesn't change, it gets overloaded with nearly-the-same but-not-quite methods so that somewhere, somebody doesn't complain about how their website "broke" with the latest release--never mind the fact that by using insecure functions, their sites are already broke.
It goes beyond that. When the new API variants are released, details the actual problem resolved are usually found deep in the discussion and not the primary document itself.
Does the main documentation for unserialize call any attention to the hazards associated with it?
I have no particular grudge against PHP. I used it myself for small projects because the language is relatively easy to relearn on the fly. Perl demands too much head space to use it less than once a month. However, when you decided you really want to get a function right, you tear your hair out trying to get an exhaustive account from the online PHP documentation of the issues you need to concern yourself with.
The PHP project brought the month of bugs onto themselves. The simplest measure they could have taken was to make prominent in their online documentation the risks associated with each function PHP provides. I have no problem with caveat emptor. In fact, I've always shunned the languages that attempt to save me despite myself. The lack of prominent "beware of dog" signs in the online PHP documentation is what drives the security split within the PHP community: allowing one camp to remain lax, while the other camp becomes increasingly strident.
I regard this "month of bugs" as long belated complement to the online PHP documentation for concise information on the risk side of the equation.
No amount of extra fiber will help if the routers can't keep up.
I think you are way overstating the cost of smarter and more direct routing topologies with more direct links and fewer hops on the traceroute diagnostic. The other burden on the routing infrastructure is too many small packets. Besides, the YouTube spike is just that: a short term spike where traffic growth exceeds the norm, before falling back onto historical trend lines. We're going to change the politics of the internet as a whole because of a short term spike in YouTube traffic? But I guess that is the overall theme of YouTube content: that the human race is far stupider than we like to admit. Perhaps this is a clasic case of making chicken salad out of chicken shit: human stupidity is just depressing when expressed in a textual media, but worth its weight in chicken feathers when expressed as a three minute video clip. He's my two cents for the network engineers: the pain in your diodes is psychosomatic.
I went to a university in the early 1980s that prided itself on its Math and CS department (still does) and found myself using... WIDJET terminal rooms, 3270 terminal rooms, and interpreted PASCAL on the Commodore Superpet.
Let me tell you what turned out to be the "killer application" on thin clients: the ability to have *multiple* windows open at the same time and *cut and paste* data from one to another.
Comparing the thin clients of yore with the modern thin client is like comparing an airline tray table with a war operations planning facility. Lest we forget...
It's not like there isn't a tradition dating back to the C language of leaving string functions in the language that constituted an open invitation for shoddy programming. It's extremely confusing to the novice programmer to be handed a tool where portions of the language have been extremely clearly thought out intermixed with abortions waiting to happen. Don't give PHP more credit than it deserves. This practice has been with us since forever.
I wonder what ratio of the equipment, colo, and bandwidth costs derive from the massive quantities of fancruft articles at Wikipedia (a rant I skimmed recently gave "list of foods mentioned in Harry Potter" as a representative article). There would be little loss to Wikipedia if *only* the fancruft pages served ads. Not the main entry on Star Wars, but the associated pages that list the length and colour of every character's light saber, or the list of epic fanfic poetry in the Buffyverse. The commercial purpose of Harry Potter, Star Wars, and Buffy's buttocks was to drive ad impressions and merchandise sales. This content would hardly be compromised by Google ad-sense any more than it has already compromised itself.
My feeling is that Wales has already figured this out, and he set up Wikia to skim the lucrative fancruft traffic. He doesn't wish to see adsense on Wikipedia, because his hope is that Wikia will alleviate Wikipedia of the fancruft burden, at great profit to himself, and for the betterment of Wikipedia at the same time.
To keep this in perspective, Wikipedia probably has about the lowest cost structure in terms of pages delivered of any major content site, and it is only a matter of time (two to five years?) before the exponential growth of Wikipedia as measured either in content size or page views delivered falls short of Moore's windfall. 90% of the Wikipedia infrastructure at their Florida colo facility is multi-core scalable (PHP/Apache and Squid servers). Only the expensive database cluster at the very center will scale more slowly than Moore's law now that it has squished sideways into more cores with less GHz.
I take complaints that the Mediawiki Foundation is running out of money with a large grain of salt. The sums are money are a mere trickle measured against the prominence of the asset. To a certain extent, the tax code strongly conditions charities/foundations toward a hand-to-mouth existence. Moreover, it might be strategically advantageous for the WF to keep themselves in poverty. Recalls to mind the line from the movie spoken to Gandhi "do you have any idea how much it costs us to keep you in poverty?" At that point in his life, Gandhi in a three-piece suit wouldn't have been Gandhi any more. I feel the same about Wikipedia. They could save a lot of money by being less broke, but it wouldn't suit the mission.
Lamer alpha: Person C: Yeah, but where do Canadian's live? While Canada might be larger in terms of land area, what if you look at inhabited land area? Lamer beta: Why speculate when three minute's Googling [slashdot.org] gets you an answer?
I've lived in Victoria, Vancouver, Calgary, Edmonton, Waterloo, Toronto, Montreal, and Halifax. Every one of those cities presently enjoys perfectly good broadband. The whole of Canada combined stretched across 5000km doesn't have the population to match the Boston, New York, Baltimore, Washington corridor which is just a short day trip by Canadian standards (I've done Montreal to Boston on bicycle). Do all those cities enjoy excellent and affordable broadband? Not from what I've read about the U.S. telco and cable industries. Perhaps the problem has less to do with population density, and more to do with the fact that America enjoys a huge margin over all other wealthy countries in the areas of litigation and incarceration. The premise in America seems to be that the affluent can afford it no matter what it costs, the impoverished have more pressing concerns, and there is no shortage of lawyers to ensure that never the twain shall meet.
I don't know whether he struck any nails or not, I stopped reading after he suggested returning to IE because CSS hasn't worked out. That reminds me of all the cries for Mozilla to give up and admit failure shortly before the Phoenix/Firefox product branch emerged into the public eye. The reasoning then (among the raving lunatics) seemed to be that four years was too long to wait for product release measured in internet time. Of course, this didn't take into account that the Netscape code base was developed in a scorched earth battle for market share with no allowance for an effective open source development process. What a surprise it took a few years to turn that ship around.
The situation with CSS is not so different. The initial implementations were rushed out with not much concern over getting things precisely right, despite the fact that the promise of CSS largely depends upon hair-splitting correctness. At this point CSS is nearly there, unless you measure by the installed base of web clients that peed in the pool.
The last thing I want from a web rendering standard is consistent appearance. I hate the squinty little fonts used by most web sites at their default settings. No amount of ugliness that results from enlarging the default font size can stop me from reading a well written article. Most of the time I can salvage the overprinted areas by stretching my display window, or using the mouse to select the text region, or even hitting ctrl-U for "display page source" (if the page hasn't tried to be pretty, that's usually easy enough to wade through). The beautiful web sites are the sites I hate most. I once had a girlfriend whose mother had apparently spent the majority of her adult life collecting miniature crystal figurines with fairy wings and little swan necks. She had so many of them they had afixed narrow glass shelves onto the walls (not more than three inches deep) in multiple tiers on both sides of the front door entry way. I had to enter that house like Steve Martin removing a straight-jacket in an undersized phone booth. But that's the kind of web page most web designers seem to like. So balls to the crystal figurine man, I like my CSS the way it is, big and messy and room to swing your elbows around.
So you're the person behind this the whole time: the ideological desire that parties play to form so that no one ever has to think (either within the party, or in the general public) and then, for ice-cream on top, an invocation of the slippery slope argument.
He's another slippery slope argument: what happens when we all stop thinking? Pretty scary boys and girls.
If AMD can produce a better performing chip at 65nm, then who the hell cares if Intel - or anyone else - move to a 45nm process?
Feature size has denominated progress (as measure either by raw performance or performance per watt) over an unbroken 30 year period. Do you recall the very passionate debates about RISC vs CISC? Did a RISC design at one feature size ever beat a CISC design at the next shrink? I think not. Design has never mattered anywhere near as much as feature size. Not that you can't get design wrong. But then you can get a shrink wrong, too, and end up with 1% yields. AMD managed briefly to remain competitive with Intel playing a full shrink behind when Intel did that rather stupid marketron-driven face-plant into the thermal wall (against good advice from their Israel team, who later came to the rescue with Core Duo).
With the recent skyrocket of leakage current, the holy grail of feature size is somewhat tarnished, but it still dominates the performance curve. You completely missed the relationship between feature shrinks and the performance crown. If Intel has better process technology than AMD (almost always) and AMD has a better design (most of the time since the Athlon was first launched) and both companies shrink every 18 months following the Moore projection (that unbroken 30 year historical trend) and AMD always shrinks 9 months behind Intel, then the performance crown will pass back and forth exactly as often as either company announces their next product.
So I agree with you: feature size has no importance to the customer who wants performance for their dollar. Except that you can set your clock by it and project ten years into the future effective performance levels of shrinks we haven't even seen yet. Except for that part, yeah, I'm with you.
The point is: system libraries are ALMOST always better than anything you will be able to write yourself, unless you already specialise in writing such libraries.
If it were that simple, theory and practice would not sleeping in separate beds.
I recall an interview where Theo claimed that a substantial number of bugs discovered in the OpenBSD code audit were created because the programmer failed to understand the library or system API they were programming against. We're talking about simple libraries here, such as the C string library and basic system services such as network programming. Now that I think of it, I have a 1006 page reference entitled Unix Network Programming. The simple API and implied infrastructure is rarely as simple as it is made out to be. The library might be correct in itself, but the program won't be unless the correctness of the library is correctly understood. Not even counting the cases where the API is stupidly designed by those who should have known better, such as the C string functions.
It's rare that a piece of code does exactly what you want it the moment after you download it. If it proves unsatisfactory, do you maintain your own patch branch, or do you try to push your required changes to the upstream maintainer? You might find one library that you can live with without any changes, but what if it conflicts in some way with one of the other five libraries you also need to incorporate? Do all the library components have compatible memory management? Are error conditions handled consistently? Do they all use different string functions?
Some of the best code around has been authored by serious do-it-yourselfers such as Knuth and DJ Bernstein, both of whom wrote complex systems essentially bug free. In Bernstein's case, his strangeness and personality make it hard to use his binaries, much less incorporate his code.
A good example of code seriously engineered for re-use is the Boost C++ library. What most programmers seem determined to ignore is that re-use imposes a serious abstraction penalty. Source code composes nicely only when it was designed to do so, but that design represents a complexity of its own kind.
A final factor I'll mention is that the computational infrastructure improves exponentially. Perfectly sensible coding decisions made when sendmail or vi was authored to cope with extremely limited hardware make far less sense five or ten years later. Why would a programmer wish to adopt a block of code who design reflects constraints which no longer exist (unless the original coder took this explicitly into account). Even Knuth made a bad choice regarding character encoding to satisfy a performance constraint related to machine word size, which created a lot of extra complexity later in grafting in the Asian languages.
It's time we put to rest the notion that code reuse is somehow trivial or automatic. Any simplicity that matters is achieved by hard work.
More than you ever wanted to know? That article contains the least amount anyone needs to know to participate in an informed discussion about future fuel cycles. Far too many people think they are clever enough to discuss fuel sources and carbon cycles because they have figured out how to pump their own gas at the filling station. We're not even at the level here of an intelligent dicussion about a bike shed.
It wasn't long ago I was reading a slashdot thread with a lot of negative posts about the general quality of Wikipedia. I'm increasingly coming to the opinion that improving one sentence in Wikipedia is a better use of my time than any three +5 informative paragraphs here.
It's a huge problem with the hydrocarbon reform movement that the minimum intelligent radius is so much larger than most people are willing to wrap their mental arms around, whereas many other complex subjects at least permit sub-topics to be split off without degenerating into outright pointlessness. This isn't one of those subjects.
I live in a duplex with electric baseboard heat in a corner of Canada with a relatively mild winter. The amazing thing about my incandescent bulbs is that for several months of the year, they function with 100% efficiency: 5% produces light, the other 95% produces heat, which spares my baseboard heaters the trouble of burning off the dust. When I'm working long days in the short days of winter, I'd rather have my heat producing extra light as a by-product.
Smart companies read this report and outsource customer data security infrastructure, which after all is just a cost center, but maintain the same old IT staff to protect their own earth shattering competitive corporate secrets.
For a long time there was endless speculation about a possible back-door embedded by NSA/IBM into the DES S-boxes, but later on it was discovered that the S-boxes selected were optimal against a mode of attack known to the NSA but unknown in the public sector (differential IIRC). People get a little crazy with speculation about NSA back doors. Think about the DES. If the DES had a back door, any stars-and-stripes loathing infidel could potentially have discovered, or bought, or obtained via "special extraction" the billion dollar secret and hacked directly into the US banking system. Do you really think the NSA wants to put an exploitable back door into 600 million copies of Vista and then have to protect that secret forever after from the Arabs, the Chinese, the Korean script kiddies?
My own opinion about DES is that the NSA wanted brute force to be the only viable method and that they developed a capability--not necessarily cost effective--to crack DES by brute force where absolutely necessitated. The fact of the matter is that the NSA is 99% reliant on traffic analysis and only 1% reliant on code breaking (which simply costs too much on the grand scale of modern communications), of which 90% consists of scooping up leaked passwords by simpler means, then the mass-parallel trillion password dictionary attack, and only then bringing to bear real resources.
I've long suspect the NSA implemented a DES cracking chip using electron beam lithography on semiconductor substrates grown in space. They spent a lot of money on space-based crystalography. With enough of a fetish on purity they could potentially have engraved a DES breaking die in the ten to one hundred square centimeter range at transistor sizes comparable to current technology. The problem with electron beam lithography, such as I've been able to discover, is that it is only good for one-off production processes, it doesn't scale. For a DES chip of this nature, it doesn't need to.
In any case, the NSA would far rather possess a single instance of the magic chip funded by a ten billion dollar investment in space technology than a stupid software hole any hammer-and-tongs turban-wearing slant-eyed Kaczynski might someday discover. In the former scenario, your concern over who else might gain possession of the space crystal is largely confined to volcanic islands, and you have people trained to deal with that on a case-by-case basis. The NSA does not have the resources to combat a vast and varied assortment of million bot e-armies controlled by a globally integrated cartel of insurection, drugs, corruption, and cultural fanaticism.
Just about everyone would be better served if Stallman promoted his own brand of "vridom" (self replicating viral-freedom) instead of insisting on what the very broad word "freedom" ought to mean to everyone else, even though his personal slant on the word is narrow, off-center, and twisted almost to the point of counterintuitiveness. If he would content himself to promote "vridom" (or any such word of his own coinage and definition) then maybe finally we could all agree about our disagreements, but Stallman seems not to want that, as if conceding the possibility that others might not agree is too painful to contemplate. Stallman seems to lack faith in his ideas presented on their own terms. He behaves as if he believes debate equals defection. I'm descended from that tribe myself, but I make it a point of conduct not to express those genes.
Interesting timing. I have a E6600 system on order with a $50 Asus EAX550 video card based on the hoary ATI R300 core so I could run an open source video driver. Plenty fast enough for 2D and potentially some low-end (non-game) 3D. I tried hard to find something newer and faster, but failed. Matrox has a fully open source driver for some of its older cards, expensive, with lamentable performance, and the second head wouldn't drive the required frequency, which completely negates Matrox's long standing reputation for excellent finals. What I used to like about Matrox is you always knew what you were getting, even if it was a little behind the curve. Then the day came when Microsoft update pushed a new Matrox driver that eliminated multidesk support with narry a "this might screw you over" or "really do this?" I was in the middle of a deadline push and lost half a day discovering that Matrox had fed this into the Microsoft update pipeline in full deliberation. It proved faster to buy an ATI product than research alternative multidesk implementations in software. Still, I have a fondness for what Matrox used to stand for back when NVidia was setting benchmark records with finals that rendered fifty tints of pastel grey.
Since I collected these links just two days ago, I might as well include them:
I want to use an editor to edit my files, not an operating system like emacs.
Nor do you need Firefox 2.0 with a 200MB process size to access your mailbox. Firefox has a generalized page rendering subsystem. It's a sunk cost, justified by one or two other uses. Emacs has a generalized scripting language, which ironically, is also the love object of a sufficiency cult. What's your point?
With TB disk drives cresting the horizon, what's this stupid thing about delete? I agree that everything should be undoable. The replacement buttons should read "deep six" (equivalent to throwing a document in some unlabled file folder at the back of your filing cabinet) or "Authur Anderson" complete with shreading sound effects and a "Consult you lawyer?" yes/no dialog box.
easily solved by the vendor simply writing perfect software.
Ah yes, the old strawman, haughty and nattily attired. The entire industry knew that Microsoft's integration of IE, Outlook, and ActiveX was a terrible misstep, and Microsoft knew this too, from the moment of first inception. It was a competitive decision to damn the torpedoes and endure the consequences in the aftermath (i.e. by mounting a massive PR campaign to promote responsible disclosure after the barn door was open). "Might makes right" was their design process watch phrase.
When someone steps on a landmine planted on the village footpath, do we term this an accidental death? You're abusing the notion of perfection something fierce. We're not asking for perfection: it would only take pragmatic design and robust implementation on the part of immensely wealthly corporations to eliminate 90% of the mafia involvement that has come to pass.
I'm totally in this camp myself. The only thing responsible disclosure accomplishes is perpetuating the market for software that was written badly in the first place. Consider companies Rock and Scissors. Rock decides to push their product to market first at all cost. Scissors elects to create a development culture that promotes rigorous coding practices. Well, we all know how this story plays out: formation of a rebel Paper alliance. Then the Paper people are accused of being irresponsible for suffocating Rock long *after* Rock has already destroyed Scissors who began with the intent to do it right in the first place. What goes around, comes around. We can break the cycle by accusing Paper of being irresponsible, or we can break the cycle by imposing accountability on Rock. I choose option B. The situation is like one of those terrible Westerns where they end up in a showdown circle drop with everyone pointing guns at the next guy in the saloon. Every option involves a gun. So let's just shoot the guy who started it all by deploying terrible code in the first place.
The error in your reasoning starts when you assume that self-appointed do-gooders have the right to infringe the rights of third parties. (I'm not going to answer any posts about how actually it's just a list and no-one has to use it bla bla - save it for the bar-room barristers.)
You have some gall beginning your post with an analysis of the error in other people's logic while predicating your argument on rights that don't exist and then insisting that if anyone points this out you'll stick your fingers in your ears and hum "nya nya nya nya". Sounds a lot like the behaviour of the ISPs you are seeking to defend.
I wish I had a moderation button that would add your introductory remarks to your slashdot sig for all time.
Slashdot Mirror
Any judge would view that dodge as the moral equivalent to going around in public all the time with a Zoro mask over your face in order than no-one can conclude that the Zoro mask implies you are up to something.
The same notion shows up in onion routing: you create a fixed rate stream of false traffic (in this case, random sector rewrites under a changed sector key) and valid traffic merely displaces slots in the fake traffic stream, ensuring that there are no shifts in data rate to analyse or correlate.
In a disk scenario, you'd probably want to move the valid sectors around a lot to disguise the active locations. Flash doesn't much like the extra data churn, and harddrives don't like the acess pattern fragmentation. This application is best suited to a "spintronics" solid-state technology (infinite rewrite cycles, fast, low-cost random access). It'll be a while yet before spin reaches the capacities to convincingly front your undeclared eBay earnings with your porn collection.
But, your honour, I happen to like 32x32 icon-base Anime porn!
I once conceived of this in a Russian doll format: each password supplied decrypts half the remaining unencrypted capacity. When questioned, after each broken limb, you reveal another password, but there is always another smaller region where your secret secret secrets reside. Eventually they throw you into the river. If you drown, you were telling the truth that the last password didn't exist.
Russian proverb: Not wise to get into a pissing competition with a rubber hose.
One man's ignorance is another man's discernment. Not every site has the same security profile. Some systems are availability-critical (typically found within the military, healthcare, aviation industries) and other systems are integrity-critical (such as the IRS taxpayer database). For systems in the second category a DOS is a highly visible irritation, hardly something to lose sleep over. If it happens more than once, network traffic flows to the machine can be captured an analysed for the triggered event. No taxpayer data is compromised. The case of a remote-root is infinitely more troublesome in the context of an integrity-based system. The data might have been altered/forged months ago. It can be a nearly impossible task to reverse audit the damage that might have been done.
Somehow I doubt there are many OpenBSD instances in between a fighter pilot's stick and the aircraft control surfaces. As a network security measure, I bet there are plenty of OpenBSD installed in integrity-critical environments where an untraceable remote root represents a worst case scenario.
But feel free to lump the two scenarios together if you feel good being the world's smartest person incapable of discernment.
Unfortunately, hack-a-day cowboys gained control of both the house, the senate, and the clone army, so hack-a-day coding practices are now the accepted norm, and people look at you funny when you pinch your brow in abject frustration.
The problem with DbC is that the benefits are best understood by an examination of the system as a whole, rather than the culturally ascendant analysis that permits the cable companies and telcos to put forward the view, in all seriousness, that the demise of net neutrality increases their incentive to invest in their network infrastructure, whereas game theory shows that it has precisely the opposite effect. Most people--in any professional context--are heavily invested not in full systems analysis, but careerist analysis whose principle arguments reference the power hierarchy rather than the behaviour of the system in which the power hierarchy is embedded. The careerist analysis that DbC is relatively worthless is accurate enough in its own scope: after all, the cowboys now rule the world.
I incorporated DbC principles into a large and complex C application (at that time still MSDOS based) shortly after the Meyer book was published in 1988. I never believed that DbC can only be practiced in a language that directly supports it (I regard that as outright language bigotry propoganda). DbC is an intellectual practice. What you can't achieve in a language that doesn't support DbC is the imposition of DbC on participants who don't otherwise choose to participate voluntarily. However, managing to impose DbC on a participant who wouldn't do so voluntarily is at best a hollow victory: compliance over enthusiasm rarely produces the best results.
We imposed DbC by a different tactic. Anyone caught tracing through code in the symbolic debugger was subject to anyone walking past making police siren noises. "How am I supposed to concentrate on debugging this code if everyone is making stupid sound effects?" Answer: "If you have to concentrate that hard to understand your code, you aren't doing it right." Time spent in a debugger produces no asset to the code base, yet it requires the greatest level of concentration. How could that be right?
After we instituted DbC principles, we didn't get many bug reports. Over a three year period, about half of all our bug reports pertained to *one* module written before DbC was instituted. No one wanted to rewrite that module because it involved an external file format which needed to remain compatible, but the exact requirements of the file format were hard to reverse engineer from the conceptually-damaged code base.
The other critical aspect of that situation is that I vetoed many design choices where DbC would have been less beneficial. Some design approaches don't mesh well with DbC. You can still go through the motions, but the conditions you can actually express never catch what you really want to catch at the moment it most needs to be caught. For DbC to work well, you need to choose designs where consistency is a local property of your data structures rather than a global property that can only be enforced by some kind of global fsck. If you have sideways paths into a recursive data structure, you have no hope of checking invariants on the nested context you didn't descend through.
When we did have a bug report, it never took us long to find the code responsible. Most of the plausible theories were eliminated immediately because we shipped with the vast majority of DbC assertions enabled. "This bug would result if function foo returned NULL, but wait, there is a live assertion right here that proves this never happens." Then when we did find the right chunk of code, we rarely felt we needed to test the change for a week or more before shipping out the patch to the affected customer: there was so many assertions in so many directions, it was hard to construct a theory
I built a similar machine for myself just recently with a low end Seasonic and Thermaltake Typhoon for noise control. The machine it replaced was a P3, and I still have a number of fanless P2 machines in my network closet that work just fine for the tasks involved. That said, I also live in an apt in a Canadian city with baseboard electrical heat, so whatever heat I do get from these machines is cost free as far as I'm concerned for six months of the year, as it only diverts electricity out of the baseboard heaters.
On a more serious note, if America was more into responsible government, Intel would answering a lot of questions right now about gigawatts of generation capacity compromised by their hideous P4 design, which I refused to purchase. The computer industry ships several hundred million PCs a year. Over the design lifecycle, Intel must have shipped on the order of half a billion P4 systems all consuming (for no good reason) 30 to 60 watts more than necessary. They had a perfectly good alternative to the power-hungry "Netburst" (pron. "juicesucker") proposed in the design stage. That's pretty hard to justify as a use of resources on a crowded planet.
Too bad we don't have the tape recording of the conversation from Enron to Intel exec holding masses of Enron stock: "Isn't that a beautiful thing? Burn, Prescott, burn." Gotta wonder if some former Intel exec is presently shacked up with his hooker girlfriend on the Cayman islands.
No amount of extra fiber will help if the routers can't keep up.
I think you are way overstating the cost of smarter and more direct routing topologies with more direct links and fewer hops on the traceroute diagnostic. The other burden on the routing infrastructure is too many small packets. Besides, the YouTube spike is just that: a short term spike where traffic growth exceeds the norm, before falling back onto historical trend lines. We're going to change the politics of the internet as a whole because of a short term spike in YouTube traffic? But I guess that is the overall theme of YouTube content: that the human race is far stupider than we like to admit. Perhaps this is a clasic case of making chicken salad out of chicken shit: human stupidity is just depressing when expressed in a textual media, but worth its weight in chicken feathers when expressed as a three minute video clip. He's my two cents for the network engineers: the pain in your diodes is psychosomatic.
I went to a university in the early 1980s that prided itself on its Math and CS department (still does) and found myself using
Let me tell you what turned out to be the "killer application" on thin clients: the ability to have *multiple* windows open at the same time and *cut and paste* data from one to another.
Comparing the thin clients of yore with the modern thin client is like comparing an airline tray table with a war operations planning facility. Lest we forget
It's not like there isn't a tradition dating back to the C language of leaving string functions in the language that constituted an open invitation for shoddy programming. It's extremely confusing to the novice programmer to be handed a tool where portions of the language have been extremely clearly thought out intermixed with abortions waiting to happen. Don't give PHP more credit than it deserves. This practice has been with us since forever.
I wonder what ratio of the equipment, colo, and bandwidth costs derive from the massive quantities of fancruft articles at Wikipedia (a rant I skimmed recently gave "list of foods mentioned in Harry Potter" as a representative article). There would be little loss to Wikipedia if *only* the fancruft pages served ads. Not the main entry on Star Wars, but the associated pages that list the length and colour of every character's light saber, or the list of epic fanfic poetry in the Buffyverse. The commercial purpose of Harry Potter, Star Wars, and Buffy's buttocks was to drive ad impressions and merchandise sales. This content would hardly be compromised by Google ad-sense any more than it has already compromised itself.
My feeling is that Wales has already figured this out, and he set up Wikia to skim the lucrative fancruft traffic. He doesn't wish to see adsense on Wikipedia, because his hope is that Wikia will alleviate Wikipedia of the fancruft burden, at great profit to himself, and for the betterment of Wikipedia at the same time.
To keep this in perspective, Wikipedia probably has about the lowest cost structure in terms of pages delivered of any major content site, and it is only a matter of time (two to five years?) before the exponential growth of Wikipedia as measured either in content size or page views delivered falls short of Moore's windfall. 90% of the Wikipedia infrastructure at their Florida colo facility is multi-core scalable (PHP/Apache and Squid servers). Only the expensive database cluster at the very center will scale more slowly than Moore's law now that it has squished sideways into more cores with less GHz.
I take complaints that the Mediawiki Foundation is running out of money with a large grain of salt. The sums are money are a mere trickle measured against the prominence of the asset. To a certain extent, the tax code strongly conditions charities/foundations toward a hand-to-mouth existence. Moreover, it might be strategically advantageous for the WF to keep themselves in poverty. Recalls to mind the line from the movie spoken to Gandhi "do you have any idea how much it costs us to keep you in poverty?" At that point in his life, Gandhi in a three-piece suit wouldn't have been Gandhi any more. I feel the same about Wikipedia. They could save a lot of money by being less broke, but it wouldn't suit the mission.
Lamer alpha: Person C: Yeah, but where do Canadian's live? While Canada might be larger in terms of land area, what if you look at inhabited land area?
Lamer beta: Why speculate when three minute's Googling [slashdot.org] gets you an answer?
I've lived in Victoria, Vancouver, Calgary, Edmonton, Waterloo, Toronto, Montreal, and Halifax. Every one of those cities presently enjoys perfectly good broadband. The whole of Canada combined stretched across 5000km doesn't have the population to match the Boston, New York, Baltimore, Washington corridor which is just a short day trip by Canadian standards (I've done Montreal to Boston on bicycle). Do all those cities enjoy excellent and affordable broadband? Not from what I've read about the U.S. telco and cable industries. Perhaps the problem has less to do with population density, and more to do with the fact that America enjoys a huge margin over all other wealthy countries in the areas of litigation and incarceration. The premise in America seems to be that the affluent can afford it no matter what it costs, the impoverished have more pressing concerns, and there is no shortage of lawyers to ensure that never the twain shall meet.
I don't know whether he struck any nails or not, I stopped reading after he suggested returning to IE because CSS hasn't worked out. That reminds me of all the cries for Mozilla to give up and admit failure shortly before the Phoenix/Firefox product branch emerged into the public eye. The reasoning then (among the raving lunatics) seemed to be that four years was too long to wait for product release measured in internet time. Of course, this didn't take into account that the Netscape code base was developed in a scorched earth battle for market share with no allowance for an effective open source development process. What a surprise it took a few years to turn that ship around.
The situation with CSS is not so different. The initial implementations were rushed out with not much concern over getting things precisely right, despite the fact that the promise of CSS largely depends upon hair-splitting correctness. At this point CSS is nearly there, unless you measure by the installed base of web clients that peed in the pool.
The last thing I want from a web rendering standard is consistent appearance. I hate the squinty little fonts used by most web sites at their default settings. No amount of ugliness that results from enlarging the default font size can stop me from reading a well written article. Most of the time I can salvage the overprinted areas by stretching my display window, or using the mouse to select the text region, or even hitting ctrl-U for "display page source" (if the page hasn't tried to be pretty, that's usually easy enough to wade through). The beautiful web sites are the sites I hate most. I once had a girlfriend whose mother had apparently spent the majority of her adult life collecting miniature crystal figurines with fairy wings and little swan necks. She had so many of them they had afixed narrow glass shelves onto the walls (not more than three inches deep) in multiple tiers on both sides of the front door entry way. I had to enter that house like Steve Martin removing a straight-jacket in an undersized phone booth. But that's the kind of web page most web designers seem to like. So balls to the crystal figurine man, I like my CSS the way it is, big and messy and room to swing your elbows around.
So you're the person behind this the whole time: the ideological desire that parties play to form so that no one ever has to think (either within the party, or in the general public) and then, for ice-cream on top, an invocation of the slippery slope argument.
He's another slippery slope argument: what happens when we all stop thinking? Pretty scary boys and girls.
Feature size has denominated progress (as measure either by raw performance or performance per watt) over an unbroken 30 year period. Do you recall the very passionate debates about RISC vs CISC? Did a RISC design at one feature size ever beat a CISC design at the next shrink? I think not. Design has never mattered anywhere near as much as feature size. Not that you can't get design wrong. But then you can get a shrink wrong, too, and end up with 1% yields. AMD managed briefly to remain competitive with Intel playing a full shrink behind when Intel did that rather stupid marketron-driven face-plant into the thermal wall (against good advice from their Israel team, who later came to the rescue with Core Duo).
With the recent skyrocket of leakage current, the holy grail of feature size is somewhat tarnished, but it still dominates the performance curve. You completely missed the relationship between feature shrinks and the performance crown. If Intel has better process technology than AMD (almost always) and AMD has a better design (most of the time since the Athlon was first launched) and both companies shrink every 18 months following the Moore projection (that unbroken 30 year historical trend) and AMD always shrinks 9 months behind Intel, then the performance crown will pass back and forth exactly as often as either company announces their next product.
So I agree with you: feature size has no importance to the customer who wants performance for their dollar. Except that you can set your clock by it and project ten years into the future effective performance levels of shrinks we haven't even seen yet. Except for that part, yeah, I'm with you.
I recall an interview where Theo claimed that a substantial number of bugs discovered in the OpenBSD code audit were created because the programmer failed to understand the library or system API they were programming against. We're talking about simple libraries here, such as the C string library and basic system services such as network programming. Now that I think of it, I have a 1006 page reference entitled Unix Network Programming. The simple API and implied infrastructure is rarely as simple as it is made out to be. The library might be correct in itself, but the program won't be unless the correctness of the library is correctly understood. Not even counting the cases where the API is stupidly designed by those who should have known better, such as the C string functions.
It's rare that a piece of code does exactly what you want it the moment after you download it. If it proves unsatisfactory, do you maintain your own patch branch, or do you try to push your required changes to the upstream maintainer? You might find one library that you can live with without any changes, but what if it conflicts in some way with one of the other five libraries you also need to incorporate? Do all the library components have compatible memory management? Are error conditions handled consistently? Do they all use different string functions?
Some of the best code around has been authored by serious do-it-yourselfers such as Knuth and DJ Bernstein, both of whom wrote complex systems essentially bug free. In Bernstein's case, his strangeness and personality make it hard to use his binaries, much less incorporate his code.
A good example of code seriously engineered for re-use is the Boost C++ library. What most programmers seem determined to ignore is that re-use imposes a serious abstraction penalty. Source code composes nicely only when it was designed to do so, but that design represents a complexity of its own kind.
A final factor I'll mention is that the computational infrastructure improves exponentially. Perfectly sensible coding decisions made when sendmail or vi was authored to cope with extremely limited hardware make far less sense five or ten years later. Why would a programmer wish to adopt a block of code who design reflects constraints which no longer exist (unless the original coder took this explicitly into account). Even Knuth made a bad choice regarding character encoding to satisfy a performance constraint related to machine word size, which created a lot of extra complexity later in grafting in the Asian languages.
It's time we put to rest the notion that code reuse is somehow trivial or automatic. Any simplicity that matters is achieved by hard work.
More than you ever wanted to know? That article contains the least amount anyone needs to know to participate in an informed discussion about future fuel cycles. Far too many people think they are clever enough to discuss fuel sources and carbon cycles because they have figured out how to pump their own gas at the filling station. We're not even at the level here of an intelligent dicussion about a bike shed.
It wasn't long ago I was reading a slashdot thread with a lot of negative posts about the general quality of Wikipedia. I'm increasingly coming to the opinion that improving one sentence in Wikipedia is a better use of my time than any three +5 informative paragraphs here.
It's a huge problem with the hydrocarbon reform movement that the minimum intelligent radius is so much larger than most people are willing to wrap their mental arms around, whereas many other complex subjects at least permit sub-topics to be split off without degenerating into outright pointlessness. This isn't one of those subjects.
I live in a duplex with electric baseboard heat in a corner of Canada with a relatively mild winter. The amazing thing about my incandescent bulbs is that for several months of the year, they function with 100% efficiency: 5% produces light, the other 95% produces heat, which spares my baseboard heaters the trouble of burning off the dust. When I'm working long days in the short days of winter, I'd rather have my heat producing extra light as a by-product.
Smart companies read this report and outsource customer data security infrastructure, which after all is just a cost center, but maintain the same old IT staff to protect their own earth shattering competitive corporate secrets.
For a long time there was endless speculation about a possible back-door embedded by NSA/IBM into the DES S-boxes, but later on it was discovered that the S-boxes selected were optimal against a mode of attack known to the NSA but unknown in the public sector (differential IIRC). People get a little crazy with speculation about NSA back doors. Think about the DES. If the DES had a back door, any stars-and-stripes loathing infidel could potentially have discovered, or bought, or obtained via "special extraction" the billion dollar secret and hacked directly into the US banking system. Do you really think the NSA wants to put an exploitable back door into 600 million copies of Vista and then have to protect that secret forever after from the Arabs, the Chinese, the Korean script kiddies?
My own opinion about DES is that the NSA wanted brute force to be the only viable method and that they developed a capability--not necessarily cost effective--to crack DES by brute force where absolutely necessitated. The fact of the matter is that the NSA is 99% reliant on traffic analysis and only 1% reliant on code breaking (which simply costs too much on the grand scale of modern communications), of which 90% consists of scooping up leaked passwords by simpler means, then the mass-parallel trillion password dictionary attack, and only then bringing to bear real resources.
I've long suspect the NSA implemented a DES cracking chip using electron beam lithography on semiconductor substrates grown in space. They spent a lot of money on space-based crystalography. With enough of a fetish on purity they could potentially have engraved a DES breaking die in the ten to one hundred square centimeter range at transistor sizes comparable to current technology. The problem with electron beam lithography, such as I've been able to discover, is that it is only good for one-off production processes, it doesn't scale. For a DES chip of this nature, it doesn't need to.
In any case, the NSA would far rather possess a single instance of the magic chip funded by a ten billion dollar investment in space technology than a stupid software hole any hammer-and-tongs turban-wearing slant-eyed Kaczynski might someday discover. In the former scenario, your concern over who else might gain possession of the space crystal is largely confined to volcanic islands, and you have people trained to deal with that on a case-by-case basis. The NSA does not have the resources to combat a vast and varied assortment of million bot e-armies controlled by a globally integrated cartel of insurection, drugs, corruption, and cultural fanaticism.
Just about everyone would be better served if Stallman promoted his own brand of "vridom" (self replicating viral-freedom) instead of insisting on what the very broad word "freedom" ought to mean to everyone else, even though his personal slant on the word is narrow, off-center, and twisted almost to the point of counterintuitiveness. If he would content himself to promote "vridom" (or any such word of his own coinage and definition) then maybe finally we could all agree about our disagreements, but Stallman seems not to want that, as if conceding the possibility that others might not agree is too painful to contemplate. Stallman seems to lack faith in his ideas presented on their own terms. He behaves as if he believes debate equals defection. I'm descended from that tribe myself, but I make it a point of conduct not to express those genes.
Interesting timing. I have a E6600 system on order with a $50 Asus EAX550 video card based on the hoary ATI R300 core so I could run an open source video driver. Plenty fast enough for 2D and potentially some low-end (non-game) 3D. I tried hard to find something newer and faster, but failed. Matrox has a fully open source driver for some of its older cards, expensive, with lamentable performance, and the second head wouldn't drive the required frequency, which completely negates Matrox's long standing reputation for excellent finals. What I used to like about Matrox is you always knew what you were getting, even if it was a little behind the curve. Then the day came when Microsoft update pushed a new Matrox driver that eliminated multidesk support with narry a "this might screw you over" or "really do this?" I was in the middle of a deadline push and lost half a day discovering that Matrox had fed this into the Microsoft update pipeline in full deliberation. It proved faster to buy an ATI product than research alternative multidesk implementations in software. Still, I have a fondness for what Matrox used to stand for back when NVidia was setting benchmark records with finals that rendered fifty tints of pastel grey.
. odp -- DCC 2006, MIME problem, but opens with evince directlys .sxi -- DCC 2005, didn't read this one myselfm =576&num=1m =463&num=1
Since I collected these links just two days ago, I might as well include them:
http://www.skynet.ie/~airlied/talks/ols06/ols2006
http://www.skynet.ie/~airlied/talks/ddc05/ddc_pre
http://free3d.org/
http://intellinuxgraphics.org/
http://dri.freedesktop.org/wiki/
http://www.phoronix.com/scan.php?page=article&ite
http://www.phoronix.com/scan.php?page=article&ite
I want to use an editor to edit my files, not an operating system like emacs.
Nor do you need Firefox 2.0 with a 200MB process size to access your mailbox. Firefox has a generalized page rendering subsystem. It's a sunk cost, justified by one or two other uses. Emacs has a generalized scripting language, which ironically, is also the love object of a sufficiency cult. What's your point?
With TB disk drives cresting the horizon, what's this stupid thing about delete? I agree that everything should be undoable. The replacement buttons should read "deep six" (equivalent to throwing a document in some unlabled file folder at the back of your filing cabinet) or "Authur Anderson" complete with shreading sound effects and a "Consult you lawyer?" yes/no dialog box.
easily solved by the vendor simply writing perfect software.
Ah yes, the old strawman, haughty and nattily attired. The entire industry knew that Microsoft's integration of IE, Outlook, and ActiveX was a terrible misstep, and Microsoft knew this too, from the moment of first inception. It was a competitive decision to damn the torpedoes and endure the consequences in the aftermath (i.e. by mounting a massive PR campaign to promote responsible disclosure after the barn door was open). "Might makes right" was their design process watch phrase.
When someone steps on a landmine planted on the village footpath, do we term this an accidental death? You're abusing the notion of perfection something fierce. We're not asking for perfection: it would only take pragmatic design and robust implementation on the part of immensely wealthly corporations to eliminate 90% of the mafia involvement that has come to pass.
I'm totally in this camp myself. The only thing responsible disclosure accomplishes is perpetuating the market for software that was written badly in the first place. Consider companies Rock and Scissors. Rock decides to push their product to market first at all cost. Scissors elects to create a development culture that promotes rigorous coding practices. Well, we all know how this story plays out: formation of a rebel Paper alliance. Then the Paper people are accused of being irresponsible for suffocating Rock long *after* Rock has already destroyed Scissors who began with the intent to do it right in the first place. What goes around, comes around. We can break the cycle by accusing Paper of being irresponsible, or we can break the cycle by imposing accountability on Rock. I choose option B. The situation is like one of those terrible Westerns where they end up in a showdown circle drop with everyone pointing guns at the next guy in the saloon. Every option involves a gun. So let's just shoot the guy who started it all by deploying terrible code in the first place.
The error in your reasoning starts when you assume that self-appointed do-gooders have the right to infringe the rights of third parties. (I'm not going to answer any posts about how actually it's just a list and no-one has to use it bla bla - save it for the bar-room barristers.)
You have some gall beginning your post with an analysis of the error in other people's logic while predicating your argument on rights that don't exist and then insisting that if anyone points this out you'll stick your fingers in your ears and hum "nya nya nya nya". Sounds a lot like the behaviour of the ISPs you are seeking to defend.
I wish I had a moderation button that would add your introductory remarks to your slashdot sig for all time.