Slashdot Mirror

FreeBSD has no dropbox client.

That's a Dropbox' problem, not FreeBSD's. But Linux has no such client any more either.

You cannot count on FreeBSD to run the latest version of LibreOffice, or anything else

?? Of course, you can — the editors/libreoffice port is usually up to date (it is now, for example). Which is more than one can say about, say, RedHat RPMs. Now try installing an up to date LLVM on Debian...

Often, Linux apps will not run at all.

?? By that logic, Linux is inferior, because "Often, FreeBSD apps will not run at all."

Not as many drivers as Linux, but that is less of a problem.

That would've been the least illogical ding, actually — if it were true...

For now, at least, FreeBSD might make a good server.

However accidental it may be, this is a compliment...

*BSD uses Mozilla's root certificate bundle.

If the FreeBSD version is ever finished, they'll use jails.

You mean, when this is "ever finished"?

No, does not seem like jails are in use...

You seem to be implying that FreeBSD is going to immediately port all their 3rd party software to any new GCC that gets released in the future during the support period, but that is not actually how FreeBSD versions work

I didn't mention GCC. The default compiler for anything that hasn't actively been marked as requiring GCC is clang. The ports framework has flags to indicate required features of a compiler. If a port is marked as needing C++14, then it will be compiled with either the system compiler (if it supports one), or one from ports if required. The infrastructure for doing this is used automatically by the package-building infrastructure, so a port that needs a newer compiler than the one shipped in the base system will automatically get the one from ports.

The actual reality is that FreeBSD will get most new versions later than even Centos!

An assertion without evidence. We run a few CentOS machines at work and getting anything that needs a newer C++ version than was available when the base OS shipped is a huge amount of pain. Let's look at available packages for CentOS 7 and FreeBSD 10 (both released 2014 and still supported). What's the latest clang version available for them? Actually, that doesn't seem to be a fair comparison, because CentOS doesn't seem to include clang packages (and LLVM is only packaged for MESA) but, for reference, FreeBSD 10 has packages for clang 3.8 to to the 5.0 release branch (5.0 isn't yet out, but there are packages for the latest snapshot from the release branch). Okay, let's make a more fair comparison: how about gcc, since that's the system compiler for CentOS? Well, the CentOS package list has a compat package for GCC 4.4 for compiling older stuff, and an up-to-date package for GCC 4.8.5 (released June 2015), which predates most C++14 features. So, as I said, compiling C++14 code on CentOS is a pain. Okay, let's look at FreeBSD. GCC isn't the system compiler and you've said it lags updates and is behind CentOS, so I guess it will be older? I see packages for GCC 4.6, 4.7, 4.8, 4.9, 5.4 (after 5.0, GCC changed its release numbering, so 5.x is a release series, previously 4.9.x was a release series), 6.4, 7.11, and the (unreleased) 8 release branch.

And no, they don't just slavishly follow the upstream release schedule, they actually couldn't do what you imply if they wanted to because so much of their 3rd party software gets local changes to make it more secure, which then isolates them from upstream and means new versions have to be basically back-ported. So you don't even get all the released versions.

Again, look in the ports collection (follow the svnweb link next to any port to see the history of files that have changed). Most ports have no patches, or trivial ones to change a couple of paths in the build system, and these typically don't change much between upstream versions other than being removed if they're upstreamed.

Stable is only useful if it's both stable and usable. The system ABIs across a stable FreeBSD release series are guaranteed to be compatible, but that doesn't mean that you can't run newer software and there's little use in a system with long-term support if support just means 'we won't change anything' - that's not support, that's atrophy.

cx88 PCI cards

http://corona.homeunix.net/cx8...

https://gist.github.com/dreamc...

xc5000 USB device)

https://wiki.freebsd.org/Webca...

Requires dvb-fe-xc5000-1.6.114.fw firmware

https://www.linuxtv.org/downlo...

MythTV

http://www.freshports.org/mult...

Thanks for the tip. I'll check it out. The proper URL is http://www.freshports.org/sysutils/healthd/. Unfortunately all the links at that page are now dead and "there is no maintainer for this port". I will try it, with trepidation, though all other sensors related ports for FreeBSD appear to be garbage.

