if access to the source mattered, he wouldn't be running Vista. conversely, if he's comfortable running Vista, running a closed-source app alongside all his other closed-source apps on his proprietary, DRM-ridden OS shouldn't be an issue.
I can see reasonable people going both ways, myself - I just find the particular combination of requirements by the OP to be unusual enough to warrant further explanation.
yes, yes there are lots of DNS requests. And there is cacheing at every single layer of the infrastructure, including most importantly: * client resolver library * client's upstream nameservers (recursive-only generally, operated by their ISP) * any add'l upstream DNS architecture between the client's nameservers and the SOA
point being that billions of DNS requests generated daily for e.g. google.com are NOT all individually served by Google's nameservers. A small percentage of the total actually comes all the way through; the rest are handled by cacheing (one of the primary design goals of the protocol).
A proper architecture will do more to improve site performance (and reduce burden on the network) than any amount of changes to the software you're using to serve DNS. The slowdown you're referring to is much more likely to occur closer to the edge than in the core of the ISP (where DNS server performance are a factor).
BIND is not the problem. DNS isn't even the problem (unless you've got some really boneheaded setups). _architecture_, in a general sense (from systems to storage to networking to web page content to CDN to GSLB to peering to geographic distribution of datacenters), is the problem. DNS is a very small facet of the overall problem (it can be a problem, granted - but it's hardly the most significant one, or even in the top 5 the vast majority of the time).
yeah, I think he really does. GP is right: to request a solution that's both open source _and_ runs on Vista at least entitles us to know why in the world those two mutually-exclusive philosophies are both requirements.
Seriously, didn't this strike anybody else as bizarre when you read the article summary? If F/OSS is a requirement in the database portion, why not in the OS? Better yet, if it's a requirement in the database portion, why not just pick an OS best-suited for that task (bdb on *nix is the canonical answer, and has been for 10+ years).
It's almost as if the article summary were a thinly-disguised troll... nah, couldn't be.
If DNS traffic is your bottleneck, you don't have a bottleneck.
Seriously, "DNS traffic grows faster than the overall traffic"? Maybe if you're doing a lot of TCP-over-DNS (thanks, Dan Kaminsky), or if you are providing DNS hosting services. Otherwise, I fail to see how a primarily UDP-based, extremely lightweight protocol (designed for cacheing at every layer, mind you) can grow faster than HTTP or whatever your traffic is.
Again, if DNS is your bottleneck, you've got something that's not designed properly, or are providing DNS hosting as a service (and probably still have something not designed properly). 100K zones is slow to startup? How about not putting 100K zones on the same servers? SPOF much?
I'm not arguing that BIND is the fastest, cleanest, most secure implementation out there (that title probably belongs to djbdns; I have yet to see a security hole published in any of his stuff - too bad it's such a hassle to use), but if your architecture is such that BIND's bugs are biting you, I would argue that BIND is _not_ your biggest problem.
If we could focus on fixing bugs and not see everything through the lens of security...
This is exactly the approach that e.g. the OpenBSD dev team takes - all bugs are squashed with equanimity. They don't consider bugs to be "less critical" because they don't represent an apparent security threat or come with an obvious exploit. This kind of consistent code-review housecleaning has the nice side effect of avoiding many security holes before they are even discovered. (See http://www.openbsd.org/security.html for more on this philosophy.)
But the point of my original post was that kernel architecture and other technical issues NOT our collective big problem when it comes to security: the most pernicious, most easily and frequently exploited, and most difficult to patch holes are human in nature. Whether it's social engineering (e.g. phishing) or bad architecture (unnecessary features, trusting in the firewall for all your security, etc; see my previous post), humans (both users and engineers/admins) are the biggest source of risk to infrastructures large and small (down to and including the home desktop user).
Unfortuantely, there are very few technical solutions to problems in this space.
system hardening is effective at defeating certain classes of attacks. that said, most security breaches are NOT due to fancy footwork with memcpy or other low-level wizardry. They're due to either:
1) improperly designed trusts between systems (e.g. the Internet can't talk to my database server, but my webserver has full access; when my webserver is compromised, the contents of my database are toast as well). Networks designed to fail safely and gracefully, with liberal application of the principle of least privilege, help mitigate this kind of risk.
2) stupid user tricks (I place social engineering in this category, along with phishing and the majority of email viruses). There is no technical solution for this essentially social problem - education helps, sane and safe defaults help tremendously (every unnecessary feature is an additional security risk, and the risk compounds as features are added), software policy approaches like ACL/MAC/UAC/RBAC help... but in the end, users just want to do whatever it is they're using the computer for. If an attacker can convincingly pretend to be legitimate, or present a convincing enough temptation, users will bypass, override or disregard any level of protection. Vista's UAC is the canonical example here - great idea foiled by end users (granted, the implementation was almost guaranteed to train users to eventually ignore the constant repeated warnings).
when I said "your choices are to exchange traffic with me, or not, but you don't get to tell me how to run things [on my network" I was speaking as a network operator, not an end-user. End users don't exchange traffic in the sense I was speaking of; they consume (p2p notwithstanding; I was using "exchange" in the sense of peering).
for the record, I completely agree with the points you made:
* gov't regulation (or lack thereof), combined with a woeful lack of due diligence in ensuring taxpayer investment sees a decent return (the POTS system was almost entirely subsidized by taxpayer dollars, and we're still paying for that initial investment in the form of surcharges and taxes on copper laid a hundred years ago in some cases, with further technological deployments (e.g. FTTP) coming late or not at all, and always with grudging complaint on the part of telcos and hints that more subsidies and monopoly support are required to "encourage" further development).
* Many, if not most, ISPs are blatantly lying in terms of what's advertised versus what they can actually deliver (and the fine print end users have to agree to in order to get a connection allows the ISP to deliver any class of service it likes, with no recourse for the customer aside from switching providers, which often isn't an option). I firmly believe that an ISP that offers unlimited Internet access should have to deliver the Webster's definition of "unlimited", or else call the offering something else.
* the vast majority of subscribers face a duopoly, at best (and one that's entrenched and is focused primarily on maximizing return on existing investment, rather than deploying new technology to stay ahead of competition - when there isn't any competition, you don't have to offer much to stay profitable).... that said, the point I was trying to make was in response to the perhaps unintentional editorializing from Rob's tagline on the story. It's not a democracy because 1) it wasn't designed as any such thing - it's a loose confederation of autonomous systems; 2) most systems were not (and are not) directly or indirectly established and maintained by the general public of any single country or locale - why should the residents of $random_{city,county,state,country} be able to dictate operational policy for $random_privately_held_ISP? (but see my points above re: artificial monopoly and public subsidy; I'm in favor of a good return on public investment)
I think the feds have been entirely too chummy with Ma Bell (and the cablecos, and BigCorp in general) for the last several decades. However, I'm very skeptical that the answer to poor federal legislation is additional federal legislation. Our Congress has repeatedly demonstrated an uncanny ability to confuse and pervert even the clearest and most uncomplicated issues into a tangled morass of legislation that benefits only lawyers, legislators and those with the money to get the latter re-elected.
I suspect that the proposed cure for network neutrality woes would be worse than the disease in the long run.
because the Internet is a group of autonomous systems (hence the identifier "ASN") agreeing to exchange traffic for as long as it makes sense for them to do so. There is no central Internet "authority" (despite what Dept of Commerce, NetSol, Congress and others keep trying to assert) - your rules end at the edge of my network. Your choices are to exchange traffic with me, or not, but you don't get to tell me how to run things (modulo the usual civil and criminal codes regarding the four horsemen of the information apocalypse). Advocates of network neutrality legislation would clearly like to have some add'l regulatory framework in place to provide a stronger encouragement to "good behavior" (as set out in the RFCs and in the early history of internetworks and the hacking community) than the market provides in some cases. It remains to be seen whether the benefits provided by that framework would at all outweigh the inevitable loopholes, unintended consequences and general heavy-handed cluelessness that's been the hallmark of any federal technology legislation.
Those networks that show consistently boorish behavior to other networks eventually find themselves isolated or losing customers (e.g. Cogent, although somehow they still manage to retain some business - doubtless due to the fact that they're the cheapest transit you can scrape by with in most cases, although anybody who relies on them is inevitably sorry).
The Internet will be a democracy when every part of the network is funded, built and maintained by the general public. Until then, it's a loose confederation of independent networks who cooperate when it makes sense to do so. Fortunately, the exceedingly wise folks that wrote the protocols that made these networks possible did so in a manner that encourages interconnectivity (and most large networks tend to be operated by folks with similar clue - when they're not, see the previous paragraph).
Not everything can be (or even should be) a democracy. Now get off my lawn, you damn hippies.
basically, the requirements for a successful 'exploit' are a poorly-attended system without even the most basic safeguards against abuse.
but mostly, who's Amit Klein? He may be brilliant, or he may be Gobbles (or somewhere in between). I don't know - but the OpenBSD team has a history of making smart decisions and doing the kind of development that has earned my trust. When presented with a scenario I can't necessarily judge for myself, and given the OpenBSD dev team on one side and $random_guy on the other, I think I'll trust the side that's already earned my trust, until they do something to lose it.
have you even read his report? I have, several times, and I see no claims that aren't substantiated/attributed to third parties (usually folks who would know, like hardware manufacturers), or else lifted directly from the documentation or quoted from Vista developers.
Ad hominems are easy... what points, in particular, do you disagree with Gutmann on? What are _your_ credentials (are you teaching cryptography somewhere, for instance)? If you haven't got anything more substantial than "this guy is full of it", don't be surprised if you aren't taken seriously.
required reading for ANY discussion of Vista cost/performance issues. I was kind of surprised not to see the URL come up in the discussion thus far, so I dropped my mod points for this story in favor of posting instead.
Bottom line: if Microsoft had put the focus of Vista development on actually making the best-performing OS they could, instead of making digital restrictions the number one feature, the OS would very likely have been one of the best releases in recent memory. Instead, features and performance came in _explicitly_ behind DRM at every level of development and marketing (including Vista Compatible branding).
I have a Deity, and a holy Book, and I find wisdom therein.:) However, said Deity also blessed me with a brain and some common sense, and I am rather more willing to consult both of those than random strangers (well-regarded, educated or otherwise) who have no personal knowledge of me or my kids.
I wouldn't mod you troll - but I also don't feel any particular need to consult "experts" (aside from my folks, who have already demonstrated their wisdom and experience to me, and others who have already gained my trust) for advice. However, I also don't disregard advice from someone just because they're a stranger - wisdom can come from many places.
(infrequently found in slashdot comments though:))
When you find somebody who's really qualified to give "expert" opinions on how random people should raise their kids (keeping in mind situations and kids and parents are all different in many ways), you let me know.
In the meantime... I'm entirely comfortable making my own decisions on how to raise my kids (4.5 and 2). The 4yo would play Yoshi's Island (DS) every waking hour if we let her, but we don't.:) She's learned letters, numbers, colors, phonics, reading and basic math through a combination of us reading with her, educational games (LeapFrog is your friend here), websites like starfall.com (hat tip to Gabe @ Penny-Arcade) and good old-fashioned one-on-one teaching and repetition.
Games have their place, just like anything else (including computers; she can't type yet, but she can navigate her favorite educational websites just fine). They're no more or less dangerous to kids' development than Baby Einstein videos, or educational TV, or pop-up books, or [insert controversial newfangled technology here].
The key here, as with everything else in life, is moderation and good sense.
if you haven't read it, you should go give Pierre Oulette's first novel a shot... it's a little dated on some of the technology concepts, but some of the biotech/GE stuff is still beyond us for the foreseeable future. If you find the idea of robot (or better yet, cyborg) flies or even larger, stranger creatures interesting (especially when designed/powered by a sentient AI), you would probably enjoy the book. Read it back when I was in high school, and just ordered a copy from Amazon to fill an empty spot in my bookshelf...
wouldn't have been fired in the first place, and if he was fired,
wouldn't have been caught, and if he was caught,
wouldn't have been prosecuted.
This guy was merely a pretender to the title, and clearly was not familiar with the extensive body of work on the subject. No true Bastard would ever allow such a demeaning sequence of events to occur under his tenure...
the answer to five 9s uptime is to stop building systems that rely on single points of failure. Compare Google's approach to processing and uptime to that of the mainframe era. Totally different infrastructures with similar goals and globally, similar uptimes/reliabilities. Design your systems such that any component (any switch, router, power supply, hard drive, server... to a certain degree, even any individual data center) can fail without resulting in a loss of data. Sure, it's complicated - but it can be done, and it's definitely the direction that network and systems architectures are headed.
in all things, moderation. I turn my phone (HTC Hermes) off when I go to sleep, but mostly just because the incessant GSM buzz on my clock radio drives the wife and I nuts. I have to say, when I finally got email on my phone (push email, that shows up all the time), it made things SO MUCH BETTER for me. Primarily because now I can be connected and involved in what's going on without having to warm a chair at work (or in my home office), or even having to pull out my laptop. I can present the appearance of always being available and working, even when I'm neither.:) It does make me more efficient (when I sit down to _work_ at the laptop, I spend more time working and less time chasing mail), and certainly has made my life more flexible (I don't feel the need to be at the laptop all the time trying to stay in the loop and responding to the fire of the day). My family appreciates it, because I can telecommute (or just take a long lunch, or leave late in the morning or come home early) more easily and frequently, giving them my presence while still remaining visible at work (which keeps mgmt happy and ensures that projects don't get stuck waiting on a response from yours truly and that I am up-to-date on the issues du jour).
I have co-workers that can't handle the mobile email though, because they don't know when to turn it off or just ignore it, so they end up looking like they're awake and working 24x7, but rarely get any time to truly relax and unplug.
(yeah, yeah I mentioned wife and family... substitute TiVO and gaming for those of you still single; the benefits are similar.:))
seriously though, this might work for office apps or web browsing or whatnot, but until neural interfaces surface, I can't see anything replacing the keyboard for programming or command-line interface tasks.
I certainly don't know anybody who's owned a visorphone, 3 treos, a blackberry, an HTC Hermes and an iPhone in the last 6 years. In fact, nobody's even heard of any of those devices, because nobody's buying them. Clearly, we're all still using whatever the free base model is that wireless providers were "giving away" (contract notwithstanding) back in 1997. And that million-units-sold-in-the-first-week iPhone is just a flash in the pan - a million units amounts to nothing compared to the 6.5 billion people on earth that haven't yet bought one!
(I can't believe anybody still publishes his drivel, much less pays him to write. I regularly read more enlightened discussion while skimming at -1 on slashdot...)
so SCOTUS agreed that DSL providers (and in my original comment, I had backbone carriers in mind, but did not specify) do in fact have common carrier status.... which is what I said in the first place: data providers (not all of them, but the telcos anyway) are common carrier. Your initial comment indicated that you thought that status was only for POTS or voice service. (Not sure how VoIP would fall, if that were the case...)
thus far, the law (CA 1934, CALEA, 47 U.S.C. 153(h)(1991), etc.) does not differentiate between a "communications provider" that uses voice or analog signal, and one that does packet pushing for data (which lately, could also be voice). Of course, as soon as you go modifying what you're carrying (snooping on traffic, prioritizing traffic for whoever pays the most, etc.) that common carrier status is in jeopardy.
The law could of course be rewritten at any time, or interpreted differently by any judge.
I'm a sysadmin (spend most of my time actually doing storage architecture, capacity planning, acceleration and other infrastructure stuff for Internet companies), and the job market is better now than I've ever seen it. I'm not a programmer (or software engineer, if there's a difference) by trade, although I do a fair bit of programming from time to time. My experience has been that those who have the ability to think methodically, take an analytical approach to troubleshooting and generally leverage past experience to new situations will _always_ be able to find work. Combine those skills with the pragmatic approach of a generalist (most sysadmins know how to do a little of everything (see http://darkuncle.net/sysadmin/what_is_a_sysadmin.txt)), and you have a combination of aptitudes, interests and skills that will serve to make you at home in almost any environment.
But mostly... do what you love to do first, and then worry about employment opportunities. If you're doing what you love, you will always be happy to get up and go to work in the morning, even if you have to scramble to pay the bills sometimes. OTOH, if you choose a career based on employment opportunities or median salary, you will end up hating what you do, because money isn't enough to compensate for a lifetime spent doing something that doesn't interest you (at least, not for hackers, who by and large require intellectual stimulation).
if access to the source mattered, he wouldn't be running Vista. conversely, if he's comfortable running Vista, running a closed-source app alongside all his other closed-source apps on his proprietary, DRM-ridden OS shouldn't be an issue.
I can see reasonable people going both ways, myself - I just find the particular combination of requirements by the OP to be unusual enough to warrant further explanation.
yes, yes there are lots of DNS requests. And there is cacheing at every single layer of the infrastructure, including most importantly:
* client resolver library
* client's upstream nameservers (recursive-only generally, operated by their ISP)
* any add'l upstream DNS architecture between the client's nameservers and the SOA
point being that billions of DNS requests generated daily for e.g. google.com are NOT all individually served by Google's nameservers. A small percentage of the total actually comes all the way through; the rest are handled by cacheing (one of the primary design goals of the protocol).
A proper architecture will do more to improve site performance (and reduce burden on the network) than any amount of changes to the software you're using to serve DNS. The slowdown you're referring to is much more likely to occur closer to the edge than in the core of the ISP (where DNS server performance are a factor).
BIND is not the problem. DNS isn't even the problem (unless you've got some really boneheaded setups). _architecture_, in a general sense (from systems to storage to networking to web page content to CDN to GSLB to peering to geographic distribution of datacenters), is the problem. DNS is a very small facet of the overall problem (it can be a problem, granted - but it's hardly the most significant one, or even in the top 5 the vast majority of the time).
yeah, I think he really does. GP is right: to request a solution that's both open source _and_ runs on Vista at least entitles us to know why in the world those two mutually-exclusive philosophies are both requirements.
... nah, couldn't be.
Seriously, didn't this strike anybody else as bizarre when you read the article summary? If F/OSS is a requirement in the database portion, why not in the OS? Better yet, if it's a requirement in the database portion, why not just pick an OS best-suited for that task (bdb on *nix is the canonical answer, and has been for 10+ years).
It's almost as if the article summary were a thinly-disguised troll
If DNS traffic is your bottleneck, you don't have a bottleneck.
Seriously, "DNS traffic grows faster than the overall traffic"? Maybe if you're doing a lot of TCP-over-DNS (thanks, Dan Kaminsky), or if you are providing DNS hosting services. Otherwise, I fail to see how a primarily UDP-based, extremely lightweight protocol (designed for cacheing at every layer, mind you) can grow faster than HTTP or whatever your traffic is.
Again, if DNS is your bottleneck, you've got something that's not designed properly, or are providing DNS hosting as a service (and probably still have something not designed properly). 100K zones is slow to startup? How about not putting 100K zones on the same servers? SPOF much?
I'm not arguing that BIND is the fastest, cleanest, most secure implementation out there (that title probably belongs to djbdns; I have yet to see a security hole published in any of his stuff - too bad it's such a hassle to use), but if your architecture is such that BIND's bugs are biting you, I would argue that BIND is _not_ your biggest problem.
This is exactly the approach that e.g. the OpenBSD dev team takes - all bugs are squashed with equanimity. They don't consider bugs to be "less critical" because they don't represent an apparent security threat or come with an obvious exploit. This kind of consistent code-review housecleaning has the nice side effect of avoiding many security holes before they are even discovered. (See http://www.openbsd.org/security.html for more on this philosophy.)
But the point of my original post was that kernel architecture and other technical issues NOT our collective big problem when it comes to security: the most pernicious, most easily and frequently exploited, and most difficult to patch holes are human in nature. Whether it's social engineering (e.g. phishing) or bad architecture (unnecessary features, trusting in the firewall for all your security, etc; see my previous post), humans (both users and engineers/admins) are the biggest source of risk to infrastructures large and small (down to and including the home desktop user).
Unfortuantely, there are very few technical solutions to problems in this space.
system hardening is effective at defeating certain classes of attacks. that said, most security breaches are NOT due to fancy footwork with memcpy or other low-level wizardry. They're due to either:
... but in the end, users just want to do whatever it is they're using the computer for. If an attacker can convincingly pretend to be legitimate, or present a convincing enough temptation, users will bypass, override or disregard any level of protection. Vista's UAC is the canonical example here - great idea foiled by end users (granted, the implementation was almost guaranteed to train users to eventually ignore the constant repeated warnings).
1) improperly designed trusts between systems (e.g. the Internet can't talk to my database server, but my webserver has full access; when my webserver is compromised, the contents of my database are toast as well). Networks designed to fail safely and gracefully, with liberal application of the principle of least privilege, help mitigate this kind of risk.
2) stupid user tricks (I place social engineering in this category, along with phishing and the majority of email viruses). There is no technical solution for this essentially social problem - education helps, sane and safe defaults help tremendously (every unnecessary feature is an additional security risk, and the risk compounds as features are added), software policy approaches like ACL/MAC/UAC/RBAC help
when I said "your choices are to exchange traffic with me, or not, but you don't get to tell me how to run things [on my network" I was speaking as a network operator, not an end-user. End users don't exchange traffic in the sense I was speaking of; they consume (p2p notwithstanding; I was using "exchange" in the sense of peering).
that said, I agree with both of your points.
for the record, I completely agree with the points you made:
... that said, the point I was trying to make was in response to the perhaps unintentional editorializing from Rob's tagline on the story. It's not a democracy because
* gov't regulation (or lack thereof), combined with a woeful lack of due diligence in ensuring taxpayer investment sees a decent return (the POTS system was almost entirely subsidized by taxpayer dollars, and we're still paying for that initial investment in the form of surcharges and taxes on copper laid a hundred years ago in some cases, with further technological deployments (e.g. FTTP) coming late or not at all, and always with grudging complaint on the part of telcos and hints that more subsidies and monopoly support are required to "encourage" further development).
* Many, if not most, ISPs are blatantly lying in terms of what's advertised versus what they can actually deliver (and the fine print end users have to agree to in order to get a connection allows the ISP to deliver any class of service it likes, with no recourse for the customer aside from switching providers, which often isn't an option). I firmly believe that an ISP that offers unlimited Internet access should have to deliver the Webster's definition of "unlimited", or else call the offering something else.
* the vast majority of subscribers face a duopoly, at best (and one that's entrenched and is focused primarily on maximizing return on existing investment, rather than deploying new technology to stay ahead of competition - when there isn't any competition, you don't have to offer much to stay profitable).
1) it wasn't designed as any such thing - it's a loose confederation of autonomous systems;
2) most systems were not (and are not) directly or indirectly established and maintained by the general public of any single country or locale - why should the residents of $random_{city,county,state,country} be able to dictate operational policy for $random_privately_held_ISP? (but see my points above re: artificial monopoly and public subsidy; I'm in favor of a good return on public investment)
I think the feds have been entirely too chummy with Ma Bell (and the cablecos, and BigCorp in general) for the last several decades. However, I'm very skeptical that the answer to poor federal legislation is additional federal legislation. Our Congress has repeatedly demonstrated an uncanny ability to confuse and pervert even the clearest and most uncomplicated issues into a tangled morass of legislation that benefits only lawyers, legislators and those with the money to get the latter re-elected.
I suspect that the proposed cure for network neutrality woes would be worse than the disease in the long run.
because the Internet is a group of autonomous systems (hence the identifier "ASN") agreeing to exchange traffic for as long as it makes sense for them to do so. There is no central Internet "authority" (despite what Dept of Commerce, NetSol, Congress and others keep trying to assert) - your rules end at the edge of my network. Your choices are to exchange traffic with me, or not, but you don't get to tell me how to run things (modulo the usual civil and criminal codes regarding the four horsemen of the information apocalypse). Advocates of network neutrality legislation would clearly like to have some add'l regulatory framework in place to provide a stronger encouragement to "good behavior" (as set out in the RFCs and in the early history of internetworks and the hacking community) than the market provides in some cases. It remains to be seen whether the benefits provided by that framework would at all outweigh the inevitable loopholes, unintended consequences and general heavy-handed cluelessness that's been the hallmark of any federal technology legislation.
Those networks that show consistently boorish behavior to other networks eventually find themselves isolated or losing customers (e.g. Cogent, although somehow they still manage to retain some business - doubtless due to the fact that they're the cheapest transit you can scrape by with in most cases, although anybody who relies on them is inevitably sorry).
The Internet will be a democracy when every part of the network is funded, built and maintained by the general public. Until then, it's a loose confederation of independent networks who cooperate when it makes sense to do so. Fortunately, the exceedingly wise folks that wrote the protocols that made these networks possible did so in a manner that encourages interconnectivity (and most large networks tend to be operated by folks with similar clue - when they're not, see the previous paragraph).
Not everything can be (or even should be) a democracy. Now get off my lawn, you damn hippies.
http://marc.info/?l=openbsd-misc&m=120268516518434&w=2
basically, the requirements for a successful 'exploit' are a poorly-attended system without even the most basic safeguards against abuse.
but mostly, who's Amit Klein? He may be brilliant, or he may be Gobbles (or somewhere in between). I don't know - but the OpenBSD team has a history of making smart decisions and doing the kind of development that has earned my trust. When presented with a scenario I can't necessarily judge for myself, and given the OpenBSD dev team on one side and $random_guy on the other, I think I'll trust the side that's already earned my trust, until they do something to lose it.
have you even read his report? I have, several times, and I see no claims that aren't substantiated/attributed to third parties (usually folks who would know, like hardware manufacturers), or else lifted directly from the documentation or quoted from Vista developers.
... what points, in particular, do you disagree with Gutmann on? What are _your_ credentials (are you teaching cryptography somewhere, for instance)? If you haven't got anything more substantial than "this guy is full of it", don't be surprised if you aren't taken seriously.
Ad hominems are easy
http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html
required reading for ANY discussion of Vista cost/performance issues. I was kind of surprised not to see the URL come up in the discussion thus far, so I dropped my mod points for this story in favor of posting instead.
Bottom line: if Microsoft had put the focus of Vista development on actually making the best-performing OS they could, instead of making digital restrictions the number one feature, the OS would very likely have been one of the best releases in recent memory. Instead, features and performance came in _explicitly_ behind DRM at every level of development and marketing (including Vista Compatible branding).
I have a Deity, and a holy Book, and I find wisdom therein. :) However, said Deity also blessed me with a brain and some common sense, and I am rather more willing to consult both of those than random strangers (well-regarded, educated or otherwise) who have no personal knowledge of me or my kids.
:))
I wouldn't mod you troll - but I also don't feel any particular need to consult "experts" (aside from my folks, who have already demonstrated their wisdom and experience to me, and others who have already gained my trust) for advice. However, I also don't disregard advice from someone just because they're a stranger - wisdom can come from many places.
(infrequently found in slashdot comments though
When you find somebody who's really qualified to give "expert" opinions on how random people should raise their kids (keeping in mind situations and kids and parents are all different in many ways), you let me know.
... I'm entirely comfortable making my own decisions on how to raise my kids (4.5 and 2). The 4yo would play Yoshi's Island (DS) every waking hour if we let her, but we don't. :) She's learned letters, numbers, colors, phonics, reading and basic math through a combination of us reading with her, educational games (LeapFrog is your friend here), websites like starfall.com (hat tip to Gabe @ Penny-Arcade) and good old-fashioned one-on-one teaching and repetition.
In the meantime
Games have their place, just like anything else (including computers; she can't type yet, but she can navigate her favorite educational websites just fine). They're no more or less dangerous to kids' development than Baby Einstein videos, or educational TV, or pop-up books, or [insert controversial newfangled technology here].
The key here, as with everything else in life, is moderation and good sense.
s/Oulette/Ouellette/g
...
pardon my French
if you haven't read it, you should go give Pierre Oulette's first novel a shot ... it's a little dated on some of the technology concepts, but some of the biotech/GE stuff is still beyond us for the foreseeable future. If you find the idea of robot (or better yet, cyborg) flies or even larger, stranger creatures interesting (especially when designed/powered by a sentient AI), you would probably enjoy the book. Read it back when I was in high school, and just ordered a copy from Amazon to fill an empty spot in my bookshelf ...
- wouldn't have been fired in the first place, and if he was fired,
- wouldn't have been caught, and if he was caught,
- wouldn't have been prosecuted.
This guy was merely a pretender to the title, and clearly was not familiar with the extensive body of work on the subject. No true Bastard would ever allow such a demeaning sequence of events to occur under his tenurethe answer to five 9s uptime is to stop building systems that rely on single points of failure. Compare Google's approach to processing and uptime to that of the mainframe era. Totally different infrastructures with similar goals and globally, similar uptimes/reliabilities. Design your systems such that any component (any switch, router, power supply, hard drive, server ... to a certain degree, even any individual data center) can fail without resulting in a loss of data. Sure, it's complicated - but it can be done, and it's definitely the direction that network and systems architectures are headed.
in all things, moderation. I turn my phone (HTC Hermes) off when I go to sleep, but mostly just because the incessant GSM buzz on my clock radio drives the wife and I nuts. I have to say, when I finally got email on my phone (push email, that shows up all the time), it made things SO MUCH BETTER for me. Primarily because now I can be connected and involved in what's going on without having to warm a chair at work (or in my home office), or even having to pull out my laptop. I can present the appearance of always being available and working, even when I'm neither. :) It does make me more efficient (when I sit down to _work_ at the laptop, I spend more time working and less time chasing mail), and certainly has made my life more flexible (I don't feel the need to be at the laptop all the time trying to stay in the loop and responding to the fire of the day). My family appreciates it, because I can telecommute (or just take a long lunch, or leave late in the morning or come home early) more easily and frequently, giving them my presence while still remaining visible at work (which keeps mgmt happy and ensures that projects don't get stuck waiting on a response from yours truly and that I am up-to-date on the issues du jour).
... substitute TiVO and gaming for those of you still single; the benefits are similar. :))
I have co-workers that can't handle the mobile email though, because they don't know when to turn it off or just ignore it, so they end up looking like they're awake and working 24x7, but rarely get any time to truly relax and unplug.
(yeah, yeah I mentioned wife and family
vaporwear? :)
seriously though, this might work for office apps or web browsing or whatnot, but until neural interfaces surface, I can't see anything replacing the keyboard for programming or command-line interface tasks.
amazon is all out, but I have one on backorder ...
I certainly don't know anybody who's owned a visorphone, 3 treos, a blackberry, an HTC Hermes and an iPhone in the last 6 years. In fact, nobody's even heard of any of those devices, because nobody's buying them. Clearly, we're all still using whatever the free base model is that wireless providers were "giving away" (contract notwithstanding) back in 1997. And that million-units-sold-in-the-first-week iPhone is just a flash in the pan - a million units amounts to nothing compared to the 6.5 billion people on earth that haven't yet bought one!
...)
(I can't believe anybody still publishes his drivel, much less pays him to write. I regularly read more enlightened discussion while skimming at -1 on slashdot
so SCOTUS agreed that DSL providers (and in my original comment, I had backbone carriers in mind, but did not specify) do in fact have common carrier status. ... which is what I said in the first place: data providers (not all of them, but the telcos anyway) are common carrier. Your initial comment indicated that you thought that status was only for POTS or voice service. (Not sure how VoIP would fall, if that were the case ...)
IANAL, but I'll correct you anyway. :)
http://www.cybertelecom.org/notes/telecom_carrier.htm
http://www.cybertelecom.org/notes/jones.htm
thus far, the law (CA 1934, CALEA, 47 U.S.C. 153(h)(1991), etc.) does not differentiate between a "communications provider" that uses voice or analog signal, and one that does packet pushing for data (which lately, could also be voice). Of course, as soon as you go modifying what you're carrying (snooping on traffic, prioritizing traffic for whoever pays the most, etc.) that common carrier status is in jeopardy.
The law could of course be rewritten at any time, or interpreted differently by any judge.
I'm a sysadmin (spend most of my time actually doing storage architecture, capacity planning, acceleration and other infrastructure stuff for Internet companies), and the job market is better now than I've ever seen it. I'm not a programmer (or software engineer, if there's a difference) by trade, although I do a fair bit of programming from time to time. My experience has been that those who have the ability to think methodically, take an analytical approach to troubleshooting and generally leverage past experience to new situations will _always_ be able to find work. Combine those skills with the pragmatic approach of a generalist (most sysadmins know how to do a little of everything (see http://darkuncle.net/sysadmin/what_is_a_sysadmin.txt)), and you have a combination of aptitudes, interests and skills that will serve to make you at home in almost any environment.
... do what you love to do first, and then worry about employment opportunities. If you're doing what you love, you will always be happy to get up and go to work in the morning, even if you have to scramble to pay the bills sometimes. OTOH, if you choose a career based on employment opportunities or median salary, you will end up hating what you do, because money isn't enough to compensate for a lifetime spent doing something that doesn't interest you (at least, not for hackers, who by and large require intellectual stimulation).
But mostly
To thine own self be true.