EasyOS version 2.3.2, June 22, 2020

[lp-dolittle]

@ Barry
@ rufwoof

Unable to really specify the basically underlying problem, I became aware of a somewhat strange 'interference' between the main desktop and the containerised desktop in EasyOS that seems to relate to the left and right ALT-key (possibly also affecting sakura) when pressed in combination with the 1-, 2-, or 3-key.

When I enter the containerised desktop, leaving untouched the quick setup, and open sakura, the keyboard layout logically is set to 'us', and I'm required to adjust my choice (Swiss German) via the 'setxkbmap ch' command. However, now simultaneously pressing the right-alt key and the 2-key - what should result in '@' - makes the containerised desktop flip back to the main desktop. Pressing the 'right alt-2' combination outside sakura has the same effect

A similar situation results if you start EasyOS from the iso-CD, leave the quick setup untouched and change to the containerised desktop. Pressing now the right alt as well as the 2-key simultaneously, makes the containerised desktop flip back to the main desktop. Now, choosing screen 1 in the icon tray at the desktop bottom leads back to the containerised desktop, but sakura no longer works correctly. Characters no longer can be entered, and sakura only can be closed or killed (both options seem to have the same effect) via the icon at the bottom of the screen. Changing to the cli (ctrl-alt-F2) works, and entering 'root' (password woofwoof) leads to an Xorg Video Wizard window and an error message.

Are these reactions in fact intended?

kind regards

[scsijon]

@Ipdolittle

It seems to me your back in a us keymap, to check this could you>

In the containerized desktop press <shift> and <2> and see what you get, should be a <@> if a us keyboard is set.
In most us keyboard maps, the left and right alt keys are set to do the same function code, so an <alt> 2, whether left or right <alt> would do the same thing.
Maybe you also need to set the keyboard kemap in the container?
If so this, when you think about it would be a plus as you can work in a number of languages, each in their own container.
?On the other hand they may be hard coded in jwm, rox, or elsewhere.

@barryk

I wonder if we can use multiple keyboards with containers? Maybe having a setting to match a keyboard to a container.

That would be great for translation work as well where the auto-translation program does the rough 'grunt work' and they use their own knowledge to complete the changes.

Now, if we could also set for two monitors and keyboards, one of each tied to each container and thus language, I could see a revolution in the way translation is being done today, as it's basically an arcache process still, (almost) just using a computer instead of pen-and-paper to write with/on!

Something like, setting >
Monitor1, keyboard1, languageset1 = english
monitor2, keyboard2, languageset2 = swiss german (in this case)
Although doing this would change the other when changing the first, leading to some hillarious expressions, like dolphin in english is sea pig in kanji.

[rufwoof]

Unable to really specify the basically underlying problem, I became aware of a somewhat strange 'interference' between the main desktop and the containerised desktop in EasyOS that seems to relate to the left and right ALT-key (possibly also affecting sakura) when pressed in combination with the 1-, 2-, or 3-key.

Alt 1, 2 or 3 ...etc is jwm's command keycode to switch to that desktop (desktop 1 = alt 1, desktop 2 = alt 2 ..etc). Same as on all jwm based puppy's

I use the keyboard for control/navigation quite a lot (Puppy's/EasyOS are really more for predominately mouse users, ROX was based on RISC which is mostly dragging and dropping things around) and there are a number of such conflicts. For example in tmux I have F11 set to add a new tmux window, but if I'm running tmux in a sakura terminal window then sakura's F11 maximise window annoyingly takes precedence.

There's another quirky key combination issue if you use ctrl-shift-delete to clear your browser cache etc. (which I tend to do often i.e. after logging out of one site so that userid/passwords aren't left around for other sites to potentially grab via cross scripting) as after having used that the ctrl-shift combination in effect locks/unlocks toggles the container window (the container looks like a desktop, but really its just a full screened window), so when you come to alt-F6 out of the container ... nothing happens - not at least until you press the ctrl-shift combination to toggle the lock/unlock that restores the alt-F6 operation (EasyOS exit container).

