Slashdot Mirror

Maturity isn't really about age, but of total development hours. Popularity matters, because it helps to attract contributing developers, and more can be done in a shorter amount of time. Because of it's popularity, I think it's probably fair to say that Linux has matured faster than FreeBSD.

You forget that for the entirety of time from 1977 and 1991, there was no Linux, just BSD (excluding AT&T versions) so all the development time was spent on BSD, from which FreeBSD comes. In addition, FreeBSD supports Linux Binary Compatibility - with exceptions, of course. There is also a lot of cross pollination between Linux and the BSDs now.

In some sense you're comparing apples with somewhat different apples and I think it's fair to leave it as a "to each their own" kind of thing and YMMV.

Maybe when FreeBSD actually gets around to supporting ZFS root on a UEFI based system, but the wiki page on UEFI and FreeBSD lists said target as "unstarted."

https://wiki.freebsd.org/UEFI

Nice try though, but your antiquated Unix knock-off has been superseded by bigger and better. FreeBSD certainly isn't dead, but it might as well be for all the use any common desktop user will get out of it.

It is presumably an attempt at a joke based on the fact that Forth makes use of RPN.
https://en.wikipedia.org/wiki/...

I for one find Forth to be a fascinating language. The fact that it has been around for a while does not diminish it in any way.

I first heard of it back in the 80's while learning assembler on the 6502. I noticed it again while getting to know FreeBSD (loader stage 3) and decided to finally learn it when I came across some old manuals and software for my newly acquired PET CBM 8032 just a few weeks ago.

Ever since, I seem to notice it mentioned more and more, perhaps partly because of renewed interest in stack machines, but also because it offers an interactive way to boot strap a very small system with minimal resources.

It is available in some form on almost every platform that I know.

Following are some resources that I have found to be of interest. Hopefully those sites will not get badly hurt.

http://www.forth.com/starting-...
http://thinking-forth.sourcefo...
http://playground.arduino.cc/C....
https://www.freebsd.org/cgi/ma...
https://uwaterloo.ca/independe...
http://www.ultratechnology.com...

...

Is Edge going to be portable to non Windows operating systems like GNU/Linux, FreeBSD, Solaris, OS X, HP-UX, OpenServer X, Haiku OS, AIX, Android and Firefox OS?

You must feel so smart listing all those UNIX operating systems. You know so many!

Is Edge going to be portable to non Windows operating systems like GNU/Linux, FreeBSD, Solaris, OS X, HP-UX, OpenServer X, Haiku OS, AIX, Android and Firefox OS?

I read a lot of the usual suspects: this site; although it's probably
gone downhill over the years, there are still some interesting, insightful
or informative opinions/posts.

Other sites include:

El Reg. Always good for the latest government fuck-ups with IT.
The latest: 16 billion quid wasted trying to implement a new IT system for what is essentially a renamed social security benefit.

Our dishonest dick of a PM (David Cameron) said today:

"I make no apology for taking Universal Credit [the new benefit] at a deliberate pace."

"Deliberate pace"? It's been years (and it wont be ready for many more, if at all!). What a tosspot.

Another good site is:

FreeBSD Forums. A must read for all those using (or proposing to use) FreeBSD.

The icing on the cake:

The Daily Mail; drivel masquerading as news.

It's like The Onion, only funnier.