From the towering heights of FreeBSD (and other BSDs), the puny differences between your various Linux distributions are negligible, inconsequential, and uninteresting.

No, not Chromium. Chrome.

Distinction without difference. "Chromium" is Chrome compiled from source-code. Not entirely unlike "Mozilla" vs. "Netscape", I suppose...

The practical differences are few and what shortcomings there are in "Chromium" by default, can be overcome at build-time. One major deficiency of official Chrome, in my not so humble opinion, is the bundling of various software, that's supposed to already exist on any decent system. FreeBSD port of Chromium, for example, goes through quite a list of "third-party" stuff to remove — including zlib, yasm, and sqlite, for crying out loud!

Hmm, now I wonder why too! Part of me thought "maybe GNUTLS is included with GPG" (as in you can alternately have it link to a shared library version, or you can just include it right into GPG statically), but looking at the git repo for GPG I don't see any sign of it.

You can verify my claims of dependencies here:

http://www.freshports.org/security/gnupg/
http://www.freshports.org/security/gnutls/

All that said: it looks like the gnupg port has an option for GNUTLS dependency (it defaults to being enabled). For whatever reason I never noticed this before, probably because it's the first menu option (I often miss this). Before and after disabling GNUTLS, dependency counts:

Before: 30
After: 13

Much more manageable, although I'd still love to get that down smaller if at all possible. Getting rid of libksba would be nice, especially if it's optional. As you can see here, it's labelled a hard dependency (both for compiling and running):

https://svnweb.freebsd.org/ports/head/security/gnupg/Makefile?revision=376062&view=markup

If it's truly optional, I should be able to submit some patches that provide those knobs (for toggling both libksba and libnpth). I still have no idea what the pinentry stuff is about, but it looks to me like it should be optional: https://www.gnupg.org/related_software/pinentry/index.en.html

I think it may be that the FreeBSD port is just "bloated by default" (similar to what I find on a lot of Linux systems), and lacks knobs to slim it down. But hopefully that gives you some idea why I've avoided GPG for a while, and why it's important port/package maintainers not let things get too out of hand.

Looks like I'll have to do some experimenting. And thanks -- this good /. convo has gotten me considering fixing all that and getting a "slim" GPG going for FreeBSD.

Hmm, now I wonder why too! Part of me thought "maybe GNUTLS is included with GPG" (as in you can alternately have it link to a shared library version, or you can just include it right into GPG statically), but looking at the git repo for GPG I don't see any sign of it.

You can verify my claims of dependencies here:

http://www.freshports.org/security/gnupg/
http://www.freshports.org/security/gnutls/

All that said: it looks like the gnupg port has an option for GNUTLS dependency (it defaults to being enabled). For whatever reason I never noticed this before, probably because it's the first menu option (I often miss this). Before and after disabling GNUTLS, dependency counts:

Before: 30
After: 13

Much more manageable, although I'd still love to get that down smaller if at all possible. Getting rid of libksba would be nice, especially if it's optional. As you can see here, it's labelled a hard dependency (both for compiling and running):

https://svnweb.freebsd.org/ports/head/security/gnupg/Makefile?revision=376062&view=markup

If it's truly optional, I should be able to submit some patches that provide those knobs (for toggling both libksba and libnpth). I still have no idea what the pinentry stuff is about, but it looks to me like it should be optional: https://www.gnupg.org/related_software/pinentry/index.en.html

I think it may be that the FreeBSD port is just "bloated by default" (similar to what I find on a lot of Linux systems), and lacks knobs to slim it down. But hopefully that gives you some idea why I've avoided GPG for a while, and why it's important port/package maintainers not let things get too out of hand.

Looks like I'll have to do some experimenting. And thanks -- this good /. convo has gotten me considering fixing all that and getting a "slim" GPG going for FreeBSD.

