Puppy Linux Discussion Forum

I find myself building isos less and less.

It is not that it is difficult to do so occasionally, but from perspective of hobby, learning/education, community help/collaboration, up-to-date and reliable installation, and even ease of reliable install, a build script release format is more convenient and certainly more powerful, simpler (for users and developers alike), yet more flexible.

An iso requires special restrictive handling, needing the likes of Ventoy or specially crafted boot loader configs with issues regarding guaranteed persistence capability. Alternatively you need to extract the contents, which become out-of-date immediately the iso is released...

A build script, on the other hand, can prepare an always most up-to-date release and can be arranged and provided to auto-config everything in a single but flexible step.

Most important is the inherent sharing of otherwise hidden-knowlege. Like open-source more generally, a build script shows in detail how the distro is constructed, which via that open-ness improves security and makes the release dynamic, flexible and alive and able to be manipulated, security checked, developed and improved.

Good riddance to old read-only isos, which are always out-of-date, or will be tomorrow, static dead storage-consuming old snap-shots. With a little build script release instead, I can at the push of an Enter key, re-install a brand new version with bug and security fixes and any modification, addition, or enhancement available or developed. A living distro release, transparent, visible, dynamic - not just an old archive that is already dead like all black-box-like isos.

There is nothing easier than running a single build script in terms of true convenience. An iso release, on the other hand, not only requires special, fundamentally restrictive handling, but is but a stale pre-packaged snapshot - a case of dead and soon rotting fruit whose contents are effectively unknown except to its creator. Really an iso is just another product handed out to a consumer public; aside from the complex insecure process of 'remastering' the already unknown contents, an iso is inevitably yet just another throw-away consumer product.

The likes of Ventoy is just a temporary, painful, hack arrangement that wrongly encourages prolonging the use of old, inconveniently static and dead, insecure old products. So much effort trying to keep what is already dead, alive!... Old archived isos are just museum pieces, but more often than not, most no longer of use or significance even for the most nostalgic. Unlike a piece of art, their archives, most of them, consume incredible space on all our systems world wide. A huge cost in the energy and resources required to continually produce and archive them away for posterity... clogging the storage space of future generations that will never want them. The consumer disease we call 'hoarding' - junk by any other name. Disposable Vapes.

wiak wrote: ↑Thu Sep 14, 2023 4:50 am

So much effort trying to keep what is already dead, alive!...

I understand your hobby-romantic attitude. However...

On the forum, the iso format has been "buried" several times in my memory. However, it continues to be used. For example, Arch just changed the internal structure and now it's not a CD inside, but a hard disk with MBR and other attributes.

And that's why this question still remains in the "this is my opinion" series.

Yes, of course iso can be usefully used. Ventoy is useful and not just for isos. But nevertheless I am fed up finding old isos on my system using up space, and it is the case that an already released iso is already dead in the water unless a rolling-release distro (but even then, with frugal installs, some aspects of upgrading via package management can be problematic).

As for all the ancient isos archived out there in the world - taking up space, consuming energy or do they somehow generate bitcoin???! After a few years of storage, what is the point? Look at some of our KL threads, KLV alpha, KLV alpha2, alpha3... beta1..beta1000000 (I exaggerate) - a thread for each and all - maybe an iso for each and all still archived out there somewhere. Just a build script please - it is tiny, efficient, easily upgraded. That's maybe my point. I forget.

I blame Ventoy, or was it SG2D? The demand for an iso. Why?

As for these Arch Linux iso constructions. Painful when all I want, unless making a full install, is to extract its root filesystem and FR initrd boot it as a frugal install. But that's easy enough I suppose. I'm just not an enthusiastic collector of old isos.

A few questions to understand.

If doing an install by using a script, that goes out into the Internet to get what is needed, and then installing it.
Where is it all coming from?

How much use of a limited amount of monthly downloads does it take? Some people are limited on there Internet usage.

If install goes bad with the installed OS.
Do you have any backup copy, like an ISO is, to reuse, without having to download again from the Internet?

