No Gravatar

It’s been a helluva weekend, it started out on Friday night when I went to see fokofpolisiekar live at Mercury with Anita. It was an awesome show as it was a kind of remembrance concert for them in the venue where they had their first ever gig. They did a lot of their old stuff – the stuff that made them legendary in the first place, and some of the stuff from their new album Antibiotika.
I’ve seen them live several times, and this was by far the best show of all. To the band I must say, and I can only say this in Afrikaans: Julle is die stem van jong Suid Afrika, nou fok julle..
Pictures from the concert:
click here to view it in a new window instead)

Saturday afternoon I went to a Urban Ink tattoo parlor to do something I have been planning for months, a new tattoo. This is my second piece of ink, much larger than the first, far more prominently placed (on my bicep) and here’s the clencher, what I got tattood on my arm is the kongoni logo. This logo, an iconic GNU (wildebeest) is a symbol of freedom, long after computing has moved on and the kongoni OS is just a memory and I’m an old man, that freedom will still be important to me- it’s a logo I am proud to wear for the rest of my life, and right now, it’s the logo of the GNU/Linux distribution I started… and that is just awesome :)
Here is a full set of pictures of the process. Of course it’s not exactly like the computer version, a few minor adaptations was needed to make it work on skin, and it won’t show exactly right for a few days yet until the bruising has gone down (the lighter colors are masked by the red skin) but even now in the evening it’s already looking great. Thanks to Anita for taking the pictures.
click here to view it in a new window instead)

This evening was Natalie’s birthday party, we went to Primi Piatti in Cavendish for dinner, some of them went on to go clubbing, we skipped that… we were just too tired after the weekend so far. My neck is so stiff from Friday’s headbanging, guess we’re getting old. Tomorrow is Arno and Christel’s aniversary party, at least it promises to be a quiet and peaceful ending to a long busy weekend.

 
No Gravatar

A post in Free Software magazine today makes the claim that software installation in GNU/Linux is broken. The author lists a number of problems with package management as a way to install software then posits that system and application software should be treated as entirely separate entities – thus we can use the success of package managers (and in the end even a ports tree like Kongoni has is still a type of package manager) for system software, while gaining greater ease with the application software users install all the time.

His proposal is to look at the MacOSX approach but the fundamental point is same-old, lets make GNU/Linux more windows-like.
What he claims to want from software installation for applications is in fact, already there – very few programs will have difficulty being installed by a user, in his home directory. The catch is that binaries are almost never built that way, because it’s inefficient – so that’s usually limited to manual source compiles – and indeed, it’s a (tiny bit) more difficult.

Frankly though – what he sees as the features of a good desktop application installation system… would be an absolute disaster.
It’s ironic, just yesterday I was reading a blogpost about GNU/Linux’s continues resilience against malware which mostly rehashed the known facts of a better design with better separation of user and admin privileges – but in the comments somebody made a point that immediately struck a massive chord with me. I had never thought about it before, but as I read it, the logic hit me: this made perfect sense. It fitted all the observed data perfectly.

GNU/Linux users almost never download and run programs from the internet. We almost never trade programs on disks with people. We install from the repo’s, it’s just easier and faster on our system – and this means, before we install the program it’s been checked – it’s coming from a source we actually can and do trust.

A major aspect of malware spreading – social engineering is entirely removed because we use repositories to install software. Do we really want to turn GNU/Linux applications into the unreliable, untrustworthy mess that is Windows software ?
Even if you remove their unclean deinstalls and registry muck-ups – the reality is that the basic premise of “download from some site and install some little app all the time” is fundamentally broken, it creates a massive and easily exploitable gap for getting users to install malware.
One of the worst I’ve seen is a site that does a very good job of emulating a respectable looking provider of anti-malware software, out to get credit cards when you buy, and install their own spyware on your box…

GNU/Linux is entirely immune to that because all our software comes from a repository, where it gets added to by developers who are technically proficient and know the system really well, who know the software they add well – they have to because they build those packages from source and that means studying the build systems at least to an extent.

Sure junk could creep into a repo – but the odds are very small. Systems like klick has tried to create ease of single-place package installs and failed because it has no real way of resolving dependencies and it’s highly desktop dependent. Even if you ignore those problems… well you’re still dealing with a single repository source of click recipes, so it’s still safe and secure – but I don’t see most third-party vendors using click to ship anytime soon, they aren’t even playing nice with repository maintainers for big distros !

