Government acceptance of Open Source software isn't based alone on purchase price, of course. There are many other issues involved. One of them is training and ``ease of use''. That relates directly to the theme of the last few articles I've written in this series: BSD should be easier for end users to use. From a BSD-centric point of view, we also have competition with Linux, where people have taken different approaches to usability. The last article was about BSD on the desktop. To judge by the record number of feedback messages I got, it obviously interests a lot of people. We'll look at that first, and afterwards I'll think a bit about keeping systems up to date.
I, too, disagree with Rasterman's assessment of Linux/UNIX on the desktop, for many of the same reasons as you, and I'll add another: X was the desktop for quite some time before Microsoft and Apple come on the scene.Nahuel Greco writes:I also agree wth your assessment about why UNIX desktops aren't more prevalent. MS-Windows' singular and insular approach has dumbed-down the user base, and it's "strangle hold" on PC vendors more or less insured their position.
I don't think a "desktop distribution" would be a bad thing, but the devil lies in the details.
Does such a distribution cater to the MS literati? KDE and GNOME are trying that, and the result is inconsistant APIs (within their own products as well as crossing them) and, IMHO, way too much overhead (read: "bloat"). Or does such a distribution focus on a light- or medium-weight WM, paying little or no heed to the MS Way Of Doing Things(tm)?
Finally, I think it has to be remembered that UNIX is UNIX: Don't hide xterm! And (sorry for leading off with a conjunction) I think it has to be remembered that UNIX can/should not protect the user from himself. If the newbie is messing with stuff he really shouldn't be, well, that's his business. If I saw "Are you sure (y/n)?" littering every operation, that'd drive me away from the distribution, even if I was the newbie such a distribution would target.
I want to point that you don't mention MacOSX, I think this omittion is a BIG mistake, given that OSX is based on a BSD system and it proves that you can make UNIX totally user-friendly.
This is a valid point. My concern, though, is that MacOS X still provides the same type of visual paradigm that Microsoft does. Sure, it's different, and most people think it's better, but it's still too dependent on sign language. I must confess that my own exposure to MacOS X is minimal, and possibly I'm doing it a disservice there, but I get the impression of too many graphical gimmicks which take up screen real estate (and presumably processor time) without giving you any more functionality.
Mark Lapointe writes:
The only thing I need MS Windows for is the few games I play.. srry, linux nor BSD can really compete yet in that area, thugh there is WineX 2.1 that can d warcraft 3 n stuff, but as languages(Java,C#,something better comes I hope or java fixes itself so its not soo sluggish and a resource hog) start to become more universal the day will come when every app can run on every OS(if the developer s desires).
Agreed, games tend to work better on Microsoft. That's really an issue of the game developers, of course, but it's unlikely that it will change much in the next few years. I'd disagree, though, that approaches like C# are the way to go. Whatever the technical merits, the real issue here seems to be commercial, and I would feel very uncomfortable using development software which belongs to somebody who can modify the conditions of its use as they see fit.
Mark goes on to say:
The only ting I really need is to find a ofice site that works with M$'s crap 100%, otherwise everything would be fine. Maybe the new openoffice thingy is good enough, haven't tried it yet since I really don't handle sales anymore.
I have to disagree here. Yes, it seems that things like OpenOffice come close to Microsoft's offerings. But the thrust of my last article wasn't saying ``let's emulate Microsoft'', it was ``let's find a better way''. I think it would be fair to say that OpenOffice and other such packages don't do the job as well as the Microsoft originals, though they're certainly a good substitute until somebody invents the better way. I use StarOffice myself when I have to, but I can't say I enjoy that kind of interface.
Anthony Cordeiro writes:
You hit the nail on the head with your paragraph on BSD driving some people crazy. When everyone's saying "Hey guys, I can't figure out how to get started with email and web surfing, here," they probably have a point that needs addressing. The problem of course is that high-powered unix hackers, on average, don't care about making it easy to use. They want to make newer and better high power tools, not go back and put padding on the stuff they've done already so that the average shmoe can use it. Which is why my hat goes off to the ports maintainers: they take nifty tools (like, say, gallery) that are pretty sophisticated and require lots of configuration and work to install and get running, and make them easy to use for someone like me: a technically savvy fellow that isn't as interested in spending time tinkering with something as he is just installing and using it. Now we need to extend that out further to the non-technical user.So, IMO, the trick isn't so much finding product managers who understand, but finding coders that are going to be interested and motivated to actually do the work, to spend the time on something that they themselves don't need.
Most people in those days were luckier installing UNIX System V on PCs, but it was still a pain compared to current installation processes. They had to work their way through hundreds of floppy disks and a maze of twisty little authentication keys, all different. By comparison, BSD/386's installation, from a single tape and without any authentication keys, was luxury.
Things changed, of course. New releases came, and over the course of a few years I migrated to FreeBSD. More new releases came, old configuration files disappeared, new ones came. Asynchronously to the releases, newer versions of ports appeared. Compatibility became a significant issue. Round about 2000, I discovered that my FreeBSD system still had a number of binaries from version 1.0 (anno 1993) in /usr/local/bin. They hadn't been replaced because the names had changed.
The files in /etc were a special case. Many of them defined the system configuration, so I couldn't just throw them out and replace them. The FreeBSD build process has a simple solution to the problem: it doesn't install the files in /etc. I didn't even notice that my regular system upgrades weren't overwriting them. Many of them were out of date, but things ran pretty well for a surprising length of time. Then I found that I could no longer run NFS, that remote authentication wasn't working properly, and that my changes to sendmail.cf didn't seem to be working: the file had been moved, but I hadn't noticed.
``Well, do a proper installation'' is the obvious answer. But what is the proper installation? I'm currently in the last throes of updating my book ``The Complete FreeBSD'', which should be on the bookshelves in the next few months. What ``proper installation'' do I tell the readers? This should be something of the form:
# cd /usr/src # make world # make buildkernel # make installkernel
The trouble is that that doesn't upgrade the configuration files. In FreeBSD, you do that with mergemaster. But mergemaster has a frightening number of options, and it frequently requires you to make decisions.
For mechanical upgrades, decisions are bad. What if something goes wrong? You send a message to the FreeBSD-questions mailing list (in this case) saying ``I tried to upgrade from 4.3 to 4.7, and now I can't log in''. Everything looks as if you've done the right thing, except that you've ended up with the wrong password file. How did it happen? Who knows? ``It works for me''.
This is only one example. I'm currently trying to install NetBSD 1.6, which I have got from CVS. The system I'm building it on runs NetBSD 1.5, and I can no longer just do a make build, because make has changed. Instead, it seems that I have to run build.sh, which was originally intended for non-NetBSD cross builds. That builds the system without any problems, but it takes more than a cursory examination of the supplied documentation to find out how to install it. Yes, I'm experienced enough to find out a way, but it might be the wrong way, and again it's not repeatable.
The situation is similar with ports. Here you have the added problem of dependencies, which could be conflicting. It's not difficult to handle, but it requires more work than many people are prepared to expend. In particular, it appears very difficult to people who are moving from Linux to BSD. They're used to apt-get, rpm and other such programs, and though I'm personally convinced that the Ports Collection is a better approach, it's not easy to convince them: there are doubtless advantages to the Linux approaches, and until we can match the advantages, there will be people who look past them and consider BSD approach to be inferior.
I've frequently been taken to task by the Darwin people for not counting Darwin in these discussions. See above for an example. Yes, I agree, Darwin is also BSD, but it's not what the typical Mac user sees: he sees OS/X, which differs from the other BSDs in a number of ways. Certainly in the context of this discussion, it would be crazy to suggest that Darwin become like the other BSDs, or vice-versa.
We already have some contacts between the individual teams, and many developers who have commit access to more than one of the projects. What we don't have is anybody responsible for ensuring a common look and feel, to address the issues that Anthony Cordeiro raises above: BSD for real people, not for developers. I think we need exactly that. I'd be interested in feedback. I'll publish the more interesting replies; if you don't want your reply published, please let me know.