Today I posed this message to several of the LUG’s in South Africa. I am reposting it here without edits.

Hi Everybody,
Sorry for the cross-post, I promise it’s a once-off but this is a bit of a special circumstance.
In the grand tradition of GNU and later the Linux kernel, I am beginning with a mail to announce
my intentions, and a request for anybody who shares my vision to help out.
The interest in my CLUG talk about distribution creation some time ago left me thinking that
perhaps there are enough people out there (particularly here in South Africa) who may feel up to
the fun and work of helping to create something special. Having spent 5 years creating a
successful commercial distribution, I believe I have the skills for such a project to be workable, though this one is meant to be very different as you’ll see.

Starting in the next weeks I want to create a GNU/Linux distribution called kongoni. Kongoni is the
Shona word for a gnu (wildebeest) and this represents the origins of the system: firstly it is African,
secondly it is meant to be a truly free distribution of the GNU operating system.
The name in other words translates literally as: GNU Linux (I rather like the wordplay as well).

Fundamental to the design will be an absolute commitment to free software only. That means we will not
include in the installer, nor in the ports tree or any other officially distributed packages any piece of
software that is not under an FSF approved license.
Some degree of the workload can be shared by utilising (and contributing back to) Gnewsense’s list (and blacklist).

Development releases will have a kernel compiled with the no-taint flag – not allowing any non-free drivers to load,
which will be very useful for auditing purposes, where possible we will provide free alternate drivers.
UPDATE: I should have been more clear here. I mean ONLY development releases will have notaint, official releases will not restrict what users can or cannot load.

Where possible I want the system to actively contribute to high-priority free software projects like GNASH and Nouveau,
not least by providing automated scripts in the packages to allow even non-technical users to file automated
bug reports to the projects with usefully information for their needs. Thus possibly increasing the number of testers
exponentially, the improvements that arise will in turn benefit all free software users and developers.
The system will never be commercial, I have no problem with commercial free software (in fact I run a commercial free
software company) but this project would best benefit from being a true community project. If the need arises to
formalize structures, I pledge that it will be done by registering a charity organisation, or joining an existing one
– not by starting a company. If people some day want to start companies that sell services related to the system however
more power to them.

Now on to the initial technical details. First off, I don’t think there is any room in the market for yet another Ubuntu
respin. Ubuntu is a nice system in many ways, but the need is met – and Gnewsense already provides a fully free alternative
to fans of Ubuntu. Instead I believe there is room for new ideas and new thinking.
To this end I want to start with a slackware/bluewhite64 baseline initially targeting x86_32 and x86_64 platforms.
Slackware has many advantages as a baseline and offers enormous power of (easy) customization to give the system a real
unique identity while staying true to standards.
The biggest catch is addressing slackware’s number one shortcoming for desktop users: the limited package manager.
To address this, and also minimise the workload of multiple platforms, I intend to use portpkg to provide a ports tree
that is fully tracked for dependencies. Among my first coding tasks will be a full graphical frontend for portpkg as well
as a series of patches to portpkg itself to allow us to maintain our own ports trees as default. These will consist
of license-audited and dependency-mapped clones of the slackware/bluewhite64 repositories for upstream, and source-only
ports for 3rd-party packages. It is important to maintain our own ports tree since unfortunately all the default ports
available in portpkg include non-free software in their package lists. While we cannot (and should not) prevent users
adding those repositories and installing such proprietary packages – we should not give this action any official support.

The initial default desktop will be KDE4 with intention of including KDE4.2 (due in February) in the first stable release
if possible. OpenOffice.org 3.0 is on the standard packages list, and if the promised GNU/Linux port of Chromium is available by
release time it will be the default browser, otherwise one of the free firefox forks.
An absolute must is a powerful and complete system administration and configuration tool,
utilising things like darkstarlinux’s ALICE suite to complement a full kit for user-admin,
setting up advanced Xorg settings (like multiheads) and other common admin tasks. To ensure
seamless wireless and wired network roaming, wicd will be a default package (and madwifi with the new free ath5k hal for older cards and the newly GPL’d hal from Atheros as well).

It is quite possible that if we have enough volunteers and resources future releases could include parallel versions for
Gnome,xfce,enlightenment etc. and I am happy to include these in the ports tree if somebody helps create the ports.

In terms of project admin I wish to set up a suite of easy-to-use web-apps for contributing, auditing and approving
of ports (the first should be open to all, the latter two to trusted testers only). Designed to make the task
of contributing in this manner not only as simple as possible but to minimize the time needed as far as possible so
that those who choose to contribute their spare time to it can spend as much of that time as possible doing fun stuff
and as little as possible doing drudge work.