It consists of "news" about celebrities (I use the word loosely: most of
them I've never heard of). On a typical day there will be about a dozen
stories about the dreadful Kardashians. A tweet by one of those revolting
people constitutes Daily Mail "news".

What beggars belief though, is that the DM is one of the most popular sites
in the UK! People believe and read the trash they write, as the hundreds of
braindead comments attached to each story attest.

Who was it that said "You can't underestimate people's stupidity"? The DM
is living proof of the wisdom of that quote. Remember, that half the
population has an IQ < 100; I read the DM so that I know what that
half are thinking/being told to think.

I'm not the only one to read the DM. The government takes a keen interest
in what the DM and their imbecile audience has to say and it inevitably
informs part of their unashamedly populist government policy.
Eg. EU bad, people on social security are all scroungers, isn't
the Royal Family lovely?, immigrants are scum, BBC bad etc.

In short, they're hugely influential and I take it as a public duty to
stay informed of what these dingbats are up to. If I lived in the States,
I'd watch Fox News.

I used to troll the DM: post comments which caused a certain amount of
cognitive dissonance amongst the readers. But I got bored with it; the
dullards didn't really react. Maybe my trolling technique wasn't good enough.

We shouldn't always read stuff that confirms our own views/prejudices. You
need to know what the "opposition"/"mental defectives" (or in the States:
Republicans) are up to.

This. Preferably the FreeBSD License, since it's the same license that's used by the FreeBSD parts of iOS

Talk about high level requirements?

Lets use an already existing jail manager:

• iocage
• cbsd
• ezjails

Then it's just a matter of figuring out a setup config that is both extensible but KISS.

$ cat repo/config.yml
jail: myawesomejail
packages:
    - nginx
    - nmap
    - mysql-server
    - python3.4

Then maybe a 'faux filesystem' of stuff to copy.

$ cat repo/usr/local/etc/nginx.conf
# My super special nginx config

Then some sort git hooks/scripts and config parser for git. I prefer python but just because I'm learning it. But if it was done it tcsh or sh it would work 'out of the box' on a bare bones FreeBSD.

Then figure out a way build a nanobsd build that you could install to a flash drive that would contain a bare bones FreeBSD install to act as 'dom0' and some way to point it to some ZFS pools.

All managed through Git/Gitolite.

Then all of your config files are versioned and you have to commit and push them to be active. Need a way to start/stop.

Anything I'm leaving out? I don't do this for a living, I just want something stupid easy to make new jails.

Unless this unified "Open Container Project" supports both the unprivileged, isolated "machine" concept of a container AND the trusted, shared "app" concept of a container, it's going nowhere fast for me.

Solaris Zones. linux-vserver containers. Now Canonical's lxd. Few of the participants in the container effort, except these three, seem to understand the value of having containers as *machines*. Give each machine its own static IP, isolate all its resources (memory, processes, users and groups, files, networking, etc.) from the other containers on the system, and you have what's basically a traditional VM (in the early 2000s sense of the word), but with a lot less overhead, because no hypervisor and only one centralized kernel.

Docker seems to pretend like VM-style containers don't (or shouldn't) exist. I disagree fundamentally with that. I dislike that Docker pushes containers so hard while ignoring this very important use case. I hope the rest of the Linux Foundation is smart enough to recognize the value of this use case and support it.

If not, I'll just have to hope that Canonical's lxd continues to mature and improve.

I think FreeBSD's Jails would appeal to you.

The NetBSD init system (which was introduced way back in 2001, and I think ended up being adopted by the other BSDs) has a simple way of solving this. There's a tool called rcorder that parses REQUIRE and PROVIDE lines in each startup script (it's tsort, essentially) and determines the order to run each script. If you wanted to debug something, you could run this yourself and check the output.

Came here to say this.

Ditto.

SysVInit's numbering always struck me as a little hacky. But it's so simple it works. Plus everybody's used to it. When systemd appeared, I looked into FreeBSD and read about its init system. It's a total face-palm that so many years have gone by without Linux adopting something like BSD's way --- or just taking it. It's an even bigger face-palm that instead Linux adopted systemd.

FreeBSD has not replaced OpenSSL with LibreSSL; OpenSSL is still used in the base system, while LibreSSL (like newer versions of OpenSSL, or WolfSSL, or anything else) are available via ports:

