Why not do something similar to Arch Linux and only provide a core system to which you add only the stuff you want/need? The core doesn't even have a desktop. Arch Linux has done extremely well with this approach - but it's main afficionados are the techie types.

In the case of Puppy though, adding in the extra stuff should be made easier than it would be with Arch. The main desktop and network modules would be provided via the internet in the form of sfs modules - pre-configured and ready to go - just plug them in. Same for the browser.

Each developer would be in charge of his own module which would plug in to the same core as the other developers.

So that's five modules that would need a developer apiece:
Core, Network, Desktop, Video and Browser.

Other modules would be necessary as well, but these five should take care of a minimum working installation._________________Life is too short to spend it in front of a computer

So that's five modules that would need a developer apiece:
Core, Network, Desktop, Video and Browser.

Are drivers always part of the core? I have always been confused about what zdrv is. Is it possible to have a small, stable, tight core that is capable of automatically "pulling in" drivers (or requesting what it doesn't already have..) on a system that has new versions of hardware?

If the "driver section" was another one of the modules it could make hardware compatibility and portability easier perhaps?

What I would most like to see for Puppy 6 is that it be platform independent as much as possible. ie: that it looks and behaves quite similarly whether you use it on a desktop PC, a laptop, a netbook or a tablet or on a Raspberry Pi.

This means that it needs a modular structure with a simple core, and a series of add-on modules that tailor it to the hardware it is running on. In a way this is the same sort of approach that Puppy has used with the “Wizard” structure - if you want to set your system up correctly you just run the appropriate wizard.

Puppy 6 could use the same concept, but with lots more wizards. You want to run Puppy6 on a desktop PC? Then run the “Choose hardware” wizard and it should offer you a module (or selection of modules) that is appropriate for a “32bitPC” or “64bitPC”. Want to run it on a tablet? Then the “choose hardware” wizard should pull in the modules specific to that type of interface (touch screen etc etc)

It would be good to extend the number of wizards available, so that configuration tasks are simplified. eg: I have no idea how to write a network configuration file, but I know how to run the various network configuration wizards to get the outcome I need. This is why I use Puppy - the wizards make it possible for me to “assemble” the software I do not yet understand.

The key is to keep on writing and refining the wizards (ie: “modules”) that allow the user to overcome their inabilities, and to make sure that those modules allow portability to different hardware.

Even if it isn’t possible for Puppy6 to be structured so that is is portable across widely differing hardware, I would like to see it focus on improved wizard functionality in other areas.

One of the main problems that I have seen drive people away from Puppy is the difficulties of getting printing to work. Basically the “Add printer wizard” only works for a small number of models. It needs to be refined somehow.

Why can’t Puppy create a repository of drivers that are reformatted to a common standard? (At least common to the various future Puppies...). Why can’t the future Puppy define a new standard for printer drivers eg: “The driver repository must contain statics that can be installed as a standalone”. At the moment the user sees a manufacturer release a PPD and think that the PPD is all they need, but really they need other stuff as well. What if Puppy could present a “modularised PPD-static” for each type of printer that Puppy users wanted to add to CUPS?

This is basically what forum member rcrsn51 does when users get into trouble trying to load printers - he creates a .pet for that printer. This pet essentially becomes the “modular wizard” that I am talking about. Forget about the “Cups printer wizard” - the real “printer wizard” is rcrsn51.

Although “static builds” tend to be large, maybe this is what we have to accept more of. Allow dumb users like myself to have access to “static build” wizards, while smarter users already know how to avoid the bloated statics and finetune individual config files to achieve what they need.

Example: I got Skype running on my Puppies by running the “Skype-static” installer. I could not have done it any other way. This “static” installer became the “wizard” that did the install.

I would like to see Puppy6 be built around “static wizards” that work well for the new user, even if the static is ugly and bloated from a programmers point of view.

Quote:

In the case of Puppy though, adding in the extra stuff should be made easier than it would be with Arch. The main desktop and network modules would be provided via the internet in the form of sfs modules - pre-configured and ready to go - just plug them in. Same for the browser

Yeah, maybe there needs to be more connection between the wizards and various .sfs files? Lots more wizards pointing to lots more sfs options? And keep the core small and tight?

There's no point in providing just a core and then saying to the user "go and install your own stuff" a la Arch Linux. Puppy needs to be fundamentally friendlier than that. There needs to be a friendly "welcome-screen" included along with the core, that points the user towards these wizard options .

This sort of welcome-screen approach has already been used in, amongst others Puppy Lucid, but I don't recall seeing it used on top of a bare bones core Puppy.

Also, as greengeek says, many of these "wizards" already exist anyway - they only need to be pulled together under a nice friendly front-end to make accessing them simple and obvious to inexperienced users who are doing an initial set-up of their Puppy system(s).

Good SW engineers, project leaders and designers think modular - so such use of wizards and sfs files would encourage this sort of approach right from the concept/design stage.

It's like starting an oil painting. The first brush stroke actually defines the final brush stroke. Make a mistake with the first stroke and you may never get to the final one without having to tear the thing up and then having to start from scratch. LOL it's like dejavu all over again!

The zdrv is simply another sfs module that contains extra drivers. The developer has the choice of building his system with this being either, an entirely separate module or, as an alternative, being included with the main pup.sfs module. These installable kernel modules would sometimes need to be recompiled to match a given kernel. If the core changes to a different kernel, then an updated zdrv.sfs would be needed with recompiled drivers.

This also leads to an interesting concept. I wonder if an updated kernel itself might be supplied in the form of an sfs file, to which the equivalent zdrv.sfs would also need to correspond._________________Life is too short to spend it in front of a computer

The iso is not a barebones ISO, thus the user can see the potential. However, you can get a barebones iso easily by removing the applications sfs.

The PPM is enhanced and polished.

Saluki custom builder is not a remastering tool - it's more like Unleashed on steroids. You can rebuild the applications sfs with only applications you want. You can also install the kernel of your choice and even cut it down to only drivers you need. Dependencies are checked and automatically downloaded.

Printing is modular. Either install the all-in-one sfs or install just the drivers you need from pets.

The iso is not a barebones ISO, thus the user can see the potential. However, you can get a barebones iso easily by removing the applications sfs.

The PPM is enhanced and polished.

Saluki custom builder is not a remastering tool - it's more like Unleashed on steroids. You can rebuild the applications sfs with only applications you want. You can also install the kernel of your choice and even cut it down to only drivers you need. Dependencies are checked and automatically downloaded.

Printing is modular. Either install the all-in-one sfs or install just the drivers you need from pets.

Although I agree with you that Saluki does many things right, there's some annoying truth about it: it makes it even harder to build the first 64-bit or ARM Puppy and I'm intentionally ignoring FatDog and Lighthouse since they were not built using Woof.

With the huge amount of manually-built 32-bit packages Saluki has, it will be a nightmare to recompile all of them. I wish you good luck with that, if you want to port it.

I believe in good infrastructure. The right way to build a distribution which supports multiple architectures is having an architecture-independent infrastructure, which is something Puppy doesn't have - it explicitly loads many x86-specific drivers, relies on ancient x86 binaries and doesn't have any means of automated package building.

The right way to build a modular Puppy is starting from scratch, with a new, more efficient skeleton with less code, better documentation and better coding style. All those attempts to port Puppy the way it is are useless.

Time to confess - Puppy is getting old and fat, with big amounts of deprecated code and dependencies._________________My homepageMy GitHub profile

I doubt if "right" could ever be achieved in the distro-building world. Even if both Jemimah and Iguleder came up with perfectly "right" concepts, their time of existence in the "right zone" would be finite i.e. limited to a certain time period. Distros are always evolutionary in their development and always will need to be re-vamped on an on-going basis - no matter how "right" they appear to be at any given point in time.

If you accept this view, then "right" is only a relative term.

There is no distro in existence at present which might be thought of as "right" - Puppy included. I think you can only talk about Puppy being sufficiently "right" for it being able to tank the opposition - even the big Linuces. It's the result that counts - how you got there is actually not really relevant - to the end user at least.

So Jemimah's stuff is sufficiently "right" for all practical purposes as of now, but to ensure that Puppy versions remain fairly and squarely in the "right" zone in the future, contributors and developers such Iguleder will be crucial to Puppy's ability to remain in that zone. Dunno though, maybe it will get to the point where at some stage the best way forward would be to start all over again with a blank sheet of paper.

Look at the classic case of MS Windows. It's now so slow that it's barely usable. The whole thing needs to be rebuilt from scratch for it to have any chance of staying level (technically speaking) with Linux. Think of how "right" Windows once was in say, 1995 or even earlier? Compare that to where it is now. LOL I think they might need Iguleder to go and sort it out for them!_________________Life is too short to spend it in front of a computer

That's a bad design decision. In 5 or 10 years, you'll lose precious time with your family and other truly important things, because you'll be stuck in an infinite, manual compilation loop. Regarding porting - you can spend an entire lifetime trying to port Saluki - say goodbye to ARM and x86_64.

jemimah wrote:

I have no intention of investing the time to do things "right".

Which means you're more than willing to waste your time on tasks that can be automated easily. What a waste!

jemimah wrote:

In 5 or 10 years, I'm sure puppy 6 will be awesome. In the meantime, saluki is here, today.

I can say the same - but with the "doing things right" thing - I built roar-ng for this. And it works great, today, tomorrow and it should work (e.g build packages, distributions and even assist in porting) even in 5 or 10 years from now, because of decisions I took early in its development._________________My homepageMy GitHub profile

Leaving differences of opinion aside....may I ask if you'll be porting to arm at all - using the tools you've built?

I am sorry, but I get complete brainfade at any attempt to understand/absorb or act on your work, though I can sense the essence of it - which is very frustrating, having read and re-read several times....something just doesn't click in my brain.....it makes me feel like nooby, so I leave it to guys like you

In the long-term, maybe I'll make an ARM port, yes. I just don't have the hardware for this

I already ported my distro once, from x86 to x86_64, to test roar-ng and the platform it provides. I had to edit a configuration file (replace "i486" with "x86_64") and wait about 6 hours for the automated compilation of all my packages - that's it.

That's a bad design decision. In 5 or 10 years, you'll lose precious time with your family and other truly important things, because you'll be stuck in an infinite, manual compilation loop. Regarding porting - you can spend an entire lifetime trying to port Saluki - say goodbye to ARM and x86_64.

jemimah wrote:

I have no intention of investing the time to do things "right".

Which means you're more than willing to waste your time on tasks that can be automated easily. What a waste!

jemimah wrote:

In 5 or 10 years, I'm sure puppy 6 will be awesome. In the meantime, saluki is here, today.

I can say the same - but with the "doing things right" thing - I built roar-ng for this. And it works great, today, tomorrow and it should work (e.g build packages, distributions and even assist in porting) even in 5 or 10 years from now, because of decisions I took early in its development.

My investment isn't in Saluki. I will abandon it when I get bored with it. The reason I do Linux development is to keep my brain active because I'm being paid to not work at the moment - and that should be a good thing, not a death sentence. The investment is in the wetware, not the software.

I'm a generalist, not a specialist. My superpower is being able to debug anything and get a lot done in a short time. The flip side of that is that I have a short attention span. I need to work on short projects under tight deadlines or I get bored and lose my momentum.

When I feel like starting over, I'll adapt whatever build system I think is best and have a distro in a few months. Not of the previous time spent is wasted, because it's all still in my head.

Some people are architects and some are field engineers - I am the latter. The world needs both.

The comment on roaring almost sounded like Iguleder is upset that his builder was not used to make Saluki and in my personal opinion, Jemimah had did a great job of coordinating the making of it.

I have tried roaring several times, following instructions, to try to build the default distro it is set to make and failed royally all times to make a resulting ISO that contained the applications.
Call me dumb, but until the average guy can use it, it needs more time in the oven as I do not consider it done yet.
I know other have had success with it and rave about roaring, but whatever I am doing wrong, I am continuing to do even with printing out the build instructions and following them to the letter.

If I more or less hijacked this post, I am truly sorry and my post can be moved or deleted. But I just had to get me feelings on roaring out and my great liking of Saluki!
A person converting from windows would feel at home in it.
One thing that I would like to see though is the bootup process hidden behind a Saluki screen to finish giving it polish.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum