dpup OS 1 Rolling

[wiak]

This quota is for files stored in the repo, not releases.

This use of GitHub Actions is not "any other activity unrelated to the production, testing, deployment, or publication of the software project associated with the repository where GitHub Actions are used", and the "2,000 Actions minutes/month" quota of Actions should be enough for dpup OS (assuming every build is 2.5 hours, there are two builds a week, and every month is 4 weeks, 60*2.5*2*4 = 1200 minutes).

My understanding was that there was a quota for not only time (minutes) but also storage, but that's interesting if github users can produce (and therefore store) such large releases. I should try it. Not really how I read their terms and conditions to be honest and I believe more than just dpup OS has been provided for in new Puppy builds via such Github Actions:

https://docs.github.com/en/github/site- ... ions-usage

a. Actions Usage
GitHub Actions is billed on a usage basis. The Actions documentation includes details, including compute and storage quantities (depending on your Account plan), and how to monitor your Actions minutes usage and set usage limits.

Actions and any elements of the Actions service may not be used in violation of the Agreement, the GitHub Acceptable Use Polices, or the GitHub Actions service limitations set forth in the Actions documentation. Additionally, Actions should not be used for:
...
any activity that places a burden on our servers, where that burden is disproportionate to the benefits provided to users (for example, don't use Actions as a content delivery network or as part of a serverless application, but a low benefit Action could be ok if it’s also low burden); or any other activity unrelated to the production, testing, deployment, or publication of the software project associated with the repository where GitHub Actions are used.

About billing for GitHub Actions→
If you want to use GitHub Actions beyond the storage or minutes included in your account, you will be billed for additional usage.

Viewing your GitHub Actions usage
You can view details of your usage of minutes and storage for GitHub Actions.

https://docs.github.com/en/github/setti ... ons-usage:

It does seem to me, therefore, that storage resulting from GitHub Actions usage thus also comes into it as a limiting factor, but if I'm wrong that would be interesting to know since I could do similar for WeeDogLinux.

[MagicZaurus]

https://github.com/pricing#feature-comparison

To me this sounds like even the Enterprise Plan quotas are free, if all your repositories are public.

[dimkr]

The billing report corroborates this interpretation of the terms of service.

[TerryH]

On a clean install after first run setup, I've run Puppy Package Manager. After updating the repository data by clicking the refresh button, every package search I am doing is indicating that every displayed package is 'ALREADY INSTALLED'. I have deleted the Save Folder and ran the setup several times to check and it happens repeatedly.

[wiak]

https://github.com/pricing#feature-comparison

To me this sounds like even the Enterprise Plan quotas are free, if all your repositories are public.

Well, hats off to Microsoft if that is true. Personally I find that unlikely. But if it's true then people can stop recommending places to store their files - Microsoft provides quota free at github if files available for all... you got to be kidding. I might as well store all my isos there then. Goodbye to Dropbox?

[s243a]

https://github.com/pricing#feature-comparison

To me this sounds like even the Enterprise Plan quotas are free, if all your repositories are public.

Well, hats off to Microsoft if that is true. Personally I find that unlikely. But if it's true then people can stop recommending places to store their files - Microsoft provides quota free at github if files available for all... you got to be kidding. I might as well store all my isos there then. Goodbye to Dropbox?

They might just be trying to lock people in. In the future they may provide less free storage

[wiak]

Well, hats off to Microsoft if that is true. Personally I find that unlikely. But if it's true then people can stop recommending places to store their files - Microsoft provides quota free at github if files available for all... you got to be kidding. I might as well store all my isos there then. Goodbye to Dropbox?

They might just be trying to lock people in. In the future they may provide less free storage

Yes, maybe, though I find it odd since they could soon get system overload if all distro builders did that. Bit of a difference between simply compiling a software app than putting together and storing a whole big distro for distribution. I'm tempted to try it with WDL build scripts but my conscience is getting the better of me. I'll think about it. Void and Arch are true rolling distros anyway and so therefore are the WDL variants of these so it would be a bit of overkill (so ends up being a bit like cryptocurrency block-chains eating up precious energy resources). DebianDog could do the same - microsoft maybe soon be biting us all!

[dimkr]

On a clean install after first run setup, I've run Puppy Package Manager. After updating the repository data by clicking the refresh button, every package search I am doing is indicating that every displayed package is 'ALREADY INSTALLED'. I have deleted the Save Folder and ran the setup several times to check and it happens repeatedly.

I'm not sure what to do about PPM ... this issue, https://github.com/puppylinux-woof-CE/w ... ssues/2186 and other issues I'm aware of make me want to remove it.

[s243a]

On a clean install after first run setup, I've run Puppy Package Manager. After updating the repository data by clicking the refresh button, every package search I am doing is indicating that every displayed package is 'ALREADY INSTALLED'. I have deleted the Save Folder and ran the setup several times to check and it happens repeatedly.

I'm not sure what to do about PPM ... this issue, https://github.com/puppylinux-woof-CE/w ... ssues/2186 and other issues I'm aware of make me want to remove it.

I think that an official puppy needs at least one of the two official package managers (either PKG or ppm). I think that the woof-CE team should continue to improve both of these ppms because they offer unique advantages. I also believe that the upstream ppm for a given distro has its own unique but different advantages and one could have both ppms working together and synced, perhaps as an add-on like wiak has done for apt/dpkg. Keep in mind that for apt/dpkg additional dependencies are at least recommend (if not required?) such as gpg support.

So maybe the change that needs to be made is to make the ppm a rootfs-package rather than built-into the roofs-skeleton. However, a problem with this idea is that pkg needs some of the files from the ppm.

[BarryK]

I have posted a report on dpupOS to my blog:

https://bkhome.org/news/202103/puppy-li ... nitrd.html

[dimkr]

So maybe the change that needs to be made is to make the ppm a rootfs-package rather than built-into the roofs-skeleton. However, a problem with this idea is that pkg needs some of the files from the ppm.

I agree, if it doesn't work well, it should be optional and disabled until it's working. This is misleading and ugly.

Actually, I also dislike the approach of adding APT to Puppy, for two reasons: 1) it makes Puppy much bigger 2) like PPM, it's far from plug n' play: many packages just don't work (for example, stuff that depends on D-Bus service activation from user sessions, because Puppy has only a "system" D-Bus instance) 3) supporting APT and fixing all these incompatibilities increases the bug surface in a way, IMHO, Puppy can't handle.