stable/8: http://svnweb.freebsd.org/base/stable/8/crypto/openssl/?view=log
stable/9: http://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
stable/10: http://svnweb.freebsd.org/base/stable/10/crypto/openssl/?view=log
head (FreeBSD 11.x): http://svnweb.freebsd.org/base/head/crypto/openssl/?view=log

It sure looks like there's a lot of work to be done (API/ABI incompatibilities with ports) before LibreSSL could replace OpenSSL in the base system: https://wiki.freebsd.org/LibreSSL

FreeBSD has not replaced OpenSSL with LibreSSL; OpenSSL is still used in the base system, while LibreSSL (like newer versions of OpenSSL, or WolfSSL, or anything else) are available via ports:

stable/8: http://svnweb.freebsd.org/base/stable/8/crypto/openssl/?view=log
stable/9: http://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
stable/10: http://svnweb.freebsd.org/base/stable/10/crypto/openssl/?view=log
head (FreeBSD 11.x): http://svnweb.freebsd.org/base/head/crypto/openssl/?view=log

It sure looks like there's a lot of work to be done (API/ABI incompatibilities with ports) before LibreSSL could replace OpenSSL in the base system: https://wiki.freebsd.org/LibreSSL

FreeBSD has not replaced OpenSSL with LibreSSL; OpenSSL is still used in the base system, while LibreSSL (like newer versions of OpenSSL, or WolfSSL, or anything else) are available via ports:

stable/8: http://svnweb.freebsd.org/base/stable/8/crypto/openssl/?view=log
stable/9: http://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
stable/10: http://svnweb.freebsd.org/base/stable/10/crypto/openssl/?view=log
head (FreeBSD 11.x): http://svnweb.freebsd.org/base/head/crypto/openssl/?view=log

It sure looks like there's a lot of work to be done (API/ABI incompatibilities with ports) before LibreSSL could replace OpenSSL in the base system: https://wiki.freebsd.org/LibreSSL

FreeBSD has not replaced OpenSSL with LibreSSL; OpenSSL is still used in the base system, while LibreSSL (like newer versions of OpenSSL, or WolfSSL, or anything else) are available via ports:

stable/8: http://svnweb.freebsd.org/base/stable/8/crypto/openssl/?view=log
stable/9: http://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
stable/10: http://svnweb.freebsd.org/base/stable/10/crypto/openssl/?view=log
head (FreeBSD 11.x): http://svnweb.freebsd.org/base/head/crypto/openssl/?view=log

It sure looks like there's a lot of work to be done (API/ABI incompatibilities with ports) before LibreSSL could replace OpenSSL in the base system: https://wiki.freebsd.org/LibreSSL

FreeBSD has not replaced OpenSSL with LibreSSL; OpenSSL is still used in the base system, while LibreSSL (like newer versions of OpenSSL, or WolfSSL, or anything else) are available via ports:

stable/8: http://svnweb.freebsd.org/base/stable/8/crypto/openssl/?view=log
stable/9: http://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
stable/10: http://svnweb.freebsd.org/base/stable/10/crypto/openssl/?view=log
head (FreeBSD 11.x): http://svnweb.freebsd.org/base/head/crypto/openssl/?view=log

It sure looks like there's a lot of work to be done (API/ABI incompatibilities with ports) before LibreSSL could replace OpenSSL in the base system: https://wiki.freebsd.org/LibreSSL

Have you looked into chroot or FreeBSD Jails? That might give you the compartmentalization you need without the overhead of virtualization.

Check out FreeBSD

What are you talking about? The FreeBSD forums have a ton of news members lately, all moving away from systemd. Including myself.

And rc.d is absolutely nothing like systemd. It's far more like SysVinit in that it's just an init system, and not a (DNS server, binary logging system, network time daemon, login daemon, console daemon, HTTP server, QR-code generator, hardware device manager, etc etc etc etc etc etc etc etc etc etc.) Only rc.d is far simpler and nicer than SysVinit. It's a thing of beauty. I set up an HTTP daemon by making a text file with five lines of text in it. See for yourself.

