Puppy 4.4 'Woofy'

Message

raffy · #101 Post by **raffy** » Wed 04 Nov 2009, 03:49

Great to have Chromium as alternative browser - feel free to make a pet.. People would test it and possibly enjoy it.

Lobster · #102 Post by **Lobster** » Wed 04 Nov 2009, 04:31

My estimates place the size of chromium compressed at about 15MB.

As I understand it Puppy will come with a stable browser
and other components will be available as modular SFS
So my advice is provide Chrome as both a pet and SFS

This way Chrome will be available in Woofy.
I for one would use it.

Woofy Alpha will be based on Puppy 4.3.1
so it might be worth considering compiling from that devx
and / or documenting the process
for future development

Aitch · #103 Post by **Aitch** » Wed 04 Nov 2009, 12:22

I can't help but feel that calling it Woofy doesn't address the serious need to resolve amigo's post[s] about numbering/naming logical sequence, which I heartily agree with

http://www.murga-linux.com/puppy/viewto ... 362#355362

This unresolved issue will keep coming up until we discuss & decide a better course of action than ignore it & hope it'll go away, IMHO

/mini-rant over

Aitch

raffy · #104 Post by **raffy** » Wed 04 Nov 2009, 13:14

Aitch, a big issue raised there is continuity, which the google code repository would help resolve. Plus, the developers have discussed the recent problems with 4.1.2/4.3.1 in relation to 4.2.1.

The persistent software that amigo described could in fact be the Puppy core,which am sure TZ would address.

Snail · #105 Post by **Snail** » Sat 07 Nov 2009, 11:57

Lobster you note that I am confused and then add to my confusion! I agree with Aitch that your reply doesn't really address Amigo's very valid points.

With the vast majority of software, the latest version number is the one for a new user to get. Sometimes there is a convention that odd and even numbers stand for stable and development versions. Whatever the numbering convention, it is stable and well explained on the software's main page. That makes it much easier for a new user to determine which puppy version will best suit his needs. With Puppy, there isn't even any clarity about which is the main documentation page. There are two wikis and the introductory page in Puppy 430 takes you to the older one. Neither of them gives the slightest clue on why so much effort was going into 214, or even that it was happening.

Surely the Puppy welcome page should point to the latest documentation? Older documentation should have the redirection to the newer documentation at the top rather than at the bottom of the page. There should also be a statement on what, if anything, was still likely to be relevant with the old document. However, it should be the aim to eliminate as much out of date stuff as possible.

Barry was monitoring the 214 work at the same time that he was putting a lot of work into 500, 431 and 218! Why was so much effort going into such ancient version numbers? Surely it would be far better to concentrate on the latest version? The only explanation that I can think of is that the earlier numbers refer to more lightweight versions. Wouldn't it be a lot more user-friendly to give these versions a new number that more accurately reflects their bang up to date status? Why not use something like "4.31Kxx,", where "xx" was the kernel version? There have been "retro" versions before, but the usage seems to have been inconsistent, and kernel numbers have also been used. Of course, it would be useful to use Alpha and Beta version number as well, where relevant. Whatever is used, it needs to be clearly explained on the main page.

I wholeheartedly agree with you that the developers are very smart, much smarter than me. That does not stop me sharing Amigo's concern about potential version control problems. Plenty of other very smart programmers seen to think that version control is very important, especially with collaborative development. I can't help but feel that the current situation is unnecessarily risky. Even if our concerns about reintroducing old bugs into new software were unwarranted, it seems to me that there are obvious problems with the user documentation that are at the least not helped by the unclear version numbering.

Maybe a lot of these problems might be made more tractable if the system was more modular?

As a final comment, I have never been able to see the attraction of calling different versions of any software by fancy names. "Puppy Linux 4.4" tells me that it is more up to date than 4.3 and when 5 comes out it will be an even better Puppy. There is no need for confusing names unless you are after marketing hype. Personally, I find Ubuntu's hype a put-off.

technosaurus · #106 Post by **technosaurus** » Sat 07 Nov 2009, 15:35

I propose 20XX.X and 20XX.X legacy for the continuation of 4.X (current) and 2.X (LTS) respectively. Any seconds?

#107 Post by **Pizzasgood** » Sat 07 Nov 2009, 19:00

It makes sense for the 2.x series to remain numbered 2.x. It is fundamentally different from the 4.x series. Numbering it anything else would be even more confusing than having two series of the same project. This way, it is clear that they are different, so there is no issue of people thinking that the 2.x based Puppy is a sequel to a 4.x based Puppy, and then the next 4.x based Puppy is the sequel to that 2.x based Puppy. That would be madness. 2.x is 2.x, and 4.x is 4.x.

If people can't figure it out, then we just need better explanations in prominent places.

If they still can't figure it out even after good clear explanations are posted prominently, then they aren't qualified to be changing their OS in the first place, so just don't worry about them.

The only other sane option would be to classify the other series of Puppies under their own names, rather than just "Puppy Linux", so that they can use whatever version numbers they want/need without worrying about confusing people. Which sounds like what Technosaurus has in mind above.

I propose 20XX.X and 20XX.X legacy for the continuation of 4.X (current) and 2.X (LTS) respectively. Any seconds?

