Hopefully in your alternate universe, "it's" no longer means "it is" (or "it has"), and your sentence parses correctly.
As it is, it's "its", as in, "It's likely that when this thing hits a patch of ice its rider will end up in the hospital."
Normally I don't nitpick, but like a flaw in an otherwise attractive painting it catches the discerning eye. Of course, it's only relevant if you're looking for karma...
...but there's a difference between saying that many people might benefit from coding, and professionals will be unable to do anything but manual labor without coding experience.
Sure, coders do need to be familiar with the domain of the problems they are trying to solve. However, I really, really doubt that, say, every therapist will need to be able to code in order to help children from broken homes.
Besides, even given the assumption that everyone who isn't swinging a pick axe can code, there are a lot of wheels that will be reinvented out there. Chances are that certain programs will become widely distributed, and people will get back to their actual jobs.
The point is that there's a difference between saying that programmers are much more useful when they have knowledge of non-CS domains to which they can apply their knowledge (which is what you seem to be saying) and saying that an air traffic controller who can't code will end up doing yard work, which is what the author of the article seems to be saying.
Whether he meant to say so or not I won't argue, but he said that the "the ability to read and write code will be as essential for professionals of every stripe as the ability to read and write a human language is today", and those who cannot write code "will have to get a manual job - if there are any left."
Although, looking at the other side of the coin, perhaps you are correct in your interpretation -- namely, that the author didn't mean what he actually said, he meant what you actually said. If that is the case, perhaps he is showing that today one can get by as an author without the ability to write clearly. If that is the case, his statement would imply that "in 50 years, perhaps much less", people who write code poorly will be okay, just as those who write unclear articles often are today.
I think the author does have a point: programming is becoming more pervasive, and what will separate the expendable from the indispensable is your ability to control the machine.
I might agree if the author hadn't said that all professionals would be unemployed unless they could code.
Furthermore, professionals are still hired by companies. Often companies realize that specialization can be more efficient than having every employee perform every task. I would imagine that long before a company would ask every employee to learn to code, they would find a few people to develop the apps they need in-house. This would allow a few people to know the codebase well, rather than many people to know the codebase a little bit.
Of course, this supports your point quite well, but not the author's.
You accused MS of stealing code from Linux. I asked you to justify that. Now you're accusing them of stealing code from VMS, et. al.
You're pulling SCO tactics. SCO accused IBM of misappropriation of trade secrets. IBM asked SCO for evidence, and they pulled out something from SGI.
You accused MS of stealing Linux code. I'm not even asking for actual evidence, I'm asking for something which might lead to reasonable suspicion. Going on about lawyers won't get you around the fact that you have yet to provide information which even causes Microsoft to look suspect.
He's saying most people are doing such menial jobs in the information sector that they could easily be replaced by a machine.
I think he's saying much more than that.
From the article:
In 50 years, perhaps much less, the ability to read and write code will be as essential for professionals of every stripe as the ability to read and write a human language is today. If your children's children can't speak the language of the machines, they will have to get a manual job - if there are any left.
Emphasis added.
As I've stated elsewhere, if someone tries to convince me that a doctor or lawyer's time is best spent coding, I'm going to call bullshit. That's what programmers are for -- I wouldn't expect a coder to diagnose illness, and I wouldn't expect a doctor to write code.
In 50 years, perhaps much less, the ability to read and write code will be as essential for professionals of every stripe as the ability to read and write a human language is today. If your children's children can't speak the language of the machines, they will have to get a manual job - if there are any left.
Your little example (knowing that a starter is an electric motor) is like knowing what a partition is.
To put it in automotive terms, the article says that anyone who can't change a head gasket or rebuild a transmission won't be able to drive.
Yes, it's a shitty analogy, but all analogies break down when you look closely enough. The point is, it's rediculous to say that a doctor or lawyer will be forced to "get a manual job" simply because they don't have "the ability to read and write code", which is what the article suggests.
There's a difference between knowing enough of the physics of driving to pull out of a fishtail and knowing how, say, a CV joint works (or even what it does).
Okay, okay, you said RWD, so let's say a limited-slip differential, or a torque converter (or throwout bearing, if you're of that persuasion), or a water pump, or an ignition system.
Did you read the article? Did you catch this paragraph?
In 50 years, perhaps much less, the ability to read and write code will be as essential for professionals of every stripe as the ability to read and write a human language is today. If your children's children can't speak the language of the machines, they will have to get a manual job - if there are any left.
If an article tells me that doctors and lawyers will have to know how to code in order to save themselves from field work, I'm going to call bullshit, plain and simple.
The article doesn't say that people will have to "process information". It says that people who cannot read and write code (not click on GUI widgets, write code) will be stuck with manual labor. Look:
In 50 years, perhaps much less, the ability to read and write code will be as essential for professionals of every stripe as the ability to read and write a human language is today. If your children's children can't speak the language of the machines, they will have to get a manual job - if there are any left.
To use a computer, you must understand the abstract concepts - this is a program, it runs, it interacts with files, files are stored in directories, etc.
Yes. I would agree that this is fairly requisite knowledge for, say, word processing.
But knowing how to write your own program is not requisite knowledge, which the article implies pretty strongly.
What is "[using] a computer to its full potential"?
Can you use a hammer to its full potential? What about an axe? A paintbrush?
Computers are tools. If they get the job done effectively, then they are good tools.
I don't understand this elitism. If someone wants to write a letter, let them write a letter, don't try to force programming up their ass. They're not "wasting" the tool, they're using it just as you are when you're piping output in bash.
Are there more convenient ways to do things? Possibly, but if the job gets done and the user is happy, then I'd say that's an overall success.
I'm not missing that point, I totally agree with it.
The future of computing isn't in forcing the users to know how to code. The future of computing is in designing interfaces that map better and better with human expectation and intuition (such as, say, uninstalling an application under MacOS, instead of Windows' unintuitive counterpart).
No, basically the article said what I did in my summary -- that people would no longer be able to use computers without programming knowledge.
Not that programming knowledge would be useful. That it it would be necessary. That secretaries won't be able to write a letter without coding knowledge.
You'll argue that the article deserved a place on the homepage, but you didn't read it? What is the homepage for, if not for referring to articles which are worth reading?
On the other hand, programming concepts are reaching the general public in spread sheets, style sheets, search engine strings, database queries
How does a spreadsheet require programming knowledge?
The average user has no idea what a style sheet is, let alone how to write one.
Search engine strings? I haven't done anything but type in what I'm looking for into the search box since Google arrived on the scene. This is about as difficult as telling a librarian what sort of book you're looking for.
Furthermore, I'd wager that easily 99% of computer users couldn't even pick an SQL query out of a lineup, let alone write one.
That's also why cell phones, VCRs, and microwaves turn on instantly instead of having to boot up; Their functionality is usually fixed.
Interesting. My cell phone, VCR, DVD player, Playstation, and Comcast cable box all have a delay between initial power-on and full functionality. It's too bad that you claiming that they don't doesn't suddenly make my cell phone allow me to place a call within 8 seconds of initial power-on, since it's still starting up (not seeking service, starting up).
GUIs map very well to how computers actually function, and that's one of the current problems with them. Example: If I drag a file from one folder to another on the same hard drive, it moves it. If I drag it from one folder to another folder that is on another hard drive or a network share, it copies it.
How does this rather arbitrary design choice map well to the way the system actually functions? In this case, the GUI is designed with the user's actions in mind, not the system's function.
In years past, users often used media to which the system often had only temporary access (such as floppies). When the user dragged a file to another drive (especially to or from removable media), the system assumed that the user was making a copy, such as for backup purposes. When the user dragged a file to another location on the same drive, the system assumed that the user was placing the file in a more appropriate location, and moved it.
This design decision had nothing to do with any underlying operating system requirements or behaviour that files cannot be moved across media unless the user is holding a modifier key.
I would claim that many GUI components don't map very well to the state that they try to represent. Take, for instance, the famous hourglass cursor. It's not actually indicative of system load, but rather appears at the whim of the application developer during times which he or she has imagined the system might be unresponsive. These are two different things -- Windows will happily thrash the swap file for minutes on end while the cursor remains arrow-shaped.
Why isn't the UI consistent? Why must the user be exposed to the underlying physical storage structure to know if their file will be moved or copied?
And furthermore, what does this have to do with any mapping between the way the system functions on a basic level and the GUI? The GUI calls one OS function if the user is dragging between directories on the same drive, and another function if they're dragging between drives. This is an arbitrary design choice, not an insight into the underlying OS.
You seem to confuse being able to perform normal maintenance (changing oil, inspecting various components, checking fluid levels, etc.) with understanding how, say, a limited-slip differential or CV joint works.
I never said that computer users won't have to perform maintenance (such as performing backups, restoring old versions of files, installing and upgrading software, etc.) -- I said that programming experience isn't a prerequisite for using computers, and probably won't be in the future.
Furthermore, driving a stick-shift does not teach you how the transmission works. Moving a lever and pushing a foot pedal does not explain how synchros work to make the shift smoother, or how the shifting forks select the proper gear, or how the throwout bearing is laid out.
Nor is any of that necessary knowledge for those who drive stick-shifts, and most of it probably wouldn't even help the average driver.
And I don't like SUVs. If I wanted something tall with tons of cargo room that handled much worse than the average car, I'd drive a minivan.
I would say that any worker using a computer who can do his job without doing ANY programming could be replaced by a slightly better program than the one he is ``operating''. The only exceptions would be people doing jobs which are wholly creative, and could be done without a computer at all (e.g., writers, who could use pencil and paper).
What about people using computers in doctor's offices to maintain patient records? Or the doctor whose PDA allows him to search medical data sets? What about people using their computers to write letters, or to play MP3s? Who work in auto body shops and use computers to help them to write accurate estimates? Those who do little but browse the Internet and check their email?
Those doing data entry? What about bank tellers? They use computers to handle transactions and look up customer data. People have been predicting for years that they'd be replaced by ATMs, as you are suggesting that most of the non-creative uses of computers will be automated.
Have you walked into a bank lately? There are an awful lot of people behind the desks and teller lines, 30 years after ATMs started being used.
I would say that any worker using a computer who can do his job without doing ANY programming could be replaced by a slightly better program than the one he is ``operating''.
News flash: Those doctors, repairmen, and bank employees to whom I referred aren't writing the software themselves. Their jobs are already being enhanced by computers, but they aren't the ones writing the tools.
That's why there's a need for programmers, you see. There's a reason why programs aren't normally written in production environments. Would you rather enter a doctor's office and wait for hours because the doctor is debugging his latest app?
Perhaps it would make more sense for him to devote his time to helping people, and for programmers to write the programs.
GUIs don't map very well to the way that computers actually function.
Within 50 years, the average secretary will need to know how to program or will be unable to perform his or her job.
Those aren't direct quotes, but that's the meat of the article.
Imagine that in 1930, somebody said that the controls presented to drivers don't map well enough to the function of cars, and that in the future people would have to know how every drivetrain component works in order to drive or face losing the ability to use public roads.
You don't have to know how a VCR functions in order to use it. You don't have to know how your cell phone transmits signals in order to use it. You don't have to be an engineer or know how a torque converter works in order to drive with an automatic transmission.
I don't see why an article that states that users will have to know how to code in order to use computers is worth a spot on the homepage.
You suggested that Microsoft stole code. Not ideas, code.
Remember Linux dates back to the days of Win 3 or even a might earlier... 1)There's pre-emptive multitasking - oops, no Linux had that first,
...and many operating systems had preemptive multitasking before Linux. This is similar to asserting that any car with four wheels is emulating Honda, simply because Honda happens to produce four-wheeled vehicles.
Windoze started with multi-threading tasks, and wouldn't scale past 3 CPUs in an MPU system until they *emulated* the Linux tasking scheme
Until the very recent past, Linux scaling wasn't much to write home about either. Systems such as Solaris were much more scalable. Microsoft wasn't trying to beat Linux -- in fact, for years they've been promising a scalable, preemptive operating environment.
2) Clustering support - oops, no Linux had that first, WIndoze atarted with "warm-spare" failover clustering that couldn't share tasks - till they *emulated* Linux clustering
Again, clustering existed before Linux. Clustering is not unique to Linux.
3) Multi-user File security - oops, no Linux had that first. WIndoze started as a single user system that didn't have file ownership, till they *emulated* Linux security
No, MS didn't emulate the UNIX security model, which you somehow attribute to Linux despite the fact that it existed years before even Linux v0.01. Microsoft's security model is much finer-grained. In fact, NTFS has supported ACLs for years.
Does the version of ext3 included in modern kernels support ACLs yet?
4) LDAP authentication for single sign-on - oops,no Linux had that first. Windoze didn't have networking support at all, let alone network based authentication until they *emulated* Linux in AD...except that NT supported remote authentication years ago, and certainly before Active Directory...
5) Network File Sharing - oops, no, Linux had that first. Windoze didn't have the ability to share much of anything over a network until they *Emulated* NFS with SMB.
Let's check Microsoft's own Windows Server Products History page, shall we?
The public caught the first glimpse of a new type of Microsoft Windows(R) operating system in August 1991, when Windows Advanced Server for LAN Manager was demonstrated at a developers conference. By the time it launched two years later, the product had been renamed Microsoft Windows NT(R) and marked the first appearance of the Windows Server operating system. It quickly became known for its support of high-performance servers, advanced workstations, and client/server computing.
I downloaded a copy of the Linux 0.96c source code. Source files are stamped as late as April 24, 1992 (files mentioning that date are all SCSI-related, btw -- aha1542.c, aha1542.h, hosts.c, hosts.h, scsi.c, scsi.h, sd.h, seagate.c, st.c, and st.h, all in kernel/blk_drv/scsi/), and the only mention of NFS is in lib/malloc.c ("We will probably need this functionality when networking code, particularily things like NFS, is added to Linux.").
In other words, MS had aspirations to develop a networked operating system before Linux supported NFS at all.
5) The CLI for the new "Foghorn: Windoze" - oops, no Linux had that first. Windoze won't have the complex scripting ability of Linux until they *emulate* it in 2005.
Actually, you're wrong again on that one. Microsoft products are scriptable to a fault -- in fact, a friend of mine wrote a tool to parse Makefiles and direct MS DevStudio to perform the appropriate actions years ago.
MS Office products are scriptable to a level that Linux GUI products only dream of.
And the list goes on and on and on... Yeah every once in a while M$ works a deal with a hardware maker, and gets them to write a windoze driver for a USB camera or some similar gadget that
Consider first the fact that many, many more devices are supported under Windows than under a Linux-based operating system. Consider further that most of the time, hardware which is supported under Linux was supported under Windows first.
What if the rumors are true, and MS has been lowering software development costs by incorporating open-source drivers into Windoze?
What rumors? Other than your post, I've never heard of anyone accusing MS of stealing driver code from Linux. MS' networking code is quite likely derived from BSD code, but that's 100% legal.
MS has been working for years on Windows. Linux has matured rapidly in recent years, but so have Microsoft's operating systems.
Many MS APIs look nothing like their OSS counterparts. Like SCO accusing Linux contributors of theft without offering proof, you seem to be pointing fingers without much justification.
But hey, it's cool to bash MS and misspell product names. How clever of you!
Slashdot Mirror
As it is, it's "its", as in, "It's likely that when this thing hits a patch of ice its rider will end up in the hospital."
Normally I don't nitpick, but like a flaw in an otherwise attractive painting it catches the discerning eye. Of course, it's only relevant if you're looking for karma...
If so, I'm sure that lawyers all around would be interested in seeing the results.
If not, then you're wrong!
Sure, coders do need to be familiar with the domain of the problems they are trying to solve. However, I really, really doubt that, say, every therapist will need to be able to code in order to help children from broken homes.
Besides, even given the assumption that everyone who isn't swinging a pick axe can code, there are a lot of wheels that will be reinvented out there. Chances are that certain programs will become widely distributed, and people will get back to their actual jobs.
The point is that there's a difference between saying that programmers are much more useful when they have knowledge of non-CS domains to which they can apply their knowledge (which is what you seem to be saying) and saying that an air traffic controller who can't code will end up doing yard work, which is what the author of the article seems to be saying.
Whether he meant to say so or not I won't argue, but he said that the "the ability to read and write code will be as essential for professionals of every stripe as the ability to read and write a human language is today", and those who cannot write code "will have to get a manual job - if there are any left."
Although, looking at the other side of the coin, perhaps you are correct in your interpretation -- namely, that the author didn't mean what he actually said, he meant what you actually said. If that is the case, perhaps he is showing that today one can get by as an author without the ability to write clearly. If that is the case, his statement would imply that "in 50 years, perhaps much less", people who write code poorly will be okay, just as those who write unclear articles often are today.
I might agree if the author hadn't said that all professionals would be unemployed unless they could code.
Furthermore, professionals are still hired by companies. Often companies realize that specialization can be more efficient than having every employee perform every task. I would imagine that long before a company would ask every employee to learn to code, they would find a few people to develop the apps they need in-house. This would allow a few people to know the codebase well, rather than many people to know the codebase a little bit.
Of course, this supports your point quite well, but not the author's.
Have you tried integrating a virgin node recently?
I have, and it's not gone well.
You accused MS of stealing code from Linux. I asked you to justify that. Now you're accusing them of stealing code from VMS, et. al.
You're pulling SCO tactics. SCO accused IBM of misappropriation of trade secrets. IBM asked SCO for evidence, and they pulled out something from SGI.
You accused MS of stealing Linux code. I'm not even asking for actual evidence, I'm asking for something which might lead to reasonable suspicion. Going on about lawyers won't get you around the fact that you have yet to provide information which even causes Microsoft to look suspect.
From the article:
Emphasis added.
As I've stated elsewhere, if someone tries to convince me that a doctor or lawyer's time is best spent coding, I'm going to call bullshit. That's what programmers are for -- I wouldn't expect a coder to diagnose illness, and I wouldn't expect a doctor to write code.
I don't disagree, but it's still quite different from, say, writing application software (or even being able to parse Perl code).
What I'm arguing against is statements like this:
Your little example (knowing that a starter is an electric motor) is like knowing what a partition is.
To put it in automotive terms, the article says that anyone who can't change a head gasket or rebuild a transmission won't be able to drive.
Yes, it's a shitty analogy, but all analogies break down when you look closely enough. The point is, it's rediculous to say that a doctor or lawyer will be forced to "get a manual job" simply because they don't have "the ability to read and write code", which is what the article suggests.
YES!
Thank you. I hoped I wasn't along in feeling that if a doctor needs to write code, the computing industry is woefully lacking.
Okay, okay, you said RWD, so let's say a limited-slip differential, or a torque converter (or throwout bearing, if you're of that persuasion), or a water pump, or an ignition system.
Did you read the article? Did you catch this paragraph?
If an article tells me that doctors and lawyers will have to know how to code in order to save themselves from field work, I'm going to call bullshit, plain and simple.
Emphasis added.
But knowing how to write your own program is not requisite knowledge, which the article implies pretty strongly.
What is "[using] a computer to its full potential"?
Can you use a hammer to its full potential? What about an axe? A paintbrush?
Computers are tools. If they get the job done effectively, then they are good tools.
I don't understand this elitism. If someone wants to write a letter, let them write a letter, don't try to force programming up their ass. They're not "wasting" the tool, they're using it just as you are when you're piping output in bash.
Are there more convenient ways to do things? Possibly, but if the job gets done and the user is happy, then I'd say that's an overall success.
I'm not missing that point, I totally agree with it.
The future of computing isn't in forcing the users to know how to code. The future of computing is in designing interfaces that map better and better with human expectation and intuition (such as, say, uninstalling an application under MacOS, instead of Windows' unintuitive counterpart).
No, basically the article said what I did in my summary -- that people would no longer be able to use computers without programming knowledge.
Not that programming knowledge would be useful. That it it would be necessary. That secretaries won't be able to write a letter without coding knowledge.
You'll argue that the article deserved a place on the homepage, but you didn't read it? What is the homepage for, if not for referring to articles which are worth reading?
The average user has no idea what a style sheet is, let alone how to write one.
Search engine strings? I haven't done anything but type in what I'm looking for into the search box since Google arrived on the scene. This is about as difficult as telling a librarian what sort of book you're looking for.
Furthermore, I'd wager that easily 99% of computer users couldn't even pick an SQL query out of a lineup, let alone write one.
How does this rather arbitrary design choice map well to the way the system actually functions? In this case, the GUI is designed with the user's actions in mind, not the system's function.
In years past, users often used media to which the system often had only temporary access (such as floppies). When the user dragged a file to another drive (especially to or from removable media), the system assumed that the user was making a copy, such as for backup purposes. When the user dragged a file to another location on the same drive, the system assumed that the user was placing the file in a more appropriate location, and moved it.
This design decision had nothing to do with any underlying operating system requirements or behaviour that files cannot be moved across media unless the user is holding a modifier key.
I would claim that many GUI components don't map very well to the state that they try to represent. Take, for instance, the famous hourglass cursor. It's not actually indicative of system load, but rather appears at the whim of the application developer during times which he or she has imagined the system might be unresponsive. These are two different things -- Windows will happily thrash the swap file for minutes on end while the cursor remains arrow-shaped.
And furthermore, what does this have to do with any mapping between the way the system functions on a basic level and the GUI? The GUI calls one OS function if the user is dragging between directories on the same drive, and another function if they're dragging between drives. This is an arbitrary design choice, not an insight into the underlying OS.
You seem to confuse being able to perform normal maintenance (changing oil, inspecting various components, checking fluid levels, etc.) with understanding how, say, a limited-slip differential or CV joint works.
I never said that computer users won't have to perform maintenance (such as performing backups, restoring old versions of files, installing and upgrading software, etc.) -- I said that programming experience isn't a prerequisite for using computers, and probably won't be in the future.
Furthermore, driving a stick-shift does not teach you how the transmission works. Moving a lever and pushing a foot pedal does not explain how synchros work to make the shift smoother, or how the shifting forks select the proper gear, or how the throwout bearing is laid out.
Nor is any of that necessary knowledge for those who drive stick-shifts, and most of it probably wouldn't even help the average driver.
And I don't like SUVs. If I wanted something tall with tons of cargo room that handled much worse than the average car, I'd drive a minivan.
Those doing data entry? What about bank tellers? They use computers to handle transactions and look up customer data. People have been predicting for years that they'd be replaced by ATMs, as you are suggesting that most of the non-creative uses of computers will be automated.
Have you walked into a bank lately? There are an awful lot of people behind the desks and teller lines, 30 years after ATMs started being used.
News flash: Those doctors, repairmen, and bank employees to whom I referred aren't writing the software themselves. Their jobs are already being enhanced by computers, but they aren't the ones writing the tools.
That's why there's a need for programmers, you see. There's a reason why programs aren't normally written in production environments. Would you rather enter a doctor's office and wait for hours because the doctor is debugging his latest app?
Perhaps it would make more sense for him to devote his time to helping people, and for programmers to write the programs.
You don't have to know how to code in order to use Quicken, or GNUCash.
And I do know how to change a tire safely, but again, that has nothing to do with how the vehicle actually works.
Changing a tire is like restoring a file from a backup, not like writing C code.
Those aren't direct quotes, but that's the meat of the article.
Imagine that in 1930, somebody said that the controls presented to drivers don't map well enough to the function of cars, and that in the future people would have to know how every drivetrain component works in order to drive or face losing the ability to use public roads.
You don't have to know how a VCR functions in order to use it. You don't have to know how your cell phone transmits signals in order to use it. You don't have to be an engineer or know how a torque converter works in order to drive with an automatic transmission.
I don't see why an article that states that users will have to know how to code in order to use computers is worth a spot on the homepage.
Am I missing something here?
Remember Linux dates back to the days of Win 3 or even a might earlier... 1)There's pre-emptive multitasking - oops, no Linux had that first,
Windoze started with multi-threading tasks, and wouldn't scale past 3 CPUs in an MPU system until they *emulated* the Linux tasking scheme
Until the very recent past, Linux scaling wasn't much to write home about either. Systems such as Solaris were much more scalable. Microsoft wasn't trying to beat Linux -- in fact, for years they've been promising a scalable, preemptive operating environment.
2) Clustering support - oops, no Linux had that first, WIndoze atarted with "warm-spare" failover clustering that couldn't share tasks - till they *emulated* Linux clustering
Again, clustering existed before Linux. Clustering is not unique to Linux.
3) Multi-user File security - oops, no Linux had that first. WIndoze started as a single user system that didn't have file ownership, till they *emulated* Linux security
No, MS didn't emulate the UNIX security model, which you somehow attribute to Linux despite the fact that it existed years before even Linux v0.01. Microsoft's security model is much finer-grained. In fact, NTFS has supported ACLs for years.
Does the version of ext3 included in modern kernels support ACLs yet?
4) LDAP authentication for single sign-on - oops,no Linux had that first. Windoze didn't have networking support at all, let alone network based authentication until they *emulated* Linux in AD
5) Network File Sharing - oops, no, Linux had that first. Windoze didn't have the ability to share much of anything over a network until they *Emulated* NFS with SMB.
Let's check Microsoft's own Windows Server Products History page, shall we?
I downloaded a copy of the Linux 0.96c source code. Source files are stamped as late as April 24, 1992 (files mentioning that date are all SCSI-related, btw -- aha1542.c, aha1542.h, hosts.c, hosts.h, scsi.c, scsi.h, sd.h, seagate.c, st.c, and st.h, all in kernel/blk_drv/scsi/), and the only mention of NFS is in lib/malloc.c ("We will probably need this functionality when networking code, particularily things like NFS, is added to Linux.").
In other words, MS had aspirations to develop a networked operating system before Linux supported NFS at all.
5) The CLI for the new "Foghorn: Windoze" - oops, no Linux had that first. Windoze won't have the complex scripting ability of Linux until they *emulate* it in 2005.
Actually, you're wrong again on that one. Microsoft products are scriptable to a fault -- in fact, a friend of mine wrote a tool to parse Makefiles and direct MS DevStudio to perform the appropriate actions years ago.
MS Office products are scriptable to a level that Linux GUI products only dream of.
And the list goes on and on and on... Yeah every once in a while M$ works a deal with a hardware maker, and gets them to write a windoze driver for a USB camera or some similar gadget that
Did anyone else think that "SCO's Lawyers Analyzed" meant that they were finally seeing psychiatrists?
Er, wait...
In a word, no.
Consider first the fact that many, many more devices are supported under Windows than under a Linux-based operating system. Consider further that most of the time, hardware which is supported under Linux was supported under Windows first.
What if the rumors are true, and MS has been lowering software development costs by incorporating open-source drivers into Windoze?
What rumors? Other than your post, I've never heard of anyone accusing MS of stealing driver code from Linux. MS' networking code is quite likely derived from BSD code, but that's 100% legal.
MS has been working for years on Windows. Linux has matured rapidly in recent years, but so have Microsoft's operating systems.
Many MS APIs look nothing like their OSS counterparts. Like SCO accusing Linux contributors of theft without offering proof, you seem to be pointing fingers without much justification.
But hey, it's cool to bash MS and misspell product names. How clever of you!