Please tell me how did BSD win from OS X using it as a code base. They don't give back, and attempts at cooperation ended up wasting some time of BSD developers.

BSD got its automatic live self-defragmenting code from OS X. Then there's libdispatch/GCD, LLVM, and so on.

I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts.

And I still call bullshit because scripts are every admin's (and that doesn't even stop with systemd) best and most valuable tool. I don't presume you're seriously going to claim that even admins could completely forgo of the shell? Or would want to do that in the first place? (Hint: automation). If a sys- and network admin entirely using GUIs to do their job is what you imagine, then you're so far away from reality, it's not even funny anymore...

I mentioned busybox to show that binary commands [are] enough to admin a box

And what do you think is the execution environment for literally every single of those tools? Seriously if you were even slower, you'd go backwards.

I have see[n] a lot of Linux boxes with load[s] like the one you describe[d] on your BSD box[es], this is not impressive at all.

That wasn't mean to impress, i was merely responding to your claim about unfair comparisons. Nice try, but it would help if you would consider the parts you reply to in their actual context, instead of trying to create and tear down straw men like this.

Now, did your Linux kernel really crash[]?

Yes, I've seen uncountable instances of linux panicing.

I understand that you reboot for each libc or kernel update, this is your choice, but certainly not a stability problem.

I didn't say the reboots required by updates were a stability problem; they are an availability problem, however.

About the libc update, you might find [it] simple[r] to just reboot, but again this is your choice, not a stability problem. Now in case of libc upgrade[s], [what] [do] you do with your BSD boxes[]? Or [is] the BSD libc [] so perfect that no upgrades [are] required[]? Hint: https://www.freebsd.org/securi...

Hint: It's not FreeBSD, and Hint: if the BSD servers receive a libc update that fixes a security issue we're affected by, then the server gets rebooted. Not that i hadn't already said that in the post before.

You call me ridicul[ous], but I largely prefer restarting some services

if it's a libc fix, "some" services will not cut it.

It's a choice, and I will not call you ridicul[ous] for your own choice.

Well if you choose to go for a reboot-less libc security upgrade just to keep uptime (yet losing availability), then i'd actually ridicule you for that, because it'd be a moronic waste of time. If you get paid by the hour, maybe.

If you are so conservative to reboot each box[] as soon as a libc or kernel upgrade [appears], then I wonder how your BSD boxes could have uptime[s] a "few orders of magnitude less shitty".

See above.

aerospace, or railway, or automotive, or civil engineering standards

So, let's assume you're designing some aerospace-grade embedded system, linux based no less. Would you make it use systemd? Why not?

But I would like to rem[ind] you th[at] this discussion is about the fact [t]hat Ubuntu has released [their] first version with systemd :-)

Sure. Let's see how it works out.

dpkg --get-selections | wc -l
3423

dpkg -L $(dpkg-query -Wf '${Architecture;-20}${Priority;-40}${Package}:${Architecture}\n' | egrep "all|amd64" | cut -b21- | egrep "required|important" | cut -b41-) | grep "/usr/s*bin/.*" | xargs file | egrep " script, " | wc -l
56

And 17 of them are perl scripts. The rest are mostly not so used commands. So I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts.

I mentioned busybox to show that binary commands is enough to admin a box (outside of system V init), not about a supposed busybox GUI.

I have see a lot of Linux boxes with load like the one you describes on your BSD box, this is not impressive at all. Now, did your Linux kernel really crash ? I understand that you reboot for each libc or kernel update, this is your choice, but certainly not a stability problem.

About the libc update, you might find more simple to just reboot, but again this is your choice, not a stability problem. Now in case of libc upgrade, how did you do with your BSD boxes ? Or the BSD libc is so perfect that no upgrade is required ? Hint: https://www.freebsd.org/securi...