Rox-desktop has an app-folder approach that only works with rox, but does offer pretty much what the author seems to want… but nobody uses it. The reality is there are many different package managers out there and despite many claims this is a good thing, they all have strengths and weaknesses. They allow distributions to be good at some things they would otherwise not be good at, and other distributions to fill in those gaps.

It wouldn’t be too hard to combine a rox-style appfolder with a .desktop file to make a desktop-neutral app-folder tech… but it’s usefulness would in fact be very limited. Users don’t want their data-space (home folders) cluttered with applications – even Windows users know that. It’s hard enough to find your files now, what would adding all your application files among them add as a hundred or more extra directories do ?

Well besides obviously turning GNU/Linux into a quagmire of virii and other malware as ugly as windows and twice as rotten (because we don’t use antivirus software) ? Nothing. Nothing that’s actually good for us as a community anyway.

The only reason people seem to think that being able to quickly download and install software from anywhere is a good thing (as opposed to a disaster we have been wonderfully lucky enough to avoid) – is because they are used to this idea from the Windows world. They think it’s good as an easy way to get third-party software, but what they don’t say is… well that thirdparty software would already be in the repo’s- unless they license doesn’t allow it.

Let me spell it out: the only people who have difficulty or problems with GNU/Linux’s package management idea, or the proliferation of package managers out there: are the developers of non-free software.
They want to join our party, but refuse to play by our rules. Well – whose fault is it then if they keep losing the games ? More often than not, this is not even a reality, they are making excuses not to support free platforms, and taking a convenient one, forgetting that if they made free software – it wouldn’t exist.
They wouldn’t need to care how to package for distro’s X, Y, Z – why not ? Because that’s windows-thinking, where vendors package the software. Just put the software out there, it’s my job to package it for kongoni, and the MOTU’s jobs to package it for Ubuntu etc. etc. hey guess what, this means the people packaging the software are actually experts on the OS platform they are packaging it for – as opposed to merely knowing their own program.

You can get software installs that integrate cleanly, don’t break things, don’t get infected with malware by accident…

Basically, I think the advantages of a package manager approach to software greatly outweighs the advantages of any other approach I know off, and more crucially than that: most of those so called advantages are in fact disasters.
Ease-of-use is a good thing, but I don’t think quickly-download-and-install software is easier to use.

Expecting every user to be able to spot a real software company from a fraud, a good program from a bad one… and judge it entirely by themselves… that’s not a good way to make it easy to keep your system fast, secure and stable. Package managers have their downsides, (but the only practical point he raises that could be improved is difficulty with running multiple versions of an app, which is a pure power-user feature anyway) – but they are relatively small in fact… the alternatives take the responsibility of ensuring the integrity of software away from people who are trained to do it, and puts that burden on ordinary users.
This was Microsoft’s biggest single mistake – the main reason for the continued plague of spam, botnets and spyware on the internet. Please, let us not make the same mistake.

Update: It occurred to me after publishing that I should add this. If repository based installation is so bad, why is it being copied and emulated as an idea ? The iphone’s app-store is a prime example, although proprietory and pay-for-play, it’s a repository of safe software, for users to install from. In every other aspect, it’s identical to how GNU/Linux installs software on your computer.

 
No Gravatar

Busy, busy, busy. Such is the life of a distro developer when releases are being made. Kongoni-current has been quite lively of late with a lot of things happening last week – especially as it was a short work week.

My girlfriend luckily is very supportive of my endeavors because she hasn’t been seeing much of me lately – but the good news is that the progress has been amazing.

My week began with a minor setback when quite a lot of files on the 64-bit build got badly corrupted, don’t tell the girlfriend but it was her fault… hairdryer in the clean power. Luckily – I keep very good backups of the build systems so restoring it wasn’t too hard. The problem was compounded though because I initially mistook an unrelated issue for part of it – so long after it was fixed, I was still hunting file corruptions in what turned out to be a wild goose chase.

The real issue turned out to be an incompatibility between squashfs 4.0 and linux-live. Choice to be made there: patch linux-live, or roll-back the kernel to 2.6.29.4, ultimately I opted for the rollback, I hate patching upstream and I avoid it as far as possible (in this regard, I’m with Pat – the less patching I do – the more stable your systems will be).

So Nietszche will ship with kernel 2.6.29. More importantly was another major gain in the freedom-support of Kongoni. It won’t be shipping with source code from kernel.org but rather with the linux-libre project’s cleaned up code. No more non-free blobs, nor the ability to directly add them. I tested it roundly and the impact is fairly small, but for those who have a piece of crucial hardware that absolutely has-to-have a non-free blob and who cannot afford to replace it, Bret Murch has offered to host and build a set of identical packages based on the non-free kernel.org Linux, which users can install if they wish.

