1. Is this an appropriate GUI system to be using in such memory-deficient devices? I believe we we find out soon...
Yes. If you think specifically of KDE/QT - check out what runs on zaurus, ipaq, and whatnot, but you have to remember that this is Qtopia, not the same thing you have as a kde desktop, although resourcewise, KDE is becoming lighter and lighter...
Also, they speak about a rendering engine, not a GUI/OS solution (and afaik Nokia did a browser using khtml but with GTK UI).
Wow! Is that all it takes to get a +5 Insightful now? - I could ask the same of your own post, because some parts are factually wrong.
Now this is where Ports and Portage, IMHO, really suck. When I uninstall a package from my system I want it gone. apt-get remove --purge and a properly packaged deb will do that for you. Ports and Portage will leave "package cruft" on your system.
I don't know about portage, but ports don't leave cruft behind. When you remove a port, you effectively remove a package. FreeBSD does not differentiate between ports and package deinstallation. Portinstall/upgrade tools, share the same command for package removal, whether it was built from ports or installed as a binary package. pkg_deinstall -rd fooo* will recursively deinstall every fooo* package and those packages that depend on it. Not only that, but it will remove the directory as well - unless you modified some files by hand, in which case if will tell you which files it couldn't remove (because they didn't match original checksum). Ports leaves "cruft behind" is a myth - or sounds to me like superstition or something. ALL installed files by a port or package are recorded in the plist, and all those files will be removed on deinstall - unless you changed them manually, in which case you will notice (and probably don't want to delete them anyway before making a backup).
Ports (and Portage) does Rock, but only if all you ever care about is package installation and not package management (package building, installation and uninstallation).
WTF? The reason I use ports is because I care about package management. I have to take care of a small lab with old computers. 3 of them run freebsd+blackbox+opera/gaim/irc combo (and a simplified menu so all can use it). What makes the whole setting really nice is that I can compile every installed package (there aren't that many - ~ 110) optimized for that hardware on my home puter. Than I can point portupgrade -PP to my ftp repo, and don't have to worry about dependencies and whatnot: everything will be upgraded/installed in the right order (and removed if I wish to). Yes, this is possible with deb and rpm as well, it is just not that easy. Forgot putting a required package in the repo? You can create binary packages with pkg_create -b pkgname from a package installed on your system. It doesn't matter if it was installed from source using ports or from a package. Package management knows of every file belonging to that package and the proper paths, and it will create a binary package for you, which will similar to any.deb: it will register all the required dependencies as well (unlike slack.tgz). Again, how could you do that if package management would not accurately keep track of everything? In other words - you pull this "cruft" stuff out of your ass (don't know about gentoo though) - ports doesn't leave any cruft behind (no more than apt does).
When will apt finally replace/usr/ports in FreeBSD?
Hopefully never! I really really hope that it doesn't. Why? Because we already have package management - think of ports as a bonus, where you can dynamically (and very easyliy) configure dependencies: with an mplayer.deb, you don't know wheter it was compiled with x264 support or not - in ports, you just put one statement in pkgtools.conf, and mplayer will always compile with x264 support. Otherwise, for all intents and purposes, the various pkg_ tools work just like apt. Or you can instruct portupgrade to work like apt (portinstall -PP mplayer = apt-get install mplayer).
So what you suggest as an "improvement" is really taking away the reallycool ports system...
So, dont rail about the software, rail about patents - that is an entirely different matter. Basically, you cant write anything more complex than Hello World, without violating one software patent or another. Im absolutely against selectively disregarding patented code, just because the patent is more visible. If you look at the usual pattern of patent lawsuit, a small company that we never heard of comes up with ridiculous claims and sues $Big_company for money.
Besides, mp3 is patented (and no one stops using it), mpeg-4 is patented (much in the same way as h.264) and we use XVID, FFMPEG/LIBAVCODEC (and divix! - they dont own the patents actually) - so why, should we bitch about the x264 codec (a gpl implementation of h.264)? We should bitch about software patents in general, while we still can (here in the EU)... Also, if you actually read about the licensensing terms, youll see that free implementations are absolutely allowed. You must start paying above a certain number of sold items containing the patented technology. Again, this is similar to mp3. Commercial vendors selling products containing mp3 codecs have to pay. The LAME project does not. The reason why certain distroes dont include mp3 decoders is because it might be that more than 100.000 users download it, and that may count - especially if that vendor sells the distribution as well - as selling product containing the patented algorythm.
"WMV (VC-1) will be dead along with H.264, which is already the primary codec for Blu-ray movies (Sony is already threatening X-Box 360's streaming movie capabilities thanks to Blue-ray, thereby making X-Box 360 useless since it has no Blu-ray or HD-DVD drive)."
I always see this kind of stuff recurring here on./ about H.264. H.264 is not tied to blue-ray, hddvd or anything. It is a codec. You can put h.264 encoded movies on anything you want. I also think that video encoding is one of the few areas where competition works the right way: usually the best implementation wins (Now 50% or more of movies on various p2p networks uses XVID, the rest varies between divx, ffmpeg, the occasional wmv, etc.). To be more specific, h.264 is a new standard, just like mpeg-4 was (actually, h.264 is mpeg-4 part 10). There were various implementations of the mpeg-4 standard: opendivx, which went closed source with divx 4 and began to suck, so most still used divx 3 until xvid matured, and divx begin to suck less (but it still sucks at 6.0 compared to free alternatives). The same way, there are various implentations of h.264, one of which is GPL (x264), another one is developed by NERO (and it is one of the best), and yet another one is developed by APPLE (which sucks the most, because it lacks most of the features that make h.264 the best codec around). So h.264 is not going anywhere - it is the most advanced video codec in existence (you can achieve the same quality as with mpeg-4 spending 10-15% less bits!).
The point is, and this is not specific to FreeBSD, that there are some really innovative experiments going in one bsd flavor or another. Dragonfly comes to mind - some new concepts in computer science comes from its development.
Another example (now from FreeBSD) is their support for multiple threading libraries, like libthr (1:1 - like in linux) and libkse (kernel scheduling entities), which implements M:N threading, that on paper is supposed to be a superior impementation, but it hasn't been implemented previously (afaik, SUN wanted to do it in Solaris, but later went with 1:1). See this and this posts by one of their kernel developers. Quote: "Hopefully this makes a good platform for people to do thread research.." Now that is what "academic spirit" is all about.
Need I mention OpenBSD's innovations in the field of security, or NetBSD's in portability (and their driver infrastucture)?
Parent post is not offtopic - in fact, it is right on target: there is no linux vs. bsd debate, except here on slashdot (and that's the point Scott Long makes, except for the slashdot part). That is my experience as well. I came to bsd from a linux background (mandrake), and I only met friendly people at bsdforums.org. Friendly as in not trying to convince you to use bsd instead of linux at all cost. In fact, I read good reviews of various linux distroes on bsdforums. Generally speaking, bsd users (and I think bsdforums is a good representation of the userbase) are basically friendly towards linux - so don't let./ trolls convince you otherwise (or journalists, who like this kind of x vs. y stuff because, like all controversies, they make better headlines).
I agree - with one addition: I had nothing but good experience with FreeBSD (the 5.x line) on the desktop. Everything works as expected, packages/ports are up to date, kde performace is great, what else needs to be said?
The day to day tasks I use FreeBSD for include text editing, watching tv, encoding video, browsing the net, and occasionally playing some games (wesnoth!), in other words, the usual stuff. Let's take these one by one:
Text editing: OpenOffice.org support is excellent. We had always the latest builds not only in ports, but as packages from goodday-net. What's more, not only english builds, but all language packs. Of course, I like to build these oo.o myself, so I switched from latest snapshots (all of which built fine) to beta and I'm now building rc1 (with KDE support and all).
multimedia: mplayer of course. H.264 being the next standard (for future dvds) and all, I began to use it instead of mpeg-4 (ffmpeg or xvid). Downside is that it is painfully slow to encode, but still, it's the future. In the case of rapidly developing encoders like h.264 (and its opensource implentation, x264) it is important to have the latest and greatest. Right now, I have x264-0.0.20051004 (yesterday's snapshot) installed:)
games: the number of games available in ports is impressive, but as usual with opensource games, few of them are impressive. Luckily, the important ones (for me at least) are also always up to date, like wesnoth.
So I'm eagerly waiting for 6.0 - by all accounts it's gonna be great!
One of the main problems with what you wrote is that it is really really difficult to tell who is to blame for those crashes. Very few linux distributions ship unmodified mplayer - and sometimes one customization or another will be the cause of bugs, and neither kde, nor mplayer developers can be responsilbe for those. Package maintainers on the other hand... Also, mplayer depends on a lot of supporting libraries, and depending on your needs, the problem might lie in one of those (x264, xvid, live.com, realplayer, etc.)
I only say this because mplayer on my FreeBSD 5-STABLE desktop works flawlessly. I know how frustrating is when someone comes up with a "works perfectly on my install" kinda reply, but you need to supply more info. Is mplayer buggy on Debian Linux? SuSe? Fedora? All of those? (I doubt it!). Solution is to find a distro that is most suitable for desktop use. There are a lot of problems with our current concepts of "Desktop friendly Linux." We tend to think of Mandrake, Ubuntu, SuSE and others that offer easy installation and GUI configuration tools. But whether or not a distro is desktop friendly depends more on the quality of the packages they maintain. Writing GUI tools or simplifying things is really not that difficult. PC-BSD comes to mind, that has 1/10 of the resources that popular Desktop Linux distroes have at their disposal, yet arguably, in about a year, they become as close to a user friendly *nix like desktop as any of the big names.
Actually, that is why the KDE project is exemplary, and is one of the best managed open source projects out there. They do things in the right order: they make sure that the supporting infrastructure (QT4 in this case) is solid. Then they build developer-friendly tools (and artists/usability guys and girls friendly) like klik. They do workshops all around the world now (New Delhi is the next station) - familiarizing developers with their tools (oh, and don't forget the excellent documentation of QT). And once that infrastructure is in place, maintainability of the code base is assured. That is how a user friendly linux distro should be built. Take a small but solid base (slackware would be a good candidate) and make sure every single package works as expected (that is not the case with Debian unfortunately). Build the whole damn thing slowly from the ground up, make it easy, make it low-barrier for future contributors (Document every aspect!). Organize a quality assurance team! And as a final step, build a user friendly installer/gui config tools.
Again, look at pc-bsd for an example of this. What they inherit from FreeBSD is a sense of integration. PC-BSD is a misnomer - it should be named KDE/PC-BSD (just like gnu linux). They use every configuration tool that is already available in kcontrolcenter. What is missing is written in QT (including the installer). In mandrake (as far as memory servers) you could manage users in both kcontrolcenter and mandrake's own control center - which is understandable as long as desktop linux efforts are shackled by the perception that they must be desktop agnostic. That is why Ubuntu was a great success imho (of course, I know that now we have Kubuntu).
Anyhow, my choice of FreeBSD is based on my personal preferences - but what primarily drove me to it is the problem you describe. What should a non-techie user do when mplayer crashes? Complain to... whom? Finally, I found myself switching distroes (rh 7.3 >> Mandrake 9.0/9.1 >> Debian Woody >> Unstable - where half the packages had some quirks) until I realized I was looking for exactly what FreeBSD had to offer. My current problem with linux distroes is that I can't find any that is relatively flawless or comes close to Free~'s quality. Well, maybe slackware - or arch (I have the former installed, and I have heard good things about the latter). But as long as there is no distro that has quality and simplicity (that is where slackware is excellent) as their first and foremost
I understand that rootkits are a problem but once someone has root you're out of luck either way...
Unless you run services in jails... of course, if there is some serious kernel level vulnerability around the jail syscall, than you are screwed - but that doesn't happen too often:)
What about securelevels? It was a long time ago since I used it, but mandrake had something like that. I assumed that it was similar to FreeBSD's securelevels, where securelevel 1 means:
1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted file systems,/dev/mem, /dev/kmem and/dev/io (if your platform has it) may not be opened for writing; kernel modules (see kld(4)) may not be loaded or unloaded.
See man (8) securelevel
This way you don't need to recompile the kernel if find out later that you need a module afterall.
More info here. Actually, I did a few rips with x264, and I'm not impressed that much. It is better somewhat than xvid or ffmpeg, but that comes at a cost: on a 2800+ Athlon XP encoding was rather slow: 2fps/sec. Of course, I used high quality settings:
frameref=6, deblock, deblockalpha=0, deblockbeta=0, cabac, me=3, 4x4mv, b8x8mv, subq=5, bframes=3, b_pyramid, weight_b, direct_pred=2, chroma_me. Decoding also needs a lot more cpu cycles (2-3x) than mpeg-4.
H.264 was NOT developed by Apple - it is a new standard that will probably become THE standard for DVD streams in the (near) future. H.264 is an ISO standard - the precise name is mpeg-4 part 10, but you will find many people referring to it as avc or mpeg-5/avc. There are various implementations of this standard. One implementation is done by apple in Quicktime - and I have to add that it is not the best one - it supports only 1 (consecutive) bframes, no CABAC, no Loop and no Weighted Prediction). To put it bluntly: apple's implementation sucks. A better implementation is x264, which is open source (gpl I think), supports almost all the features, and it is in heavy development. Another very good h.264 codec is Nero Digital AVC, which is considered the best (alongside x264).
"I understand your worries, but fortunately I am able to put your mind to rest: KOffice is in fact not related to StarOffice or OpenOffice. It is a completely separate product, and a very fine one at that."
"It's no wonder that DragonFlyBSD is now becoming the premiere production BSD.." Dragonfly is nowhere near production quality yet. It may or may not be better than FreeBSD in the future, but your fanatism (earning you +5 insightful apparently) blinds has blinded you to the fact that not even its developers recommended for production use.
"Like it or not, DragonFlyBSD is bound to take the role FreeBSD has.." Seeing how Dragonfly has a different set of goals than FreeBSD, I cannot see how it would take FreeBSD's role... provided it becomes better, which is not proven yet! This is like saying that Open~ or Net~ will take FreeBSD's role in the future! It is stupid.:
"Meanwhile, systems like FreeBSD which have failed to make the transition to a far more threaded kernel design will lose the performance race." Just as silly as the rest - FreeBSD 5/6 now shows very good performance on MP systems. Last time a more or less objective comparison was made, FreeBSD 5.x proved to be more scalable than 4.x - and the difference by which linux won was quite negligible, if you read the whole article. So, what you wrote is one of the silliest rants I have recently read.
I'm in a similar situation. I'm doing my PhD in literature and philosophy - wrote my MA thesis on Freud and the Uncanny, and my dissertation would be on alternative economic models in utopian/science fiction and in the high tech industry (gift-economy for the geeks in the humanities - someone must tell them what's going on in their language).
Anyhow, with my MA and doctorate (which I'll hopefully get in two years) I will be qualified to teach at a university. Only problem is that they don't throw tenures at you these days. I calculate 5% chance of getting a job in my area of expertise, which - and I don't mean to brag - covers a fairly broad area compared to other students: classic literature (from the Bronte sisters through Balzac to Thomas Pynchon), philosophy (from Kant and Hegel to Jacques Derrida and Michel Foucault), feminism and gender studies, and whatnot. So, it was this year that I began to face reality and recognize that I will probably have a (much) greater chance to find job as an *nix administrator.
So here is where I stand now: I switched to linux 4 years ago and to FreeBSD two years ago. I gradueally learned how to secure a FreeBSD system (using pf/ipfw), some basic networking stuff, some very basic scripting, ~ 10 commands I need to set up mysql and manage its accounts - just enough so I can use some CMS. I have a part time job working for some folks at the university, maintaining their site (which includes everything: the underlying os - FreeBSD, translating geeklog into hungarian, writing documentation for non technical stuff to handle moderation, well, every apsect of running this site, and another hobby site. I recognize that this knowledge is almost nothing for a serious job application in the field. So in the upcoming two years, I must set aside time from working on my dissertation to learn more. I just bought a book on introduction to php and mysql, with lots of examples. Knowing php and mysql is a must. Javascript comes next, along with a good working knowlede of a scripting language (most likely python or pearl). Along with these I need to learn setting up more complicated (not just NAT and basic load balancing via pf) networks, vlans, etc.
This is both a fortunate and unfortunate. If I manage to get a job that has something to do with *nix, I would be happy. But then, there are those 7 years I spent learning and thinking about literature and philosophy. I don't regret it, I enjoyed it, and would enjoy working with it, but if those years were spent learning programming, then I would be better off now. On the other hand, I know that I would not be the same person, and I would not know what I have missed. And there is a chance that I will be able to return to my "official" field. There are so many things I want to do and write (I have already something for another book if I finish my dissertation) - so maybe, I will be able to do it in my free time, while earning my living working with unix. Anyhow, the next 3 years will be probably the most difficult years in my life, for I'll have a double workload: finishing my dissertation in two years (that basically means writing a book that will be accepted for publication) + acquiring an in-depth knowledge of everything that a good system administrator needs. And I have no choice in this: no matter how good my dissertation will be, it won't be enough for a tenure, because the staff at our univ. is young and talented, and there won't be any job openings in the forseeable future. And I can't think of anything else that I might somewhat enjoy than working with linux/unix.
You might want to use some CMS - take a look at opensourcecms.org, where you can try out some.
My favorite is geeklog, which has medium complexity, and it is easy to develop your own plugins for it. It has a good user management interface, and you can do almost anything with the built in static page plugin (a misnomer, for the pages are just as dynamic as the rest), like running php scripts for instance. Also, geeklog is written with security as a priority (even though you need register globals on). An example for a geeklog site is groklaw.net - a pretty good reference, no?
My own tftpanel.hu runs on geeklog, as well as another site I maintain. Hosting requirements are pretty good for geeklog: mysql (if you have access to only one database, that's fine) and php support, plus works on windows as well.
There are lots of CMS out there, ranging from pivot (simple) to typo3 (overkill) - so you might look at them at opensourcecms.org before you decide.
And while we are at it, something like atacontrol - to be able to hotswap ide drives. I know about hdparm, but last time I tried it (it was more than a year ago though) it didn't work very well.
There is something seriously screwed with that 31ms startup time of Word. Office XP starts up in 2-3 seconds (athlon xp 2400+), a few seconds more on slower (celeron 1600) machines. That's not the case with oo.o.
Perfromance while running oo.o is good, but not better than Office XP. It becomes better in oo.o-2.0 (or 1.9m109 I'm running now) if you compile it with support for native widgets: in my case, support for KDE. That doesn't help the startup time, but it helps speed once oo is up and running. Not that 1.1.x was too slow, as I said, speed was OK, but still, when you opened the help browser it wasn't instantaneous (nor was navigating it). It wasn't more than ~1 sec, but actually you can feel ~1 secs if you click through fast and expect instant results. Instant results is what I get with oo.o compiled for KDE: as soon as I click help, or tools --> options - the new window instantly appears, and navigating through the help system is just as fast. I think that it is faster than Office XP on the same machine - but not by much. But what the article claims is absolute nonsense.
I have no reason to disbelieve the author's experience, but this is not "normal" operation. In other words, he might have measured those times, but something must be seriously borked about his Office Install (or windows install, or both). I have installed Office XP on all machines here in the small comp. lab I administer that run winxp. The machine's specs range from 700 Mhz Durons to 2.4Mhz Pentiums, with 256Mb Rams - and OfficeXP wasn't as slow as author claims even on the Duron.
ULE works for me just fine. What's your setup? Because as far as I know, stability issues come up in smp environments with ULE. On single processors it should work - and it works very nicely: desktop interactivity remains top notch when using ULE even while doing CPU intensive tasks (like I do right now, compiling oo.o-2) - meaning smooth playback of movies with mplayer and all. See my kernel config here.
On a sidenote: I just finished compiling openoffice1.9m107 a few days ago (now that the port is updated to m109, I'm there compiling again) - with KDE support. Running it under KDE with native widget support is simply amazing speedwise. Startup times don't change much, however, opening various dialogues (options for instance), the help, etc. is instantaneous - just like konqi when preloaded. Not that it was very slow before, but still, once oo starts up, it is lightning fast using the native widgets!
I uploaded the m107 package to my ftp server (see link in my signature) - you may try pkg_adding it, but read the README.txt before that. And while we are at it, one majore advantage of FreeBSD (that a review should include) is its excellent software support. I can't think of a linux distro with such great support for oo.o as FreeBSD (not by default anyway). The latest binaries distributed by openoffice.org are at m104, and I couldn't find (on google) the source downloads for m107, much less m109 today, except at good-day.net of course, which is pretty much overloaded recently, because ports uses it for source downloads, and it also distributes precompiled binaries: m107 builds are ready with all language packs! So, if you want only the english (or KDE) version, use this link to get it. I just began compiling m109 an hour ago, so in a day it will also be uploaded.
Don't think using the patches provided by APPLE was a simple copy and paste job or in any way convenient. It was probably more convenient than rewriting them from scratch though... but we don't know how much easier it was.
Slashdot Mirror
Yes. If you think specifically of KDE/QT - check out what runs on zaurus, ipaq, and whatnot, but you have to remember that this is Qtopia, not the same thing you have as a kde desktop, although resourcewise, KDE is becoming lighter and lighter...
Also, they speak about a rendering engine, not a GUI/OS solution (and afaik Nokia did a browser using khtml but with GTK UI).
Now this is where Ports and Portage, IMHO, really suck. When I uninstall a package from my system I want it gone. apt-get remove --purge and a properly packaged deb will do that for you. Ports and Portage will leave "package cruft" on your system.
I don't know about portage, but ports don't leave cruft behind. When you remove a port, you effectively remove a package. FreeBSD does not differentiate between ports and package deinstallation. Portinstall/upgrade tools, share the same command for package removal, whether it was built from ports or installed as a binary package. pkg_deinstall -rd fooo* will recursively deinstall every fooo* package and those packages that depend on it. Not only that, but it will remove the directory as well - unless you modified some files by hand, in which case if will tell you which files it couldn't remove (because they didn't match original checksum). Ports leaves "cruft behind" is a myth - or sounds to me like superstition or something. ALL installed files by a port or package are recorded in the plist, and all those files will be removed on deinstall - unless you changed them manually, in which case you will notice (and probably don't want to delete them anyway before making a backup).
Ports (and Portage) does Rock, but only if all you ever care about is package installation and not package management (package building, installation and uninstallation).
WTF? The reason I use ports is because I care about package management. I have to take care of a small lab with old computers. 3 of them run freebsd+blackbox+opera/gaim/irc combo (and a simplified menu so all can use it). What makes the whole setting really nice is that I can compile every installed package (there aren't that many - ~ 110) optimized for that hardware on my home puter. Than I can point portupgrade -PP to my ftp repo, and don't have to worry about dependencies and whatnot: everything will be upgraded/installed in the right order (and removed if I wish to). Yes, this is possible with deb and rpm as well, it is just not that easy. Forgot putting a required package in the repo? You can create binary packages with pkg_create -b pkgname from a package installed on your system. It doesn't matter if it was installed from source using ports or from a package. Package management knows of every file belonging to that package and the proper paths, and it will create a binary package for you, which will similar to any .deb: it will register all the required dependencies as well (unlike slack .tgz). Again, how could you do that if package management would not accurately keep track of everything? In other words - you pull this "cruft" stuff out of your ass (don't know about gentoo though) - ports doesn't leave any cruft behind (no more than apt does).
Hopefully never! I really really hope that it doesn't. Why? Because we already have package management - think of ports as a bonus, where you can dynamically (and very easyliy) configure dependencies: with an mplayer.deb, you don't know wheter it was compiled with x264 support or not - in ports, you just put one statement in pkgtools.conf, and mplayer will always compile with x264 support. Otherwise, for all intents and purposes, the various pkg_ tools work just like apt. Or you can instruct portupgrade to work like apt (portinstall -PP mplayer = apt-get install mplayer).
So what you suggest as an "improvement" is really taking away the reallycool ports system ...
Besides, mp3 is patented (and no one stops using it), mpeg-4 is patented (much in the same way as h.264) and we use XVID, FFMPEG/LIBAVCODEC (and divix! - they dont own the patents actually) - so why, should we bitch about the x264 codec (a gpl implementation of h.264)? We should bitch about software patents in general, while we still can (here in the EU)... Also, if you actually read about the licensensing terms, youll see that free implementations are absolutely allowed. You must start paying above a certain number of sold items containing the patented technology. Again, this is similar to mp3. Commercial vendors selling products containing mp3 codecs have to pay. The LAME project does not. The reason why certain distroes dont include mp3 decoders is because it might be that more than 100.000 users download it, and that may count - especially if that vendor sells the distribution as well - as selling product containing the patented algorythm.
How do you do that? I tried using the volume here, but I didntt notice any positive effect on my income (but at least my neighbours are pissed).
I always see this kind of stuff recurring here on ./ about H.264. H.264 is not tied to blue-ray, hddvd or anything. It is a codec. You can put h.264 encoded movies on anything you want. I also think that video encoding is one of the few areas where competition works the right way: usually the best implementation wins (Now 50% or more of movies on various p2p networks uses XVID, the rest varies between divx, ffmpeg, the occasional wmv, etc.). To be more specific, h.264 is a new standard, just like mpeg-4 was (actually, h.264 is mpeg-4 part 10). There were various implementations of the mpeg-4 standard: opendivx, which went closed source with divx 4 and began to suck, so most still used divx 3 until xvid matured, and divx begin to suck less (but it still sucks at 6.0 compared to free alternatives). The same way, there are various implentations of h.264, one of which is GPL (x264), another one is developed by NERO (and it is one of the best), and yet another one is developed by APPLE (which sucks the most, because it lacks most of the features that make h.264 the best codec around). So h.264 is not going anywhere - it is the most advanced video codec in existence (you can achieve the same quality as with mpeg-4 spending 10-15% less bits!).
The point is, and this is not specific to FreeBSD, that there are some really innovative experiments going in one bsd flavor or another. Dragonfly comes to mind - some new concepts in computer science comes from its development.
Another example (now from FreeBSD) is their support for multiple threading libraries, like libthr (1:1 - like in linux) and libkse (kernel scheduling entities), which implements M:N threading, that on paper is supposed to be a superior impementation, but it hasn't been implemented previously (afaik, SUN wanted to do it in Solaris, but later went with 1:1). See this and this posts by one of their kernel developers. Quote: "Hopefully this makes a good platform for people to do thread research.." Now that is what "academic spirit" is all about.
Need I mention OpenBSD's innovations in the field of security, or NetBSD's in portability (and their driver infrastucture)?
Parent post is not offtopic - in fact, it is right on target: there is no linux vs. bsd debate, except here on slashdot (and that's the point Scott Long makes, except for the slashdot part). That is my experience as well. I came to bsd from a linux background (mandrake), and I only met friendly people at bsdforums.org. Friendly as in not trying to convince you to use bsd instead of linux at all cost. In fact, I read good reviews of various linux distroes on bsdforums. Generally speaking, bsd users (and I think bsdforums is a good representation of the userbase) are basically friendly towards linux - so don't let ./ trolls convince you otherwise (or journalists, who like this kind of x vs. y stuff because, like all controversies, they make better headlines).
The day to day tasks I use FreeBSD for include text editing, watching tv, encoding video, browsing the net, and occasionally playing some games (wesnoth!), in other words, the usual stuff. Let's take these one by one:
So I'm eagerly waiting for 6.0 - by all accounts it's gonna be great!
I only say this because mplayer on my FreeBSD 5-STABLE desktop works flawlessly. I know how frustrating is when someone comes up with a "works perfectly on my install" kinda reply, but you need to supply more info. Is mplayer buggy on Debian Linux? SuSe? Fedora? All of those? (I doubt it!). Solution is to find a distro that is most suitable for desktop use. There are a lot of problems with our current concepts of "Desktop friendly Linux." We tend to think of Mandrake, Ubuntu, SuSE and others that offer easy installation and GUI configuration tools. But whether or not a distro is desktop friendly depends more on the quality of the packages they maintain. Writing GUI tools or simplifying things is really not that difficult. PC-BSD comes to mind, that has 1/10 of the resources that popular Desktop Linux distroes have at their disposal, yet arguably, in about a year, they become as close to a user friendly *nix like desktop as any of the big names.
Actually, that is why the KDE project is exemplary, and is one of the best managed open source projects out there. They do things in the right order: they make sure that the supporting infrastructure (QT4 in this case) is solid. Then they build developer-friendly tools (and artists/usability guys and girls friendly) like klik. They do workshops all around the world now (New Delhi is the next station) - familiarizing developers with their tools (oh, and don't forget the excellent documentation of QT). And once that infrastructure is in place, maintainability of the code base is assured. That is how a user friendly linux distro should be built. Take a small but solid base (slackware would be a good candidate) and make sure every single package works as expected (that is not the case with Debian unfortunately). Build the whole damn thing slowly from the ground up, make it easy, make it low-barrier for future contributors (Document every aspect!). Organize a quality assurance team! And as a final step, build a user friendly installer/gui config tools.
Again, look at pc-bsd for an example of this. What they inherit from FreeBSD is a sense of integration. PC-BSD is a misnomer - it should be named KDE/PC-BSD (just like gnu linux). They use every configuration tool that is already available in kcontrolcenter. What is missing is written in QT (including the installer). In mandrake (as far as memory servers) you could manage users in both kcontrolcenter and mandrake's own control center - which is understandable as long as desktop linux efforts are shackled by the perception that they must be desktop agnostic. That is why Ubuntu was a great success imho (of course, I know that now we have Kubuntu).
Anyhow, my choice of FreeBSD is based on my personal preferences - but what primarily drove me to it is the problem you describe. What should a non-techie user do when mplayer crashes? Complain to ... whom? Finally, I found myself switching distroes (rh 7.3 >> Mandrake 9.0/9.1 >> Debian Woody >> Unstable - where half the packages had some quirks) until I realized I was looking for exactly what FreeBSD had to offer. My current problem with linux distroes is that I can't find any that is relatively flawless or comes close to Free~'s quality. Well, maybe slackware - or arch (I have the former installed, and I have heard good things about the latter). But as long as there is no distro that has quality and simplicity (that is where slackware is excellent) as their first and foremost
Unless you run services in jails ... of course, if there is some serious kernel level vulnerability around the jail syscall, than you are screwed - but that doesn't happen too often :)
This way you don't need to recompile the kernel if find out later that you need a module afterall.
More info here. Actually, I did a few rips with x264, and I'm not impressed that much. It is better somewhat than xvid or ffmpeg, but that comes at a cost: on a 2800+ Athlon XP encoding was rather slow: 2fps/sec. Of course, I used high quality settings: frameref=6, deblock, deblockalpha=0, deblockbeta=0, cabac, me=3, 4x4mv, b8x8mv, subq=5, bframes=3, b_pyramid, weight_b, direct_pred=2, chroma_me. Decoding also needs a lot more cpu cycles (2-3x) than mpeg-4.
H.264 was NOT developed by Apple - it is a new standard that will probably become THE standard for DVD streams in the (near) future. H.264 is an ISO standard - the precise name is mpeg-4 part 10, but you will find many people referring to it as avc or mpeg-5/avc. There are various implementations of this standard. One implementation is done by apple in Quicktime - and I have to add that it is not the best one - it supports only 1 (consecutive) bframes, no CABAC, no Loop and no Weighted Prediction). To put it bluntly: apple's implementation sucks. A better implementation is x264, which is open source (gpl I think), supports almost all the features, and it is in heavy development. Another very good h.264 codec is Nero Digital AVC, which is considered the best (alongside x264).
"I understand your worries, but fortunately I am able to put your mind to rest: KOffice is in fact not related to StarOffice or OpenOffice. It is a completely separate product, and a very fine one at that."
"It's no wonder that DragonFlyBSD is now becoming the premiere production BSD.." Dragonfly is nowhere near production quality yet. It may or may not be better than FreeBSD in the future, but your fanatism (earning you +5 insightful apparently) blinds has blinded you to the fact that not even its developers recommended for production use.
"Like it or not, DragonFlyBSD is bound to take the role FreeBSD has.." Seeing how Dragonfly has a different set of goals than FreeBSD, I cannot see how it would take FreeBSD's role ... provided it becomes better, which is not proven yet! This is like saying that Open~ or Net~ will take FreeBSD's role in the future! It is stupid.:
"Meanwhile, systems like FreeBSD which have failed to make the transition to a far more threaded kernel design will lose the performance race." Just as silly as the rest - FreeBSD 5/6 now shows very good performance on MP systems. Last time a more or less objective comparison was made, FreeBSD 5.x proved to be more scalable than 4.x - and the difference by which linux won was quite negligible, if you read the whole article. So, what you wrote is one of the silliest rants I have recently read.
Anyhow, with my MA and doctorate (which I'll hopefully get in two years) I will be qualified to teach at a university. Only problem is that they don't throw tenures at you these days. I calculate 5% chance of getting a job in my area of expertise, which - and I don't mean to brag - covers a fairly broad area compared to other students: classic literature (from the Bronte sisters through Balzac to Thomas Pynchon), philosophy (from Kant and Hegel to Jacques Derrida and Michel Foucault), feminism and gender studies, and whatnot. So, it was this year that I began to face reality and recognize that I will probably have a (much) greater chance to find job as an *nix administrator.
So here is where I stand now: I switched to linux 4 years ago and to FreeBSD two years ago. I gradueally learned how to secure a FreeBSD system (using pf/ipfw), some basic networking stuff, some very basic scripting, ~ 10 commands I need to set up mysql and manage its accounts - just enough so I can use some CMS. I have a part time job working for some folks at the university, maintaining their site (which includes everything: the underlying os - FreeBSD, translating geeklog into hungarian, writing documentation for non technical stuff to handle moderation, well, every apsect of running this site, and another hobby site. I recognize that this knowledge is almost nothing for a serious job application in the field. So in the upcoming two years, I must set aside time from working on my dissertation to learn more. I just bought a book on introduction to php and mysql, with lots of examples. Knowing php and mysql is a must. Javascript comes next, along with a good working knowlede of a scripting language (most likely python or pearl). Along with these I need to learn setting up more complicated (not just NAT and basic load balancing via pf) networks, vlans, etc.
This is both a fortunate and unfortunate. If I manage to get a job that has something to do with *nix, I would be happy. But then, there are those 7 years I spent learning and thinking about literature and philosophy. I don't regret it, I enjoyed it, and would enjoy working with it, but if those years were spent learning programming, then I would be better off now. On the other hand, I know that I would not be the same person, and I would not know what I have missed. And there is a chance that I will be able to return to my "official" field. There are so many things I want to do and write (I have already something for another book if I finish my dissertation) - so maybe, I will be able to do it in my free time, while earning my living working with unix. Anyhow, the next 3 years will be probably the most difficult years in my life, for I'll have a double workload: finishing my dissertation in two years (that basically means writing a book that will be accepted for publication) + acquiring an in-depth knowledge of everything that a good system administrator needs. And I have no choice in this: no matter how good my dissertation will be, it won't be enough for a tenure, because the staff at our univ. is young and talented, and there won't be any job openings in the forseeable future. And I can't think of anything else that I might somewhat enjoy than working with linux/unix.
Ooops, sorry about that :(
My favorite is geeklog, which has medium complexity, and it is easy to develop your own plugins for it. It has a good user management interface, and you can do almost anything with the built in static page plugin (a misnomer, for the pages are just as dynamic as the rest), like running php scripts for instance. Also, geeklog is written with security as a priority (even though you need register globals on). An example for a geeklog site is groklaw.net - a pretty good reference, no?
My own tftpanel.hu runs on geeklog, as well as another site I maintain. Hosting requirements are pretty good for geeklog: mysql (if you have access to only one database, that's fine) and php support, plus works on windows as well.
There are lots of CMS out there, ranging from pivot (simple) to typo3 (overkill) - so you might look at them at opensourcecms.org before you decide.
And while we are at it, something like atacontrol - to be able to hotswap ide drives. I know about hdparm, but last time I tried it (it was more than a year ago though) it didn't work very well.
Perfromance while running oo.o is good, but not better than Office XP. It becomes better in oo.o-2.0 (or 1.9m109 I'm running now) if you compile it with support for native widgets: in my case, support for KDE. That doesn't help the startup time, but it helps speed once oo is up and running. Not that 1.1.x was too slow, as I said, speed was OK, but still, when you opened the help browser it wasn't instantaneous (nor was navigating it). It wasn't more than ~1 sec, but actually you can feel ~1 secs if you click through fast and expect instant results. Instant results is what I get with oo.o compiled for KDE: as soon as I click help, or tools --> options - the new window instantly appears, and navigating through the help system is just as fast. I think that it is faster than Office XP on the same machine - but not by much. But what the article claims is absolute nonsense.
I have no reason to disbelieve the author's experience, but this is not "normal" operation. In other words, he might have measured those times, but something must be seriously borked about his Office Install (or windows install, or both). I have installed Office XP on all machines here in the small comp. lab I administer that run winxp. The machine's specs range from 700 Mhz Durons to 2.4Mhz Pentiums, with 256Mb Rams - and OfficeXP wasn't as slow as author claims even on the Duron.
ULE works for me just fine. What's your setup? Because as far as I know, stability issues come up in smp environments with ULE. On single processors it should work - and it works very nicely: desktop interactivity remains top notch when using ULE even while doing CPU intensive tasks (like I do right now, compiling oo.o-2) - meaning smooth playback of movies with mplayer and all. See my kernel config here.
On a sidenote: I just finished compiling openoffice1.9m107 a few days ago (now that the port is updated to m109, I'm there compiling again) - with KDE support. Running it under KDE with native widget support is simply amazing speedwise. Startup times don't change much, however, opening various dialogues (options for instance), the help, etc. is instantaneous - just like konqi when preloaded. Not that it was very slow before, but still, once oo starts up, it is lightning fast using the native widgets!
I uploaded the m107 package to my ftp server (see link in my signature) - you may try pkg_adding it, but read the README.txt before that. And while we are at it, one majore advantage of FreeBSD (that a review should include) is its excellent software support. I can't think of a linux distro with such great support for oo.o as FreeBSD (not by default anyway). The latest binaries distributed by openoffice.org are at m104, and I couldn't find (on google) the source downloads for m107, much less m109 today, except at good-day.net of course, which is pretty much overloaded recently, because ports uses it for source downloads, and it also distributes precompiled binaries: m107 builds are ready with all language packs! So, if you want only the english (or KDE) version, use this link to get it. I just began compiling m109 an hour ago, so in a day it will also be uploaded.
Don't think using the patches provided by APPLE was a simple copy and paste job or in any way convenient. It was probably more convenient than rewriting them from scratch though ... but we don't know how much easier it was.