KLA-OT2baseCE-1.0 released ( 720 MiB ) With package manager Gnome-packagekit

[Sofiya]

KLA-OT2baseCE-1.0 (720 MiB)
ISO:
https://archive.org/download/20230225_2 ... CE-1.0.iso
SHA1-MD5.txt:
https://drive.google.com/file/d/1DV7MoD ... share_link

You can also download the image from here, I think the download speed should be higher here.
ISO:
https://drive.google.com/file/d/1ct0-aC ... share_link

NEW: New FR initrd.gz version 7.0.1 rc1 released on March 09, 2023; Includes rolling update of Arch Linux packages dated March 11, 2023.

INCLUDES small but effective 'Eolie' Internet browser.
Regardng Internet browser.
I see no point in bloating a base iso with any large browser users may well not want.
Since fully-Arch-Linux-compatible KLA-OT2baseCE-1.0 comes with official and complete pacman package manager (think of it like Quickpet...).
To install Firefox or Chromium, you simply need to open a terminal and (assuming you logged in as user root) enter command:

Code: Select all

pacman -S firefox

Code: Select all

pacman -S chromium

QEMU :
qemu-system-x86_64 -enable-kvm -m 2G -vga std -smp 2 -device AC97 -cdrom /root/Downloads/KLA-OT2baseCE-1.0.iso

[geo_c]

Running KLA-OT2baseCE-1.0 now and posting from it.

This openbox/tint2 combination is a whole new experience. Certainly a snappy and nice looking system you put together here @Sofiya

I'll be playing with a lot in the upcoming weeks.

[fredx181]

Very nice, a light system with many options, thanks @Sofiya and of course thanks also to @wiak !
I may become an Arch Linux user because of this !

From quick testing, some things that can be improved IMO:
- The timezone setup from Menu > System does not work, found the 'wd_timezone' setup and works but not very user friendly (lots of scrolling needed to get to e.g. Europe)
(btw, the default timezone should be UTC , not 'Auckland' IMO)
- In Menu > Internet it shows 'Chromium' but doesn't launch it.
- Perhaps add a nice 'light theme' (probably @geo_c can help), only choice now is for dark themes, except 'Raleigh' which looks rather ugly IMHO.
- Could not find a GUI package manager, perhaps good to add it, not everyone knows how to handle 'pacman ...' from terminal.
EDIT: Oh, and 'sclock' shows correctly only if picom is enabled.

Keep up the good work

[Sofiya]

Very nice, a light system with many options, thanks @Sofiya and of course thanks also to @wiak !
I may become an Arch Linux user because of this !

From quick testing, some things that can be improved IMO:
- The timezone setup from Menu > System does not work, found the 'wd_timezone' setup and works but not very user friendly (lots of scrolling needed to get to e.g. Europe)
(btw, the default timezone should be UTC , not 'Auckland' IMO)
- In Menu > Internet it shows 'Chromium' but doesn't launch it.
- Perhaps add a nice 'light theme' (probably @geo_c can help), only choice now is for dark themes, except 'Raleigh' which looks rather ugly IMHO.
- Could not find a GUI package manager, perhaps good to add it, not everyone knows how to handle 'pacman ...' from terminal.
EDIT: Oh, and 'sclock' shows correctly only if picom is enabled.

-Keep up the good work

Taken into account !

Browsers are not installed, this privilege is left for the user

the default timezone is set like this in the build script.
-I usually set the time zone from the console :

Code: Select all

ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/localtime

or like that

Code: Select all

timedatectl set-timezone Europe/Moscow

-about the light theme, yes, you need to think, but so that it looks beautiful

[fredx181]

Very nice, a light system with many options, thanks @Sofiya and of course thanks also to @wiak !
I may become an Arch Linux user because of this !

From quick testing, some things that can be improved IMO:
- The timezone setup from Menu > System does not work, found the 'wd_timezone' setup and works but not very user friendly (lots of scrolling needed to get to e.g. Europe)
(btw, the default timezone should be UTC , not 'Auckland' IMO)
- In Menu > Internet it shows 'Chromium' but doesn't launch it.
- Perhaps add a nice 'light theme' (probably @geo_c can help), only choice now is for dark themes, except 'Raleigh' which looks rather ugly IMHO.
- Could not find a GUI package manager, perhaps good to add it, not everyone knows how to handle 'pacman ...' from terminal.
EDIT: Oh, and 'sclock' shows correctly only if picom is enabled.

