As others have pointed out, what you're talking about is a fileserver, not a SAN.
However, interest in cheap SANs is rising, and I suspect it won't be long before a couple of projects start up to build these, then they get polished, then corporate types get interested in the big cost savings, and they start using these. It'd be particularly cool if Linux beat Windows to the gun here.
Before you scoff, remember that that's what happened with the advent of clustering cheap PCs -- the custom supercomputer is nearly a dead beast now.
There are enormous profits on SANs, so an open-source project could do wonders here.
Just one point -- Serial ATA is going to run in parallel with vanilla ATA for a while, while vendors skim money off high-end users. It's not going to be "SCSI at ATA prices", at least not right away.
This is despite the fact that they use a gnu (NEW) as their logo. I hate cutesy logos/names designed to be annoying or complicated to say....as I post this on "slashdot"...
He said that operating systems will inherently have security holes.
I wonder if he meant that operating systems will inherently have remote security holes? I'm not so sure that's true, if you're using few servers, simpler ones, and ones not written in C.
The exploit is well known and people are aware of it. It's the same thing that Slapper.A and Slapper.B used.
Also, while the article makes much of "thousands" of servers compromised, it ignores the fact that the number of compromised servers is (at least last I saw) in the five digits, and pretty much leveled off to very few new infections.
Similar Windows worms (like Code Red) infected hundreds of thousands of machines, and took much longer to level off. Yes, there are still a lot of computers out there, but UNIX admins are a lot more on top of their machines than Win admins, by these numbers.
Every time you create a copy of your program with fork() you consume another large chunk of memory.
No, not really. You *do* need to allocate kernel data structures for a new process, but you have to do the same thing for a thread, and in Linux the two things are essentially the same, so there isn't a huge overhead there. As for fork() -- when you fork() you produce a new *process*, not a whole copy of the old process' memory. The contents of the program's memory are actually not copied. If the child process does nothing but read memory, no memory is ever copied -- it reuses the parent's memory (well...I lied a little. No memory in the *heap*, but that's the overwhelming majority of the space.). The only time the memory is actually copied is if you try writing to it.
So here are the scenerios you could have: (1) Need to have children threads/processes alter memory. Then you need to make copies of the memory anyway. With threads, this is manual, and with processes automatic. (2) Do not need to have children threads/processes alter memory. Then processes are no more expensive than threads, and you avoid accidental race issues due to better separation of the two threads of execution.
I said I was qualified to comment on the state for developers. Every statement above I made is backed up by my experience, which is no less valid than your own. If you want 15 years of Win32 development to make a simple evaluation, sorry, can't do it.
In any event, if you feel otherwise, you're certainly more than free to post your own evaluation of the situation for others to critique. I'd be interested in something more than negative personal criticism, if you're up to it.
And yet, it doesn't seem like this is such an issue for the Linux world, since software is distributed in source, rather than binary, form.
I expect that package systems will become even simpler over the years...probably eventually simpler than InstallShield (which doesn't have the ability to get, say, dependencies).
Yes, you can do CreateProcess(), but because Windows doesn't have support for copy-on-write, it's massively expensive in memory and CPU time, and destroys the fork() programming model where you can spawn off copies of servers that can be done so elegantly in Linux. Instead, you're required to use threads. Now, there *are* a few tasks better done with threads, but generally, developers in Windows are forced to use threads for tasks that they really should be using processes for.
Also, while mingw does work (I use it whenever I'm in Windows), it has a number of issues.
First, there are bits of the headers that are always out of date -- I had to send in a couple of corrections while doing work with mingw. Granted, the mingw team fixed them immediately (thank you, open source!), but they're still forced into a situation of necessarily playing perpetual catch-up with Microsoft.
Second, the support for mingw with third party tools is less than good. You can cobble together a decent toolkit, but it takes work and a fair bit of knowledge of what you're doing. There's a resource compiler (and a free resource editor) that you can make work together with a fair bit of poking. You can compile libraries, after learning about Windows and mingw name mangling and calling convention issues. I could never get gdb working, though it's possible that someone else could. And snippits of source and third party tools do not tie in well with mingw.
This is not meant to be criticism of mingw -- I'm very impressed with their tool, but they're in something of the same position as the WINE folks -- they're deeply invading what Microsoft considers to be its own turf, and compatibility issues will come up unless they're on top of any changes like hawks.
Maybe true, but MinGW works quite well. MAME is compiled with MinGW. And it works just as well as GCC does on Linux.
I've used MinGW on two professional projects, and while I can say that I enjoy using it (mostly because of familiarity with gcc), it definitely requires one to go above-and-beyond because of the massive Visual Studio emphasis among Windows developers. I ended up having to learn quite a bit about Windows symbol mangling, calling conventions, and resource storage to do basic stuff like store dialog resources and build a library....ever hear about Purify and BoundsChecker?
Neither are general-purpose debuggers.
Also GDB works on Windows just fine
Well, I certainly haven't had any success using it. If you have a working copy (might be in cygwin -- I use exclusively win32 native ports if I'm working in Windows, like mingw), I strongly suspect that there are some major limitations.
Very true, but how else are you going to get someone with a philosophy degree to program?
Ironically enough, I happen to have a philosophy degree, as does another close friend who's a skilled coder.
No guarantee of binary compatibility between version of GTK?
Not major release version changes, no. Same goes for Microsoft's C runtime if you're used to Windows or other libraries.
For the record, I am not a MSFT schill...
Good. I'm not either...but they do have some things going for them and Linux is not perfect.
Oh, I agree. It's just that from the developer's point of view, the table is hugely tilted toward Linux, and seeing Balmer talking about how much Microsoft values and coddles programmers cracks me up.
Resorting to distorted "fact" sheets like this is just as bad as MSFT.
Please, if you have any major shortcomings Linux has from a developer's standpoint that MS's platform doesn't have, enlighten me.
Oh -- there is the recompile-in-place feature of VS's debugger/IDE that I've never tried -- Carmack was drooling over it, though. That's the only thing I can think of.
I'll bet you that some Microsoft programmers support Open Source and even work on it for kicks in their spare time.
Of the four people that I indirectly know that work at Microsoft, three prefer using and developing for Linux (one has a Tux doll in his cubicle at Microsoft), and only the least competent one doesn't know or like Linux (but he's also a Visual Basic programmer, as opposed to the others).
It's hard for MS to *find* competent developers that dislike UNIX. UNIX was designed to *be* a developer's baby.
Internet Explorer is the best browser today? Do you not use any sites that produce popups or something? Do you never block cookies or ads from a site? Are you not concerned about any of the holes that keep being shown in it?
As for Office beating LaTeX, Office has always been much easier to use and LaTeX has always produced higher quality output. That won't change unless Office moves to a whole new font and layout architecture. Knuth is still years ahead of the competition in quality.
You like Visual Studio? It's really slick editor is a joke to people that use emacs, its "world class" debugger may well be good but not *that* much better, and it has a decent compiler, but lacks lots of other supporting development tools like the whole GNU suite.
I crack up when I see the "Developers" line. Let me compare thee to Linux (which will represent the open source community as a whole), MS development environment:
COMPILER:
Linux: Many compilers for many languages. Free. LCC and GCC for C, G++ for C++, Eiffel, *ML, more than I want to go through. If you want, you can also buy commercial compilers like icc.
MS: Killed most compilers for their platform (except the oddball ones) by squashing them with their own. Visual C++ generates pretty tight code, but you're just screwed if you run into a bug with it. Oh, and it costs lots of money. Most compilers commercial. Mingw/cygwin exists but not supported well (MSDN support bitterly hates both).
DEBUGGERS/DIAGNOSTICS:
Linux: memprof, debauch, debug mode on malloc, gdb, strace, ltrace....many, many, many more. These were the ones I used on my last small project. All these are free, and there are many more.
MS: Um...ntinternals put out regmon and filemon. Apparently MS puts out WinDBG for free, though I haven't used it and apparently it isn't too popular. No free high level debuggers. Few diagnostic programs for already compiled code.
DEVELOPER SUPPORT:
Linux: Email the developers for the kernel, libc, SDL, XFree86, or whatever library or kernel bit you're working on if you find a weird corner case or bug. Get response, bug fix, patch. Most exchanges between core developers documented on publically available (and searchable) mailing lists, so usually you don't even have to email. Lots of IRC channels of developers who are interested in talking about their work.
MS: Guess at what's going on underneath the covers, most of the time. No source to look at. Some newsgroups, mostly for higher level problems. Can purchase extremely expensive (though usually effective) MSDN incidents.
SAMPLE CODE
Linux: Tons. Usually, if it runs on Linux, you can see the code. If you're using a library and you find an unclear bit in the documentation, you can take a look at the source.
MS: A fair bit, in certain areas. Game developers, in particular, have built up some web sites that have lots of snippits. Usually hard/impossible to get library source code.
GENERAL DEVELOPER COMPETENCE:
Linux: Many new programmers, but most are interested in technology for its own sake and doing cool things with it, so learn the system inside out. Some accessable very skilled systems developers.
MS: Many, many Visual Basic coders. MS dug its own grave with Visual Basic. Very low barrier to entry, very difficult to scale above a certain height ("Well, you *can* do this advanced thing in Visual Basic...you just need to also know how the underlying Win32 API works and how Visual Basic chooses to interact with it"). Some contractors that should be shot before calling themselves developers (I remember an expensive contract with a GUI-coding-tool using developer at one company...). Some competent ones, as well.
APIS:
Linux: Some UNIX cruft. Usually, APIs are pretty clean. Emphasis is on keeping things clean for the many developers -- if something is unclear in gtk1, fix it in gtk2.
Windows: The most godawful APIs in the world. Win32 is so full of cruft, poor conventions, inconsistent conventions, and unnecessarily complicated *crap* that it's amazing. Most advanced MFC programmers end up having to interact with Win32 as well to do certain things that MFC can't do. Has some great snippits on MSDN, along the lines of "Do not use this argument, as it represents a security risk and has been obsoleted. Some developers may wish to use this argument for backwards compatibility with Microsoft CSPs."
OS CAPABILITIES:
Linux: Pretty much if you could want it in an OS, it's there. I've yet to miss something (well, Linux *does* need disk priorities on processes for scheduling, but Windows lacks them as well).
MS: No fork()? Damn, that was a pretty convenient syscall. How about file deletion...can I delete or move an open file? No? Nuts. As for the registry...well, it's one ugly, giant unregulated hack that lots of programs directly modify and end up screwing up all sorts of stuff. The number of times I've seen borked file associations because a program was writing straight to the registry and prevented Explorer from reading or coping with the file association is ridiculous.
I could go on, but the point is that any MS claims of being ahead on making life good for developers are absolutely ludicrous. The *worst* thing about Windows, easily, is doing development for it.
And ten years later we find out that the hallway is circular, leading through an infinite series of doors...the robot ends up staring at their own asses from behind.
This must get them a lot of PR and funding. I mean, how often can you make an archaelogical announcement that hits the big news sites that says "We found another door!" Normally, you have to find an unlooted pharoh's tomb or Viking traces in Florida or something.
Technology like clustering would be better in Windows than Linux eventually, said Balmer
Intimidating.
"We will beat Linux on clusters."
Good luck. There's a lot more researchers doing distributed Linux work than there are on Windows, though I'm sure MS is blowing lots of money on it in their private labs. Windows is not great for a headless cluster machine -- lousy remote administration, high CPU/RAM overhead, not the best performance, costs more.
As for their distributed filesystem beating Linux...well, might happen, but they're building on a database (overhead implied), whereas Linux has the excellent AFS (openafs and arla implementations, both free), Coda, and Intermezzo, plus some other fringe ones. All the filesystem people I know (CMU is a big distributed filesystems research place) do Solaris or Linux...not Windows.
Microsoft is considering extending its shared-source initiative
You don't get it, do you, Microsoft? Seeing the source is the smallest benefit of open source to your customers. *They* mostly care about less immediate license costs, and (the biggie) no vendor lock in in the Linux world. Open source strongly facilitates this. Your NDA and smartcard supported limited shared source program doesn't interest these types in the least -- especially the NDAs, which are designed to *increase* lock-in.
For nine years, the company has designated users with particular skills -- usually seen by how often they intervene helpfully in newsgroups -- as "most valued professionals". Currently there are about 1,200 MVPs, half of whom are in the United States
Whee. Linux never needed a formal system for this because it already happens. Stop by any of the channels on irc.openproject.net. You can get hours of real-time help...not just one lousy newsgroup post. Good luck on this one, MS.
"We do not anticipate offering software on Linux. Nobody pays for software on Linux."
Hell, I'll bet there's a lower percentage of Linux users pirating *any* Linux software than there are Windows users *pirating Microsoft Windows*! The only reason anyone pays is because MS does aggressive business audits and has OEM deals.
The big issue there [with IBM], he said, was a reluctance to accept legal liability for open-source software.
Well, fuck me senseless. MS must be planning on accepting legal liability for their own closed source software. Hot damn. I've wasted more times fixing problems that their software has caused than I can count. Windows Updates that bluescreen and render a computer unbootable. Crashing Office installations. You name it. I've been wrong about MS all along! They're going to come through and actually support their software! Tech support will be free, not expensive "incident-based" issues! Woohoo!
Aren't journalling filesystems implemented in the kernel side?
Yes. I'm talking about the system as viewed as the kernel being the client and the hard drive the server, not the kernel the server and the apps the client.
I'm not talking about data in files. I'm talking about the metadata that comprises the filesystem. That's transaction based, and does do rollbacks if power is lost in the middle.
You could extend this to files if you wanted to, once you've established that it can be done for metadata.
My point was that it is certainly technically possible to do the work with client side code. The hard drive does not natively provide "transaction support".
I think what it could really do with is different regional sections...
Argh! No!
news.google.com has been up for *months*! I've been getting my news from them for some time, and they're awesome...and they *just* changed the interface to this ugly table-based thing that you see today. They used to have a simple, clean interface. Argh!
Yes. The network was not originally based around a single central point of failure, but in an effort to make money, the Kazaa people added a centralized authentication system in. If this point is shut down, the entire network goes down.
Until it is shown that most people pirate content that they either already own, have owned or purchase legally in the future....
Riiight.
Also, purchasing in the future does not make pirating the song legal. It also makes sense not to have that make it legal -- to some degree, you decrease the value of the song by listening to it, since the best time is the first time. Also, the artist/company does not have your money in the meantime, and cannot be using the money to produce more goods or earn interest.
It doesn't matter what you're doing is even in the RIAA or even artists' best interests -- it's still illegal.
Now, whether you're concerned over whether what you do is a crime is your own concern...
Actually, "yours" is defined by the legal system, so, no, it isn't yours.
You have the right to own and listen to your copy, though. You also have a few other specifically granted rights. But you do not hold the copyright on the music, which is the mark of ownership of that music.
You do own the raw CD, and you could melt it and then do whatever you like with the raw materials...but you do not have ownership of the data that comes pre-recorded on the CD.
Scalability has been so oversold that it drives me nuts. Yes, sometimes it's an awfully good idea to have -- you have something crucial to your company that might drastically grow. Maybe a.com's backend. But, as you pointed out about your "small ebusiness server" bit...sometimes you know that your load isn't going to increase by 100x and overload the server.
Scalability is what the DB vendors like -- "you're already running DB X? Great! Just drop another $Y to us -- you're already semi-locked in to us!"
Slashdot Mirror
As others have pointed out, what you're talking about is a fileserver, not a SAN.
However, interest in cheap SANs is rising, and I suspect it won't be long before a couple of projects start up to build these, then they get polished, then corporate types get interested in the big cost savings, and they start using these. It'd be particularly cool if Linux beat Windows to the gun here.
Before you scoff, remember that that's what happened with the advent of clustering cheap PCs -- the custom supercomputer is nearly a dead beast now.
There are enormous profits on SANs, so an open-source project could do wonders here.
Just one point -- Serial ATA is going to run in parallel with vanilla ATA for a while, while vendors skim money off high-end users. It's not going to be "SCSI at ATA prices", at least not right away.
This is despite the fact that they use a gnu (NEW) as their logo. I hate cutesy logos/names designed to be annoying or complicated to say. ...as I post this on "slashdot"...
He said that operating systems will inherently have security holes.
I wonder if he meant that operating systems will inherently have remote security holes? I'm not so sure that's true, if you're using few servers, simpler ones, and ones not written in C.
And the patch fixes the hole that all variants use.
The exploit is well known and people are aware of it. It's the same thing that Slapper.A and Slapper.B used.
Also, while the article makes much of "thousands" of servers compromised, it ignores the fact that the number of compromised servers is (at least last I saw) in the five digits, and pretty much leveled off to very few new infections.
Similar Windows worms (like Code Red) infected hundreds of thousands of machines, and took much longer to level off. Yes, there are still a lot of computers out there, but UNIX admins are a lot more on top of their machines than Win admins, by these numbers.
Every time you create a copy of your program with fork() you consume another large chunk of memory.
No, not really. You *do* need to allocate kernel data structures for a new process, but you have to do the same thing for a thread, and in Linux the two things are essentially the same, so there isn't a huge overhead there. As for fork() -- when you fork() you produce a new *process*, not a whole copy of the old process' memory. The contents of the program's memory are actually not copied. If the child process does nothing but read memory, no memory is ever copied -- it reuses the parent's memory (well...I lied a little. No memory in the *heap*, but that's the overwhelming majority of the space.). The only time the memory is actually copied is if you try writing to it.
So here are the scenerios you could have:
(1) Need to have children threads/processes alter memory. Then you need to make copies of the memory anyway. With threads, this is manual, and with processes automatic. (2) Do not need to have children threads/processes alter memory. Then processes are no more expensive than threads, and you avoid accidental race issues due to better separation of the two threads of execution.
I said I was qualified to comment on the state for developers. Every statement above I made is backed up by my experience, which is no less valid than your own. If you want 15 years of Win32 development to make a simple evaluation, sorry, can't do it.
In any event, if you feel otherwise, you're certainly more than free to post your own evaluation of the situation for others to critique. I'd be interested in something more than negative personal criticism, if you're up to it.
Doesn't make much sense, but it's part of their name.
And yet, it doesn't seem like this is such an issue for the Linux world, since software is distributed in source, rather than binary, form.
I expect that package systems will become even simpler over the years...probably eventually simpler than InstallShield (which doesn't have the ability to get, say, dependencies).
Yes, you can do CreateProcess(), but because Windows doesn't have support for copy-on-write, it's massively expensive in memory and CPU time, and destroys the fork() programming model where you can spawn off copies of servers that can be done so elegantly in Linux. Instead, you're required to use threads. Now, there *are* a few tasks better done with threads, but generally, developers in Windows are forced to use threads for tasks that they really should be using processes for.
Also, while mingw does work (I use it whenever I'm in Windows), it has a number of issues.
First, there are bits of the headers that are always out of date -- I had to send in a couple of corrections while doing work with mingw. Granted, the mingw team fixed them immediately (thank you, open source!), but they're still forced into a situation of necessarily playing perpetual catch-up with Microsoft.
Second, the support for mingw with third party tools is less than good. You can cobble together a decent toolkit, but it takes work and a fair bit of knowledge of what you're doing. There's a resource compiler (and a free resource editor) that you can make work together with a fair bit of poking. You can compile libraries, after learning about Windows and mingw name mangling and calling convention issues. I could never get gdb working, though it's possible that someone else could. And snippits of source and third party tools do not tie in well with mingw.
This is not meant to be criticism of mingw -- I'm very impressed with their tool, but they're in something of the same position as the WINE folks -- they're deeply invading what Microsoft considers to be its own turf, and compatibility issues will come up unless they're on top of any changes like hawks.
Obviously developing on the Microsoft platform is beyond your capability.
Ah? I've done two Win32 projects professionally. I think I'm reasonably qualified to make criticisms about its shortcomings as regard developers.
Maybe true, but MinGW works quite well. MAME is compiled with MinGW. And it works just as well as GCC does on Linux.
...ever hear about Purify and BoundsChecker?
..but they do have some things going for them and Linux is not perfect.
I've used MinGW on two professional projects, and while I can say that I enjoy using it (mostly because of familiarity with gcc), it definitely requires one to go above-and-beyond because of the massive Visual Studio emphasis among Windows developers. I ended up having to learn quite a bit about Windows symbol mangling, calling conventions, and resource storage to do basic stuff like store dialog resources and build a library.
Neither are general-purpose debuggers.
Also GDB works on Windows just fine
Well, I certainly haven't had any success using it. If you have a working copy (might be in cygwin -- I use exclusively win32 native ports if I'm working in Windows, like mingw), I strongly suspect that there are some major limitations.
Very true, but how else are you going to get someone with a philosophy degree to program?
Ironically enough, I happen to have a philosophy degree, as does another close friend who's a skilled coder.
No guarantee of binary compatibility between version of GTK?
Not major release version changes, no. Same goes for Microsoft's C runtime if you're used to Windows or other libraries.
For the record, I am not a MSFT schill...
Good. I'm not either.
Oh, I agree. It's just that from the developer's point of view, the table is hugely tilted toward Linux, and seeing Balmer talking about how much Microsoft values and coddles programmers cracks me up.
Resorting to distorted "fact" sheets like this is just as bad as MSFT.
Please, if you have any major shortcomings Linux has from a developer's standpoint that MS's platform doesn't have, enlighten me.
Oh -- there is the recompile-in-place feature of VS's debugger/IDE that I've never tried -- Carmack was drooling over it, though. That's the only thing I can think of.
I'll bet you that some Microsoft programmers support Open Source and even work on it for kicks in their spare time.
Of the four people that I indirectly know that work at Microsoft, three prefer using and developing for Linux (one has a Tux doll in his cubicle at Microsoft), and only the least competent one doesn't know or like Linux (but he's also a Visual Basic programmer, as opposed to the others).
It's hard for MS to *find* competent developers that dislike UNIX. UNIX was designed to *be* a developer's baby.
Internet Explorer is the best browser today? Do you not use any sites that produce popups or something? Do you never block cookies or ads from a site? Are you not concerned about any of the holes that keep being shown in it?
As for Office beating LaTeX, Office has always been much easier to use and LaTeX has always produced higher quality output. That won't change unless Office moves to a whole new font and layout architecture. Knuth is still years ahead of the competition in quality.
You like Visual Studio? It's really slick editor is a joke to people that use emacs, its "world class" debugger may well be good but not *that* much better, and it has a decent compiler, but lacks lots of other supporting development tools like the whole GNU suite.
I crack up when I see the "Developers" line. Let me compare thee to Linux (which will represent the open source community as a whole), MS development environment:
COMPILER:
Linux:
Many compilers for many languages. Free. LCC and GCC for C, G++ for C++, Eiffel, *ML, more than I want to go through. If you want, you can also buy commercial compilers like icc.
MS:
Killed most compilers for their platform (except the oddball ones) by squashing them with their own. Visual C++ generates pretty tight code, but you're just screwed if you run into a bug with it. Oh, and it costs lots of money. Most compilers commercial. Mingw/cygwin exists but not supported well (MSDN support bitterly hates both).
DEBUGGERS/DIAGNOSTICS:
Linux:
memprof, debauch, debug mode on malloc, gdb, strace, ltrace....many, many, many more. These were the ones I used on my last small project. All these are free, and there are many more.
MS:
Um...ntinternals put out regmon and filemon. Apparently MS puts out WinDBG for free, though I haven't used it and apparently it isn't too popular. No free high level debuggers. Few diagnostic programs for already compiled code.
DEVELOPER SUPPORT:
Linux:
Email the developers for the kernel, libc, SDL, XFree86, or whatever library or kernel bit you're working on if you find a weird corner case or bug. Get response, bug fix, patch. Most exchanges between core developers documented on publically available (and searchable) mailing lists, so usually you don't even have to email. Lots of IRC channels of developers who are interested in talking about their work.
MS:
Guess at what's going on underneath the covers, most of the time. No source to look at. Some newsgroups, mostly for higher level problems. Can purchase extremely expensive (though usually effective) MSDN incidents.
SAMPLE CODE
Linux:
Tons. Usually, if it runs on Linux, you can see the code. If you're using a library and you find an unclear bit in the documentation, you can take a look at the source.
MS:
A fair bit, in certain areas. Game developers, in particular, have built up some web sites that have lots of snippits. Usually hard/impossible to get library source code.
GENERAL DEVELOPER COMPETENCE:
Linux:
Many new programmers, but most are interested in technology for its own sake and doing cool things with it, so learn the system inside out. Some accessable very skilled systems developers.
MS:
Many, many Visual Basic coders. MS dug its own grave with Visual Basic. Very low barrier to entry, very difficult to scale above a certain height ("Well, you *can* do this advanced thing in Visual Basic...you just need to also know how the underlying Win32 API works and how Visual Basic chooses to interact with it"). Some contractors that should be shot before calling themselves developers (I remember an expensive contract with a GUI-coding-tool using developer at one company...). Some competent ones, as well.
APIS:
Linux:
Some UNIX cruft. Usually, APIs are pretty clean. Emphasis is on keeping things clean for the many developers -- if something is unclear in gtk1, fix it in gtk2.
Windows:
The most godawful APIs in the world. Win32 is so full of cruft, poor conventions, inconsistent conventions, and unnecessarily complicated *crap* that it's amazing. Most advanced MFC programmers end up having to interact with Win32 as well to do certain things that MFC can't do. Has some great snippits on MSDN, along the lines of "Do not use this argument, as it represents a security risk and has been obsoleted. Some developers may wish to use this argument for backwards compatibility with Microsoft CSPs."
OS CAPABILITIES:
Linux:
Pretty much if you could want it in an OS, it's there. I've yet to miss something (well, Linux *does* need disk priorities on processes for scheduling, but Windows lacks them as well).
MS:
No fork()? Damn, that was a pretty convenient syscall. How about file deletion...can I delete or move an open file? No? Nuts. As for the registry...well, it's one ugly, giant unregulated hack that lots of programs directly modify and end up screwing up all sorts of stuff. The number of times I've seen borked file associations because a program was writing straight to the registry and prevented Explorer from reading or coping with the file association is ridiculous.
I could go on, but the point is that any MS claims of being ahead on making life good for developers are absolutely ludicrous. The *worst* thing about Windows, easily, is doing development for it.
And ten years later we find out that the hallway is circular, leading through an infinite series of doors...the robot ends up staring at their own asses from behind.
This must get them a lot of PR and funding. I mean, how often can you make an archaelogical announcement that hits the big news sites that says "We found another door!" Normally, you have to find an unlooted pharoh's tomb or Viking traces in Florida or something.
Technology like clustering would be better in Windows than Linux eventually, said Balmer
Intimidating.
"We will beat Linux on clusters."
Good luck. There's a lot more researchers doing distributed Linux work than there are on Windows, though I'm sure MS is blowing lots of money on it in their private labs. Windows is not great for a headless cluster machine -- lousy remote administration, high CPU/RAM overhead, not the best performance, costs more.
As for their distributed filesystem beating Linux...well, might happen, but they're building on a database (overhead implied), whereas Linux has the excellent AFS (openafs and arla implementations, both free), Coda, and Intermezzo, plus some other fringe ones. All the filesystem people I know (CMU is a big distributed filesystems research place) do Solaris or Linux...not Windows.
Microsoft is considering extending its shared-source initiative
You don't get it, do you, Microsoft? Seeing the source is the smallest benefit of open source to your customers. *They* mostly care about less immediate license costs, and (the biggie) no vendor lock in in the Linux world. Open source strongly facilitates this. Your NDA and smartcard supported limited shared source program doesn't interest these types in the least -- especially the NDAs, which are designed to *increase* lock-in.
For nine years, the company has designated users with particular skills -- usually seen by how often they intervene helpfully in newsgroups -- as "most valued professionals". Currently there are about 1,200 MVPs, half of whom are in the United States
Whee. Linux never needed a formal system for this because it already happens. Stop by any of the channels on irc.openproject.net. You can get hours of real-time help...not just one lousy newsgroup post. Good luck on this one, MS.
"We do not anticipate offering software on Linux. Nobody pays for software on Linux."
Hell, I'll bet there's a lower percentage of Linux users pirating *any* Linux software than there are Windows users *pirating Microsoft Windows*! The only reason anyone pays is because MS does aggressive business audits and has OEM deals.
The big issue there [with IBM], he said, was a reluctance to accept legal liability for open-source software.
Well, fuck me senseless. MS must be planning on accepting legal liability for their own closed source software. Hot damn. I've wasted more times fixing problems that their software has caused than I can count. Windows Updates that bluescreen and render a computer unbootable. Crashing Office installations. You name it. I've been wrong about MS all along! They're going to come through and actually support their software! Tech support will be free, not expensive "incident-based" issues! Woohoo!
Aren't journalling filesystems implemented in the kernel side?
Yes. I'm talking about the system as viewed as the kernel being the client and the hard drive the server, not the kernel the server and the apps the client.
I'm not talking about data in files. I'm talking about the metadata that comprises the filesystem. That's transaction based, and does do rollbacks if power is lost in the middle.
You could extend this to files if you wanted to, once you've established that it can be done for metadata.
My point was that it is certainly technically possible to do the work with client side code. The hard drive does not natively provide "transaction support".
I think what it could really do with is different regional sections...
Argh! No!
news.google.com has been up for *months*! I've been getting my news from them for some time, and they're awesome...and they *just* changed the interface to this ugly table-based thing that you see today. They used to have a simple, clean interface. Argh!
Yes. The network was not originally based around a single central point of failure, but in an effort to make money, the Kazaa people added a centralized authentication system in. If this point is shut down, the entire network goes down.
Until it is shown that most people pirate content that they either already own, have owned or purchase legally in the future....
Riiight.
Also, purchasing in the future does not make pirating the song legal. It also makes sense not to have that make it legal -- to some degree, you decrease the value of the song by listening to it, since the best time is the first time. Also, the artist/company does not have your money in the meantime, and cannot be using the money to produce more goods or earn interest.
It doesn't matter what you're doing is even in the RIAA or even artists' best interests -- it's still illegal.
Now, whether you're concerned over whether what you do is a crime is your own concern...
Actually, "yours" is defined by the legal system, so, no, it isn't yours.
You have the right to own and listen to your copy, though. You also have a few other specifically granted rights. But you do not hold the copyright on the music, which is the mark of ownership of that music.
You do own the raw CD, and you could melt it and then do whatever you like with the raw materials...but you do not have ownership of the data that comes pre-recorded on the CD.
Scalability has been so oversold that it drives me nuts. Yes, sometimes it's an awfully good idea to have -- you have something crucial to your company that might drastically grow. Maybe a .com's backend. But, as you pointed out about your "small ebusiness server" bit...sometimes you know that your load isn't going to increase by 100x and overload the server.
Scalability is what the DB vendors like -- "you're already running DB X? Great! Just drop another $Y to us -- you're already semi-locked in to us!"