This was the last major hurdle we had to cross to be acceptable for being listed on gnu.org, and I am now comfortable to request that listing once Nietszche is released. It is interesting to note that the existence of distro’s like kongoni and gnewsense is rapidly reducing the level of non-free driver requirements all around anyway. The recent GPL’d release of drivers for the Atheros 9x wireless cards by Atheros themselves is a direct result of the work that the madwifi developers did in creating a completely free blob for the Atheros 5.x cards. The result is that now, all GNU/Linux users can run any Atheros card with only free software drivers and firmware.

On a completely different note, I think we are close enough to the end of the month for me to let you in on a big secret I’ve been holding for well over a month now since I was first informed of it.
The July issue of Linux User Magazine will have Kongoni Sophocles on it’s cover-DVD, as well as an article on the system, with a mention that Nietszche is on it’s way.

The editors of the magazine spoke to me while preparing for the article to clear up some small details and mentioned the following choice tidbit: “Usually we only include stable releases, no alpha’s or beta’s – we made an exception in Kongoni’s case because your alpha was a truly solid release.” (Slightly paraphrased for clarity – but the meaning was not altered in any way).

So those of you who can read German should look out for the magazine in the next couple of weeks – this is the first mainstream publication to ship Kongoni disks – and it’s a major piece of recognition for our work.

Another nice bit of news is that the Kongoni IRC channel is starting to become quite lively. This is an idea that came from, and were implemented by, our users themselves. Myself and Bret Murch are regulars in the channel, so please do drop by and come have a chat with us, the more the merrier. The channel is hosted on freenode’s IRC server (on kongoni, if you install xchat from PIG it’s on the list already) and it’s called (you guessed) it #kongoni.

I made a small change to our git helper scripts, specifically to gitmaster.sh and gitcurrent.sh so the commit messages they use get automatically sent to twitter and to floss.pro – so for a constant stream of messages about what the devs are currently doing considder following @kongonidev on floss.pro or on twitter.

 
No Gravatar

Here, for a Friday, a few of the most valuable life lessons I have learned:

1] Nothing good ever gets marketed with an infomercial. Ever.
2] There is no such thing as a “special” – since shops are advertising *something* as being on special all year round – there is nothing special about it.
3] The difference between love and lust ? How long it lasts, that’s about it.
4] Governments and corporations really *are* out to get you.
5] Do not be so cynical about that, that you think we can’t fight back, or get people to do so (case in point: the pirate party victory last week)
6] Never believe anything. No matter who said it. Judge and critique and then decide for yourself, accept nothing without question.
7] Good sex needs at least two lubricants, more often than not the first one is “alcohol”. *
8] There is no such thing as too much fun.
9] Despite so many claims to the contrary, the Dave Mathews band does not, in fact, rock.
10] Any list with ten items on it is suspect.

*The second is called “good foreplay” – if that’s in short supply “KY” makes an acceptable substitute (or so I hear).

 
No Gravatar

Now as you know, I don’t like non-free software, and I make a great effort to keep all my machines free of the stuff. Unfortunately, I also have a dayjob and I don’t get to decide software purchase policy so I’m required to have windows available to run a few windows applications.
Oh well – until such time as me and my fellow voices of reason in the company have won, I’ve got virtualbox on my work laptop with a windows vm for running said few apps. When I first set it up, I gave it a 10gb virtual hard drive, unfortunately, it has lately gotten to the point where it is just not enough. The machine is basically data-less but the apps on it take up a lot of space.
I had to make it bigger, and I did not want to have to spend hours reinstalling it. GNU/Linux to the rescue :) I used kongoni for this because it’s easy to work with and has everything I need for this already easily available but quite a lot of other live systems would work just as well as long as at least parted is available (I prefer to work with gparted but it’s hardly a requirement). I did this on a virtual machine, but the exact same approach should work just as well on real machines.

Okay, so the first step was to create a new hard drive for the windows VM, doubling it’s size to 20Gb which should be more than enough to handle my needs, and connect it as the primary slave. I then added my kongoni ISO as the CD-rom drive and booted it up into the LIVE cd.

I chose not to start the graphical environment at this stage, and did a root login on the console instead. A quick check to verify that I had the drive names right:
fdisk -l /dev/hda
fdisk -l /dev/hdb