-Keep up the good work

Browsers are not installed, this privilege is left for the user

the default timezone is set like this in the build script.
-I usually set the time zone from the console :

Code: Select all

ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/localtime

or like that

Code: Select all

timedatectl set-timezone Europe/Moscow

-about the light theme, yes, you need to think, but so that it looks beautiful

Well, for a part I was just thinking from the point of an average user (may get confused or worse).

[Sofiya]

[Sofiya]

- Could not find a GUI package manager, perhaps good to add it, not everyone knows how to handle 'pacman ...' from terminal.

Package manager installed - System > Package
and for updating packages - System > Package Updates

[wiak]

Using wd_timezone it only takes a couple of seconds scrolling using PgDn (as advised) from top to bottom of timezone list for this one time needed operation, no matter whose timezone it starts from. That is perfectly good enough for me.

For CE releases users are free and encouraged to submit as sophisticated GUI frontends to underlying commandline utilities as they wish. Alternatively they can use Arch Linux approach per Arch Wiki, which is to use commandlines that also expand understanding.

That other timezone mechanism ncursive comes by default from Arch. Yes, didn't work for me either, but haven't time to study it so left in base release for others to work out if they wish.

[fredx181]

Using wd_timezone it only takes a couple of seconds scrolling using PgDn (as advised) from top to bottom of timezone list for this one time needed operation, no matter whose timezone it starts from. That is perfectly good enough for me.

Tried also PgDn but it takes ages too, I guess my PgDn is slower than yours
Here's attached a modification of wd_timezone , using --list, easier IMHO.

wd_timezone.gz

Remove fake .gz and make executable

(843 Bytes) Downloaded 44 times

EDIT: Correction, I used the arrow down/up, indeed it's fast with pgdn and pgup on the right of my keyboard.

Screenshot from 2023-03-13 10-37-07.png (19.31 KiB) Viewed 1525 times

[wiak]

Using wd_timezone it only takes a couple of seconds scrolling using PgDn (as advised) from top to bottom of timezone list for this one time needed operation, no matter whose timezone it starts from. That is perfectly good enough for me.

Tried also PgDn but it takes ages too, I guess my PgDn is slower than yours
Here's attached a modification of wd_timezone , using --list, easier IMHO.
wd_timezone.gz
EDIT: Correction, I used the arrow down/up, indeed it's fast with pgdn and pgup on the right of my keyboard.
Screenshot from 2023-03-13 10-37-07.png

Yes PgUp and PgDn is fast, but not so intuitive that's for sure. Will check out your offering for next set of releases (but that will be a while since I have to stop computing now to get on with other matters I've been neglecting).
Sofiya has a nice automatic solution I encourage posted here for others to use soon.

[Sofiya]

Script to automatically set the time zone

put the script in: /etc/NetworkManager/dispatcher.d/09-timezone

Code: Select all

#!/bin/sh
## /etc/NetworkManager/dispatcher.d/09-timezone
## https://wiki.archlinux.org/title/System_time#Update_timezone_every_time_NetworkManager_connects_to_a_network

case "$2" in
    up)
        timedatectl set-timezone "$(curl --fail https://ipapi.co/timezone)"
    ;;
esac

[rockedge]

Script to automatically set the time zone

This was exactly what I was looking for! Trying to set the time of KLA on a QEMU machine........

[keniv]

I have just downloaded KLA-OT2baseCE-1.0 which took over an hour but md5 checksum was OK. Made a manual frugal install to an hdd sda2 partition formatted ext3 and booted with grub4dos. This boots up to a desktop, however, I have done nothing else as I am concerned about the content of the .iso. There are many files I do not recognise and I am not sure what they are for. They end in .sh. I can guess from their names what some might do but do not know why they held within the .iso. Is this perhaps an artifact Arch linux? I also see similar in the KLA-XFCEbase-1.1.iso. Am I expected to have per-knowledge of this version of linux before I try to use KLA-OT2baseCE-1.0. I decided to try it as it was reported that it was lite on resources but if KLA-OT2baseCE-1.0 is an "only for experts" OS then please let me know.

Regards,

Ken.

[fredx181]

This boots up to a desktop,

Can't really help with what the scripts in the ISO are for, but it boots up to a desktop, that's what's most important IMO (and is a flexible modern system).
Not for experts, but may need to explore a little about Arch Linux for full potential, I guess.

[Clarity]

Hello @keniv

