Phasing out PETs
-
- Posts: 247
- Joined: Fri 31 Jan 2014, 14:12
Phasing out PETs
Hi,
I trust this new thread isn't misplaced.
Somewhere deeply hidden in the puppy blog,
is Micko's proposal to eventually get rid of PETs
among other changes for future distro designs.
This would be a shame, as particularly OscarTalks
Index of PETs is a useful source of add-on apps.
eg. I notice he always keeps Flash-plugin versions bang up to date.
If this materialises, perhaps the above and other useful
PET app sources could be archived for easy access to all.
Regards.
I trust this new thread isn't misplaced.
Somewhere deeply hidden in the puppy blog,
is Micko's proposal to eventually get rid of PETs
among other changes for future distro designs.
This would be a shame, as particularly OscarTalks
Index of PETs is a useful source of add-on apps.
eg. I notice he always keeps Flash-plugin versions bang up to date.
If this materialises, perhaps the above and other useful
PET app sources could be archived for easy access to all.
Regards.
-
- Posts: 247
- Joined: Fri 31 Jan 2014, 14:12
Yes ok noted jlst.
I'm relatively new to Linux at 71 and the learning curve
associated with the subject, after leaving Windows
behind and my first-hand terrors of virus infections.
The ease of Puppy and its offshoots seemed a safe
haven from all of that and reading forums gave me
a good insight into how it all fitted together.
I'm not a coder or compiler, so the distro building blocks
of words like Woof and bones that Barry K created
seemed strange when I first dipped a toe in the water
to install to usb then try out his innovated work.
I realise this must seem old hat to compilers like Micko
who forked out on their own to modernise operating systems.
Though for me as Barry explained some years ago - the Pet
is the equivalent of an executable windows application -
just click on it and the program will self-install.
I thought that was a marvellous idea and still do, but
the world moves on and progresses new revolutionary
ideas I suppose. So you can see how I'm reluctant
to let go of something I'm just getting used to.
Regards.
I'm relatively new to Linux at 71 and the learning curve
associated with the subject, after leaving Windows
behind and my first-hand terrors of virus infections.
The ease of Puppy and its offshoots seemed a safe
haven from all of that and reading forums gave me
a good insight into how it all fitted together.
I'm not a coder or compiler, so the distro building blocks
of words like Woof and bones that Barry K created
seemed strange when I first dipped a toe in the water
to install to usb then try out his innovated work.
I realise this must seem old hat to compilers like Micko
who forked out on their own to modernise operating systems.
Though for me as Barry explained some years ago - the Pet
is the equivalent of an executable windows application -
just click on it and the program will self-install.
I thought that was a marvellous idea and still do, but
the world moves on and progresses new revolutionary
ideas I suppose. So you can see how I'm reluctant
to let go of something I'm just getting used to.
Regards.
so i guess the question is: 1. what should package creators do now? .pet? .deb? vary on the distro? 2. what should puppy deriv authors do now? frugal+install+remaster? are there other ("standard"?) options we should know about?jlst wrote:PET support will never go away, but the ability to build a puppy ISO based entirely on pet files only (something like puppy4, wary5) is already gone.
I don't understand what is considered to be wrong with the idea of pets. It is a great way to add functionality. I especially benefit from it as I have no savefile and only load the programmes i want each session (programmes loaded via pets).
It means I can trial heaps of software without accidentally loading it permanently into a savefile.
SFS files dont work as well because they sit on the lowest level of Puppys layered system whereas pets sit on top - ie: you can use a pet to overwrite (and therefore override) a faulty file in the main Puppy sfs, but you cant achieve this by loading an sfs - it would sit below the main sfs and achieve nothing.
Long live pets!
It means I can trial heaps of software without accidentally loading it permanently into a savefile.
SFS files dont work as well because they sit on the lowest level of Puppys layered system whereas pets sit on top - ie: you can use a pet to overwrite (and therefore override) a faulty file in the main Puppy sfs, but you cant achieve this by loading an sfs - it would sit below the main sfs and achieve nothing.
Long live pets!
I hope the stuff is backed-up somewhere in case in the future this was decided as an over-zealous decision. I like the PET based system as it provides good cross platform support between puppies but I see that some puppy distros (e.g. fatdog64) have phased out the pet-get system.jlst wrote:The repos are there, i think micko is not going to delete them. Even the support for building pet-based puppies may come back in the future... we had a deleting rampage to clean up stuff and just went berserk.. but that doesn't mean that woofce puppies can't install PET files anymore, we just dropped support for building PET-based puppies (T2, quirky, whatever).
Those changes are still not visible, in fact nothing that happens in woofce git code repository is visible to anyone, for the first time users can monitor and comment on each change but nobody knows and nobody cares, so it doesn't matter anyway.
You have to know to care, but even if you both know and care, you don't necessarily have to tell anyone about how you care, but it matters even if nobody knows.jlst wrote:...for the first time users can monitor and comment on each change but nobody knows and nobody cares, so it doesn't matter anyway.
I do exactly like greengeek, I run without any savefile, an it only takes a few seconds to load a .pet when needed.
But I see some problems assosiated with that procedure, and that is when you delete that same .pet after using it, or you may simply change your mind. If the .pet add already excisting files to the system, it will remove them too. And that may cause some problems for other programs which used those files. I may be totally wrong about this, but I have sometimes had problems with other programs after removing a .pet. An .sfs is just removed whitout such issues. (I still don't like them)
But what is the alternative to a .pet?
Does that mean that a future puppy will be some kind of mongrel without it's own genes? What is the point in such a puppy? You can just shave off some unnecessary Ubuntu functions, Oh! Great only 650Mb, and achieve the same?jlst wrote:There is Ubuntu, Debian, Devuan, Slackware and Gentoo. There are just too many sources for Puppy to get the basic stuff and work fine, like a parasite.. there's no need for anything else..
Please elaborate!
tallboy
True freedom is a live Puppy on a multisession CD/DVD.
cd / ; tar -xvf puppypackage.pet 2> /dev/null (although that wont run the install scripts.)jlst wrote:This is gradually becoming a somewhat fast process, but the package manager needs a complete rewrite to allow cli usage and versatility.
the annoying part is creating a .pet package, which is tied to a gui. i bet thats more easily fixed than creating a new system.
i do agree that the .pet system is fine. but i appreciate the fact that there are these new style puppies that came after .pet, and the potential for a new package is not all terrible. i really hate package manager changes in general. please keep it simple as possible-- the package system, not just the installer!
-
- Posts: 1543
- Joined: Mon 22 Feb 2016, 19:43
Sometimes I notice Woof-CE says "Updated an hour ago" so I look at the testing, rationalise etc. branch commits and all the comments and nothing was updated for 12+ hours. I did wonder what mysterious "thing" was always being updated.jlst wrote:Those changes are still not visible, in fact nothing that happens in woofce git code repository is visible to anyone, for the first time users can monitor and comment on each change but nobody knows and nobody cares, so it doesn't matter anyway.
You can use petget from the command line both to add and remove packages. Also you can see the installed packages installed by petget in the directory /root/packages.jlst wrote:Hahaha i chose the wrong word, but you get the idea.
I mean Puppy does not descend from any other distro, but uses packages from other distros to run, the work to make this happen has been tremendous.. it's also incomplete and it's been very slow both at building puppies and the package manager itself.
This is gradually becoming a somewhat fast process, but the package manager needs a complete rewrite to allow cli usage and versatility.
I find browsing directories and text files much easier than navigating a package manager.
If a puppy distro doesn't have petget one could write a wrapper script for it which might even maintain this directory as an alternative way to view the installed packages.
Perhaps you should make a list of features that you would like to see in petget.
oh, thanks for this. as dialogs come up when i use petget i assumed they would stop puppy from running petget from a vt. youre right-- it works without x running at all.s243a wrote:You can use petget from the command line both to add and remove packages. Also you can see the installed packages installed by petget in the directory /root/packages.
I find browsing directories and text files much easier than navigating a package manager.
i generally prefer to avoid x in puppy whenever i can. its not that i dislike x-- i use it for running a term, browser, and naturally graphical tools like graphics editors.
i am all for gui addons to management utilities, but i dont want to have to start x (or fiddle with the mouse, or hit tab 20 times) to use them.
It's not only about preference if you mess up X by trying to trouble shoot something (like poor performance in virtual box) then using petget through the cli is the only option.learnhow2code wrote:oh, thanks for this. as dialogs come up when i use petget i assumed they would stop puppy from running petget from a vt. youre right-- it works without x running at all.s243a wrote:You can use petget from the command line both to add and remove packages. Also you can see the installed packages installed by petget in the directory /root/packages.
I find browsing directories and text files much easier than navigating a package manager.
i generally prefer to avoid x in puppy whenever i can. its not that i dislike x-- i use it for running a term, browser, and naturally graphical tools like graphics editors.
i am all for gui addons to management utilities, but i dont want to have to start x (or fiddle with the mouse, or hit tab 20 times) to use them.
too true, but i have the preference more often than i have the issue.s243a wrote:It's not only about preference if you mess up X by trying to trouble shoot something (like poor performance in virtual box) then using petget through the cli is the only option.
(and part of the reason for the preference is that when it does come to that, i like to spend a few seconds fixing it rather than reinstalling or something like that.)
if people focused on the advantages of the command line, instead of the times when its not better (or the unfair reputation given to it by marketers,) people would realize its priceless and generally worth considering.
almost no one uses it all the time-- im typing into a browser in x, and now im going to post this by switching from the keyboard to the mouse for a moment.
Have you tried any of the cli based internet browsers. I wonder if one can surf any linux forums from them.learnhow2code wrote:too true, but i have the preference more often than i have the issue.s243a wrote:It's not only about preference if you mess up X by trying to trouble shoot something (like poor performance in virtual box) then using petget through the cli is the only option.
(and part of the reason for the preference is that when it does come to that, i like to spend a few seconds fixing it rather than reinstalling or something like that.)
if people focused on the advantages of the command line, instead of the times when its not better (or the unfair reputation given to it by marketers,) people would realize its priceless and generally worth considering.
almost no one uses it all the time-- im typing into a browser in x, and now im going to post this by switching from the keyboard to the mouse for a moment.
Have you tried any of the cli based internet browsers. I wonder if one can surf any linux forums from them.learnhow2code wrote:too true, but i have the preference more often than i have the issue.s243a wrote:It's not only about preference if you mess up X by trying to trouble shoot something (like poor performance in virtual box) then using petget through the cli is the only option.
(and part of the reason for the preference is that when it does come to that, i like to spend a few seconds fixing it rather than reinstalling or something like that.)
if people focused on the advantages of the command line, instead of the times when its not better (or the unfair reputation given to it by marketers,) people would realize its priceless and generally worth considering.
almost no one uses it all the time-- im typing into a browser in x, and now im going to post this by switching from the keyboard to the mouse for a moment.
elinks is the one you want. its not great for forums, and w3m is very cool but again, not for forums.s243a wrote:Have you tried any of the cli based internet browsers. I wonder if one can surf any linux forums from them.
text-based browsers have terrible (if any) css support, which means textboxes are the wrong size, among other things.
you could use a proxy to edit the attributes of textboxes you use often enough. seriously though, using text-browsers for forums isnt as fun as it sounds. they are good for a number of other things.