---

I've started working on some debootstrap-powered replacement for 0setup/1download/2createpackages that uses rootfs-petbuilds, rootfs-packages and parts of rootfs-skeleton, with hope to produce something that looks and feels very very very close to dpup OS the way it is now: auto-login as root, JWM, ROX-Filer, gtkdialog, browser running as spot and even stuff like ptheme. It's just an experiment at this point, and it's a long-term project.

In fact, this was part of my original idea with dpup OS: build a 'lean' Puppy free from the PET format, PPM, etc' (that's why dpup OS has zero PET packages), migrate everything to GTK+ 3, build the 'Puppy desktop' from source (if old PET packages like xdg-puppy are built by woof-CE, there's no need for PETs and they can be patched for GTK+ 3 support), then find ways to make the parts in woof-CE that in my mind, are beyond repair, optional.

I think it should be possible to build something very close to dpup OS as it is right now, leveraging the good parts of woof-CE and without the bad parts, but with working APT, etc'. It would be much closer to Puppy, compared to DebianDog, and a natural path forward for both users and woof-CE developers.

It's still in early stages, but I'm very optimistic because frugalify basically allows you to stuff any distro in .sfs files, and it becomes a live distro with a layered filesystem. I don't see why this concept won't work, but I'm mostly curious how close to dpup OS it can get, without much effort.

(Everything I do will be eventually in woof-CE pull requests, awaiting feedback, and in every point through the development timeline, I'll make sure it's possible to build a traditional Puppy using the same woof-CE tree.)

[wiak]

perhaps as an add-on like wiak has done for apt/dpkg. Keep in mind that for apt/dpkg additional dependencies are at least recommend (if not required?) such as gpg support.

Actually, I also dislike the approach of adding APT to Puppy, for two reasons: ... many packages just don't work (for example, stuff that depends on D-Bus service activation from user sessions, because Puppy has only a "system" D-Bus instance) 3) supporting APT and fixing all these incompatibilities increases the bug surface in a way, IMHO, Puppy can't handle.

I agree entirely. I did not contribute my dpkg_apt_PAM sfs addon to Puppy community with a view that in that simplest add-on form it should be merged into official Puppy. I just contributed it, because I can, for those who wanted to easily experiment with apt alternative in Puppy and more so for cases when they were having trouble installing some larger packages via PPM or pkg alone, which I know can happen.

Certainly, my view aside from that, is that "fixing all the incompatibilities" between Puppy and the upstream repo that it uses is what is really required to make Puppy a better system. Relying on a part-compatibility with what are afterall Puppy's official upstream repos, using similarly part-compatible package managers guarantees points of failure, which means that Puppy can never be rock-solid but only appear so if measures are taken to prevent it being fed packages as dependencies from upstream that it cannot handle and doesn't want (for example, systemd/dbus-related issues are clearly problematic for Puppy users).

The best way to make Puppy actually better in my view would thus indeed be to make Puppy itself compatible with using official dpkg_apt package manager, but in current design it isn't, and in current woof-CE development plans it isn't going to be. For those who really want to use dpkg_apt, which is itself pretty much guaranteed to do dependency management properly, WeeDogLinux contributed dpkg_apt_PAM will continue to be made available, but with the disclaimer that some things won't work because Puppy is only partially able to use packages from the upstream repos it depends on owing to several major system incompatibilities with upstream. That, I agree, is just the reality, so unless some developer is more inclined to address these 'incompatibilities' properly, some, and perhaps over time, many, upstream packages will prove very difficult to get working and using Puppy's own home-grown package manager(s) might even be likely at times to break the Puppy system depending what upstream components they install (or fail to or cannot exclude).

Personally, I'd like Puppy to stop being that possible-to-fail system, preferably by adopting official package managers for the repos it uses (rather than stubbornly hanging onto what doesn't work properly) and fix the incompatibilities that prevent the official package manager working perfectly. I'm not suggesting getting rid of Puppy's main boot system, and unique internal control scripts, which are what makes Puppy "Puppy", though no doubt many changes need to be made to fix the upstream package-management incompatibilities. However, each to their own, and the community has to decide if current Puppy development approach is the one they want, but hopefully users will not just act like ever-faithful old sheep who as a flock just follow those who are currently leading the developments of their preferred distro.