Some more URLs I have in my collection (haven't checked some of these in awhile, though):

UPS tracking (after trigger enter your tracking number)
US Postal Service Tracking (after trigger enter your tracking number)
YouTube Video Search
E.gg Timer (type the length of the countdown in plain text after your trigger -- eg: "5 minutes" to make the timer run for five minutes, "2 hours 3 minutes" for two hours and three minutes, ect. You can even go do other browsing and background the tab, it will jump to the front when it goes off.
IMDB Search
Rotten Tomatoes
Google Translate (to English) -- just paste the URL of the foreign site after your trigger.
ZXing QR Code decoder -- paste a image URL after the trigger.
DownForEveryoneOrJustMe website check
NewEgg Product Search
FreshPorts Search

For sites without their own searches, you can always set up a Google search restricted to the site with "site%3Adomainofsite.tld+%s" as the string.

Once you have all the major search engines set up there's really no reason to waste toolbar space on Firefox with the actual Search Bar anymore.

The answer to all your questions is "it is there". For any future questions of the same kind, go to http://www.freshports.org/ and search for the package that you want.

There was a period of time during the GCC->Clang transition where a lot of stuff didn't build, but those days are long gone.

If you stick with the Ports collection, using Clang is fairly safe if you're on 10.1 and you keep your Ports db up to date. The problem is when you stray outside of Ports, or you find one that really needs GCC (or worse, a newer version of GCC).

The last compiled version of GCC included with FreeBSD was 4.2.1. You can build newer versions using the Ports collection, but then you have to make a decision to keep two versions installed. There is also some hassle regarding which shared libraries to use.

I had a package that really wanted something newer, so I installed gcc48. It took me a few hours, but I finally got it shoehorned in. Ugh. I'll stick with packages that are happy with Clang.

I've done this myself as an experiment a few weeks ago. With the exception of FTB (the site has a jar file for it, so it'll likely work) everything you mentioned is available in ports. http://www.freshports.org/

There's also a binary packing system (pkg) but packages seem to randomly go missing there. A couple of weeks ago it was Xorg, until yesterday no Firefox. BTW can anyone explain the dynamics behind that?

The best way to get in is head first, install it on the least fancy PC you have. I'd strongly recommend FreeBSD and the handbook (This should be your first place of reference). http://www.freebsd.org/handboo... (take note of chapter 11). If you're a gentoo man you don't need PC-BSD.

Putting my view on *nix desktops aside (Are they worth the effort?), If there is a show stopper it'll probably be hardware support.

so I can use http://www.freshports.org/
I have subscriptions for the stuff that I use, build, or that I'm generally interested in (I run my on own build-server and build about 1200 packages these days) and I get an email every evening (local time) that lists all the updates to these projects.
It will sometimes take a longer time for a port to be updated (for various reasons) - but it works well enough.
In these cases, other news-portals often carry the news of a new release (like it's the case for PHP).
In contrast to freshmeat, freshport's mail-summaries contain much more and better information.

I've subscribed to all the ports that interest me or that we're actively using and every time one get's an update, I get an email at the end of the day.
It's really handy.

Does that mean I also don't get email-updates from freshmeat anymore?

It is possible to create powerful sites generated in Ada. One popular option is the Ada Web Server ( http://www.adacore.com/aws ) ( http://www.freshports.org/www/... ), plus it's possible to create cgi and fast-cgi applications using various libraries.

Actually, you do not have to pay for for an Ada android cross-compiler and one has been available for 3 years already. Here is the latest gcc 4.9-based free (in every sense) android/arm cross compiler with FreeBSD as host (DragonFly BSD is also an option)

http://www.freshports.org/lang...

And here are the testsuite results: http://www.dragonlace.net/gnat...

The only test it fails are the stack-check tests, and that is because gcc doesn't support it yet (a patch was produced but it's not be accepted yet).

FreeBSD Graphics Driver Download Version: 1.0-3203 File Size: 3 MB Release Date: November 7, 2002

And pretty close to a decade already with OpenOffice: http://www.freshports.org/editors/openoffice-1.1/

11 Mar 2004 12:36:03

Being a copyfree zealot, I haven't used Macromedia / Adobe Flash in years. I'm missing out on many Web annoyances, and on very little good. I still get access to all the videos I want via youtube-dl (or my own buggy little equivalent thereof) or BitTorrent - either of which can be used to download Khan Academy videos (an example mentioned above).

Hoping HTML5+ video and something like NaCl will dominate.

--libman

Good luck on running mplayer with a remote control.

"RTFM" > "LUCK"

Mplayer had LIRC support for over a decade, including on FreeBSD.

XBMC is meant for media center usage, not jerking off to porn at the desktop.

Real geeks have no use for the former. 8-)

But seriously - the opposite of "bloated" is "modular". Mplayer "does one thing and does it well", as per The UNIX Way . It's easily scripted and controllable via a runtime API, with many existing wrappers. So instead of having one bloated mess like XBMC trying to be all things to all people, all we should need is a simple video menu app that then passes control to mplayer.

It so happens that I'm toying around with precisely this kind of project on the back-burner: a Node.JS + HTML5 media searching / browsing UI that can launch mplayer if connecting from localhost. (HTML5 video still sucks, especially on my old system.) It even remembers which parts of the video you've played or skipped through, for automatic resume. I personally don't use a remote control, but hopefully HTML 5.1+ will support that "10-foot user interface" crap as well. And hopefully someday in-browser video formats will be common enough, and in-browser player features powerful enough, to make all them copyleft stand-alone player apps obsolete!

--libman

No, nobody does.

You can't be sure. But even if there are, something like the reverse of elftoaout could probably be written relatively easily.

http://www.sourceforge.net/
http://www.portableapps.com/
http://www.freshports.org/
http://www.getdeb.net/

Or just man up and install linux and use the repositories. Failing that, go to the program's WEBSITE and download it there like you are SUPPOSED to!

Looks like it's another 2-3 hours of compiling packages and the odd several hours of library/package build error resolution for you!

You can use freebsd-update to do a binary update. Also, recompilation of ports is not usually necessary in between minor upgrades (ie. 8.1 to 8.2). Of course, you may have chosen to build a custom kernel and then you need to build it manually. On my dual core CPU with 4GB RAM it takes about 10-12 minutes to build the kernel and 30-40 minutes for world. To deal with etc scripts you can use etcupdate.

Also, if you don't like this way of doing things and you are a more desktop oriented user, you can look at PC-BSD which comes with its own package system for binary packages, while still offering access to the ports system. And PC-BSD 8.2 (which is obviously based on FreeBSD 8.2) was just released, too.

but other than a gui I see no outstanding advantage over the FBSD package system

As a gauge of relative activity level in each package system:

The weekly list of UPDATED (and possibly NEW) BSD packages at

http://www.freshports.org/ports-new.php?interval=week

is roughly equal in size to the weekly list of NEW Debian packages at

http://packages.debian.org/unstable/main/newpkg

So, each week, there is about as much new stuff added to Debian as there is updated preexisting stuff in BSD.

Also FreeBSD 8 is a little faster than FreeBSD 7.2 but a lot slower than Ubuntu Linux 9.10

Not disputing the conclusions of the memory, I/O benchmakrs, part of what they benchmarked is the compiler — FreeBSD's gcc-4.2.1 vs. Ubuntu's 4.4.1. I'm not surprised, GCC's newer release both compiles faster and produces faster binaries.

You could say, FreeBSD is at fault (and thus deserves bad rep) for including an outdated compiler, but, on the other hand, FreeBSD's choice may prove wiser, when bugs in the hot new compiler surface... The compiler's history — as, really, that of any sufficiently complex piece of software — teaches, it is wise to stay several releases behind. Bugs in the older releases are known and all platforms — certainly including FreeBSD — merge fixes into their repositories.

Their choice of using ImageMagick as a test is particularly suspect — that software has so many options (which graphics back-ends to include, whether to use OpenMP, etc.) and varies so greatly between its own frequent minor releases, that I'm sure they built it with subtle (but timing-affecting) differences between platforms... For just one example, FreeBSD's port of ImageMagick runs all of their bundled self-tests after compilation by default, which takes quite a while. Unfortunately, the testers don't even mention, how exactly they built the stuff. If they used the port on FreeBSD, did they change any options? If they did not use the port, then they didn't build ImageMagick the way the users will be building it... And if they did use the port and flipped some features, did they ensure an identical match between two FreeBSD versions and Ubuntu?

There have been a lot of cases (the linksys modding scene for instance) in which the lack of GPL would have meant no release of source or tools. There are a variety of other examples.

In other words, thank God we've got Richard Stallman to use the legal system to beat people into submission, and force them to do exactly what WE want them to do. It might be unfortunate, but given that said people work for corporations, they're not as equal as we are, and hence, their wellbeing doesn't count.

I love the smell of freedom, don't you?

At this point BSD is basically an also-ran

Yep. Marginal, dead, and completely irrelevant; just like Netcraft said. I guess that's why FreeBSD is ranked 13th on DistroWatch. It might also have something to do with why NetBSD just had a new release last month, or OpenBSD having its' most recent release in May. It's probably also why Theo de Raadt gave a keynote speech about OpenBSD's development process in May, as well.

Because, you know, they're fringe, dead, irrelevant operating systems. Nobody uses them.

That's also why we've kept seeing stories like this crop up in the trade press over the last three months or so; because the GPL is just such an awesome, business-friendly license. Everyone just loves the freedom that their Uncle Richard has provided for them; I really can't imagine where we'd be if it wasn't for him.

not on the same level as linux or supported in anything like the same way in terms of FOSS and commercial software.

Yeah. Too bad World of Warcraft doesn't run on it. Having to surf the Web without Flash really hurts, too. Like you said, FreeBSD is so irrelevant, it doesn't even have 3D video card drivers.

http://www.freshports.org/emulators/virtualbox/

FreeBSD was providing Java (with the plugin) for both i386 and amd64 for years now...

Well let's be honest. Linux is now the darling of the "open source" movement, irrelevant of technical or developer merit. It's similar to Opera VS Firefox. Opera usually has more new features while Firefox takes the credit later when it finally introduces those same features. Firefox is the darling of browers. No, it's not fair, but it's just the way it is.

Unlike Flash, Java source-code was perfectly open and available for years (it has even been GPL-ed for a while, but before that was still available). Why did anyone have to wait for Sun to release the 64-bit plugin instead of compiling one? A fairly small patch was required (long vs. size_t somewhere deep inside)...

FreeBSD was providing Java (with the plugin) for both i386 and amd64 for years now...

What does the fact, that this is news, tell us about Linux developers? First they holler at Sun to release the source, that's already available for download under GPL. And then they still would not touch it, until Sun gets around to it... "Freedom to tinker" my behind.

It's the only browser that will run natively on every platform I use, including Mac, Linux, Windows, and FreeBSD. Firefox can't claim that last one, at least not since the 1.x branch

Really? Does 3.0.4 not count as 'since the 1.x branch'? If you don't like 3.x, 2.0.0.18 is also in ports.

Actually I meant xwatchwin. http://www.freshports.org/x11/xwatchwin/ Been a long time since I've used it.

FreeBSD has a nice port for this: http://www.freshports.org/sysutils/devcpu/

You should ask: "What can I do for KDE".

Obviously, in your case, that's less than nothing.

a) that's irrelevant — a project striving for dominance of a desktop must be usable by all and accept criticism from all; b) I have done quite a bit — as part of FreeBSD's ports team I've created and/or maintain dozens of ports, including, incidentally, devel/qmake (if you know, what that is); c) I've originated dozens of KDE bug-reports; d) see a).

