Dev.SN ♥ developers
Sections
Dev.SN
from the Boot-him?-I-just-met-him! dept.
jbernardo writes:
"Having had several issues with systemd, and really not liking the philosophy behind it, I am looking into alternatives. I really prefer something that follows the Unix philosophy of using small, focused, and independent tools, with a clear interface. Unfortunately, my favourite distro, Arch Linux, is very much pro-systemd, and a discussion of alternatives is liable to get you banned for a month from their forums. There is an effort to support openrc, but it is still in its infancy and without much support.
So, what are the alternatives, besides Gentoo? Preferably binary... I'd rather have something like arch, with quick updates, cutting edge, but I've already used a lot in the past Mandrake, RedHat, SourceMage, Debian, Kubuntu, and so on, so the package format or the package management differences don't scare me."
[ED Note: I'm imagining FreeBSD sitting in the room with the all the Linux distros he mentioned being utterly ignored like Canada in Hetalia.]
(Score: 0) by dbot on Wednesday February 26 2014, @11:19AM
So, what release are you running, and what version is the browser currently running on your system? (I'm assuming you have a browser, it sounds like a desktop config.)
I can almost guarantee your browser is out of date, to the point that if someone wrote a FreeBSD exploit, you'd be exploitable. The same goes for any other third party software running on the machine.
Where you really run into trouble on FreeBSD is recursively updating the ports tree, over, and over, and over, for each security fix.
There's some really smart people working on the system, and in general, the operating system is simply awesome (pf, zfs, geom, etc, etc, etc), but for all that: the project overall hasn't addressed the elephant in the room - that the ports tree has 24650 ports [freebsd.org] with interdependency galore, and to update one library for a security fix (or installing a package later on) means recursively updating every inter-dependant package to the latest, api/config file-breaking or not, version.
Maintaining a secure system over time is a huge task. Stuff goes wrong building, all the time - the state of the ports tree is constantly in flux.
Extra credit: Install the latest 10.0-RELEASE 'desktop' system, and update firefox ('cause it's out of date already, I'm sure). Better yet, use pkgng, or portupdate, and do a binary recursive update - forget building from source and make your life easy.
I'm considering Debian/kFreeBSD for this reason for my next server build. I haven't played with it to know where the trouble spots are yet though, so it might be a world of pain for other reasons.
The idea of back-porting security fixes to a -STABLE ports branch (with no api or config file breaking changes), with signed binary updates, is a concept that has been not addressed in the slightest by the project - to my knowledge. I believe it's the only sane way to deal with actually running a system over time though.
pkgng is lipstick on a pig - it still is just running the bleeding edge of ports. That's a design problem.
My gut says: it's O(N^2) hard to build recursively (status quo), where back-ports make it O(N) hard, where N is the number of ports installed on a given machine. O(N) because you only need to update that one package, not its dependencies. Also, you don't need to update that package's config files, so even in the case where it's just one package, you are still further ahead.
Obviously back porting security fixes for ~25k packages is a lot of work. I'm not going to do it. My point being that the problem is structural for the project. I don't need the latest and greatest. What I need is a stable config that works for a time. Whether it's a year, or two years, or whatever. This isn't owed to me, I'm just going to try and balance this with my other needs, and choose software that fits.
TL;DR; There's a lot of great things about FreeBSD. Keeping up to date, or installing new stuff later is not one of them.
(Score: 3, Interesting) by fnj on Wednesday February 26 2014, @12:49PM
FreeBSD is quite a bit of work for a desktop. It's not like a linux distro, where everything has been massaged to make sure it fits together well and the defaults are sensible, fonts are pretty, etc. PC-BSD is the obvious choice for desktop, just like FreeBSD is the obvious choice for server. PC-BSD is just a polished FreeBSD.
That said, I have absolutely zero problems with pkgng. I type "pkg upgrade" and presto. Everything works, up to date with respect to this week instead of last week.
In practice I don't have any real problems due to riding the bleeding edge with either FreeBSD or Arch. I have all kinds of problems with ancient frozen snapshots from the year 2010 (like RHEL6). That crap is just so out of date for desktop use it's ridiculous. Would I use a rolling release, aggressively updated, for a critical server? Of course not.
(Score: 1) by dbot on Wednesday February 26 2014, @01:25PM
(Score: 1) by GeminiDomino on Thursday February 27 2014, @10:51AM
Has FreeBSD changed that much? It's been a (long) while since I last worked somewhere that we used it, but 4-STABLE didn't seem particularly "aggressive" in its updating. Just hella time-consuming to do it, which is why I haven't put my weight behind it where I'm at now(waaay more machines.)
"We've been attacked by the intelligent, educated segment of our culture"
(Score: 3, Insightful) by drussell on Wednesday February 26 2014, @03:48PM
It is true that interdependencies are an issue, but they are an issue with Linux as well. You either use an old version of a library for all your installed programs or you update the library and everything that depends on it when there is a change that breaks something. I've honestly had more issues with updating things on Linux when I've used it for things than I've had on FreeBSD, but of course YMMV.
The binary updates with pkgng (which is now the default in 10-) should usually handle everything for you as long as you don't have a bunch of custom programs/builds/etc. but again, this just really depends on what you're doing, I suppose. Custom stuff relying on strange/old libraries can be compiled with the libraries statically linked in, for example, removing the reliance on something that may change for other reasons, etc.
Ports maintainers strive to maintain a given port's buildability on not only the current developers' branch (right now that would be 11-CURRENT) as well as the latest (10-STABLE) and previous (9-STABLE) 'stable' branches intended for the end-user. Often they manage to keep them running properly much, much farther back, it's just not one of the main project goals. It's not uncommon for me to painlessly build a latest version of a port with no modification on a system that is 4,5,6 or more versions obsolete. There are buildbots that constantly build these and build failures are generally fixed as soon as possible. If you've got an (perhaps 8-) or 9- box, you should still be able to just do a make install in any port directory, and it should fetch, compile, install just fine. The ports tree is one tree, there aren't separate trees for different branches/release versions but when security or other updates are applied, it IS checked to be sure it still runs on -STABLE.
My experience has been precisely the opposite. I still have internal machines here running 2.x, 4.x, 8.x, 9.x and 10.x for various purposes and reasons and I've always found it far easier to keep what I need up to date on FreeBSD than Linux. It's actually one of the main reasons I DON'T use Linux except in a few niche cases (like on one MythTV frontend box in a system for tuner card support with the other frontends and the backend running FreeBSD)... Things seem to constantly change and it's a contstant update/support nightmare! I end up manually uninstalling and re-installing things that were supposed to update themselves due to some non-obvious dependency or change somewhere breaking something else. I find the FreeBSD system MUCH easier. To me, the dependencies and such seem more clearly marked. Sometimes that means a port is marked 'broken', but then I have the option to find the broken-ness myself and fix it or work around it when I need something specific/strange/downright wierd and nutty to work the way I want.
Users that aren't so savvy shouldn't really see much difference between a 'pkg upgrade' on FreeBSD or using one of the binary update mechanisms used in the various Linux flavors. In most cases any of these systems will look at your system's version and current state, make the best decisions they can as to what should be updated and from which repository of binaries, fetch and install.
I'm sure the on Linux way is more comfortable to one familiar with that particular system just as the FreeBSD system is second-nature to me but essentially they're all doing the same thing.
(Score: 1) by drussell on Wednesday February 26 2014, @04:58PM
That was supposed to read:
Silly me, using the wrong brackets and not noticing it in preview... :)
(Score: 1, Interesting) by dbot on Wednesday February 26 2014, @10:57PM
I respectfully disagree. They are not doing the same thing at all. The key being: fixes are back-ported to a static version of a library. So imagine on your 2.1-RELEASE, there was a ports tree freeze. That is the 2.1-RELEASE port tree, forever. Now, during the supported lifetime, security issues, or major bugs occur in those ports. Critical fixes from the latest upstream source are backported down to the 2.1-RELEASE tree, for the supported lifetime of 2.1-RELASE. No major version bumps. One day, when your production schedule permits, you upgrade to 2.2-RELEASE, and now you've got all the api+config file changing updates in one fell swoop.
Right now, it's: upgrade to the latest upstream version, recursively.
I don't know if you've used Debian + apt, or CentOS and yum to use some canonical examples. The repos have stable versions of the software, and have major fixes backported, for a release (as mentioned above). That is, you run an old version, with non api/config fixes backported. Periodically, these repos are updated to more cutting edge software, so you aren't running things 2+ years old, but by and large, the software you run will be the same version until you update. So when you say more issues, how are you installing software and dependencies, on which distro?
Here are some examples of things that have been a pain over the years:
autoconf
gettext
gmake
libiconv
*perl* omfg
ruby (if you use portupdate)
php
I think by the way this is phrased, people might get the impression that they are testing things on old releases. They are testing build success, periodically, for supported releases.
Anyways, I think that this discussion illustrates pretty quickly my point. There is total failure to acknowledge that this is a problem. I believe it is, for my uses. I'm not saying They Should Fix That, because it's a volunteer project. I'm not going to do it. I'm saying this isn't even in the discussion when talking about 'fixing the ports system'.