You do realize that the JVM specifications are published and that, in fact, the OSS community has been incompetent in the sense that no one group has really come together to implement a fully compliant virtual machine (including security aspects) ?
It's very easy to point your fingers at Sun and blame them for the failure of the OSS community.
You're absolutely right. It is a cheap shot, and we ought to be reading more into this RedHat notice to find out what it is really about. Probably has to do with GCJ. RedHat has been competing with Novell for enterprise-grade dominance. Novell chose Mono and C#, so RedHat went with GCJ, at a time Sun was clearly hindering distribution on Linuxes (still does on BSDs - with the exception of FreeBSD now). Now RedHat is probably pissed off that it won't be able to push their per-seat licenses + GCJ as a solution for enterprise grade Java platforms, since Sun has made life easier for Linux distros. All along, this has been a Sun vs. RedHat thing. (IMHO, Sun really is too slow...Look at OpenSolaris...They really don't give it as much attention as they ought to.)
The author entirely missed the most basic facts: the hings he wanted to work well with Linux didn't work, not because open source programmers are a bunch of incompetent jerks, but simply because they're working with proprietary systems done by vendors that don't "play nice" with others sice they don't release specifications for they products. Which means open-source programmers have to reverse-engineer. Blame Apple and Microsoft for incompatibilites, not open source programmers! This, I believe, has to do with something that Stallman calls attention to: it's about the values.
I'm gonna have to say "me too." Funny how I never hear people say the opposite: "Gee, I couldn't get anything done with KDE, so I switched to GNOME." Buy, you know what? GNOME will win, even though they're usability-challenged. It has a nicer license. People will never develop business/desktop integration software on a GPLed toolkit. Not all of KDE is GPLed, however. Look how consfusing it is: http://developer.kde.org/documentation/licensing/l icensing.html
In the end, it's going to boil down to FreeBSD having the same softwares and ease of installation as Linux (already 15000 ports), plus having up-to-date software from the ports tree and/or PBI installs, while Linux distros will carry on with their packaging frenzy, (apt, yapp, rpm, whatever) always behind the curve, like Debian, or Slackware, or always "experimental", "cutting edge" unreliable distros, such as Fedora. Never up-to-date and stable, like FreeBSD.
Yeah, modded "insightful" by GPL fanboys. Look, factually speaking, you're wrong. Apple has contributed code to FreeBSD.
Read this: Since Mac OS X v10.0 was released in 2001, Apple has been filtering BSD code in and out of their kernel, userland, and libraries. This code then makes its way back to FreeBSD.(...) By the time Apple released Panther, their contributions back into FreeBSD had amassed into a new FreeBSD milestone, the 5.x branch. http://osviews.com/modules.php?op=modload&name=New s&file=article&sid=938&mode=&order=&thold=
OpenBSM is derived from the BSM audit implementation found in Apple's open source Darwin operating system, which upon request, Apple relicensed under a BSD licence (wikipedia citation) OpenBSM: Open Source Basic Security Module (BSM) Audit Implementation http://www.trustedbsd.org/openbsm.html
Basically, what you said boils down to: HP/IBM/Novell support Linux. Ok, that's a fact. But I've been listening to this "Linux is going to rule the desktop" crap for, what 3 or 4 years now, and I still haven't seen that many ISVs provide software solutions around said desktop. Now, anybody's who's got so much as an inkling of how desktop integration works on the corporate environment, with its nearly one billion ISVs provinding hooks to every little bit of functionality you can extract from building apps around Microsoft's softwares, is bound to agree with me that anything around the GPL doesn't make any business sense. Sure, they might work with LGPLed GNOME, but at some point, you will have to delve into kerneland. And it doesn't really seem promising if you're a small ISV selling business solutions around, say, OpenOffice.org (workflow software, or e-paper solutions) if you'll have to face huge IT departments from big corporations with a license that forces you to disclose your work. There's lots to be done in business integration, but FOSS desktops are nowhere close to providing the stack of solution available in M$ land. The ammount of FOSS developers isn't that big, and a lot of them are either writing web servers, desktops and window managers, or doing systems programming. Either FOSS gets ISVs on their sides, or we can have these/. discussions ad eternum and nothing will substantially change. M$ has had 90% market share for long years now, and they keep getting better. Heck, Microsoft research has the best minds of Comp Sci working there. Let's not forget that IBM/HP/Sun sell hardware, and that Novell, SuSE and RedHat really have proprietary solutions while promoting themselves as Free Software paladins (there isn't really a SuSE "community", is there?). I mean, all these "free softwares" examples are somewhat of a sick joke. I remember when there was such a thing as United Linux. You could get the source. It was like this ftp with the source and no documentation of instructions on how to even compile the friggin' thing. Does RedHat have a community? Yeah, Fedora, a bunch of people working for free testing RedHat. CentOS - RedHat told it to remove any mention of its name. Real fair play.
So basically, what you're saying is that last time you cared to check the Java status of the FreeBSD project, it was 2001. And then you woke up one day in May 2006, got on Slashdot, and started dissing FreeBSD because you're too negligent to even care to keep up-to-date with the FreeBSD news? How very intelligent.
You're the retard who chooses to make your won life difficult by making uninformed decisions that go against the project developers' official recommendation, then hop on/. to diss FreeBSD because of your moronic ways. RTFM, stupid.
I think *BSDs have the clear advantage that ISVs can develop for those OSs and still maintain their business. Their code does not need to be released, as in the case of GPL contamination.
To think little shops can go against huge IT departments is a joke. The joke is on GPL developers. All "successfully" GPL-licensed software has huge corporate backing. Why: Because hardware vendors are neck deep in Linux. However, they have little third-party software written for them.
The GPL has failed in the applications arena, where licenses are largely business-friendly (MIT, Apache, LGPL, etc.). What usually happens is that so-called Freedom Lovers GPL developers dual-license their code. And you have to be really dumb to contribute to a project which asks of you to sign an agreement ceding copyright to people who will dual-license your code, and then make money selling proprietary licenses.
The argument of "taking" or "stealing" code is so absurd. It's immaterial, you can't "take it away". It won't exhaust you.
From what I've read, I think that might be because some developers on the Linux camp have been a factor of irritation when they produce Linuxisms is C code, foresaking portability.You see this phenomenom mentioned in what regards GNOME in the article. It almost sounds as if GNOME developers are a clique that don't give a shit about other projects.
Another famous little war was Linuxers resistance (glibc maintainers, to be exact) resistance against the safer strlcpy and strlcat functions from OpenBSD's libc: See these amazing threads that illustrate prejudice against the OpenBSD developers. After 2 or smth years, they finally gave in and the OpenBSD functions are part of glibc. But here's my sample:
Here's the amazing answer from the glibc's maintainer Ulrich Drepper, a real insight into strong software engineering principles. No wonder Linux boxes got so rootkitted: This is horribly inefficient BSD crap. Using these function only leads to other errors. Correct string handling means that you always know how long your strings are and therefore you can you memcpy (instead of strcpy).http://sources.redhat.com/ml/libc-alpha/2002-01/ms g00002.html
Theo's take: TdR: They're still not in glibc. They're everywhere else. They're in Solaris. We invented them two years ago. They're showing up in vendor operating systems. We made a convincing argument why these things are necessary. http://www.ddj.com/184404914
Look at CERT's list for "glibc" vulnerabilites here. Please draw comparisons with BSDs. Answer honestly: who's got bragging rights?
Ever try to get native Java working on FreeBSD? First you have to download the Linux Java distribution, install it, then download the FBSD patchset for native Java, build and install it. This takes a day, even on my 2.4GHz, 768MB laptop.
For fsck's sake, it really seems this/. thread on FreeBSD is full of trolls! Didn't you read the news, the FreeBSD Foundation negotiated with Sun and now there's a native Java on FreeBSD so stop trolling, because installing it is as easy on any, e.g. Debian-like system (simply #pkg_add diablo-jdk-freebsd6-1.5.0.06.00.tbz)
under freebsd it's impossible to configure the sound card withouth rebuilding a kernel?
Have you read the FreeBSD handbook? What you say seems totally strange to me, and I'm a new FreeBSD user (ex-Debian, pfff...) You just load the kernel module (or the generic one).
You can also google for Theo de Raddt's last interview in which he comments how he doesn't like gcc but uses it for the lack of better free alternative.
I'm sorry, what's so great about GNU userland and Debian's ever-so-late release schedules? Besides, you want GNU userland stuff (Bash, etc.) you just install them. Such a thing would be for masochists.
IMHO, when you choose a free software project you must also evaluate how the project is set up. Any moderately important open source project is bound to be a big project. As such, it'll involve software engineering practices, team management, documentation, and other stuff like security policy, release management, buid processes, server farms, etc, all stuff that will reflect on quality of the code base. You must ask yourself: is this a project that will last? Will it scale? Will it be able to produce quality, reliable software in a predictable manner?
Some projects are better engineered as a project than others. Some do stuff better than others. Some work in a "democratic" fashion, others in an "autocratic" fashion. But how the project works as a whole is very important. This may determine, amongst other things whether a project will scale or not.
Let me give you some concrete examples. Autocratic projects are things such as the Linux kernel and the most famous theocracy, Theo's OpenBSD. Such projects may scale or not. These two, apparently do, but you may see problems in the way they're managed, because of the "dictator" aspect. For instance, they may get something wrong. You can't be right all of the time.
Other projects are a complete mess in terms of human resource management. The showcase example is Debian, which doesn't seem to be an organization that scales up very well and seem to be in a pattern of falling short everytime. This, I believe, has to do with a mix of technologies chosen (apt- being just a layer of complexity added to what Makefiles already do - as any BSD port collection proves), and the design of their organization (you know, how all their so-called "developers" get to scream at the mailing lists over trivia all the time). Another example of a project that possibly will not scale is OpenBSD. Already they had financial problems, they're not set up as a Foundation, so they won't be able to do things that an organization like FreeBSD Foundation, Debian or the FSF can achieve in terms of negotiations and legal actions (for instance, OpenBSD will probably never have a Sun certified Java, because Sun can't negotiate with an OpenBSD legal entity). The FreeBSD project, because of the Foundation is able to strike deals with software firms such as Coverity (for source code analysis), which already has produced results in terms of bug-hunting. Other projects will most likely never be able to provide the best tools for their developers.
An yet other projects may have great ideas, but have no clear cut roles and aren't really clear on how they go about their ideas. One that comes to mind is GoboLinux, which sort of threw away the Unix File System hierarchy and borrowed some (innovative) ideas from projects such as NeXT. It's not clear what the roadmap or the security policy is for this project. In fact, I don't think they have a security policy. So that leaves you with a great idea, and a lot of questions. And this from competent hackers. Many free software projects don't even get there. Again, this is just an example. Another example that comes to mind is NexentaOS, which aims to be a GNU/OpenSolaris project. Sounds great, but do they have a plan (besides being able to compile the software)?
And finally, on technical merits alone, I think all BSDs stand to the test. However, when you factor in all those things I mentioned, I believe FreeBSD is set up to be the great project that it is, and will continue to be in the future. So, for me, it's:
techical merits + organizational skills = great open source project
PS: I don't mean to bash projects. I seriously hope they come around their shortcomings.
Slashdot Mirror
And if you're wrong about Microsoft and the GPL, you don't have an argument.
You got him there! You can't sustain an argument when you ignore half of the truth table.
You do realize that the JVM specifications are published and that, in fact, the OSS community has been incompetent in the sense that no one group has really come together to implement a fully compliant virtual machine (including security aspects) ?
It's very easy to point your fingers at Sun and blame them for the failure of the OSS community.
This non-free Debian thing is very much someone sucking your **** and then you saying that you did not have sex with that person.
You're absolutely right. It is a cheap shot, and we ought to be reading more into this RedHat notice to find out what it is really about.
Probably has to do with GCJ. RedHat has been competing with Novell for enterprise-grade dominance. Novell chose Mono and C#, so RedHat went with GCJ, at a time Sun was clearly hindering distribution on Linuxes (still does on BSDs - with the exception of FreeBSD now).
Now RedHat is probably pissed off that it won't be able to push their per-seat licenses + GCJ as a solution for enterprise grade Java platforms, since Sun has made life easier for Linux distros. All along, this has been a Sun vs. RedHat thing.
(IMHO, Sun really is too slow...Look at OpenSolaris...They really don't give it as much attention as they ought to.)
Since when BSD-licensed software is not free software? You really gotta go read those FSF pages once again...
The author entirely missed the most basic facts: the hings he wanted to work well with Linux didn't work, not because open source programmers are a bunch of incompetent jerks, but simply because they're working with proprietary systems done by vendors that don't "play nice" with others sice they don't release specifications for they products. Which means open-source programmers have to reverse-engineer.
Blame Apple and Microsoft for incompatibilites, not open source programmers!
This, I believe, has to do with something that Stallman calls attention to: it's about the values.
I'm gonna have to say "me too."l icensing.html
Funny how I never hear people say the opposite: "Gee, I couldn't get anything done with KDE, so I switched to GNOME."
Buy, you know what? GNOME will win, even though they're usability-challenged. It has a nicer license. People will never develop business/desktop integration software on a GPLed toolkit. Not all of KDE is GPLed, however. Look how consfusing it is: http://developer.kde.org/documentation/licensing/
Where did KDE go wrong? Qt.
However, in the real world, there is less time for such things, and my interest in FreeBSD has waned somewhat.
Yes, yes. Stop playing now.
It does seem to provide some indication.
In the end, it's going to boil down to FreeBSD having the same softwares and ease of installation as Linux (already 15000 ports), plus having up-to-date software from the ports tree and/or PBI installs, while Linux distros will carry on with their packaging frenzy, (apt, yapp, rpm, whatever) always behind the curve, like Debian, or Slackware, or always "experimental", "cutting edge" unreliable distros, such as Fedora.
Never up-to-date and stable, like FreeBSD.
Yeah, modded "insightful" by GPL fanboys. Look, factually speaking, you're wrong. Apple has contributed code to FreeBSD.
w s&file=article&sid=938&mode=&order=&thold=
Read this:
Since Mac OS X v10.0 was released in 2001, Apple has been filtering BSD code in and out of their kernel, userland, and libraries. This code then makes its way back to FreeBSD.(...) By the time Apple released Panther, their contributions back into FreeBSD had amassed into a new FreeBSD milestone, the 5.x branch. http://osviews.com/modules.php?op=modload&name=Ne
OpenBSM is derived from the BSM audit implementation found in Apple's open source Darwin operating system, which upon request, Apple relicensed under a BSD licence (wikipedia citation) OpenBSM: Open Source Basic Security Module (BSM) Audit Implementation http://www.trustedbsd.org/openbsm.html
Basically, what you said boils down to: HP/IBM/Novell support Linux. /. discussions ad eternum and nothing will substantially change. M$ has had 90% market share for long years now, and they keep getting better. Heck, Microsoft research has the best minds of Comp Sci working there.
Ok, that's a fact. But I've been listening to this "Linux is going to rule the desktop" crap for, what 3 or 4 years now, and I still haven't seen that many ISVs provide software solutions around said desktop.
Now, anybody's who's got so much as an inkling of how desktop integration works on the corporate environment, with its nearly one billion ISVs provinding hooks to every little bit of functionality you can extract from building apps around Microsoft's softwares, is bound to agree with me that anything around the GPL doesn't make any business sense. Sure, they might work with LGPLed GNOME, but at some point, you will have to delve into kerneland. And it doesn't really seem promising if you're a small ISV selling business solutions around, say, OpenOffice.org (workflow software, or e-paper solutions) if you'll have to face huge IT departments from big corporations with a license that forces you to disclose your work.
There's lots to be done in business integration, but FOSS desktops are nowhere close to providing the stack of solution available in M$ land. The ammount of FOSS developers isn't that big, and a lot of them are either writing web servers, desktops and window managers, or doing systems programming. Either FOSS gets ISVs on their sides, or we can have these
Let's not forget that IBM/HP/Sun sell hardware, and that Novell, SuSE and RedHat really have proprietary solutions while promoting themselves as Free Software paladins (there isn't really a SuSE "community", is there?). I mean, all these "free softwares" examples are somewhat of a sick joke. I remember when there was such a thing as United Linux. You could get the source. It was like this ftp with the source and no documentation of instructions on how to even compile the friggin' thing. Does RedHat have a community? Yeah, Fedora, a bunch of people working for free testing RedHat. CentOS - RedHat told it to remove any mention of its name. Real fair play.
So basically, what you're saying is that last time you cared to check the Java status of the FreeBSD project, it was 2001. And then you woke up one day in May 2006, got on Slashdot, and started dissing FreeBSD because you're too negligent to even care to keep up-to-date with the FreeBSD news? How very intelligent.
You're the retard who chooses to make your won life difficult by making uninformed decisions that go against the project developers' official recommendation, then hop on /. to diss FreeBSD because of your moronic ways. RTFM, stupid.
I think *BSDs have the clear advantage that ISVs can develop for those OSs and still maintain their business. Their code does not need to be released, as in the case of GPL contamination.
To think little shops can go against huge IT departments is a joke. The joke is on GPL developers. All "successfully" GPL-licensed software has huge corporate backing. Why: Because hardware vendors are neck deep in Linux. However, they have little third-party software written for them.
The GPL has failed in the applications arena, where licenses are largely business-friendly (MIT, Apache, LGPL, etc.). What usually happens is that so-called Freedom Lovers GPL developers dual-license their code. And you have to be really dumb to contribute to a project which asks of you to sign an agreement ceding copyright to people who will dual-license your code, and then make money selling proprietary licenses.
The argument of "taking" or "stealing" code is so absurd. It's immaterial, you can't "take it away". It won't exhaust you.
Damn, I need a grammar nazi.
From what I've read, I think that might be because some developers on the Linux camp have been a factor of irritation when they produce Linuxisms is C code, foresaking portability.You see this phenomenom mentioned in what regards GNOME in the article. It almost sounds as if GNOME developers are a clique that don't give a shit about other projects.
0 305.html
s g00052.html
s g00002.html
Another famous little war was Linuxers resistance (glibc maintainers, to be exact) resistance against the safer strlcpy and strlcat functions from OpenBSD's libc:
See these amazing threads that illustrate prejudice against the OpenBSD developers. After 2 or smth years, they finally gave in and the OpenBSD functions are part of glibc. But here's my sample:
Here's a Debian developer calling on GNOME developer's biased and prejudiced views against OpenBSD's innovation for safer C programming:
http://lists.debian.org/debian-devel/2002/03/msg0
Here's the guy that sends the patch for glibc: http://sources.redhat.com/ml/libc-alpha/2000-08/m
Here's the amazing answer from the glibc's maintainer Ulrich Drepper, a real insight into strong software engineering principles. No wonder Linux boxes got so rootkitted:
This is horribly inefficient BSD crap. Using these function only
leads to other errors. Correct string handling means that you always
know how long your strings are and therefore you can you memcpy
(instead of strcpy). http://sources.redhat.com/ml/libc-alpha/2002-01/m
Theo's take:
TdR: They're still not in glibc. They're everywhere else. They're in Solaris. We invented them two years ago. They're showing up in vendor operating systems. We made a convincing argument why these things are necessary. http://www.ddj.com/184404914
Look at CERT's list for "glibc" vulnerabilites here. Please draw comparisons with BSDs. Answer honestly: who's got bragging rights?
Ever try to get native Java working on FreeBSD? First you have to download the Linux Java distribution, install it, then download the FBSD patchset for native Java, build and install it. This takes a day, even on my 2.4GHz, 768MB laptop.
/. thread on FreeBSD is full of trolls!
h tml
For fsck's sake, it really seems this
Didn't you read the news, the FreeBSD Foundation negotiated with Sun and now there's a native Java on FreeBSD so stop trolling, because installing it is as easy on any, e.g. Debian-like system (simply #pkg_add diablo-jdk-freebsd6-1.5.0.06.00.tbz)
http://www.freebsdfoundation.org/downloads/java.s
I've seen this posted before. Apparently, this guy copies and pastes this everytime "FreeBSD" shows up on /.
under freebsd it's impossible to configure the sound card withouth rebuilding a kernel?
Have you read the FreeBSD handbook? What you say seems totally strange to me, and I'm a new FreeBSD user (ex-Debian, pfff...) You just load the kernel module (or the generic one).
If the Coverity bug report for FOSS software is true, NetBSD is amazingly well done and bug-free.http://scan.coverity.com/
Right here, on my desktop.
You can also google for Theo de Raddt's last interview in which he comments how he doesn't like gcc but uses it for the lack of better free alternative.
I'm sorry, what's so great about GNU userland and Debian's ever-so-late release schedules?
Besides, you want GNU userland stuff (Bash, etc.) you just install them.
Such a thing would be for masochists.
IMHO, when you choose a free software project you must also evaluate how the project is set up. Any moderately important open source project is bound to be a big project. As such, it'll involve software engineering practices, team management, documentation, and other stuff like security policy, release management, buid processes, server farms, etc, all stuff that will reflect on quality of the code base. You must ask yourself: is this a project that will last? Will it scale? Will it be able to produce quality, reliable software in a predictable manner?
Some projects are better engineered as a project than others. Some do stuff better than others. Some work in a "democratic" fashion, others in an "autocratic" fashion. But how the project works as a whole is very important. This may determine, amongst other things whether a project will scale or not.
Let me give you some concrete examples. Autocratic projects are things such as the Linux kernel and the most famous theocracy, Theo's OpenBSD. Such projects may scale or not. These two, apparently do, but you may see problems in the way they're managed, because of the "dictator" aspect. For instance, they may get something wrong. You can't be right all of the time.
Other projects are a complete mess in terms of human resource management. The showcase example is Debian, which doesn't seem to be an organization that scales up very well and seem to be in a pattern of falling short everytime. This, I believe, has to do with a mix of technologies chosen (apt- being just a layer of complexity added to what Makefiles already do - as any BSD port collection proves), and the design of their organization (you know, how all their so-called "developers" get to scream at the mailing lists over trivia all the time). Another example of a project that possibly will not scale is OpenBSD. Already they had financial problems, they're not set up as a Foundation, so they won't be able to do things that an organization like FreeBSD Foundation, Debian or the FSF can achieve in terms of negotiations and legal actions (for instance, OpenBSD will probably never have a Sun certified Java, because Sun can't negotiate with an OpenBSD legal entity). The FreeBSD project, because of the Foundation is able to strike deals with software firms such as Coverity (for source code analysis), which already has produced results in terms of bug-hunting. Other projects will most likely never be able to provide the best tools for their developers.
An yet other projects may have great ideas, but have no clear cut roles and aren't really clear on how they go about their ideas. One that comes to mind is GoboLinux, which sort of threw away the Unix File System hierarchy and borrowed some (innovative) ideas from projects such as NeXT. It's not clear what the roadmap or the security policy is for this project. In fact, I don't think they have a security policy. So that leaves you with a great idea, and a lot of questions. And this from competent hackers. Many free software projects don't even get there. Again, this is just an example. Another example that comes to mind is NexentaOS, which aims to be a GNU/OpenSolaris project. Sounds great, but do they have a plan (besides being able to compile the software)?
And finally, on technical merits alone, I think all BSDs stand to the test. However, when you factor in all those things I mentioned, I believe FreeBSD is set up to be the great project that it is, and will continue to be in the future. So, for me, it's:
techical merits + organizational skills = great open source project
PS: I don't mean to bash projects. I seriously hope they come around their shortcomings.