I think you are high-lighting how this family of distros differ from the others in the forum and across the Linux world.

Yes, it is.

In this forum we have no less than 5 different architectures released within the scope of "Puppy Linux Discussion Forum". Each of them 'different' from the other, while some/each "borrows" app/programs/subsystems that are in each-other to build the desktop we use for launching in our use needs.

The foundational levels are the programs you reference which may/may-not have tweaks or names that are familiar with other individual programs as each distro developer takes steps they feel would be useful to them and helpful to others.

The implied beauty of all of this is that 'things' are open source if one is capable of reading these offerings,

But, I do agree, that this distro appears as a family which is different from other you see, just as FATDOG is different from DebianDOG which is different from Slacko which is different from Vanilla which is diffeent from EASY which is different.... ALL under the same forum umbrella.

I know you know this forum knowledge, and this KL family is yet just one of the breeds of PUPs, DOGs, and probably upcoming WOLFs/DINGOs/COYOTEs/etc to remain in the forum family.

@fredx181 in the post above is signaling that difference

Yes, it is different as it presents its view of what a GOOD Linux can/should be, yet it does maintain much familiarity with subsystems we've come to know in the Linux world as it attempts to make the family easy to use, simple to step into, and providing persistence we are customarily expecting.

[wiak]

if KLA-OT2baseCE-1.0 is an "only for experts" OS then please let me know.

It is slightly lighter on resources (probably - depends what is added to it) because it uses lighter desktop manager 'Openbox', but XFCE isn't too much heavier in reality.

It is a desktop distribution and thus great for any Linux user, including beginners.

However, like actually all forum distribution contributions, it contains lots of little utilities (often created by forum members) for the likes of system administration, opening up sfs and iso files and so on. As on all Linux distributions such utility often relies on underlying small commandline utilities. Some forum members, who are what might be called intermediate or expert scripters have written these GUI utility apps for anyone to use (even sometimes for beginners).

Most KL distros I release now contain a few dozen extra very small commandline utilities. Anyone can use these, or they can be ignored entirely, but intermediate and expert Linux users might find some of them useful (for example, tcpdump allows you to keep a detailed eye on the packets coming into and out of your system - saves an intermediate or expert user having to install huge GUI network analyser such as wireshark). Beginners probably find none of these tiny commandline utilities useful for them, but that is fine; there are hundreds of other such small commands on all linux distros, including those of KL, that beginners or even intermediate users don't know about and never use.

However, for expert users/developers, these kind of commandlines are food for creation of new utility apps that anyone can usefully use (beginners and so on) - the developer simply makes the commandline utility user friendly by writing a GUI frontend for it (usually using gtkdialog script or yad script); i.e. These distros also encourage developers and increase the hobby-developer attractiveness that is a key characteristic of all forum distros.

