Whats up in Puppy World

[wanderer]

hi everyone

i note distrowatch has finally updated the screenshot on our page
they had previously updated the date

it took a while
but at least the basics are done

wanderer

[wiak]

Perhaps (and in my view) more interesting is contemplation on: "What should be up in Puppy World", which we might describe as a slim, efficient, versatile, and can be small distro, world. No longer has to be small, but certainly can be.

My view (and really has been since late 1990s) is that Puppy World future should stop holding itself back by endless focussing on the tradition old Puppy Linux distro, including an almost now irrelevant repeating concern about "sfs-load". Puppy World should lead the way in a focus on networked virtual machines. In that world, sfs-load is irrelevant because it is trivial to load a complete alternative Puppy World distro with easy add/delete pre-selection of whatever addon sfs layers wanted in any virtual machine setting.

Yes, a virtual machine requires RAM allocation, but what computer nowadays cannot afford sufficient resources in practice to run at least one virtual machine (or indeed a single sfs via a simple chroot, or some kind of AppImage, or sharable container technology)? Furthermore, storage needs for virtual machine instances can, in practice, be next to nothing via the use of KL multi-instances.

So you want a different desktop or set of active applications? Simply close down current virtual machine (if resources are limited) and start up a different one (for example from your set of multi-instances).

Of course, there may occasionally still be times you need all resources for one distro. On these rare occasions there remains nothing to stop you shutting down all virtual machine instances and if you need or wish to there is no problem ever rebooting solely into one multi- instance host distro (and still be able to boot additional virtual machine instances when you want).

All that technology is already available to us here, but so much useful dev work and documentation work to create management utilities to make that system a simple user-friendly and powerful joy to use. Distros in this Puppy World have special layer-based flexibility that makes them uniquely placed to be key components in that networked virtual machine oriented world. Consider the networked virtual machines themselves to be a higher layered system where each vm layer is a single Puppy World flexible distro built from sfs layers in multi-instance form. That future Puppy World future would by its definition involve all forum distros and hopefully help rid us of forum damaging narrow viewpoints based on past glories.

[Clarity]

@wiak offers excellent points of today's world. Further, VM allows individualized security features to match or exceed the host's security which launches the VM(s). ... And much more flexibility with varying virtual CPUs and other options.

In addition to the VMs, there is Distrobox, and docker which offers some similar ability to VMs for both distros as well as applications.

Lastly, a very overlooked ability in this forum is the ability to run an multimedia desktop access to a forum distro via XRDP using the RDP protocol. Reason this is important is that a typical forum PC can support multiple users simultaneously connected using the PC running the apps and services on that very PC. This means that a RDP client (aka Wins/MACs/Linux/Unix/etc) can connect and run on the XRDP host as if he/she was sitting at the PCs console. For decades RDP has been a better solution than VNC/SSH clients because one sees the desktop exactly the same as if they are at the console of the PC.

Our PCs today provide so much more ability than the "thinkings" of our past.

If we want new faces in the forum along with the current members, some of these 'new "thinking" tools' should be embraced to attract them to learn, join and stay.

For example, how many have noticed the many distros that have popped-up with Wayland-KDE in just the last month or 2. Its more than just something new, as the industry has been moving onto this Pipewire-Wayland bandwagon for quite some time. There is a demand and users are flocking to those distros to examine and embrace the benefits provided. This is NOT a request to the forum, but, if anyone(s) see an advantage its not out of the question. We cant/shouldn't use systemD init as an excuse to support past thinkings.

I DO KNOW that this community has developers who continue doing their best to move the needle forward where possible. This innovation on their part(s) will continue to amaze all of us.

[dimkr]

match or exceed the host's security which launches the VM(s).

Vulnerabilities like Zenbleed affect VMs and if the VM is not patched to mitigate them, the VM becomes an attack vector for the host (!!!) running the hypervisor. This statement is wrong. VMs can be bad for security, even if we ignore their impact on battery life, performance issues (like lack of GPU acceleration or only partial access to the host GPU) and annoyances like key grabbing.

