[nycbug-talk] Switch to FreeBSD from RHEL
carton at Ivy.NET
Fri Mar 6 14:17:46 EST 2009
>>>>> "sk" == Steven Kreuzer <skreuzer at exit2shell.com> writes:
He is only sort of right about Linux release engineering. Bitkeeper
was replaced by git pretty quickly I think, and it is not just git,
there is procedure surrounding it.
First, there isn't a development branch with odd numbers any more, at
least none that I ever hear of. Even in Linux 2.2/2.3 days most work
was already happening on 2.2 and then getting forward-ported to 2.3 by
dilligent frustrated people, and now no one ever talks about odd
branches, especially developers. All the work happens on
mini-branches off the stable (even) trunk. so, depending on what you
are working on, you'll have a stable kernel plus development bits for
your area of interest. Also the even trunk is allowed to become
unstable between releases, which is not true of BSD's stable branches.
Second, they are using git, which I think allows them to be extremely
stingy with repository access compared to BSD. Almost nobody has it.
But you can have local branches in git, so a read-only repository plus
git works well with this stable-plus-a-few-development-bits. I think
it may actually be better than what BSD does for the developer, though
for a sysadmin it's a disgusting mess because you usually do not have
access to all these private git repositories spread all over the
place---the only one who can see the true history of the development
of a certain subsystem is the guy working on it in his local
repository, unless you want to try to piece it together through the
``patch sets'' he spews to mailing lists, but these don't get tracked
in the main git tree, just sort of spewed.
I think the private-branch thing is bad in that it tends to make
people territorial about their code, BUT (1) bigger projects will have
their own public git server so you CAN see their work-in-progress,
though I'm not sure how easy it is to incorporate it into your kernel,
because I've not learned how to do anything but download with git, and
(2) honestly BSD has had *way* more problem with unproductive people
remaining territorial about old, broken code when less skilled but
vastly more productive people want to work on it, than Linux has, so
the claim ``spread-out private repositories and stingy global git/cvs
access makes people more territorial than generous cvs access''
doesn't really wash with history.
Third an important part of Linux revision control is these patchsets
they mail around. There is a special git command for generating
patchsets in an acceptable form for email, and there is some kind of
political procedure backed by code for tossing aruond these patches
that I don't understand. I'm following a smaller project, the
UBI/UBIfs/mtd project, because I want to figure out when they will
support mtd partitions >2GB so I can (ab)use it for USB sticks. I
can't figure out if they're emulating the Linux-kernel patchset
political framework, or actually participating in it.
The criticism that things like 'ifconfig' (or 'ip' which is what they
use on Linux instead of ifconfig) are not revision-controlled along
with the kernel is fucking spot-on. They are living out some bogus
fantasy with all this basic housekeeping they want to ``leave up to''
the distributions, and they ought to knock it off. That said, the
Gentoo tree is something in which you can make a 'cut' like BSD. And
it sort-of has branches, but not in the revision control software.
They have 'keywords' in portage, so each package will have a stable
'x86' version and an unstable '~x86' version. You can build an entire
system with '~x86' to get the newer, less-stable packages. When
they're ready they'll mark a newer package as 'x86' and move it into
the stable system. but what ~x86 does, is fetch slightly newer
tarballs and then build them. It doesn't give direct access to a
revision control tree like BSD. It's a serious deficiency of Linux
that there's such a barrier to getting from a binary on your system to
a revision-controlled source tree used to build that binary. They
need to find some way to keep their idea of ``distributions,'' but turn
sourceforge/Savannah into one giant git repository from which all the
``the stricter separation of "base" vs "ports" in BSD, as well as the
structure of the ports tree itself, make it easier to have multiple
parallel versions of packages in BSD. Sometimes, it's even possible
and easy to have multiple versions installed at the same time.''
disagree, Gentoo handles this much better than pkgsrc/ports.
but discussion of package management can't be Linux vs. BSD because
Linux has so many different package managers. It needs to be Gentoo
vs Centos/RHEL vs Ubuntu vs pkgsrc vs freebsd-ports vs openbsd-ports
vs OpenSolaris/IPS, or else it gets confusing.
My favorite so far is OpenBSD ports because they disallow USE flags
and package ``options'' which I think are a disaster. but a real
package management system needs the support of a
sandbox/chroot/snapshotting-filesystem---I'd like to see that. NetBSD
has the right idea with their bulk builds of forcing packages to build
in an environment that has only their declared dependencies available,
but I think it could be much faster with a libc sandbox or kernel
support. Also a good package system which AFAIK doesn't exist yet,
should be able to parallelize builds not with 'make -j2' but by
looking for wide areas of the dependency graph and building separate
packages independantly. And finally it should be possible to do
cross-builds using emulators, not using autoconf. Run most of the
build inside the emulator, but have fancy wrappers that can break out
of the emulator for running certain safe programs natively, like a C
cross-compiler, gzip, nroff, u.s.w., but as far as the Makefile can
tell it's running on a real MIPS CPU.
``If it's written reasonably portably, 95% or better of it will
compile right off on any vaguely POSIX-compliant system.''
hah! yeah, sure, POSIX. Unless it happens to be a programming
language (Java, DalvikRE, Haskell, Lisp, Erlang), an extremely large
program with its own GUI widgets, module ABI's, reflection-layers
(Firefox/Chrome, Xorg, Openoffice), heavily-subpackaged (Ruby, Perl,
Python, Gnome, KDE, emacs), or is a web service held together by spit
and duct tape (Zimbra, Socialtext) or anything else not written in C
and thus *not POSIX* (slap!) such as CouchDB/H2, cvsup/git/hg/darcs.
Then, you're in trouble.
In short, if the Linux app in question is a single-threaded forking
TCP listener written in 1980 and building with GNU autoconf, fine for
BSD, minimal effort. If it's anything remotely interesting, like any
of the programs people like to run these days and spend most of their
time using if the people in question are not boring ponderous
dinosaurs, anything alive and interesting and not fossilized, then it
will be a major undertaking to get it working on BSD if its developers
are working on Linux. He is so disastrously wrong on this point, and
so harmful to anyone gullible enough to buy his POSIX crap, though it
does not affect Matt since he is using only fossilized LAMP software.
but please do not let yourself be trapped by this baloney in what
ought to be an extremely exciting time for software, a real
possibility at finally something post-Unix and still Free.
sk> For whats its worth, during the 90's porn boom, most of the
sk> sites hosting adult content ran FreeBSD because it was able to
sk> handle large amounts of traffic.
...heh. yeah but what do they run now? Linux, ngix, lighttpd?
sk> However, Getting web sites to scale depends on much more then
sk> the underlying operating system. Its something that I could
sk> talk about for hours without mentioning the OS once.
k fair enough.
sk> Check out http://people.freebsd.org/~kris/scaling/mysql.html
so maybe the analog to the way BSD people always slam Linux for unfsd
that they haven't used in 15 years, is Linux people slamming
FreeBSD/mysql based on FreeBSD 6.x.
what's this about mysql 5.1, though? it's faster on Linux than BSD,
or it's slower everywhere?
READ CAREFULLY. By reading this fortune, you agree, on behalf of your employer,
to release me from all obligations and waivers arising from any and all
NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap,
browsewrap, confidentiality, non-disclosure, non-compete and acceptable use
policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its
partners, licensors, agents and assigns, in perpetuity, without prejudice to my
ongoing rights and privileges. You further represent that you have the
authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 304 bytes
Desc: not available
More information about the talk