This is the point, where you recant the "obviously" part and apologize profusely.

Oh, and a special for you: e) Kennedy, who coined that servitudish slogan, was a mafia-elected skirt-chasing scumbag, who is mostly beloved for getting shot.

Pre-built binaries are for wussies — real women and men build from source.

Yeah, that must be why TrustedBSD is copying SELinux

There is no "copying". They all implement the same features and ideas designed by the same people for the same purpose. From NSA's, DARPA's et al. perspective, this is simply "dual sourcing" — what customers with huge budgets and strict requirements are supposed to do for redundancy.

They need them all for their multitude of servers. But since FreeBSD is better to begin with, you want it for your smaller establishment, unless already "married" to Linux for some other reason — just as I said before ;-)

The page you sent me to describes SEBSD as a port, not a "copy". Guess what? Firefox is a port too. Does it make it somehow inferior?.. Mozilla's primary target-platform is Windows — what you have on Linux is also, what you'd call "a copy".

Hey, why not bundle gcc and the kernel with it :-P

You may think you are joking, but the maintainers of the FreeBSD's port of OpenOffice.org have in the past insisted on building their own version of gcc — just so that OO.o was built by the compiler they new as "good".

The asinine practice has since stopped, but the port named gcc-ooo is still here, and its description says:

GCC, the GNU Compiler Collection includes gcc, g++ for OpenOffice.org compilation This port installs the various front ends as gcc-ooo, and g++-ooo into the ${PREFIX}/bin directory. WWW: http://gcc.gnu.org/