Confirmed that hda had a 10gb partition on it (hda1) and hdb had no partitions.
Right then, next command was to clone the existing drive with partition table and all onto the new drive:
dd if=/dev/hda of=/dev/hdb

When it finished, another fdisk now showed identical partition layouts on both drives. I then shut down the VM and swapped the virtual drives around so that the 20gb became the primary master, and booted it up to verify that indeed it worked just fine.

Rebooted off the CD again, fired up gparted and resized partition the new drive (now named hda of course) to the full 20gb available space.
When it finished, I booted windows again, it did a disk-check and then let me in – all good.
Finally, I shut down the VM and removed the old 10gb drive, reclaiming that space for my real operating system.

The whole process took a long time (unfortunately both cloning partitions and resizing filesystems are slow processes) but it worked beautifully.

 
No Gravatar

Well – it took some time to get the infrastructure in place, but it is there now – the final culmination of our branch based splitting of the ports tree: kongoni-current.

Like slackware-current, kongoni-current is where every day development will happen, while the branches users sync to will contain stable trees without much change between versions (except to add new ports and backport important updates to existing ones). Until this morning, this daily development still happened in the main tree, the reason primarily was twofold. Firstly, the development-in-progress already there had to reach a state that was stable enough to be the point where Sophocles effectively stopped, secondly the existing infrastructure around handling the ports tree had to expand to deal with the approach.

Both are now there, all the code that I have been working on in the past few weeks build stably and run as expected, though not yet Nietszche it’s in a good and solid state, and if you keep updated, you’ll have a solid system. Since Nietszche is no longer an alpha but a beta, this differentiation becomes crucial for the future though, we need to keep the rolling updates and the actual future-development cleanly but elegantly separated. This was a crucial reason for introducing a branched tree in the first place.

There is thus, now, effectively six active branches that make up the kongoni ports tree, although users only ever see one, split up into two sets (or series) or branches.
The first is the released series, which makes up what normal users will sync to. That would be:

  • Master: This holds almost all the code for the released ports, except for architecture specific files
  • 1.12.2_i486: This contains all of master, plus the i486 specific files
  • 1.12.2_x86_64: This contains all of master, plus the x86_64 specific files

All in all, this means normal users will only be synced to either of 1.12.2_i486 or 1.12.2_x86_64 at any given time, depending on their version. The actual version number in these branch names will stay extant. When we the time comes that 2.13.0 is released, this will be a new set of branches (forked from what is then “current” of course). Thus we can continue to provide at least maintain basic updates to previous releases for some time afterward. Probably about 2 releases back – but we’ll see what the workload actually allows.

The other series is the current series, which is very similar to the other but – contains daily worked-on code that could at any given moment be entirely unstable or broken, but gradually stabilizes over time as we approach releases, when we do, it gets merged into the version specific series (currently the 1.12.2 series, but whatever it may be in future) – and a new set of ISO’s become available. So the current series consists of:

  • Current: This holds almost all the code for the released ports, except for architecture specific files
  • current_i486: This contains all of current, plus the i486 specific files
  • current_x86_64: This contains all of current, plus the x86_64 specific files

In order to simplify the process of managing all this and make it easy on all contributors to know what to hack and how to make commits, I wrote a series of helper scripts that are inside the tree, for everybody to use, they wrap the commit, push and pull commands with due understanding of how the branches are laid out, and why – what should regularly merge with what to maintain sanity etcetera. The scripts exist only the current and master branches (with the exception of gitpusher.sh) since they should only ever be run from one of those two – and this also cleverly hides them from the users on the read-only side of the process.
I added a short document on them into the tree as well, README.HELPERSCRIPTS which I copy below:

In order to help maintain the correct workflow for everybody, there is a bunch of helper scripts in the tree here which helps ensure that the process happens
right and nothing gets forgotten.
This document describes them and what they do.

