new KLU-jamXFCEbase 1.1 (620MiB) Ubuntu Jammy-based

[rcrsn51]

- at least for those in a situation where turning off secure boot is simply not an option).

The Starter Kit project has handled this situation since 2020.

[rockedge]

The Starter Kit project has handled this situation since 2020.

Just saying this is no help to me. Please guide me to this Starter Kit.

[wiak]

- at least for those in a situation where turning off secure boot is simply not an option).

The Starter Kit project has handled this situation since 2020.

Typical spam post. Same poster often provides links to non-existent resources or information that needs the attachments supposedly provided. Apparently the attachments often get removed because the poster gets into a huff because no-one posted a response quick enough.

I don't myself bother at all with such poor sources of information anymore since better to use reliable people than waste a lot of time and suffer disappointment when claimed contributions don't even exist. Result is a kind of unreliable forum pollution; there are many such link or attachments removed by that 'expert'. Plenty of others can provide same expertise actually, and without fuss or conditions. The ultra-long 'Starter Kit' threads are basically wasted since so many such 'holes' in their useful continuity. No dev 'team' can thus grow and develop there, which results in one-man band dictatorship situation that leaves its users uncertain of its likely maintainance and future continuity.

People less need individual 'experts' than they need reliable useful information and equally reliable contributions provided without conditions or required hoops to first jump through prior to being given the info or provision. And who has time or cares to read huge thread to finally find the claimed resource (which may or may not still exist)? Pity, but that is how that situation has become.

[rockedge]

for a guy so hung up on response time I am surprised I received no response from @rcrsn51 to my query. Leaves me to have to search for it.

I seem to remember having this conversation before about the nastiness and the removing of the links and packages.

Man I posted twice test results AS REQUESTED and no response. That was yesterday and the day before so we are talking hours and hours.......but only silence.

I can imagine if the shoe was on the other foot.

[mikeslr]

for a guy so hung up on response time I am surprised I received no response from @rcrsn51 to my query. Leaves me to have to search for it.

I seem to remember having this conversation before about the nastiness and the removing of the links and packages.

Man I posted twice test results AS REQUESTED and no response. That was yesterday and the day before so we are talking hours and hours.......but only silence.

I can imagine if the shoe was on the other foot.

Real life can be distracting. Even I sometimes forget to follow-up on conversations. And as far as I can tell, there's a not uncommon human-quirk that something clear in one's own mind is belived to be communicated to another by just the reference point enabling it to have been remembered*. Add that you've structured the Forum to make it easy to find the starter kit, viewtopic.php?t=644, once you know where it is don't be too put-off by rcrsn51's silence.

Some Like it Hot.png (223.43 KiB) Viewed 2064 times

Nobody's perfect.

-=-=-=-=
* PS. Working down from the top of the forum, I just ran across this conversation where the tables were turned as to who failed to provide references. viewtopic.php?p=132561#p132561. More important: Note to self. Hunt of 'Some Like it Hot' and watch it again.

[wiak]

for a guy so hung up on response time I am surprised I received no response from @rcrsn51 to my query. Leaves me to have to search for it.

I seem to remember having this conversation before about the nastiness and the removing of the links and packages.

Man I posted twice test results AS REQUESTED and no response. That was yesterday and the day before so we are talking hours and hours.......but only silence.

I can imagine if the shoe was on the other foot.

Real life can be distracting. Even I sometimes forget to follow-up on conversations.
...
* PS. Working down from the top of the forum, I just ran across this conversation where the tables were turned as to who failed to provide references. viewtopic.php?p=132561#p132561. More important: Note to self. Hunt of 'Some Like it Hot' and watch it again.

That's all very well, but the real issue, not only but particularly in that Starter Kit, is the oft done removal of contributions. Having clashes of personality and in-fighting happens at times, not that any of that has importance, but if even a few removed parts of what we contribute this forum as a useful resource to come visit would be destroyed. The guy has a lot of expertise and that is well acknowledged so pity to feel the need to hurt users as a weapon of control. Not worth dealing with that - better to buy Windows since all they look for is your money.

Do you remember rufwoof? Another who felt he had the right to control the behaviors and opinions of others. A big loss to this forum overall in terms of interesting ideas and technical descriptions (if not in terms of packaged working contributions). Okay, so didn't quite vanish since his own particular distro interest and needs forced him to somewhat reluctantly return to this forum. He also went to the in a huff trouble to delete many of his useful posts. What a daft dumb waste of time.

