Jun 232009
 
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.

Jun 042009
 
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.

Apr 262009
 
No Gravatar

As I write this – the 32-bit ISO have passed everything in the core test cycle and I’m busy with a test on 64-bit ISO – I’m quite confident that these are the final builds and we’ll head our release date next week with ease. This next version of Kongoni, is an alpha version for 1.12.2 – as such it really represents the first true kongoni release. Unlike the baseline Aristotle which merely established a working platform, this is where we began the work to turn it into what Kongoni is.

Sophocles was named for a very specifically chosen philosopher, it’s namesake has been called the father of modern thought and in a similar vein, this release represents the first of a new generation of distribution. Kongoni is truly an innovative operating system. It’s a GNU/Linux that tries to just work, be familiar but at the same time offer a truly fun and unique experience. Sophocles is the beginning of that vision.
It’s an alpha release because it’s jam-packed with features, but new bugs could appear at unexpected moments – especially on the ports tree side. As it matures through beta and stable now, we’ll start seeing a true production ready system appearing. Having said that, the ISO’s at least are remarkably stable and work very well – thus far, I have had no problems and I am using Sophocles for production work (mostly to produce itself I admit).

And as I reached this paragraph, the tests on 64-bit just passed, all of them. So that’s it, the final ISO’s are ready – and they’ll be available in a few days, we’re into the release-management part of the cycle.

The purpose of this post however, is to highlight what some of these features are. What has gone into Sophocles to make it unique and new ? Well here is a completely non-exhaustive highlights list.:

  • PIG officially included
  • This version ships with PIG included and running by default. PIG’s system-tray-run-as-user approach allows it to integrate beautifully into the OS, making software management a breeze (and people thought a ports tree meant it had to be harder). Even on the LIVEcd it’s already there – with a few clicks you can add a piece of software to use LIVE, and if you run the installer afterward, it will be installed with it. Update notification and management is therefore also, fully integrated and easy to use.

  • Latest and greatest upstreams
  • Sophocles will ship with KDE4.2.2 which was released literally just two days before we froze the system. It has the latest versions of Mozilla and OpenOffice.org included as well and the entire base system has the latest updates from upstream distributions already applied.

  • Shiny !!!!
  • Sophocles looks sexy (and other people have similarly described it). Aristotle had shipped stock KDE themes barring only three small changes. Lancelot menu with a kongoni-logo icon, and a standard wallpaper. For Sophocles the arts team under Hannes’s leadership went all out however and ship with a truly beautiful theme-set for almost all the things on screen. The login-screen, most of the splash-screens and the desktop wallpaper are all blended together with gorgeous artwork. The early-preview screenshots I posted last week shows some of what’s coming but the final release includes a few pretty surprises that were not yet ready at the time. We’re making full use of KDE4.2.2′s abilities to create a truly beautiful working environment that is nevertheless consistent and easy to navigate.

  • KISS
  • New in this release is the Kongoni Integrated Setup System. While this is an early release that doesn’t have a lot of features it does cover the most requested features as based on our forum requests and bug reports. More importantly KISS provides a structure that’s easily expanded so new releases and even completely different ports can update it with more features allowing it to grow quickly and transparently.

  • Improved ports tree management
  • Finally, the heart of any GNU/Linux distribution: software management. A nice GUI is no use if the underlying architecture isn’t solid. Portpkg provides us a very solid system, but this release sees numerous improvements to our plugins which combine to make the kongoni ports tree truly work better than ever before. Synchronization errors are almost non-existent now, the tree is cache-protected to prevent proxies from messing it up, the default configurations are enhanced for better multi-platform support and the entire thing just works better.

  • Soft rolling-upgrades
  • Finally, but certainly not least importantly, Kongoni aims at stable ISO’s roughly once per year to follow the slackware release schedule, but regular rolling-updates throughout. Making for a best of both worlds approach, with the flexibility and continuous life of a rolling release, along with the reliability of a regular release schedule. This release will include a brand new port called simply kongoni, which allows for easy and simple updates between ISO levels without downloading the ISO or reinstalling anything or affecting your current settings. For more information on this, see the upgrade howto in the User Guides section of kongoni.co.za.

In short, this is a very exciting release for us, it establishes kongoni as a truly innovative new distribution well worth a look. Over the next while we’ll be stabilizing it and I am confident that the final 1.12.2 release is going to rock.

Apr 222009
 
No Gravatar

Building kongoni means building a huge amount of software not written by me. Usually this is not hard. A few basic combinations of commands will build almost anything, these days even most packages with autotools support DESTDIR so it’s generally not a complex process. In fact, it is so predictable that autopork automatically generates about 80% of everything.