You call me ridicule, but I largely prefer restarting some services on a remote machine., and even more when the machine also act as a NFS server, or a router, or a firewall, or have virtual machines. It's a choice, and I will not call you ridicule for your own choice.

If you are so conservative to reboot each boxes as soon as a libc or kernel upgrade exists, then I wonder how your BSD boxes could have uptime a "few orders of magnitude less shitty".

I do tests on the system I deliver, and my customers do tests too, I just say that this is tests not usually done in the cycle of a kernel release [by the kernel maintainers] (last part added for you understanding).

You can't usually buy the systems we design as there are not for consumers. What I can tell you is that we have build systems where conformity to part of aerospace, or railway, or automotive, or civil engineering standards are required. Nothing highly critical, but still with a good chunk of audit and conformity tests. Customers are happy enough with our work to allow, to setup our own company 4 years ago.

But I would like to remain you the this discussion is about the fact hat Ubuntu has released his first version with systemd :-)

Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...

Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).

I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.

I don't understand you, really. The procedure you mentioned was the bare minimum if you don't want to use any helper scripts or applications

Except for the mentioned helper scripts and the whole bloated infrastructure of systemd, sure.

and is almost identical to what you need with system V init to get the same functionality: the configuration file and the two scripts are absolutely not related to systemd at all.

How aren't they related to systemd? I'm not following, I think.

The difference is that with system V init you need to write a script with a start) and stop) method while with systemd you have to write a service file. At the end this is exactly the same number of files, so what your problem ?

So you see how pointless it is?

systemd-networkd is only an alternative. Personally I largely prefer C code over scripts, mainly because C code projects tend to be adopted by many distributions while scripts tend to remain specific to each distribution. The systemd vs system V story is an very good illustration of this difference.

Disclaimer: I have a ton of experience in C; i really like the language. But would you please think of debugability? Quickly analyzing and fixing a bug in a script means editing that script. Fixing a bug in a component that is written in C, means a) identifying what part failed in the first place, checking out the entire project, getting it to compile (which tends to include a ton of build time dependencies), of course don't forget to compile with debug symbols. Then either install the debug version, which sucks, or put it somewhere else and hope the part you're fixing doesn't use the non-debug version. And that is even ignoring the actual effort about fixing the actual bug...
A shell script? add a ``set -x'' to find out what's going wrong, edit to fix, which is usually no problem for someone who knows their shell.

You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.

So why did you post on a Ubuntu systemd specific discussion if you use *BSD and have only tried Arch ? AFAIK Debian still provides support for /etc/network/interfaces with systemd so basically nothing changed for the users.

Perhaps because I had some impressions with a journey into the systemd world to share? I do manage a few hundred Debian machines at work, so i'm not a complete stranger in the linux world.

Why do you put whitespace in front of question marks?

Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...

Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).

I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.

I don't understand you, really. The procedure you mentioned was the bare minimum if you don't want to use any helper scripts or applications and is almost identical to what you need with system V init to get the same functionality: the configuration file and the two scripts are absolutely not related to systemd at all. The difference is that with system V init you need to write a script with a start) and stop) method while with systemd you have to write a service file. At the end this is exactly the same number of files, so what your problem ?

systemd-networkd is only an alternative. Personally I largely prefer C code over scripts, mainly because C code projects tend to be adopted by many distributions while scripts tend to remain specific to each distribution. The systemd vs system V story is an very good illustration of this difference.

You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.

So why did you post on a Ubuntu systemd specific discussion if you use *BSD and have only tried Arch ? AFAIK Debian still provides support for /etc/network/interfaces with systemd so basically nothing changed for the users.

Well, there is probably a lot of even more complicated methods.

I'm sorry to hear it.

Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...

Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).

I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.

I hope this one is simple enough for your use case.

No, it's not; and more to the point, I don't have a real "use case". As said:

The other day I had a spare machine sitting around [.........] [and then] I nuked [it]

You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.

Why oh why would you put the parsing of HTTP at the kernel level?