gitgetall.sh
This checks all the existing remote branches, if needed it sets up local tracking branches, then updates all. This is a very usefull and convenient tool to ensure you
have the latest code from other developers in your local working tree.
gitpusher.sh
A very simple script, that merely commit's and pushes the current branch upstream. It's used by some of the other scripts but you should rarely use it by itself unless
you are working on architecture specific stuff.
gitmaster.sh
This updates all changes to the STABLE branches (the ones that users ultimately see). E.G. the branches that get pushed is "master","$VERSION_i486" and "$VERSION_x86_64".
Crucial point: it merges master into the arch branches so make sure that master is an stable mergeable state (and architecture specific stuff ONLY exists in their proper
branches where they can't be overwritten) before running it. When this gets run, users will get the changes as updates - so this gets done only when the changes are stable
and ready.
gitcurrent.sh
This is almost identical to gitmaster.sh but with one crucial difference, it pushes the CURRENT branches, where day-to-day work happens that need to be pushed for testing.
Users will not see these branches unless they specifically configured their system to track current (with /etc/kongoni.cfg) so we can mess around and try ideas here. The branches
that ultimately become the next release.
gitrelease.sh
This one is crucial but dangerous ! It merges current into master, then repeats for the architecture branches... in other words, it makes the day to day stuff. We do not use this
for backporting fixes (use temp-branches and cherry-picks for that) except in very rare cases. We run this when a new distro release is out, and we want to let users soft-upgrade.
Basically, it should almost only ever be run when a new set of ISO's are uploaded.
It runs both gitmaster and gitcurrent first to ensure the trees are stable (so be aware of this before running it) and then merges the branches seperately - it finally runs gitexport.
gitexport.sh
This exports the gitosis tree to the http-read-only tree that users synch from, it is autocalled by gitrelease, and otherwise frequently when a change to gitmaster should be made
public.

So that’s the developer side of it, but there is a user-side as well. Just like slackware users have for years been used to installing packages from current when they wanted them early, or even upgrading and running current at any given time, so kongoni users who are happy with the risk can now do the same, just edit /etc/kongoni.cfg and change “KONGONI_VERSION” to “current” – then resync your ports tree and you can install any package you want from the current series, you can even do portpkg -nu and actually run, right now, the exact same set of packages that are running in the iso build partitions on my machine and which will become Nietszche.

 
No Gravatar

So I didn’t do a Kongoni updates newsletter in a while, the major reason being that I am sick in bed – so all the stuff has slowed down a great deal. In fact some of what I’m writing about here was started last week already and only came to completion over the past several days while I have been limiting my entire computer time to about 10 minutes a day -most of which was given to solving critical stuff for work.
I just finished a long nap which I really needed, if the illness wasn’t enough – the high heat and humidity in Cape Town as the next cold front pushes the hot air ahead of it took care of knocking me out cold – but I decided it’s time for an update on how things are going.

Now I am still updating the todo list as well, but that lacks any kind of story, and doesn’t include more generic across-all-versions changes like our first major story for this issue.

Those of you who regularly sync and update may just have noticed an update to portpkg last week, if you installed it – you would have noticed a small change in the sync output, with something like 1.12.2_x86_64 or 1.12.2_i486 being printed during synchronization. If you examined the tree, you will find that the top-level 1.12.2 directory no longer exists. What is going on here ? It took a lot of research and discussion with the guys from CLUG (sorry guys, I know I said I would be at the GIT talk and I really wanted to come – but I was sick in bed) – but I have gradually switched the ports system to a new approach – something I don’t believe any other distro does (even the other ports based ones) – which we can do, because our ports tree uses git.

Git makes branches cheap, easy, and elegant. Traditionally distribution packages maintain separate trees for each architecture and each version. The fact that 99% of the code overlaps is ignored because it has to be. Even ports based systems like gentoo effectively does the same. Kongoni does not. We always maintained a single tree, with our scripts written to do the minor things that should be done different between architectures automatically.

This was almost perfect. But there are a few cases where this made the code convoluted and ugly, like when we were doing prebuilt binaries and had to build the download commands into the code rather than letting portpkg fetch the sources. It also didn’t address the future issue of “how will we deal with a new version – where we want to only backport critical stuff to the old tree” – the 1.12.2 directory was an old placeholder built on the assumption that we would ultimately have new trees.

Well, as my git knowledge improved, I realized that git has a much cleaner and nicer way of doing this: branches. Because in git branches are cheap and easy to work with and merge across (a side effect of being a distributed system). We can put that 99% overlap in the master branch, and the 1% difference in architecture and version specific branches. By merging across them (which just took a bit of cleanup to get right, and means “ignore the conflicts on some packages”) – we can cleanly share code across the branches while still maintaining a single point-of-work. The new portpkg installs a generic config file called /etc/kongoni.cfg (which you can edit should you wish and know what you’re doing) that among other things, the kongoni ports plugin uses to determine the version part of your branch, it then adds the architecture and automatically checks out the right branch for your system.

When we start on 2.13.0 – we just fork two new branches of the existing two – to cover both architectures, and they become the future – so those who like to test early can follow along just by editing /etc/kongoni.cfg ahead of release. It’s just sweet elegance.

On another note, I finished a minor update to kongoni_dialog which fixed some small problems with dialog sizing, the new installer had some bugfixes alongside it and now works perfectly, including support for JFS and XFS root filesystems (I have successfully tested both). The text based installer is nearly working right, it’s a bit, well, ugly as hell – but it’s functional and will be good enough for a beta. There is at this stage only one major bug in the text installer that I still need to fix before it’s good to go.
The text based installer will support all the file systems that the graphical one supports but, unfortunately, will not support everything the GUI system supports. Most notably the safe-and-easy resizing of existing partitions is a gparted/parted feature providing an equivalent in the text-space will require coding a brand new frontend for parted- a lot of work, while the use of cfdisk+smart formatter, handles everything else just fine already – a huge amount of effort for very little gain. Perhaps we’ll do it in the future, but I’m not going to delay the release at this stage for the sake of it.

During the past weeks a few other things of note happened, we switched our default browser to GNUzilla IceCat – an important step toward being more free, and after an e-mail discussion with RMS approved for the ports tree ports that were previously blocked by virtue of being either patented or DMCA restricted code (but still free software), since these laws do not apply in South Africa. See my earlier blogpost on the topic for more detail on this.

So that’s it for now, slow progress mostly with one fairly revolutionary idea gradually and almost unnoticed by users leading ever onward toward our next release. I think it’s safe to say that with me not being healthy, the release will be later than I originally expected – but these things happen and right now my first priority is to get enough rest and heal up.

 
No Gravatar

During the past two days there was quite a big discussion on the kongoni developers list, with Richard Stallman also giving his opinion (we specifically asked for it). The debate centered around software like DeCSS and lame.
These packages are generally excluded by most distributions – even the ones that are only partially free like Ubuntu, not because of their own licenses (both these examples are fully free software) – but because of other laws that their use could violate.
Notably DeCSS can violate the US DMCA and it’s counterparts in many other countries, while lame violates a US software patent.
So when most of our counterparts exclude this support, particularly the other fully free distro’s like GnewSense – why would Kongoni now decide to add them – and with RMS’s agreement on the decision at that ?

Well – because there is no DMCA law in South Africa, software patents aren’t recognized in South Africa (and I will continue to do my bit to make sure it never becomes so – as should you) – these programs are entirely legal in this country. Moreso, their primary use-cases is not something that is either morally or ethically wrong and shouldn’t be illegal. Sure you can use DeCSS is to make and sell illegal copies of DVD’s – but the majority of people who use it use it to watch DVD’s on their GNU/Linux computers, or rip backup copies or (like me) add them to their digital movie libraries on their media computers. All actions that are entirely legal.

Of course I’m in favor of using formats that are entirely open and this has many benefits for users, but without this reading support, there isn’t even the option of moving existing media between these formats.

So – the conclusion is: Kongoni is developed in South Africa we will not punish ourselves or our users by preventing them in any way from doing perfectly legal things just because they made illegal by draconian laws in other countries.
It would be tantamount to removing the word processor from the operating system because with it you could write an article critical of China – something that is only illegal in China (and yes, the DMCA does basically work like this: who cares what legal uses a program has, we’ll ban it because it has the potential for an illegal one).

Well then, over the next few weeks a lot of ports that have been previously withheld from the kongoni tree will be getting added, including liblame for mp3 support and DeCSS plus related libraries like libdvdread.
A selected subset of these will go onto the ISO’s as well chosen by space and necessity.

Being developed in South Africa gives kongoni a distinct advantage here, we are able to offer our users capabilities that other free or mostly-free distributions simply cannot because they are subject to laws that make perfectly legal actions practically impossible.
Let’s be clear: not even in the US is it illegal to watch a DVD movie on any operating system you want, but the DMCA does make it illegal to use DeCSS to do so, and in fact the only legal program that can is non-free – so it effectively makes it impossible to watch DVD movies with free software, despite the perfect legality of the actual activity.
This is not just draconian legislation – it is stupid, and those of us not subject to it cannot stand and support it, in fact, by utilizing our immunity from these laws to empower users to perform these perfectly legal and ethical actions, we are helping to build a case against these draconian laws which could in fact help those fighting them in the countries where they exist to show how wrong they are.

Please allow me to reiterate one more time: we are not breaking any laws, or advocating it, we are simply using the freedom given us by laws that don’t exist here. It is up to the users to determine the legality of any particular piece of software in their own country. This is no different from any other software project or company.

Socialist Libertarian

FSF

© 2012 The Blog From Hell Suffusion theme by Sayontan Sinha