Miscellania BSD: Die Elixiere des Teufels ?
Here is a temporary placeholder, by now mainly a repository of binary packages for a couple of operating systems I use the most home.
Daemon specie: NetBSD
NetBSD is my preferred.It's a good alternative on old sparcstations since the SMP support. It seems that nodoby longer care about running Sparcsen of the pizzabox kind, the SS4,5,10 and 20.
Everybody sings the portability and the support for many architecture, for instance linuxians do often.
And the fact is that you get a bare OS running on old boxes, but besides OpenBSD, you'll find no up-to-date binary packages and have to build from sources.On a slow box it takes times.Last time I did it for NetBSD sparc32, I decided to put the packages on line.
Here: NetBSD-2.0.2 sparc build on an SS10 biproc.
On a slow sparc, an issue is the web browser: until now Mozilla/Firefox have been taking to much resources and proven slow.
Nothing is faster than the old Netscape 4.x, despite their lack of support for current standarts.They are still usable on many sites.
To run the Sun 4.x version on NetBSD or OpenBSD the old libraries are available from Sun, according to the instructions here:
How do I set up SunOS/Solaris emulation?
Well, here the SunOS compatility files for the emulation layer of NetBSD or OpenBSD.
Daemon specie: DragonflyBSD
I disliked this one at first because I'm lazy and it takes for a while to type in the name.Couldn't they chose a name like NewBSD or HeheBSD instead? Then the mascot was a dismay.I like so much devils, evils, demons and all the satanic entities.What the heck with a dumb and ugly insect? Anyway, I was rather interested by this FreeBSD fork, just because I didn't like much the feel of the new FreeBSD from the 5.x release, in a very subjective way.The installer is much better under Dragonfly, more control as well as simple, much less prone to botch your partitions and mbr if you are tired at installation time.
Binary packages for DragonFly
Building on DragonFly is very similar to FreeBSD-4.x at the time of releases 1.0 and 1.2.The only small fix was to create the needed machine and system definition files needed by the GNU autotools (autoconf, automake, libtool), since most userlands nowadays follows the GNU paradigm.
As of beginning Januar 2006, I see that DragonFly 1.4 is ready, so I have installed it .The NetBSD pkgsrc maintainer(s) seems to take care of the needed system definitions for the bmake process and patches are being submitted to the pkgsrc tree.I always considered pkgsrc to be more consistent and easier to maintain than the FreeBSD port.Having most things in /usr/pkg is clean and neat, and one can still play with homebrew stuff in /usr/local for instance.A better alternative to ports in /usr/local is, IMHO, the traditional SVR4 package used by Solaris.
GoBSD.com has a nice binaries repository built at the time of DragonFly-1.3.7.
I have tried the usability of DragonFly-1.4 as a desktop for daily usage, and how pkgsrc does work on it.Here is my repository of packages:
All is build on a PentiumIII 1Ghz box, and c++ stuff takes much time to buid.I am still adding packages on the way, as they get beeing build.I'm interested in knowing if these binaries work well and are useful for others.
DragonFly-1.4.0-RELEASE pkgsrc binaries
Software that you get here, which are not found on the GoBSD archive are:
- Kde 3.5: the base desktop with of course Konqueror and most locales
- Kdewebdev 3.5: I build always Kde because Quanta which is a very good web authoring tool
- Editors: Abiword and plugins, Lyx-xforms, Emacs
- Graphics: Gtkam, Gthumb
- Print: CUPS, all the Foomatic stuff
- Maths: Gnumeric
- Chat: GnomeICU, Gaim
- Net: Etherape, Gftp
- Multimedia: Dvdrip, Gmplayer and all codecs
- Audio: the Grip ripper/encoder from thw WIP tree
- Security: Gpa (gtk gnupg frontend), Seahorse (Gnome gnupg frontend)
- Window managers: Afterstep(2), Fvwm2-Themes
- X11: wxGTK, py-wxWidgets
Important remarks about the binaries:
- DragonFly doesn't ship its own X tree, which actually makes things easy.Pkgsrc source defaults the X location to /usr/pkg/xorg/, so a simple symlink is all needed to make happy any other software:
link -s -f /usr/pkg/xorg /usr/X11R6
- Few sources needed tweaking.
I had to slighty fix one or two files in gnome-vf2, gftp, grip, cdrecord-xcdroast, gnumeric.
I haven't gone into real issues, as it's just by now a global try at how things do feel.
Some rough edges here and there by now.
- The Linux emulation: Suse packages are here, and Opera is working but most other tries with Firefox spits out the TLS error, despite all the needed linux /proc, elf branding, wrapper calling, etc
- Gnome: the control center is missing, because libgtop2 is pesky to build.I had an idea for some patch but still am not sure about the correctness.
- cdrecord: mine, or the one from the GoBSD repository doesn't work with my SCSI burner (which works under cdrecord for any other OS I use, from UnixWare to Linux and more exotic things.
But cdrdao works, so to burn ISO data files, the recipe is:
write a TOC file:
CD_ROM
TRACK MODE1
DATAFILE "file.iso"
and then:
cdrdao write --device x,y,z TOC
Daemons and Coffee
Coffee isn't easily available for daemons.They must roast, grind the beans and brew it themselves.But, if it's time consuming, when one is in a hurry, the process itself is well known.Here is the recipe as summarized by the OpenBSD people
The JDK ports are in the devel/jdk subdirectory of the ports tree.
You can choose among different versions, each in their own subdirectory.
Only the 1.3 and 1.4 versions have a browser plugin.
When you just type make, you will see a message asking you to
to fetch the source files manually from Sun's website.
Before you can do that, you need to register on that website, and agree
with the license.
That's why the ports framework cannot start the download automatically.
Once you have downloaded the necessary distribution files and patch sets,
copy them to the /usr/ports/distfiles directory and start the
build by issuing make in the port's subdirectory.
The JDK requires a working Java 2 compiler as a bootstrap to build.
For this purpose, the port uses a Linux version of the JDK.
If you feel this is unfair, you should ask Sun why they do not provide
a native OpenBSD version.
Linux emulation on OpenBSD is restricted to i386 systems, and so the
JDK will build only on i386.
The ports framework should take care of installing the necessary files
and setting kern.emul.linux=1.
For more information, please read about Linux emulation in the
compat_linux(8)
manual page, and also
FAQ 9 - Running Linux binaries on OpenBSD.
Note that this Linux emulation is only required during the build of the
JDK, which results in a native OpenBSD JDK.
You do not need Linux emulation to work with the native JDK.
After many hours, the build will finish.
Just continue with make install to install the JDK.
In NetBSD, the easy way to brew coffee is by using the Work In Progress pkgsrc tree:
wip-pkgsrc
It's in /usr/pkgsrc/wip/jdk14
In FreeBSD, like for OpenBSD, it's in the default ports:
/usr/ports/java/jdk14
In my experience such builds are always quiet and successful, even if quite long.As a proof one can see
here the actual binary packages, with their respective big sizes:
