Final line in the paper: "Therefore, the most we can read from the overall balance of marks is that open source development approaches do not produce software of markedly higher quality than proprietary software development."
Interesting, but not shocking for those who have worked with disciplined commercial teams. I wonder what the results would be in less critical areas than the kernel, say certain types of applications.
Er...hopefully you realise that the great, vast majority of server-side and webapp business programming is in Java, and has been for ages. Java is the new Cobol.
Wow, that is one skewed view of business history you have there. It almost sounds like you form your opinions and get your business news from Slashdot, rather than mainstream business sources.
As a guess, I'd say it's because desktop computer gaming is dwindling, while mobile sales are exploding and it's a ripe new market for a convergence device. Meanwhile, the stationary gaming experience is owned by consoles.
Yeah, but the stuff responsible for your file system integrity is the same stuff on every Linux system. Slack isn't unique because of having "better" code. It's the same across distributions.
There is no big push back to Perl that I can see. I have not had a single client request it, and in fact I haven't heard of any large-scale new developments done in Perl in years. It's a legacy language, for all intents and purposes.
The entire point of threads is to share everything ^_~ Agreed, which is why it's not a one-size-fits-all multiprocessing solution. Unfortunately, most people think it is, and that it's the only option.
In fact, sharing everything is generally unsuitable except in some cases - what you really want to do is share certain objects.
Agreed, that's what I heard too, but like you I couldn't find the reference.
My major problem with threading is simply that it breaks "encapsulation", if you generalise that term beyond object orientation. Threads have access to everything in the process space, even those objects that you'd rather not have them know about. That's why tuplespaces appeal to me: put those objects that are supposed to be synchronised somewhere special for processes to access, and don't bother worrying about everything else.
Well, I recall Unix threads as being difficult and divergent depending on OS. I wrote threaded code on AIX, HPUX, and Solaris. I recall compilation difficulties on AIX (different version of cc required, if I recall) and on Solaris it was just plain difficult, using a library called thr_thread (I think). Trying to write cross-platform threaded code was a pain vs. just using fork().
I later used pthreads, of course, and that was much easier, but multiprocesses always seemed to be "the way things were done" - all the server software forked to service requests or whatever, rather than used threads.
On Linux, Linus's anti-thread stance was a reflection of prevailing Unix attitudes. Threading has always seemed like the red-headed stepchild of Unix multiprocessing.
Meanwhile, threads were in NT from day one, for better or for worse.
Threads only seemed to get really popular with Windows. Unix programming has typically always been multi-process with some form of shared memory. I've heard (and this is unconfirmed hearsay) that CreateProcess() on Windows is so heavyweight that they pushed for a comprehensive threading model instead.
These concerns (size, density, etc.) are addressed in the report, and in summary, there's more to it than that. Canada is way less dense and way bigger and has significantly better coverage, thanks in part to more enlightened policymakers.
They are also perfect for busy programmers like me who deploy to Unix/Linux and who are sick to death of the endless clusterfuck nightmare that is desktop Linux. Of course, desktop Linux is perfect for casual, non-professional hobbyist types, or people who place no value on their time.
Actually, it's only around 825 000 installs (55 000 labs * 15 "access points" per lab) serving several tens of millions of students. It's still a lot, but not as huge as one install per student.
Slashdot Mirror
Final line in the paper: "Therefore, the most we can read from the overall balance of marks is that open source development approaches do not produce software of markedly higher quality than proprietary software development."
Interesting, but not shocking for those who have worked with disciplined commercial teams. I wonder what the results would be in less critical areas than the kernel, say certain types of applications.
Er...hopefully you realise that the great, vast majority of server-side and webapp business programming is in Java, and has been for ages. Java is the new Cobol.
Wow, that is one skewed view of business history you have there. It almost sounds like you form your opinions and get your business news from Slashdot, rather than mainstream business sources.
Short answer: no.
Long answer: no.
As a guess, I'd say it's because desktop computer gaming is dwindling, while mobile sales are exploding and it's a ripe new market for a convergence device. Meanwhile, the stationary gaming experience is owned by consoles.
Key word from the summary: "mobile".
Yeah, but the stuff responsible for your file system integrity is the same stuff on every Linux system. Slack isn't unique because of having "better" code. It's the same across distributions.
Or to use an analogy: Java is the new Cobol. Wordy, non-clever, clunky...and a de-facto IT standard.
Interesting...well, if you're right, then it's good you're having fun and making money at the same time. More power to you.
Let me just say that I miss reading posts like yours on Slashdot. Well done, sir.
There is no big push back to Perl that I can see. I have not had a single client request it, and in fact I haven't heard of any large-scale new developments done in Perl in years. It's a legacy language, for all intents and purposes.
Why do you write language names in all caps? They aren't acronyms - ie it's "Ruby", not "RUBY", and "Java", not "JAVA". Just wondering.
In fact, sharing everything is generally unsuitable except in some cases - what you really want to do is share certain objects.
Threads on Linux (using NPTL) are actually a result of clone().
Agreed, that's what I heard too, but like you I couldn't find the reference.
My major problem with threading is simply that it breaks "encapsulation", if you generalise that term beyond object orientation. Threads have access to everything in the process space, even those objects that you'd rather not have them know about. That's why tuplespaces appeal to me: put those objects that are supposed to be synchronised somewhere special for processes to access, and don't bother worrying about everything else.
Apache2 uses processes or threads, and I believe processes are still the default (not sure though, I'm sure somebody will correct me).
There are some gotchas when using Apache threads - read here: http://httpd.apache.org/docs/2.0/developer/thread_safety.html
Well, I recall Unix threads as being difficult and divergent depending on OS. I wrote threaded code on AIX, HPUX, and Solaris. I recall compilation difficulties on AIX (different version of cc required, if I recall) and on Solaris it was just plain difficult, using a library called thr_thread (I think). Trying to write cross-platform threaded code was a pain vs. just using fork().
I later used pthreads, of course, and that was much easier, but multiprocesses always seemed to be "the way things were done" - all the server software forked to service requests or whatever, rather than used threads.
On Linux, Linus's anti-thread stance was a reflection of prevailing Unix attitudes. Threading has always seemed like the red-headed stepchild of Unix multiprocessing.
Meanwhile, threads were in NT from day one, for better or for worse.
http://en.wikipedia.org/wiki/Tuplespace
Threads only seemed to get really popular with Windows. Unix programming has typically always been multi-process with some form of shared memory. I've heard (and this is unconfirmed hearsay) that CreateProcess() on Windows is so heavyweight that they pushed for a comprehensive threading model instead.
These concerns (size, density, etc.) are addressed in the report, and in summary, there's more to it than that. Canada is way less dense and way bigger and has significantly better coverage, thanks in part to more enlightened policymakers.
The suit is nuclear-powered. Lots of people here have never read the comic, it seems! For shame!
They are also perfect for busy programmers like me who deploy to Unix/Linux and who are sick to death of the endless clusterfuck nightmare that is desktop Linux. Of course, desktop Linux is perfect for casual, non-professional hobbyist types, or people who place no value on their time.
Apple did not take BSD and "slap a bubbly gui on top of it". You should consider learning something about software one day.
And I'm sure you meant Turkey.
Fair enough, but I was responding to the original poster's numbers, which seemed to refer specifically to installs.
Actually, it's only around 825 000 installs (55 000 labs * 15 "access points" per lab) serving several tens of millions of students. It's still a lot, but not as huge as one install per student.