EDIT : I resolved my tmux/sakura F11 key conflict by adjusting ~/.config/sakura/sakura.conf file to set fullscreen_key=F10 (instead of F11).

[lp-dolittle]

@ scsijon
@ rufwoof

Thank you for your feedback!

Rufwoof's explanations especially proved to be helpful, and I now can better understand the latent keyboard-layout issues.

After all, I'm still astonished that the left and the right ALT-key may evoke different reactions even if the pre-set us keyboard-layout is not changed in any way, neither in the main desktop nor in its containerised counterpart.

The sometimes appearing and sometimes missing icons in the applet-tray seem to be an additional source of confusion.

kind regards

[rufwoof]

@Barry.

Wondering about instead of the agro of acking agar whether instead you might chroot into /sys/init and where in that loop something like ...

X :3 vt1 &
DISPLAY=:3 galculator &
chvt 1

is run, but substituting galculator for any other window/gtk dialog/whatever i.e. the 'console' in effect switches over to displaying X with (in this case) galculator running. Store any values in /tmp/stored-values, then when you kill X :3 and exit chroot back into initrd cli those values are available within /easy_new/tmp/stored-values - which might be used to set initrd things up further before reinvoking the main system (X) again (ctrl-alt-f4).

???

[BarryK]

@Barry.

Wondering about instead of the agro of acking agar whether instead you might chroot into /sys/init and where in that loop something like ...

X :3 vt1 &
DISPLAY=:3 galculator &
chvt 1

is run, but substituting galculator for any other window/gtk dialog/whatever i.e. the 'console' in effect switches over to displaying X with (in this case) galculator running. Store any values in /tmp/stored-values, then when you kill X :3 and exit chroot back into initrd cli those values are available within /easy_new/tmp/stored-values - which might be used to set initrd things up further before reinvoking the main system (X) again (ctrl-alt-f4).

???

Yes, the "only" problem with using Agar is learning how to use it!

Yes, I did wonder about starting X temporarily. But, I want effectively instant startup, and without having actually tried it, I thought it might be too slow to startup.

Oh yeah, also, X would have to start without all the kernel modules loaded, so there wouldn't be the i915.ko kernel Intel kms module for example.

There are other possibilities of course, such as goingnuts' tinyX, that he has compiled statically, and I think also there is a statically-compiled gtkdialog for gtk1.

[technosaurus]

Yes, I did wonder about starting X temporarily. But, I want effectively instant startup, and without having actually tried it, I thought it might be too slow to startup.

Oh yeah, also, X would have to start without all the kernel modules loaded, so there wouldn't be the i915.ko kernel Intel kms module for example.

There are other possibilities of course, such as goingnuts' tinyX, that he has compiled statically, and I think also there is a statically-compiled gtkdialog for gtk1.