For people who only want to use the distro, that is fine too - the desktop environments used in KL are usually either XFCE or Openbox/tint2 capable and provides all the usual facilities for anyone to use. My wife prefers any of KLV, KLA or KLU distros to even nice-designed Zorin (which she currently has to use for business reasons) and she is not Linux-savvy at all, but likes the layout/design and some additional facilities KL distros provide (she hasn't a clue about any underlying utilities I also include - well, not till I sometimes provide a new GUI frontend for one or more of them...).

[geo_c]

There are many files I do not recognise and I am not sure what they are for. They end in .sh. I can guess from their names what some might do but do not know why they held within the .iso. Is this perhaps an artifact tinycore linux?
Ken.

I'm just guessing as to what your question might be about the scripts included on the top directory of the .iso. It seems maybe you are considering whether you need to manually run these scripts. The answer is NO, they are there for the system to build it's layers on bootup and they will be run automatically.

If that's not the nature of your question, disregard this response!

[wiak]

There are many files I do not recognise and I am not sure what they are for. They end in .sh. I can guess from their names what some might do but do not know why they held within the .iso. Is this perhaps an artifact tinycore linux?
Ken.

I'm just guessing as to what your question might be about the scripts included on the top directory of the .iso. It seems maybe you are considering whether you need to manually run these scripts. The answer is NO, they are there for the system to build it's layers on bootup and will they will be run automatically.

If that's not the nature of your question, disregard this response!

Oh I see - could be a question about the likes of build_firstrib_rootfs.sh and FRmake_*.sh scripts in top level of the iso (where the necessary components: vmlinuz and initrd and the various numbered sfs addons are).
Yes, I include the actual build scripts used to build the distro inside my published KL iso contributions, in the frugal install directory, as a convenience so that anyone wanting to develop the system further can do so without having to look elsewhere for the build system components. They are not loaded up at all by the running operating system - just there for potential developers should they later wish to use them.The FirstRib build scripts are also tiny in size (a few tens of kB) so take up no real space on the iso. They are also there as a convenience for myself since I build the underlying base distro and maintain it - othewise I have to login to my github resource to find the relevant versions of these scripts for whichever KL distro I'm rebuilding. Don't worry about them - unless you don't trust the distros I am providing! These scripts is how I build them afterall and they are opensource text files for all to see and freely use, as is the rest of the provided distro

Actually, it would be similar to a Puppy distribution release that also came with woof-CE included except that woof-CE is a big system (that would add a lot of bloat to an iso release) and not just a few simple easily modified build scripts like firstrib build system is.

[Clarity]

I agree with your above post as that is one of the feature of this family of distros which is a distinguishing item in what it delivers for user use.

As I agree, I would not reference WoofCE as some builder that encloses "Bloat" as I dont feel it an good reference in all of what WoofCE and GIT, together, does for developers and builders.

WoofCE IS different from how a distro is created versus how its done by WoofQ versus how it is done for KL versus FATDOG versus DebianDOG builder versus etc. Each of these builders are a technique as different as there are breeds.

I perceive your approach as excellent. I would assume in the future this will evolve, too whereby there will be a video published by some member on how to use this builder to replicate a current KL distro OR to build a new one. As well, the links to published information may be enclosed to be a guide to steer users to info or pathways for building. This of course would NOT be the same as is provided by the WoofCE team, but would be similar in functional information useful to anyone venturing into "KL land".

KL overall is proving to be excellent in its scope of services to the users.

Thanks for what you, and everyone, has done or is doing!

[wiak]

As I agree, I would not reference WoofCE as some builder that encloses "Bloat" as I dont feel it an good reference in all of what WoofCE and GIT, together, does for developers and builders.

I'm not saying woof-CE is particularly huge from an overall point of view (woof-CE downloaded is currently in the ten(s) of MiB range uncompressed - not sure myself of the exact size since I haven't downloaded it for years), but that's kind of large to include in the iso if someone is trying to make as small a downloadable iso as possible. But doesn't matter at all that the woof-CE build system used to build Puppy Linux isn't included in any Puppy Linux iso by default - it is easy enough to fetch that (or they can make builds online using Github Actions) if someone really wants to try using it.

All I was saying is that I can however easily include FirstRib build scripts, as a definite convenience, because they only take up around 62 KiB, which is irrelevant in terms of bloating the overall downloadable iso size. If that FirstRib build system was more than a few MB in size I wouldn't include any of it in the iso, because that would be bloat from the point of view of keeping the iso small... Since the FR build scripts are small and relatively simple, they are easy to read, understand, and modify for changed or added functionality by anyone with reasonable scripting/Linux admin skills; hence it being worthwhile to me including them in the iso by default.

Anyway, it is relatively simple and tiny at the same time. Why is FR build system so small you might wonder? Well, FirstRib is basically centred around its relatively small but flexible initrd design - the rest of the system on purpose utilizes not only the repos of upstream distros but also their official package managers. Hence all firstrib needs as a build component extra is a script (including plugin) that simply uses the official package manager to build the underlying root filesystem (plus some scripting skills, by the likes of @rockedge, or myself or whoever, to do any needed additional configuration work), which also has the advantage that the result is not only fully upstream distro compatible but therefore also full multi-user capable. We have the upstream distro designers to thank for that, not ourselves. It is a simple idea based on busybox + official package manager (specially for KLV case), but per the KL results is shown to work very well in practice.

Aside from now building a few such distros, the only main work I myself really do, is develop that FirstRib initrd (including making it support the likes of Ventoy); that work is a bit complex and I have to be careful any time I change any part of that code not to break any of the quite intricately connected w_changes, w_bootfrom UUID|LABEL blah blah blah, w_altNN, w_copy2ram, and so on, flexible functionality involved for different install type uses ..., which is why I sometimes resist making too many changes to it. What works, I feel for my sanity, is best overall left alone...!... but fortunately the inner-code design/arrangement makes it not overly difficult to add new functionality in a logical manner without any spaghetti code workaround hacks or I would have completely broken it long ago. Despite the extra functionality added over time, the FR initrd remains very small and probably not slowed down at all - I am more relieved about that than ever was confident about making the changes without destroying the whole thing... I consider the hand of luck (and brain-hurting concentration) somehow helped. I prefer now to sit back and just use it and have no internal desire to add more at present...