Any controls on what is updated?

Any control on keeping older versions of dependency stuff or having it added, if needed to run a specific program?

For sure if you update stuff too much, most of the useful Puppy specific programs are going to no longer run.
Those are not programs you want to no longer be able to use.
They are 50% of what Puppy is.

Even now, some Puppy specific programs have needed to be code updated, to work in very new Puppy versions or the Puppy version needs to have older dependency stuff, to support them.

A life-time ago I worked in the home office of a major department calculating 'opens to buy' in Boysware for 55 stores. Most of my time was spent solving quadratic equations. I received a print-out of the sales for the last 8 weeks, the last 8 weeks of the previous year and the next 8 weeks of the previous year: Calculate the estimated sales for the next 8 week of this year. About two weeks into the job --when it became sufficiently routine that I had time to think-- I realized an important fact I didn't pass on to my boss: my job existed because 'the left hand' didn't realize what the 'right hand was capable of doing'. Merchants didn't know what a computer was capable of doing; programmers didn't know what product the merchants needed.

Little has changed.

Personal computers are manufactured to run Windows. Microsoft has 80 +/- of the personal computing market. Linux on a personal computer is an 'after-market' product. It has to be obtained and installed. There are thousands of versions of Linux, roughly 30 someone owning a computer running Windows may take into consideration. That someone knows nothing about Linux and is accustomed to being 'spoon-fed' under Windows: download an exe or msi, click it. Terminal? -- that's the end of Life.

"Assembly Not Required".

Who is the 'market' for your product? Can your script be run under Windows? If not, you've spent a lot of time for the few people who --like ham-radio operators-- are themselves hobbyists and already familiar with Linux and won't think twice about using a terminal.

Things change. Google/Android changed the World we live in. The Smartphone/Tablet is now the instrument of choice for communication. What remains for PCs are those activities where voice or touching a screen are insufficient and keyboards and mice are needed: the creation or modification of various types of datafiles: text, graphic, video, sound and programming. But one principal, variously identified, remains constant as necessary to postpone termination: ease of use, personal efficiency and the path of least resistance.

It may be easier to personally deploy an operating system via a script than an ISO. But it's even easier to do nothing at all. Who is your market?

Puppys --in the broad sense of 'portable operating system'-- remain a viable means to fulfill the small niche of a 'co-existent' operating system for the computer a User already has. And the ISO remains the means by which that User can easily obtain that operating system: any operating system (s)he already has can easily burn an ISO to some media his/her computer can boot from.

The ISO can be abandoned as a vehicle for deploying operating systems. But only when some vehicle and the means to make use of it are easier for the uninitiated.

p.s. Here's an idea or two. With first-rib you've developed a great tool for deploying almost any Linux distro. Make it as easy for Windows Users as rufus. What you need (copyrighted) is:

(a) an easy way for a User to select the download link of Linux operating systems; maybe just cut & paste from a web-browser; already downloaded, or --as rufus does-- include some prefigured choices. The latter would require frequent updates.
(b) includes or automatically downloads an open-source boot-manager; grub2 or some other.
(c) formats a USB-Key creating the two or more partitions needed to hold the UEFI capable boot loader files and the deployed operating system.
(d) Writes the boot-loader to the boot partition and the operating system to another partition, substituting your intrd for that downloaded.
ALL WRITTEN TO RUN UNDER WINDOWS.
There's a lot of free information and tools to writing Windows programs.
Sell downloadable exes on line for $5.00. (100,000 x $5 = $500,000). Build in a reasonable expiration date.
Maybe get your kid involved. Just as android programmers are likely to be needed for the foreseeable future, so are Windows programmers.

I virtually never boot from an iso. Took a couple up north we when I traveled (always strip a laptop for transport -if stolen it's a lump of uninteresting old metal-) but used the tiny USB stick on my keychain to reinstall OS and apps up there. That said, the iso format (or its' successor?) is great for archiving. Especially when troubleshooting, it is great for quickly going back a version or two to compare operation. One click mount, copy the relevant files and boot. No internet connection -or cloud- required.