Certainly, aside from that, there are some good developments going on in other ways up in the woof-CE Puppy world.

[dimkr]

Certainly, aside from that, there are some good developments going on in other ways up in the woof-CE Puppy world.

I think what's most interesting is the idea of synthesis between Puppy and DebianDog, inside woof-CE. If this idea works, it can "convert" both woof-CE and DebianDog developers to work on one project, a win-win situation. woof-CE's CI will make sure this transition doesn't break anything, developers like @zigbert won't feel the change, and we'll be able to move all development work that happens in the forums to GitHub. It's a fantasy at the moment, but let's re-evaluate this statement several months away from now.

[wiak]

As far as I know, and I haven't checked for some time, the only two people working on DebianDog developments are fredx181 and rcrsn51. You'd have to ask them if they are interested in your idea. Certainly I've noticed Fred often contributes help, ideas, and utily/apps to the Puppy community (not just his Dogs) but he seems recently to have been a bit less active than previously. That may simply because DebianDogs work well - with no major issues that I know about (though I've lost touch with DebianDog developments so haven't really any idea about that). Fred's build systems certainly seem to work well from DD user reports, so I'm not sure what benefit woof-CE 'synthesis/sharing' would bring to him; on the other hand some of the relatively recent work Fred has done, such as implementing tinycore-like method of loading sfs files via symlinks (which is method wanderer likes) would probably be useful to Puppy too if it moves (in total or as an alternative) to overlayfs rather than aufs. Forum member rcrsn51 originally was a key contributor to Puppy with his many well-written Peasy apps and he also has his DebianDog-related build scripts I believe.

The developers of FatDog on the other hand, which started out pretty much as a Puppy extension before becoming an independent distro design, seem to directly support Puppy itself quite strongly, on the side at least.

I would think that any such 'synthesis' or merge would likely require Puppy crowd to acknowledge that it is no longer the dominant distro amongst the pack - even perhaps the distro with the most to gain from collaboration, though I do suspect from these more recent developments (such as innovations apparent in this dpup OS1) that Puppy has an excellent future ahead of it whether it more formally 'joins' with others or not.

I certainly imagine most of these non-Puppy devs also want to see continuing active development of Puppy itself - all Linux distros seem to benefit from the overall health of all others, and even more so, I feel, when they share a forum.