Applying -9 to an innocently running process is a sign of extreme amateurishness in a sys-admin. Presuming, sudo is even installed is another — one does not need it for the most common usages on an OS (such as *BSD), where only a 0-group (wheel) member can become root, and where the regular su is happy to read commands from stdin:

echo kill 84676 | su

That is, if I ever wanted to become a regular Slashdotter again in the first place — by parting with my significant other over the amount of memory her web-browsing is consuming on my system... Sorry, it is not you, it is me: I just can't stand the amount of browser-tabs you are opening, dear!

In my opinion, the article summary is a pretty big red herring because the SMP performance may not have a huge impact on the result.

Slide 10 out of 37 (emphasis mine -mi):

• Online transaction processing" benchmark; /usr/ports/benchmarks/sysbench
• Complex transaction-based queries
• Read-only: no disk access to avoid benchmarking disk performance
• Clients and servers on the same system
• PostgreSQL 8.2.4 (process-based + System 5 Inter-Process Communication (IPC)
• MySQL 5.0.45 (thread-based)
• Test hardware:
  1. 4 * 2-core Opteron (amd64 mode) 2.2GHz CPUs, 4 GB RAM
  2. 2 * 4-core Xeon E5320 (i386 mode) 1.8GHz CPUs, 3.5GB RAM

Incorrect. Both track the main FreeBSD tree. Consider them "value add" packages of software and tweaks layered on top of the official FreeBSD. A fork would be traced to a single point in time with ever-growing divergence (think DragonflyBSD). Both DesktopBSD and PC-BSD include updated bases of the main FreeBSD with their own updates. For example, PC-BSD 1.0 was based on FreeBSD 6.0. The current version of PC-BSD, 1.4.1, is based on FreeBSD 6.3. PC-BSD 2.0 will be based on FreeBSD 7.0.

In fact, a lot of the DesktopBSD components are available as an add-on in the Ports collection:
http://www.freshports.org/sysutils/desktopbsd-tools/

boehm-gc is totally broken when using threads on FreeBSD SMP. And it's still totally broken on FreeBSD 7.

pkg_add -r bash

In the meantime, Landon Fuller is doing an admirable, if duplicated, job of single-handledly porting Java 6 to OS X based on the efforts for BSD.

Java 6 was released more than 12 months ago for other platforms. "fake" and real Steve may dismiss Java as irrelevant but the truth is Apple have dropped the ball.

I develop Swing applications and it's frustrating that we can't use new features of Java 6 because we have to support OS X's legacy Java 5 implementation.

The majority market share is still Windows. While Apple lags with Java it's hurting Linux AND OS X. Much as Java-haters on this site would like it to disappear, Swing is still an option for cross OS deployments in the enterprise, offering a rich client alternative to web-browser environments. At times the option of supporting an application for Win32, Linux and OS X with native toolkits is not viable. More likely it's mandate Windows-only or use Java.

NVidia may have released FreeBSD/i386 drivers, but has anyone actually got the damned things to work?

I had no problems with the drivers as installed by the /usr/ports/x11/nvidia-driver . Used it on FreeBSD-4, -5, and 6. Maybe, they have not updated for Xorg-7.2 yet — have not tried that...

If you were trying to install directly, rather than via port (pick the right one, to get the version of the driver, that supports your card), you ought to give port a try...

You can't seriously claim that "the vast majority" can take advantage. Look on any Unix package manager web interface (e.g. http://www.freshports.org/ and take a sample of about 20 programs randomly (heck, even just the most recent ones) and think of a genuinely good reason to make it more parallel. Keep in mind that many programs will be running in parallel anyway, without being multi-threaded in their own right, so you can't call that parallelising the programs.

Just becoming more parallel does not mean it's an advantage - it carries significant impacts to complexity and makes the correctness of a program very difficult to verify formally. I would say "the vast majority of real world applications can severely cripple themselves in the search for parallelism". That's at least consistent with reality.

Intel's compiler (icc), available for Linux, Windows, and FreeBSD extends OpenMP to clusters.

You can build your OpenMP code and it will run on clusters automatically. Intel's additional pragmas allow you to control, which things you want parallelized over multiple machines vs. multiple CPUs (the former being fairly expensive to setup and keep in sync).

I've also seen messages on gcc's mailing list, that talk about extending gcc's OpenMP implementation (moved from GOMP to mainstream in gcc-4.2) to clusters the same way.

Nothing in OpenMP prevents a particular implementation from offering multi-machine parallelization. Intel's is just the first compiler to get there...

The beauty of it all is that OpenMP is just compiler pragmas — you can always build the same code with them off (or with a non-supporting compiler), and it will still run serially.

Depending on your hardware, try FreeBSD. VLC works a treat via ports, and installs a heap of codecs as well. Granted, the Open Sound System perhaps isn't quite as nice as ALSA, but it offers perfectly good stereo, and there are actually a number of sound filters available for XMMS at least which do various different things, so if you want something that boosts volume or cleans sound up in some way, you can probably get that from ports too.

I wouldn't bother with Samba, personally...use FTP. You can put an ftpd on the Windows box, make the directories you want accessible, and then do a batch wget from the Linux/FreeBSD box to transfer whatever files you need over. If you need to send files the other way, there are any number of GUI ftp clients for Linux or FreeBSD available; either search here for Linux or here for FreeBSD.

Until Linux frees itself from the horrible terminal/command line dependencies, eliminates text files for configuration (how the heck is the average joe supposed to know which one of hundreds of config files he needs to edit just to connect a network drive??)

What do you advocate as a replacement? The Registry? ;) The Registry uses text in places...the DWORD is actually an assembler variable...but it also uses a lot of non-text and is completely non-transparent in places. There are good reasons why UNIX (and hence Linux) uses text config files...you can read about those here if you want.