But some packages have excruciatingly complex build systems, that are hard to master, harder to package… and in short, the bane of a distribution developer’s existence.

Herewith, my top list of packages with the most terribly stupid build system out in the world (why some of the most popular programs are on this list, and haven’t done anything to get off it I just can’t figure out).

  • Gnome
  • Man… a project that requires non-standard patches to a core system library is bad, one that requires dozens of them is simply terrible. Gnome is so bad in this regard that since Slackware 10 Patrick no longer even tries to include it so slack gnome users have to rely on projects like GSB and FreeRock to run it. Both of them have the same problem at the end though -you now have to rely on their versions of several core packages so you can’t use Patrick’s updates.

  • OpenOffice.org
  • Just ask anybody who has built this one from source, forget that it takes days to compile – it’s a nightmare just to get set up, let alone package. To make things worse – their own binaries are only available in deb and rpm formats… hundreds of them. This is why it’s one of the few binary-only ports in kongoni, it’s just too much of a nightmare.

  • Pingus
  • Pingus uses scons, in theory, this means it’s really easy to build. In practise though the scons setup it uses is terrible. It fails to detect libraries that are present, then reports as present dependencies that aren’t… I still haven’t gotten it to build right.

  • Frozen Bubble
  • Wait… you need a customized version of a core perl module that’s 7 versions behind the current… so you break hundreds of programs to run one… erm… right.

  • Boost
  • Now here’s a headache one, the library set that uses it’s own built-in build-system, you have to build this first. Only then can you build the libraries… and it’s impossible to do in a fakeroot setup. In fact, I still haven’t built a working boost port, the only way to build it is to run the SlackBuild by hand from a real root shell (su doesn’t work) and then install the package it creates.

  • Amarok
  • In theory, amarok is as easy as any CMake based system. In practice it has a bug almost as bad as Boost’s – it can only be built by real-root, fakeroot just doesn’t work. At least this one works with su, so the amarok port asks for a password.

So here’s hoping some of the developers of these projects read this, remove their craniums from their rectal cavities and give a thought to the poor slobs who have to package this stuff so users can enjoy them.

Mar 272009
 
No Gravatar

Well, here we are for another Friday’s worth of weekly updates. The list is a bit shorter this week, largely because my efforts were slowed down by a hard-drive failure. The drive is still readable but not writeable and it’s my main data drive. I’m getting a new one today and I’m investing in a 1tb hard drive so there will be plenty of space to play around with :)

Our first piece of news is from upstream, I contacted Bluewhite64 about the state of their ia32-emulation packages in the current tree. They assured me that these will be updated over this weekend – that means that we will be able to get a chromium test-case runnable on a kongoni system sync’d to current on 64-bit in future. All this is of course still very experimental stuff – but it’s a glimpse of our medium-term future.

A big impact on the work now, is the upcoming feature freeze for Sophocles. This means that from now until April 6th, I’ll be pushing in as many features as I can – ready for testing and fixing after the freeze.

I released P.I.G 0.0.3 this week and the port should be on most mirrors by now, this is a major release and marks the last feature-release prior to sophocles. From here on in any releases until Sophocles is out will be bugfixes only (there isn’t time before freeze to work on any of the major parts of the TODO list here). The new version does however have some pretty awesome stuff in it. The first is that autoporK is now fully integrated into it, the second is that port-sharing support has been added to the interface though it is disabled for now (it will be finished after harbourmaster is running). I fixed a few bugs from 0.0.2 and there is a lot of cleanups in some of the processes. This release has the longest changelog yet for the project in fact.

KISS has now got a skeleton in place as well as it’s first feature: switching off roaming networking (as per wicd) and configuring stationary networking using classic slackware scripts instead. The core design her was meant to be as flexible as possible, so kiss uses .desktop files to tell it what exists, and scripts to actually implement them. This means we can use existing tools with ease, grow the system without code-changes and present it in a whole bunch of cool ways – browse it with dolphin or konqueror or most other file managers, set up an admin menu based on kiss using a lancelot-part (I am tempted to do this on the default taskbar as the default way to use it).
I have quit a bit to do in line of getting a basic set of features into it but the work has begun. A big missing piece is the icon here but that is quick to plug in when one of our artist folks get around to it :)

Another new port this week done specifically with the freeze in mind is ksplasherX a nice gui tool to help artists design splash screens for Kongoni. Would anybody like to volunteer to do one for us ? Anastacia… you look bored ;)