[wiak]

my life is a bit upside-down at the present @gabtech so the negative approach of some towards me gave me a good excuse, but of course I'll get back onto this eventually. Indeed it weighs on my mind that KL needs a newer Ubuntu-based release, which will I assure you appear sooner or later here since its lack feels like an unnecessary black hole in the KL universe.

It will hopefully not be long till I do this. It is just one distro release after all and the core commandline version is almost trivial to make as it happens.

So I'm doing a bit work on this at the moment.

Currently built a commandline only test KLU-Noble and trying different mksquashfs compressions on that. Results on main root filesystem are as follows, and won't be much different at all once I inherit and copy in the KL utilities from latest KLV-Airedale, which will be my next step prior to releasing a commandline-base KLU-Noble. The following includes NetworkManager (for connection via nmtui):

Main root-filesystem uncompressed normal directory size: 619 MiB

mksquashfs compressed using -comp xz -Xbcj x86 -b 1024k: 161 MiB

mksquashfs compressed using -comp zstd -Xcompression-level 19 -b 512K: 187 MiB

mksquashfs compressed using -comp zstd -Xcompression-level 19 -b 1024K: 183 MiB

I'll be using that last zstd with -b 1024K. Much more responsive than the small xz compressed version; albeit 14% larger in storage size it is relatively small anyway. Obviously the final iso will need kernel/modules/firmware and initrd added (I'll also be using same zstd compression with the firmware and modules). The firmware included tends to determine final size of the iso (once compression level decided); that and whatever the user chooses to provide for a GUI desktop - smallest would be a custom gui desktop rather than what upstream provides by default, but the likes of Sway with Wayland is pretty small addon anyway.

NOTE WELL that this is a pretty nice base commandline release with pretty full Ubuntu commandline utilities. Of course a lot of these could be stripped out, but why???! I really don't appreciate unnecessarily crippled releases.

I will be using a skeleton FR initrd so users can then easily swap in any Puppy-style huge kernel/modules combination that provides overlayfs support (aufs not needed, but not a problem if also compiled into the huge kernel, and the overlayfs can be provided either built in to the kernel or as a module).

I will thereafter include a quick install script for a GUI desktop (which can be supplemented by alternative desktops by distro extender using alternative addon script); I'll likely provide a test iso with one such desktop built in (useful I imagine for Clarity 'tests'). I 'could' provide that as addon desktop sfs files, but more generally it is usually better built into the main root filesystem iso release since then pseudo full install mode of the uncompressed main root filesystem allows easy remastering all in one chunk. Nevertheless, users interested in moulding the distro into a variant of their own choice will be better to start with the commandline-only base variant, put that into pseudo full install mode, and run a suitable desktop gui install script to create the final frugal install.

Release date? No idea at present sorry, but at least you know I am actively working on it... and I will endeavour to release the base commandline-only variant relatively soon since others may find that useful for their own addons

[Clarity]

... I really don't appreciate unnecessarily crippled releases. ...

Less developer work and chance for developer errs is reduced for the minimal benefit a cripple provides.

Time better spent in ability toward a stable platform for any user. Smarter users know how to cripple for their use and experienced user know how to change complete system operations for unique needs in a remaster.

The multiple desktop option idea, you propose is interesting approach. But you'll need a 'ncursive' console app for a desktop DE selection to run, OOTB, affording any user to choose one to continue to a chosen desktop, or, to operate in console only mode.

A good approach, no doubt.

[wiak]

Well, when I say it is not 'crippled', of course the base version is minimal and thus crippled to that extent, but the amount of 'crippling' is determined by Ubuntu minimal build rather than by myself. That way any 'official' Ubuntu minimal-rootfs upgrade will work as Ubuntu intended.

The base build is coming along well and easily because rather than trying to re-invent wheels I am borrowing from long-developed KLV-Airedale for the KL utilities components; that is helped A LOT by the fact that most of that is included in one location, which is /usr/local hierarchy, so I am simple copying that hierarchy from KLV_Airedale into a separate numbered addon (which I can use uncompressed during dev work, but will squash later once ready). Of course, there may well be components of that /usr/local hierarchy that should be removed for my purpose, but that can be determined during actual use and from forum user feedback - main thing is that KLV-Airedale dev work can help determine this overall KL-utils sfs if rockedge will keep in mind we can conveniently use his Airedale dev work for this more general KL utilities addon.

