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.
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.
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.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).
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."
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.
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
Comments - Edit - Delete
Odroid-U2 is fast!
Odroid-U2 is really fast. I built Seamonkey 2.22.1 (the latest at the time of writing) on it - it took me only 2 hours 45 minutes. This compares favourably with building on my 64-bit x86_64 laptop which is about 2 hours 15 minutes (or so).It is a far cry with my original build of Seamonkey 2.19 on Mele (A10, Cortex A8, single-core, 512MB) - which took between 15 to 18 hours depending on my luck.
During the build, all the four cores of Odroid-U2 was maxed out at 100%, yet the temperature never climbed higher than 70 degrees. Odroid-U2 uses a fanless heatsink, and this heatsink - while noticeably warm - was still touchable. This contrasts with my x86_64 laptop, whose temperature climbs to a worryingly 95 degrees with its fan is being overworked to prevent thermal shutdown.
I need to revise my opinion that ARM is still playing catch-up with Intel - it no longer is. In fact, there is no Intel offerings which is on similar power/performance/price as this one. Intel Minnowboard is a single-core hyper-threaded (=dual-thread) 1GHz CPU and 1GB RAM priced at $199. Intel Galilo is a measly 400MHz single-core CPU poised to compete with Arduino. None of them are even close in terms of price/performance to Odroid-U2 (I didn't check the specs on their power consumptions) - this board and its Exynos4412 Prime CPU is in a class of its own.
Comments - Edit - Delete
FatdogArm on Odroid-U2 - take two
I really want to have console framebuffer on the Odroid.So I spent quite a while to figure out what's wrong with console framebuffer. I wanted to know why the framebuffer works with X but not with fbcon.
First, I figured which driver provided the framebuffer functionality (not easy since /proc/fb doesn't show the driver name). Turned out it is "videobuf2-fb.c". Secondly, I traced the failing call from fbcon.c - this was one was quite straightforward, and brought me back to videobuf2-fb.c - and there lied the problem - videobuf2-fb.c checked for fbcon call and reject it (the line that did it was even commented that mmuch!). The check was actually for an init call from kernel space (which fbcon does).
Okay, so what happened if I allowed fbcon call to pass through? Various bad things happened - either the system didn't boot up at all; or, if I switched fbcon to use the framebuffer later, the system froze. Well I can't see anything when this is happening, so I have to hazard a guess: there must be some interlocking mutex between videobuf2-fb and fbcon. Enabling fbcon call to videobuf2-fb caused a deadlock somewhere. Without a serial console, things like these are very difficult to trace and debug - so that was the end of it.
Turned out all the above was a wild goose chase anyway. I was planning to upgrade to kernel 3.8, and now that I hit dead-end with that investigation, I decided to build it. Guess what? The hardkernel guys (or is it samsung itself? not sure) have fixed the framebuffer issue! The videobuf2-fb issue is still there; but there is a brand-new "exynos-drm" module that does the same job, but only better!
In fact, kernel 3.8 improves on other things: HDMI audio now works, alsa volume control now works ... three cheers for the hardkernel guys.
So yeah, looks like it will be smooth sailing from here.
Comments - Edit - Delete
FatdogArm on Odroid-U2
I've just received an Odroid-U2 board a few days ago, from a nice person who wish to remain unnamed (thank you!).Odroid-U2 is a board with Samsung Exynos4412 Prime SoC, a 1.7GHz, 4-core Cortex-A9 CPU with 2GB of memory. It's very small (smaller than cubieboard2) yet it is very capable; it demonstrates lucidly where ARM is going (and Exynos4412 is actually last year's product - the newest one being Exynos5 which is an 8-core CPU).
I immediately set to task to get FatdogArm running on it, after confirming that the board works by running stock Hardkernel Ubuntu ARM on it.
I went with the (now) standard procedures of building the bootloader (u-boot), building the kernel, and preparing the initrd (mainly for kernel modules), and put them into SD card.
I immediately hit a snag - the system seemed to boot but my screen was blank. After a few visits to odroid/hardkernel forum, it was made obvious that odroid doesn't have a working framebuffer console for HDMI output to due quirky way the HDMI output driver had been written. For the better or worse, I don't have an UART serial cable to go with it - which means I'm blind, I don't know whether the board works or not (and if not, what is the error).
But thankfully Hardkernel guys (the manufacturer of this board) has been working hard to prepare a kernel that is rock-solid - the board actually worked the first time, it's just that I can't see the output. I typed the output blindly (I know what to expect if things goes right), slotted in my USB flash drive and piped command output to the flash drive, and read the output on my laptop. This way of working soon got me a working ssh server on the odroid, and with that I'm no longer blind. Sure I still can't see what happens before the ssh server is started but that's not so important at the moment.
With ssh working, I managed to get X desktop working shortly afterwards (as it turned out, there is nothing special required except to specify the correct framebuffer device), here's a simple screenshot based on a tweaked Alpha4 release (it must be tweaked because verbatim Alpha4 release has a boot-up command (/etc/init.d/02-cpuspeed) that causes the kernel to crash).
Comments - Edit - Delete
