tronkel wrote:All this discussion about voting worries me. Why vote at all?
...
What the Puppy project needs, is someone to whom all major decisions about what the OS build consists of, can be left. This would be the same guy who also does the innovation, the programming and the building. He would be described as Mr Puppy - the buck stops with him. Forget committees and voting.
Where this chief builder of Puppy can be found is not yet clear. Hopefully he can be found somewhere somehow.
Yup voting has all sorts of problems.
What are the criteria for being allowed to vote?
Should MU receive the same voting rights as joenewbie?
Who do you trust as returning officer?
What is the mechanism for voting?
Does this mechanism have a cost that causes a barrier to inclusion?
None of these consider the problems of managing a project whose direction is determined by the popular vote.
Considering that you don't have a 'chief builder' in mind I wouldn't fancy holdng my breath waiting for one to turn up that matches your criteria and wants the job.
What should puppy do next?ttuuxxx wrote:The problem in the past with Barry for myself was, icons
We clearly have very different views on what puppy's priorities should be, and that is fine.
As puppy has progressed it has gradually started to include the small connecting features of daemons, services, widgets, status monitors and other tools that eat your cpu cycles on both windows and many major linux distros. One of the reasons that early puppies ran well on minimal hardware was because they passed responsibility for these functions onto the end user.
If you wanted to mount a partiton, then you had to start MUT and do it yourself
If you wanted to know the state of your battery then you had to load the right models and cat /proc/acpi/batteryBAT0/state
I wonder what difference these things make to the minimum
effective hardware.
How much cpu do you save by having a black desktop background?
There is a compromise here between having a distro which is highly efficient but is hard to use unless you have a good level of understanding and between having one that 'just works' for someone who is clueless. I do appreciate that the expert can always find ways of turning this stuff off but often it is less effort to stump up for a couple of hundred extra Hz of cpu cycles.
Does anyone fancy building a "service manager" to control CUPS, pup_event, volume control, freemem, blinky, battery monitor, ROX pinboard, xload.
A Different Model
How about this? Barry gives the rights to use the puppy name to a number of people who have been releasing genuinely innovative (at the fundamental level) puplets for a while. Each of these people can release a version whenever they like. The people I have in the back of my mind would be capable of agreeing version numbers (names) amongst themselves. They have previously demonstrated the ability to release high quality supported puplets. These people have previously incororated cutting edge bits of other peoples's work into their own releases. There would be no pressure on them to release versions on any paticular timescale.
This would in effect lead to a number of cross-fertilising forks that were all allowed to use the official puppy name (if they wanted to). I suspect that these people will just do their own thing anyway, they have a history forging frontiers one their own regardless I would just like to do my best to support them in their efforts.
playdayz wrote:Puppy was/is Barry's project and it was/is his perrogative to do anything he wanted/wants to do with it. I believe strongly that nobody else was owed any choice in the matter of what he included or didn't iinclude.
I agree strongly, but I don't really want to put a dfferent person in a similar postion with someone else's baby.