xvesa+jwm can start in less than half a second. I got it down to less than 0.2s but that was with a built-in initramfs and lz4hc compressed kernel, no modules and only enough built into the kernel for qemu network capabilities.
Gtkdialog1 is slightly different from current versions but should be easy to port.
On the other hand slitaz uses busybox httpd and cgi scripts for similar functionality. Scotman started a similar thread on this forum in Programming. That would allow using netsurf (forked version for framebuffer), dillo (in goingnuts' static gtk1 multicall binary) , midori or a standard browser depending on the context.
Another alternative is to port gtkdialog back to one of the earlier versions of gtk2 that worked on the framebuffer... probably 2.6.x since it has the least dependencies.

[rufwoof]

In the OpenBSD install process (cli based), the very first question is to enter a numerical number for your keyboard layout (shows a list). Numerics I believe are consistent across all keyboard types ??? My EasyOS install indicates /lib/keymaps to be 45KB in total size for all of the available keymaps (i.e. to unzip the appropriate choice and feed into loadkeys from within initrd). Thereafter password prompt/entry is using the correct keyboard layout.

Pretty much how EasyOS currently also does it. Other than a bit of bling what is the benefit of changing from that?

[BarryK]

Yes, I did wonder about starting X temporarily. But, I want effectively instant startup, and without having actually tried it, I thought it might be too slow to startup.

Oh yeah, also, X would have to start without all the kernel modules loaded, so there wouldn't be the i915.ko kernel Intel kms module for example.

There are other possibilities of course, such as goingnuts' tinyX, that he has compiled statically, and I think also there is a statically-compiled gtkdialog for gtk1.

xvesa+jwm can start in less than half a second. I got it down to less than 0.2s but that was with a built-in initramfs and lz4hc compressed kernel, no modules and only enough built into the kernel for qemu network capabilities.
Gtkdialog1 is slightly different from current versions but should be easy to port.
On the other hand slitaz uses busybox httpd and cgi scripts for similar functionality. Scotman started a similar thread on this forum in Programming. That would allow using netsurf (forked version for framebuffer), dillo (in goingnuts' static gtk1 multicall binary) , midori or a standard browser depending on the context.
Another alternative is to port gtkdialog back to one of the earlier versions of gtk2 that worked on the framebuffer... probably 2.6.x since it has the least dependencies.

Yes, I did recently look back at old versions of gtk2, 2.6.x was the last version supporting "linux-fb", after that, right until now, gtk2 supports "directfb".

I compiled directfb, with lots of patches from debian, and tried to configure it as small as possible, but it is still big and complicated.

Oh, yes, I also attempted to compile gtk 2.6.x with linux-fb, configured ok (warned that linux-fb not maintained and likely to fail to compile and fail to work), but compile failed, didn't bother to try and fix.

[BarryK]

double post

[BarryK]

In the OpenBSD install process (cli based), the very first question is to enter a numerical number for your keyboard layout (shows a list). Numerics I believe are consistent across all keyboard types ??? My EasyOS install indicates /lib/keymaps to be 45KB in total size for all of the available keymaps (i.e. to unzip the appropriate choice and feed into loadkeys from within initrd). Thereafter password prompt/entry is using the correct keyboard layout.

Pretty much how EasyOS currently also does it. Other than a bit of bling what is the benefit of changing from that?

Yeah, seems good enough. However, he linux console only supports latin-type characters, not Chinese, Hindi, etc.

One thing that does puzzle me, a bit of a lack in my understanding. If load the ru (Russion) console keyboard layout, and a Cyrillic font that supports ru characters, it makes no difference, you type "abcdef" keys and that is what displays.

In an Xterm however, type "abcdef" and you get the Russian characters.

I would like a GUI in the initrd that will not just show the ru text, but also the password entry box accept ru characters. Yeah and Chinese, etc., also.

Or, is that wanting too much? Do users in Russian have PCs that are able to enter English characters? Or, if they type those keys that we have labeled as "abcdef", also have English lettering on their keyboards?

[jamesbond]

Yeah, seems good enough. However, he linux console only supports latin-type characters, not Chinese, Hindi, etc.

For these you will need an input method. I guess that's why we have fbterm (among others). Without input method this isn't possible.

One thing that does puzzle me, a bit of a lack in my understanding. If load the ru (Russion) console keyboard layout, and a Cyrillic font that supports ru characters, it makes no difference, you type "abcdef" keys and that is what displays.

The secret is that there is a "switch key" that you need to press to switch between Latin and Russion layout (for example).

In a full environment (not initrd) you can do this in Linux console:

Code: Select all

loadkeys ru
setfont LatGrkCyr-8x16

Then press Ctrl-Shift to switch between Latin and Russian. E.g. Type "abcde", then press Ctrl-Shift, then let go, then type "abcde" and you will see Russion characters. Press Ctrl-Shift again and you're back to Latin. The "switch" key is different from layout to layout, if you're native uses of that layout you're probably supposed to know.

In principle this should work inside initrd too but in my own testing I can do the switching (Ctrl-Shift does work) but not the characters (they show up as question mark, but once I press Enter they do show up). I suppose either the busybox utilities I use for that purpose (loadkmap and setfont) don't do the job well, or the font/keymap I have in my initrd is too old.
EDIT: the culprit seems to be busybox ash.

I would like a GUI in the initrd that will not just show the ru text, but also the password entry box accept ru characters. Yeah and Chinese, etc., also.

Agar looks good, but I'm not sure of its input-method capability. gtk2 however does support various input methods ... not sure about gtk1, however.

[watchdog]

My first experience with EasyOs. I have successfully installed and made snapshot of 0.9.18. Using palemoon28 and sylpheed. Sylpheed-3.4.3-x86_64.pet:

https://drive.google.com/file/d/1AEKVxq ... sp=sharing

(from slackware 14.1). Installed Pavrecord for webcam and the racy container. Cups not working in the racy container: permissions problems writing to /var/spool/cups. I can use a self made precise container as explained at:

http://www.murga-linux.com/puppy/viewto ... 62#1018462

I have also solved the printer installation installing foomatic from fatdog64 800 for a brother laser printer.

Foomatic32:

https://drive.google.com/file/d/1YvYJu7 ... sp=sharing

Foomatic64:

https://drive.google.com/file/d/1J-3UPb ... sp=sharing

(install both). Thanks for this beautiful distro.

[rufwoof]

Booting EasyOS with qfix=nox and starting up tmux I can view pdf's fine (along with tmux I've also installed vlc and fbpdf2), but vlc wont display a video. vlc works fine if I exit tmux back to cli and run it from there, or even if I detach from tmux, run vlc and then tmux attach again afterwards.

I've attached a framebuffer grab after ctrl-c'ing out of vlc attempting to play a video within tmux. Anyone know of any trick or workaround to get vlc running ok within a tmux window?

[BarryK]

Agar looks good, but I'm not sure of its input-method capability. gtk2 however does support various input methods ... not sure about gtk1, however.

I am now using gtk2! Running on the full Xorg:

http://bkhome.org/news/201903/xorg-gui- ... nitrd.html

It remembers the locale/keyboard choices, and future bootups, pre-configures the easy.sfs layer in the initrd, so only the password-entry box has to be displayed.

Now, to test this on my older PCs...

[lp-dolittle]

@ Barry,

maybe, the following observation is of interest to you after your success in starting a Xorg GUI in initrd:

Running totally in RAM EasyOs 8.0.1 or Quirky Xerus64-8.6, I noticed some interesting differences, as for the keyboard layout settings.

(1) In EasyOS, keyboard layout settings via the setxkbmap command in 'Sakura' always need to be refreshed after every restart of the X sever.
In contrast, running Quirky Xerus64-8.6, the same settings mostly seem to survive X server restarts but not on every machine. Comparing the hardware-info of such laptops and pc's, I so far was not able to make out which hardware component might cause these different reactions

(2) When I plug in a usb-keyboard into laptops whose (internal) keyboard layout either needs or does not need a refresh after X server restarts, sakura responds equally to both input devices as long as the external keyboard is already attached during the setting.
The situation is different if I first set the wanted keyboard layout via setxkbmap and plug in the usb-keyboard, thereafter. On laptops whose keyboard layout settings need to be refreshed after X server restarts, I now have the option to toggle in characters which belong to different layouts (in my case 'Swiss German' according to the laptop keyboard or 'US American' according to the usb-keyboard) into one and the same sakura window!! On laptops whose keyboard layout survives X server restarts (running Quirky Xerus) the internal and the external keyboard commands always are responded equally by sakura even if the usb-keyboard is plugged in only after the specific setxkbmap command.

kind regards

[rufwoof]

Any chance of having lz4 support being added to the default EasyOS kernel? So a easy sfs compressed using lz4 is mountable.

I have my frugal HDD installed version using lzo level 1 compression (... sfs/easyos/oe/pyro/easy_1.0_amd64.sfs) and its real quick. lz4 can further improve upon that.

I've set it not to copy the easy sfs to ram on bootup as well, so starts up quicker. I prefer it that way as given a slower boot (easy sfs loaded into ram), faster first time run of programs, versus faster boot/slower first time run of a program (thereafter often stays cached so second time runs are comparable in speed to having had easy sfs copied to ram), the latter uses less ram in total as the former loads everything into ram whereas the latter only loads what is actually used (for instance why load gparted into ram if you don't do any disk partitioning/changes during a session ... wasteful).

