FatdogArm Beta1 kernel packages re-uploaded

If you have downloaded FatdogArm Beta1 recently, please re-download the kernel packages again. The ones I uploaded before have one leftover settings from my development that I forgot to turn off: they have SSH server enabled by default. You can easily turn them off using the Control Panel --> Services Manager, or just
chmod -x /etc/init.d/S50dropbear
but it is a hassle.

The newly-uploaded kernel packages have SSH disabled by default.

Note: I have just re-uploaded the kernel packages, and it usually takes about 24 hours for the mirrors to sync. So either hit ibiblio.org directly or wait 24 hours from this post before hitting your favorite mirror.

Posted on 13 Mar 2014, 19:33 - Categories: FatdogArm Linux Arm XO
Comments - Edit - Delete


FatdogArm Beta1 is released.

After being in the cooker for over two months, I can happily announced the next release of FatdogArm: the Beta1 release.

Get it from ibiblio.org as usual, or from one of ibiblio's popular mirrors: nluug.nl and uoc.gr if you're in Europe, or aarnet.edu if you are in Australia. Many thanks for ibiblio and the mirrors for providing this public service.

Read the release notes first; and if you are new to FatdogArm, please also read the INSTALL instructions. Unlike many of Linux ARM distributions out there, FatdogArm is *not* distributed as images.

Forum announcement here.

FatdogArm Beta1 is the second-generation of FatdogArm; despite its name it is *not* a continuation of Alpha: it is in fact a full-rebuild using LFS 7.4 as the base (I would like to claim "the latest LFS" but LFS 7.5 had just been released as I was gearing for release, oh well) with glibc 2.18 and gcc 4.8.1 but otherwise with many of the packages remain identical with its Alpha counterpart (updates are only done for stability reasons).

The major goal of Beta is a change of hardware platform (from VFPv3-d32 to VFPv3-d16 *without* NEON) to enable it to run on larger class of hardware; as well as a fully-reproducible build system. As a bonus, Beta1 also supports 3D GPU acceleration for all supported platforms, which are: Odroid-U2, Odroid-U3, A10/Mele A1000, A20/Cubieboard2, OLPC XO-1.75 and OLPC XO-4.

Just like Alpha4, Beta1 also ships as a "meta-distribution" (now conveniently provided as a tarball instead of fossil repository) that enables you to build your own customised version as you see fit: headless console-only version; etc. All the kernel sources are provided (kernels were cross-compiled using Linaro cross-toolchain)) so you can also also build new modules etc if you need.

Special thanks to mavrothal and 01micko for OLPC XO support and testing.

Enjoy.


Posted on 11 Mar 2014, 23:11 - Categories: FatdogArm Linux Arm XO
Comments - Edit - Delete


Puppy Linux lives!

In case you haven't heard it, Puppy Linux Slacko 5.7 has been released !

This release is special in so many ways.

Firstly, it represents the FIRST ever official Puppy release from Woof-CE, the community-maintained version of Woof (the Puppy-builder, the meta-distribution of Puppy Linux).

Secondly, it represents the FIRST ever official Puppy Linux release after Barry Kauler (the original author of Puppy Linux) stepped down back in September last year.

More than everything else, this release is a statement of reassurance to the world that Puppy Linux will continue to live and grow strong under the new stewardship and community contributions.

It will continue to move with the times and adapts to new future. Already, a 64-bit thoroughbred Puppy Linux is in the works (Slacko64). The mailing list is rife with contributed ideas on how to bring Puppy to boot on UEFI machines.

Congrats and greets to the team: 01micko (Puppy Slacko), mavrothal (Woof-CE gatekeeper) and many other contributors (zigbert et al).

Posted on 10 Mar 2014, 18:22 - Categories: PuppyLinux Linux
Comments - Edit - Delete


Gearing for FatdogArm Beta1 release

In preparation for FatdogArm Beta1 release, I have removed Alpha3 images and binaries from ibiblio to make some space. Alpha4 will remain for the moment, I will probably remove them when Beta is considered "stable" enough.

I have also updated the article about how to run FatdogArm in Qemu (and the example shell script) for use with Alpha4 onwards (which no longer ships as images) - the instruction will also be useful for Beta1 when it is released.

Posted on 10 Mar 2014, 17:48 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete


3D hardware acceleration on FatdogArm Beta

FatdogArm beta hits another milestone today: I've got 3D hardware acceleration running on Mele/Cubieboard2 and Odroid-U2. As it happens all of them use the Mali GPU variants.

It's quite cool to watch es2gears and glmark2-es2 running on all these boards.
As a reference, here are their glmark2-es2 scores:
Mele A1000 (A10) - 53
Cubieboard2 (A20) - 63
Odroid-U2 (Exynos4412) - 123

Remember that FatdogArm Beta is built with VFPv3-d16 (just like Debian armhf) and no NEON.

The 3D acceleration on all these uses the same Xorg driver (fbturbo) and the appropriate version of Mali blobs, all coming from sunxi-mali (from linux-sunxi repository).

All of this is made possible by the hard work of linux-sunxi folks; especially Siarhei Siamashka (ssvb) who maintains xf86-video-fbturbo (formerly xf86-video-sunxi), Luc Verhaegen (libv) who maintains the sunxi-mali repo (Luc is also the man behind the Lima open-source Mali driver effort), and Dmitriy Beykun (rzk) who ported version 20 of Mali kernel interface from upstream to Odroid kernel.

Thanks guys!

Note: I managed to get 3D acceleration done (but not tested) on XOs much earlier last year (with dovefb/libgfx-marvell); but in FatdogArm beta it will ship disabled by default as enabling it will corrupt the display on some circumstances.


Posted on 26 Feb 2014, 5:57 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete


Connecting machines behind NATs

One of my friend asked me on how to use VNC when both the client and the server are behind NAT routers. He knows that he can re-configure the router to do port-forwarding and such, but it is not good enough because not everyone is comfortable (or competent) enough to do it.

So I looked into the matter and found out that yes it is possible to do so without re-configuring anything. I've written a wiki article to document the process using commonly available tools, it is located here. While it talks specifically about VNC, the methods discussed is readily extendable to any other protocols.

I hope it is useful for others who have similar problems.

Posted on 25 Feb 2014, 6:23 - Categories: Linux General
Comments - Edit - Delete


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.

Posted on 25 Feb 2014, 2:54 - Categories: Fatdog64 Linux
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.

Posted on 25 Feb 2014, 0:41 - Categories: Linux General
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.



Posted on 19 Feb 2014, 19:34 - Categories: Linux General
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.


Posted on 11 Feb 2014, 19:00 - Categories: Linux
Comments - Edit - Delete


Pages: ... [10] [11] [12] [13] [14] [15] ...