But a big part of the reason I switched from Xubuntu to Puppy was to get off the "update treadmill"

I reckon there are folks building parts for Ubuntu (and everything else including cars and clothes) who say "that's finished - what'll we do next. OH, lets make another new version or else we'll have nothing to do"

Of course there is a need, from time to time, to bring out a new version when an error is discovered.

But, apart from that, I don't think we should be frogmarched into new versions.

Let the developers of new versions advertise the improvements and then I can decide if they are of any value to me. But don't include them automatically.

But, apart from that, I don't think we should be frogmarched into new versions.

That's an odd phrase. No one is ever forced into a new version. Your old version will not spontaneously self-destruct when the new one appears.

But there are several good reasons for building new Puppies. New kernels mean support for new hardware. If you buy a new wifi adapter and try to run it in Puppy 4, chances are slim that it will work OOTB.

Third-party software developers often build their projects on the latest mainstream Linux platform. In order that those apps also run in Puppy, Puppy has to keep up with the mainstream.

If all your stuff runs fine in Puppy X, that's great. You have no need to upgrade. But that's not true for everyone. If some community members had their way, we would still be stuck on Puppy 2.

But, apart from that, I don't think we should be frogmarched into new versions.

That's an odd phrase. No one is ever forced into a new version. Your old version will not spontaneously self-destruct when the new one appears.

What you say is technically correct but in practice, with Xubuntu for example, there are updates/upgrades of something or other every few days. There is never an explanation of what the changes will be so that you could make an informed decision. And if you ignore the updates for a month or so there are so many that the only practical option is either to select them all or get further out of date.

I understand completely what you say about new hardware - but why not design the system so there is a simple option to upgrade the piece you need only - for example upgrade the kernel without needing to upgrade LibreOffice and vice versa.

Or build the driver on the kernel in use...that easy option seems to get forgotten...not like you buy a new dongle every week is it.

Well the main complaint would be that the masses would be starved of their weekly dose of freebies from the FOSS world....there would be a riot.

I find there is more software pressure...centred around the web.... most other stuff just does the job and keeps doing it.... physics and such.

Puppy 2 methods perhaps...that would be worth hanging onto...just keep the software happy with updates and yes even microsoft tell you what's in the updates if you want to know without jumping through too many hoops...which is nice because i turn them off and only have those really needed...which is a surprisingly small amount.

Fortunately I have never subjected myself to the mainstrean distro contant update boogie.... it would seem too much like vista and that would be the end of it. Plus often its not just updates but 'lets change half the system basics and breaks everything from 2 weeks ago.... unprofessional stuff unfortunately which keeps potential mainstream users away. Check what versions of linux your pet servers are running and you may notice that they are surprisingly conservative in what kernels and userspace they are running...because the want to KEEP running.

One last thing.... having new features to offer simply gets more perceived brownie points than bug fixing...the latter is classed as dull far too often. Not the way of true engineers....

new device appears...build driver... OR configure new kernel, build, adapt initrd to modules and latest quirks, alter system to deal with latest quirks, update iso and start all over again with bug fixing...sounds fun.

Perhaps it is easier from a users point of view to build a one off driver but I am sure some of the above would need effort from a dev or two.
Perhaps also I have found driver building to take little longer than the time it takes to unpack the source...especially when working with a familiar kernel.

Also another perhaps is I do notice that since microsoft rarely alter their kernels, driver maintainance is a relatively simple task which the venders themselves happily undertake. Last big headache was the introduction of the vista and newer model....still NT just additional security stuff to handle.

Back to the first point.... every new puppy means tempestuous has to start all over again with another... drivers for ... thread...along with the change of toolkit and familiarization required with every kernel change.

Constant change is not necessarily a good breeding ground for creativity and progress.

At some point there will be...lucid did not have one initially...... or is the current idea to obsolete a release every month which sort of brings us back to the constant update cycle which the op referred to.

In the case of puppy a kernel change is not exactly as straight forward as it is in say ubuntu either.

I also curious how its now become the case that a set of drivers are associated with a particular kernel ... ...for example I changed alsa on puppy 4.12.... was a quick switch and made a netbook happy....kernel remained the same keeping everything else happy. Though they need kernel approval many drivers are developed independently of the kernel and a (kernel) build is simply contains a snapshot. Your pet wifi dongle might have a fix for it 2 days after you implant the latest (kernel).

