Brazil is all talk with the Free Software, with the Lula government and what not, their big bruhaha forums, their highfalutin' Minister of Culture Gilberto Gil and speeches about "empowerement and technology transfer", but no action. No action, that is, except the government hiring consulting firms full of sysadmins that are making big bucks installing FOSS.*
The Brazilian government AFAIK is spending zilch, nada, on developing the code base that will save them millions. It's an exploitative mentality: you use, deploy widely, but don't give anything back. Except to the consulting $ysadmin$.**
I would like to see the Brazilian government spend money on the development of software they'll use. This would be money well spent. It's the sort of investment that actually saves money, becauses it creates better products and tools, and eases installation, deployment, and integration. FOSS depends on having a solid code base. If you're going to use that code base, you might as well pay something for it.*** This goes for individuals and governments, in particular governments who like to shout out loud their support for Free Software. The Japanese government is an example for all to follow.
---
* Many of those guys are, strangely, acquaintances of the individuals on the government. If there's a scam, I don't know, but it sure smells funny. I should know, I know some of them.
** In fact, I'm lying a bit here: there's a small bunch of government employees developing some stuff. But they're too slow, small in numbers and lacking in expertise. And also, there are small research grants. All this sums up to almost nothing. How many times have you read about a big project the Brazilian government funded on FOSS (except the usual replacement of Windows desktops?) For instance, there is a huge opportunity for KDE and GNOME usability studies, a huge oppportunity for office integration via OO.org. Where are they? Not to be found...
*** How much money have _you_ donated to a FOSS entity like GNU or OpenBSD this year, even though _you_ use their software on a daily basis?
It has become a common modus operandi for companies to force-feed binary drivers to open source projects. The Linux kernel is a shameful example of this. FreeBSD followed after.
Linus says it's ok, smug user's don't care, 'cause their nvidia cards works, and developers are cool with Java, because it "runs everywhere", except where it doesn't.
OpenBSD remains true to its origins: quality and freedom.
There should be some community global effor/site to watch patent offices around the world. This was local FLOSS communities could at least put up a fight. Better yet, a global fund.
Yeah, okay. Apple says. Monkey does? Wait. I *buy* hardware (x86), then I *buy* software (Mac OS). And then *Apple* tells me what I can do with them? If I'm not violating copyright, I don't see how they can even hope to enforce something like that. It goes against property rights.
[GNOME is] (...) very usability-test centric (...)
AFAIK, there's only one formally conducted usability-test , a small one at that, made a long time ago, with 12 people. And it was conducted by Sun, not by any Free Software organization.
People like to give often the be-thankful-shut-up-and-code-and-submit-patches standard answer, but I would like to know if not even reviewing 19% of patches as evidenced here is "acceptable" (i.e., widely practised) or is there a problem?
How do other FLOSS projects stack-up against each other on this measurement?
He's from Australia, and IIRC reverse-engineering laws are different there. I'm not so sure Apple can sue. But, hey, maybe he shouldn't fly to the States, where - hmm - Freedom Abounds (copyright by George Walker Bush) - remember Dimitri?.
Furthermore, he's made it very clear that Apple used a lot of things that had been published before. I don't know much about the Australian law, though, pointers are appreciated.
YMMV.
FYI, you're a bit outdated on the Lisp side of things. The most widely used package for regex - CL-PPCRE (portable Perl-compatible regular expressions for Common Lisp) - is faster than Perl.
There are now great frameworks for integrating HTML and code, all much simpler than PHP. Some support continuations, which is a hot topic.
Lisp, Scheme and Haskell are not just "for play."
Although you intented to flamebait, the joke invites the consideration that some languages make it harder to write clear specifications and some make it easier.
In Perl's case specifically, the language lends itself to quick scripting and shorthand. This is great for little tasks, but as everyone knows, it doesn't scale well. This isn't Perl's or Larry Wall's fault. It was designed to/also/ allow for "quick and dirty" style which is ideal for little tasks. If you maintain that style for larger programs, it is exclusively the fault of your lack of talent, methodology and wits as a programmer.
However, I would like to point out that some languages actually enforce a clean specification. In particular, the functional languages almost literally *force* you to it. I am thinking here of the likes of SML, Haskell, OCaml, Clean, etc. This is not the place to discuss the fact that they also have a sane type system, where others have a broken one (e.g., C - see: http://perl.plover.com/yak/typing/). Language advocacy sucks, anyway ( http://www.perl.com/pub/a/2000/12/advocacy.html).
There's this story a guy posted once on comp.lang.functional about how once he wrote a Haskell program, handed it to the manager and he said: "great, you wrote a specification, now write the program." (!) The manager actually though what was executable Haskell code was just a "spec." Haskell fully suppports Knuth's literate programming approach.
If you ever tried writing something in those languages you know how they force you to write clean code. It is simply the easier way to break code in small functions. "Factoring", I believe it's called.
My point is that I feel the OSS community could greatly benefit from non-mainstream languages. These languages have seen nearly 2 decades of intense research. Arguments pertaining to performance just don't hold anymore vis-a-vis other mainstream languages like C#, Java, Python, Perl, etc. Clean has a video-game library to prove the point (http://www.cs.ru.nl/~clean/). OCaml, SML and Clean approach C performance (Ocaml coming second to C in some "language shootouts" for most benchmarks, for all its worth). Also, some of these have been used in large "real world" problems. OCaml has been deployed in the C code verification for correctness of the flight control software for the Airbus 340 airplane, for instance (http://www.astree.ens.fr/). It is widely known that Ericsson uses Erlang for their telephony switches (www.erlang.org). The CIL - Infrastructure for C Program Analysis and Transformation is written in OCaml and if more widely known, could prevent the weekly flow of buffer overflows developed in Berkeley and can be used *right now* in large OSS projects (http://manju.cs.berkeley.edu/cil/). They've tested it in the Linux kernel, for example (whether they sent patches or not, I don't know).
Of course, you have to have an open mind, and be willing to learn and throw some old tricks out and work using a different approach/mindset. Learning things thoroughly is always hard work, but the OSS shouldn't dismiss functional languages as "academic" - and for that matter, other serious approaches, like Squeak Smalltalk, for instance.
My 2 cents.
PS: I'm no expert at programming, just a beginner, but I offer my opinion here because I feel some people just haven't been introduced to some facts and haven't heard of some stuff. Not everyone has a big company to promote their language.
I would agree with you guys. I believe this is a flaw in the Debian engineering cycle: nobody uses testing. martinde is right when he says *this* is the time to be in "testing." But this would be the *only* right time. As it was said, it's pretty much pointless sticking with testing all year long, because you don't get the fixes upstream made that get into sid.
I believe this calls for a change in practice: have a bipolar cycle (sid/stable) and in the *final* weeks move for testing. Either that or drop testing altogether, and then have something like the BSDs practice.
Debian dosn't follow the common software engineering practice of setting deadlines for relase cycles. They claim this is because it relies on volunteers. But this is "no excuse", because OpenBSD and FreeBSD rely on volunteers. OpenBSD has always had 6 months release cycles and this is what Scott Long (From FreeBSD) has said recently: "By the middle of 2002 is was very apparent that we needed to start
focusing on getting 5.0 released. Unfortunately, we fell into the trap
of wanting to finish more features in order to feel good about 5.x. (...) New -STABLE branched will be made on a calendar-based time line (...) While as engineers we all tend to hate timelines, this does have a lot
of positive aspects. First, it increases the predictability of the
development both for our users and for our developers. Users can plan
effectively for upgrades and testing/validation knowing that there will
be major and minor releases at fixed times of the year. Developers can
judge when to start new projects and when to focus on bug-fixing because
there will no longer be the temptation to delay a release by a month in
order to slide 'one more thing' in. This is not unlike most commercial
OS vendors, and we've received a _LOT_ of feedback that this method of
planning is desperately needed. Link for the above here
These practices should be adopted in Debian too. If BSD development can do it, and it involves kernel developments, Debian can do it too (mostly userland hacks).
Here's what I do: on top of a stable Debian, I run a chrooted sid. Pronto! I get the best of both (ideally, I should be using testing instead of sid, since I'm not a Debian developer).
My point being that you get the best of both worlds. It is ridiculously easy to set up a chroot jail in Debian. "Google and ye shall find."
But isn't this due to a "cultural" problem? For instance, the fine OpenBSD guys have given us strncat and strncpy, and a patch has been applied to glibc in August 2000.
http://sources.redhat.com/ml/libc-alpha/2000-08/ ms g00052.html
GNU/Linux programmers have a bad track record on this issue. Not to mention safer languages. Consider the little attention a mainstream language like C# has gathered in the community (I won't even mention other languages that achieve C-like performance such as SML or Common Lisp). People use C for everything, not just systems programming. The result you get to read at CERT. And let's not even mention formal methods...
I guess it says something about M.I.T. and about the Lisp "family" (Common Lisp, Scheme and Islisp). By the way, nobody writes "LISP" anymore, and I guess it's been that way for more than a decade (or two, maybe).
I don't think anyone would dispute the M.I.T. is a great institution, capable of the most creative and excellent research. So, why is it they/require/ you to learn Scheme (Lisp), instead of any of the fashionable languages-du-jour? Maybe it's got something to do with the fact that you can bend Lisp a lot, and it doesn't break. Think about that.
My university went from Pascal, then to C, because Pascal was too old, then away from C, because it was too troublesome for first-timers and experimented with Java, because OOP was "the way forward." However, inexperienced students found OOP concepts kinda overwhelming and too hard to grasp (why go through all that just for procedural programming?). Then, they dropped Java and adopted...Pascal, because it allowed for the same set of skills then C, with a better type system and a cleaner syntax! Pascal! Oh, Pascal!
Personally, it has been a source of great distress. I wish we had been doing C. Better yet - and totally unrelated - I *really* wished for SML or Common Lisp - heck, I'd settle for Scheme, if we were to use SICP - had been the languages adopted, but they apparently seem to think that becoming knowledgeable in data structures with pointers is of the utmost importance. I do tend to agree, because of the amount of code that's out there. *However*, I wish universities would look toward the future, and not be stuck to the ways of the past.
I wonder if anyone knows if Gnome conducts usability studies on GUIs (meaning: collecting statistics on user's opinion on ease of use)? Apple and Microsoft do.
Objective usability studies are entirely different from gaining feedback from a community with a heavy bias - us here at/. It means we get to know if aunt Thelma likes Gnome.
Because if they *don't*, then that's really stupid. Open Source has the chance to experiment, instead of just copying what Apple or Microsoft do.
For instance, Gnome is being deployed on a massive scale on Extremadura (Spain). Are they even collecting opinions on that?
They have corporate money now, they should. Shouldn't they?
-"Sun, or some other group, needs to maintain control over the language to ensure what happened to HTML doesn't happen in Java (MS HTML)"
You are talking absolute nonsense! This has nothing to do with GPLing Java (or not). "Control over a language" is not necessary when you have a language specification. Various languages have one: Common Lisp, Eiffel, Scheme, ML, C, etc. Once you have a specification, people go and implement it. And there will be different, competing implementations, yes. That is a Good Thing.
For sure, for there to be a specification, there has to be set up a commitee, I believe it's a requirement by the overseers (ANSI, ISO, ECMA) of the specification process.
The fact that in the Open Source world we have all these scripting languages - Perl, Python, PHP, Ruby, what have you - that do not have a specification but are in continuous flux of implementation due to the continuous change of mind of their designers is probably what is confounding you.
My suggestion: learn a/real/ programming language. You will live a happier life.
But the point is valid: there has to be a specification, and not just an implementation.
I don't remember the issues revolving around the time Sun pulled back from going for a specification, but IIRC it might have had something to do with the fact that once you published a specification in a body like ISO, ANSI or ECMA, that naturally leads to implementations, and those you cannot control. Think C# and Mono.
I agree that Java has almost no future, it lost it's window of opportunity. C# and.NET will take over, IMHO. C# is a better language than Java (this seems to be a point generally agreed upon). C# builds on Java. C# has published a spec, Java hasn't. C# will be deployed on a monopolist platform, XAML will cause an earthquake. And we have C# on GNU/Linux.
In conclusion: by going through a specification process for C# and.NET, Microsoft has delivered Sun the killing blow...
But then again, except for the GUI research, Apple has never made a decente OS, has it?
Unix-loving is for people who never read or saw Alan Kay's "The Computer Revolution Hasn't Happened Yet", of for the uninformed who never saw or heard of a Lisp Machine.
Linux-loving is for people who think the current OS is *very* advanced when, in fact, the most advanced people in GNU/Linux are either: quitting the whole Linux kernel (The HURD) or implementing design choices that Microsoft has implemented in their OS (components, Mono). This is not to say that cool stuff hasn't been done, but the only thing I personally find interesting is Debian's intelligent package-management, which updates *all* your software packages. But then again, the crowd codes in C or C++, regretably...
If Unix is so good, would Bell Labs be researching Plan9 or a *BSD?
In a few words: we're all in a very bad situation, but only few people realize it.
Slashdot Mirror
"it doesn't not" mean
Substitute for the obvious "it doesn't mean."
Brazil is all talk with the Free Software, with the Lula government and what not, their big bruhaha forums, their highfalutin' Minister of Culture Gilberto Gil and speeches about "empowerement and technology transfer", but no action. No action, that is, except the government hiring consulting firms full of sysadmins that are making big bucks installing FOSS.*
The Brazilian government AFAIK is spending zilch, nada, on developing the code base that will save them millions. It's an exploitative mentality: you use, deploy widely, but don't give anything back. Except to the consulting $ysadmin$.**
I would like to see the Brazilian government spend money on the development of software they'll use. This would be money well spent. It's the sort of investment that actually saves money, becauses it creates better products and tools, and eases installation, deployment, and integration. FOSS depends on having a solid code base. If you're going to use that code base, you might as well pay something for it.*** This goes for individuals and governments, in particular governments who like to shout out loud their support for Free Software. The Japanese government is an example for all to follow.
---
* Many of those guys are, strangely, acquaintances of the individuals on the government. If there's a scam, I don't know, but it sure smells funny. I should know, I know some of them.
** In fact, I'm lying a bit here: there's a small bunch of government employees developing some stuff. But they're too slow, small in numbers and lacking in expertise. And also, there are small research grants. All this sums up to almost nothing. How many times have you read about a big project the Brazilian government funded on FOSS (except the usual replacement of Windows desktops?) For instance, there is a huge opportunity for KDE and GNOME usability studies, a huge oppportunity for office integration via OO.org. Where are they? Not to be found...
*** How much money have _you_ donated to a FOSS entity like GNU or OpenBSD this year, even though _you_ use their software on a daily basis?
It has become a common modus operandi for companies to force-feed binary drivers to open source projects. The Linux kernel is a shameful example of this. FreeBSD followed after.
Linus says it's ok, smug user's don't care, 'cause their nvidia cards works, and developers are cool with Java, because it "runs everywhere", except where it doesn't.
OpenBSD remains true to its origins: quality and freedom.
There should be some community global effor/site to watch patent offices around the world. This was local FLOSS communities could at least put up a fight.
Better yet, a global fund.
Yeah, okay. Apple says. Monkey does?
Wait. I *buy* hardware (x86), then I *buy* software (Mac OS). And then *Apple* tells me what I can do with them? If I'm not violating copyright, I don't see how they can even hope to enforce something like that. It goes against property rights.
This case illustrates that reverse engineering can be a legitimate and even necessary thing to do.
[GNOME is] (...) very usability-test centric (...)
AFAIK, there's only one formally conducted usability-test , a small one at that, made a long time ago, with 12 people. And it was conducted by Sun, not by any Free Software organization.
Hi --
People like to give often the be-thankful-shut-up-and-code-and-submit-patches standard answer, but I would like to know if not even reviewing 19% of patches as evidenced here is "acceptable" (i.e., widely practised) or is there a problem?
How do other FLOSS projects stack-up against each other on this measurement?
He's from Australia, and IIRC reverse-engineering laws are different there. I'm not so sure Apple can sue. But, hey, maybe he shouldn't fly to the States, where - hmm - Freedom Abounds (copyright by George Walker Bush) - remember Dimitri?.
Furthermore, he's made it very clear that Apple used a lot of things that had been published before.
I don't know much about the Australian law, though, pointers are appreciated.
YMMV.
FYI, you're a bit outdated on the Lisp side of things. The most widely used package for regex - CL-PPCRE (portable Perl-compatible regular expressions for Common Lisp) - is faster than Perl.
There are now great frameworks for integrating HTML and code, all much simpler than PHP. Some support continuations, which is a hot topic.
Lisp, Scheme and Haskell are not just "for play."
Although you intented to flamebait, the joke invites the consideration that some languages make it harder to write clear specifications and some make it easier. /also/ allow for "quick and dirty" style which is ideal for little tasks. If you maintain that style for larger programs, it is exclusively the fault of your lack of talent, methodology and wits as a programmer.
In Perl's case specifically, the language lends itself to quick scripting and shorthand. This is great for little tasks, but as everyone knows, it doesn't scale well. This isn't Perl's or Larry Wall's fault. It was designed to
However, I would like to point out that some languages actually enforce a clean specification. In particular, the functional languages almost literally *force* you to it. I am thinking here of the likes of SML, Haskell, OCaml, Clean, etc. This is not the place to discuss the fact that they also have a sane type system, where others have a broken one (e.g., C - see: http://perl.plover.com/yak/typing/). Language advocacy sucks, anyway ( http://www.perl.com/pub/a/2000/12/advocacy.html).
There's this story a guy posted once on comp.lang.functional about how once he wrote a Haskell program, handed it to the manager and he said: "great, you wrote a specification, now write the program." (!) The manager actually though what was executable Haskell code was just a "spec." Haskell fully suppports Knuth's literate programming approach.
If you ever tried writing something in those languages you know how they force you to write clean code. It is simply the easier way to break code in small functions. "Factoring", I believe it's called.
My point is that I feel the OSS community could greatly benefit from non-mainstream languages. These languages have seen nearly 2 decades of intense research. Arguments pertaining to performance just don't hold anymore vis-a-vis other mainstream languages like C#, Java, Python, Perl, etc. Clean has a video-game library to prove the point (http://www.cs.ru.nl/~clean/). OCaml, SML and Clean approach C performance (Ocaml coming second to C in some "language shootouts" for most benchmarks, for all its worth). Also, some of these have been used in large "real world" problems. OCaml has been deployed in the C code verification for correctness of the flight control software for the Airbus 340 airplane, for instance (http://www.astree.ens.fr/). It is widely known that Ericsson uses Erlang for their telephony switches (www.erlang.org). The CIL - Infrastructure for C Program Analysis and Transformation is written in OCaml and if more widely known, could prevent the weekly flow of buffer overflows developed in Berkeley and can be used *right now* in large OSS projects (http://manju.cs.berkeley.edu/cil/). They've tested it in the Linux kernel, for example (whether they sent patches or not, I don't know).
Of course, you have to have an open mind, and be willing to learn and throw some old tricks out and work using a different approach/mindset. Learning things thoroughly is always hard work, but the OSS shouldn't dismiss functional languages as "academic" - and for that matter, other serious approaches, like Squeak Smalltalk, for instance.
My 2 cents.
PS: I'm no expert at programming, just a beginner, but I offer my opinion here because I feel some people just haven't been introduced to some facts and haven't heard of some stuff. Not everyone has a big company to promote their language.
He uses a laptop.
I would agree with you guys. I believe this is a flaw in the Debian engineering cycle: nobody uses testing. martinde is right when he says *this* is the time to be in "testing." But this would be the *only* right time. As it was said, it's pretty much pointless sticking with testing all year long, because you don't get the fixes upstream made that get into sid.
I believe this calls for a change in practice: have a bipolar cycle (sid/stable) and in the *final* weeks move for testing. Either that or drop testing altogether, and then have something like the BSDs practice.
Debian dosn't follow the common software engineering practice of setting deadlines for relase cycles. They claim this is because it relies on volunteers. But this is "no excuse", because OpenBSD and FreeBSD rely on volunteers. OpenBSD has always had 6 months release cycles and this is what Scott Long (From FreeBSD) has said recently:
"By the middle of 2002 is was very apparent that we needed to start focusing on getting 5.0 released. Unfortunately, we fell into the trap of wanting to finish more features in order to feel good about 5.x. (...) New -STABLE branched will be made on a calendar-based time line (...) While as engineers we all tend to hate timelines, this does have a lot of positive aspects. First, it increases the predictability of the development both for our users and for our developers. Users can plan effectively for upgrades and testing/validation knowing that there will be major and minor releases at fixed times of the year. Developers can judge when to start new projects and when to focus on bug-fixing because there will no longer be the temptation to delay a release by a month in order to slide 'one more thing' in. This is not unlike most commercial OS vendors, and we've received a _LOT_ of feedback that this method of planning is desperately needed.
Link for the above here
These practices should be adopted in Debian too. If BSD development can do it, and it involves kernel developments, Debian can do it too (mostly userland hacks).
As soon as security update support is up and running for testing (...)
I didn't know they were planning this...Must of missed some Debian news. Any pointers?
Here's what I do: on top of a stable Debian, I run a chrooted sid. Pronto! I get the best of both (ideally, I should be using testing instead of sid, since I'm not a Debian developer).
My point being that you get the best of both worlds. It is ridiculously easy to set up a chroot jail in Debian. "Google and ye shall find."
But isn't this due to a "cultural" problem? For instance, the fine OpenBSD guys have given us strncat and strncpy, and a patch has been applied to glibc in August 2000.
/ ms g00052.html
http://sources.redhat.com/ml/libc-alpha/2000-08
GNU/Linux programmers have a bad track record on this issue. Not to mention safer languages. Consider the little attention a mainstream language like C# has gathered in the community (I won't even mention other languages that achieve C-like performance such as SML or Common Lisp). People use C for everything, not just systems programming. The result you get to read at CERT. And let's not even mention formal methods...
I guess it says something about M.I.T. and about the Lisp "family" (Common Lisp, Scheme and Islisp). By the way, nobody writes "LISP" anymore, and I guess it's been that way for more than a decade (or two, maybe).
/require/ you to learn Scheme (Lisp), instead of any of the fashionable languages-du-jour? Maybe it's got something to do with the fact that you can bend Lisp a lot, and it doesn't break.
I don't think anyone would dispute the M.I.T. is a great institution, capable of the most creative and excellent research. So, why is it they
Think about that.
My university went from Pascal, then to C, because Pascal was too old, then away from C, because it was too troublesome for first-timers and experimented with Java, because OOP was "the way forward." However, inexperienced students found OOP concepts kinda overwhelming and too hard to grasp (why go through all that just for procedural programming?). Then, they dropped Java and adopted...Pascal, because it allowed for the same set of skills then C, with a better type system and a cleaner syntax! Pascal! Oh, Pascal!
Personally, it has been a source of great distress. I wish we had been doing C. Better yet - and totally unrelated - I *really* wished for SML or Common Lisp - heck, I'd settle for Scheme, if we were to use SICP - had been the languages adopted, but they apparently seem to think that becoming knowledgeable in data structures with pointers is of the utmost importance. I do tend to agree, because of the amount of code that's out there. *However*, I wish universities would look toward the future, and not be stuck to the ways of the past.
You're right, all I saw was *one* usability study, with *12* users in 2001! That can hardly be taken as a serious approach to usability, can it?
Hi --
/. It means we get to know if aunt Thelma likes Gnome.
I wonder if anyone knows if Gnome conducts usability studies on GUIs (meaning: collecting statistics on user's opinion on ease of use)? Apple and Microsoft do.
Objective usability studies are entirely different from gaining feedback from a community with a heavy bias - us here at
Because if they *don't*, then that's really stupid. Open Source has the chance to experiment, instead of just copying what Apple or Microsoft do.
For instance, Gnome is being deployed on a massive scale on Extremadura (Spain). Are they even collecting opinions on that?
They have corporate money now, they should. Shouldn't they?
-"Sun, or some other group, needs to maintain control over the language to ensure what happened to HTML doesn't happen in Java (MS HTML)"
/real/ programming language. You will live a happier life.
You are talking absolute nonsense! This has nothing to do with GPLing Java (or not). "Control over a language" is not necessary when you have a language specification. Various languages have one: Common Lisp, Eiffel, Scheme, ML, C, etc. Once you have a specification, people go and implement it. And there will be different, competing implementations, yes. That is a Good Thing.
For sure, for there to be a specification, there has to be set up a commitee, I believe it's a requirement by the overseers (ANSI, ISO, ECMA) of the specification process.
The fact that in the Open Source world we have all these scripting languages - Perl, Python, PHP, Ruby, what have you - that do not have a specification but are in continuous flux of implementation due to the continuous change of mind of their designers is probably what is confounding you.
My suggestion: learn a
But the point is valid: there has to be a specification, and not just an implementation. I don't remember the issues revolving around the time Sun pulled back from going for a specification, but IIRC it might have had something to do with the fact that once you published a specification in a body like ISO, ANSI or ECMA, that naturally leads to implementations, and those you cannot control. Think C# and Mono. I agree that Java has almost no future, it lost it's window of opportunity. C# and .NET will take over, IMHO. C# is a better language than Java (this seems to be a point generally agreed upon). C# builds on Java. C# has published a spec, Java hasn't. C# will be deployed on a monopolist platform, XAML will cause an earthquake. And we have C# on GNU/Linux.
In conclusion: by going through a specification process for C# and .NET, Microsoft has delivered Sun the killing blow...
But then again, except for the GUI research, Apple has never made a decente OS, has it?
Unix-loving is for people who never read or saw Alan Kay's "The Computer Revolution Hasn't Happened Yet", of for the uninformed who never saw or heard of a Lisp Machine.
Linux-loving is for people who think the current OS is *very* advanced when, in fact, the most advanced people in GNU/Linux are either: quitting the whole Linux kernel (The HURD) or implementing design choices that Microsoft has implemented in their OS (components, Mono). This is not to say that cool stuff hasn't been done, but the only thing I personally find interesting is Debian's intelligent package-management, which updates *all* your software packages. But then again, the crowd codes in C or C++, regretably...
If Unix is so good, would Bell Labs be researching Plan9 or a *BSD?
In a few words: we're all in a very bad situation, but only few people realize it.