That's because undergraduate CS is traditionally a blow-off crap curriculum. Intro to algorithms, data structures, a little assembly, C, Java, programming assignments. Maybe one Scheme course.
OK, that's the first eight weeks, give or take a maths course. What's in the second term?
EE is a fine subject, but it's not CS, and hiring an EE guy when you want a CS guy is a mistake. (Of course, hiring a CS guy when you want a code monkey is also a mistake.)
My undergrad degree was in maths, BTW, so I'm not grinding an axe here. And the first eight weeks comment was then, and according to the syllabus remains now, pretty accurate for the undergrad CS course at the university I went to.
It's always fascinating to hear people say we don't need as much understanding of CS these days, because all the outsourced code monkeys can do the mainstream programming, and no-one using programming incidentally needs that depth of understanding anyway.
Then they ask why software today seems to run slower than it did a decade ago despite hardware being orders of magnitude faster, complain about how everything on the Internet is insecure and they keep getting junk mail, wonder why web sites get Slashdotted so easily, get disappointed by the dumb actions of computer opponents in games, use grammar checkers that produce worse documents than they started with...
Recursive data structures are trivially dealt with if you have concepts like disjunctive types and pattern matching.
Can you dumb that down for me? I have no idea what this means.
Sorry. The terms are common in the world of functional programming languages (Haskell, ML, etc.) but there's no reason someone who works with something like C would known them. You've already got a good reply, but at the risk of oversimplifying, I'll try to describe the concepts in more C-friendly terms.
A disjunctive type works a bit like a combination of a union (i.e., it can represent several kinds of data, but only one at once) and an enum that identifies which kind of data the current value is. A common example is making a "nullable" version of a type T, which might have two options:
an empty type, with corresponding tag None
a type containing a single object of type T, with corresponding tag Some
which you'd define by simply listing the names of the possible options and the type each represents:
type Optional T = None or Some T
You can't access the value of an object with a disjunctive type directly, because you don't know which of the options is being used, and there needn't be any particular relationship between them. Instead, you use a technique called pattern matching, which is essentially a type check serving a similar purpose to C++'s dynamic_cast.
For example, to print an object obj of type Optional T, you can't write something structured like this:
print obj
because you don't know which of the two options obj is currently using, but you can write something structured like this instead:
print object matched with None -> "None" Some x -> x
to print "None" in the None case, or the value of the T object in the Some case.
(Obviously I'm making the syntax up here, although in fact what you write in many functional programming languages isn't far off this.)
In this way, you can define many useful types. Nullable variations are one example, but you can also extend that to data strucures like linked lists and trees, and much more.
With a type system like this, there is no built-in concept of NULL as there is with C's pointers. You just don't need it: if you want a nullable type, you create it explicitly (which usually requires a grand total of one extra word in the source code), but then the type system forces you to check for the null option properly when you access the data. There is no concept of dereferencing a null pointer or throwing a null reference exception, because you simply can't be in that position.
Wow, that was a truly awful post. Sorry. I'm writing this quickly at lunch and don't have time to edit it much. If you're interested in these concepts and their close relations -- and personally, I'd certainly rate them as one of my top five things the maintstream programming industry should get to! -- then you might like to search for:
Maybe type
nullable type
disjunctive type
conjunctive type
type system
strong typing
There are some pretty good articles in various programming-related wikis that you'll probably find your way to via the above, although I give you fair warning that some of them get a bit deep, and the functional programming world does have its share of zealots and evangelists just like any other...
What's up with the extra 2 keys on the home row between JKL; and Enter? It's impossible to hit their Enter key without moving your right hand off the home row.
They're pretty standard in many keyboard layouts; here in the UK, they are '/@ and #/~ for example.
And no, it's not a problem moving your hand slightly off the home row to reach Enter; you get used to it in about five seconds.
The old 8 bit computers also all had identical, known hardware, so there was no need for driver updates. They were far less complex, so there was far less chance of bugs. They were far less interconnected (if at all), so far less chance of (exploitable) security holes.
They were also running on hardware literally thousands of times slower than today's, so none of the above is really any excuse.
I wrote software with GUIs that were instantly responsive back in MS-DOS and 12MHz 80286 days. I now specialise in writing scientific instrument control and mathematical software, so I'm somewhat familiar with how fast modern computers can really go, and the effects of having numerous custom drivers running under a multitasking OS. I really don't see any technical reason today's software can't be vastly faster than most of it is, but then technical reasons are rarely the limiting factor in software development.
We'd do a lot better if the software development community collectively learned a lot more about good design, dropped its lazy attitudes ("Of course $LANGUAGE_X is fast enough"), stopped relying on faster hardware as a crutch for slower code, learned to profile, and was given chance to do it by management rather than pushing the product out to market two days earlier.
You're thinking too classically, like a C programmer. With a higher-level language, more design intent can be expressed directly by the programmer, and used by the compiler for safety and optimisation purposes.
Sure, you can't check all arrays access for bounds violations, but if you think about it with your human level of understanding, very few accesses can ever really be dangerous. The trick is to be able to convey that level of understanding to the compiler, so it can perform the necessary checks, and no more.
As for NULL pointers, there's really no need for them at all if you have a serious type system. Recursive data structures are trivially dealt with if you have concepts like disjunctive types and pattern matching.
In fact, as useful as they can be at lower levels, pointers generally are only useful as reassignable references to objects. There's no need to relate pointers and arrays, nor to provide arbitrary pointer arithmetic and the NULL concept, with a moderately powerful type system.
There is a reason that many languages make a point of saying they don't support pointers, even if they have a more limited variation of the concept, as with things like Java. The killer isn't the concept of indirection, or changing the target, it's the arithmetic, and assignment of arbitrary values. That leads to a world without proper type safety, and it leads to aliasing concerns that have horribly negative effects on optimisation.
My underlying assumption (which I believe the graph backs up) is that Windows OS penetration is primarily driven by PC turnover and not in-place "upgrades". (With rare exceptions like Win95 or MacOSX.)
We can certainly agree on that. I think such disagreement as we have is a matter of timescales. I don't doubt that with time, IE7 will become an established player. My argument is simply that if developers don't go out of their way to accommodate it, it will have to be good much faster than that, because it won't have the market share to force the whole web to support it specially from the start. Otherwise, it risks people switching away to alternative browsers, something that is much more likely today than it was last time MS brought out a major new OS and attendant utilities. Hence I believe the correct thing for web developers to do to support IE7 is "absolutely nothing different".
Yeah. It seems that NT4/2K transitioned on one axis and 98/XP transitioned on another.
Exactly. XP was supposed to be the release where the home and pro product lines came together. However, I'm not sure your graph shows any great transition from 2K to XP at all; at most, the number moving up to XP was balanced by the number moving up or over to 2K from NT4, or possibly the 9x series in a few cases.
No. the graph shows that it took about 3 years for 98, 98SE, and 98ME (which I believe is how it reported itself) to gain 55% marketshare, and it took about 3 years for XP to do the same.
Not quite. It shows that it took at most three years for the 9x series to establish what appears to be the entire home user base. They might have done it much faster, but since ME was a separate OS that would have been shipping on new machines for about half of that period and the graph doesn't give a breakdown of the two, it's hard to say. What is certain is that either not many people upgraded from 95/98 to ME, or the upgrade cycle slowed down a lot from ME to XP. I'm guessing that ME was the flop, but you can't tell from that graph.
Furthermore, it is quite possible that MS will repackage OEM XP to include IE7. They've done it before.
Indeed, and I did acknowledge that I thought they would do something like this in my original post. However, the only official announcements I've seen to date said that IE7 would be Longhorn-only.
The mistake is your assumption that this will "hurt Microsoft". It will be perceived by consumers to be a problem with the site, so a blase attitude towards IE7 will hurt the web developers more than anyone.
Perhaps I have more confidence in the Internet-using public than you.:-)
Five years ago, I'd have bought that argument. Since then, we've had worms and viruses, and security flaws in Microsoft products have started making mainstream news, as has the availability of alternatives.
For one thing, Firefox now represents a very credible threat on Microsoft's home turf (Windows boxes), and a lot of people who turn to their favourite geek for advice on setting up a new PC are going to be hearing about it who wouldn't have done a few years ago. Convert the home user geeks and the professional sysadmins, and the sheep will follow in both markets; it's only a matter of time.
For another thing, a lot more people are using the web routinely now than they were in the late '90s. People expect things like Internet banking, or that their favourite shop or restaurant will have a web site, and they've used these things with previous browsers. If something suddenly stops working after they buy their new PC that worked before, I doubt the first thing any intelligent adult will do is assume the site has broken, particularly when the first reply they get from the site's webmaster says that unfortunately Microsoft broke IE, and they're working on a fix but for now you need to use browser software that isn't broken.
Now, obviously if Microsoft pulls a Nutscrape and creates a "severe compatibility event", they might have problems. But this would go against their entire product marketing history
Ah, now I've definitely got you. You're talking about the company that manages to break backward compatibility in one of its primary products, Microsoft Office, fundamentally in about every other version. 95->97 was a farce. Office 2K wasn't bad, but Office XP apps could crash trying to load older documents. I haven't played with the most recent version much yet, but in any case, Microsoft's compatibility history is not altogether glowing. I know they try -- I've read articles by insiders on just how hard they try -- and I realise that with the number of people using their products in different ways some issues are almost inevitable, but still, that's all true for IE as well.
And as I've noted throughout, if Microsoft don't create a significant compatibility problem, there will be no need for devs to do anything anyway, will there?
When I came back to my current job, I accepted the position on the condition that I could shift my schedule several hours forward from the usual "9-5". This not only makes me more productive when I am in the office, but let's me shave a couple of hours off my commute because I avoid rush hour. Win-Win for everybody.
It's interesting that one of the most highly regarded "perks" in every survey of geek staff I've seen for years has been flexible working hours.
At my current employer, we have quite a clever policy: the rule is you have to be in the office for at least 5 hours between 9am and 6pm every day, but other than that, you can work your 37.5 as you see fit, with common sense applying when it comes to organising meetings and the like. What this means is that you're guaranteed to be in the office for at least an hour of overlap with any of your colleagues in a given day, so you never miss someone completely. However, you can effectively take a half-day off without using leave, or go in before the morning rush and then leave mid-afternoon to pick the kids up from school, etc.
I'd say most of the guys' typical hours are somewhere between 9:30-5:30 and 10:30-6:30. We also have quite a few habitual early starters and a few habitual come-in-at-lunchtime guys. There are even some guys who change quite radically from week to week or even day to day, such as the guy next to me whose fiancee works shifts at a hospital, or one of the girls who finishes early-late-early-late to alternative picking her son up from school with her husband.
This is a great arrangement, and it was interesting that when we were bought out by a US corp a few months back, this was one of the Big Things everyone was adamant we would keep in the new contract. (We collectively made them rewrite it so we could.) Of all the other "perks" brought in by the corp, none has anything like the value of this one, and I'm not sure I actually use any of the others.
I would have assumed that the labor laws in the UK were much stronger than in the US. There really are cases where someone could be denied their paycheck?
I'm not an employment lawyer, so I can't give you a definite answer to that. I can certainly comfirm that other standard employment rights (e.g., a notice period before dismissal, during which pay is maintained) are very likely to be forfeit in the event of things like gross misconduct, deception, committing criminal activity, etc.
It's hard to say what would happen in this specific case, because I can't imagine anyone over here working an hourly rate in this particular business who isn't doing so as a contractor. I don't know enough about the US employment market to be sure, but I get the feeling the employment-at-will concept and the culture of salaried workers putting in stupidly long hours make the whole employer-employee relationship work very differently to ours. Maybe a lot more people across the pond still work hourly rates long after the jobs at that level would have been salary-based over here.
But getting paid for hours worked would be nearly always be slam-dunk for an employee.
If they were at least trying to do a reasonably job, I'd assume so over here too. I'd be interested to find out whether that still applies when they're blatantly not, though.
We have a concept of a basic trust relationship between employer and employee that (so the lawyers tell me) forms part of any employment relationship. Either side may be able to invalidate part of the employment contract if they can demonstrate that this basic trust relationship has broken down. I'd say that getting a job by lying and then acting in bad faith once employed was a pretty clear breakdown of trust! Hence I'm guessing any attempt to fire someone immediately and without pay-to-date would be made on this basis, but as I said, I'm not a lawyer and this is based only on a layman's understanding of our employment laws.
Fair enough, you've obviously seen some information I haven't noticed about where this story comes from.
Here in the UK, industrial tribunals have a pretty good reputation, since the panels are deliberately composed to include people who would naturally side with both sides and a relatively neutral lawyer. Companies certainly don't risk a tribunal lightly, because it's unlikely a tribunal will find in their favour if they have been acting improperly, but OTOH frivolous cases by (ex-)employees tend to be thrown out pretty quickly too.
It doesn't surprise me at all to find that the same neutrality isn't present in the US system; it seems like every time I read about any sort of law in the US these days, it's because it's stacked even further in favour of megacorps at the expense of consumers and/or staff.
Check out the nice straight lines here: http://www.pegasus3d.com/osshare2.gif (original source, Google). In 18 months XP had the Windows marketshare lead.
Please think about what the figures in that graph represent for a minute. For example:
The Win2K market share has been almost completely unaffected by the arrival of WinXP.
It took longer for WinXP to hit majority market share than Win98.
Also, notice that WinME isn't shown at all. There's a whole operating system that isn't there. If it's been merged into the Win98 figures, then that suggests that the adoption of WinXP was only around half as fast as its predecessors.
Slashdot FUD isn't much of a predictor of anything.
However, official announcements from Microsoft that they're dropping the two most useful pillars out of the original three that were supposed to be the heart of Longhorn are likely to be, well, representative of Microsoft policy, no?
New PCs, on the other hand, are the irresistible force.
Only measured over a period of years. The day after Longhorn comes out, if IE7 doesn't work with existing web sites, it's unlikely many of those sites will care at all. The same "support the majority player" mindset that has held back W3C standards compliance for years is going to come back and bite Microsoft in the backside now if they try to play proprietary again. Too bad.
Well, I've provided an argument why it will mostly "just work", so you will need to provide one why it won't.
No, I don't. My argument (see my original post) is simply that the best strategy for web developers is to do nothing special for IE7. If it "just works", that policy won't cost them anything. It if doesn't, I think it will hurt Microsoft a lot more than it hurts the WWW. My position doesn't lose either way.
Why is it unfair to the employer? What you just described is a total failure of the interview process, and a total inability of the company to handle a new employee.
I agree that it's a failure of the recruitment process, but where we differ is that I think a recruitment process can never be perfect, nor even close. It's simply unrealistic to expect any such process to weed out all the bad apples before they start, or to expect a company to supervise a new employee who claims certain basic competencies well enough to identify a bullshit artist immediately. However, I don't see why operating in the real world should be damaging to a company.
As I suggested in another post, the extent to which the employer's actions (or lack thereof) was negligent and led to their own demise in this case would probably have to be determined by a court or tribunal of suitable authority in that particular jurisdiction, with full access to the specific facts of the case. However, it seems to me that even if you're working for an hourly rate, if you lie to get a job and are completely incompetent to perform the work required, you don't deserve any legal protection just because you successfully pull the wool over your employer's eyes for a while. Even for an hourly rate, you're still being paid to do a job, and that's a two-sided deal. IMHO wilful dishonesty demonstrates clearly that there was no intent to meet one side of the bargain, and should therefore disqualify someone from any legal protection of the other side of the bargain by default. Why should an employer (and by extension, other staff with an interest in the company, any shareholders, etc.) be screwed for even a $MINOR_CURRENCY_UNIT to benefit a deceptive incompetent?
(Obviously this is a different case from a contractor, who clearly wouldn't get paid if they failed to meet the requirements of the contract, but I think we agree on that anyway.)
Thanks for the reply, but I think my reasoning was a little more thought out than you give credit for...
Assumption #1: IE 7 will have a low marketshare.
Better prediction: Within a month or two, IE7 will have a greater marketshare than Firefox and all other alternative browsers combined. (Based on historical adoption of IE6.0). When Longhorn ships, the market will be predominately IE7 within months. Your statement that IE7 will not develop a huge market share either appears to be completely groundless -- just the shipment of new PCs alone negates it.
I find that extremely unlikely. Adoption of new operating systems from Microsoft has been slowing dramatically since Win2K. Even today, as Microsoft starts blatantly shutting off support to force people to upgrade, a very significant proportion of their customer base are not running WinXP.
Longhorn may be the most hyped MS operating system since the last one, but they've cut most of the potentially great stuff out of it already; see Slashdot discussions passim. There's not much of a compelling driver for upgrades, which means the only way it's getting out there in serious volumes is via new PCs.
A common business plan replaces PCs every three years, with plenty of places using older machines and software, and not many upgrading more frequently. That means for IE7 to reach the same penetration as IE6, even without other factors, would take the best part of three years. And this is assuming that everyone buying a new PC gets Longhorn, which isn't necessarily going to be the case for many reasons, and that no-one switches to a different browser in the meantime, which also isn't necessarily the case.
Microsoft just don't get those three years. If they're lucky, they get a month or two, by which time if there are serious incompatibility flaws, every magazine, on-line review site, CIO journal and tech news forum is going to be carrying the fact that IE7 breaks web sites and the damage really starts, crippling further spread of IE7.
Assumption #2: IE 7 will have some major incompatibilities with IE 6.
Better prediction: In the vast majority of cases, IE 7 will just work. It will still contain all HTML3.2-era hacks and IE5-style BogoCSS. The most affected sites are the few that exploited CSS2 bugs to work around other CSS2 bugs in IE6.
Well, if it "just works", there will be no need for developers to do anything special to support it, will there?
But if it was going to "just work", Microsoft wouldn't need to spend a fortune trying to get everyone to check their sites and fix the breakage early. They're worried it won't "just work", which is pretty telling.
Assumption #3: Major sites will be unprepared for IE 7
Better prediction: This is the biggest browser release in years, and sites will test with the beta releases. (Admittedly this is going to sorta suck for W2K shops like ours.)
I admire your optimism. Gecko-based browsers have around 10% market share today, depending on who you ask, yet we're only just now seeing some key web sites (particularly those dealing with financial matters) upgrading in the face of customer pressure and bad PR. I very much doubt the kind of site naive enough to be IE6-only until recently is going to be IE7-ready the moment Microsoft releases it, if IE7-ready doesn't mean "works like IE6".
Assumption #4: Microsoft "bullies the dev community right now because it has huge market share"
Reality: Most web developers are primary IE and are using simplistic techniques that generally work just fine on Firefox and Safari.
I'm not sure either part of that claim is true. A lot of cheapo shops and schoolkids pretending to be businessmen are IE only, but most of the pros I know (of which there are quite a few, given I work in a big tech centre) are more than familiar w
The term "wages" implies that he was an hourly employee, and therefore would get paid for time worked, no matter how good or bad his work was. Slavery is illegal and stuff.
I'll have to take your word for that, because I don't know where this incident occurred or the law there. I'm pretty sure that if you're guilty of something as serious as deception or gross misconduct, the normal rules often don't always apply, though. I'd expect the extent to which that's true of an employee if they're paid by the hour, and how much it would depend on the level of supervision, is probably something for an industrial tribunal or suitable court to decide.
I would certainly be surprised if you could get a job by completely lying on your application, work for some amount of time nominally on an hourly rate but not actually doing the job, and still have legal support for getting paid, though. That seems hugely unfair to an employer, regardless of any duty to provide reasonable supervision.
What strategy must we follow to have M$ kind-of stab themselves in the foot by the selfish/greedy actions they might take in regard to IE7?
Change absolutely nothing. Your strategy is as simple as that. Continue to develop for W3C standards, and make the usual pragmatic concessions to allow for IE 5 and 6. Make no special attempt to accommodate IE7 whatsoever.
This strategy is a clear winner for one simple reason. The only reason MS gets a lot of developers to code for IE is because it's big. When you have 90% market share, you don't follow the standard, you define it, regardless of what the W3C and its supporters might wish were the case. As a corollary, when you have 90% of market share, a lot of ill-informed cheaposoft developers will code for your software because they don't know any better.
However, when IE7 comes out, it will not have 90% market share. It starts at 0% like everyone else, and if it isn't directly compatible with either the W3C standards or Microsoft's previous one (the now-well-known quirks in IE 5/6) then it gets a category of its own.
Moreover, since MS were making a big point of how IE7 will only be part of Longhorn and won't be available as a retrofit onto the previous versions of Windows, they are almost condemning it to be a minority player for several years. Just look as how many home users are still running ME, and how many businesses are still on 2000, never mind XP. (As an aside, I heard rumours of this policy changing, though I've not personally noticed anything official from Microsoft about it yet. I'll be amazed if there isn't an IE7 upgrade for WinXP available the moment it releases, though.)
If critical web sites like banks and the big e-shops don't immediately work reliably with IE7 -- and that information will probably spread very fast -- then this will hurt Microsoft's sales and market share. Microsoft will not sell as many copies of its new operating systems as long as they rely on IE7, so they will either have to fix IE7 or drop it and advise users to switch to something that works. In the meantime, big players like Dell will not be selling as many new PCs, or they'll be stuck with the overheads of supporting multiple OS configurations at supply time. After they had to do that with Win2K, when many major customers said they just didn't want the untried-and-untested WinXP installed on their new systems, I suspect they'll be very reluctant to do it again because of something as stupid as a web browser.
In summary, Microsoft only bullies the dev community right now because it has huge market share. IE7 will not start with a huge market share, and if Microsoft does restrict it to Longhorn only as they threatened in the past, IE7 will not develop a huge market share either. Thus IE7 is not a tool with which to bully the development community, it is a tool that must comply with the will of the development community. If it does not, Microsoft and the customers and business partners it most cares about will lose money, and that is the one thing they will not allow to happen.
Of course, Microsoft are well aware of this risk, which is why their legendary PR machine is now trying to mitigate it. All that is necessary to defeat this ploy is to see the PR for what it is: an attempt to trick the dev community into helping Microsoft, not the other way around.
I was just about to post and ask why anyone pays someone so incompetent, until I noticed your final comment. I would have thought dropping the company/firing the individual without any pay whatsoever would be completely justified if they were specifically asked to produce standards-compliant code as part of the spec.
The facts that they fobbed their employer off with "it's unimportant", didn't know about Mozilla, and ripped copyrighted code just demonstrate that they were incapable of doing the job they accepted and were acting in bad faith throughout; this was no accidental misunderstanding or legitimate ambiguity in the agreed specification. If anything, the company/employer whose time and resources they wasted should be suing them to recover losses through wasted time and effort, though sadly this probably isn't how it's going to work out in practice.
If I'm reading this right, they are simply using open source software, and not necessarily (as the Slashdot summary says) "[using] OSS modules in their applications". Was I the only one who immediately read that as if they were linking (L)GPL'd modules into their code or something similar?
It's not really clear what the statistic includes anyway. The only specific cases mentioned in TFA are "the operating system" and "application servers like Jboss or Gluecode". I certainly wouldn't describe using a Linux box somewhere in my organisation as "using an OSS module in my application", and I doubt more than half the software developers in the world use something like Jboss or Gluecode. Does writing software in an OSS-friendly scripting language count? Using an OSS database in the back-end? Does using Firefox to access a web-app?
Without clarification, the number is as meaningless as most other OSS-vs.-CSS statistics produced by either side.
If the US disappeared off the Internet... well, you would notice.
Sure, but sitting here in the UK and speaking in all seriousness, would I miss it?
The most US-centric resource I use with any regularity on the Internet is in fact Slashdot, which I find interesting and informative enough to read fairly regularly, and entertaining enough to post to a few times in a day if I'm on-line. I also follow a few other techie sites, some of which are US-based, though not as regularly.
However, the other things I use frequently are e-mail, Usenet, a few UK-based e-shops, the BBC News web site, and a few UK-based web pages related to my various hobbies, exactly none of which would even blink if the US disappeared from the Internet tomorrow, but for logistical hiccoughs. And of course, the UK would come up with its own alternative to the various techie forums like/. pretty fast. Think of it as "branching".;-)
As for the economics, a split would hurt the US far more than anyone else. A large part of current US financial policy is geared toward international trade. Personally, I'd love it to happen for that reason alone; my various savings accounts and pension funds are well-distributed geographically with a local bias, and certainly many local companies I indirectly hold shares in would be likely to increase in value dramatically in the absence of competition from Internet-based alternatives in the US. In fact, the US appears to have been running an unsustainable economic policy that's likely to collapse sooner rather than later for some time, and the more distance there is between that and our relatively healthy economic state over here in Europe when it goes, the better!
I'm honestly not trying to troll here, though I realise it may come across that way. I'm simply illustrating how little the US content on the Internet matters to someone in my country, even a pseudo-geek like me. And if anything other than US-based content disappears, that is a clear weakness in the architecture that should be addressed for the security of everyone else's service -- which, I believe, is where we came in.
Further, in race to declare that the US can't control the Internet, you ignored or were ignorant to the fact the US DOESN'T own all of the root servers.
On the contrary, I'm well aware of that, and consider that a compelling argument that it is realistic for the remainder of the world to force the US to concede control of the DNS system to an international group. (No, I'm not convinced the UN is the right one either, but something not entirely under the control of one nation's government would be considerably more resilient in certain plausible scenarios.)
Incidentally, many of the same arguments apply to the GPS satellite system, and you may have noticed that an alternative one of those is also being constructed outside of US control, at considerable expense. That certainly tells me something about the lengths other nations will go to in order to ensure the security of services they regard as essential.
Presuming you have enough language skill to know that "create" is not equal to "develop, nurture, and improve", which country did create it?
No one country did. That's exactly the point. For a start, the Internet is almost by definition a network of networks, many of which are not in the US. Moreover, there is no clear "creation date"; different aspects of what we know today as "the Internet" appeared at very different times in history.
What became today's Internet was mostly driven by academic research. While I'll certainly concede that much of the initial research during the '60s and early '70s happened in the US, it's still clear that from a very early stage, the research effort was international. For example, ISoc's brief history of the Internet mentions researchers in the UK working in parallel with the US research as early as 1967, until the groups discovered each other and started collaborating.
The infrastructure is obviously international, and for the most part quite capable of surviving without any one country. Networks that now form major parts of the Internet have existed in other countries for over 20 years. (The same history notes the existence of the JANET in the UK in 1984, while another mentions satellite links to Hawaii and the UK as early as 1975 and the creation of EUnet, connecting the Netherlands, Denmark, Sweden, and UK, in 1982.)
The software side, in particular the established communications protocols for things like e-mail, WWW, Usenet or FTP communication, has come from diverse sources. What was effectively the first TCP/IP standard was presented to an international working group at Sussex University in the UK in 1973.
Bodies like the IETF and W3C have geographically diverse memberships. While the US has by far the largest single category of W3C membership today, it still represents less than 40% of the total, which isn't much more than Europe, for example. There are a total of 28 countries with member organisations.
For any one country, including the US, to claim that this whole picture developed because of it, or wouldn't have happened in a similar way without it, is simply a delusion of grandeur. It might not have happened as fast, or in exactly the same way, but it would still have happened, probably working off the research done in Europe.
I find it deeply ironic that one of the other replies to my GP post was an AC who claimed I was trolling, and challenged me to provide information about other countries that contributed to the Internet's creation, while another accuses me of rewriting history. Fortunately, while a lot of mostly US-based Internet history pages choose to ignore the contributions from outside and focus on the US academic network during the early stages, the kind of information above (all of which is written by the people and organisations at the heart of the Internet) is freely available, even to those in the US.
I'm guessing Steak and Shake is some US food place, right? If that's the case, then your comparison is missing the point: the UN can't easily meddle internally in the US, but if the other nations representing it want to dump the US control of DNS, they can relatively easily just switch to an alternative system. Then the US can either play by everyone else's rules or not play at all. It gets no third choice of "status quo".
The United States developed the internet, with many large investments (DARPA etc.), and now we are expected to just give it up?
You may not even realise it, but the thinking exemplified by the above quote is exactly the reason the international community is so wary of leaving the US with any controlling interest in the Internet at all.
The US did not create the Internet. It may have played a larger part in some aspects than other countries, but it is neither responsible for all of the technological innovation, nor for even the majority of the investment, nor for keeping it running as it stands today. The fact that ICANN and its overlords are effectively US-government-controlled is an anomaly, not the norm.
The current US administration has demonstrated a great willingness to interfere in the affairs of foreign nations economically, legislatively and even militarily, essentially to further its own economic interests. This doesn't exactly engender trust on the part of those nationss' governments, and you can't really be surprised that they don't trust the US to "do the right thing" any more.
I was about to post the answer "a bin", but it looks like you beat me to it...
Seriously, I always smile when I hear about geeks with five home computers in their study, seventeen kinds of connectivity to each one, and so on. I mean, how many different boxen can you type on at once, anyway?!
I think a lot of people overlook simple ways to keep things tidy that have quietly appeared recently. For example:
USB keyboards and mice can be plugged into the hub found on many monitors, or into the front of many cases, rather than trailing all the way around to the back of a system unit. Cordless devices don't even need that, of course.
If you have peripherals like printers and scanners that can connect directly to a network, then you can use your hub/ADSL router/whatever as a focal point (which is their job, after all!) and plug individual stations into that, thus avoiding running extra cables from all your peripherals into the back of some PC's system unit.
If you use several external data storage boxes, consider whether you really need them, and whether you really need them to be connected to the box they are: it might be easier to just copy everything to a new, cheap, bigger hard disk. If you're running more than one PC on a network, consider moving all the boxes from your main workstation to an out-of-the-way machine that can act as your file server.
In any of the networking scenarios above, rather than running cables over extended distances, you can use wireless.
Basically, if you start by minimising the number of connections you have and the length of each cable, there's less to worry about tidying up in the first place.:-)
Slashdot Mirror
OK, that's the first eight weeks, give or take a maths course. What's in the second term?
EE is a fine subject, but it's not CS, and hiring an EE guy when you want a CS guy is a mistake. (Of course, hiring a CS guy when you want a code monkey is also a mistake.)
My undergrad degree was in maths, BTW, so I'm not grinding an axe here. And the first eight weeks comment was then, and according to the syllabus remains now, pretty accurate for the undergrad CS course at the university I went to.
It's always fascinating to hear people say we don't need as much understanding of CS these days, because all the outsourced code monkeys can do the mainstream programming, and no-one using programming incidentally needs that depth of understanding anyway.
Then they ask why software today seems to run slower than it did a decade ago despite hardware being orders of magnitude faster, complain about how everything on the Internet is insecure and they keep getting junk mail, wonder why web sites get Slashdotted so easily, get disappointed by the dumb actions of computer opponents in games, use grammar checkers that produce worse documents than they started with...
Sorry. The terms are common in the world of functional programming languages (Haskell, ML, etc.) but there's no reason someone who works with something like C would known them. You've already got a good reply, but at the risk of oversimplifying, I'll try to describe the concepts in more C-friendly terms.
A disjunctive type works a bit like a combination of a union (i.e., it can represent several kinds of data, but only one at once) and an enum that identifies which kind of data the current value is. A common example is making a "nullable" version of a type T, which might have two options:
which you'd define by simply listing the names of the possible options and the type each represents:
You can't access the value of an object with a disjunctive type directly, because you don't know which of the options is being used, and there needn't be any particular relationship between them. Instead, you use a technique called pattern matching, which is essentially a type check serving a similar purpose to C++'s dynamic_cast.
For example, to print an object obj of type Optional T, you can't write something structured like this:
because you don't know which of the two options obj is currently using, but you can write something structured like this instead:
to print "None" in the None case, or the value of the T object in the Some case.
(Obviously I'm making the syntax up here, although in fact what you write in many functional programming languages isn't far off this.)
In this way, you can define many useful types. Nullable variations are one example, but you can also extend that to data strucures like linked lists and trees, and much more.
With a type system like this, there is no built-in concept of NULL as there is with C's pointers. You just don't need it: if you want a nullable type, you create it explicitly (which usually requires a grand total of one extra word in the source code), but then the type system forces you to check for the null option properly when you access the data. There is no concept of dereferencing a null pointer or throwing a null reference exception, because you simply can't be in that position.
Wow, that was a truly awful post. Sorry. I'm writing this quickly at lunch and don't have time to edit it much. If you're interested in these concepts and their close relations -- and personally, I'd certainly rate them as one of my top five things the maintstream programming industry should get to! -- then you might like to search for:
There are some pretty good articles in various programming-related wikis that you'll probably find your way to via the above, although I give you fair warning that some of them get a bit deep, and the functional programming world does have its share of zealots and evangelists just like any other...
They're pretty standard in many keyboard layouts; here in the UK, they are '/@ and #/~ for example.
And no, it's not a problem moving your hand slightly off the home row to reach Enter; you get used to it in about five seconds.
They were also running on hardware literally thousands of times slower than today's, so none of the above is really any excuse.
I wrote software with GUIs that were instantly responsive back in MS-DOS and 12MHz 80286 days. I now specialise in writing scientific instrument control and mathematical software, so I'm somewhat familiar with how fast modern computers can really go, and the effects of having numerous custom drivers running under a multitasking OS. I really don't see any technical reason today's software can't be vastly faster than most of it is, but then technical reasons are rarely the limiting factor in software development.
We'd do a lot better if the software development community collectively learned a lot more about good design, dropped its lazy attitudes ("Of course $LANGUAGE_X is fast enough"), stopped relying on faster hardware as a crutch for slower code, learned to profile, and was given chance to do it by management rather than pushing the product out to market two days earlier.
You're thinking too classically, like a C programmer. With a higher-level language, more design intent can be expressed directly by the programmer, and used by the compiler for safety and optimisation purposes.
Sure, you can't check all arrays access for bounds violations, but if you think about it with your human level of understanding, very few accesses can ever really be dangerous. The trick is to be able to convey that level of understanding to the compiler, so it can perform the necessary checks, and no more.
As for NULL pointers, there's really no need for them at all if you have a serious type system. Recursive data structures are trivially dealt with if you have concepts like disjunctive types and pattern matching.
In fact, as useful as they can be at lower levels, pointers generally are only useful as reassignable references to objects. There's no need to relate pointers and arrays, nor to provide arbitrary pointer arithmetic and the NULL concept, with a moderately powerful type system.
There is a reason that many languages make a point of saying they don't support pointers, even if they have a more limited variation of the concept, as with things like Java. The killer isn't the concept of indirection, or changing the target, it's the arithmetic, and assignment of arbitrary values. That leads to a world without proper type safety, and it leads to aliasing concerns that have horribly negative effects on optimisation.
We can certainly agree on that. I think such disagreement as we have is a matter of timescales. I don't doubt that with time, IE7 will become an established player. My argument is simply that if developers don't go out of their way to accommodate it, it will have to be good much faster than that, because it won't have the market share to force the whole web to support it specially from the start. Otherwise, it risks people switching away to alternative browsers, something that is much more likely today than it was last time MS brought out a major new OS and attendant utilities. Hence I believe the correct thing for web developers to do to support IE7 is "absolutely nothing different".
Exactly. XP was supposed to be the release where the home and pro product lines came together. However, I'm not sure your graph shows any great transition from 2K to XP at all; at most, the number moving up to XP was balanced by the number moving up or over to 2K from NT4, or possibly the 9x series in a few cases.
Not quite. It shows that it took at most three years for the 9x series to establish what appears to be the entire home user base. They might have done it much faster, but since ME was a separate OS that would have been shipping on new machines for about half of that period and the graph doesn't give a breakdown of the two, it's hard to say. What is certain is that either not many people upgraded from 95/98 to ME, or the upgrade cycle slowed down a lot from ME to XP. I'm guessing that ME was the flop, but you can't tell from that graph.
Indeed, and I did acknowledge that I thought they would do something like this in my original post. However, the only official announcements I've seen to date said that IE7 would be Longhorn-only.
Perhaps I have more confidence in the Internet-using public than you. :-)
Five years ago, I'd have bought that argument. Since then, we've had worms and viruses, and security flaws in Microsoft products have started making mainstream news, as has the availability of alternatives.
For one thing, Firefox now represents a very credible threat on Microsoft's home turf (Windows boxes), and a lot of people who turn to their favourite geek for advice on setting up a new PC are going to be hearing about it who wouldn't have done a few years ago. Convert the home user geeks and the professional sysadmins, and the sheep will follow in both markets; it's only a matter of time.
For another thing, a lot more people are using the web routinely now than they were in the late '90s. People expect things like Internet banking, or that their favourite shop or restaurant will have a web site, and they've used these things with previous browsers. If something suddenly stops working after they buy their new PC that worked before, I doubt the first thing any intelligent adult will do is assume the site has broken, particularly when the first reply they get from the site's webmaster says that unfortunately Microsoft broke IE, and they're working on a fix but for now you need to use browser software that isn't broken.
Ah, now I've definitely got you. You're talking about the company that manages to break backward compatibility in one of its primary products, Microsoft Office, fundamentally in about every other version. 95->97 was a farce. Office 2K wasn't bad, but Office XP apps could crash trying to load older documents. I haven't played with the most recent version much yet, but in any case, Microsoft's compatibility history is not altogether glowing. I know they try -- I've read articles by insiders on just how hard they try -- and I realise that with the number of people using their products in different ways some issues are almost inevitable, but still, that's all true for IE as well.
And as I've noted throughout, if Microsoft don't create a significant compatibility problem, there will be no need for devs to do anything anyway, will there?
It's interesting that one of the most highly regarded "perks" in every survey of geek staff I've seen for years has been flexible working hours.
At my current employer, we have quite a clever policy: the rule is you have to be in the office for at least 5 hours between 9am and 6pm every day, but other than that, you can work your 37.5 as you see fit, with common sense applying when it comes to organising meetings and the like. What this means is that you're guaranteed to be in the office for at least an hour of overlap with any of your colleagues in a given day, so you never miss someone completely. However, you can effectively take a half-day off without using leave, or go in before the morning rush and then leave mid-afternoon to pick the kids up from school, etc.
I'd say most of the guys' typical hours are somewhere between 9:30-5:30 and 10:30-6:30. We also have quite a few habitual early starters and a few habitual come-in-at-lunchtime guys. There are even some guys who change quite radically from week to week or even day to day, such as the guy next to me whose fiancee works shifts at a hospital, or one of the girls who finishes early-late-early-late to alternative picking her son up from school with her husband.
This is a great arrangement, and it was interesting that when we were bought out by a US corp a few months back, this was one of the Big Things everyone was adamant we would keep in the new contract. (We collectively made them rewrite it so we could.) Of all the other "perks" brought in by the corp, none has anything like the value of this one, and I'm not sure I actually use any of the others.
I'm not an employment lawyer, so I can't give you a definite answer to that. I can certainly comfirm that other standard employment rights (e.g., a notice period before dismissal, during which pay is maintained) are very likely to be forfeit in the event of things like gross misconduct, deception, committing criminal activity, etc.
It's hard to say what would happen in this specific case, because I can't imagine anyone over here working an hourly rate in this particular business who isn't doing so as a contractor. I don't know enough about the US employment market to be sure, but I get the feeling the employment-at-will concept and the culture of salaried workers putting in stupidly long hours make the whole employer-employee relationship work very differently to ours. Maybe a lot more people across the pond still work hourly rates long after the jobs at that level would have been salary-based over here.
If they were at least trying to do a reasonably job, I'd assume so over here too. I'd be interested to find out whether that still applies when they're blatantly not, though.
We have a concept of a basic trust relationship between employer and employee that (so the lawyers tell me) forms part of any employment relationship. Either side may be able to invalidate part of the employment contract if they can demonstrate that this basic trust relationship has broken down. I'd say that getting a job by lying and then acting in bad faith once employed was a pretty clear breakdown of trust! Hence I'm guessing any attempt to fire someone immediately and without pay-to-date would be made on this basis, but as I said, I'm not a lawyer and this is based only on a layman's understanding of our employment laws.
And the big media firms will no doubt try to control the Internet as a result, before they adapt or die.
Fair enough, you've obviously seen some information I haven't noticed about where this story comes from.
Here in the UK, industrial tribunals have a pretty good reputation, since the panels are deliberately composed to include people who would naturally side with both sides and a relatively neutral lawyer. Companies certainly don't risk a tribunal lightly, because it's unlikely a tribunal will find in their favour if they have been acting improperly, but OTOH frivolous cases by (ex-)employees tend to be thrown out pretty quickly too.
It doesn't surprise me at all to find that the same neutrality isn't present in the US system; it seems like every time I read about any sort of law in the US these days, it's because it's stacked even further in favour of megacorps at the expense of consumers and/or staff.
Please think about what the figures in that graph represent for a minute. For example:
Also, notice that WinME isn't shown at all. There's a whole operating system that isn't there. If it's been merged into the Win98 figures, then that suggests that the adoption of WinXP was only around half as fast as its predecessors.
However, official announcements from Microsoft that they're dropping the two most useful pillars out of the original three that were supposed to be the heart of Longhorn are likely to be, well, representative of Microsoft policy, no?
Only measured over a period of years. The day after Longhorn comes out, if IE7 doesn't work with existing web sites, it's unlikely many of those sites will care at all. The same "support the majority player" mindset that has held back W3C standards compliance for years is going to come back and bite Microsoft in the backside now if they try to play proprietary again. Too bad.
No, I don't. My argument (see my original post) is simply that the best strategy for web developers is to do nothing special for IE7. If it "just works", that policy won't cost them anything. It if doesn't, I think it will hurt Microsoft a lot more than it hurts the WWW. My position doesn't lose either way.
I agree that it's a failure of the recruitment process, but where we differ is that I think a recruitment process can never be perfect, nor even close. It's simply unrealistic to expect any such process to weed out all the bad apples before they start, or to expect a company to supervise a new employee who claims certain basic competencies well enough to identify a bullshit artist immediately. However, I don't see why operating in the real world should be damaging to a company.
As I suggested in another post, the extent to which the employer's actions (or lack thereof) was negligent and led to their own demise in this case would probably have to be determined by a court or tribunal of suitable authority in that particular jurisdiction, with full access to the specific facts of the case. However, it seems to me that even if you're working for an hourly rate, if you lie to get a job and are completely incompetent to perform the work required, you don't deserve any legal protection just because you successfully pull the wool over your employer's eyes for a while. Even for an hourly rate, you're still being paid to do a job, and that's a two-sided deal. IMHO wilful dishonesty demonstrates clearly that there was no intent to meet one side of the bargain, and should therefore disqualify someone from any legal protection of the other side of the bargain by default. Why should an employer (and by extension, other staff with an interest in the company, any shareholders, etc.) be screwed for even a $MINOR_CURRENCY_UNIT to benefit a deceptive incompetent?
(Obviously this is a different case from a contractor, who clearly wouldn't get paid if they failed to meet the requirements of the contract, but I think we agree on that anyway.)
Thanks for the reply, but I think my reasoning was a little more thought out than you give credit for...
I find that extremely unlikely. Adoption of new operating systems from Microsoft has been slowing dramatically since Win2K. Even today, as Microsoft starts blatantly shutting off support to force people to upgrade, a very significant proportion of their customer base are not running WinXP.
Longhorn may be the most hyped MS operating system since the last one, but they've cut most of the potentially great stuff out of it already; see Slashdot discussions passim. There's not much of a compelling driver for upgrades, which means the only way it's getting out there in serious volumes is via new PCs.
A common business plan replaces PCs every three years, with plenty of places using older machines and software, and not many upgrading more frequently. That means for IE7 to reach the same penetration as IE6, even without other factors, would take the best part of three years. And this is assuming that everyone buying a new PC gets Longhorn, which isn't necessarily going to be the case for many reasons, and that no-one switches to a different browser in the meantime, which also isn't necessarily the case.
Microsoft just don't get those three years. If they're lucky, they get a month or two, by which time if there are serious incompatibility flaws, every magazine, on-line review site, CIO journal and tech news forum is going to be carrying the fact that IE7 breaks web sites and the damage really starts, crippling further spread of IE7.
Well, if it "just works", there will be no need for developers to do anything special to support it, will there?
But if it was going to "just work", Microsoft wouldn't need to spend a fortune trying to get everyone to check their sites and fix the breakage early. They're worried it won't "just work", which is pretty telling.
I admire your optimism. Gecko-based browsers have around 10% market share today, depending on who you ask, yet we're only just now seeing some key web sites (particularly those dealing with financial matters) upgrading in the face of customer pressure and bad PR. I very much doubt the kind of site naive enough to be IE6-only until recently is going to be IE7-ready the moment Microsoft releases it, if IE7-ready doesn't mean "works like IE6".
I'm not sure either part of that claim is true. A lot of cheapo shops and schoolkids pretending to be businessmen are IE only, but most of the pros I know (of which there are quite a few, given I work in a big tech centre) are more than familiar w
I'll have to take your word for that, because I don't know where this incident occurred or the law there. I'm pretty sure that if you're guilty of something as serious as deception or gross misconduct, the normal rules often don't always apply, though. I'd expect the extent to which that's true of an employee if they're paid by the hour, and how much it would depend on the level of supervision, is probably something for an industrial tribunal or suitable court to decide.
I would certainly be surprised if you could get a job by completely lying on your application, work for some amount of time nominally on an hourly rate but not actually doing the job, and still have legal support for getting paid, though. That seems hugely unfair to an employer, regardless of any duty to provide reasonable supervision.
Change absolutely nothing. Your strategy is as simple as that. Continue to develop for W3C standards, and make the usual pragmatic concessions to allow for IE 5 and 6. Make no special attempt to accommodate IE7 whatsoever.
This strategy is a clear winner for one simple reason. The only reason MS gets a lot of developers to code for IE is because it's big. When you have 90% market share, you don't follow the standard, you define it, regardless of what the W3C and its supporters might wish were the case. As a corollary, when you have 90% of market share, a lot of ill-informed cheaposoft developers will code for your software because they don't know any better.
However, when IE7 comes out, it will not have 90% market share. It starts at 0% like everyone else, and if it isn't directly compatible with either the W3C standards or Microsoft's previous one (the now-well-known quirks in IE 5/6) then it gets a category of its own.
Moreover, since MS were making a big point of how IE7 will only be part of Longhorn and won't be available as a retrofit onto the previous versions of Windows, they are almost condemning it to be a minority player for several years. Just look as how many home users are still running ME, and how many businesses are still on 2000, never mind XP. (As an aside, I heard rumours of this policy changing, though I've not personally noticed anything official from Microsoft about it yet. I'll be amazed if there isn't an IE7 upgrade for WinXP available the moment it releases, though.)
If critical web sites like banks and the big e-shops don't immediately work reliably with IE7 -- and that information will probably spread very fast -- then this will hurt Microsoft's sales and market share. Microsoft will not sell as many copies of its new operating systems as long as they rely on IE7, so they will either have to fix IE7 or drop it and advise users to switch to something that works. In the meantime, big players like Dell will not be selling as many new PCs, or they'll be stuck with the overheads of supporting multiple OS configurations at supply time. After they had to do that with Win2K, when many major customers said they just didn't want the untried-and-untested WinXP installed on their new systems, I suspect they'll be very reluctant to do it again because of something as stupid as a web browser.
In summary, Microsoft only bullies the dev community right now because it has huge market share. IE7 will not start with a huge market share, and if Microsoft does restrict it to Longhorn only as they threatened in the past, IE7 will not develop a huge market share either. Thus IE7 is not a tool with which to bully the development community, it is a tool that must comply with the will of the development community. If it does not, Microsoft and the customers and business partners it most cares about will lose money, and that is the one thing they will not allow to happen.
Of course, Microsoft are well aware of this risk, which is why their legendary PR machine is now trying to mitigate it. All that is necessary to defeat this ploy is to see the PR for what it is: an attempt to trick the dev community into helping Microsoft, not the other way around.
I was just about to post and ask why anyone pays someone so incompetent, until I noticed your final comment. I would have thought dropping the company/firing the individual without any pay whatsoever would be completely justified if they were specifically asked to produce standards-compliant code as part of the spec.
The facts that they fobbed their employer off with "it's unimportant", didn't know about Mozilla, and ripped copyrighted code just demonstrate that they were incapable of doing the job they accepted and were acting in bad faith throughout; this was no accidental misunderstanding or legitimate ambiguity in the agreed specification. If anything, the company/employer whose time and resources they wasted should be suing them to recover losses through wasted time and effort, though sadly this probably isn't how it's going to work out in practice.
If I'm reading this right, they are simply using open source software, and not necessarily (as the Slashdot summary says) "[using] OSS modules in their applications". Was I the only one who immediately read that as if they were linking (L)GPL'd modules into their code or something similar?
It's not really clear what the statistic includes anyway. The only specific cases mentioned in TFA are "the operating system" and "application servers like Jboss or Gluecode". I certainly wouldn't describe using a Linux box somewhere in my organisation as "using an OSS module in my application", and I doubt more than half the software developers in the world use something like Jboss or Gluecode. Does writing software in an OSS-friendly scripting language count? Using an OSS database in the back-end? Does using Firefox to access a web-app?
Without clarification, the number is as meaningless as most other OSS-vs.-CSS statistics produced by either side.
Sure, but sitting here in the UK and speaking in all seriousness, would I miss it?
The most US-centric resource I use with any regularity on the Internet is in fact Slashdot, which I find interesting and informative enough to read fairly regularly, and entertaining enough to post to a few times in a day if I'm on-line. I also follow a few other techie sites, some of which are US-based, though not as regularly.
However, the other things I use frequently are e-mail, Usenet, a few UK-based e-shops, the BBC News web site, and a few UK-based web pages related to my various hobbies, exactly none of which would even blink if the US disappeared from the Internet tomorrow, but for logistical hiccoughs. And of course, the UK would come up with its own alternative to the various techie forums like /. pretty fast. Think of it as "branching". ;-)
As for the economics, a split would hurt the US far more than anyone else. A large part of current US financial policy is geared toward international trade. Personally, I'd love it to happen for that reason alone; my various savings accounts and pension funds are well-distributed geographically with a local bias, and certainly many local companies I indirectly hold shares in would be likely to increase in value dramatically in the absence of competition from Internet-based alternatives in the US. In fact, the US appears to have been running an unsustainable economic policy that's likely to collapse sooner rather than later for some time, and the more distance there is between that and our relatively healthy economic state over here in Europe when it goes, the better!
I'm honestly not trying to troll here, though I realise it may come across that way. I'm simply illustrating how little the US content on the Internet matters to someone in my country, even a pseudo-geek like me. And if anything other than US-based content disappears, that is a clear weakness in the architecture that should be addressed for the security of everyone else's service -- which, I believe, is where we came in.
On the contrary, I'm well aware of that, and consider that a compelling argument that it is realistic for the remainder of the world to force the US to concede control of the DNS system to an international group. (No, I'm not convinced the UN is the right one either, but something not entirely under the control of one nation's government would be considerably more resilient in certain plausible scenarios.)
Incidentally, many of the same arguments apply to the GPS satellite system, and you may have noticed that an alternative one of those is also being constructed outside of US control, at considerable expense. That certainly tells me something about the lengths other nations will go to in order to ensure the security of services they regard as essential.
No one country did. That's exactly the point. For a start, the Internet is almost by definition a network of networks, many of which are not in the US. Moreover, there is no clear "creation date"; different aspects of what we know today as "the Internet" appeared at very different times in history.
What became today's Internet was mostly driven by academic research. While I'll certainly concede that much of the initial research during the '60s and early '70s happened in the US, it's still clear that from a very early stage, the research effort was international. For example, ISoc's brief history of the Internet mentions researchers in the UK working in parallel with the US research as early as 1967, until the groups discovered each other and started collaborating.
The infrastructure is obviously international, and for the most part quite capable of surviving without any one country. Networks that now form major parts of the Internet have existed in other countries for over 20 years. (The same history notes the existence of the JANET in the UK in 1984, while another mentions satellite links to Hawaii and the UK as early as 1975 and the creation of EUnet, connecting the Netherlands, Denmark, Sweden, and UK, in 1982.)
The software side, in particular the established communications protocols for things like e-mail, WWW, Usenet or FTP communication, has come from diverse sources. What was effectively the first TCP/IP standard was presented to an international working group at Sussex University in the UK in 1973.
Bodies like the IETF and W3C have geographically diverse memberships. While the US has by far the largest single category of W3C membership today, it still represents less than 40% of the total, which isn't much more than Europe, for example. There are a total of 28 countries with member organisations.
For any one country, including the US, to claim that this whole picture developed because of it, or wouldn't have happened in a similar way without it, is simply a delusion of grandeur. It might not have happened as fast, or in exactly the same way, but it would still have happened, probably working off the research done in Europe.
I find it deeply ironic that one of the other replies to my GP post was an AC who claimed I was trolling, and challenged me to provide information about other countries that contributed to the Internet's creation, while another accuses me of rewriting history. Fortunately, while a lot of mostly US-based Internet history pages choose to ignore the contributions from outside and focus on the US academic network during the early stages, the kind of information above (all of which is written by the people and organisations at the heart of the Internet) is freely available, even to those in the US.
You write that as if the entire world outside the US isn't already in that exact position. This is your insurgency on a massive scale.
I'm guessing Steak and Shake is some US food place, right? If that's the case, then your comparison is missing the point: the UN can't easily meddle internally in the US, but if the other nations representing it want to dump the US control of DNS, they can relatively easily just switch to an alternative system. Then the US can either play by everyone else's rules or not play at all. It gets no third choice of "status quo".
You may not even realise it, but the thinking exemplified by the above quote is exactly the reason the international community is so wary of leaving the US with any controlling interest in the Internet at all.
The US did not create the Internet. It may have played a larger part in some aspects than other countries, but it is neither responsible for all of the technological innovation, nor for even the majority of the investment, nor for keeping it running as it stands today. The fact that ICANN and its overlords are effectively US-government-controlled is an anomaly, not the norm.
The current US administration has demonstrated a great willingness to interfere in the affairs of foreign nations economically, legislatively and even militarily, essentially to further its own economic interests. This doesn't exactly engender trust on the part of those nationss' governments, and you can't really be surprised that they don't trust the US to "do the right thing" any more.
I was about to post the answer "a bin", but it looks like you beat me to it...
Seriously, I always smile when I hear about geeks with five home computers in their study, seventeen kinds of connectivity to each one, and so on. I mean, how many different boxen can you type on at once, anyway?!
I think a lot of people overlook simple ways to keep things tidy that have quietly appeared recently. For example:
Basically, if you start by minimising the number of connections you have and the length of each cable, there's less to worry about tidying up in the first place. :-)