If the kernel is to become that monolithic then puppy had better find a better way of changing it to keep up.

What about stability.... you might get a new driver but is this weeks kernel a stable one since its trying out new (kernel) features?
Some kernel releases I had used had bad problems with wifi and NFS for example only cured by going back a release or three.

For the most part, Puppy has not changed much.
The basic desktop appearance and installed programs has been about the same, for some time.

The hardware support issue is always going to be a driving force for change.

What now seems to be driving Puppy version release is two things.
People wanting programs to have more and more features.
Bug fixes.

As these Puppy core programs get added features/bug fixes.
It seems to be the most common solution is to just release a new version of Puppy, with the most recent core programs.

Tahrpup 6.0 released using the latest programs in Woof CE.
Some of those programs have now been changed by adding new features/bug fixes.
So, what does the developer of Tahrpup do?
If bugs are found in Tahrpup what does the developer do?

I can state for sure, that without the ability to update Tahrpup, with bug fixes and program improvements/bug fixes.
Tahrpup would not be as good a Puppy version as it now is.

Even Tahrpup 6.0 reached a point at which the amount of bug fixes and program improvements required a new release of the Tahrpup iso.
If for no other reason, so that a new user would get a version fully updated with the latest bug fixes, out of the box._________________I have found, in trying to help people, that the things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected

rcrsn51 is right about drivers. Modern 3.x kernels seem to keep pace with the latest devices, and there's little need to provide third-party drivers any more.
Unfortunately as new drivers appear with new kernel releases, they often require new firmware - that's another can of worms.

For example, Slacko 5.7.0 gained the brcm wifi drivers, but the corresponding firmware was not added.Last edited by tempestuous on Mon 26 Jan 2015, 08:20; edited 1 time in total

But a big part of the reason I switched from Xubuntu to Puppy was to get off the "update treadmill"

I reckon there are folks building parts for Ubuntu (and everything else including cars and clothes) who say "that's finished - what'll we do next. OH, lets make another new version or else we'll have nothing to do"

Of course there is a need, from time to time, to bring out a new version when an error is discovered.

But, apart from that, I don't think we should be frogmarched into new versions.

Let the developers of new versions advertise the improvements and then I can decide if they are of any value to me. But don't include them automatically.

...R

Thank you for your thoughts Robin2 I also agree that using Puppy has stopped me having to be stuck in the update treadmill.

There are great Pups like Lucid which still have life left in them yet.

Mikeb has a good point that drivers can be written for these older kernels eg. RTL8192CU works really well in 412 and 4.31 thanks to Mr Tempestuous and others.

Everyone has Pups which suit them for me its Lucid, 3.01 and 4.12/4.21/4.31 JRB Version. I even like Carolite 1.2.

There is a place I suppose for old and new but even kernel 3
versions will need extra driver threads one day or do we simply throw them away. Sorry I'm personally not joining the treadmill.

Modern 3.x kernels seem to keep pace with the latest devices, and there's little need to provide third-party drivers any more.

Could that be in part due to a slow down in the appearance of new hardware with as you say the exception of the firmware requirements. There was after all the boom associated with the vista era which was intented to obsolete all the XP and older gear and associated systems and in linux land keeping up with this weeks hardware baby was indeed a challenge?
The stability comment still stands in my book...sometimes new kernel features can cause problems...which is what new releases are about rather than new /updated drivers..that just happens because they happen to be the versions around at build/release time.

Well if you are having an easier time then thats a bonus tempestuous

Quote:

I wonder would it be possible to package Puppy as a pair of SFS files - one which has the kernel and other core stuff and the other with the applications.

I did this with a slax kernel change ...was trying lucid with slax 6...and yes made sense...for puppy though (and slax) as it stands you also have to have the initrd as a matching pair...not the worst deal I think...otherwise all initrd drivers need building in or use perhaps the humongous initrd approach.
Also as it is that extra sfs would not be handled very gracefully....some script changes needed but again no biggie. After all getting the layering correct is only a minor adjustment as is loading more than 6 sfs.

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