(And I wouldn't recommend SMB, RDP and other old technologies from the Windows world that play a major role in many remote attacks)

Current Puppy development doesn't have any clear vision or roadmap, but IMO better support for VMs is ... meh, not important, especially if at the end of the day you want to build a distro that feels lightweight on actual hardware, has good battery life on old laptops with old batteries, utilizes the GPU whenever possible to reduce power consumption and utilize available computing power, etc'. Containers and "containerized" applications (Flatpak, etc') are super useful, though.

[wanderer]

hi all

as for the future direction of our distro

as a user
here is what i would like to see

1. can run totally from usb
save file can be put on usb

2. desktop separate from base file
as a sfs file or whatever
so you can choose your own desktop
this should be able to be opened and closed easily
so you can permanently customize your desktop
and keep it as an sfs file or whatever

3. can be added to by using self contained apps
like sfs files flatpaks appimages etc
so you can add and remove the entire application easily

4. small selection of basic apps
kept in a local repository
as sfs files or whatever
that have been tested so we know they work

anything else ?

the build system doesn't matter to the user
but to attract developers
i think it should be a single bash script like debiandog
and seems like it would a good idea to base it on debian so we have their support

wanderer

[wiak]

2. desktop separate from base file
as a sfs file or whatever
so you can choose your own desktop
this should be able to be opened and closed easily
so you can permanently customize your desktop
and keep it as an sfs file or whatever

Whilst it is reasonably trivial matter at least in KL/FR distros to create addon sfs of anything there is major problem of making sure package manager database isn't broken. Read-only sfs addons will use fixed versions of packages, which generally need to be hidden (not recorded) from package manager. If the sfs was allowed to contain relevant overlay to package manager database, when you swapped in different desktop sfs you would break the database and thus package management (since different database would have different database information in it). If you chose to remove package manager database overlay altogether from each desktop manager sfs, but upgrading components in the main system, dependencies for the desktop manager components would likely all get messed up in terms of versions required. Probablly you could nevertheless build such a system if you made the addon desktop sfs lower than main root filesystem so the older binaries in the sfs did not overlay on top of main system (so upgrades to main system would still work), but I expect the old sfs would eventually not function correctly with main root filesystem newer libs.

But even if we found the system kept working reasonably well, it is a good idea to upgrade most all parts of the system every so often, which would require re-building the desktop sfs files every so often, which seems painful rather than useful to me.

[geo_c]

But even if we found the system kept working reasonably well, it is a good idea to upgrade most all parts of the system every so often, which would require re-building the desktop sfs files every so often, which seems painful rather than useful to me.

Seems to me this could be achieved using the KL-multi-install technique. Each instance could have it's own 08 desktop layer over the 07rootfs and of course underneath upper_changes, so the package manager could update desktop components without breaking the database.

Not saying it wouldn't eventually need a rebuild, but the shelf life would be appear to be longer, since each instance would have it's own distinct 08 layer and wouldn't interfere with updates in the in each unique set of upper_changes.

[wiak]

But even if we found the system kept working reasonably well, it is a good idea to upgrade most all parts of the system every so often, which would require re-building the desktop sfs files every so often, which seems painful rather than useful to me.

Seems to me this could be achieved using the KL-multi-install technique. Each instance could have it's own 08 desktop layer over the 07rootfs and of course underneath upper_changes, so the package manager could update desktop components without breaking the database.

Not saying it wouldn't eventually need a rebuild, but the shelf life would be appear to be longer, since each instance would have it's own distinct 08 layer and wouldn't interfere with updates in the in each unique set of upper_changes.

Yes, we should try that. The basic multi-instance structure costs next to nothing afterall (a couple of kilobytes storage per desired instance and no effect on cpu or RAM usage). Multi-instance makes dev experiments easy to undertake (can even boot different instances from Qemu I think - though I havent myself tried that, but want to sometime).

So yes, should maybe use firstrib plug to build simple commandline-only distro (or better simply including X or Wayland, the latter being more interesting now), and then add desktop in new boot pristine upper_changes and remove pkg manager database entries from that followed by making sfs of the result. Then continue making alternative desktp sfs from the pristine system. Can also or alternatively use uncompressed layer variants in KL/FR of course.

One of the design purposes of FirstRib was to make its build system and result particularly attractive for hobby dev experiment work. Since many hands make light work and basically produce nice design templates for others to use and modify, thats the main reason I wish for as many KL/FR users as possible. We all benefit from the work and ideas of others and KL distros are really convenient for such experiments (especially because of multi-instance and ability to also use uncompressed and thus editable addon layers).

[rockedge]

can even boot different instances from Qemu I think - though I haven't myself tried that, but want to sometime

It does work.

[Clarity]

@dimkr , I think VMs are excellent tools for developer-development. Affords them an environment for coding, compliations, evaluations, and operations of their work in either BIOS or UEFI virtual PCs of all types. Further, IIRC, QEMU v9 mitigates your concern beyond a development-test use.

And yes, containers like docker, distrobox, and others can be brought to bear, but the various CPU options do NOT compare to the PCs addressed by QEMU.

There a place and room for each of the options to assist developers, testers as well as assist distro-hoppers over and above a single desktop which requires a tear-down and reboot when one wants to evaluate other distros.

But YOU know this, too!

[dimkr]

@dimkr , I think VMs are excellent tools for developer-development.

I have no idea what "developer-development" means but testing something on QEMU doesn't guarantee it will boot with any BIOS or any UEFI system, and many things are simply impossible to test in a VM (like GPU accelerated video decoding) because a VM is ... a VM.

QEMU v9 mitigates your concern

What concern? How? A VM is a VM, no matter if it's running under QEMU or not, and no matter under what version. No QEMU version will mitigate CPU vulnerabilities, eliminate the overhead of virtualization or somehow make testing on a VM 100% equivalent to testing on bare metal.

And yes, containers like docker, distrobox, and others can be brought to bear, but the various CPU options do NOT compare to the PCs addressed by QEMU.

Are you aware of the fact that containers are not VMs and don't require virtualization? I don't understand what you're trying to say here.

There a place and room for each of the options to assist developers, testers

I disagree, it really depends on what you're trying to do, and it's easy to run into false conclusions if you don't use tools or methodologies in the right context. If you want to see if a distro boots in QEMU, then boot it inside QEMU. But if you're trying to check how a distro affects battery life or how responsive it feels, you can't do this with a VM.

[rockedge]

But if you're trying to check how a distro affects battery life or how responsive it feels, you can't do this with a VM.

I agree, that there is no substitute for booting and running a distro on bare metal. Virtual machines are great but there are differences that can not be overlooked.

[wiak]

But if you're trying to check how a distro affects battery life or how responsive it feels, you can't do this with a VM.

I agree, that there is no substitute for booting and running a distro on bare metal. Virtual machines are great but there are differences that can not be overlooked.

Yes, but we are also talking about user 'pleasure'; isn't it wonderful to just boot up a VM with a totally different distro and very little pain involved. Yes, containerised solutions avoid virtualisation, so a lot to be said to that as an alternative way of doing things, but VMs are simple for everyone to use and humans tend to go for the simple easy way to do things, but of course if we can provide containerised mechanisms that work better than VM mechanisms to achieve similar ends then that will be great and best of course.

[rcrsn51]

VMs are simple for everyone to use

So is ISObooter. And I get to see how the distro will work with a real-life bootloader, like the eventual end user.

[rockedge]

I use wd_multi a lot. I just set up 10 frugal installs in a QEMU HDD using it. When in danger of breaking the system often is in play, the virtual machines really streamline the process of figuring out how to achieve the goals and not worry at all about the system breakage.

So is ISObooter. And I get to see how the distro will work with a real-life bootloader, like the eventual end user.

Also super useful and a solid way of working in the same manner. ISObooter comes into use regularly for taking a good look if a system will boot and is any good.

Matter of fact, I think ISObooter should get more publicity.

[dimkr]

VMs are simple for everyone to use

Define 'use'. Even if you don't care about 'niche' use cases like gaming, many modern applications (especially those that use GTK+ 4) use Vulkan and some have graphical glitches or sluggish animations in VMs, browsers go 100% CPU in every web page with videos, ... the list of issues that can be found just by trying to use your VM for daily tasks for several minutes is long.

I believe nobody runs Puppy or a Puppy-like distro in a VM, uses it as a daily driver for a long time and has zero complaints.

IMO the various Puppy installers are horrible (even offer ext3 or f2fs without fsck) but the solution is to build a good installer, not to tell people they should use the distro inside a VM.

[wiak]

IMO the various Puppy installers are horrible (even offer ext3 or f2fs without fsck) but the solution is to build a good installer, not to tell people they should use the distro inside a VM.

To me, you come across as taking the whole hobby distro thing too seriously. I only do this kind of thing for fun, but some of the results surprise me. Certainly, VMs probably no use with gaming - not my thing so I wouldn't be thinking about that. If I'm using a distro to access bank accounts then I tend to think about all the updates/security issues, but more generally speaking I couldn't care less if I'm running as root user or playing around with old software. Nothing evil has happened to any computer usage I've had thus far, and in that hobby mode, I do nothing that I'd be worried to be temporarily hacked in anyway. Yes, it probably is true that some forum members use the likes of Puppy as their go to main distro, which is fine, but probably they do lots of stuff in the process that is potentially a bit dangerous, but how many reports of horrible stuff happening do we get on here - not much that I know of. You should lighten up. Life is too short to be too serious about what is just humans playing with machines - yeah but watch your bank account(s) if you have any money in them

[dimkr]

it probably is true that some forum members use the likes of Puppy as their go to main distro

I think that's a very good reason to take things seriously when I'm developing my distro, and avoid general statements about the security of VMs.

To each their own, but I'm having more fun building my distro when I solve performance and security issues, so this extra work benefits both the users and me

[wiak]

It may depend on different backgrounds. When I moved into academia as a career, teaching Linux, maintaining dual-booting on local worstations was a major headache for IT department. But vmware came along so in 1999 we told IT to just install vmware on the main image and we'd configure a Redhat Linux and run that under vmware. It was a fast LAN so we stored and loaded the image from a server. Most students probably didnt even know the Linux they booted into was actually a vmware VM. They are probably still using vmware for Redhat certification programs today, even though qemu could freely be used instead.

Aside from Linux cert programs I was mainly teaching data communications since TCP/IP and all that layered protocol junk was my research background. Only reason I knew enough to teach Linux waz cos the data comms internetworking research was on done on big university UNIX servers (mainly SUN microsystems). So I also later taught data comms primarily from UNIX/Linux perspective so mainly using networks of vmware machines plus networks of user mode linux instances. Maybe I still sometimes miss all that stuff. I did programming related to data comms protocols, but that was all low level in C. I actually only knew shell-scripting at a relatively basic level though did write quite a few awk-based programs because awk language was pretty useful filtering and processing some of the streaming data.

So, for me, single machine instances have always been a bit limiting/boring so I suppose it is natural for me to try and cater for multi-instances and try and boot several of these and get them to communicate with each other. Single-user systems also lack a lot in terms of ideas I like trying out. VMs are really handy for the client/server lab research type experiments I was in the habit of doing. No doubt desktop users sometimes/often couldn't care less about building networks of machines and getting them communicating with each other as efficiently as possible, despite delays and network noise, using rich multi-media higher level protocols. Network security is a big part of all that, more so than the security of each machine connected in that network.

[Clarity]

... I believe nobody runs Puppy or a Puppy-like distro in a VM, uses it as a daily driver for a long time and has zero complaints. ...

Wrong AGAIN, OH Great One!

I've used several over the course of 3 decades. In fact @fatdog distros have proven YOU wrong on this as I have found it to behave just a quick (if not quicker) and stable with ALL of its feature advantages with no issues...for YEARS.

Without going into other findings such as what I will see when moving a test from VM to bare-metal on the varied 64bit PCs I use for testing forum distro.

YOU may find fault, but for simple download and run solutions, this has great benefit to those who now and in the past have used it.

Your views seem to disregard much.

I may not be the developer you are, but I assure you I am ...

[rockedge]

I believe nobody runs Puppy or a Puppy-like distro in a VM, uses it as a daily driver for a long time and has zero complaints.

What?? I do and have with almost no complaints for a really long time. My main driver has QEMU which serves OS's throughout my house and with a handy VNC and some dynamic DNS aliases that allow me to use TigerVNC viewer over the Internet.....if I want too.

I compile packages on a QEMU F96-CE_4's

[Keef]

but I assure you I am ...

Anyone want to start a poll?

[darksun]

I sense a bit of grudge between few users here. This is bad IMO. I hope I am wrong but if I am not I wish this forum remains a place of tolerance, functional discussions and calm among gentlemen. Peace to all

[dimkr]

but I assure you I am ...

Anyone want to start a poll?

That's a good idea. If everybody is suddenly running Puppy only in VMs and not old computers, the few developers we have are wasting their time and can drop >100 MB of drivers and firmware

[geo_c]

I sense a bit of grudge between few users here. This is bad IMO. I hope I am wrong but if I am not I wish this forum remains a place of tolerance, functional discussions and calm among gentlemen. Peace to all

I don't sense that. Seems a pretty healthy, honest discussion at this point. I'm learning a lot.

[rockedge]

That's a good idea. If everybody is suddenly running Puppy only in VMs and not old computers,

You know as well as I do that "everybody is suddenly running Puppy only in VMs" is never going to happen. So what's with the negative vibes?

Running Puppy's in a VM is just a tiny bit of what happens here. Kind of feel like saying anything is like walking on very thin ice. I know that ice on rivers, lakes and ponds isn't a thing in some places in the world, but try to imagine it.

Poll is useless. How about looking at https://bwpup.puppylinux.com and if somebody could find time in their busy schedule, let me know where to go with this.

My goal is to finish and get such powerful Google search rankings for Bookwormpup going to this page that Google will be calling me.....basically I seek Global Domination.

[wanderer]

hi all

i am a user

and do not now and will never run my distro in vm

that is for developers not users

please continue making distros that will boot normally

thanks

[dimkr]

functional discussions

Don't confuse my writing style with my ideas, I'm not a native English speaker. I live in a culture known for its direct, anti-bs style and avoidance of discussions with 100% politeness and zero substance or actionable conclusions.

I know it sometimes (often?) comes across as condescending, contrarian or argumentative, but I'm only trying to push the discussion forward rather than what I see as slow drift sideways (VMs, modularity, ...).

[wanderer]

hi rockedge

your page looks beautiful as always
you have done a fantastic job

i think it should have on it

the 2 screenshots of

bookworm64 and
bookworm32

download links to the isos

a statement that they are our latest submission to distrowatch
(so distrowatch doesn't become confused)

a short blurb on what they are
i.e. a small fully functional flexibly deployed easily modifiable distro

anything else technical that anyone has the time and patience to add

and a link to the forum

and thanks for doing all of this

wanderer

[Keef]

I wasn't suggesting a poll about Puppy usage. More of a "guess the missing word".