Your problem wasn't text config files...it was knowing which transfer protocol to use for what you want.

Also realise that Microsoft created the interoperability problems themselves...it's very convenient...first they make something completely closed and proprietary, and then they can use their obviously greater level of familiarity with their own system to make it marginally more workable with Linux.

Unfortunately, things like DRM which people talk about so much on here go hand in glove with people wanting Windows to do everything for them. If you willingly surrender self-responsibility to Microsoft, they're going to use that power to make some bad decisions...it's human nature. You can't reasonably expect them to give you something which works without you investing any effort at all on the one hand, and not have them include things with it which are actively harmful to you on the other. I realise that is going to sound self-righteous, condescending, and offensive...but unfortunately, it's also true.

If you want a system which does what you want, and only what you want, you're going to have to accept some responsibility, and do some work...that isn't Linux's fault. It's simply that you've got used to having most things done for you on the one hand, but also being abused on the other.

Also falling into the "not necessarily better, but interesting" category, portmaster is a utility much like portupgrade, but it requires no dependencies to build or run. It's worth noting that you end up relying on FreeBSD's pkg_* utilities instead of portupgrade's port* suite. Of course, if you would have Ruby installed anyway, then portupgrade doesn't really cost you anything extra.

Your main point is dead on, but there are a few other projects working on open-source compilers; off the top of my head I know of:

TCC, written by the guy who created QEMU
BCC, "Bruce's C Compiler", which spits out 16-bit code (for embedded machines?)
OpenWatcom C compiler which is only for OS/2, DOS and Win32, but they're porting it to *nix Real Soon Now.

There's also one I'm forgetting which has been talked about in the OpenBSD mailing list as a free alternative to GCC; but I forget the name of it.

As for automagic updates: I've tried to do my part to make this work better, see e.g. etcmerge, and the options system for ports (so options are kept across updates automagically). I would like to do more, I've not been active for a while, though.

WRT Java, this has been closely tied with the licensing issues of Sun. A couple of months ago, Sun added a new licensing option, so I think this may change. I'm not sure, though - Java on FreeBSD has been such a pain that I've mostly avoided Java.

Eivind.