While fixing the installer problems with turtle kevux 0.9.4, I kept finding more problems until an entire month passed.
I did manage to fix a whole lot of problems and so I release turtle kevux 0.9.5 with a functional installer.
I also stumbled apon other problems and even managed to solve some really old known issues.
Claws-mail now works, the latest series of xorg and mesa are now being used, and even the 64-bit cdrom boot issue is resolved.
Now for the bad parts.
Modesetting is functional and enabled by default, but I find that my old ati radeon card that worked wonderfully with mesa 7.8 does not perform as well with 7.11. With modesetting enabled, its performance is barely acceptable and with modesetting off it is only acceptable performance. However, the newer video cards work wonderful with modesetting. If you have any trouble with desktop performance, try booting with the option: nomodeset.
It has come to my attention that the installer (kiwi) on turtle-0.9.4 has problems and does not properly boot.
The mistake was simple and the solution is simple and I will make another release in January to fix this.
The live-cds can still be used and the system can still be manually installed, but the automated installer will not function in turtle 0.9.4.
The highlights of this release are:
/etc/resolv.conf (which on kevux is /etc/network/resolution) defines how to talk to domain name authorities in order to resolve a domain name such as www.google.com to its appropriate ip address.
The standard way in which this happens is via the nameserver settings, such as: nameserver 22.214.171.124.
DNS extension support provides a way to specify a nameserver based on the extension being looked up.
That is to say, one could provide their own private dns server with their own extension, such as 'computer', and only the private dns server will be used for all domain names that end in '.computer'.
If the private dns server was 192.168.0.1, then the extension line for this would be: extension computer 192.168.0.1.
A complete /etc/network/resolution file using the mentioned extension and nameserver would be:
Just like with DNS Extension Support, DNS private ports alters how the dns resolution process works.
Traditionally port 53 is used for dns and no other port is supported.
DNS private ports alters this behavior such that any port may be used, thus allowing a single server to host dozens of separate dns servers.
To utilize this, one need only add ':port_number" where 'port_number' is replaced with the desired port number.
Lets use the example /etc/network/resolution example file specified in DNS Extension Support.
The '.computer' domain name server at 192.168.0.1 for whatever reason wants to run its dns on port 80, the resulting /etc/network/resolution file would look like:
The first stage of the kevux undernet utilizes the DNS Extension Support and DNS Private Ports to provide the kevux domain name authority.
To utilize the kevux undernet domain name server, simply add: extension kevux 126.96.36.199:1 to the top of your /etc/network/resolution file.
The standard kevux /etc/network/resolution file looks like:
The package manage is planned to be developed through-out the next few releases such that it turtle kevux can be slowly converted to using it.
Therefore, it is being released in stages of functionality.
This first release does practically nothing at all and currently only provides source based installation for whatever packages might that might be available.
The only package available as of the release date for turtle kevux 0.9.4 is the linux kernel.
The Turtle Kevux Installation Scripts have been promoted to version 1.0.0 as they are being replaced by Kit.
Planned Package Manager Functionality:
In an attempt to push for using encrypted websites by default for security purposes, the HTTPS protocol is now used by default.
This means that typing www.google.com will get you https://www.google.com/ instead of http://www.google.com/.
The downside of this is that a large number of websites either do not listen on HTTPS or provide a completely different website on HTTPS.
For those cases, you will have to manually prepend http:// to the problematic url.
This really isn't a good thing, but users should be aware of both good and bad things about a release.
This highlights the major problems that were introduced and have been unable to be fixed by the time of the release for one reason or another.
A handfull of applications decided they did not want to work with no obvious reasons as to why.
These applications are:
I have only had bad experience with gstreamer and have never liked it (not to mention the bloat it adds to the system).
However, a lot of the newer functionality, such as HTML5 support in webkit and video conferencing in pidgin, depend on it and do not provide an alternative.
For this reason gstreamer was added, but as far as I can tell, gstreamer does not work in the slightest way.
It fails to detect that sound support exists (while every single other application and library on the system can).
It fails to report that it is capable of playing video and as such midori won't play any HTML5 video and pidgin video conferencing cannot be supported.
Qemu recently stopped starting up.
It appears to startup and then deadlocks or gets caught an infite loop doing no apparent task but waisting cpu time.
I have no idea what or why this is happening.
This has prevented me from doing some much needed work in non-x86 architectures.
The latest version of lbreakout2 appears to have the same problem as qemu.
Fortunately, downgrading from 2.6.3 to 2.6.2 seems to get lbreakout2 working again.
Fixing this may lead to solving the qemu problem.
The latest version of claws-mail at the time of this release is 3.7.10.
When claws-mail tries to read IMAP mail, it segfaults.
I have consistently had problems with claws-mail, IMAP, and uClibc in the past, so this may be caused by some uClibc bug as well.
Like claws-mail, Freedroid RPG decided it wants to segfault.
There is no clear reason as to why and as such I can only assume its a uClibc given that freedroid rpg has not been changed since the previous release of turtle kevux (and it worked in the previous release).
When a non-root user tries to burn a cdrom, the cdrom? symbolic links disappears.
The only way to I have been able to burn to /dev/cdrom? is to do so as the root user.
This is either a bug in the kernel, udev, or both.
The 64-bit live cdroms do not properly load grub for some reason.
This can be worked around if you have booted to the live cd and ar sitting at a grub prompt.
At the said grub prompt, type in the command: configfile /boot/grub/menu.lst.
This could be related to how I am using the 32-bit grub on the 64-bit live cdroms.
Yes, Turtle Kevux now supports B.A.T.M.A.N.
In addition to adding B.A.T.M.A.N. support, there have been a number of major changes that have broken backwards compatibility.
The first of these changes is an overhauled permissions system.
The permissions system is now broken up into multiple groups:
The second of these changes is a complete renaming of the services group.
The terms "server", "service", "daemon", and "target" have all been used to reference the same thing by different systems and different people.
Unfortunately, terms such as "server" and "service" have meanings other than referring to a daemon.
This leads to a communication problem.
It was decided that the term "target" would be used to represent some service/daemon/server that is available on the system.
This change was made throughout the entire system, for example: /home/services directory is now called /home/targets.
This release also offers architecture-specific optimization where possible while still favoring portability.
In particular, there is now a new experimental 64-bit version of Turtle Kevux.
The primary problem with the 64-bit release is that grub is not available and no boot loader has yet to be made available.
For now the 32-bit version of the system will be needed to install grub.
There are a few other applications that crash only in the 64-bit version and investigation on the cause is pending.
Qemu and scummvm emulators are now available on Turtle Kevux.
The release even provides freedos 1.0, with the image being located inside of /share/freedos/
Turtle Kevux 0.9.2 had a rather major regression that probably scared away users trying Turtle Kevux for the first time.
The problem was that booting to device failed completely such that only squash and squish boot from memory would work.
This rather major problem has been resolved and with any luck no new boot regressons have been introduced with this release.