They probably saw that FreeBSD has been doing it for 15 years and thought it might be a good idea.

This is the kind of stuff which needs to be in userspace, not the friggin OS.

Apparently not everyone agrees with that.

I'm in no way a Microsoft apologist, but it's not like a senior engineer rolled out of bed one morning, smoked some crack, and yelled "hey, let's break some crap today!" Lots of stuff is done in kernel mode in Linux and the BSDs - like all kinds of graphical mischief - and MS probably does the same things for the same reasons.

And my favourite line:
locore.S
                call hammer_time /* set up cpu for unix operation */

So they reinvented what was already available and much more flexible with ipfw/dummynet?

So they reinvented what was already available and much more flexible with ipfw/dummynet?

Perhaps you would like to point to a set of current Gnome packages that dont have any SystemD dependency?

How current do you want?

https://forums.freebsd.org/threads/gnome-3-14-port-is-solid.49299/

Or do you think FreeBSD runs systemd now?

Then they open sourced it.

Kinda, sorta. What they didn't do, is release it under a BSD license, so that the project which they stole their userland from could actually use their code. And ever since 2005 launchd on FreeBSD has been languishing in limbo, Google SoC support not withstanding.

So, as usual, fuck Apple.

The "code was touched" in order to bring some new features in. Here is the commit for that branch to /dev/random r 273872

This is the much-discussed major upgrade to the random(4) device, known to you all as /dev/random.

This code has had an extensive rewrite and a good series of reviews, both by the author and other parties. This means a lot of code has been simplified. Pluggable structures for high-rate entropy generators are available, and it is most definitely not the case that /dev/random can be driven by only a hardware souce any more. This has been designed out of the device. Hardware sources are stirred into the CSPRNG (Yarrow, Fortuna) like any other entropy source. Pluggable modules may be written by third parties for additional sources.

The harvesting structures and consequently the locking have been simplified. Entropy harvesting is done in a more general way (the documentation for this will follow). There is some GREAT entropy to be had in the UMA allocator, but it is disabled for now as messing with that is likely to annoy many people.

The venerable (but effective) Yarrow algorithm, which is no longer supported by its authors now has an alternative, Fortuna. For now, Yarrow is retained as the default algorithm, but this may be changed using a kernel option. It is intended to make Fortuna the default algorithm for 11.0. Interested parties are encouraged to read ISBN 978-0-470-47424-2 "Cryptography Engineering" By Ferguson, Schneier and Kohno for Fortuna's gory details. Heck, read it anyway.

Many thanks to Arthur Mesh who did early grunt work, and who got caught in the crossfire rather more than he deserved to.

My thanks also to folks who helped me thresh this out on whiteboards and in the odd "Hallway track", or otherwise.

My Nomex pants are on. Let the feedback commence!

You can see the list of those who reviewed and commited the code in the link. They are all longtime contributors.

The problem was:

When the new random adaptor code was brought it in r273872, a call to
randomdev_init_reader to change read_random over to the newly installed
adaptor was missed. This means both read_random and arc4random (seeded
from read_random) were not returning very random data. This also
effects userland arc4random as it is seeded from kernel arc4random.

So there was a problem was that the new adaptor was not 'retro-fitted' to the existing code. A simple thing to miss - I've done this many times in refactoring code. The generated was getting new seeds from the old function and not the new one.

No, and who mods this "Informative"?
Both -CURRENT and -STABLE are development branches.

-RELEASE is meant for production and of course gets supplied with security relevant fixes (then referred to as patchlevels).

But yes, please go on educating people about things you don't know jack about.

No, and who mods this "Informative"?
Both -CURRENT and -STABLE are development branches.

-RELEASE is meant for production and of course gets supplied with security relevant fixes (then referred to as patchlevels).

But yes, please go on educating people about things you don't know jack about.

Bleeding edge software has bugs?? what