The ISO can be abandoned as a vehicle for deploying operating systems.

They are the transport and landing craft for moving operating systems around. ISO is easy to mount and copy from. NO NETWORK REQUIRED to install a frugal system if one uses portable storage, USB Flash or SSD to carry a couple of OS's around. I know I do, take a Puppy and KLV along on a USB stick stashed in my car just in case

It is convenient to test if a distro I build actually works by starting it in a Virtual Machine from ISO without having to repeatedly reboot a real metal machine. I do this often per hour as experimentation and development takes place. No time for constant reboot and avoiding all the wear and tear on a bare metal machine, shutting down and powering back up over and over again.

I have strong reasons to use ISO.

net builds are nice if you have a decent internet connection.
single file (iso's) downloads can be managed by uget if you dont.

Although I can see good reasons for other methods, I use isos IF they are under CD size (700mb). Lots of poorer countries still use CDs, so I hope Puppy doesn't abandon them or become too big for them. pCompress is a good way to create useful hybrid isos.

Looks like I am near alone in preferring scripted builds, though I'm not surprised about that. Yes a pre-made img or iso build can be carried about and re-used without needing Internet connection - that is a given. A scripted build (depending on the script) doesn't actually always need to re-download 'everything', however, if everything has already changed to new/updated versions then it does of course (but then you get nice updated system...).

What I do remember is that during the many years I had moved to using DebianDog(s) I was delighted when @fredx181 finally one day produced a simple single scripted build rather than the usual manually hacked down iso or complex build system. In practice, I know it is much much easier for the distro builder to manually hack an existing system (add to a debootstrapped core build or hack down a bigger filesystem) than to work out all the intricacies needed to automate such matters in a script.

But the advantage of the script is profound: suddenly I could download a tiny script, read and understand it, and easily delete what I didn't want included or add what I did. The principal reason I advocate a script in comparison to an iso is that it is a case of:

Give a Man a Fish, and You Feed Him for a Day. Teach a Man To Fish, and You Feed Him for a Lifetime

Easy enough to locally produce an iso if I want to archive the result (just another simple script needed to do that). Perfectly possible to make a build script that stores a local repo of the packages used in the build (and even force it to re-use that archived mini-repo, but most of the time the point of running a build script for a second time is to fetch the latest and the greatest updated security-fixed build so the local stale/dead repo isn't particularly useful in that case.

There is no doubt I was inspired by DD's simple build script approach, but I also recognised that Void Linux offered an even simpler approach because it provided a statically compiled version of its package manager allowing me to use a simple 'busybox + package manager' build script approach which is how (and why) FirstRib distro building began as a project (the second script, for an automated FR initrd build, wasn't originally part of my plan but I became ambitious for an independent boot mechanism rather than just a chroot usable root filesystem). But debootstrap and similar remains also a useful upstream resource for Debian-style distro building rather than just using a pre-built iso so I employ that too.

@wiak Don't get me wrong, I really like scripted building and basically the ISO is for running tests in QEMU to see if a build boots and/or what happens if it does.

I have been refining the f_00_Void_KLV_XFCE_no-kernel_FRteam-rc7.plug to produce a KLV-Airedale rootfs that when finished, offers the same polish, tools and the utilities as KLV-Airedale-sr5 rootfs has. THe PLUG is close to a test release!

Would probably not be hard to have a wrapper script that assembles an entire KLV-Airedale ready for frugal installation that utilizes the PLUG as the other KL type OS build scripts can and do.

mikeslr wrote: ↑Thu Sep 14, 2023 3:10 pm

Can your script be run under Windows?

Interesting idea; could be done. Just need bash/shell plus some win utility to make Linux format filesystem, or even some script translation to use powershell or other scripting language windows can use. Cygwin would do though or provide small Linux virtual machine plus the build script (any kind of windows usable container).

I myself don't really write for any wide market or no doubt ease of use gui frontend would be offered. But that could always be added on anyway. Power starts with commandline. Separation from gui is key; then others can always implement their gui frontend of choice in whatever programming language and so on they prefer. To be frank, unlike those from the MS distro masses a simple script is more 'user friendly' for me than a gui usually. Depends on familiarity. I once attended a weekly course on MS admin and got fed up learning all the gui wizard's involved... mind-numbing. Powershell was amazing though albeit a huge learning curve.

Can your script be run under Windows?

use a Puppy Linux on a VMPlayer or similar virtual machine. There is some Windows meshing of Linux or keep it simple using Cygwin.

My choice if forced to use Windows is an OS something like, if not, Puppy Linux in a VMPlayer virtual machine to run the build scripts.

ozsouth wrote: ↑Thu Sep 14, 2023 11:06 pm

IF they are under CD size (700mb).

By the way, it's one thing to use ready-made images of optical discs. And it's quite another to mess with real ones I recently hardly found BD discs on sale in the city, ordinary single-layer 25 gigabytes (10 pieces in a pack). Only two options, Verbatim and VS. At an obscene price. And of course I'm not going to make images from them after recording - I'm crazy, but not violently crazy.

Give a Man a Fish, and You Feed Him for a Day. Teach a Man To Fish, and You Feed Him for a Lifetime

Very good, but still I'm glad that I can go to my local fish-store to buy a fish

Two words... hard copy. Here' a few more, extant software.

Considering the comparison... BOTH iso and script NEED A 2ND COPY off the machine to be effective. CD/DVD for the former, or both can have a 2nd electrical copy... but OFF THE TARGET 'PUTER. I see no disadvantage to an iso format. syslinux, grub_xyz, and other partitioning/setup scripts are still needed. Fancy a new bright shiny wrapper with a catchy name and lable it 'new and improved'.

"The rumors of my death have been greatly exagerated" --M. Twain

FWIW
8Geee

fredx181 wrote: ↑Fri Sep 15, 2023 4:31 pm

Give a Man a Fish, and You Feed Him for a Day. Teach a Man To Fish, and You Feed Him for a Lifetime

Very good, but still I'm glad that I can go to my local fish-store to buy a fish

And I was brought up as a slave for my father working on a 2 acre small-holding with primary charge looking after our 100 chickens (when I was eight year old) and digging the acre of potatoes out (with his help) and much more beside. Big meat eaters at that time, but then, at 19 year old I became vegetarian, and after soy milk improved, twenty years later I became vegan, which I remain (well... as a life-long biker I still kept my leather jacket and so on...). So please don't give me a fish or teach me how to fish ... as a child in Scotland I used be the local expert at guddling (fish tickling) anyway.

Just saw this.

I do understand what is in the opening post.

I wonder if the author has the same position of an ".img/.image" deliverable production of a distro.

I have always for 4 decades seen ISO/IMG as a mere deliverable. My view of a deliverable is different than the author shares. The ISO as a deliverable is well understood and so far has stood the test of time.

Recent decade has provided IMG as a deliverable. It too is well understood. In fact, Ventoy boots them, too.

What I believe the author intends, as I read between the lines, is a more favorable approach in using a builder vs the understood deliverables. And he sees his view of an approach as having advantages over the static builds contained within the commonly known deliverables of ISO/IMG. Again, I am trying to see the essence of his intent and I do agree that his approach offers an up to date ability that removes the developer's packaging of the known deliverables of ISO/IMG.

In todays Linus world, there are several methods to providing up-to-the-minute OSes that the author portrays. In Puppyland, one method is the one built-in to @666philb's FossaPUP64, also used by one/more other developers into their distros. This allows the user, at his discretion to add recent changes to the system, appropriately. There are also "running" updaters used in the Linux world which is similar in thought to what is done by MS and Apple (et. al. also) to keep a current system(s) secure and up-to-date.

Personally, I think ideas like this can be pursued to gather evidence and evaluate the culpability of the approach.

It would certainly gather understanding as it will allow answering questions which will arise to help development see all/most advantages and disadvantages that users will uncover.

As far as the industry is concern, if this proves valuable; like any other past implementations, new ones replace them.

In my case, I am old: Yet, for 3.5 decades, I have been a proponent for uses of the current packaging. I know how to use the ISO/IMG to 'flash' CDs, DVDs, HDDs, SSDs, SD/microSD/miniSD as well as how to run systems where drive space is ONLY needed for persistence by booting these ISO/IMG packagings. One other way, I have been a proponent for booting the ISO/IMG files that further does NOT require installation is to boot the PC via PXE. FATDOG and Lighthouse64 contained all the elements to setup a simple PXE environment for booting a PC over the LAN without the PC having boot media on either its drives or its devices. Recently, I have tested Ventoy's PXE implementation and it will allow a LAN attached PC to boot via its PXE, the @fatdog distros and some mainline Linux distros, as well. (I will report this ability to the forum at some date, soon).

Today, I, personally, am NOT in favor of any installation of any distro on any of my personal PCs in an effort to be productive. The information, to me that matters beyond the RAM operations of the static ISO/IMG is what I choose to be in my Persistence...where the ISO/IMG package merely serves to give me the operational RAM to use MY persistence and MY data. Therefore, my thoughts are NOT about ISO/IMG, it is about the tools (found in the persistence on the local media) and my data (of course, on local media). The ISO/IMG to RAM gives me a base for my data-tools usage.

To help, though, where possible, I will test and provide any feedback that I feel would be useful to development to support their causes.

P.S. I marvel at Google, Apple, Microsoft ability to upgrade from one RELEASE to another on millions of cell-phones, seamlessly.

Dont know if this constitutes a "Rolling Upgrade" or if it is some other Linux magic they have created. But, this could be one way of viewing what the author intends.

Just a hunch.

Clarity wrote: ↑Sun Sep 17, 2023 6:57 am

In my case, I am old:

Clarity wrote: ↑Sun Sep 17, 2023 6:57 am

on any of my personal PCs in an effort to be productive.

Hello. I can't understand in any way what you are doing there at such an age on so many computers and want to be productive. 3D graphics? Just wondering.

Clarity wrote: ↑Sun Sep 17, 2023 6:57 am

has stood the test of time.

Much like fossil fuel, fax machines and other things that need to go away to make room for better solutions

Clarity wrote: ↑Sun Sep 17, 2023 6:57 am

In todays Linus world,

The world doesn't belong to Linus Torvalds yet

I don't think the OP was particularly concerned with iso format, which being a format for delivering files is not significantly different from any zip type format, several files in one file. However, if the iso is intended for booting per se, I suppose that's different, and those who prefer to boot straight from iso rather than unpack the files and install to a particular location should probably also have the means to create an iso on their own. If they did have the means, then it wouldn't matter much what format the files were delivered, they could simply create the iso for themselves.

Still, I don't think that was the focus of the original post.

I think the OP was talking more about the idea of building from scripts making more sense in terms of delivering an up-to-date OS rather than one packed at a certain date by the developer. In running a build script all the downloads are more than likely the most recent packages available at the specified repository, and customizations by the user are more easily achieved.

Also, rather than the developer repacking the iso and publishing every time a change is made, a script approach allows for the developer to simply change the script and post the edited text.

At the rate OS's and applications are being updated these days, I think the idea has some merit. But it would necessarily limit the number of people cabable of using the OS to those who are both comfortable and capable of building from a script.

geo_c wrote: ↑Sun Sep 17, 2023 5:58 pm

However, if the iso is intended for booting per se, I suppose that's different, and those who prefer to boot straight from iso rather than unpack the files and install to a particular location should probably also have the means to create an iso on their own. If they did have the means, then it wouldn't matter much what format the files were delivered, they could simply create the iso for themselves.

Indeed, and as I said previously with same view:

wiak wrote: ↑Fri Sep 15, 2023 12:00 am

Easy enough to locally produce an iso if I want to archive the result (just another simple script needed to do that).

wiak wrote: ↑Mon Sep 18, 2023 12:47 am

Easy enough to locally produce an iso if I want to archive the result (just another simple script needed to do that).

Easy. But who sets the pace in this dance? A developer with his advice to write and run scripts or a user who requires everything ready-made and with a GUI? You use the word script a lot on this page (47 times, most of them are yours).
At the same time, the script is a creation system, and ISO is a storage format.

wiak wrote: ↑Fri Sep 15, 2023 2:08 am

then others can always implement their gui frontend of choice in whatever programming language and so on they prefer.

Who? In a topic nearby, the participants came to the conclusion that there are 2,5 developers. The rest want everything to be easy, fast and regular. Who if not you as the main ideologue?

In an ideal world, the idea would have been quite good and worked, I do not argue

Grey wrote: ↑Mon Sep 18, 2023 3:33 am

At the same time, the script is a creation system, and ISO is a storage format.

An easily modified or added to (tiny to download or re-download new versions) script that can however just be used as provided (so no user-work necessary apart from run the script which gives newest packages and then update grub)

versus

an already usually out-of-date iso stored archive version that either needs extracted, or, for example, moved to a specially made/prepared Ventoy disk, and then... have often ALL its packages updated/re-downloaded to become current, or quickly re-download the whole iso, re-do the extraction, and hope it is more recent than first attempt... And better check md5 or sha sums of the iso since unlike build system packages that check is not automatic for iso download either - more techy geeky work for the poor user...

Summary, just run the flipping single script with no techy geek work required. Even the 'script' can be provided with a frontend GUI (i.e. as a package) and include adding appropriate grub stanza and update-grub if developer chooses to provide it that way. BUT... with a script user can read it, understand, modify and enhance, if and only if they want to and have learned enough to do so - but that education enhancing process, which is inherently part of the mechanism is optional only; the installation method itself needs less technical ability, not more.

wiak wrote:

Looks like I am near alone in preferring scripted builds ...

In spite of what @dimkr says to me (which BTW doesn't offer ideas to @wiak excepting maybe to move on and leave the forum due to my age), I am NOT opposed to what you @wiak are presenting. I was, indeed, making the case that a packaging, no matter its form, is still a mere packaging. That can be those I mentioned, or mentioned by someone else as ZIP, or a file of some sort or even a folder that can be found by the booting PC.

@wiak is indicating an approach, to be done locally (I am assuming on the user's PC) which is similar to a cloud effort presented by SUSE over a decade ago that I have used to build an OS. Back then users could use the SUSE site to build a distro where its outputted package was an ISO, but it was my first where the user selected some off the shelf contents and its builder would build a running OS, downloadable to the user. Interesting. (not sure if they continued to offer that free service)

Similarly the closest thing to that I have seen in the forum is the user interface GUI that @fredx181 provides for DOG builders and is a very good one, indeed. An approach that seems somewhat similar to what you are considering for building on a local PC.

I dont think and hope that my comments are not in opposition; in my re-reading, I dont see opposition as an interpreted view.

wiak wrote: ↑Mon Sep 18, 2023 6:57 am

... or added to ... versus ...

Again, something in the forum by @peebee that is kinda similar is with the 'delta' he has used in the past few years that will upgrade the static with new packages and security.

Just another finding on the forum for getting the upgrades to a running distro.

@Grey's and others point is that many new and even seasoned users could/will exhibit a comfort in using package formats versus scripted approaches.

I feel @fredx181's approach more nearly matches your description and I believe many more would/could get their heads around using some GUI for script launches to create a running OS.

Just again things I have seen and used that might be in line to your direction for evaluation.

This post adds an experience I just had moments ago. My TV JUST UPDATED!

IN the case of browsers over the years, they can/will alert the user of available updates. My phones do so, my Chromebook does so, my TV does so...but, I have NOT seen a mechanism in Puppy LInux Forum distros that alert its users running a forum distro that an update is available.

Further, I have never used a rolling-release of any Linux and am unsure if those distros have mechanisms in place to upgrade/update the user by an announcement.

Curious