The kongoni facebook group got a growth spurt this week with ten new members joining – I’m kind of to blame, it occurred for the first time to me to invite those among my friends list with an interest into the group – the group has the potential to be a nice marketing avenue for us so if we can hijack and evil website to a good purpose – why not ? Those of you on facebook who aren’t in the group – please do join it – and invite your GNU/Linux using/interested friends as well :)

Daniel has reported that we have a new mirror that came back, from Sweden this time, setups are in progress there so we’ll soon be able to add a European mirror to our list.

Talking of mirrors, our current loadbalancer is really rather basic, the php is simple but it could be a much nicer tool. For starters it should count requests for ISO’s (it already treats those special so just adding the code is easy – I can pull the initial value from the logs to start it off on) so we can have a truly accurate count of downloads – at least those downloads that didn’t go straight to a mirror. But a much nicer feature would be to split the mirror lists by country somehow instead of just by content like they are now, and make an effort to direct the user to one nearby him. So a request for a ports mirror from South Africa should automatically go to mirror.ac.za (which is in the ports mirrors list) but an ISO download from the user should randomly choose between mirror.ac.za and IS.
The current script is about 100 lines of php – would anybody like to volunteer to expand and maintain this ? It could be a fun little project that doesn’t require genius-level php skills but would be one less thing your brave and fearless dealer needs to find time for :)

That’s about it for this week.
Ciao

Mar 182009
 
No Gravatar

So if I thought the route from baseline to alpha would be short… boy was I wrong, though baseline is surprizingly solid (I use it as my production OS on two machines) there is a lot to do to finish making it kongoni.

The first major milestone to breach was P.I.G which is now officially released. It can still get lot better but it certainly works well. Yesterday I finally tackled another: getting the kernel updated. There is now a solid and well working port for kernel 2.6.28.7 and it’s a marked improvement over its parent. FIrstly the port itself is much cleaner, secondly this one actually follows up the kernel-source install by creating a kernel-binary package and upgrading for you.
You can rebuild with our own configs but it’s all automated by default – and now your kernel files are actually in a trackable package. The port is still called kernel-sources (and likely to remain so at least for now) but it also installs a new version of the linux package.
Another thing that got changed is that the lilo boot-splash image is now fetched by the kernel-sources port and installed in the linux package – so it is no longer deleted when you remove kongoni_installer (a major bugfix). Finally there are now seperate configs for x86 and x86_64 rather than a shared one which just adjusts the CPU type. The reason is simple: there is a crapload of old hardware that never came out on 64-bit systems which you cannot compile the drivers for in a 64-bit kernel, so a config generated on 64-bit strips them out, and that makes them unavailable on 32-bit, there is a similar set of modules that can only be enabled on 64-bit as well.
The only choice: two separate configs, based on one another. The new kernel brings a lot of new features like console-on-braile support, wireless USB and of course stable ext4 support (to use it however you need to update to the ext2 userspace package from slackware/bluewhite64 current).

Since testing kernel build scripts take long at the best of times, I had a lot of idle time and I used this to do testing on a few other ports, managed to fix rather nasty bug in the 64-bit port for OpenOffice.org. Now my current activity is building a port for google’s chromium browser. The port will be based on the arch user repository build script which in turn is based on the ubuntu ppa daily builds. Keep in mind when it goes live though, this is an alpha port of an alpha tool built by a bot that is in alpha status… if it breaks, drowns your cat or sleeps with your spouse – don’t say you weren’t warned.

Feb 262009
 
No Gravatar

The guys over at opensourcereleasefeed did an interview with me about the Kongoni release.

On rereading it, I have to admit… I should have checked my grammar better but I was answering mails at 1am so I think I’ll forgive myself, still I think I got the messages I wanted to spread across even if I took a bit of a ballistic approach to the location of commas and dashes.

Feb 222009
 
No Gravatar

Kongoni’s second baseline release will be the first public release of the distribution. At this point in time it is extremely close to being released and you can expect it to be officially announced sometime in the next 48 hours (don’t hold me to this as a promise though – we are community project and we do not set or do deadlines).

But with that in mind, I felt I should give a taster of what Kongoni is like, so I did a screenshot tour from the ISO build that we will be releasing which shows of quite a bit of the system. It’s not very in depth into things like the ports tree (for that check out the kongoni website) because screenshots are highly unideal for showing things like that off. Instead it focuses on the visual aspects of the system as it will be encountered by a first time user, through a first install in the normal “launch installer from live” mode. The “just install” option is extremely similar but because it doesn’t use the desktop it is faster and works well on lower memory systems or for rapid deployments (such as perhaps if you remastered a disc with your needed add-ons for your environment and want to just clone your install around fast).

So without further ado: the first ever screenshots of kongoni:
(click here to view it in a new window instead)