But would the devs of these other seemingly perfectly healthy distros want to become part of woof-CE, which is afterall promoted as Puppy build system (and the forum, come to that, promoted as Puppy's forum)? None of these alternatives are Puppy derivatives, so like the forum itself such 'synthesis' would likely, it seems to me, require equal promotion, respect, forum organisation/space, and some way of indicating that Puppy linux itself, though traditionally the only distro discussed on the forum is but one of the increasing many. Since each distro most often has its own website (and associated domain or subdomain of some sort), the only way I could see all these matters fairly addressed would be for some other 'neutral' domain that the likes of fatdog, debiandog, and puppy itself redirect to (where the shared forum would reside, and a new development/build git site named accordingly) - but even as I say that I pity poor rockedge! TheKennelsLinux.com???

Even if mutual collaboration only remains the best model of interaction likely to occur between such distros (rather than each having own branch at a 'TheKennels' shared woof-CE site), it would still be nice if the in-common forum they shared was not named and organised only in terms of one of them as if it were dominant still. Anyway, time will tell, and the alternative is to leave things as they are where some distros and their devs will perhaps move away entirely, eventually (or not) to their own space (forums, wikis and whatever). I suspect some old-timer Puppy guards would prefer that - however... No doubt the common shared forum interest (and its active members) is what has prevented that drift away thus far - the forum is as much a social space, as a generic technical discussion space, and thus effectively a long-established 'Linux-related' home for its members whether they still actually use Puppy or not (as some of them do, and some of them don't).

EDIT: I should say that I don't think the shared but 'less than equal shared' forum is much of an issue really. Pretty much all the 'other' distro devs seem fine with just an entry or two to briefly discuss their own developments and to help out more generally when they can. Build systems are a bit different though, as are individual distro's main websites. Certainly, the forum is not perfect from that point of view, but history has its effects such that nothing is ever perfect anyway and the importance of this forum is as I say mainly a social/technical one and I doubt most really care which distro is being discussed. The number of active users on the forum does not appear to me particularly high anyway (though seem to be a few new non-oldtimer members recently, which is a really good thing to avoid old bickers and boredom...) - very little congestion therefore and most of us know the existence and location of the other distro threads and websites.

Actually, alas, I remember all too well the opinion of one woof-CE dev when I simply once posted a list of "Distributions created by forum members" since I felt that 'other-than-Puppy' distros were pretty low in visibility down in Puppy Projects thread on the old forum. https://murga-linux.com/puppy/viewtopic.php?t=115557 NOTE I've written the link as https but won't work unless changed to http but I'm worried rockedge would be mad at me if I used http since that style has apparently caused forum hacking issues (though I don't understand the details). Same first post can be found here (https ok with this one though I still need to update its internal links to new puppy-related https urls): https://www.tinylinux.info/post/distrib ... m-members/ Actually I don't write much about the DebianDogs there, but I did in the end add more about WeeDogLinux since that is what I am myself concentrating on.

...all this cataloguing is indeed just to provide more visibility to specific efforts.
Is OK for a developer to promote the distro of choice but I still do not see any value in this selective cataloguing in the expense of all the rest, for the reason I just said above.
I did not hear anything to the opposite yet.
Only that debian dogs deserve more visibility and acknowledgment.
This is fine, but let's be clear about it.

That past resistance to change forum to reflect usefulness of all distros contributed is what leaves me doubtful overall and still somewhat fighting the old-timer resistance is futile, who cares about anything but Puppy, sort of negativity (despite that no longer being so direct as it used to be). Anyway, times have changed to some extent (new forum here at least) so perhaps visibility of other distros is no longer so frowned upon, and personally I couldn't care less if someone loves Puppy or loves DebianDog or whatever, or doesn't, but I am interested in seeing all forum distros develop and applaud all such efforts. I cannot be bothered with old-timer stick in the mud conservative approaches however - all possibilities should always be on the table, but that does not mean that all suggestions need be accepted - community should decide that - not just those capable of contributing to woof-CE or accepted there by the old-guards.

wiak

[dimkr]

Maybe https://github.com/puppylinux-woof-CE/woof-CE/pull/2201 will fix PPM. PPM relies on woof-installed-packages and it was empty, but I still can't tell if this is the only problem that prevents PPM from working.

EDIT: I was able to install screen and GIMP in build 19. Also, I tried changed the language to Spanish - everything is in Spanish (including stuff like errors in the terminal!), except Firefox, which needs a language pack I installed through PPM.

[darry19662018]

Hi Dimkr,

Is it possible to frugal install this by placing files in a directory and making a grub4dos entry?

If so what would that entry look like with persistence??

[Clarity]

No offense to anyone.

But, GRUB2 + EFI as it is developed and contributed by world developers, PC manufacturers, Storage manufacturers, and is easily understood as well as robust to assist PUP and DOG booting that we have witnessed as stable over the past 18 months; If is the leading contender for the standard we should be striving to considering the benefits it provides. From my point of review, the PUP developers spent a bit of time evaluating the best booting methods and have implemented such with the GRUB2-EFI approach currently used.

The current implementation supports BIOS PCs, UEFI PCs, x86/x86-64/RasPi/etc as well as VMs.

It is proven Safe and stable. My feeling is that GRUB2 is, both, timely (as manufacturers continued support and contributes) and offers improvements. All done without PUP developers special follow-up needs. And it is easily understood with documentattion everywhere on the net.

G4D was a mainstay, for me. But, time has shown us a better way without PUP development's involvement and some of the other restrictions in G4D.

Not only does GRUB2 provide simple boot ability, but also gives direct debug ability and can be much more than the simple means seen.

This is just a mere picture that any of us can review.

P.S. I am an Oldtime (as referenced by @wiak) and it took me awhile to loosen my grip on G4D (10 years).

[dimkr]

Hi Dimkr,

Is it possible to frugal install this by placing files in a directory and making a grub4dos entry?

If so what would that entry look like with persistence??

It won't be proper frugal install, because there's no initrd. But technically, you can take the extlinux configuration file and translate it into a grub.cfg, there's no reason why it won't be able to boot like that.

dpup OS always saves stuff in /save, under the boot partition. There's no save file.

[dimkr]

It is proven Safe and stable. My feeling is that GRUB2 is, both, timely (as manufacturers continued support and contributes) and offers improvements. All done without PUP developers special follow-up needs. And it is easily understood with documentattion everywhere on the net.

Easier said than done. I'll take a look at UEFI support at some point, but not now. As you can see, one of the main ideas here is simplifying Puppy's core. Therefore, I want to do this as simple as possible, and using the EFI stub (no GRUB) is a possible direction.

[wiak]

Yep, a small, single executable is ... a small, single executable. Doing it in C has the advantages of not having to put busybox with ash, losetup, mount, etc' on the boot partition, and the advantage of not having to build two busybox binaries, one for the "initramfs" part and another to put inside the main SFS.

That is a very small advantage indeed. The init provides the layering facilities for the whole distro, so that is the core mechanism for providing modularity and functionality. Providing that in a compiled C binary makes it unaccessible except to those with C programming skills, but even then it is a nuisance in terms of development contributions since C is nothing like so user-friendly when it comes to doing anything with it. I say that as someone who has programmed in C for over thirty years, including as part of my profession (I love C, but...).

Certainly C tends to mean 'speed' but that's only going to be humanly noticable on large data tasks which an init simply does not involve. So the net result of using C for an init is that it is yours to play with and develop and pretty much unlikely to be modified by most anyone else at all (if only because why bother when shell script version with busybox is so easy to add facilities to and improve). I guess that embedded system arguement where initramfs cannot be used is one special circumstance where someone might make a 'special' C-coded init like this, but that is hardly the usual general needs case.

Anyway, interesting someone would code their init in C like this. No doubt some who are interested in C as a hobby will be attracted to it and excited to examine its workings. At the end of the day the overall flexibility is what is important too - the algorithms used and so on - which allow easy study, maintenance and extension, because init systems used to create facilities for frugal installation need to be flexible in terms of easy to add new facilities and I suppose the key algorithm concerns the creation and management of the layers themselves. That process is a weakness in traditional Puppy - it adopts a fixed filename approach to its sfs 'modules' and only allows very few such modules at boot time.

I recognised that in designing the open and user-friendly (short and simple shell scripts only) WeeDogLinux build system and created an algorithm based on a "loop through boot directory looking for sfs approach" followed by sort, mount to tmpfs and bind routine, with final assembly of the sorted list for presentation to the mount overlay command. I recently documented that further (for aspiring WeeDog developers) here (though of course this design pattern was already open and available to read in the always published easy-to-read simple WeeDog build shell script):

viewtopic.php?p=21859#p21859

That unique "loop for sfs/followed-by-layer-sort" WeeDog design gives WDL a clear advantage over Puppy in terms of modularisation. No other distro I know of used the same approach. One added part of that WeeDog algorithm is the abandonment of the idea of using fixed filenames for the sfs modules, by simply prepending a numeric digit onto the front of the filename and using that to make the layer sort more effective (Puppy as I say just hardcodes the layers it will use - no WeeDog-style search, find, and order approach). By using that approach a WeeDog user can simply change the module numeric to have it loaded at boot time to a different layer position (and WDL by default allows one hundred such module layers...).

Of course, Puppy's sfs modules naming convention (including puppyXXX.sfs) could be left as they are, but then the WeeDog "loop through boot directory looking for sfs approach - followed by sort" isn't so effective and nothing like so flexible (without giving extra processing work to the init). Probably is that puppyXXX.sfs has to come first (layer 0) to meet traditional Puppy needs, so any alphabetic sort routine has to take the messy first step of singling out puppyXXX.sfs for the special treatment that it is assigned to layer 0. Only then can sort alphabetic be used on the remaining sfs modules (adrv, fdrv and so on) but even that would inflexibly assume that alphabetic ordering of these is correct.

So for Puppy proper my recommendation would be - look at the way WeeDogLinux does it and consider using that WeeDog algorithm as is, or deriving from its unique "loop looking for sfs approach followed by sort approach", but also consider minor modification to puppy filenames using either pre or post numeric module layer position identifier. Or at least rename the puppy filename modules alphabetically (so puppyXXX.sfs filename could be altered to start with letter 'a' perhaps, though limiting to 26 letter alphabet may in time prove to be inadequate in terms of the number of layers/modules someone sometime might want... WeeDog layers/modules are easily expanded to allowing for NNN or NNNN i.e. 10,000 modules if you want!!! though underlying Linux system would need to be also capable of that support). Certainly it is always possible to use symlinks (as I've read you do) to provide an alternative filename (for example with numeric pre or post addition) without physically otherwise renaming (though often actual renaming makes more sense - using symlinks can get pretty messy when used for a purpose like this: I used to use them as a file renaming mechanism in tinycore installs so I could share tcz modules between different boot scenarios, but was annoying to adjust/maintain - certainly that use involved dozens of symlinks to the tczs, but there is no reason that in a modular-based distro someone won't want dozens of sfs modules/layers, which tinycorelinux does in fact use though not via unionfs constructs; wanderer is wrong in imagining dpup OS 1 is particularly accommodating in terms of sfs layer-manipulation, modularisation capability I think though I gather an improvement over the fixed modules allocation used by Puppy traditional - better with WDL approach if you want modularisation, or tinycorelinux approach indeed).

Anyway, your personal project is none of my business - just commenting on C init part of it (since you are a community woof-CE dev) in the hope Puppy main does not move towards using C for it's boot init. That in my opinion would be a backward step: makes the code inaccessible to the majority, and difficult to modify when new facilities are desired (which they always are), simply not flexible format for easy development. Speed here is pretty much irrelevant (unnoticable); size in bytes? - an initrd is pretty tiny anyway (or can be made so, and most unloaded out of RAM on switch_root anyway)... so nothing that needs tinyfied really.

Other than that, yes, an interesting 'experiment' - it works - why not, at least for this one-off.

wiak

[dimkr]

Providing that in a compiled C binary makes it unaccessible except to those with C programming skills, but even then it is a nuisance in terms of development contributions since C is nothing like so user-friendly when it comes to doing anything with it.

I strongly disagree with this statement. (Let's ignore the fact I've spent most of my adult life so far, doing mostly low-level development, mostly in C - it's irrelevant).

People who don't know what mount is, won't edit the initramfs or the init script. But people who know what mounts are, what chroot does, etc', and have some imagination, won't find these 300 lines of C code (with comments and empty lines!) hard to hack on.

This line (https://github.com/dimkr/frugalify/blob ... ify.c#L162), this cryptic mount(NULL, "/", NULL, MS_REMOUNT | MS_NOATIME, NULL) is equivalent to "mount -o remount,noatime /", mkdir() is equivalent to mkdir, and chroot() is equivalent to chroot. The difference is not big, when you focus on the implementation details and not the semicolons.

Other than that, yes, an interesting 'experiment' - it works - why not, at least for this one-off.

You're dismissing my work as if it's some experiment or toy, while there are strong technical arguments why it's a better approach (in many ways), compared to the shell scripting you're advocating and justifying using the statement I just refuted.

[wiak]

You're dismissing my work as if it's some experiment or toy, while there are strong technical arguments why it's a better approach (in many ways), compared to the shell scripting you're advocating and justifying using the statement I just refuted.

I thought it was an experiment, but never suggested it was a toy. Presumably the method you use to determine the selection and placement of the Puppy sfs modules in the layering system is not the same as that in Puppy traditional or your number of modules would remain very limited. You haven't refuted anything, you have simply stated your differing opinion - I'm fine with you disagreeing with my opinion.

As I said, I personally hope using C for Puppy main system component does not become more than experimental in woof-CE should that be introduced there; I am pretty sure that is not so accessible a form of coding to even some excellent developers on this forum. Otherwise I am fine with people writing in C (it is your own project afterall and not woof-CE official); as I say I have done so myself (though not for something that worked efficiently enough in a higher level language such as shell - but each to their own).

[wiak]

This is a 'forum', by the way. If something is published about here, everyone has a right to give their opinion, the negative and the positive.

Seems to me, the use of C as an alternative to shell scripting, in terms of accessibility, for community distro core component designs is a worthwhile topic for discussion (heated or otherwise). Also, if the language used is not understood by everyone then we can get the additional problem that a person can say the same thing but that won't be understood or recognised, which doesn't help add to the body of research/development effort (my opinion... remember?).

Though I've also 'used C for years', still I am so rusty at it just now I would struggle with it overall (but I'm fortunate that using it would still be within my own grasp - not so sure about every one else on the forum including some very talented developers here).

[s243a]

This is a 'forum', by the way. If something is published about here, everyone has a right to give their opinion, the negative and the positive.

Seems to me, the use of C as an alternative to shell scripting, in terms of accessibility, for community distro core component designs is a worthwhile topic for discussion (heated or otherwise). Also, if the language used is not understood by everyone then we can get the additional problem that a person can say the same thing but that won't be understood or recognised, which doesn't help add to the body of research/development effort (my opinion... remember?).

Though I've also 'used C for years', still I am so rusty at it just now I would struggle with it overall (but I'm fortunate that using it would still be within my own grasp - not so sure about every one else on the forum including some very talented developers here).

Woof-CE could have the option to build more than one type of init system. If that is the case then both the "c" and "shell" approach could exist together. The concept of more than one type of init system is probably a good idea since at the very least some people might want to use overlayfs and others might want to use aufs instead.

[wiak]

Woof-CE could have the option to build more than one type of init system. If that is the case then both the "c" and "shell" approach could exist together. The concept of more than one type of init system is probably a good idea since at the very least some people might want to use overlayfs and others might want to use aufs instead.

Yes, woof-CE could indeed include alternative C and shell init scripts. The point is what is okay as 'mainstream' Puppy, which advertises itself as a 'community' distro? Its development becomes very much non-community-oriented if mainstream is in a language most in the community cannot even read (like alone check for correctness, safety, and its meeting code re-use licensing conditions). How would that foster community involvement in Puppy development? And why? Shell scripting for inits is fine and fast enough. Writing core mainstream Puppy code in languages that will never likely be understood by most of the Puppy community will create divisions - more than already exist - in the form 'those who can read, and the (vast majority) who can't'. Shell script, on this forum at least, is pretty much a universal language (for many at least). Sorry, but using C is very clever and I do think an interesting 'experiment' for those who love C, and for some kind of work a compiled language is really needed, but...

EDIT: I've already said that this is my own 'opinion' but also that of course what dimkr does in his own distro project is his own business (within the limits of safety and also meeting code re-use licensing conditions of course), but Puppy Linux mainline is a community distro, so that is a different situation altogether.

[Duprate]

Helo! For me, when things get very complicated, I discard and go ahead! I prefer an overlayfs system, I don't care if after boot I will be able to assemble or disassemble modules. Since I am not a programmer, I minimally understand a startup script. I can make some adaptations for my use. Simple ideas are the ones that work!
I recognize the effort of "dimkr" and each one involved in this project, but for me it is beyond my capacity.

[wanderer]

hi all

i know ive never mentioned this before
so it will come as a shock to everyone

but why not make puppy into a modular system

one module will be dimkrs c init
another module will be the old script init

and using my simple build system
one can choose which module one wants in each build

since my simple build system
is so simple it can be used by anyone
both systems can be available to all

problem solved

william

[wanderer]

by the way

im working on all of that now on the corepup thread

using dcore-stretch as the example base

william

[dimkr]

Yes, woof-CE could indeed include alternative C and shell init scripts. The point is what is okay as 'mainstream' Puppy, which advertises itself as a 'community' distro? Its development becomes very much non-community-oriented if mainstream is in a language most in the community cannot even read

Users who understand what "mount" does in a shell script, understand what "mount()" means in C. This direct translation to C should be as clear as a shell script. Those who can't read the init script can't read the C translation, and those who understand the init script, can modify the C translation with the same ease. The problem is not the {} and the ; or the "int" before numbers, but understanding concepts like the file system hierarchy, loop devices, etc'. Have you read frugalify.c? If you can identify one thing in it that is totally unreadable to someone who understand how Puppy's init script and initramfs work, I'd gladly add extra documentation.

And even if C is indeed an obstacle, the responsibilities of the initramfs are very clearly defined and easy to meet, so I don't think it should be changed often once it reaches its "1.0" version, hence the switch to C shouldn't affect the number of contributions at all. The whole point about doing this in C is reducing complexity (getting rid of the initramfs along with the long init script and configuration files inside it, while making updates easier), so I don't get why you'd want to add extra bells and whistles to frugalify: it has only one job, and except support for encryption, maybe, I see no reason to touch it.

[wiak]

Partial list of features:

• The new PUPMODE 6 boot mode, using frugalify and overlayfs - no initrd, no aufs

• To load a SFS on boot, just add put it in the boot partition

• Inspired by @666philb's Fossapup64 and expanding on this idea, dpup OS consists of a main SFS, adrv, zdrv, fdrv, devx, nlsx and docx - you can delete adrv to get a barebones Puppy that boots to a JWM/ROX-Filer desktop without applications, delete docx and nlsx if you don't need documentation and speak English, etc'

At the moment, there is no installer that can be used to install dpup OS to disk

So booting dpup OS1 from usb and checking with: mount | grep overlay
gives this result to show how the layers are assembled:

Code: Select all

overlay...lowerdir=/save/.sfs0:/save/.sfs1:/save/.sfs2:/save/.sfs3:/save/.sfs4:/save/.sfs5:/save/.sfs6,...work

Please see attached Screenshot (Screenshot_WDL_dpupos2.png)

Note that this has been booted from hard disk /mnt/sda1 on my system and result of mount | grep overlay is:

Code: Select all

overlay ...,lowerdir=save_sfs00:06:05:04:03:02:01,...work

Similar, hmmm? Created this version in 10 minutes (literaly ten minutes). How???!

Well, because of what I explained, here: viewtopic.php?p=21859#p21859

which is an explanation of WeeDogLinux unique _addlayers function (original designed early 2019), given also in simplest english as:

Code: Select all

Make a directory in tmpfs for mounting layer filesystems to.
while not all files done:
  Look through the directory where the filesystem modules are
  looking for .sfs module filesystems and raw module filesystems.
  For each one found, mount it ready for use in unionfs layers.
  Keep track (variable or array) of each found.
end_while_loop (i.e. keep doing the loop till finished)
Sort all the results found above in the order you want them in the layers.
mount the overlay (be it with aufs or overlayfs) to a tmpfs directory in RAM using the stored list of filesystem modules found above.

A huge improvement, if I may say so, to the static coded method traditional Puppy uses...

Turns out that dimkr's dpupos1 is extremely compatible with WeeDogLinux's init (WDL init however provides considerably extra functionality and is not coded in C, but rather in shell script). It thus took me but 10 minutes to use WDL initrd to boot dpupos1 and it booted in that manner (not a surprise to me...) at my first attempt. Would have taken even less time to do, but, just for my amusement... I quickly altered a couple of lines in WDL init to show puppyXXX.sfs as save_sfs00, or I would have left it simply as name 00 ...

Actually making that tiny modification to WDL code of its _addlayers algorithm was even easier than that since main (shell script) init code for WeeDogLinux isn't even buried inside the initrd.gz, it is an external text file (shell script in boot directory called w_init), which is immediately editable with geany. So, very accessible to all, and easy to modify if you wish, and supports one hundred (100) module layers out of the box, and these layers can be sfs filesystems or raw directory filesystems or a mix of both...

So it all comes down really to WeeDogLinux, dare I say elegant' _addlayers algorithm given above, coded in shell script for easy reading/modification - not that any actual modification was really required to work with dpupos1...

Anyway, really late here. Nothing more needed for me to show or say I think if you understand the explanation. Good night.

wiak