KLV-Airedale-alpha Released for Experimentation and Improvement by the Puppy community

[keniv]

Hello All,
Thank you for the replies and the information therein. I will try to answer the questions I've been asked as best I can. Unfortunately I cannot answer via klvalpha3 as I cannot make a wifi connection. I will move between klvalpha3 and fossapup in order to reply.
@rockedge

What type of machine specs are you running KLV-Airedale on?

This is taken from PupSysInfo in fossapup.

PC Manufacturer: Dell Inc.
Product Name: Vostro 230
Pentium(R) Dual-Core CPU E5400 @ 2.70GHz
Min/Max Speed: NA/NA MHz
Current Speed of Core 0:2171 MHz, 1:2577 MHz
Core Count: 2
Thread Count: 2
Memory Allocation:
Total RAM: 3905 MB
Used RAM: 1240 MB
Free RAM: 2665 MB
Buffers: 66 MB
Cached: 999 MB
Total Swap: 63 MB
Free Swap: 63 MB

Nowadays this is not well specked but I am able to run fossapup, bionicpup, busterdog and easyos 2.9 (updated from 2.7) and others without problems.

@mikewalsh

I have to say that I always found XFCE to be 'challenging' to work with..................but I'm personally looking forward to the JWM-ROX variant

I agree with the above quote. Perhaps it's just habit but I prefer JWM-ROX though I have used others without much trouble.

It's early days, so there's going to be plenty of issues, and rough edges to be smoothed-off, etc.

Yeah, I saw these were marked alphas so I appreciate that but having got to the desktop I expected to get a bit further than I got after that especially as others had managed to make a wifi connection and run a browser.

@wiak

What kind of partition filesystem did you install this on Ken?

The hdd has two partitions. klvalpha3 is on sda2 which is formatted as ext3.

Could you open a terminal and enter: whoami

Here is the output.

Code: Select all

bash-5.1# whoami
root

However, here is the output when I run

Code: Select all

wiakwifi

in a terminal.

Code: Select all

bash-5.1# wiakwifi
logname: no login name
###########You are logged in as USER: ###########
Configuring network interfaces. Please wait...

 Interface Names->
 enp2s0 
 wlp0s29f7u5 

Enter interface name chosen from above for connection:

Please note the You are logged in as USER This really confuses me.
I hope I have covered all the questions I was asked and that this helps.

Regards,

Ken.

[hundido]

I think I'm still missing something:

Code: Select all

menuentry "Puppy vanilladpup 9.0.14" {
  insmod ext2
  search --no-floppy --fs-uuid --set=root f60fb816-c5b9-48ac-8707-daf04dda1588
  echo "Loading vmlinuz"
  linux /Kennel/Vanilla32/vmlinuz pmedia=usbflash pdrv=f60fb816-c5b9-48ac-8707-daf04dda1588 psubdir=/Kennel/Vanilla32 pfix=fsck,fsckp TZ=AKST9AKDT,M3.2.0,M11.1.0
  if [ -e /Kennel/Vanilla32/local-initrd.gz ]; then
    set local_rd=/Kennel/Vanilla32/local-initrd.gz
  else
    set local_rd=
  fi
  if [ -e /Kennel/Vanilla32/ucode.cpio ]; then
    set ucode_rd=/Kennel/Vanilla32/ucode.cpio
    echo "Loading ucode.cpio and initrd.gz"
  else
    set ucode_rd=
    echo "Loading initrd.gz"
  fi
  initrd $ucode_rd /Kennel/Vanilla32/initrd.gz $local_rd
}
menuentry "KLV-Airedale-alpha3" {(uuid)
  uuid 8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa
  kernel /KLV-Airedale-alpha3/vmlinuz-5.13.19_1 w_bootfrom=UUID=8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa=/KLV-Airedale-alpha3 net.ifnames=0
  initrd /KLV-Airedale-alpha3/initrd.gz 

 title KLV-Airedale-nokernel (LABEL)
  uuid 8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa
  kernel /KLV-Airedale-alpha3/vmlinuz w_bootfrom=LABEL=psystem=/KLV-Airedale-alpha3 net.ifnames=0
  initrd /KLV-Airedale-alpha3/initrd.gz
  }
if [ $grub_platform = 'efi' ]; then
    menuentry 'System BIOS setup' {
        fwsetup
    }

I tried to make it look like the other boot entries, thinking there might be something important in the sytax of the {}.

XFCE? That's one of the desktops that doesn't have a blue light filter available, right? Pretty much excludes me from using it if that's the case.

@mikewalsh

