RC7 (STABLE) WeeDogLinux Arch 64 now released

[wiak]

Hello rockedge,

Thanks for the report. I'll get back to looking at non-chroot version later. Currently I'm working on a firstrib_rootfs build for "Arch Linux" with idea to have a frugal install option using WeeDog for that. Early work on this addition to build_firstrib_rootfs script are going well, but EDIT: have not got as far as the plugin part (first I have to use Arch a bit since I've never used it before).

Some may be interested in Arch alternative, which would be good since the WeeDog part remains in common to all. Arch turns out to be very easy to build actually - much nicer than the way Debian does things.

Yes, one day we should work towards producing an initial iso - perhaps specially trimmed for smaller size.

EDIT: Currently using mount_chrootver007.sh with the newly created Arch Linux firstrib_rootfs and now using pacman to install linux kernel (default kernel is linux 5.5.13.arch1-1) and linux-firmware prior to first WeeDog Arch attempt. It's a pretty big rootfs though: around 1.5GB...! In practice, it will need an Arch expert to create plugin for final distro out of this; I know nothing about Arch aside from the basics of pacman I am learning now but useful to have for fun experimenting for someone or other during coronavirus lockdown maybe... I'm also thinking of looking into including vector linux firstrib_rootfs build, since that could result in a small rootfs prior to running build_weedog_initramfs script. Having said all that, I won't polish these ones - my own main interest being to stick with Void Linux, since I can't handle learning all the necessaries for properly tweaking all these others myself...

wiak

[wiak]

@rockedge

Actually, rockedge, in parallel with working on a WeeDog Arch Linux build I'm wanting to set up a laptop to run a version of your WeeDog Zoneminder creation. Will probably want to try a version that includes X and minimum version that doesn't need X server (is that possible with ZM?). Are your firstrib plugins and documentation for that on the forum here up to date?

wiak

[rockedge]

hello wiak,
yes the files are up to date. and yes you can run ZoneMinder without an X server running. running it from a web console (it's how most do it) or using zmNinja as a front end for ZM. Either on the a mobile device or another laptop/desktop on the LAN

I use a Dynamic DNS service to track my IP and assign an alias domain name and port forward the router to a Puppy Linux Xenial64 running Apache2 as a reverse proxy that can through virtual host blocks in the Apache2 configuration send each domain name to different machines on the LAN behind the reverse proxy.

This way I can use zmNinja or the ZM web console in a browser from anywhere.

I will double check the instructions, but I think they are okay. I just built a WeeDog64-104 and setup zoneminder with script and all went smoothly just recently.

[wiak]

Thanks rockedge, I'm planning to try this before the end of the week, maybe even tomorrow. I'm hoping old Android phones can be used as simple IP cams so I've hunted out some I have and been busy charging them all...

EDIT: I just noticed that I successfully made an initramfs05.gz and firstrib_rootfs.sfs along with outputted vmlinuz ready for first boot attempt of WeeDog Arch. Last night, whilst watching tv I had started up ./build_weedog_initramfs with void argument (since Arch stores modules and firmware in same place as void, so I reckoned that should work). Anyway, I forgot I had done that but pleased to see it obviously built - whether it works will have to wait for me to try booting it since late at night here now... I'm actually very rusty on using WeeDog, despite having written these build scripts, so I'm thankful I had put in some --help in each of the scripts or I wouldn't know what I was doing! I'm afraid it may be my brain that is getting rusty, but seems to work okay still once I start using it... (both WeeDog build script and my brain).

wiak

[rockedge]

I feel the same way! for 2 days intensely work on web application then switch to doing some python and object detection with Puppy Bionic and using X10 then later I go over to WeeDog and suddenly I'm totally rusty. I have to look at the script help always....and some tricks that are learned from all the attempts fade just enough that one knows that you already solved this..but are not sure anymore exactly how.

No wonder we can't build pyramids or Machu Picchu anymore.

[wiak]

I'm not sure anyone (including myself) is really interested in a frugal installable WeeDog version of Arch Linux, but I've made some progress. I needed to add a few lines of code to handle Arch in build_weedog_initramfs script to get the modules required during boot correctly copied over to the initramfs and to make sure the switch_root finds systemd (which is the init used by Arch). Actually, my first attempt 'almost' worked but ended with dreaded 'Kernel panic' because switch_root couldn't find /sbin/init (just needed a symlink to /usr/lib/systemd/systemd to sort that though. Anyway, have WeeDog Arch booting to commandline now (as uname -a evidences below), and Arch package manager pacman is there and working (or would be except I haven't pre-installed some components needed for internet connection). I also need to work out how to start X display in Arch - I had included xorg in firstrib_rootfs so possibly just need to pre-install a suitable window manager via pacman during build of Arch firstrib_rootfs.

Code: Select all

uname -a
Linux bootstrap 5.5.13-arch1-1 #1 SMP PREEMPT Wed, 25 Mar 2020 16:04:40 +0000 x86_64 GNU/Linux

Not sure when I'll get round to finishing this FirstRib/WeeDog addition since I've not really put much effort into it as yet since busy with other matters, but I suppose I'll get round to it eventually since it clearly works now. Will need to read up on Arch usage first though, to see what extras I need.

Anyway, it's interesting to have Arch Linux booting in a typical Puppy-like frugal install configuration via WeeDog initramfs.

wiak

[wiak]

So I'm continuing to work on WeeDog Arch Linux flavour but came across an interesting issue that wasn't occurring at all with WeeDog Void Linux flavour...

I have WeeDog Arch Linux booting via newly created Arch-based 01firstrib_rootfs.sfs from grub4dos successfully and X with JWM is working (though not prettied up at all by me). However, when debugging I prefer to not use 01firstrib_rootfs.sfs but instead use the uncompressed firstrib_rootfs directory with its name changed to 01firstrib_rootfs (and I usually rename 01firstrib_rootfs.sfs to No01firstrib_rootfs.sfs so it doesn't get used).

But... boot was hanging when using 01firstrib_rootfs instead of 01firstrib_rootfs.sfs with error message on trying to mount the overlayfs to dir merged: "mount... failed: Stale NFS file handle"

I spent a day looking at this issue but couldn't find any clue as to why it was behaving so surprisingly since all the initramfs05 init script does is to mount --bind 01firstrib_rootfs (which itself seemed to work anyway) rather than mounting 01firstrib_rootfs.sfs. To make matters worse, putting rdsh0, rdsh1, rdsh2 debug points on the grub kernel line resulted in the debug break occurring but with keyboard not working! So I couldn't test anything!!! I was close to giving up and just accepting that WeeDog Arch works but only if using 01firstrib_rootfs.sfs. However, just as I reached that point of exhaustion I happened to notice a stupid little mistake in the build_weedog_initramfs script. Odd thing is that it is a mistake that doesn't prevent the build working (and as I said resulted in no problem with WeeDog Void Linux flavour, but turns out to be the issue for Arch!!! The simple mistake was that in the build script I had accidentally missed out the -s when trying to make busybox symlinks (with the result that they ended up being hard links...).

i.e. I had this:

# Make the command applet hardlinks for busybox
cd usr/bin; for i in `./busybox --list`; do ln busybox $i; done; cd ../..

when it should of course have been:

# Make the command applet hardlinks for busybox
cd usr/bin; for i in `./busybox --list`; do ln -s busybox $i; done; cd ../..

There is actually a busybox option to automatically make the symlinks but problems with it, hence me manually making them as above.

Anyway, long story short: putting the missing -s back in results in WeeDog Arch Linux flavour booting fine now with either uncompressed directory 01firstrib_rootfs or with compressed 01firstrib_rootfs.sfs

I can only imagine the tons of hard links I accidentally made to busybox used up too much hard link capability such that mount overlayfs failed. I don't know, nor now care...

Note that one advantage of me noticing my earlier blunder is that the intermediary build directory firstrib_rootfs_for_initramfs_sNNN ends up being around 80MB rather than around 400MB!!! (it was that huge size that I had actually suddenly noticed, which led to me checking the build_weedog_initramfs script more carefully - I don't normally check or care about the size of that directory, but luckily checked...).

I'll be fixing build_weedog_initramfs and uploading the new version soon (just making sure first that I also have the changes to allow Arch flavour build also inside it).

wiak

EDIT: Having to wait prior to further builds because busybox.net seems to currently be down.

[rockedge]

hello wiak!!

excellent progress!
I am looking to run an Arch build very soon but am struggling to fix the latest master of Zoneminder not compiling completely and errors force a build stop. Investigating why this is happening on this WeeDog and I must test another version to see if me trying to get a decent python3 working replaced some library or is at a wrong version or was removed somehow.

what does the command line look like when you are setting up for an Arch build?

Any way...good work and please do incorporate the changes into the current scripts.

I am now experimenting also using the uncompressed firstrib-rootfs to boot from! I feel like updating works better dealing with the one file system to boot from and is more dynamic and keeps the overall size down.

I am using the ideas you are using as well. Also I am interested again in using 2 upper_changes directories....like 01upper_changes

Once again let me stress how well WeeDog (Void) is running and performing. Zoneminder, LHMP and all the pieces that let this machine do face recognition and object detection in almost real time and using daemons to control lamps remotely via X10. Low loads, low temps, fans are quiet

hope all is well with the family!

[wiak]

what does the command line look like when you are setting up for an Arch build?

I haven't written the arch code stuff for build_firstrib_rootfs as yet; currently building the rootfs manually, step by step, prior to scripting that into the build _firstrib_rootfs script.

The main thing is the WeeDog part using build_weedog_initramfsXXX. Actually for both build_firstrib_rootfs and build_weedog_initramfs the commands will be identical to what we are already used to except when building WeeDog Arch Linux flavour you will be using argument "arch" rather than "void".

I now have wifi internet working (haven't bothered connecting to ethernet, but that would work too) using same simple wpa_supplicant and busybox udhcpc method. In fact I'm posting via wifi on WeeDog Arch Linux prototype build right now. I've attached screenshot. Obviously I haven't tried configuring look and feel or JWM at all, as that is no priority of mine, but it is all working fine as you can see.

Official Arch pacman package manager all working fine in WeeDog of course. I hardly know how to use it but seems very similar to Void's xbps (e.g. pacman -Suy to sync and do full system upgrade; pacman -S firefox to install firefox; pacman -R firefox to remove firefox).

Being Arch, this is Firefox version 75.0 of course...

Once I complete the new scripts I will likely publish them on murga-forum thread temporarily prior to creating WeeDog website and properly tidying up associated github or more likely gitlab site for the downloads. WeeDog being capable of providing so many distro "flavours" (Void, Debian, Ubuntu, Devuan, and now Arch) I am really finding the organisation of Murga Puppy Linux site too restrictive and don't want to open multiple Project threads here anyway (especially since there is much in common between each WeeDog, including the weedog initramfs and the firstrib build plugins and weedog run plugins). Forum-wise, I'd like to use rockedge's new forum site, but I'm not happy with it being named Puppy forum for this purpose, since WeeDog is neither a Pup, a derivative, nor even inspired by Puppy Linux - the only connection with Puppy, really, is that I am a longtime Puppy/Dog contributor. The organisation of the new Puppy Forum is certainly better than Murga Forum, but still too much emphasis on Puppy itself from my point of view. Puppy certainly has its place (and there is always a lot to gain from shared discussion/ideas/utilities etc), but a lot of Murga distributions are not derivatives of Puppy, and certainly not WeeDog (which isn't actually wee - though could be pruned such that it was, but I generally prefer it to be full distro capable albeit in core build form to start with).

wiak

[wiak]

@rockedge: I see that Arch has a zoneminder package in its AUR; might prove useful if WeeDog Arch runs so efficiently as WeeDog Void, which I think it might. I presume that Arch zoneminder is pretty up-to-date?

https://aur.archlinux.org/packages/zoneminder/

I could see myself using WeeDog Arch since obviously Arch has very large and generally very up-to-date repos and pacman seems to be very flexible and similar (thus far) to using Void xbps. Admittedly for smaller more customised WeeDog builds, the self-contained nature of xbps makes it very attractive, but for a more general distro, Arch will have advantages in terms of its repo-size. Having said that, by default, the Arch build will use systemd, whereas Void uses nice runit. So it's arguable which is to be preferred - I guess both have their place. Goodthing is that WeeDog builds always provide the convenience of frugal install, plugin firstrib_rootfs build capability and also the on boot weedog plugin facilities and so on (which I hope to improve over time...).

I'm less interested in the Debian/Ubuntu/Devuan-based weedog builds; the DebianDogs already do a perfectly good full-featured (and polished implementation of these) so I prefer to use them when I want that. Nevertheless, for a unique weedog-initramfs-driven Debian-based system that is also on tap here for build-your-own devotees. Slackware doesn't lend itself to the official Slackware package manager build from scratch approach, nor any debootstrap approach, but, as I've already demonstrated it is already easy to build a WeeDog Slackware out of any Slackware rootfilesystem, so, for some distro-flavour completion, I may sooner or later add such an option into build_firstrib_rootfs (which is just a simple extra bash function) and the required little bit of extra code into build_weedog_initramfs.

One advantage of weedog overall build system is that it should basically always work and build the most up-to-date versions of the distro flavours it covers. And being the official flavour systems and package managers, full upgrade/update is also always available during use.

WeeDog may never be well-known or used, but it's design means that it will age only very slowly, and need only minimum maintenance to keep it up-to-date, so it is likely to be a very stable build platform for years to come (as long as the web pages are kept running and maintained as needed so that other interested distro experimenters can discover it in their own time).

As for if I myself, or someone such as yourself, rockedge, will ever produce some sample isos, which no doubt would increase testers, I don't know. I'm fine if no-one else used it, though I believe it is a particularly good system to learn with and from since the scripts, though not entirely simple, are relatively short and hopefully provide reasonably commented explanations/help information. I could certainly expand on the system explanations, had I time, and a more flexible publishing environment, such as I hope to later create. Owing to my having in the past taught Linux courses, I tend to produce WeeDog as something I wish I had for my students to experiment with (including multi-distro; come to think of that I really should look towards Fedora/CentoOS build options since RedHat-based courses were relatively dominant in the education institutions I've worked in).

EDIT: Pacman Cheat Sheet https://devhints.io/pacman
Almost completed first draft of new build_firstrib_rootfs script to include Arch Linux x86_64 flavour. Will give it a spin tomorrow to see what works and what doesn't... I'm not sure if I can use https://archlinux32.org/ project in same method for an i686 build, but I'll look into that (though 32-bit IS surely now really becoming obsolete...). I think new build_weedog_initramfs is pretty much ready so shouldn't be more than a few days before both are published. Note that I am beginning to really like Arch's pacman package manager - easy to use and very flexible.

wiak

[rockedge]

hello wiak!

read everything and feel excited about the project.

There is little interest in the work on bringing the murga forum into a new age...so what if we modify the puppylinux.rockedge.org into weedog.rockedge.org? Simply replace the Puppy logo and change the sub domain to weedog.rockedge.org. I would leave the current registered members as is. We could redesign the layout of the forum to reflect the changes over to the WeeDog Project and re-arrange the design to fit accordingly.

This would energize the new forum and bring the whole thing together and I also believe that FirstRib is a fantastic learning system as well as a solid performing OS and very customizable. Working with FirstRib and building a desktop really helped in better understanding Puppy's inner workings and applying some of the new knowledge there as well.

The Zoneminder package in Arch is of course very close to the master branch git version and is maintained regularly. This of course makes it a breeze to install. Question is does the Arch system also install the LAMP when installing ZM? In Ubuntu this is all automated and is also similar in Debian. My script does the entire install in Void Linux. At some point I will dive in and try to make an official ZM Void package and submit it. But that's to come.

I am going to try to make an ISO of the WeeDog my plug file creates and see if I can generate the ISO, install it and boot it.

At this moment I am processing all that you've written to make sure I did not miss anything.

So many cool things to try out! This shut down of the USA is giving me a great excuse to sit/stand all day working on this stuff. Even the wife does not complain! Hope all is well over there and here Spring is starting to roll up to speed and the forest is turning green again.

[wiak]

There is little interest in the work on bringing the murga forum into a new age...so what if we modify the puppylinux.rockedge.org into weedog.rockedge.org? Simply replace the Puppy logo and change the sub domain to weedog.rockedge.org. I would leave the current registered members as is. We could redesign the layout of the forum to reflect the changes over to the WeeDog Project and re-arrange the design to fit accordingly.

Hi rockedge,

I've been thinking about your suggestion above. It's disappointing that after some initial interest no other project has indicated that it is working towards moving over to your new forum site. That would have been my preference albeit with a different all-encompassing forum title and a section organisation that gave equal weight to all projects it acted as forum for. But, a lot of time has passed and it appears that you are correct that there is little in the way of general interest on moving across; except that is for WeeDog/FirstRib, which, as I've said, remains committed to making that move and sooner rather than later.

Fact is, if WeeDog does continue moving forward and gains some momentum in terms of continued development and general interest then I would want a forum for it that provides sufficient scope for the threads it needs. The current puppylinux.rockedge.org certainly provides that scope, and frankly, the puppy steward crew are losing an opportunity not indicating to yourself that they are in progress of moving across to it as their new forum. I suspect it simply is a case of no-one in main Puppy dev team cares to make that decision to move to a forum that also caters equally to the many other dogs. Eventually they will have to make their own new puppy forum, in that case though, unless John Murga becomes active again and upgrades the existing forum.

I hesitate, but I suppose in these lack-of-move circumstances, it would be better to, at least temporarily go it alone with a weedog forum. Murga forum still exists and easy enough to make announcements there with links and pointers back to weedog forum development/feedback discussions. I suspect you could later offer separate forum for puppy itself it they wanted it, and so on, and perhaps if later interest in a communal Dog/Puppy forum arose, we could always re-arrange things to equitably satisfy that alternative at a later date.

So, yes, I am happy for you to go ahead and create a weedoglinux.rockedge.org forum in the meantime. I think it is important to use term "weedoglinux" rather than simply "weedog" for that, just as tinycore uses tinycorelinux in its forum name and puppy uses puppylinux in its.

Another reason for preferring weedoglinux title in the url is that I (long-lease) control the domain weedoglinux.com (and also tinylinux.info) so I could presumably also arrange for redirects (or some other mechanism) to point to your forum setup. As you know I also control the tinylinux.info domain and website. My weedoglinux.com website is under construction as I indicated elsewhere. Main thing is that I don't have sufficient time to become proficient enough to look after any phpBB site on my own so, from my point of view, your phpBB forum efforts are much appreciated (as are your more general development contributions to weedog/firstrib).

Having said that I was perfectly happy to have the forum as being part of an umbrella Dog-type forum (but not a Puppy-titled forum per se, since WeeDog is not a Puppy); there are certainly advantages to a forum being a melting pot though it does need carefully organised when thus representing many voices in a forum collaboration. (Current Murga Puppy Linux forum represents many different distributions but not equitably at all). But it is a new year development-wise (from my point of view - since autumn/winter-coming here now) and what I really need is some stability in terms of forum situation since I imminently want to push new information/threads across to that, so yes, let's go it alone with or without current users - we can attract them later...; hopefully you can make it "weedoglinux.rockedge.org" then.

wiak

EDIT: I should also mention that during my most recent developments I am in process of building a new git site (at gitlab rather than github) for weedoglinux: https://gitlab.com/weedog/weedoglinux I'm using that during my current WeeDog Arch dev work, but you can expect to find me re-organising it later. In particular, the build_firstrib_rootfs script there is not yet compete nor the latest; so not usable - it is just my last commit but my home git version of build_firstrib_rootfs is much different to that now, though I continue to use underlying arch-bootstrap script for base Arch rootfs creation (similar to debian debootstrap but very simple and tidy).

Alternative, though I am happy with either, would be just to remove the Puppy multiple threads and create a single section for Puppy just like for every other distro. I've already shown how with new phpBB we can create individual HowTo subforums and Utility subforums and so on within that individual section without causing unnecessary front page Forum index bloat. Seems like no-one else wants it thus far so renaming to weedoglinux.rockedge.org makes sense and you can always delete any other distro section later if they continue to have no interest? Or as you say just make it weedoglinux only...

[rockedge]

there is another way....let's not forget that there is a test forum here ->
https://wiak.rockedge.org/

we could leave the https://puppylinux.rockedge.org forum as is for the time being and I could transfer the wiak.rockedge.org site to weedoglinux.rockedge.org and set it up currently for WeeDogLinux and all the sub forum topics needed. We can make it as simple or complex as we wish, with room to modify it as we see fit.
Once it is being used we can use input and observations to customize the structure to it's optimum

So I will go ahead and eliminate the 2nd test forum and reconstruct it as the new weedoglinux.rockedge.org with a basic starting structure. I'll need some guidance on the design of the forums / sub forums.

It will help facilitate storing centrally all the information on the scripts and plugs as well as place to discuss and ask questions and some how to's are always cool.

I'll do it in the morning since it is closing in on midnight here and I still need to run a kernel compile.

[wiak]

there is another way....let's not forget that there is a test forum here ->
https://wiak.rockedge.org/

we could leave the https://puppylinux.rockedge.org forum as is for the time being and I could transfer the wiak.rockedge.org site to weedoglinux.rockedge.org and set it up currently for WeeDogLinux and all the sub forum topics needed.

Good idea rockedge. Let me know how it goes.

wiak

[darry19662018]

I have updated wiki entry for Weedog with gitpage and Rockedge Puppy forum links.

[wiak]

I have updated wiki entry for Weedog with gitpage and Rockedge Puppy forum links.

Thanks darry, should be lots of new developments coming soon. As with rockedge, Covid lockdown getting me back on the computer more than for many months past. (though did none today because was up on the roof fixing a new leak...)

wiak

[rockedge]

hello wiak
working with your hands and in the outside air is good for refreshing the programmer's mind

I started the forum move....working on finding a little logo and will keep the one as is as a space holder in the header
https://weedoglinux.rockedge.org

credentials are the same.

[wiak]

I started the forum move....working on finding a little logo and will keep the one as is as a space holder in the header
https://weedoglinux.rockedge.org

credentials are the same.

Thanks rockedge,

I logged into that and it seems to be working fine thus far.

As far as publishing next build_firstrib_rootfs script (with Arch flavour included) goes, I am close to finishing that now. Actually pretty much all seems to be working right now - just testing, but probably find something else needing tweeked. One issue I had was that it was not working with https:// repos, only with http://. Same issue as void until I included ssl.certs.tar from my repo. Actually that exact file also fixed things for the Arch build also. But one 'problem' is that though I created that ssl.certs.tar.gz file, I can't remember how I did it and failed to takes notes, which is a pity. Certificates operations can be a bit tricky...; anyway, it works and I can re-examine what's inside the tar so presumably easy enough to create should I need to update it later...

As I've said, I'm using script arch-bootstrap to build the base rootfs for Arch Linux flavour since that saves me a lot of duplication in terms of work and it works well. It's also quite a simple script so fits in well with firstrib simplicity ideas. Unfortunately, though it is on github, its author stated about a year ago that he isn't using it much so isn't regularly maintaining it and I note there have been a few issues and unmerged patches from others (which do work).

According to its github issues pages, there have also been attempts to use archlinux32 repositories. With archlinux32 the github issues page talks about problems getting that to work (certificate related errors); I'm hoping my ssl.certs.tar.gz will be the solution to that in which case I'll push the idea up to arch-bootstrap github (though first I'll have to remind myself how I constructed that ssl.certs archive). However, I haven't tried 32bit build, so I don't know if I will be successful with that and if ssl.certs.tar.gz will help there - I hope to try that tomorrow. Anyway, x86_64 build working though haven't checked if plugin code is working for that yet.

So, basically, things are looking good and I'm finding Arch Linux option quite exciting and interesting thus far (though pacman isn't so similar to xbps as I though - some of the pacman commands I listed earler look like same options as for xbps but turns out they don't mean the same and forcing 'yes' for auto-package-installs turned out to be very different too; nothing to do with option -y as it happens; of course, any regular Arch user knows all that... but I've never used Arch before).

Arch uses systemd by default, but I expect I could modify arch-bootstrap to use runit instead, though I am not making that a priority at present.

wiak

[rockedge]

A screen shot of a WeeDogLinux64
Linux void-live 5.4.25_1 #1 SMP PREEMPT Thu Mar 12 20:39:27 UTC 2020 x86_64 GNU/Linux

JWM window manager
ROX --pinboard default desktop
xlunch menu system

outfitted with: geany, rox-filer, mm_view, mc,gftp, Palemoon, Firefox, leafpad, htop, VLC, Hiawatha, mariadb, PHP 7+, Zoneminder, zmeventnotification server, opencv, python 2, python 3, PERL, glade, mtpaint, guvcview, Retrovol, pmcputemp, xload, Lxterminal, uxterm, xterm and more.

Desktop background is a photo I took while onboard the Akademik Mstislav Keldysh in the North Atlantic Ocean.

open windows are X10 controllers for lights around the house I can control from the computer.

[wiak]

A screen shot of a WeeDogLinux64

Nice screenshot and particularly nice desktop photo rockedge!

I'm taking ages finishing WeeDog Arch Linux flavour tests, but I'm very close to completing the x86_64 version of that now. Most of the time is being taken up with a plugin I'm making for it, in which I'm configuring openbox/tint2 with some simple features. Doing this with one eye reading Arch Linux wiki on how to do this and that... I rather like this Arch flavour though initial boot is very slow; it appears to hang, but seems the kernel is checking for something or other and hangs there till timeout and then boots fine - I'd like to fix that but I don't know how and it is no big deal as long as user is patient and just waits... fine once booted. I doubt I will be finished tomorrow, but maybe. The plugin installs a lot of apps (and does a lot of configuration) so it needs a fair amount of free disk space, but runs very economically like any WeeDog.

wiak