Of course not everything needed for KL utilities addon is including in that /usr/local hierarchy. For example, there are some binaries that have been placed under /usr/bin such as snapmerge puppy (though personally I'd prefer that also under /usr/local/bin. Also /usr/share/pixmaps and /usr/share/applications contain some parts that may need determined later via user use and feedback. The more KL specific sharable stuff that could be organized under /usr/local hierarchy the better though. One thing related:

I want to use a huge kernel type of construction alongside only skeleton latest FR initrd for this KLU_Noble build. Reason is that, like general Puppy builds, the use of a huge kernel arrangement makes it easy for users to swap different kernel/modules/firmware combinations to suit their own computers (old and new). I see that latest KLV-Airedale is not using a huge kernel; is that an official Void Linux kernel? @rockedge or whoever: Is there a suitable newish KL huge kernel/modules and good firmware set available that you'd recommend for first release of this KLU-Noble I am working on??

[rockedge]

@wiak I also think that the placement of KL utilities into a directory (squashed or not) is a good idea.

I always intended to move the snapmerge and the rest of the RAM2 mode components into /usr/local/bin because it is as @wiak noted, easy to use the same parts in other KL's with the components all in one place.

For now we'll keep KLV-Airedale going in it's current design to make borrowing from it easier. It is the secret on how fast a special purpose KLV can be constructed. KLV-vmHost was built rapidly by modifying an already existing PLUG file recipe for an almost KLV-Airedale and adding the the virtual machine packages. Then some manual polish and there it is...a working KLV for running virtual machines.

Is there a suitable newish KL huge kernel/modules and good firmware set available that you'd recommend for first release of this KLU-Noble I am working on??

I have been using either a huge full real time kernel self compiled with various firmware modules or a modular Void Linux kernel extracted and assembled like a Puppy Linux huge kernel. I feel like there is a lot of success using the huge Void Linux modular kernels.

Though a thought....what if we use the same tools as FirstRib/KLV that extracts the actual Void Linux kernel and creates the initrd.gz, 00modules and the vmlinuz but modified for doing the same using an Ubuntu kernel??

Code: Select all

FRmake_initrd.sh
FRmake_initrd_dep.sh
FRextract_kernel.sh

The 01firmware I am still trying out different ones from Puppy Linux or extracted manually from Void Linux firmware

[wiak]

Though a thought....what if we use the same tools as FirstRib/KLV that extracts the actual Void Linux kernel and creates the initrd.gz, 00modules and the vmlinuz but modified for doing the same using an Ubuntu kernel??

Code: Select all

FRmake_initrd.sh
FRmake_initrd_dep.sh
FRextract_kernel.sh

I forget the exact details, but the credit for the bulk of these scripts goes to Thomas M of Slax from which I copied the actual important and clever parts of the code. One small addition from similar Thomas M based scripts by fredx181 and a few really straightforward simple bits by me to extract kernel and create 00modules sfs along with splitting things up in a way that suited KL development process needs. As far as I remember the code is pretty much distro agnostic as you suggest so maybe straight away or with the tiniest of tweaks would work with Ubuntu/Debian releases.

Overall it is true that official upstream kernels seem to be the best in terms of reliably working on most hardware, and hence the importance of the above scripts, but on the other hand I think more of us notice kernel-sensitive problems getting systems to boot with newer computers - for that issue I kind of like using huge kernel/00modules/01firmware combinations along with bare skeleton FR initrd since it is SO SIMPLE to swap kernels over and often find a combination that boots successfully; so I almost prefer providing huge kernel type KL releases since users can then swap in different kernels so easily if they run into kernel-related issues.

Well... I suppose I am in two minds about which I prefer - huge kernel/modules/firmware plus skeleton FR initrd or official kernel plus FR initrd with inserted modules. What is really good is that we are able to provide either without much difficulty, and for people who actually build their own KL distros I do think official upstream distro kernels are best option in terms of reliability (and rigorous testing).

[rockedge]

I also like a lot the usage of huge kernels in KL with the skeleton initrd.gz. I found that the huge full real time kernels work really work well and when matched with the proper firmware module work and increase performance for certain tasks on a variety of computer models.

Which opens up the subject of creating reliable fdrv's and 01firmware SFS modules. So far I have had success from borrowing the fdrv's from the many different huge kernel packages. But always ready to try another method creating these firmware components. Experimented a bit with some scripts that filter the giant firmware directories into far more compact versions but finding the right formula that does the filtering..............

[wiak]

Experimented a bit with some scripts that filter the giant firmware directories into far more compact versions but finding the right formula that does the filtering..............

Yes, I haven't done much investigating firmware filtering since generally relied on the work of others building new kernels and so on, but would be very nice to be able to more reliably have means to reduce firmware since that is major factor in overall published iso. Yes, we can produce slim iso on the basis of slimmed down firmware, but then get lots of disappointed users since fails to boot on their particular hardware or various devices turn out not to operate properly - no easy solution to this other than multiple iso productions of isos produced for named set of particular computer models (aside from possibility of providing mechanisms for people to determine and create customised 01firmware on their own machines, but that isn't attractive proposition to most users who just want the iso to boot out of the box).