Erik, if a JWM-ROX version should make an appearance, how easy (or hard) would it be to modify/convert existing Puppy stuff for use with it, given the Void Linux base? Call it 'professional curiosity', if you like, given how much stuff I've packaged for Puppy itself over the last few years.....

One of my favorite things about puppy is all the "artisanal" .pet and portable apps. It's fun to find all the things people made on the forum. To me, it seems like the home-made bread of programming. Things special and unique.

[mikewalsh]

@keniv :-

You might be having the same problem I was, Ken.

Like me, you're not getting the 'normal' eth0 & wlan0; instead, you're getting the "ifnames" equivalents:-

Code: Select all

enp2s0 
 wlp0s29f7u5

I found that by changing these back to the 'standard' items, ethernet finally connected. (In my case, it was 'enp4so'. wiakwifi refused to connect on that one. As soon as I'd changed it back to 'eth0', it all worked beautifully...)

-----------------------------------

Before you boot into KLV-Airedale again, go into your Grub4DOS, find KLV's boot stanza, and at the end of the kernel line, enter a space, then:-

Code: Select all

net.ifnames=0

.....save, and re-boot. Now try connecting via wiakwifi again. I'll bet you this time it'll work as it should.

--------------------------------------------------

(To be fair, rockedge has provided this same info in the ReadMe file among the ISO contents. I found you can simulate a 'virgin' boot again by deleting the two directories 'upper_changes' & 'work' .....like deleting a save-file/folder, I guess. I don't know of a way to simply de-activate them.

I think the command

Code: Select all

wiakwifi reset

....will clear any existing connection data. I believe that's how it's supposed to work, but I could be wrong...)

Let us know what happens. My own knowledge is somewhat "piecemeal", and only very recently acquired, like most of us.... I hope I'm not steering you up the garden path!

Mike.

[rockedge]

I don't know of a way to simply de-activate them.

Simply rename /upper_changes to /No-upper_changes or /upper_changes-bak
, basicly any name other than what it is. If one places a 2 digit number in front like /55upper_changes this directory will be loaded and a new /upper_changes will be created and written too instead of /55upper_changes. This is sort of a roll back system. One can make all kinds of /upper_changes, just rename them and one can collect them and swap back and forth. Good for testing....

[Grey]

I tried to make a bootable image and run it in Qemu. And I couldn't. Tomorrow, if my head clears up, I'll try again.

By the way, the .iso is not bootable, maybe at this stage it is better to upload as tar.xz for example. Or do the build tools do exactly iso?

[rockedge]

Or do the build tools do exactly iso?

It is possible to distribute as .tar.xz

I have not tried to make it a boot able ISO yet. I will now soon try it. I have other problems with a screen saver that has a mind of it's own (HAL9000) and is locking the desktop making extra work.

Also found out I can mix modules and fdv-XXX.sfs from different kernels. This version I am typing from is running the stock bionic 4.19.23 kernel. When using just the zdrv.sfs both eth0 and eth1 are not detected at all. So I added the fdrv-5.4.70-rt40.sfs which I named 00firmware-5.4.70-rt40.sfs to the frugal directory and now kernel 4.18.23 is humming along.......

2021-12-12-211037_846x198_scrot.png (28.04 KiB) Viewed 685 times

2021-12-12-211046_1024x768_scrot.png (178.02 KiB) Viewed 685 times

I am pushing forward regardless. What I'm getting is a bad ass fast OS. Take on any one soon. Publish or not publish that is the question.......I have what I want and have no other motivation to keep the project going on a share basis if that's what the people demand. My enthusiasm has extinguished to push out in new directions......

So I will now learn woof-CE and once I do I will begin to churn something out. Maybe I'll show it to you.

[wiak]

I found that by changing these back to the 'standard' items, ethernet finally connected. (In my case, it was 'enp4so'. wiakwifi refused to connect on that one. As soon as I'd changed it back to 'eth0', it all worked beautifully...)

-----------------------------------

Before you boot into KLV-Airedale again, go into your Grub4DOS, find KLV's boot stanza, and at the end of the kernel line, enter a space, then:-

Code: Select all

net.ifnames=0

.....save, and re-boot. Now try connecting via wiakwifi again. I'll bet you this time it'll work as it should.

--------------------------------------------------

(To be fair, rockedge has provided this same info in the ReadMe file among the ISO contents. I found you can simulate a 'virgin' boot again by deleting the two directories 'upper_changes' & 'work' .....like deleting a save-file/folder, I guess. I don't know of a way to simply de-activate them.

I think the command

Code: Select all

wiakwifi reset

....will clear any existing connection data. I believe that's how it's supposed to work, but I could be wrong...)

The above all looks correct. I am optimistic that if keniv follows above advice wiakwifi will successfully connect.

An alternative 'should have been' continuing to answer the wiakwifi dialogue questions with the names it found for the interfaces (which is what I myself do - i.e. I don't myself bother with net.ifnames=0, but nothing wrong with that approach and rockedge used it himself a lot in the past).
i.e. for wlan would use: wlp0s29f7u5 (followed by appropriate WLAN name and password when asked)
and for ethernet connection would use: enp2s0 (and just hit enter a couple of times thereafter cos there is no 'name' or 'password' required for ethernet)
Once it works first time, it all seems very simple (since you will then trust the mechanism), but until then it may seem like gobbledygook.
Certainly easy to enter any names wrongly (especially these weird interface forms of names hence net.ifnames method maybe better to start with anyway). Also, yes, if you get WLAN name or password wrong of course it won't connect, but 'wiakwifi reset' allows you to re-enter the info on next attempt. Hope it works for you - I also suspect it will from your report keniv (the fact the interface names were shown by wiakwifi basically means the firmware was all found too; I do need to tidy up the messages wiakwifi otherwise reports - as long as you are root user, which you are according to whoami, then all 'should' connect fine via wiakwifi on most networks, but not all - if not, there is one other thing I could suggest you try, but you'd need to edit the /usr/local/bin/wiakwifi script slightly. I'll leave that further possibility till you test mikewalsh suggestions since editing wiakwifi may not be required).

[bigpup]

Rockedge,

Any reason you have not followed the normal Puppy way of naming the different files in the ISO?

First thing I did, with the manual frugal install I did.
Renamed the initrd.gz and vmlinuz to just those names.

I see the SFS files are not the normal adrv thru zdrv names.

Is this just because it is alpha or are you totally getting away from, the normal Puppy way of naming them?

Is this going in the direction of being totally different from a normal Puppy Linux, in everything, or just what programs and features are in it?

I see it just makes a save folder and uses it with no user input to do it or not do it.
I am kind of 50/50 on that feature.
Probably best idea with a new Puppy User!

Am I just missing how to do it or feature not yet in it, to install pet packages?

I was going to install the latest version of SNS for network connection, as a pet package, and see how it would work.

[wiak]

Good thing is, once you get to desktop as root user (and even better an internet connection), the world becomes your oyster; we can in time guide you from then on in changing Desktop Manager to some other form such as JWM/Rox or Openbox/tint2; work involved to polish any of these, but easy to basically get them working as alternatives to full-on XFCE. More difficult is the sort of issue rockedge is having with system lockup because of weird XFCE screensaver effects - off the top of my head, for one, I know nothing about what might be causing that - problem may well just disappear in a JWM/Rox variant, but have to find solution for XFCE option too of course.

Aside, from these teething issues, the distro is well on the way - once Internet connectivity acheived, xbps package manager makes it relatively trivial to install anything you wish, and the numbered sfs file addon module layers should already work out-of-the-box in most cases (sfs-load capability more complicated of course and needs tested for correctness).

In addition to ability to use previous saved folder (upper_changes) as a read-only rollback folder simply by numbering it prior to next boot (e.g. as 50upper_changes), where a new non-numbered upper_changes folder will be auto-created for next read_write session, it is also possible to make any read-only layer into an sfs or to leave it uncompressed, which can be incredibly useful since even main root filesystem can be left uncompressed (but still with number for layer position in folder name). You can then fine-tune distro manually simply by changing whatever you want inside the numbered uncompressed layer folders - so gives you many of the advantages of full install distros yet with the advantages of using frugal install layers... i.e. you can use any mix of uncompressed or sfs layer addons (just use appropriate two-digit layer number for order you want them loaded). To avoid accidental changes, making say 50upper_changes rollback into an sfs (via mksquashfs utility) may often be preferred overall, and also then takes up less disk storage space of course; however, disk storage space is often plentiful anyway, and at development phase numbered uncompressed folder layers can sometimes be particularly useful as can be demonstrated/discussed later.

[bigpup]

Rockedge,

Just a suggestion, but I think it would help you.

When you release a new ISO.

Give us some info on what is new, what needs to be looked at, fixed, tested, etc.....

What is still needed to be in it for the next newer ISO.

We are here to help!

Give a little clue as to what needs help!

[wiak]

Rockedge,

Any reason you have not followed the normal Puppy way of naming the different files in the ISO?

First thing I did, with the manual frugal install I did.
Renamed the initrd.gz and vmlinuz to just those names.

I see the SFS files are not the normal adrv thru zdrv names.

Truly, this is optional. At dev stage it is useful for sure to know which kernel version we are talking about, but for a stable release then simply vmlinuz and initrd.gz naming is easier.

The sfs addons are layered according to first two digit numeric order, so nothing wrong with calling them say 00zdrvXXX.sfs and 01fdrvXXX.sfs and if you really want to you could even call 07firstrib_rootfs.sfs 07puppy_whatever.sfs, though that root filesystem isn't actually a traditional Puppy root filesystem at all, so I wouldn't advocate that. Main thing is, in this distro only the first two digits are important, so could even go to the extreme of simply naming them 00.sfs, 01.sfs, 07.sfs and so on appropriate to whatever order you want them to appear in the overlay.

But just use Puppy naming convention in your own frugal install if you wish, but make sure you include the appropriate two-digit numeric at start of module filename or it simply won't work...

Is this going in the direction of being totally different from a normal Puppy Linux, in everything, or just what programs and features are in it?

I see it just makes a save folder and uses it with no user input to do it or not do it.
I am kind of 50/50 on that feature.
Probably best idea with a new Puppy User!

In terms of traditional Puppy look-and-feel, to a large extend you can make it that way as much as you like, EXCEPT this distro does not use PPM but rather, the official package manager of the upstream repos the packages are being taken from (i.e. xbps package manager for this Void Linux compatible case). So no, it is not out-of-the-box designed to accept dotpet packages. Could that be arranged - yes, a utility could be written that would install a dotpet package - the results of that would be somewhat unpredicatable of course - simple ones such as simple bash/gtkdialog dotpets would work perfectly. Major apps in dotpet form would possibly clash with Void installed libs (though in that case Void Linux can already provide such packages anyway). Similar applies to use of sfs-load portable apps - most of these if designed portable enough will actually likely work fine though (though xbps package manager will know nothing about them being there, but then again neither does PPM in Puppy know portable apps are being used...).

I was going to install the latest version of SNS for network connection, as a pet package, and see how it would work.

Indeed, I am thinking similarly for playing with Frisbee and PeasyWIFI, but I'd convert the dotpet into either a small sfs addon first (with an appropriate two-digit number to say which layer it would be merged into) or I'd experiment with just including the contents of the dotpet under /usr/local hierarchy - easy enough to re-structure a dotpet out of /usr/bin to /usr/local/bin (indeed I have a version of weX and Precord that simply fits into /usr/local/bin and dotpets are easy to handle since really just .tar.gz files). i.e. simple dotpets will simply need a conversion utility to move them out of /usr/bin (which should not be used by other than the official upstream repo binaries and so on).

[wiak]

Rockedge also knows about all these factors I mention in above post so really I am just an observer here, but if people jump on board then a lot can be acheived. Whatever is produced is not a replacement for traditional Pups, nor traditional DebianDogs nor for my own WeeDog builds (where I am perfectly happy to use parts of the DebianDogs and Pups as well as upstream distro packages).

I forgot to say that as of now, the grub config is why the save folder is automatically created on media folder. Different options can be put in the grub config to instead save changes in other places including RAM for write-back later (like Pupmode 13 type operation or DebianDog changes EXIT mode), but these are just operational modes. To keep things simple at this dev stage, it is easier to stick to that simple auto-save persistence back to upper_changes folder on boot partition/directory. Certainly this particular Kennel Linux offer of rockedge is not a woof-CE design so terminology is not the same - not being a traditional Puppy of course there is no mention of Pupmodes for example, but similar functionality is indeed available pretty much completely, and some extra modes besides (all such are in a state of flux both at woof-CE and in other distro initrd 'designs' depending what users wish for and dev time permits. There are no Distrospecs files and similar so would actually be tricky to try and adopt same kernel grub option names - they are similar in final effect, but not implemented the same way so more often than not actually need specified on grub line differently (in this KLV, for example, it is often important to state the uuid and/or LABEL of where user wants things to be found - but it is also very flexible in what can be asked for and even whether an sfs or an uncompressed folder layer).

Short answer: best for now, just to accept simple (perhaps most useful) case of save persistence simply always going to upper_changes on boot partition/directory; nothing needs to be specified at all for that to happen.

If you manage to get Puppy network connect package working via sfs or manual additions into /usr/local/bin and similar let us know. Just now trying out different net connect options seems like a good priority. If not managing, then will be worth others looking into what went wrong. Some on the forum are particularly skilled with network connection matters (it is not easy and different 'possible network app solutions' apparently often conflict in their operations) so they would be particularly useful to help with all of these options.

Do not be afraid of learning how to start and stop runit services - that is a major key to controlling this particular Void-Linux-based KLV distro - refer to upstream Void docs for the know-how; yes, a bit geeky, but no more so than any basic shell script knowledge, which most here already have - way easier actually than sysVinit since that init system doesn't really have any nice standard services management procedure (which runit, like the often hated systemd, nicely does).

By the way, though I forget how runit services work and are to be configured, my quick attempt to use NetworkManager as a runit service last night (which seemed to fail) indeed connected automatically on booting this morning. I guess I forgot to try simple rebooting after following Void Linux NetworkManager docs, but that package is pretty big and more so when used with that nm-tray applet.

[bigpup]

There are a Hugh number, of really good Puppy specific programs, out there, as pet packages.
I for one, would not want to no longer be able to use them.

I know we have not really used xbps very much.
But even PPM, getting stuff compiled for another specific Linux OS, did not work 100%.
The stuff was not compiled specifically for Puppy!
Hopefully, xbps will be better.
Not sure if alpha stage, is a good time to give it a workout.

[wiak]

There are a Hugh number, of really good Puppy specific programs, out there, as pet packages.
I for one, would not want to no longer be able to use them.

I know we have not really used xbps very much.
But even PPM, getting stuff compiled for another specific Linux OS, did not work 100%.
The stuff was not compiled specifically for Puppy!
Hopefully, xbps will be better.
Not sure if alpha stage, is a good time to give it a workout.

Well, for the most part, the distro is fully upstream Void Linux compatible right away - it is not alpha from that point of view. It is alpha from the point of view of configuring some services since it is not using any pre-configured Void Linux root filesystem but is instead being built up from scratch by rockedge. The distro for the most part is thus rock solid - once you get over the likes of network connection configuration. Using Puppy apps and sfs addons and so on is the main part of development needs - some of that will be easy (just simple install/conversion utilities) - the DebianDogs have been making such conversion utilities for almost ten years now - many of the same will be usable. Some existing dotpets are worth more than others though I am not judging. Upstream repos will certainly work pretty much flawlessly (unlike PPM attempts to do the same), which is particularly important when trying to install more complex apps that involve many dependencies. But lots of Puppy-style techniques are very handy and attractive, and there are indeed tons of nice utility dotpet apps, which it would be daft to not accommodate whatever style of Kennel Linux distro someone is offering up for use.

Furthermore, no-one (not me anyway) is arguing against other Kennel Linux community distro offerings, be these be based on woof-CE design or whatever - just that rockedge found this build method easier. There are plenty of usable facilities available in woof-CE - for example the (huge) kernel build kit is perfectly useful immediately here. Main thing is that this build method is easy so easier to involve non-experts, though more research/expertise/Wiki-reading obviously helps greatly. This KLV is not any kind of remaster; the end result will be a re-buildable/modifiable script, though rockedge will have to keep track of changes for that to be true...

Certainly, I've said more than enough. I'm away to play with the distro and see if I can sort anything out. Maybe I'll just sleep for a few months and come back to see if it is still being used or discussed or if something else has appeared in its stead.

[rockedge]

Here is a BOOT ABLE ISO called KLV-Airedale-alpha4
Download Size = 457 M
https://rockedge.org/kernels/data/iso/K ... alpha4.iso

This is KLV-Airedale-alpha3 with the boot components added.

@Grey Tested in QEMU and starts and runs on a Bionic64-CE (woof-CE built) host.

Screenshot(4).png (32.6 KiB) Viewed 714 times

Screenshot(5).png (202.12 KiB) Viewed 714 times

Code: Select all

title WDL-KLV-Airedale-alpha4 (RAM0)
 kernel /vmlinuz w_bootfrom=/mnt/sr0 w_changes=RAM0 net.ifnames=0
 initrd /initrd.gz
 
title KLV-Airedale-alpha4 (LABEL,RAM0)
 kernel /vmlinuz w_bootfrom=LABEL=KLV-Airedale=/ w_changes=RAM0 net.ifnames=0
 initrd /initrd.gz 

title KLV-Airedale-alpha4
 kernel /vmlinuz w_bootfrom=/mnt/sr0  w_changes=/mnt/sda1/WDL-live copy2ram net.ifnames=0
 initrd /initrd.gz

title KLV-Airedale-alpha4 (LABEL)
 kernel /vmlinuz w_bootfrom=LABEL=KLV-Airedale=/  w_changes=/mnt/sda1/WDL-live copy2ram net.ifnames=0
 initrd /initrd.gz
 
title KLV-Airedale-alpha4 (LABEL no copy2ram)
 kernel /vmlinuz w_bootfrom=LABEL=KLV-Airedale=/  w_changes=/mnt/sda1/WDL-live net.ifnames=0
 initrd /initrd.gz 

ISO built in Puppy Linux Bionic64-CE (woof-CE build) :

Code: Select all

mkisofs -b boot/isolinux/isolinux.bin -c boot/isolinux/boot.cat -D -l -R -v -V "KLV-Airedale" -no-emul-boot -boot-load-size 4 -boot-info-table -o "KLV-Airedale-alpha4.iso" KLV-Airedale-alpha4

_

[Grey]

This is KLV-Airedale-alpha3 with the boot components added.

Yes, that's much better Now it starts. It's a pity that without GL-acceleration (virtio-gpu), which must be disabled in Qemu, but this is a long-standing xfce problem.

[wiak]

Please note the You are logged in as USER This really confuses me.
I hope I have covered all the questions I was asked and that this helps.

Regards,

Ken.

Fair enough, but that is not a fault of wiakwifi per se. The logname command typed at a terminal (from coreutils package, which is installed) is supposed to report who is logged in (of course). wiakwifi refers to that command in its script code, but logname is not reporting correctly. It's no big deal in practice here; whoami is an alternative but not used in wiakwifi script for various reasons I can't remember. No idea why logname not working - maybe an environment variable was supposed to be set but wasn't at auto-login-as-root time (e.g. LOGNAME ? No, tried it, wasn't that).

However, solution for logname is probably in this lot: https://www.toolbox.com/tech/operating- ... ng-100610/

I could in this case change wiakwifi script (even to just use $LOGNAME or `whoami`... maybe...) but that is just a fudge since logname should be made to work anyway and no guarantee LOGNAME is set (though it is in my test).

This is what a 'developer' actually is: someone who googles (or Duckduckgoes) tries things and learns how to do it - lurking around letting others do that is an alternative and I'm happy doing that too. That's what I do anyway; I have no formal training in UNIX or Linux.

[Grey]

wiakwifi

Don't you have an ethernet-only version? Without wifi part.

[wiak]

wiakwifi

Don't you have an ethernet-only version? Without wifi part.

It was originally wifi only, hence the name. It works with ethernet too. Just use the ethernet interface name reported and hit enter twice since no wlan name or password involved. I don't sit near my home router, so was always a pain for me to have to move computer to plug in ethernet cable so it was important for my own needs to be able to use wifi on most any distro I tried without too much effort - hence wiakwifi was first written and I just always include it since works for me.

Be warned though - if you manage to set up NetworkManager as a runit service, don't use wiakwifi as well - NetworkManager will already have started the likes of wpa_supplicant (for wifi connections) and a mess will result such that nothing will work... Use one or both and wiakwifi is just simplistic dumb method that is convenient sometimes.

[wiak]

As a matter of interest, I managed to get a network connect tray icon/app working by removing nm-tray with:

Code: Select all

xbps-remove nm-tray

and installing instead:

Code: Select all

xbps-install -S network-manager-applet

though that takes up a bit more space maybe...

Not sure about nm-tray in terms of finding missing icon, sorry.

Of course, to get NetworkManager all working I had to configure it as a runit service per the Void documentation here:

https://docs.voidlinux.org/config/services/index.html
and
https://docs.voidlinux.org/config/netwo ... nager.html

On reboot NetworkManager than auto-connects for me once first set up via the taskbar network-manager-applet

It's pretty full-featured/nice-looking that network-manager-applet; it's by RedHat though (so what do you expect...)

[wiak]

This may surprise you, but:

Code: Select all

xbps-install -S gnome-screenshot

isn't particularly huge to download for current alpha KLV, and it is very pretty to use.

But yes, always nice to have commandline scrot and mtpaint available (I always use mtpaint for scaling images).

Per usual habit, I tend to refer for packages to:

https://voidlinux.org/packages/

e.g. small epdfview or ultra-big (qt5-based okular) or better probably for most to use portable app masterpdfeditor...

Here is one way (example) to search for packages (from the commandline) in Void repos:

Code: Select all

xbps-query -Rs epdfview

If you omit the 'R' then the search will be on packages you have locally installed.

However, that trawls through upstream I think so can be slow. Aside from online packages search (which is great) a fast alternative is to install xtools package, but that is a big download so I don't.

For the package browsers amongst you, I just came across the following (but its http:// so I have no idea how 'safe' it is so put a space after http:// here so purposively not appearing as a link; maybe there is better https:// page of the same somewhere?): http:// 54.37.137.89/pkgs.void/all
If trying it, be patient, takes a while to load 'all' packages to browse. I don't think it is particularly useful page though - better normal online package search page methinks.

I actually have a habit of using sometimes quite large apps, because they generally have many features, such as nomacs (when I already have many Qt libs installed), but of course tiny image viewing apps sit nicely for small downloads and running in RAM. I never myself use lite inkscape (so would never bother including that at all) - I always need the full version, which is so much more powerful (a portable sfs app version again would be equally appropriate in practice).

Just like in Arch Linux (specially after reading relevant Arch Wiki section) you can easily experiment/try-out full Wayland (or Xwayland for that matter): https://docs.voidlinux.org/config/graph ... yland.html though you have to choose appropriate DE and apps that work with that of course.

If you want to experiment with lightweight containers you can try, for example, package 'containers' (uses namespaces - by one of Void devs I believe):

http:// 54.37.137.89/pkgs.void/package/containers which is: https://github.com/arachsys/containers

or the likes of: https://docs.voidlinux.org/config/conta ... index.html

Off to watch some tv now.

[Grey]

Alpha4 with Ungoogled Chromium (96.0.4664.93) on board.
Applications>>Internet>>Ungoogled Chromium
600 megabytes, but browsers are not small these days.
https://mega.nz/file/pxsyFRBY#oaqrHo7sH ... 12eG3gVAyM

Checked in Qemu. Internet via wiakwifi. There is sound on Youtube. Everything seems to be opening up.

Of course, if you go to chrome://gpu/, then a lot is disabled. Can be enabled in chrome://flags/

Probably it will be necessary to add add-ons someday, such as GroupSpeedDial and adblock Origin. It is extremely inconvenient without them.

[williams2]

In BionicPup64:

Code: Select all

# logname
logname: no login name
# busybox logname
root
# echo $USER
root
# whoami
root
# su spot
$ busybox logname
spot
$

In https://askubuntu.com/questions/490620/ ... nd-logname

The utility logname is broken in 16.04, apparently on purpose ...

[wiak]

In BionicPup64:

Code: Select all

# logname
logname: no login name
# busybox logname
root
# echo $USER
root
# whoami
root
# su spot
$ busybox logname
spot
$

In https://askubuntu.com/questions/490620/ ... nd-logname

The utility logname is broken in 16.04, apparently on purpose ...

Good find williams2. So edit (using geany) /usr/local/bin/wiakwifi and change (line 3) `logname` to `busybox logname` and user logname report will be correct.

Similar link I read that also included bugs link:
https://askubuntu.com/questions/424237/ ... -terminals
echo $USER also worked in this case but maybe depends on the distro.

[wiak]

For anyone wanting to punish themselves via autologin as normal user (currently weedog user; I believe rockedge planning spot user), here is how to do it even as things stand:

geany /etc/sv/getty-autologin-tty1/conf

and change line:

Code: Select all

		GETTY_ARGS="--autologin root --noclear"
to:
		GETTY_ARGS="--autologin weedog --noclear"

and save that file.

Then from Start Menu (i.e. 'Applications'), choose 'Logout' followed by pressing Logout button. That takes you out of X to a terminal. Then simply enter command:

Code: Select all

exit

and system will autologin as user weedog.

Change back to autologin as root user in a similar manner. There are ways of scripting this of course and making the switch more user-friendly...
Some apps basically prefer you to be logged in as normal user, even if most forum users prefer not to be.

If you happen to be logged in as any normal user (such as weedog or spot), my method of doing admin work is:

open a terminal

and enter command:

Code: Select all

sudo thunar

and anything done from that terminal is as user root so no difficulties most of the time saving and so on anywhere.

Of course there are other ways to do similar and no one is forcing anyone to autologin as a normal user... Nowadays, I myself usually do though.

Main issue is that when running a browser as a normal user (which works nicely with chrome or chromium, for example, of course) you will be restricted (permission-wise) as to where you can download files found whilst browsing. I normally make special directories outside the upper_changes area that I give normal user ownership and permission to so that I can always save to them... For example:

Code: Select all

chown -R weedog:weedog /mnt/sda2/my_folder

-R being for 'recursive' in case my_folder also contains subdirectories at that stage. Command means that both the group and the owner of my_folder becomes weedog (no matter if it was all owned by root before).

Okay, so none of this 'nonsense' required at all when using autologin as root...

[wiak]

I haven't come across any issue with the xfce4 screensaver on my machine yet rockedge.

From terminal, I played around with xfce4-screensaver-preferences

I 'think' I am using alpha3, but I can't find fredx181 sfs-load anywhere. Where is it? Main thing to check set up off, when it comes to things like that, is right-click in filemanager operation for ease of use I'd say.

[wiak]

This is the first alpha release of Puppy community build of Puppy Linux.

This is not correct info rockedge. As you know, this is a forum distro, which you have already named as being 'Kennel Linux'. It is certainly not 'Puppy Linux', which is a creation of woof-CE. I am surprised you would call it that. I think it is important never to mislead anyone about what KLV-airedale is or is not or confusion will definitely arise. No big deal otherwise.

[fredx181]

@rockedge

I quickly tested alpha3 and boots and runs fine, I like XFCE, but I can imagine other people will prefer JWM or Openbox as it's much lighter of course.

Re: Sfs-Load:
The scripts you included need to be changed a bit (was made specially for DebianDog);
Attached: sfs-load.tar.gz, changes:
- Removed checking for "dpkg-new" files (as Void doesn't use these)
- Changed some yad dialog commands to support yad gtk3 (buttons should now display properly)
- Changed path to mount the SFS to /mnt/layers/SFS/
- Renamed rmbrokenlinks.sh in /etc/profile.d/ to 00rmbrokenlinks.sh as it didn't work when named rmbrokenlinks.sh (not sure why, perhaps because it ran after autologin.sh)
- Removed warning dialog when loading .sfs

Note: One of the most important things with this mechanism of creating symlinks is that there should be NO leftover symlinks when you forget to unload an SFS before shutdown.
The 00rmbrokenlinks.sh script should remove the symlinks at boot, but I'd recommend also to run a similar code at shutdown (before unmounting devices) for more safety (for DebianDog I've added it to wmpoweroff and wmreboot).

As wiak said, it would be good to have right-click options load and unload sfs in Thunar (set in Thunar custom actions)

[mikewalsh]

Alpha4 with Ungoogled Chromium (96.0.4664.93) on board.
Applications>>Internet>>Ungoogled Chromium
600 megabytes, but browsers are not small these days.
https://mega.nz/file/pxsyFRBY#oaqrHo7sH ... 12eG3gVAyM

Checked in Qemu. Internet via wiakwifi. There is sound on Youtube. Everything seems to be opening up.

Of course, if you go to chrome://gpu/, then a lot is disabled. Can be enabled in chrome://flags/

Probably it will be necessary to add add-ons someday, such as GroupSpeedDial and adblock Origin. It is extremely inconvenient without them.

@Grey :-

See if this info helps with adding extensions to Ungoogled_Chromium. It's a bit of a pain - and somewhat long-winded! - but it does work:-

viewtopic.php?p=18966#p18966

Mike.

[wiak]

@rockedge

I quickly tested alpha3 and boots and runs fine, I like XFCE, but I can imagine other people will prefer JWM or Openbox as it's much lighter of course.

Re: Sfs-Load:
The scripts you included need to be changed a bit (was made specially for DebianDog);
Attached: sfs-load.tar.gz, changes:

This is a key ingredient for sure, in my opinion.

I also agree with the comment that XFCE is okay, but JWM or Openbox lighter. Perhaps I was indoctrinated by Openbox/tint2 DebianDogs, but in terms of lightness and features that is far and away my own preferred desktop variant.

I'm still not sure of my preference between pcmanfm and thunar (pretty similar in so many respects) - I prefer both to Rox aside from one thing: making symlinks. I just can't get my head round doing that in Thunar or in Pcmanfm (tending to thus resort to using ln -s from a terminal commandline).

I did use Rox-filer for years though, so realise how nice it is in terms of simplicity via the icons in its top menu bar, which is a very clever design. But the ability of thunar or pcmanfm to handle filesystem mounting makes them winning filemanagers for me (especially via gvfs plugins for the likes of MTP-based smartphone connection and so on).

Rox pinboard does have its merits over say pcmanfm desktop (though I use the latter often). However, options are a great thing - not sure what the state of Rox is, however, in terms of active development (none for years?) for the future (a lot changing fast with Wayland being adopted more). Certainly lots of different approaches - some being more integrated in practice and feel than others. I admit I do use terminal commands quite often, but it has to be a featureful terminal that can do copy and paste and so on with ease (no two-mouse-button push tricks...) - something like lxterminal (I hate urxvt style of terminal other than possibly for pop-up dialogues - I struggle copying/pasting anything with it...).

I also habitually install lxtask, which is nice and light.