[rufwoof]

Some weeks back, someone asked about EasyOS and cgroup's so that limits could be set for a Easy Container for swap, memory ...etc.

I've been toying around in EasyOS with cgroups and so far these are my notes/tests that I've run so far, with a few of adding cgroup controls into my own frugal EasyOS

Code: Select all

# Check if cgroups are active

ls /sys/fs/cgroup/

# If (likely) no return is seen, then cgroup needs to be created/mounted ...

# Prepare the cgroups
mount -t tmpfs none /sys/fs/cgroup
mkdir /sys/fs/cgroup/memory
mount -t cgroup none /sys/fs/cgroup/memory -o memory

# Make a new 'easy' cgroup
mkdir /sys/fs/cgroup/memory/easy

# now we should be able to ls /sys/fs/cgroup/memory/easy and see ....

ls /sys/fs/cgroup/memory/easy
blkio.io_merged
blkio.io_merged_recursive
blkio.io_queued
blkio.io_queued_recursive
blkio.io_service_bytes
blkio.io_service_bytes_recursive
blkio.io_serviced
blkio.io_serviced_recursive
blkio.io_service_time
blkio.io_service_time_recursive
blkio.io_wait_time
blkio.io_wait_time_recursive
blkio.leaf_weight
blkio.leaf_weight_device
blkio.reset_stats
blkio.sectors
blkio.sectors_recursive
blkio.time
blkio.time_recursive
blkio.weight
blkio.weight_device
cgroup.clone_children
cgroup.event_control
cgroup.procs
cgroup.sane_behavior
cpuacct.stat
cpuacct.usage
cpuacct.usage_all
cpuacct.usage_percpu
cpuacct.usage_percpu_sys
cpuacct.usage_percpu_user
cpuacct.usage_sys
cpuacct.usage_user
cpu.shares
devices.allow
devices.deny
devices.list
memory.failcnt
memory.force_empty
memory.kmem.failcnt
memory.kmem.limit_in_bytes
memory.kmem.max_usage_in_bytes
memory.kmem.slabinfo
memory.kmem.tcp.failcnt
memory.kmem.tcp.limit_in_bytes
memory.kmem.tcp.max_usage_in_bytes
memory.kmem.tcp.usage_in_bytes
memory.kmem.usage_in_bytes
memory.limit_in_bytes
memory.max_usage_in_bytes
memory.move_charge_at_immigrate
memory.oom_control
memory.pressure_level
memory.soft_limit_in_bytes
memory.stat
memory.swappiness
memory.usage_in_bytes
memory.use_hierarchy
notify_on_release
release_agent
tasks