[geo_c]

[(aside from possibility of providing mechanisms for people to determine and create customised 01firmware on their own machines, but that isn't attractive proposition to most users who just want the iso to boot out of the box).

User created firmware would be cool, but maybe an easier approach is to have a standard EVERYTHING firmware/kernel, which will be big in size, but function on the most hardware, and then have an alternate stripped down firmware for those who are size conscious. Or, later adding a mechanism to trim down/build custom.

[rockedge]

@geo_c

we can construct one that is over 400 M from a Void Linux repo or borrow the one from the NoblePup64 ISO package which is 472 M in size but pretty sure it covers just about everything.

From NoblePup64 the fdrv_upup64n_24.04.sfs is usrmerge structured 472 M so I believe it will be easy to swap into Jammy and above.

It will work with KLV's so it should be okay in KLU-jamXFCEbase-1.1

[wiak]

There is no great answer possible to all this. Leave out some firmware and chances are someone's computer will have issues. Best attempt is publish with less firmware and rely on failure feedback to slowly fine tune firmware additions till 'most' computers work. Part of the issue is forum distros often competing to be as small as possible, which is a useful characteristic for some uses, but irrelevant pretty often.

[wiak]

I always intended to move the snapmerge and the rest of the RAM2 mode components into /usr/local/bin because it is as @wiak noted, easy to use the same parts in other KL's with the components all in one place.

Rightly or wrongly I tend to think of New Year as the natural new beginning of distro dev cycle despite it being a continuous process following a pretty much individual do-ocracy model.

It so happens, that almost a year later than I expected, I am likely to have my own time freed up again around then and thus more fully be able to focus again on some KL-related firstrib dev work/plans. Despite that individual do-ocracy somewhat anarchic dev process I hope we will overall see definite improvements in KL utilities integration and user-friendly polish and particulary like the idea of a KL utilities addon approach that becomes a central point for development and improvement. Creators of new KL distro variants will thus be freed up to concentrate on unique distro characteristics, knowing that the distro-agnostic KL-utilities addon, much like the distro-agnostic flexible and powerful FR initrd, can simply be bolted on (in truly optional compressed or uncompressed normal directory form; the latter being ideal for ease of editing).

And yes, we continue to want all of this to function as transparently as possible with the likes of Ventoy and other iso/img boot methodologies, and to improve virtual machine usage (e.g. QEMU) and related host/guest/network connectivity and communication mechanisms.

It isn't new year yet but time flies so I say this now to keep my own mind in focus in terms of planning for that soon to arrive future. By this time next year I envisage an incredibly solid and refined distro build methodology, which is clearly heading in that direction.

[houndstooth]

This is clearly not ready for users, but kudos for cutting out the bloat, & stability.

Only tested on a machine sans wi-fi, Ethernet does not connect automatically unlike Xubuntu (networking one of its strongest draws, it just works).

The way I booted it mounts even sans persistence, so default ram-only mode is gone. I've seen there is a way for ram-only with full Ubuntu for a mountain of memory:

Puppy technology seems like it could go RAM with any GNU setup.

SFS tool demands function translation. I literally had to remember I loaded an SFS to unmount the partition it was on, but it generally works.

No crashing & < 700MB = on target.