The biggest fun I personally have had was with 'weedogit', which effectively showed how useful the FR initrd ended up miraculously being. It was forum member @Duprate who first referred to it as a magic initrd (I appreciated his nice comments of course). For me, however, it is somewhat miraculous that it actually worked per my plans, hopes, and design - that maybe-lucky-fluke is the magic in it from my point of view. Some accuse me of 'boasting' (though why shouldn't I exactly?), and I'm called a 'tool' or 'nasty individual' or whatever, but actually I am not so much ever boasting but rather 'counting my blessings and good fortune' albeit in the least religious of ways... At this current 'end of the day' it 'works' and these KL distros are a continuing demonstration of that, so I enjoy the fruits of my own labour and the very much appreciated help of others that have contributed so much in overall distro design and production based on that FR initrd and the associated build scripts.

Git as a resource is a separate matter altogether of course. Nothing to do, per se, with woof-CE or FirstRib or whatever - just a useful version control system that any such project can use (and do).

[keniv]

@fredx181, @Clarity, @wiak ,@geo_c,
Thank you all for the very informative replies. I did not expect to trigger this level of response.

Oh I see - could be a question about the likes of build_firstrib_rootfs.sh and FRmake_*.sh scripts

Yes this is the main issue I was raising. I had a small idea of what they were but not what they might do and not whether there was some mechanism that caused them to be loaded at boot up. I have now said many times on this forum that I am a simple user of the OSs that are hosted here and have very little or perhaps no expertise. This tends to make me very wary of anything I haven't seen before particularly the files, folders etc found inside an .iso that I am going to attempt to install on my hdd and then boot. Now I know what they are for I think it is unlikely that I will make use of them. For the moment I have placed them in their own folder.

if KLA-OT2baseCE-1.0 is an "only for experts" OS then please let me know.

From what I've said above you may not be surprised to here that I am a user who prefers to use a GUI rather than the command line I expect that more use of the command line than I am used to will be require. All I've done so far is connected to the wifi and done some setting up manly of the included browser. I will probably switch to one of the portable browsers I already use. I do more this evening and see how I get on.

Regards,

Ken.

[wiak]

I will probably switch to one of the portable browsers I already use. I do more this evening and see how I get on.

I have no idea how or if such portables (that were designed I guess for Puppy Linux use) will work. Certainly such items could be made to work with any KL distro, and maybe that's already been done - I wouldn't know since I generally just install my browser (usually Chromium) via package manager.

Non-forum-made AppImages certainly work. I used to use Ferdium AppImage (which is basically Chromium underneath) in KLV and also WDL_Arch64 (the earlier version of KLA-OT2 really), so if there are any AppImages for browsers more generally, I think they work in pretty much any Linux distro. @Mikewalsh I guess knows which if not all of his designed-for-Puppy portables work in KLV though - I do remember him trying some in earlier KLV dev days. One issue might be the /usr/lib situation -> /lib is a symlink in the likes of Void Linux and Arch Linux and more recent Debians even I think, so older 'designed-for-Puppy-portable browsers' may run into problems with that.

[mikewalsh]

@wiak / @keniv :-

Most of the current release Chromium-clone 'portables' work without issue in KLV, AFAICT. The Menu entry scripts add/remove OK; the only thing you notice is the absence of screen 'flicker' which you get in Puppy when JWM restarts.

Also, some of them will appear under the 'Other' category (I always use the Whisker menu) rather than under Internet.....simply because I haven't yet got around to re-writing all the Menu add/remove scripts to detect for XFCE, but function they most certainly do. And I do like the ability with current XFCE for simply dragging an item from the Whisker menu directly onto the desktop. That's neat, and simplifies things no end.

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

The lib->/usr/lib sym-link thing appears to make no difference at all. They're quite happy with it. I can see the logic behind it - I understand the original layout was dictated by the restricted drive sizes of Dennis Ritchie's initial hardware, and having to spread his OS out across TWO drives - but because all the 'top-level' directories have been 'moved' into /usr via symlinks, it makes no odds to existing applications. They will still find everything they're looking for, and therefore run/work.....which at the end of the day, is all any of us really need.

Mike.

[keniv]

@mikewalsh,@wiak
I have PaleMoon_gtk2-portable64 running in KLV-Airedale rc3 and was hoping to use this or Firefox-portable64 in KLA-OT2baseCE. I have some of the Chromium-clone 'portables' but I don't use these so much but I could use one if I had to.

Ken.

[wiak]

On phone right now so can't check. I can't remember if kla-ot2 has gtk2 installed, though could be added anyway. I tend now to go for gtk3 app releases.

[keniv]

On phone right now so can't check. I can't remember if kla-ot2 has gtk2 installed, though could be added anyway. I tend now to go for gtk3 app releases.

Have tried PaleMoon_gtk2-portable64 and Firefox-portable64 and neither work. As far as Chromium-clone 'portables' are concerned Opera does work including "menu add".

Ken.

[Clarity]

... you may not be surprised to here that I am a user who prefers to use a GUI rather than the command line I expect that more use of the command line than I am used to will be require. All I've done so far is connected to the wifi and done some setting up manly of the included browser. I will probably switch to one of the portable browsers I already use. I do more this evening and see how I get on.

I think you are taking a practical approach and this distro could use any helpful ideas you can provide.

IMHO, this distro strives to make this THE Friendliest distro this forum has to offer that is attractive to BOTH users with little terminal skills AS WELL AS those who prefer friendly GUIs; namely a distro attractive and useful to all user types; experienced and new. ... again, IMHO.

Let this KL thread (and other KLs too) know your successes, future progress and ideas.

[keniv]

Script to automatically set the time zone

put the script in: /etc/NetworkManager/dispatcher.d/09-timezone

Code: Select all

#!/bin/sh
## /etc/NetworkManager/dispatcher.d/09-timezone
## https://wiki.archlinux.org/title/System_time#Update_timezone_every_time_NetworkManager_connects_to_a_network

case "$2" in
    up)
        timedatectl set-timezone "$(curl --fail https://ipapi.co/timezone)"
    ;;