# Set the amount of memory which tasks in the easy cgroup can use :
echo 100000000 > /sys/fs/cgroup/memory/easy/memory.limit_in_bytes
# and set the cgroup to also have swap turned off ... 
# See what currently is allocated swap

cat /sys/fs/cgroup/memory/easy/memory.swappiness
# mine returns 60

# and set it to zero
echo "0" > /sys/fs/cgroup/memory/easy/memory.swappiness
# ... or whatever limits/things you want to apply to the cgroup task(s)

# start a new shell, so we can later exit out of it 
sh

# Move the current (new) shell process into the easy cgroup
# so that all other processes started in this shell are automatically also
# moved into the easy cgroup:

echo $$ > /sys/fs/cgroup/memory/easy/tasks

### THIS IS WHERE WE WOULD START THE EASY CONTAINER I.E. 
### AS A MEMBER OF THE EASY CGROUP (THAT HAS WHATEVER
### LIMITS WE SET BEING APPLIED).

# and see what we're permitted for swap now
cat /sys/fs/cgroup/memory/easy/memory.swappiness
# should return 0

# We set a 100,000,000 byte memory limit above, so create a python script
# that eats memory (I called mine eat-mem) ...

f = open("/dev/urandom", "r")
data = ""

i=0
while True:
    data += f.read(10000000) # 10mb
    i += 1
    print "%dmb" % (i*10,)