You mean numbered after the current year? If so, then yeah, that sounds good. Helps to pin down just how old any given release is. Just so long as it's made clear that the legacy release is more than a trivial modification of the normal release to fit old hardware. Otherwise people might try treating them interchangeably with bad results.

Aitch · #108 Post by **Aitch** » Sat 07 Nov 2009, 19:30

raffy/ITAmember

raffy wrote:Great to have Chromium as alternative browser - feel free to make a pet.. People would test it and possibly enjoy it.

There is this Chrome/Firefox/modded 'Firedog' by sc0ttman

http://www.murga-linux.com/puppy/viewtopic.php?t=48254

Available as .pet/SHS, I believe

sc0ttman wrote:I wanna see Firedog used as the default browser in Puppy. Discuss!

Just a messenger....haven't tried it....yet, still using ttuuxxx's Firepup, but certainly looks like a possible contender

Techno?

Re: numbering, I agree with PG - especially after ttuuxxx's efforts have generated so much google traffic as 214XX

more discussion/explanation needed, please

Aitch

#109 Post by **ttuuxxx** » Sat 07 Nov 2009, 23:16

Well 2.14X is staying 2.14X and then I have 2.20 on the back burner, and also Barry called Upup karmic upup-432.iso I'm building a Karmic right now and I was thinking of calling it upup-444.iso hmmm probably a bad Idea since this is 4.4 . really woof is suppose to be 5 series, I don't see why its called 4 series.
ttuuxxx

#110 Post by **ttuuxxx** » Sat 07 Nov 2009, 23:50

I change the Karmic build to 4.50 so that should work fine now

ttuuxxx

#111 Post by **Pizzasgood** » Sun 08 Nov 2009, 02:15

Oh. I didn't realize we had that many different projects going on at once. Yeah, then the first half of my post above doesn't help. The second option is the way to go.

We just need to stop focusing so much on the version number. Give each series a name, and do not assume that the version numbers in one series have anything to do with the version numbers in another series.

For example, do you automatically assume that MathCad 7.0 is newer than Firefox 3.0?

Karmic-Puppy should not care what version Puppy is about to use. Karmic-Puppy should just be whatever version Karmic-Puppy wants to be. If you want people to know which Puppy it was based on, just tell them as a separate statement, e.g. "This is Karmic-Puppy 5.42, based on Puppy 4.3". Or maybe use a convention like this:

Karmic-Puppy 5.24 p4.3

(I think that's cumbersome though, especially for puplets based on puplets based on puplets.)

ITAmember · #112 Post by **ITAmember** » Mon 09 Nov 2009, 00:33

The current linux versions of google chrome use SSE2 instructions which aren't supported on P3 and older and AMD athalon and older. I guess chrome's a no go.

But google says the the real releases won't use SSE2 and it's for a temporary fix. Maybe in time...

ITAmember · #113 Post by **ITAmember** » Thu 12 Nov 2009, 17:56

I'm testing out the webkit rendering engine with midori and after about a week I finally got everything built. Now I'm working on packaging it all up. But in the meantime I run the v8 javascript benchmark and here's my results on a 2.0 GHz P4 (higher is better)

Midori 0.20.0 + Webkit r50616:
926

SeaMonkey 1.1.11:
38.8

Midori blows SeaMonkey out of the water. Every other benchmark I've seen has webkit based browsers (Safari) ahead of both firefox and chrome. I think we have a speed win.

technosaurus · #114 Post by **technosaurus** » Fri 13 Nov 2009, 01:31

Thanks, sounds great - I actually had Midori and webkitgtk in my src directory ready to compile. Have you tested it with the flash and gxine plugins?

ITAmember · #115 Post by **ITAmember** » Fri 13 Nov 2009, 02:53

works with flash but it's kind of buggy. (webkit is to blame) My webkit version (50616) only gets a 93/100 on the acid3 test but webkit uploads new versions every day.

I think I'm going to try to make some nightly builds for puppy. Haven't tried gxine plugins yet, I'll give that a shot. On the midori website they say it has support for all netscape (and hence firefox) plugins, so we should be good to go.

The only problem is it's extremely unstable. I'm guessing it'swebkit because I keep getting all these x server errors running from the console.

I'm waiting on MU to transfer my pet uploads from ftp.servage.net to dotpups.de.

ITAmember · #116 Post by **ITAmember** » Fri 13 Nov 2009, 03:13

I had to update glib, pango, cairo because of dependency issues. I get lots of gtk related errors when I run from the command line so I'm going to update that next and see if that helps with stability.

technosaurus · #117 Post by **technosaurus** » Fri 13 Nov 2009, 03:36

try barry's 2.18.3 on ibiblio or you will have to compile it twice to prevent the insert key bug

ITAmember · #118 Post by **ITAmember** » Fri 13 Nov 2009, 22:39

I installed the libs pet and the dev pet but now I get compile errors. I attached the redirected stderr if you want to take a look at it, reverting back to the gtk included in puppy 4.1.2.

Whoops, look like I forgot the attachment, here it is.

ITAmember · #119 Post by **ITAmember** » Fri 13 Nov 2009, 23:33

For you guys that are watching replies...

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

Puppy 4.4 'Woofy'

Chromium

continuity

Version Numbering and Control