The focus of the project is home and desktop users, there are other distro’s aiming at this market but precious few
with a stated mission to be completely free, in both senses of the word.
After freedom, our second most important design principle should be one of “it just works”.

Now of course, as I type this Kongoni is vapourware, the first line of code has yet to be written (though I’ve done
significant amounts of research to make the decisions above, and I have written an installer).
Normally, it isn’t my style to announce something until the first pieces are written but in this case I
find it crucial to the very concept that other people be involved from the start. I have proposed a vision
(not an uneditable one technically) and I want to see who shares my vision and would like to contribute to it’s
realisation. I will be happy to fund hosting for the project and contribute much of my free time to it’s realisation
but I would like to have as many people helping as possible so that this is not just my vision, but our vision.
People who can suggest ideas and improvements, people who can help realise those ideas and help with the
large workload ahead.

If just a few people say “I’m in” – then that’s a go-ahead as far as I’m concerned.

The most useful skills right now will be:
*Web-app programming and web-design
*Ports builders and co-maintainers of the tree
*Graphic design
*Testers

These will likely get official lieutenants appointed on a first-come, first-serve basis.
There is much more to do so if you feel that you can contribute something please feel free to speak up.
If any of the mirror maintainers would be willing to host local mirrors of the ports tree and ISO’s when
we get to release time, please let me know as I have learned from hard experience how even a small distro
release can hit a server.

May I request that those who wish to contribute also reply to me directly as I do not want any
names to get lost in the noise as people discuss the idea.
Finally, I would like to suggest that those who are in Cape Town (once we have a list) meet up
for a face-to-face planning session. Perhaps over coffee on Saturday somewhere in Rondebosch ?

Thank you for reading this far
I hope to hear from you.

Ciao
A.J.

I got my hands on a copy of NeverWinterNights for Linux the other day, and I’ve been playing it whenever I have spare time at night – what a great RPG. Now before the flame comments start, I’m on record as saying I don’t think it’s ethically crucial that games be free software because they aren’t software to begin with – they are art. At least, they art part is far more important than the programming part.
Which is not to say it’s not very good (and certainly a lot better) when they are free software, but like with music it’s good when it happens, but not evil when it doesn’t.

So back on topic, I really enjoy NWN. It’s rules are familiar to anybody who knows even the basics of DnD or has played Nethack for that matter, and it’s filled with tremendous flexibility of gameplay (as befits an RPG). I haven’t tried the online version at all I must admit, but the single player version is really nice. A compelling storyline with the kind of environment that allows you to live that storyline out.

NWN is of course, 32-bit only but I had no real trouble running it on Bluewhite64, all I had to do was grab the 32-bit SDL packages from slackware.com install them in a temp root and copy the usr/lib files into /usr/lib32 and it worked fine ever since.

I did find one nasty – it doesn’t play (no pun intended) nicely with twinview, putting itself in the middle of the two screens spanning halfway onto each. With Xinerama, it works perfectly. Of course Xinerama on NVidia means no compiz effects but I have also found that with twinview enabled my system is really slow and unstable, using Xinerama instead is much faster and works way better under KDE4.

I made one change though, I don’t run it under KDE at all, seeing as I have two screens, KDE needs to keep managing the one NWN is not on, and it’s not like I can multitask that way since the mouse is trapped inside NWN, so that was just a waste of resources, instead I created a .desktop file to launch NWN by itself and copied it into /usr/share/xsessions, now when I want to play it I just select “Neverwinter Nights” from my session menu on the login screen and log in, when I exit the game I’m back at the login screen. I tend to do this with most heavy-on-resource games anyway and I highly recommend it. Being able to completely switch off your desktop while playing games is just part of the real power that GNU/Linux with it’s immense customization offers over other OS’s.

Arny has just announced the availability of new live DVD’s for Bluewhite64. There are now both KDE3 and KDE4 live DVD’s available and both sets have received a number of crucial security and stability updates.

Most exciting to me (and I hope a lot of users however) is the inclusion of bw64installer. For those who do not know yet, bw64installer is a complete, flexible, powerful and above all ease to use live system installer I wrote for bluewhite64. The code has been under development for some time (the official releases are shipping with version 0.0.5 which could be considered the first fully stable version).

This puts the LIVE versions of bluewhite64 completely on par with most other live distributions. Bluewhite64 has taken the interesting approach of buiding what is essentially a pure 64-bit port of slackware on one hand, and then being truly creative in their LIVE setups on the other, which ship a solid and easy to use preconfigured desktop system with a very impressive suite of applications, many of which are not included in the default (slackware ported) images, one example of which being the ALICE administration suite from the darklinux team.