# no need to make it executable as
# we run that with python ./eat-mem
# ... and you should see ...
10mb
20mb
30mb
40mb
50mb
60mb
70mb
80mb
Killed

# cgroups can’t be removed until every processes in the tasks file has exited or
# been reassigned to another group. 
# Exit the shell to exit the easy cgroup
exit

# now back at the original shell level
cat /sys/fs/cgroup/memory.swappiness
#should see 60 (or whatever swap was previously available
# also if you now run the eat-mem script, it should get a lot further
# (I ctrl-c'd out of it once it had clearly passed 100MB).

# DON'T rm -rf the /sys/fs/cgroup/memory/easy FOLDER
# ... just use rmdir instead.

Note that in the above I disabled swap, as otherwise even with a memory limit it could start using swap to appear to have access to more than 100MB of memory.

Of course, you can also set other things such as attaching the easy containers cgroup to a particular core(s)
cat /sys/fs/cgroup/cpuset/cpuset.cpus
0-3

cpuset.mems="0"
cpuset.cpus="0-1"

... etc

[rufwoof]

This is what my ec-chroot-easy now looks like (restricts easy container maximum memory to 500MB (approx), and disables the easy container access to swap

Code: Select all

#!/bin/sh

# if not already set up a easy cgroup then ...
TST=`mount | grep "/sys/fs/cgroup/memory"`
if [ -z "$TST" ]; then

	# enable cgroup's
	mount -t tmpfs none /sys/fs/cgroup
	mkdir /sys/fs/cgroup/memory
	mount -t cgroup none /sys/fs/cgroup/memory -o memory

	# create a easy cgroup
	mkdir /sys/fs/cgroup/memory/easy

	# limit memory and disable swap to easy cgroup
	echo 500000000 > /sys/fs/cgroup/memory/easy/memory.limit_in_bytes
	echo "0" > /sys/fs/cgroup/memory/easy/memory.swappiness

fi

# attach this pid to the easy cgroup before running the easy container
echo $$ > /sys/fs/cgroup/memory/easy/tasks
empty -f ec-chroot easy

Running a eat-mem script within the container now gets to 440MB shown, stalls for a bit, then shows 'Killed'. So now a runaway program or hack attempt inside the easy container doesn't lockup the main system.

EDIT: After some playing around and setting cgroup limits etc. I decided to leave the code in place (for reference), but commented out. The easy container all too easily became 'jerky' in actual use - most likely due to my (poor) choices of tweaks/settings, whilst the standard (commented out code) ... is just sweet/great, works (very) well.

[rufwoof]

I created a Debian bootstrap ... so minimal debian (cli). 120MB .gz filesize. Official Debian (main repo's only).

dir2sfs'd that folder to form a EasyPack (sfs), ensuring that the content was all in a sub-directory (otherwise when you load it, it fails (system crashes). Booting with that sfs loaded and I've set it so it appears as /debian-stretch.

Adding a Xephyr :1 (resizeable window) I'm chrooting into that using pflask and it works really well. I've added (Debian apt-get) xorg, mpv, firefox-esr and it all runs as well as the main Easy system, no lag apparent etc. ... at least when using cwm for the window manager (if I use jwm it does seem to conflict in some areas with the main EasyOS's jwm).

Currently I've set the chroot to have all capabilities. But I guess when I run firefox-esr within that I should first be dropping the chroot capability as part of firefox-esr invocation.

Great how EasyOS acts as a hypervisor - such as being able to drag/drop files to/from EasyOS into the debian chroot. I find that having the debian running on desktop 2 serves as a visual reminder of which OS your actually using. Also nice having access to fully patched up choices (run debians apt-get update;apt-get upgrade), along with the full debian repo.