esac

Have placed 09-timezone as described above. It has made no difference to correctly setting the time. Is this file supposed to be made executable? Have also set the time zone via Menu>Settings>TimeZone. Currently the date is a day out and the time is 8.30am. Time here is currently 8.30pm. Just 12 hours out! Also I cannot find a way to set the keyboard to a UK keyboard. Have downloaded the 1.1 .iso. download was much faster.

Ken.

[Sofiya]

Script to automatically set the time zone

put the script in: /etc/NetworkManager/dispatcher.d/09-timezone

Code: Select all

#!/bin/sh
## /etc/NetworkManager/dispatcher.d/09-timezone
## https://wiki.archlinux.org/title/System_time#Update_timezone_every_time_NetworkManager_connects_to_a_network

case "$2" in
    up)
        timedatectl set-timezone "$(curl --fail https://ipapi.co/timezone)"
    ;;
esac

Have placed 09-timezone as described above. It has made no difference to correctly setting the time. Is this file supposed to be made executable? Have also set the time zone via Menu>Settings>TimeZone. Currently the date is a day out and the time is 8.30am. Time here is currently 8.30pm. Just 12 hours out! Also I cannot find a way to set the keyboard to a UK keyboard. Have downloaded the 1.1 .iso. download was much faster.

Ken.

Have placed 09-timezone as described above. It has made no difference to correctly setting the time. Is this file supposed to be made executable?

yes the file needs to be made executable.

Also I cannot find a way to set the keyboard to a UK keyboard.

set the keyboard to your country
go to /root/.config/openbox/autostart

in 17 line where us,ru write down your gb .
toggle shift+ alt ___ restart required x

Code: Select all

# Set keyboard settings
setxkbmap -layout gb -variant -option grp:alt_shift_toggle,terminate:ctrl_alt_bksp &

option 2

Code: Select all

setxkbmap -model pc104 -layout gb -variant , -option grp:terminate:ctrl_alt_bksp &

restart x

[Clarity]

... the time zone

T... Trying to set the time of KLA on a QEMU machine. ...

I am not sure this is helpful, but I offer it: In QEMU, my stanza insures the VM has the same time as the host.

Code: Select all

qemu-system-x86_64 -enable-kvm -vga std -m 2G -smp 2 -device AC97 -net nic -net user -rtc base=localtime -name "KLV-Airedale-rc11 via QEMU" -cdrom KLV-Airedale-rc11.iso 

Is this helpful knowledge?