I disagree. The number of people who want really good OpenGL performance (the reason to use the closed source drivers) on linux is pretty tiny. The crazy gains in performance that ATI and NVidia have consistently been pulling off is because they own half the market each, a niche player can't come close; if you don't believe me then check out some of the graphics card also-rans, like the Volari - none of them are worth buying if you're a gamer. This is the reason ATI doesn't do linux drivers. NVidia can just about justify the salaries of their linux driver team, if they split those sales then both of them lose money.
Interestingly enough, the number of people who run a FreeBSD desktop is a lot smaller still, and of them supposedly only a fraction need good 3d performance. Yet, nvidia saw fit to provide them with a driver as well. It looks like we may even get to see a netbsd driver from them at some point. Why would nvidia do this considering the supposedly very small number of people that would 'need' it?
Maybe there are a few reasons: 1. you may be right about only a few people needing this, but many people can make use of it, and would have a nicer, more responsive gui due to it. So it serves more then gamers and 3d artists, tho those 2 are the primary target 2. development of the nvidia drivers for linux was primarely aimed at 3d workstations, not at gamers. There is quite a bit of money in that market 3. nvidia at least has their driver development relatively well organized, and seems to have relatively few problems supporting a whole lot of platforms with basicly a single driver implementation and a thin platform specific wrapper, so it isn't as expensive for them as you'd think.
Secondly, most of the games you'd buy a good graphics card for on linux are closed source anyway. You have to get over your fear of closed binaries if you want to frag stuff (the wicked Nexuiz notwithstanding).
You are aware there is GPLed source for the quake 1,2 and 3 engines, and for quite a few games based on those? No, its not the latest stuff, but it makes for good fragging for sure.
Likewise for the workstation market - if you want CAD, you're doing stuff with closed source NVidia drivers or not.
Or you are using a Matrox g550 with open source drivers or such
Correctness is way more important then performance for this market. Performance needs to be good enough to ensure previews are not hopelessly slow, but any production quality rendering isn't done in realtime anyway.
I appreciate that OpenGL accelerated desktops will change this a bit, but until that happens the fact is that OpenGL on linux is a fragment of a fragment of a significant market.
All major desktops on Linux can already make use of opengl, and do so when it is available.
You, like so many, make the mistake to think that opengl is only usefull for fast 3d graphics, however, it can do a lot more then that (transparancy, hardware scaling, perspective correction to just name a few)
However, some people are worried about including closed software in their kernel - they don't want linux to turn into the windows driver bugfest for starters....
While you can verify and possibly enhance an open source video driver, being oss is no guarantee for quality, neither is being closed source a guarantee for lack of quality. Incidentely, nvidia has done pretty well with regards to this where ati consistently makes a mess out of it.
For ISPs, overselling bandwidth is the ONLY way they can sell it to end-users cheaply. I know there are some people who are paying $50/month for 8Mbps cablemodems. Do you realize that 8Mbps of bandwidth is costing your ISP THOUSANDS (maybe hundreds, if they're in a big city) of dollars?
Depends.
I have a supposedly 100mbit ethernet connection (gets to 100mbit at times, but realistically is approx 50mbit) from a room very near the amsix, which is costing me the equivalent of $60, including 1u rackspace and 50gb transfer/month.
I also have a supposedly 100mbit ethernet connection from a building near there, which also gets the full 100 mbit, and costs around $120 including 4u rackspace and 20gb traffic (and 24/7 access and some other stuff)
I also manage a 8mbit connection for a company that is not located so luckily, and it costs approx $1500/month. It does indeed manage the 8mbit. Usage is unmetered.
Before that, they had a metered 144mbit fiber connection, but I don't know the exact details on that other then that it was metered, and that it was pretty expensiv to go over the 20gb/month
Bandwidth just isn't as cheap as everyone seems to think it is.
Its not so much bandwidth that costs, it is amounts of data that cost.
So yeah, there is NO WAY an ISP can afford to supply every one of their users the gobs of non-bursty bandwidth necessary to make HDTV downloads on a massive scale work.
Interestingly, the isp I use at home does quite well in providing non-bursty bandwidth. Ok, their supposedly 24mbit adsl2 connection peaks out at around 18 mbit (according to both themselves and my measurements), but provides a steady 12 mbit whenever I try. Could they do it when many customers would be demanding such bandwidth? They already ran into that problem some 2 years ago when they started their iptv experiment.
I don't use iptv, ip is an extremely inefficient way to transport live tv, and the rest I can download fast enough for viewing at my leisure..
and they should already have kernel interfaces in a separate library to save work, so it's a minor matter.
For all I can tell, they pretty much do.. which is why basicly the same binary blob is usable on other platforms with appropriate shims.
This is actually how the first attempt at porting the driver to FreeBSD came to be, and how the current FreeBSD driver can be made (more or less) usable on NetBSD
I don't think that would work very well with things like 2 windows side by side, the one that doesn't have focus displaying a directory, and the one that has focus creating/renaming a file in said directory.
Not to mention having a 'transparant' window overlaying the window with the file list.
In the quote of mine that you quoted, I mentioned that Darwin has taken a lot of code from FreeBSD. This does not mean that Darwin is a version of FreeBSD. I'll say it again - everyone uses FreeBSD code. If operating systems were college students, FreeBSD would be the one that has had sex with every single person you know. Twice. I'm also pretty sure that Darwin, like almost every other Unix that's still in use, especially the BSDs, is chock full of bugfixes that came from OpenBSD. Is all that copied code alone enough to argue that every Unix is just a tweaked version of OpenBSD? Of course not.
Since Darwin uses a substantial amount of FreeBSD code, apple claims FreeBSD 5.x to be the reference platform (THEY claim that, not me or other 'slashdotters'), OS X versions having imported substantial parts of the userland from 4.x and later 5.x, yes, it is fair to say that OS X (more so still then Darwin) is largely (not exclusively) FreeBSD based. Yes, it also uses code from OpenBSD and others, and it definitely also uses code comming from Next. In concept it shares more with Next then in code however, which you can verify btw, get yourself opendarwin and go read the source.
And I'm personally not wowed by the similarity of FreeBSD and Darwin in the shell. Of course there are similarities; they're both more-or-less 4.4BSD Unixes, and I'm sure that their userland is almost identical. But are they really any more identical than, say, NetBSD and FreeBSD? What about OpenBSD and Darwin? For the most part, I'm equally at home on the terminal of any of them. But I can also think of things I do completely differently on each.
Try to find ipfw or dummynet on OpenBSD or NetBSDNor am I particularly wowed by two BSD Unixes being more similar to each other than two different distributions of Linux. Linux is officially the most schizophrenic operating system to ever achieve widespread use. I haven't run it on any of my computers in a while, so I may be a bit off on these numbers, but I remember there being 3 or 4 different ways of getting sound out the speakers, two video interface systems, three different ways you might have to get a wireless card working, two different ways of having the operating system handle/dev, more packaging systems than anyone can count, etc. etc. I know of two different libcs for Linux, and I wouldn't be surprised if there's a third. I can't think of a single operating system in the history of computing that's more customizable or gets used for more different tasks.
Well, you are off a few times, but in idea, yeah, can't think of any OS that comes in so many different variations.. That however doesn't make it more flexible, rather it makes it a pita. That said, on FreeBSD theer are 2 libc implementations, 2 possible ways to get sound working, 2 ways to deal with/dev etc... So maybe that isn't what I mean..
Saying the differences between Darwin and FreeBSD are smaller than the differences among various Linux distributions and using that to imply that they are super intimately related is like saying that the distance from Los Angeles to New York is much smaller than the distance from the Earth to the Moon, so LA and NYC must be really close to each other.
Yes, and relatively spoken they are. You see, that is what happens when you talk about relative concepts like 'being similar'
Regardless, Darwin and OS X imported more code from FreeBSD then from any other platform. Apple says they use FreeBSD as their reference platform for OS X, its userland and the BSD layer of its kernel implement things that are only found in FreeBSD.. You may not like it, may not want to believe it etc, but alas, you'll have to live with it.
As someone else already said, yes, just not configured that way by default.
In fact you can script responses to any usb device being plugged in, if editing a config file and writing some simple scripts isn't a problem, you can do lots of very nifty things... editing config files and writing scripts however isn't an appropriate solution for the typical end-user.
Well, if that's how you feel, you should just stop using them -- and recommending them to your customers.
That is just silly.
I disagree with how Sun does something that mostly affects the usability of one of their products. I rather engage them on that. I wrote about this issue years ago, and I know that has been read by people inside Sun. I am not alone in making an argument about the problems with their current distribution restrictions, and I am not alone in dismissing their arguments about why they do not want to open source it, in fact I believe they are completely wrong there. Regardless, Sun shows they are willing to at least try to solve the practical issues (a vendor redistribution licence is comming, lets see the terms and conditions on that one), and technically they have a good solution.
"FreeBSD imported code from OSX 10.x" Oh, never mind...
1. That is irrelevant for tracing back the history of OS X, which was what was being discussed 2. They don't have to, no matter how much you may dislike that 3, Despite 2, they do contribute code regularely.
Lets for the sake of the discussion assume that with gui installer we both mean an easy to use and pretty to look at installer (for which a gui is the norm right now as you mentioned)
Okay. But given that users and IT departments are not exactly pounding down the doors to get FreeBSD onto the desktop, how exactly is this a recipe for growth?
1. make sure they get to know about the system and its advantages (as I mentioned earlier, a vmdk image that can be used with vmware player or such would be a good option for this, so are the various 'live' cd and dvd versions)
2. make sure it is easier and less costly to customize and support
This is actually an article about FreeBSD attaining (or nearing) feature parity with Linux *on the desktop*
It is getting there, but it isn't entirely there yet. Also, this is very recent really.
It is why I am supporting a few dozen freebsd based desktops now, while a year ago I was only supporting a bunch of freebsd based servers. It is improving at a very nice pace. It has always had near the level of customization that you can get from something like Linux from Scratch, while offering good package management and stability comparable to the best you can get on Linux. There is no Linux distribution combining that so well and not having a much higher barrier to entry (lfs, gentoo to name some)
So, for independent hardware and software vendors, it just has gotten to the point where it can compete in functionality (lacking a bit at some points, being a bit better at some others) for a desktop. Making all that easy to configure and support is progressing nicely, but not yet there.
The next issue when looking at the non corporate end-user is how to enable them to easily extend their system and change it to their requirements. An end-user orriented frontend for packages/ports is essential for that, having an easy to use and nice looking interface for configuring common options is also essential.
Getting ISVs to package their software for easy installation on FreeBSD would be a nice extra, its not essential because this can be done using the ports collection (and is done for many popular linux apps that run on FreeBSD already)
, and I think it's fair to say that the installer is a feature that MUST be competitive (with Linux at the very *least*) for FreeBSD to gain any ground on the desktop. Until the day when users and IT managers gain religion and start clamoring for FreeBSD, anyway, this is not an area to be behind the competition. As of *today*, your options for getting FreeBSD pre-installed on a desktop machine are practically nil, and the bar for installing it yourself is too high.
The bar is too high due to configuration requirements, not due to the installer.
As a sidenote, in the early 90s, I was working for IBM, doing OS/2 development and support. There was a 'school' there that insisted that OS/2 needed a graphical installer to ever become a serious desktop contender, using similar argumentation. Now, this was at a time where it was more common for end-users to install a new OS on their computer so my first argument as to why this is desirable but not essential didn't apply as strongly back then.
Why didn't OS/2 gain desktop dominance? (it did get its graphical installer, a pretty and easy to use one in my opinion also) That had a lot more to do with lacking application support, trouble with getting hardware supported and configured, and the reputation it had for being a resource hog and unfriendly (by the time of windows 95 and OS/2 warp, both were untrue, not to mention that OS/2 was at that moment technically miles ahead).
Bottomline the leson I learned from that is that no matter how easy you make it to install, as long as the result is not substantially easier to use (which also has a lot to do with user expectations and experience) and/or substantially more productive, it has no chance on the desktop. When it can do one or both, the trick is convincing people, an
Am I missing something, or is this really what you're saying?
I think so yes...
I am saying that the large majority of users never ever installs an OS, rather, they get it installed for them one way or another. Maybe it comes preinstalled, maybe their IT department installs it for them, maybe a local shop does, otherwise a more computer savy family member or neighbor does. Typical end-users installing operating systems has become rather the exception.
An installer needs to be good enough for that, that is essential. A better installer makes things more attractive, but is not essential because it is simply a one time thing.
What is essential is that the system thus installed is easy and pleasant to use and does not become a major headache and expensive to support. Good support for plug and play hardware and removable media, good compatibility with existing media and file formats and 'snappy' responsiveness are essential for that.
If you are trying to cater to users by the looks of your installer, better put it in a huge shiny box with a huge pile of cool looking documentation (to fill the bookshelves, not for reading!)...
A licence that doesn't cause major headages is one of the arguments why the BSDs are usually an attractive option indeed, and is part of why my clients use it.
The fact that it is extremely easy to customize for specific use was the main argument however. Simple cost/benefit analysis turned out that what they need was easier and hence cheaper to implement with FreeBSD then with Linux (x/vnc/rdp client, stripped down kde based desktop with kolab integration and openoffice, running on a rather smallish 'thin client' with limited memory and local storage, minimum config is 256mb without swap, 512mb flash card and a 500mhz 686 class cpu)
The big advantage in corporate environments that Linux has nowadays is name recognition... It is 'hip' to use it.
"FreeBSD needs A and B and C to succeed on the desktop. Making A easier won't make B and C easier." No argument.
Except that there are alternative ways to get a machine with FreeBSD. a user installing it him/herself is one way, but, since you like realism, the large majority of the users never ever does that.
Making it easy for companies to preinstall FreeBSD on 'thin client' and specialized desktop machines makes it very attractive for independent hardware and software vendors to use it, and as a result for users to get it preinstalled.
So.. I dispute that 'A' is needed, I do however agree that it is desirable to have and makes adaptation of FreeBSD as a desktop easier. That does not make it essential however.
I notice you didn't try to argue that FreeBSD's installer is already as easy as Windows or Mac OS X's GUI installers (let alone easier).
No, I am arguing it is good enough for people who also have the required capabilities to configure the system for desktop use. It can use a complete overhaul, no argument there.
Possibly, but it's not happening right now and it doesn't look likely to happen anytime soon. Perhaps some organizations will decide to go with FreeBSD (for whatever reason) but it will not continue to expand as long as there are cheaper or easier alternatives to run office applications, which means Windows.
Matter of fact is, it is happening right now. I know because I make a living supporting such organisations.
Also, a FreeBSD desktop with openoffice is definitely not going to be more expensive then a Windows machine. The hardware is cheaper, the software is cheaper. Only in support things are a bit less clear. FreeBSD support is generally more expensive/hour due to less availability, but with a well thought out setup, you'll need a lot less of it, so even that may turn out to be cheaper.
No, it's one of several things, but rest assured that if the installer is not at least as easy to use as Windows or Mac OS X, the average desktop user will abandon the effort rather than figure it out. Right now, the OS has to be easily installable to gain ground in the desktop market. The reason is because most people have to *switch* to FreeBSD to use it, which means installing it.
Easy to use does not mean a gui. An commandline based installer that asks as little from the user as possible and figures out everything that it can itself is a lot easier to use then a gui that requires you to set every option.
You have no argument
Argument: gui installer is nice to have, but FreeBSD has more pressing issues to solve for desktop use right now Argument: installation is a one time process, usage is not, so as long as the installer is 'good enough', it will do, people will not see it during normal usage, so for normal desktop use it is pretty much irrelevant Argument: there are many ways to get a FreeBSD machine, installing yourself is one of them. Argument: FreeBSD as it is now requires a technically knowledgable user to configure it properly, a gui installer is not going to change that. Argument: gui != easy to use
Try again please.
- your claim that pre-installed FreeBSD will become a common solution is wishful thinking of the highest order. Sorry, but I'm just being realistic here. More power to you if you can make it happen!
Pre-installed FreeBSD workstations in a corporate environment is quite an option now. Turning every pxe capable x86 machine into a FreeBSD workstation is quite an option now for corporate environments. None of this uses the installer in any way.
When looking at home users.. there it is less of an option unless you take the time to configure everything. Installation is still not the big problem here.
How many computer models can you buy with FreeBSD pre-installed? Nearly 1?
Not many, tho one of the companies I work with will be selling one later this year.
Matter of fact is that I support a few dozen FreeBSD desktop machines. The users of those machines do not have to know how to install or update things, they do not even know what they are using really, and they don't have to.
Non-sequitur. Gaining the desktop market, by definition, is turning those "clueless" users into FreeBSD users. And you do that by: 1. making those users get a clue what they're doing 2. changing the software so the user needs fewer clues.
Or 3, get the user a well configured preinstalled machine. While you will have trouble buying one right now probably, this is a very realistic option for a corporate environment.
Number 2 might just be possible. Number 1 will NEVER happen.
No, but luckily there are already some cluefull users. Right now much of the functionality required for desktop use is there, but it takes quite some fiddling to get things working nicely on a specific configuration. Untill that is the case, a graphical installer is a 'nice to have', but is definitely not what is stopping unknowledgable users from trying to use FreeBSD.
For FreeBSD to gain the desktop market, it's one of the top priorities - it's absolutely essential!
You can repeat that over and over, but so far you are not providing any kind of argument as to why this is the case, while being confronted with arguments as to why this is not the case.
I suggest you at least try to make an argument, or maybe consider your point of view.
That said, a gui installer would be helpfull for getting new users to try FreeBSD for sure. What would be even more helpfull for that is a pre-rolled vmware live image that people can download and try. There are many other things that could make it more attractive for new users to try FreeBSD, but for the moment, the big issue is that it is not all that easy to get everything to work right (auto mounting of usb memory sticks, cds etc can quite be done, but isn't exactly working 'out of the box' just to give one example, there are many of those), and getting that done has a much higher priority then a graphical installer.
Or were you making the argument that competing with Linux doesn't actually involve the desktop market?
The obvious problem for large projects like GNOME is of course that they need to make a good experience on a pretty wide variety of platforms. To use any platform-specific feature it will need to be either emulated, replicated, worked around or otherwise made available on all platforms; or it could only go in as an optional extra that nothing else is actually depending on. So, making advanced FS logging capabilities a cornerstone of the desktop, for example, would be out since far from all platforms will have the requisite framework. "You can only run desktop X if you also use filesystem Y" is likely to go over like a lead balloon.
The complaint is that the gnome (and kde) team does implement platform specific things, specifically, Linux specific things. In many cases there would be workarounds or ways to support them in a less platform specific way, but that is not being used..
A very nice example in kde is the way ksysguard obtains information about running processes...
Why would you actually look at the OS provided info for entries in/proc... you 'know' the pid is at a specific line in Linux, so just grab it there..
If the desktop you seek then a graphical installer begin thy path.
Supposedly you install once (most people neer install, they hire someone to do it for them or buyt their computer preinstalled).
Supposedly, those who are interested in installing something else then the preinstalled stuff on their machine have a slight clue about what they are doing.
If you combine those 2 things, the conclusion must be that while a graphhical installer is definitely nice to have, it is by for not as important as you make it.
Specially considering that what really matters for desktop is gnome, kde,x.org...not the kernel.
X and a desktop environment matter the most for sure.. but I think you are quite seriously underestimating the role of a kernel in this..
The kernel is involved in things hardware support, device and power management (suspend) etc, but what really matters is gnome and kde, nothing else. Gnome is not more usable under freebsd than in linux, neither the reverse.
You see.. audio/video support sortof matters for desktop use.. so does plug and play hardware support (just plugin that camera and it works..), which are indeed hardware related but specifically, usb, drm/dri and sound support are extremely important for a desktop.
Then, the scheduler can make quite a difference (optimized for throiughput versus responsiveness for example makes a big difference in how 'snappy' your desktop feels)
Then, if you open a folder in say the kde or gnome file/directory browsers, there are 3 things you desktop can do: 1. not notice changes to the directory untill you manually refresh the view 2. poll the filesystem for changes and display them once they got noticed 3. ask the kernel to send a notification when a file changes
1. is no longer an acceptable option nowadays 2. becomes very expensive when you have a lot of files in said directory, and it is always 'too late' 3. requires kernel support (it is supported in slightly different ways in Linux and FreeBSD now) but is low overhead and virtually inmediate.
As you can see, the kernel does in fact play an important role in simple things like browsing a directory already...
So, yes, it does definitely matter for both gnome and kde what kernel they are running on. A year ago the difference between Linux and FreeBSD was substantial, esp. with regards to the scheduler and support for things like fam (without having to poll for changes).. nowadays the difference is far less big.
OS X, back when it was called NEXTSTEP, forked off of BSD 8 years before FreeBSD did, even before 4.4lite came on the scene. You can trace its lineage yourself, if you'd like. Since then, there's been a lot of code borrowing but everyone borrows from FreeBSD and FreeBSD is far from the only OS whose code Darwin has borrowed. Using just that to say that Darwin is based on FreeBSD would make little more sense than using the same fact to claim that GNU/Linux and Windows XP are based on FreeBSD.
Referenced from the site you mention yourself is the BSD family tree.
If you had bothered to look at it, you'd have noticed that:
Darwin is based on Rhapsody, NetBSD 1.4 and FreeBSD 3.2 OS X 10.2 imported code from FreeBSD 4.4 OS X 10.3 imported code from FreeBSD 5.1
If you had ever bothered to use a FreeBSD 5.x machine for a while, and used a machine with OS X for a while from the shell, you'd have noticed how the userland is virtually identical, to a level way beyond how some linux distributions are similar..
Where OS X really did not derive from FreeBSD at all is at the kernel level and of course the gui.
Linux will always be ahead on cutting edge hardware because of the nature of the licences.
History shows that the 'always' part in there is seriously wrong..
BSD gets a driver, linux will have in after a quick port. Linux gets a driver, BSD has to wait and re-impliment.
That is how it seems to a person who has absolutely no idea about kernels and drivers and the different BSD distributions.
First, there are quite a few BSD variations all with their own set of rules for integrating drivers, where some see no problem in using gpl code, others see no problem in using closed source drivers in cases, and yet others swear that everything must be free and open.
Second, differences between a BSD style kernel and the linux kernel are substantial enough that a 'quick port' is seldom an option for technical reasons alone.
I still happen to have an old t39m around with 2 good batteries, which I use mostly.. its simple, esp. to todays standards, but it does bluetooth and gprs, has a very good sound quality and receiption..
Almost a year ago, I got a free k300 from my provider (simlock free even), and didn't expect much of it. While as you say it doesn't seem overly sturdy, I was happily surprised by its sound quality and user interface. Its reception however is inferior to that of my old t39m, or so it seems from the number of calls it drops in slightly difficult conditions, as is its capability to roam between busy cells.
On the other hand, its gprs performance seems better and more reliable.. makes you wonder how much of this is really a matter of reception.
Allowing everyone to redistribute it would make the dream of "write once run everywhere" even more utopical. Various vendors will be blaming other vendors-supplied JREs for troubles with their applications... "Oh, no, you can't use the XYZ's JRE with out product, it is not compatible."
Yep.. like we have 15 different and incompatible perl, php, rub and python distributions from different people.. oh wait..
The fact that the current licence helped against Microsoft is no proof whatsoever of that being the only possible defense, neither does it say that if there was a different licence at the time, SUN couldn't have done something about the attempt to corrupt the standard.
Sun is right -- you want a JRE, you get it from Sun. Either in binary, if available, or in source...
No, they are as wrong as it gets, and seeing their shifting with licence terms, they know their licence is way to restrictive still, just instead of using a known working solution, they try to peal off just enough restrictions to solve the problem for the short term.
You can. You just have to pass a very vigorous compliance test. FreeBSD -- a volunteer organization -- did it, so it can not be unbearably hard.
I am pretty well aware of that they did that, and I also know that the previous time they managed that was for 1.3, running on FreeBSD 4.x
The point of that is that when you needed 1.4.x, or untill recently, 1.5.x, you were out of luck or had to build it from source, which I have done for years btw, so I quite know that it is possible also.
Since when is "building from source" a bad thing?..
But, anyway, you should stop the FUD-spreading -- not "each user of such a system". An organization can build a JDK once on a system, and let all users of all compatible systems use it.
Building from source is not a bad thing at all in many cases, and I do so all the time, but neither is creating a specific binary package together with some other specific binary packages and distribute that to an enduser who can install it in a few minutes, and potentially with your support run it. I support many such users, often small companies. Since those are not one big organisation, rather, all of them are seperate businesses and individuals, it helps exactly 0, nada that I can distribute a build I did myself within my own organisation.
Having all of them compile their own version is a situation I do not want to support and is not desired by my customers either because of the required investment in time and knowledge, not to mention the waste of energy in effectively repeating the same thing over and over.
I am not spreading fud, but you are lacking understanding and/or the ability to imagine a situation slightly different from your own obviously.. either that or you simply can't stand a critical comment about sun and/or java
Slashdot Mirror
I disagree. The number of people who want really good OpenGL performance (the reason to use the closed source drivers) on linux is pretty tiny. The crazy gains in performance that ATI and NVidia have consistently been pulling off is because they own half the market each, a niche player can't come close; if you don't believe me then check out some of the graphics card also-rans, like the Volari - none of them are worth buying if you're a gamer.
This is the reason ATI doesn't do linux drivers. NVidia can just about justify the salaries of their linux driver team, if they split those sales then both of them lose money.
Interestingly enough, the number of people who run a FreeBSD desktop is a lot smaller still, and of them supposedly only a fraction need good 3d performance. Yet, nvidia saw fit to provide them with a driver as well. It looks like we may even get to see a netbsd driver from them at some point. Why would nvidia do this considering the supposedly very small number of people that would 'need' it?
Maybe there are a few reasons:
1. you may be right about only a few people needing this, but many people can make use of it, and would have a nicer, more responsive gui due to it. So it serves more then gamers and 3d artists, tho those 2 are the primary target
2. development of the nvidia drivers for linux was primarely aimed at 3d workstations, not at gamers. There is quite a bit of money in that market
3. nvidia at least has their driver development relatively well organized, and seems to have relatively few problems supporting a whole lot of platforms with basicly a single driver implementation and a thin platform specific wrapper, so it isn't as expensive for them as you'd think.
Secondly, most of the games you'd buy a good graphics card for on linux are closed source anyway. You have to get over your fear of closed binaries if you want to frag stuff (the wicked Nexuiz notwithstanding).
You are aware there is GPLed source for the quake 1,2 and 3 engines, and for quite a few games based on those? No, its not the latest stuff, but it makes for good fragging for sure.
Likewise for the workstation market - if you want CAD, you're doing stuff with closed source NVidia drivers or not.
Or you are using a Matrox g550 with open source drivers or such
Correctness is way more important then performance for this market. Performance needs to be good enough to ensure previews are not hopelessly slow, but any production quality rendering isn't done in realtime anyway.
I appreciate that OpenGL accelerated desktops will change this a bit, but until that happens the fact is that OpenGL on linux is a fragment of a fragment of a significant market.
All major desktops on Linux can already make use of opengl, and do so when it is available.
You, like so many, make the mistake to think that opengl is only usefull for fast 3d graphics, however, it can do a lot more then that (transparancy, hardware scaling, perspective correction to just name a few)
However, some people are worried about including closed software in their kernel - they don't want linux to turn into the windows driver bugfest for starters....
While you can verify and possibly enhance an open source video driver, being oss is no guarantee for quality, neither is being closed source a guarantee for lack of quality. Incidentely, nvidia has done pretty well with regards to this where ati consistently makes a mess out of it.
For ISPs, overselling bandwidth is the ONLY way they can sell it to end-users cheaply. I know there are some people who are paying $50/month for 8Mbps cablemodems. Do you realize that 8Mbps of bandwidth is costing your ISP THOUSANDS (maybe hundreds, if they're in a big city) of dollars?
Depends.
I have a supposedly 100mbit ethernet connection (gets to 100mbit at times, but realistically is approx 50mbit) from a room very near the amsix, which is costing me the equivalent of $60, including 1u rackspace and 50gb transfer/month.
I also have a supposedly 100mbit ethernet connection from a building near there, which also gets the full 100 mbit, and costs around $120 including 4u rackspace and 20gb traffic (and 24/7 access and some other stuff)
I also manage a 8mbit connection for a company that is not located so luckily, and it costs approx $1500/month. It does indeed manage the 8mbit. Usage is unmetered.
Before that, they had a metered 144mbit fiber connection, but I don't know the exact details on that other then that it was metered, and that it was pretty expensiv to go over the 20gb/month
Bandwidth just isn't as cheap as everyone seems to think it is.
Its not so much bandwidth that costs, it is amounts of data that cost.
So yeah, there is NO WAY an ISP can afford to supply every one of their users the gobs of non-bursty bandwidth necessary to make HDTV downloads on a massive scale work.
Interestingly, the isp I use at home does quite well in providing non-bursty bandwidth. Ok, their supposedly 24mbit adsl2 connection peaks out at around 18 mbit (according to both themselves and my measurements), but provides a steady 12 mbit whenever I try. Could they do it when many customers would be demanding such bandwidth? They already ran into that problem some 2 years ago when they started their iptv experiment.
I don't use iptv, ip is an extremely inefficient way to transport live tv, and the rest I can download fast enough for viewing at my leisure..
and they should already have kernel interfaces in a separate library to save work, so it's a minor matter.
For all I can tell, they pretty much do.. which is why basicly the same binary blob is usable on other platforms with appropriate shims.
This is actually how the first attempt at porting the driver to FreeBSD came to be, and how the current FreeBSD driver can be made (more or less) usable on NetBSD
'gains focus'..
I don't think that would work very well with things like 2 windows side by side, the one that doesn't have focus displaying a directory, and the one that has focus creating/renaming a file in said directory.
Not to mention having a 'transparant' window overlaying the window with the file list.
In the quote of mine that you quoted, I mentioned that Darwin has taken a lot of code from FreeBSD. This does not mean that Darwin is a version of FreeBSD. I'll say it again - everyone uses FreeBSD code. If operating systems were college students, FreeBSD would be the one that has had sex with every single person you know. Twice. I'm also pretty sure that Darwin, like almost every other Unix that's still in use, especially the BSDs, is chock full of bugfixes that came from OpenBSD. Is all that copied code alone enough to argue that every Unix is just a tweaked version of OpenBSD? Of course not.
/dev, more packaging systems than anyone can count, etc. etc. I know of two different libcs for Linux, and I wouldn't be surprised if there's a third. I can't think of a single operating system in the history of computing that's more customizable or gets used for more different tasks.
/dev etc... So maybe that isn't what I mean..
Since Darwin uses a substantial amount of FreeBSD code, apple claims FreeBSD 5.x to be the reference platform (THEY claim that, not me or other 'slashdotters'), OS X versions having imported substantial parts of the userland from 4.x and later 5.x, yes, it is fair to say that OS X (more so still then Darwin) is largely (not exclusively) FreeBSD based. Yes, it also uses code from OpenBSD and others, and it definitely also uses code comming from Next. In concept it shares more with Next then in code however, which you can verify btw, get yourself opendarwin and go read the source.
And I'm personally not wowed by the similarity of FreeBSD and Darwin in the shell. Of course there are similarities; they're both more-or-less 4.4BSD Unixes, and I'm sure that their userland is almost identical. But are they really any more identical than, say, NetBSD and FreeBSD? What about OpenBSD and Darwin? For the most part, I'm equally at home on the terminal of any of them. But I can also think of things I do completely differently on each.
Try to find ipfw or dummynet on OpenBSD or NetBSDNor am I particularly wowed by two BSD Unixes being more similar to each other than two different distributions of Linux. Linux is officially the most schizophrenic operating system to ever achieve widespread use. I haven't run it on any of my computers in a while, so I may be a bit off on these numbers, but I remember there being 3 or 4 different ways of getting sound out the speakers, two video interface systems, three different ways you might have to get a wireless card working, two different ways of having the operating system handle
Well, you are off a few times, but in idea, yeah, can't think of any OS that comes in so many different variations.. That however doesn't make it more flexible, rather it makes it a pita. That said, on FreeBSD theer are 2 libc implementations, 2 possible ways to get sound working, 2 ways to deal with
Saying the differences between Darwin and FreeBSD are smaller than the differences among various Linux distributions and using that to imply that they are super intimately related is like saying that the distance from Los Angeles to New York is much smaller than the distance from the Earth to the Moon, so LA and NYC must be really close to each other.
Yes, and relatively spoken they are. You see, that is what happens when you talk about relative concepts like 'being similar'
Regardless, Darwin and OS X imported more code from FreeBSD then from any other platform. Apple says they use FreeBSD as their reference platform for OS X, its userland and the BSD layer of its kernel implement things that are only found in FreeBSD.. You may not like it, may not want to believe it etc, but alas, you'll have to live with it.
As someone else already said, yes, just not configured that way by default.
In fact you can script responses to any usb device being plugged in, if editing a config file and writing some simple scripts isn't a problem, you can do lots of very nifty things... editing config files and writing scripts however isn't an appropriate solution for the typical end-user.
Well, if that's how you feel, you should just stop using them -- and recommending them to your customers.
That is just silly.
I disagree with how Sun does something that mostly affects the usability of one of their products. I rather engage them on that. I wrote about this issue years ago, and I know that has been read by people inside Sun. I am not alone in making an argument about the problems with their current distribution restrictions, and I am not alone in dismissing their arguments about why they do not want to open source it, in fact I believe they are completely wrong there. Regardless, Sun shows they are willing to at least try to solve the practical issues (a vendor redistribution licence is comming, lets see the terms and conditions on that one), and technically they have a good solution.
So, where's the part that says
"FreeBSD imported code from OSX 10.x"
Oh, never mind...
1. That is irrelevant for tracing back the history of OS X, which was what was being discussed
2. They don't have to, no matter how much you may dislike that
3, Despite 2, they do contribute code regularely.
Whoops, you are right of course.
Lets for the sake of the discussion assume that with gui installer we both mean an easy to use and pretty to look at installer (for which a gui is the norm right now as you mentioned)
Okay. But given that users and IT departments are not exactly pounding down the doors to get FreeBSD onto the desktop, how exactly is this a recipe for growth?
1. make sure they get to know about the system and its advantages (as I mentioned earlier, a vmdk image that can be used with vmware player or such would be a good option for this, so are the various 'live' cd and dvd versions)
2. make sure it is easier and less costly to customize and support
This is actually an article about FreeBSD attaining (or nearing) feature parity with Linux *on the desktop*
It is getting there, but it isn't entirely there yet. Also, this is very recent really.
It is why I am supporting a few dozen freebsd based desktops now, while a year ago I was only supporting a bunch of freebsd based servers. It is improving at a very nice pace. It has always had near the level of customization that you can get from something like Linux from Scratch, while offering good package management and stability comparable to the best you can get on Linux. There is no Linux distribution combining that so well and not having a much higher barrier to entry (lfs, gentoo to name some)
So, for independent hardware and software vendors, it just has gotten to the point where it can compete in functionality (lacking a bit at some points, being a bit better at some others) for a desktop. Making all that easy to configure and support is progressing nicely, but not yet there.
The next issue when looking at the non corporate end-user is how to enable them to easily extend their system and change it to their requirements. An end-user orriented frontend for packages/ports is essential for that, having an easy to use and nice looking interface for configuring common options is also essential.
Getting ISVs to package their software for easy installation on FreeBSD would be a nice extra, its not essential because this can be done using the ports collection (and is done for many popular linux apps that run on FreeBSD already)
, and I think it's fair to say that the installer is a feature that MUST be competitive (with Linux at the very *least*) for FreeBSD to gain any ground on the desktop. Until the day when users and IT managers gain religion and start clamoring for FreeBSD, anyway, this is not an area to be behind the competition. As of *today*, your options for getting FreeBSD pre-installed on a desktop machine are practically nil, and the bar for installing it yourself is too high.
The bar is too high due to configuration requirements, not due to the installer.
As a sidenote, in the early 90s, I was working for IBM, doing OS/2 development and support. There was a 'school' there that insisted that OS/2 needed a graphical installer to ever become a serious desktop contender, using similar argumentation. Now, this was at a time where it was more common for end-users to install a new OS on their computer so my first argument as to why this is desirable but not essential didn't apply as strongly back then.
Why didn't OS/2 gain desktop dominance? (it did get its graphical installer, a pretty and easy to use one in my opinion also)
That had a lot more to do with lacking application support, trouble with getting hardware supported and configured, and the reputation it had for being a resource hog and unfriendly (by the time of windows 95 and OS/2 warp, both were untrue, not to mention that OS/2 was at that moment technically miles ahead).
Bottomline the leson I learned from that is that no matter how easy you make it to install, as long as the result is not substantially easier to use (which also has a lot to do with user expectations and experience) and/or substantially more productive, it has no chance on the desktop. When it can do one or both, the trick is convincing people, an
Am I missing something, or is this really what you're saying?
I think so yes...
I am saying that the large majority of users never ever installs an OS, rather, they get it installed for them one way or another. Maybe it comes preinstalled, maybe their IT department installs it for them, maybe a local shop does, otherwise a more computer savy family member or neighbor does. Typical end-users installing operating systems has become rather the exception.
An installer needs to be good enough for that, that is essential. A better installer makes things more attractive, but is not essential because it is simply a one time thing.
What is essential is that the system thus installed is easy and pleasant to use and does not become a major headache and expensive to support. Good support for plug and play hardware and removable media, good compatibility with existing media and file formats and 'snappy' responsiveness are essential for that.
If you are trying to cater to users by the looks of your installer, better put it in a huge shiny box with a huge pile of cool looking documentation (to fill the bookshelves, not for reading!)...
A licence that doesn't cause major headages is one of the arguments why the BSDs are usually an attractive option indeed, and is part of why my clients use it.
The fact that it is extremely easy to customize for specific use was the main argument however. Simple cost/benefit analysis turned out that what they need was easier and hence cheaper to implement with FreeBSD then with Linux (x/vnc/rdp client, stripped down kde based desktop with kolab integration and openoffice, running on a rather smallish 'thin client' with limited memory and local storage, minimum config is 256mb without swap, 512mb flash card and a 500mhz 686 class cpu)
The big advantage in corporate environments that Linux has nowadays is name recognition... It is 'hip' to use it.
"FreeBSD needs A and B and C to succeed on the desktop. Making A easier won't make B and C easier." No argument.
Except that there are alternative ways to get a machine with FreeBSD. a user installing it him/herself is one way, but, since you like realism, the large majority of the users never ever does that.
Making it easy for companies to preinstall FreeBSD on 'thin client' and specialized desktop machines makes it very attractive for independent hardware and software vendors to use it, and as a result for users to get it preinstalled.
So.. I dispute that 'A' is needed, I do however agree that it is desirable to have and makes adaptation of FreeBSD as a desktop easier. That does not make it essential however.
I notice you didn't try to argue that FreeBSD's installer is already as easy as Windows or Mac OS X's GUI installers (let alone easier).
No, I am arguing it is good enough for people who also have the required capabilities to configure the system for desktop use. It can use a complete overhaul, no argument there.
Possibly, but it's not happening right now and it doesn't look likely to happen anytime soon. Perhaps some organizations will decide to go with FreeBSD (for whatever reason) but it will not continue to expand as long as there are cheaper or easier alternatives to run office applications, which means Windows.
Matter of fact is, it is happening right now. I know because I make a living supporting such organisations.
Also, a FreeBSD desktop with openoffice is definitely not going to be more expensive then a Windows machine. The hardware is cheaper, the software is cheaper. Only in support things are a bit less clear. FreeBSD support is generally more expensive/hour due to less availability, but with a well thought out setup, you'll need a lot less of it, so even that may turn out to be cheaper.
No, it's one of several things, but rest assured that if the installer is not at least as easy to use as Windows or Mac OS X, the average desktop user will abandon the effort rather than figure it out. Right now, the OS has to be easily installable to gain ground in the desktop market. The reason is because most people have to *switch* to FreeBSD to use it, which means installing it.
Easy to use does not mean a gui.
An commandline based installer that asks as little from the user as possible and figures out everything that it can itself is a lot easier to use then a gui that requires you to set every option.
You have no argument
Argument: gui installer is nice to have, but FreeBSD has more pressing issues to solve for desktop use right now
Argument: installation is a one time process, usage is not, so as long as the installer is 'good enough', it will do, people will not see it during normal usage, so for normal desktop use it is pretty much irrelevant
Argument: there are many ways to get a FreeBSD machine, installing yourself is one of them.
Argument: FreeBSD as it is now requires a technically knowledgable user to configure it properly, a gui installer is not going to change that.
Argument: gui != easy to use
Try again please.
- your claim that pre-installed FreeBSD will become a common solution is wishful thinking of the highest order. Sorry, but I'm just being realistic here. More power to you if you can make it happen!
Pre-installed FreeBSD workstations in a corporate environment is quite an option now. Turning every pxe capable x86 machine into a FreeBSD workstation is quite an option now for corporate environments. None of this uses the installer in any way.
When looking at home users.. there it is less of an option unless you take the time to configure everything. Installation is still not the big problem here.
How many computer models can you buy with FreeBSD pre-installed? Nearly 1?
Not many, tho one of the companies I work with will be selling one later this year.
Matter of fact is that I support a few dozen FreeBSD desktop machines. The users of those machines do not have to know how to install or update things, they do not even know what they are using really, and they don't have to.
Non-sequitur. Gaining the desktop market, by definition, is turning those "clueless" users into FreeBSD users. And you do that by:
1. making those users get a clue what they're doing
2. changing the software so the user needs fewer clues.
Or 3, get the user a well configured preinstalled machine. While you will have trouble buying one right now probably, this is a very realistic option for a corporate environment.
Number 2 might just be possible. Number 1 will NEVER happen.
No, but luckily there are already some cluefull users. Right now much of the functionality required for desktop use is there, but it takes quite some fiddling to get things working nicely on a specific configuration. Untill that is the case, a graphical installer is a 'nice to have', but is definitely not what is stopping unknowledgable users from trying to use FreeBSD.
For FreeBSD to gain the desktop market, it's one of the top priorities - it's absolutely essential!
You can repeat that over and over, but so far you are not providing any kind of argument as to why this is the case, while being confronted with arguments as to why this is not the case.
I suggest you at least try to make an argument, or maybe consider your point of view.
That said, a gui installer would be helpfull for getting new users to try FreeBSD for sure. What would be even more helpfull for that is a pre-rolled vmware live image that people can download and try. There are many other things that could make it more attractive for new users to try FreeBSD, but for the moment, the big issue is that it is not all that easy to get everything to work right (auto mounting of usb memory sticks, cds etc can quite be done, but isn't exactly working 'out of the box' just to give one example, there are many of those), and getting that done has a much higher priority then a graphical installer.
Or were you making the argument that competing with Linux doesn't actually involve the desktop market?
The obvious problem for large projects like GNOME is of course that they need to make a good experience on a pretty wide variety of platforms. To use any platform-specific feature it will need to be either emulated, replicated, worked around or otherwise made available on all platforms; or it could only go in as an optional extra that nothing else is actually depending on. So, making advanced FS logging capabilities a cornerstone of the desktop, for example, would be out since far from all platforms will have the requisite framework. "You can only run desktop X if you also use filesystem Y" is likely to go over like a lead balloon.
/proc... you 'know' the pid is at a specific line in Linux, so just grab it there..
The complaint is that the gnome (and kde) team does implement platform specific things, specifically, Linux specific things. In many cases there would be workarounds or ways to support them in a less platform specific way, but that is not being used..
A very nice example in kde is the way ksysguard obtains information about running processes...
Why would you actually look at the OS provided info for entries in
If the desktop you seek then a graphical installer begin thy path.
Supposedly you install once (most people neer install, they hire someone to do it for them or buyt their computer preinstalled).
Supposedly, those who are interested in installing something else then the preinstalled stuff on their machine have a slight clue about what they are doing.
If you combine those 2 things, the conclusion must be that while a graphhical installer is definitely nice to have, it is by for not as important as you make it.
Specially considering that what really matters for desktop is gnome, kde,x.org...not the kernel.
X and a desktop environment matter the most for sure.. but I think you are quite seriously underestimating the role of a kernel in this..
The kernel is involved in things hardware support, device and power management (suspend) etc, but what really matters is gnome and kde, nothing else. Gnome is not more usable under freebsd than in linux, neither the reverse.
You see.. audio/video support sortof matters for desktop use.. so does plug and play hardware support (just plugin that camera and it works..), which are indeed hardware related but specifically, usb, drm/dri and sound support are extremely important for a desktop.
Then, the scheduler can make quite a difference (optimized for throiughput versus responsiveness for example makes a big difference in how 'snappy' your desktop feels)
Then, if you open a folder in say the kde or gnome file/directory browsers, there are 3 things you desktop can do:
1. not notice changes to the directory untill you manually refresh the view
2. poll the filesystem for changes and display them once they got noticed
3. ask the kernel to send a notification when a file changes
1. is no longer an acceptable option nowadays
2. becomes very expensive when you have a lot of files in said directory, and it is always 'too late'
3. requires kernel support (it is supported in slightly different ways in Linux and FreeBSD now) but is low overhead and virtually inmediate.
As you can see, the kernel does in fact play an important role in simple things like browsing a directory already...
So, yes, it does definitely matter for both gnome and kde what kernel they are running on. A year ago the difference between Linux and FreeBSD was substantial, esp. with regards to the scheduler and support for things like fam (without having to poll for changes).. nowadays the difference is far less big.
OS X, back when it was called NEXTSTEP, forked off of BSD 8 years before FreeBSD did, even before 4.4lite came on the scene. You can trace its lineage yourself, if you'd like. Since then, there's been a lot of code borrowing but everyone borrows from FreeBSD and FreeBSD is far from the only OS whose code Darwin has borrowed. Using just that to say that Darwin is based on FreeBSD would make little more sense than using the same fact to claim that GNU/Linux and Windows XP are based on FreeBSD.
Referenced from the site you mention yourself is the BSD family tree.
If you had bothered to look at it, you'd have noticed that:
Darwin is based on Rhapsody, NetBSD 1.4 and FreeBSD 3.2
OS X 10.2 imported code from FreeBSD 4.4
OS X 10.3 imported code from FreeBSD 5.1
If you had ever bothered to use a FreeBSD 5.x machine for a while, and used a machine with OS X for a while from the shell, you'd have noticed how the userland is virtually identical, to a level way beyond how some linux distributions are similar..
Where OS X really did not derive from FreeBSD at all is at the kernel level and of course the gui.
Linux will always be ahead on cutting edge hardware because of the nature of the licences.
History shows that the 'always' part in there is seriously wrong..
BSD gets a driver, linux will have in after a quick port.
Linux gets a driver, BSD has to wait and re-impliment.
That is how it seems to a person who has absolutely no idea about kernels and drivers and the different BSD distributions.
First, there are quite a few BSD variations all with their own set of rules for integrating drivers, where some see no problem in using gpl code, others see no problem in using closed source drivers in cases, and yet others swear that everything must be free and open.
Second, differences between a BSD style kernel and the linux kernel are substantial enough that a 'quick port' is seldom an option for technical reasons alone.
I still happen to have an old t39m around with 2 good batteries, which I use mostly.. its simple, esp. to todays standards, but it does bluetooth and gprs, has a very good sound quality and receiption..
Almost a year ago, I got a free k300 from my provider (simlock free even), and didn't expect much of it. While as you say it doesn't seem overly sturdy, I was happily surprised by its sound quality and user interface. Its reception however is inferior to that of my old t39m, or so it seems from the number of calls it drops in slightly difficult conditions, as is its capability to roam between busy cells.
On the other hand, its gprs performance seems better and more reliable.. makes you wonder how much of this is really a matter of reception.
Allowing everyone to redistribute it would make the dream of "write once run everywhere" even more utopical. Various vendors will be blaming other vendors-supplied JREs for troubles with their applications... "Oh, no, you can't use the XYZ's JRE with out product, it is not compatible."
Yep.. like we have 15 different and incompatible perl, php, rub and python distributions from different people.. oh wait..
The fact that the current licence helped against Microsoft is no proof whatsoever of that being the only possible defense, neither does it say that if there was a different licence at the time, SUN couldn't have done something about the attempt to corrupt the standard.
Sun is right -- you want a JRE, you get it from Sun. Either in binary, if available, or in source...
No, they are as wrong as it gets, and seeing their shifting with licence terms, they know their licence is way to restrictive still, just instead of using a known working solution, they try to peal off just enough restrictions to solve the problem for the short term.
it doesn't help performance if you're trying to run all of your tools within the same app - what's the point of a multi-threaded os then?
Well.. the point of a multi-threaded os is actually to allow things like that... do many different things within the same app at the same time..
Not that I like the idea for an IDE (which is basicly a developer frontend and some compiler/validator/debugger toolchain)...
You can. You just have to pass a very vigorous compliance test. FreeBSD -- a volunteer organization -- did it, so it can not be unbearably hard.
I am pretty well aware of that they did that, and I also know that the previous time they managed that was for 1.3, running on FreeBSD 4.x
The point of that is that when you needed 1.4.x, or untill recently, 1.5.x, you were out of luck or had to build it from source, which I have done for years btw, so I quite know that it is possible also.
Since when is "building from source" a bad thing?..
But, anyway, you should stop the FUD-spreading -- not "each user of such a system". An organization can build a JDK once on a system, and let all users of all compatible systems use it.
Building from source is not a bad thing at all in many cases, and I do so all the time, but neither is creating a specific binary package together with some other specific binary packages and distribute that to an enduser who can install it in a few minutes, and potentially with your support run it. I support many such users, often small companies. Since those are not one big organisation, rather, all of them are seperate businesses and individuals, it helps exactly 0, nada that I can distribute a build I did myself within my own organisation.
Having all of them compile their own version is a situation I do not want to support and is not desired by my customers either because of the required investment in time and knowledge, not to mention the waste of energy in effectively repeating the same thing over and over.
I am not spreading fud, but you are lacking understanding and/or the ability to imagine a situation slightly different from your own obviously.. either that or you simply can't stand a critical comment about sun and/or java