Fatdog64 630 Final is released
You have may heard it elsewhere first because I forgot to announce it here: Fatdog64 630 Final was released on 11 February 2014.For those who have followed the 630 RC releases; the changes look minor, it is mainly software updates (but important - and I would like to thank kirk for doing most of the heavylifting). For those who stayed on the "stable" path, however, the changes from Fatdog64 621 to 630 is oustanding. You can check the full list here.
Fatdog64 630 would probably be the last and final release of Fatdog64 600 series. By the time of 630 release, the 600 series is fully two years old - an eternity in computer age; and it does show its age here and there.
This doesn't mean Fatdog64 will end. I and kirk have been discussing on the path toward Fatdog64 700; but this will not happen soon, so enjoy 630 while it lasts.
You can download it from the usual places: http://distro.ibiblio.org/fatdog/iso. For Europeans, nluug.org mirror is probably faster. For those in Australian soil, aarnet.edu mirror is for you.
No comments - Edit - Delete
Food for thoughts
Interesting blog post from IgnorantGuru, the developer of SpaceFM file manager: http://igurublog.wordpress.com/2014/02/17/biography-of-a-cypherpunk-and-how-cryptography-affects-your-life/You may or may not like what he said; and the conclusion he stated may or may not be true; but the facts he stated are indeed true.
No comments - Edit - Delete
Find duplicate files
I happen to see a request in the Puppy forum on how to find duplicate files. Sure, there are specialised tools to do that (fdupes, doubles, etc) but what if you don't have access to them?Turns out it's not difficult at all. This will do it:
find / -type f -print0 | xargs -0 md5sum | sort -k1 | awk '{ if ($1==prevmd5) { if (prevfile) print prevfile; print $0; prevfile=""} else { prevmd5=$1; prevfile=$0 }}'
What the code above does is basically find all files under / (which you can change to something else, e.g. /mnt/sda1, a mountpoint of your disk), then compute the md5sum of these files (you can use sha1sum if you wish, or any other hash programs); and sort the results based on the hashes, and display those that have identical hashes.
Of course, running through all files in your filesystem and computing the md5sum of *all* of them are going to take quite sometime, grind your harddisks, saturate your I/O, and tax your CPU.
And having identical hashes doesn't always mean that the files are identical (although the chance that they aren't are very little); so if you do this with the intent of deleting duplicate files you may want to extend the code a little bit to do full file-comparison when the hashes match.
No comments - Edit - Delete
The way udev deprecates keymap
This, this, this, and this epitomises what is wrong with development of systemd/udev in general.The first post outlined the idea of a major change (and the reason for that), the second post informed that the code is now available, the third post said that the old code is now gone, and the last post said that documentation is needed.
Ok, what's wrong with all that?
1. The reason for change is wrong: keymap rules aren't really that long.
2. The duration between the initial new code commit and the removal of existing functionality is 4 days. We're talking about major change here, breaking previous udev rules that have been working for years.
3. By the time the old code was removed; the new code wasn't complete yet (the data files required for new code was still work in progress - "Martin is still working on it...").
4. In case somebody wanted to help, well ... let's wait until someone volunteered to write the documentation first, shall we? Of course, this was after removal of existing, working code.
I'm not against new functionality. New functionality, new way of thinking are always good (and even if they turn out not to be; they are still worthwhile as they show that the old way of doing thing is still better). What I'm against is major feature change that breaks configurations that have been working for years at the snap of the finger. What's wrong with backward compatibility? It isn't like hwdb and keymap can't be made to co-exist together.
Did they consider this?
5. The new hwdb keyboard mapping depends on DMI. How about platform that don't expose DMI? Didn't think of that, do we? Or perhaps they can screw themselves? Or is it "the kernel bug - ask the kernel team to surface DMI for those platforms"? Yeah, sure. We heard them before. Linux kernel deprecates many features over the years. Not a single one of them was deprecated in four (4) days without co-existence of some sort - especially one that breaks existing functionality in userspace.
Lastly, not so important but still annoying: There is a reason why keymap files are separated into many different files. It is called "ease of maintenance". The new hwdb format for keyboard mapping? Oh it just a giant keymap file, with all the information combined (indexed by DMI/USB ids). It is so much easier to edit a giant file and run "udevadm hwdb --update" than keeping the information in separate files, one for each keyboard type, isn't it? There is a reason why applications that handles large diversity uses separate files (e.g. terminfos, printer definition files) - could you imagine if the maintainer of these combine all those data into one giant file?
I'm not buying the idea, so here is the udev-keymap tarball from old udev, re-packaged to build as an independent package (no udev required). It will work with udev; it will co-exist with the new "keyboard handling" (provided the rules don't clash); it will work with your previous keymapping rules. My only contribution was the new Makefile to make it build. The rest come from here.
An another note - it is a sad day that Debian finally caved in and went with systemd. The problem with systemd is not only technical; it's also about the attitude - as this example illustrate.
No comments - Edit - Delete
FatdogArm Beta reaches parity with Alpha4 today
As the title says. The (unreleased) Beta version of FatdogArm reaches functional parity with Alpha4 today. All that is needed to be done now is testing on all the supported platforms; then we should be good for release.No comments - Edit - Delete
FatdogArm Alpha4 for Odroid-U2 - fixed
I had a major fumble. My instructions and the FatdogArm kernel package for U2 didn't work. The reasons are double whammy:1. I built the latest u-boot, but that latest u-boot doesn't work on U2.
2. I gave the wrong instructions for installing the boot loader.
Both have been fixed now - I have updated the U2 kernel package with the latest working u-boot version (commit 286a81158f01dcb08e16d77790c21fd2a40afc6c) and I have also updated the boot-loader installation instructions: basically, do not use bs=1024 for U2.
Thanks for Mick who directed me to this conclusion. He also more or less confirms that Alpha4 works on U3 too (sort of - he's still testing it).
1 Comment - Edit - Delete
Mobile friendly
This blog is now a little more mobile friendly. Using media queries, if the maximum device width is 600px or less, it will hide the usual menubox and display a simplified menubox instead. Simple stuff.No comments - Edit - Delete
FatdogArm Beta on XO-1.75
I have been slowly building the next version of FatdogArm (FatdogArm beta). This is a complete rebuild, based on newer LFS (LFS 7.4).One of the major goal is to support a wider hardware base, reducing the requirement of the FPU from VFPv3 in Alpha to VFPv3-d16 in Beta; among other things.
Today it reaches a milestone - I've got it to run Xorg and JWM window manager on XO-1.75, a machine with MMP2 CPU (Armada 610 SoC), a well-known VFPv3-d16 machine (as discussed earlier).
It still has a lot to go before it reaches parity with Alpha4 (I have just completed step 5 of my original FatdogArm roadmap), but this is a good progress nonetheless.
Note: For anyone planning to do the same (glibc-2.18 on VFPv3-d16), let me save you some time: have a look at this bug entry. Apply that patch before you build glibc and save yourself some headache - otherwise all you would get from your shiny new glibc is "illegal instruction."
No comments - Edit - Delete
FatdogArm Alpha4 for Odroid released
I had FatdogArm Alpha4 running on Odroid-U2 since early last month. In that time period, I was hoping that I could get beta up and running - but my timing was off; I got occupied by something else (Fatdog64 is one of them).I am now building FatdogArm beta, but it will be a long way off until it reaches parity with Alpha4. So in the interim, I thought I'd just release a version of Alpha4 that will run on Odroid. Get it from the usual place here: http://distro.ibiblio.org/fatdog/arm/releases/alpha4/.
Note that in addition to the kernel package, Odroid-U2 will require a newer fd-arm.sfs (named fd-arm-u2.sfs). The main change from the original alpha4 sfs are these:
a) /etc/init.d/02-cpuspeed is disabled by default - Odroid kernel is sensitive to unrecognised values; it will crash the kernel otherwise.
b) /etc/X11/xorg.conf.d/20-gpudriver.conf defaults to "/dev/fb1" as the framebuffer device (instead of /dev/fb0) - this is how it is on Odroid, /dev/fb0 is actually reserved for LCD screen (which usually isn't connected on U2).
Other than that, it is fd-arm-u2.sfs contains a newer version of Seamonkey. You could have used the original fd-arm.sfs too and make the above changes yourself, but I thought it would be more convenient to have one that immediately works.
I have also updated the INSTALL notes; I have also updated the release notes to reflect the update.
No comments - Edit - Delete
Fatdog64 RC2 is released
Christmas present for everyone :)Kirk has been hard at work building and compiling new packages for Fatdog64, and RC2 is now released.
Release notes here: http://distro.ibiblio.org/fatdog/web/630rc2.html.
Get it from ibiblio.org http://distro.ibiblio.org/fatdog/iso/ or its mirrors.
Forum thread: http://murga-linux.com/puppy/viewtopic.php?p=745962#745962
Highlights:
- kernel 3.12.6 with user namespaces support
- latest Xorg and Mesa for improved performances, VDPAU is now included by default for better video playback performance
- GIMP 2.8.10
No comments - Edit - Delete