Many people run CURRENT, so if they put their pubkeys on servers they could possibly be guessable. Try reading the article next time.

Yes they do, yes they could, no it's not news, it's on the current branch... In true BSD style i'm going to say RTFM: https://www.freebsd.org/doc/en... Current is not intended for production, end of.

The -current is not a release — it is the trunk of the development tree. Using for anything important — such as data, that may be worthwhile enough for your enemies to hack for — is silly. Far worse bugs may exist in -current — or be introduced at any point.

Stick to releases — or one of the -stable branches — for anything, that's not about working on FreeBSD itself.

Take a look at FreeBSD Gnome, for example. I am sure that their patches to make Gnome portable again flow back upstream.

Perhaps, but this is exactly what I said; only the minimal effort to make the DE's run on BSD is made by BSD developers; when it comes to making the actual DE there seems to be no BSD developers helping out. In short, BSD developers aren't pulling their share of the load when it comes to DE development.

OpenSSH is portable. This is the difference between Linux and BSD developers. [snip: the usual anti-Linux ranting]. most Unices/BSDs already have the solutions for the problems and why should they accept something that has to be ported with a lot of effort? It is only being done with things that are worth to port.

Exactly, this is why DE's like KDE and Gnome shouldn't accept BSD patches anymore, but just make the BSD developers maintain the DE's in their own source trees, just like OpenSSH. If it is worth for BSD to maintain them, then they can do it, if not, then why bother Linux developers to make it BSD compatible.

As it is now, BSD is simply dragging Linux DE development down without the BSD developers contributing anything instead. At some point this has to stop; either the BSD community starts contributing, or the Linux community will stop working for free.

Take a look at FreeBSD Gnome, for example. I am sure that their patches to make Gnome portable again flow back upstream.

When someone develops an desktop environment that does not restrict users to Linux, you should expect from them to make the system portable. The work to make it run should be minimal.

Wayland is being ported to FreeBSD, too. It is a bit useless though, because of Linuxisms in libinput and Weston.

OpenSSH is portable. This is the difference between Linux and BSD developers. BSD developers stick to the Unix concepts and portability has a high value here. Linux developers invent (mostly already existing) solutions by themselves, multiple times, multiple times in a wrong way and mostly for themselves, because... most Unices/BSDs already have the solutions for the problems and why should they accept something that has to be ported with a lot of effort? It is only being done with things that are worth to port.

The answer is yes.

The answer is yes.

The first thing you need to insure is that there is a MBR compatibility mode for your motherboard, which for your machine should be IPISB-CU (Carmel2), so this is possible. Once you have that, you can probably figure the rest out in the wiki, or better to ask in the forums. I could give you some help but maybe slashdot is not the place for that. I hang out often in #freebsd so you might catch me there, and in general there are many helpful people there.

You will notice that I put the links for FreeBSD for the PC-BSD. The only real difference between the two is the software repositories. In fact you can easily convert a standard FreeBSD to PC-BSD simply by changing a few configs. You might try that route if you want a quick desktop install. I prefer to 'roll my own' but the PC-BSD guys have really done a lot of good work putting in good defaults.

The first thing you need to insure is that there is a MBR compatibility mode for your motherboard, which for your machine should be IPISB-CU (Carmel2), so this is possible. Once you have that, you can probably figure the rest out in the wiki, or better to ask in the forums. I could give you some help but maybe slashdot is not the place for that. I hang out often in #freebsd so you might catch me there, and in general there are many helpful people there.

You will notice that I put the links for FreeBSD for the PC-BSD. The only real difference between the two is the software repositories. In fact you can easily convert a standard FreeBSD to PC-BSD simply by changing a few configs. You might try that route if you want a quick desktop install. I prefer to 'roll my own' but the PC-BSD guys have really done a lot of good work putting in good defaults.

That is complete bullshit. Have you even looked at the source code of launchd and systemd?