As I mentioned in an earlier post, bw64installer is now part of the playground repository of DarkLinux which should allow it to grow even more. In the meantime, I have achieve my initial major goal with it- to make the creative and unique BW64 LIVE systems capable of acting as easy-to-use and desktop-friendly installable operating systems. This allows bluewhite64 a best-of-both worlds approach with full compatibility to slackware on one hand, and an easy preconfigured and modern desktop distribution on the other.

While merely writing an installer is not such a huge contribution, the fact is that nobody had done it – and writing a good installer for a distro isn’t easy. I had done it in the past and I could draw on my old experience (and some of my old code) which allowed me to write it faster than most people could with a solid set of features.

There are two new feature requests which I didn’t have time to finish before the release-freeze but they will be in the next update, along with any other sensible once I can come up with (a crucial thing about installers is that bloat is even more evil than usual – more steps means more difficulty and slower installs, so you have to be careful about which features you actually choose to include).

One side-note: please note that the current release does not support ReiserFS without some tweaking, so please install on ext3 partitions.

I am happy to announce that BW64Installer version 0.0.3 is released and available in the usual place. This release fixes the installs on the LiveDVD as well as several other bugs and adds support for lower memory systems.

In other news, I’m giving a talk tonight at the CLUG meeting on how to make your own GNU/Linux distribution. I spent some serious time doing it for a living and prepared the talk quite well so I hope that everyone who can make it will enjoy it. I promise a good mixture of theory, history and practical tools. If you would like to attend, you can find directions and more information at CLUG’s upcoming talks page.

I will post my presentation to this blog tomorrow, after the talk.

As you may know, the feature freeze for KDE 4.2 is only 3 weeks away, so of course that means that if KDE3to4 is to be includeable there, it needs to have the current bugs fixed by then. Unfortunately, I am also right now working on bw64installer which needs to be ready ASAP so it can be included in bluewhite64′s next LIVEDVD. I will therefore put in a big bughunt fest for kde3to4 it this weekend with hopefully a 0.0.5 release by Monday which should be ready to propose for inclusion into the main kde 4.2 tree.

The more I used Bluewhite64, the more I like it. This is a really well thought out way to port slackware to 64bit platforms. Moreover Bluewhite64 has some really neat live cd’s. What it has not had until now was an easy way to install those meaning users wanting to install either had to hand-hack it on, or use the install-dvd’s which are slackware like.

Not that there is anything wrong with that of course.
But the LIVE media is very well put together and includes some really nice additional tools (like darkstar linux’s ALICE suite), for users who prefer to just run the system as opposed to tweaking it together these livedvd’s are among the best available tools out there if you want a 64bit slackware based system.

So I decided to help out, I still had the code for OpenLab’s installer which was GPL’d, and it covered most of the tasks needed to easily install a slackware based LIVE distro. But it was also buggy and old (the last version was a beta), branded for OL and coded for a much older slackware base.
So I began the process of porting it to bluewhite64 and bringing it up to date. This was quite a job and I ended up rewriting about 80% of the code, all that’s really left of the OL installer is the process, the actual implementation is almost entirely new and a lot of assumptions from OL are no longer there.

Either way, bw64installer is at it’s second release by now and in my testing seems to work very well. Arny has said that he would like to include it in the official builds so with a few days of my time I can feel that I have made a genuine contribution to a really nice community distribution.

Today has been a good day. First off, I just uploaded an updated set of lancelot packages. These packages are now compiled against KDE4.1.1 (they’ll probably work on older ones but don’t quote me on that) and contain a fix in the slack-desc file (thanks Kenjiro Tanaka for pointing that out).

Secondly, I’m now running KDE4.1.1 for bluewhite64 mere days after the official release, another big thank you going out to Kenjiro once more as he was the one who built these packages. I love how alive the community around BW64 is
KDE4.1.1 is quite impressive for a mere maintenance release and I definitely has a slicker feel to it. Things just work that tiny bit better especially in plasma. Still runs slow on my system though and I still blame NVidia, despite the fact that it now renders at a good speed, kwin still uses massive amounts of CPU even with effects turned off.

Finally I also discoverd wicd, courtesy of Robby Workman – finally a lovely userspace tool for network management that doesn’t bugger up the slackware philosophy, handles WPA with sweet beauty and doesn’t depend on half of gnome like NetworkManager does.

When I saw the blog post for the 1.0 release of lancelot. Today, I felt like a small contribution so I created a slackbuild script for it and built a bluewhite64 package from that. The slackbuild should work just fine on normal 32-bit slackware versions and maybe even on the official sparc version and I am actively using the bluewhite64 package.

More details and downloads here: