KLV-BspwmCE-1.5 Stable

[Sofiya]

Well, now I'm rolling. I put together a bash script to fully configure the customized CE-1.5, so now I have a plugfile that installs all the apps I need, and a script to run on first boot that fully configures my system.

At some point I'll figure out how to accomplish all of this in a plug file, so I don't have to use the extra step, though the extra step is probably the best way to access local settings.

Here's the custom local script:

Code: Select all

#!/bin/bash

## GEO CUSTOM LOCAL SETUP - BSPWM-RC5

## create /mnt/home
ln -s /mnt/sda1 /mnt/home

## autostart firewall
ln -s /etc/sv/ufw /var/service

## add desktop files
cp -av /mnt/home/sync-script/scriptLIB/applications/desktop-files-KLVb/*.* /usr/share/applications

## create directories
mkdir /root/my-applications/bin
mkdir /root/.cache/ranger
mkdir /root/.config/ranger
mkdir /root/.config/xfe
mkdir /root/.config/calcurse

## link config files
ln -s /mnt/home/portableAPP/LibreWolf-img/.librewolf /root/.librewolf
ln -s /mnt/home/tcons/xfe32-16 /root/.config/xfe/Xfe-icons
ln -s /mnt/home/dbox.sync.mir/app.sys/linxsys/SysT-DPi7/root-/.newsboat /root/.newsboat
ln -s /mnt/home/dbox.sync.mir/app.sys/linxsys/SysT-DPi7/root-/.calcurse/apts /root/.config/calcurse/apts
ln -s /mnt/home/dbox.sync.mir/app.sys/linxsys/SysT-DPi7/root-/Documents/MusesScore4 /root/Documents/MuseScore4

## copy config files
cp -arv /mnt/home/dbox.sync.mir/app.sys/linxsys/SysT-DPi7/root-/.calcurse/conf /root/.config/calcurse/conf
cp -arv /mnt/home/dbox.sync.mir/app.sys/linxsys/SysT-DPi7/root-/lynx_bookmarks.html /root/lynx_bookmarks.html 		
cp -arv /mnt/home/sync-script/scriptLIB/applications/my-applications-KLVb/classy-Bspwm-rc5 /root/Startup
cp -arv /mnt/home/KLV-bspwm-RT/fs-store/colors/xferc /root/.config/xfe
 # -cp -arv /mnt/home/KLV-airedale-RT/fs-store/colors/.Xresources /root

## copy utility scripts
cp -arv /mnt/home/sync-script/scriptLIB/applications/my-applications-KLVb/* /root/my-applications/bin
		
## install lv2 plugins
 # mkdir lv2 (already present in KLV-bspwm-rc5)		
cp -arv /mnt/home/dbox.sync.mir/app.sys/linxsys/SysT-DPi7/usr-lib/lv2/*.* /usr/lib/lv2
		
## config ranger file manager
cp -arv /usr/share/doc/ranger/config/*.* /root/.config/ranger
cp /mnt/home/KLV-bspwm-rc5/fs-store/ranger/*.* /root/.config/ranger
cat /mnt/sda1/KLV-bspwm-rc5/fs-store/ranger-bash_profile > /root/.bash_profile

@geo_c
Great job, everything is well written

[geo_c]

@geo_c
Great job, everything is well written

Thanks, except for that final cat command. The bash_profile in bspwm doesn't have anything in it out of the box, so this command is overwriting it with one that has a single line for ranger config. I really should be inserting this line into the bash_profile, so I should probably be using the sed command instead, in the case that there were existing lines in the bash_profile.

I'm curious to take a look at what you have set up with the terminals in rc5. I liked the big blue logo you had previously in v1.2, even though it took up a bit of real estate. Now you have these other color codings going which are really cool, like when you try to run a command on a file, but due to a typo that file doesn't actually exist, so the filename appears in red until it's corrected. That's a nice feature.

There are some instances when terminal turns the command dark blue, which on my monitors becomes difficult to make out.

Then I noticed you have the directory in root named "colors," but I haven't taken the time to explore what's going on there. All very interesting stuff indeed, and I don't think I would have the wherewithall to get any of that stuff working on my own.

[wiak]

@geo_c
Great job, everything is well written

Thanks, except for that final cat command. The bash_profile in bspwm doesn't have anything in it out of the box, so this command is overwriting it with one that has a single line for ranger config. I really should be inserting this line into the bash_profile, so I should probably be using the sed command instead, in the case that there were existing lines in the bash_profile.

Depends where you want the code to be. If you already had lines in your bash_profile you could have appended to the end of the file using >> instead of >, but I'm sure you know that.

Code: Select all

cat /mnt/sda1/KLV-bspwm-rc5/fs-store/ranger-bash_profile >> /root/.bash_profile

In terms of using your custom local script from main f_ build plugin whilst build it going on, you could simply rename it by putting the two characters f_ in front of its file name, for example: f_whatever, and then in the main f_ build plugin, at the very end of that file put the command:

Code: Select all

. ./tmp/f_whatever

That is simply bash way of including other files with commands in them (note there are two dots, one followed by a space then the next dot in ./f_whatever). The first dot stands for 'source'

Above will all work because all files beginning with characters f_ get copied during build into the being-constructed firstrib_rootfs to location tmp.

EDIT: Sorry, won't work since your local script is looking for things outside the chroot so you'd have to arrange things differently. The easiest is to take all you local stuff you want included (e.g. special files and directories) and made a tar archive of them and name that tar archive f_sometar and that will be auto-loaded into firstrib_rootfs/tmp during the build. You'd have to uncompress it via f_ main build plug command prior to using its contents of course. Obviously that procedure would mean re-writing your f_whatever local script since you need to copy from the new location in the untarred archive to wherever you want. Certainly a bit complicated that way.

[geo_c]

Depends where you want the code to be. If you already had lines in your bash_profile you could have appended to the end of the file using >> instead of >, but I'm sure you know that.

Code: Select all

cat /mnt/sda1/KLV-bspwm-rc5/fs-store/ranger-bash_profile >> /root/.bash_profile

Yeah, well, I would've eventually checked a reference, that's how sketchy my command line skills are. Your suggestion is helpful and exactly the command I was thinking of when I first used the cat command.

EDIT: Sorry, won't work since your local script is looking for things outside the chroot so you'd have to arrange things differently. The easiest is to take all you local stuff you want included (e.g. special files and directories) and made a tar archive of them and name that tar archive f_sometar and that will be auto-loaded into firstrib_rootfs/tmp during the build. You'd have to uncompress it via f_ main build plug command prior to using its contents of course. Obviously that procedure would mean re-writing your f_whatever local script since you need to copy from the new location in the untarred archive to wherever you want. Certainly a bit complicated that way.

That is the next step, EXCEPT, I have the annoying habit of sharing certain configs and data files, icons, etc among different OS's and different machines. So the linked files are shared with other KLV's and pups and when I make a change in one it appears in all the others. I sync the directories those links point to across my machines using rsync. I'm quite married to this technique. It allows me to go to work, run a handful of rsync scripts and be working with a mirror image of my home systems, without having to rely on "the cloud."

Now if I wanted to supply a script for a custom build for others to use, that wouldn't be the case and I could simply upload the config files and wget them in the plug.

I wouldn't claim to be able to offer anything as good as what the KL team puts out. However what I could eventually do that might be valuable is put together a FAT MEDIA version of a KL-CE build, that has a collection of music/audio/image/video and terminal based apps, with a clean menu to find them and a realtime kernel, cpu scaling scripts, etc. Something like that might prove useful to some people.

[geo_c]

@Sofiya I really like this Geany colorscheme called Cyber-sugar. It's very pleasing to the eyes.

I'm learning about how the desktop is configured. Applications choose specific workspaces, and I need to see how that's configured in bspwm.conf.
edit: I did look at the bspwm.conf, backed it up and then commented out the rules for applications. I like how the applications open in the workspace category most of the time, but it's more versatile for me to switch workspaces manually and open from there. Allows me more freedom.

I like the automatic workspace selection to a certain extent. I'm sure there's a key combination to move windows to different workspaces, haven't yet figured out how to work it from looking at sxhkd.

Also interesting that the when typing "exit" in a terminal the command prompt exits void-live and reverts to bash. I don't really know what that means, but I've been closing the window with super+w rather than using the exit command. Apparently this is a z something terminal.

Everything looks superb. Colors are vibrant and pleasant.

[williwaw]

@geo_c
since these are thing you may possibly want in multiple builds, and you are planning to do the linking multi thing anyways......

why not just boot with no upper_changes, such that a new empty upper_changes is created.

Create the directories and links to the config files (which will reside in a permanent read/write location such that they can be further edited if needed?), then save the dirs and links to upper_changes before you rename and squash.
just like you would if it were an app you wanted to link (or not) into a particular build.

[geo_c]

@geo_c
since these are thing you may possibly want in multiple builds, and you are planning to do the linking multi thing anyways......

why not just boot with no upper_changes, such that a new empty upper_changes is created.

Create the directories and links to the config files (which will reside in a permanent read/write location such that they can be further edited if needed?), then save the dirs and links to upper_changes before you rename and squash.
just like you would if it were an app you wanted to link (or not) into a particular build.

Actually, what you're suggesting is what I believe I'm doing with the above config script. I built a 07rootfs with a modified plug to include all needed applications, then booted it creating an upper_changes, then ran the above script creating links and configs, then shutdown and numbered that layer 20KLVb-rc5geo-local. Then squashed it. But I've really been liking running the layers unsquashed since they are SO FAST. A lot bigger in size, but very fast. I squash them anyway for archiving, but run them unsquashed.

So now I have:

00modules
01firmware
07KLV-bpswm-rc5geo_rootfs (the raw build, just rc5 +applications added to the plug)
20KLVb-rc5geo_local (containing all the local links, desktop files for launching portables, and configs)
21KLVb-rc5geo_hplip (layer with a small system update and hplip, and my printer added to cups)
upper_changes (planning simply to use as a working layer, may squash periodic backups of it)

[geo_c]

[wiak]

Then squashed it. But I've really been liking running the layers unsquashed since they are SO FAST. A lot bigger in size, but very fast. I squash them anyway for archiving, ...

00modules
01firmware
07KLV-bpswm-rc5geo_rootfs (the raw build, just rc5 +applications added to the plug)
20KLVb-rc5geo_local (containing all the local links, desktop files for launching portables, and configs)
21KLVb-rc5geo_hplip (layer with a small system update and hplip, and my printer added to cups)
upper_changes (planning simply to use as a working layer, may squash periodic backups of it)

Well, the good news is that whilst xz or gz compression usually results in slower system, the likes of zstd provides pretty good compression but using that the result is not necessarily slower, in fact it can be even more responsive than uncompressed. The reason why it can be faster on some machines is that the time for a not too old/slow CPU to decompress zstd is pretty fast (that's an advantage of zstd compression in fact). The problem on all machines is that Input/Output is relatively slow (I/O bottle-neck) so can take time to load in uncompressed files since they are so big. So net result is that the zstd compressed files can be loaded in faster, since much smaller, (from the I/O side of things) and the CPU doesn't take long doing the zstd decompression (but would have been too slow decompressing gz or xz).

So I suggest seeing how fast it all works after using mksquashfs but with following zstd compression. Won't be as small as xz compressed, but nothing like as large as uncompressed:

Code: Select all

mksquashfs whatever_dir/ whatever.sfs -comp zstd -Xcompression-level 19 -b 512K

Chances are, the end result will boot and run pretty fast usually. Might depend on age of the computer (CPU speed/IO speed) whether ends faster or slower than uncompressed when using fast-to-decompress zstd.

[Sofiya]

@geo_c
Great job, everything is well written

Thanks, except for that final cat command. The bash_profile in bspwm doesn't have anything in it out of the box, so this command is overwriting it with one that has a single line for ranger config. I really should be inserting this line into the bash_profile, so I should probably be using the sed command instead, in the case that there were existing lines in the bash_profile.

I'm curious to take a look at what you have set up with the terminals in rc5. I liked the big blue logo you had previously in v1.2, even though it took up a bit of real estate. Now you have these other color codings going which are really cool, like when you try to run a command on a file, but due to a typo that file doesn't actually exist, so the filename appears in red until it's corrected. That's a nice feature.

There are some instances when terminal turns the command dark blue, which on my monitors becomes difficult to make out.

Then I noticed you have the directory in root named "colors," but I haven't taken the time to explore what's going on there. All very interesting stuff indeed, and I don't think I would have the wherewithall to get any of that stuff working on my own.

Then I noticed you have the directory in root named "colors," but I haven't taken the time to explore what's going on there. All very interesting stuff indeed, and I don't think I would have the wherewithall to get any of that stuff working on my own.

This is for the window frame outline color .

I'm curious to take a look at what you have set up with the terminals in rc5. I liked the big blue logo you had previously in v1.2

the logo can be replaced with another theme if its size interferes by commenting out line 22 and uncommenting line 21 in /root/.zshrc, it will be like in my image.

[geo_c]

So I suggest seeing how fast it all works after using mksquashfs but with following zstd compression. Won't be as small as xz compressed, but nothing like as large as uncompressed:

Code: Select all

mksquashfs whatever_dir/ whatever.sfs -comp zstd -Xcompression-level 19 -b 512K

Chances are, the end result will boot and run pretty fast usually. Might depend on age of the computer (CPU speed/IO speed) whether ends faster or slower than uncompressed when using fast-to-decompress zstd.

Squashed Bspwm and Airedale using zstd and it's running pretty snappy!

[rockedge]

I been using PackIt to squash the different rootfs file systems lately. Does a nice job with zstd and one can vary the compression level. I use 1 M blocks.

Screenshot(17).jpg (45.83 KiB) Viewed 1266 times

[geo_c]

I been using PackIt to squash the different rootfs file systems lately. Does a nice job with zstd and one can vary the compression level. I use 1 M blocks.
Screenshot(17).jpg

Is the advantage of 1M blocks faster extraction?

[rockedge]

@geo_c the 1 M block gets the best compression ratio. We can try different block sizes and see what changes in size, decompression and later boot speeds

[wiak]

We can try different block sizes and see what changes in size, decompression and later boot speeds

Good to compare also with decompressed main rootfs; likely to depend on computer specs though since faster CPU is going to be fast decompressing (but likely also to be on machine with fast Input/output from storage). Overall, zstd makes sense nowadays despite slight size increase of iso.

[Clarity]

@rockedge ... The compression utility is rather comprehensive.

Might it be considered for inclusion as a feature of the KLs desktop builds across the board? Its not very big.

@wiak I have notice this "PROBLEM" with ALL RAM based distros for many-many years in the Linux environments. There is something 'odd' that did/does not exist in MS/Apple/Unix.

Never really pursued it as I always thought it was SO OBVIOUS that the Linux developers would have addressed it by now.

Back in the 1980s this was addressed in something called the Intersystems Coupler which bypassed the overhead of going thru the normal paths of the I/O subsystem used for devices, and instead would 'treat' RAM storage differently. This had an enormous resulting impact of increased application subsystems performance from milliseconds to microseconds. In some cases, the data came back so fast to some applications so fast they had to be retooled.

I do recognize that this community is NOT the designers of the Linux I/O subsystem, but often expected the 'problem' (if it can be called that) would have been addressed within the scope of the Linux architecture.

I have 3 different ways to setup a RAM disk. But never tested the performance diffs to determine which of the 3 is best way to setup a RAM disk where a timing could be compared. The 3 ramdisk methods are well known in the Linux world: Loop devices being 1 method of use.

I wonder if any have tested these for comparisons: (Maybe I will find time to do this and report...with all the other 'stupid' things I do from time to time.)

On paper, I am not so sure that "z" is actually, in practice, faster that direct access of uncompressed RAM data. If the I/O subsystem is doing something a bit different than is done for other I/O I could see a potential benefit to the CPU processes. It seems that moving I/O to a de/compression process (aka some compression application) to then turn around to move data from the process to, again, thru the CPU for application access does not, on paper, seem to provide a benefit over direct uncompressed application access from a RAM element.

I do agree, based on the reports seen over the past decade, zstd, is outstanding in performance comparison to other compression methods. And for compress, I do favor it, while recognizing that zip have gotten wide acceptance in OSes overall; and xz has become a staple in recent years of Linux.

Its just an observation I have, not knowing how the current I/O subsystem is structure for application access of compressed or uncompressed data use.

@geo_c your efforts have been noticed for how meticulous you have approach the things you have share to us in this community. THANKS!

And THANKS to everyone here.

P.S. @rockedge is the real-time best for latency or something else. In my past, it was there for signal processing vs general uses in a desktop. But there may have been some tests that shows a benefit: like with multiple audio sources in music productions for a single program. Just curious. (if desired, a PM on this kernel info might be a better place than this thread).

Edited: 5 paragrphs up in an attempt to be clearer on CPU behavior for application data request of data that must be decompressed vs direct use of uncompressed data.

[Sofiya]

Note:
Somewhere @geo_c was interested in how to move an open application to one place on the desktop because he didn’t like the fact that applications open in their own working windows. This is done simply, let’s say you have the application manager open on the 3rd workplace in order to transfer the remaining applications open in others to this place workplaces, do this, go to the place where the application that you want to move to the 3rd workplace is open, then press Super + Shift + 3, also with other applications open in other areas, go there and Super + Shift + 3. all applications will be in 3rd place

[geo_c]

Note:
Somewhere @geo_c was interested in how to move an open application to one place on the desktop because he didn’t like the fact that applications open in their own working windows. ... Super + Shift + 3. all applications will be in 3rd place

Yes, that's great! Works perfectly. I wasn't able to decipher the keystrokes from the shxkd file.

This is a really great system. I'll be running KLV-awesome soon also.

[Sofiya]

Privilege escalation using polkit:
to run applications such as gufw. to run gufw without ( pkexec -ssh )

in /root/Startup

Code: Select all

#!/bin/bash

exec /usr/lib/polkit-1/polkitd --no-debug 

[geo_c]

@Sofiya, quick question

How exactly are these terminals interacting?

I opened xterm, which seems to be really zshell, and I typed some nonsense characters to see what colors were coming out, because I had changed the basic background and foreground in Xresources, and kind of forgot the whole zshell thing. Then I typed ctrl-d to close the terminal, but I got a list of about 8 files beginning with the letter j, like json files.

I checked zhistory to see what my last command looked liked, but it wasn't what I typed (which was something like j;l;jk;jk) I never hit enter after typing the characters, just went straight to ctrl-d.

Zhistory showed this as my last command:

Code: Select all

1696563388:0;PS1='\u@\h:\w\$ '

I'm wondering if I mangled up something in the process.

[Sofiya]

@Sofiya, quick question

How exactly are these terminals interacting?

I opened xterm, which seems to be really zshell, and I typed some nonsense characters to see what colors were coming out, because I had changed the basic background and foreground in Xresources, and kind of forgot the whole zshell thing. Then I typed ctrl-d to close the terminal, but I got a list of about 8 files beginning with the letter j, like json files.

I checked zhistory to see what my last command looked liked, but it wasn't what I typed (which was something like j;l;jk;jk) I never hit enter after typing the characters, just went straight to ctrl-d.

Zhistory showed this as my last command:

Code: Select all

1696563388:0;PS1='\u@\h:\w\$ '

I'm wondering if I mangled up something in the process.

zshell is not installed by default

to enable zshell by default you need to run

Code: Select all

chsh -s /bin/zsh root
sed -i 's/zsh/# zsh/' /root/.bashrc 

log out and log in again

[geo_c]

I'm wondering if I mangled up something in the process.

zshell is not installed by default

to enable zshell by default you need to run

Code: Select all

chsh -s /bin/zsh root
sed -i 's/zsh/# zsh/' /root/.bashrc 

log out and log in again
[/quote]

Okay, that's a good start. I don't know anything about zshell. I'm not really seeking to use it.

What is /root/.zhistory then?

I've been using a combination of uxterm and lxterminal due to the fact that some of my terminal apps display better in uxterm. My commands in uxterm seem to be stored in .zhistory rather than .bash_history

I'm trying to understand the setup.

[geo_c]

On another topic, using pcmanfm I clicked on KLV-awesomeCE.iso and rather than mounting it somewhere, pcmanfm asked to extract the files, which I did.

I like that better than mounting when I'm looking to copy iso files to a drive!

[Sofiya]

I'm wondering if I mangled up something in the process.

zshell is not installed by default

to enable zshell by default you need to run

Code: Select all

chsh -s /bin/zsh root
sed -i 's/zsh/# zsh/' /root/.bashrc 

log out and log in again

Okay, that's a good start. I don't know anything about zshell. I'm not really seeking to use it.

What is /root/.zhistory then?

I've been using a combination of uxterm and lxterminal due to the fact that some of my terminal apps display better in uxterm. My commands in uxterm seem to be stored in .zhistory rather than .bash_history

I'm trying to understand the setup.
[/quote]

What is /root/.zhistory then?

This is where the commands you type in the terminal are saved

[geo_c]

What is /root/.zhistory then?

This is where the commands you type in the terminal are saved

So command history goes there instead of .bash_history.

The only reason I bring it up is because that's a different file than all my other OS's.

[Sofiya]

[geo_c]

I was just doing some updating to all my KL installs, and I noticed this while do a system update on Bspwm:

Code: Select all

WARNING: PAM>=1.5.0 has removed the pam_tally and pam_tally2 modules,
as well as the pam_lastlog module on musl. If you have a custom PAM
config, you will need to fix it immediately for these changes.

Otherwise, the pam-base-0.4 update will have handled these changes for
you, unless your XBPS config uses "keepconf=true",
"preserve=/etc/pam.d/system-login" or "preserve=/etc/pam.d/*".

It's probably harmless, unless KLV's use any of the above XBPS config parameters.

[geo_c]

@wiak, @rockedge, @Sofiya , and @williwaw

I was thinking about doing a build of KLV-Hyprland using @Sofiya's build script and modifying the plug, and so I read through this Bspwm thread to remember how to do it, and I just have to say this is a highly informative thread, a tutorial on chroot and building with firstrib, psuedo-full installs, filesystem compression methods and the likes.

Thanks for all the contributions.

[josejp2424]

very good work @Sofiya .