Launchd actually is POSIX compatible which is why it has already been ported to FreeBSD. Systemd does not even consider POSIX compatability something to be desired.

If anything, porting GNOME will be a royal pain in the ass now. In fact many opensource projects like OpenBSD are writing shim layers to insure "systemd comptability" in order to facility cross compilation of Gnome Desktop.

When open source projects have to provide an emulation layer for an init system in order to port open source software there is something terribly wrong.

You may be right, but there is such a thing at making your grip on something so tight that it escapes you grasp (e.g.g if you grip dough too tightly).

LLVM is a good case in point. The GNU, via the GPLv3, has created a situation in which companies such as Apple who are not interested in the politics of Open Source or Free Software, and aren't seeking a competitive advantage in compilers became unwilling to work with the free software community because the free software community tried to do an embrace and extend on them.

As Linus pointed out, the GPLv2 license was a good license because it imposed fairly acceptable conditions on companies. The GNU thought they had the likes of Apple by the balls, so to speak, and they tried to squeeze. Apple and others (including the BSDs) simply went to LLVM, and it is looking like LLVM is going to surpass GCC in all metrics that matter.

In fact, Apple originally worked to relicense LLVM under GPLv2 with upstream GCC https://forums.freebsd.org/thr... , but was denied by GCC developers. So GCC lost what was potentially a very good contributor Apple is now the largest company in the world - can you imagine how much better GCC could have been with a company the size of Apple working to improve the quality and performance of the compiler?

Now BSD and Mac OSX can be argued to have access to better compiler technology than GNU and Linux (although LLVM can be used under Linux). With Apple's support, free software could have been even further ahead, but politics ruled. The FSF/GNU could find itself made irrelevant if they continue to put petty politics and ideology above ensuring that free software is among the best software by engaging companies like Apple where it makes sense to do so.

Can you imagine if Apple had acted like GNU with respect to Samsung. Even when Apple was fighting Samsung on one hand, they were still prepared to buy a lot of gear off Samsung in a mutually beneficial relationship, and Samsung was willing to supply its biggest competitor with chips and other electronic gear that was going into products that were competing directly against its biggest moneymaker. Both companies, however, acted in a grown up manner to reach a mutually beneficial arrangement while continuing to kick lumps out of each other in the courts, in advertisements and in the markets. GNU acted all childish over LLVM and Apple's (and BSD and Linus) contributions to issues such as GPLv3 and accepting code that would enable GCC to work better for everyone, not just Apple.

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.

Nobody within the FreeBSD community gives a fuck what Hubbard thinks about this matter. Nobody within the FreeBSD community takes his init system ideas seriously.

Look at the FreeBSD Core Team Alumni list and you'll see:

Jordan K. Hubbard (1992 - 2002)

He was a major player at one time, over a decade ago. That's not the case today.

In fact, if you actually followed any of the discussion regarding this matter, you'd be aware that the majority of people were against anything remotely like systemd or launchd.

The BSD community in general isn't made up of the nancies who make up the Debian community. The BSDers are totally focused on stuff that works, and they generally don't give a fuck about dumb social causes and idiocy like systemd, like the Debian crowd does.

Linux isnt Unix. Unix is that way.

The fix has already released

Here you go. Please tell me how the poor sod has any hope of getting anything back without a proper repair tool. Oh yeah, I forgot, when your blood runs thick with ZFS koolaid, all those unrecoverable pool errors out there never happened.

Patches to Linux do actually work.

Bottom line for what you want, which is FreeBSD, start with the manual.

Then go to the releases and pick the latest production, i.e. stable, release (Currently 10.1). Everything will be stable and binaries and source packages for your desired functions will all be available and up to date.

if you want a dedicated machine for one specific purpose, then another BSD might be better, but for multiple purposes/general purpose, just use FreeBSD. It'll be just as good as the others for specific purposes (just not by default, you'll have to run a command to install software, big deal), many of which have a FreeBSD source.