Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 22 Oct 2014, 04:48
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
Saluki, Puppy Remastered
Moderators: Flash, Ian, JohnMurga
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 5 of 24 Posts_count   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, ..., 22, 23, 24 Next
Author Message
ttuuxxx


Joined: 05 May 2007
Posts: 10821
Location: Ontario Canada,Sydney Australia

PostPosted: Fri 10 Sep 2010, 17:24    Post_subject:  

technosaurus If the #1 most popular distro Ubuntu and then you have Debian, uses i386 then I think we should go that way. Plus new products like my surfboard pc I purchased like 2 weeks ago uses vortex86 http://murga-linux.com/puppy/viewtopic.php?t=59466
the vortex86 cpu is going to expanded into other pc's also, they already have a ipad clone version that uses it also, plus the edubook.
When I made up the VLC package in 4.0, The resources were way lower than Mplayer and Gxine. I built it as i386, where as Barry was building as i486. Don't forget the vlc had sdl and wxgtk , Here's a couple of user quotes from the VLC 8.6h page


Quote:
Playing 'Lonesome Day Blues' from MP3 file on the hard disk. This notepad is a Toshiba Portege 3110CT with 128mb ram and a 300mhz processor (a PII).

Did comparison of gzine (with visualisation turned off) and VLC:

Gxine came out at 124% mem use and 38% CPU
VLC looked very good with 86% mem and 3% (sometimes 2%!) CPU usage. Unbelievable?

with some mpg video off a hard drive gxine 130%mem 98%cpu and VLC 112%mem and 89%cpu - but have to say the display at that point from VLC was roughly 3 times the size which makes a difference. plus not jerky like gxine.

VLC looks much better too Smile


I'm not too sure about your statement "Some areas where a higher architecture would be acceptable are encoders/decoders" The above is proof supporting the lower i386. Also The vlc package is double the Gxine size but takes way less resources, actually there were a few post that some people could play dvd's on there low spec pc's where they couldn't on Gxine because gxine was choppy.
ttuuxxx

_________________
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games Smile
Back to top
View user's profile Send_private_message Visit_website 
ttuuxxx


Joined: 05 May 2007
Posts: 10821
Location: Ontario Canada,Sydney Australia

PostPosted: Fri 10 Sep 2010, 17:38    Post_subject:  

Lets stay focussed on what puppy is and what it isn't, Puppy isn't Arch Linux -i686, Puppy is made for breathing new life into older pc's and also has supports bleeding edge technologies. But we still have many users using i486 pc's. heck most of my pc's other than the the surfboard are i686 dual-core, but I'm pretty much against the extra kernel bloat for the extra cores that have to be included by default for a minimal increase in speed that we have to force on all users to which most don't have more than 1 core cpu's.
ttuuxxx

_________________
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games Smile
Back to top
View user's profile Send_private_message Visit_website 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Fri 10 Sep 2010, 21:18    Post_subject:  

Well is the mission to support just old computers, or all underpowered computers? I don't see how we get around either making compromises - or making multiple versions.
Back to top
View user's profile Send_private_message Visit_website 
ttuuxxx


Joined: 05 May 2007
Posts: 10821
Location: Ontario Canada,Sydney Australia

PostPosted: Fri 10 Sep 2010, 21:39    Post_subject:  

jemimah wrote:
Well is the mission to support just old computers, or all underpowered computers? I don't see how we get around either making compromises - or making multiple versions.


naaa jemimah Puppy is usually well rounded as know, and I don't think its time to stop supporting older hardware, and some things keep bloating puppy up, like gnome libs or big fat kernels, larger Xorg versions. etc If we don't get handle on things and we let things fly like from 4.0 to 5.0 with a 50% increase in size. and keep on that path then puppy 6 should be 200MB, lol I know it won't ever be that bad maybe puppy 10 Smile
Multiple versions is a pain, I think we should build puppy as i386, I only compile as i386 and do pretty well Smile Or stick with Barry's default i486 but I'll still compile as i386 only. But noway should we go to 586 or 686, its not the time for that. We still get lots of users recycling older pc/laptops. There are lots of other distros who can handle 586,686 etc
My first pick is i386, i486 as second and last.
ttuuxxx

_________________
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games Smile
Back to top
View user's profile Send_private_message Visit_website 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Fri 10 Sep 2010, 22:05    Post_subject:  

ttuuxxx wrote:

naaa jemimah Puppy is usually well rounded as know, and I don't think its time to stop supporting older hardware, and some things keep bloating puppy up, like gnome libs or big fat kernels, larger Xorg versions. etc If we don't get handle on things and we let things fly like from 4.0 to 5.0


The latest crop of netbooks cannot be made to work on anything but a very recent Xorg and kernel. I won't argue over the compile arch - but if you expect to support more hardware over time - it's inevitable that the number and size of the drivers you need will grow. We can of course reduce the size by removing support for very old hardware. Wink
Back to top
View user's profile Send_private_message Visit_website 
ttuuxxx


Joined: 05 May 2007
Posts: 10821
Location: Ontario Canada,Sydney Australia

PostPosted: Fri 10 Sep 2010, 22:17    Post_subject:  

jemimah wrote:
ttuuxxx wrote:

naaa jemimah Puppy is usually well rounded as know, and I don't think its time to stop supporting older hardware, and some things keep bloating puppy up, like gnome libs or big fat kernels, larger Xorg versions. etc If we don't get handle on things and we let things fly like from 4.0 to 5.0


The latest crop of netbooks cannot be made to work on anything but a very recent Xorg and kernel. I won't argue over the compile arch - but if you expect to support more hardware over time - it's inevitable that the number and size of the drivers you need will grow. We can of course reduce the size by removing support for very old hardware. Wink


I agree with Xorg and kernel, but I guess it could be reduced with only 1 cpu, and maybe a bit older kernel, There was something I read where the latest kernels have been growing 1000 lines of code a day!!!.
ttuuxxx

_________________
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games Smile
Back to top
View user's profile Send_private_message Visit_website 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Fri 10 Sep 2010, 22:19    Post_subject:  

As far as getting off topic I would rather have this discussion during the planning phase and not have to rebuild everything later (ttuuxxx you've worked construction right - What's the saying? an hour during planning can save 10 later on - something like that)

ttuuxxx wrote:
If the #1 most popular distro Ubuntu and then you have Debian, uses i386 then I think we should go that way. Plus new products like my surfboard pc I purchased like 2 weeks ago uses vortex86


I would agree at least for the underlying libraries except that:
"glibc no longer supports 386" ... are they both using eglibc now?
http://www.linuxfromscratch.org/lfs/view/6.5/chapter05/glibc.html

the surfboard is 586 compatible (all vortex86 and dx and mx are - not the sx though)
cpufamily is 5 (aka 586) for all except the SX
flags are: fpu tsc cx8 (mmx only on the mx)

The SX is cpufamily 4 with no flags at all, but is generally targeted toward industrial applications.

My point is that the pentium has been around for over 15 years and most 486 computers will have hardware that is not supported in newer kernels (which glibc uses to compile against) so there should be a separate codebase to support 486 and below based on the older stable 2.6.16.62 or similar kernel and compiled with 486 and fpu emulation or use an older/different libc with 386 and fpu emulation. This should not be a problem to maintain if we use a build process as bigbass has mentioned.

regarding fpu and mmx not speeding up things: this is a result of the fpu and mmx sharing the same registers (poor design which causes one to flush the other and speed gains are lost, due partly to limitations of manufacturing at the time but mostly for win95/nt compatibility) combined with using libraries and programs written by different developers and/or just from being compiled for different architectures. This explains why people complain about a certain build being slower with -march=i686 - the underlying libraries are using the fpu and flushing the mmx from registers because the defined the fpu section of code rather than the mmx section when they were compiled.

To minimize this effect it is maybe better to set the build architecture to the maximum supported by the minimum desired platform specs from the get go and realize that changing them to a higher architecture is unlikely to be beneficial (with the exception of ffmpeg and programs using liboil like gstreamer which have workarounds and highly benefit from mmx for a continuous process like video encoding)

Perhaps a good compromise default config could be to use 386 with fpu emulation for the underlying libraries for the size benefit and so that there is no interference when building programs or specific libraries on top of them that can benefit from mmx and would never run comfortably on a 486 anyways.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send_private_message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Fri 10 Sep 2010, 22:38    Post_subject:  

ttuuxxx wrote:


I agree with Xorg and kernel, but I guess it could be reduced with only 1 cpu, and maybe a bit older kernel, There was something I read where the latest kernels have been growing 1000 lines of code a day!!!.
ttuuxxx


My netbook is about a year old and the first kernel that really worked well on it was 2.6.33 (before that the drivers are nonexistant or extremely buggy). Removing hyper-threading support would be also be deal-breaker for most netbook owners (Plus I doubt it really would reduce the size of the kernel significantly).

I'm perfectly happy to keep making netbook forks - but my uneducated guess is that the netbook market is larger than the ancient computer market or will be soon as prices continue to drop. Moving forward seems important too!
Back to top
View user's profile Send_private_message Visit_website 
Lobster
Official Crustacean


Joined: 04 May 2005
Posts: 15117
Location: Paradox Realm

PostPosted: Fri 10 Sep 2010, 23:25    Post_subject:  

I have tried running Puppy on an actual 486 and just yesterday on a Pentium II with 170MB ram.

Running on the 486 was an exercise in futility, more problems than solutions.
Never again.

The pentium II (running Lucid) would be acceptable to a lot of users. When Barry moved up to 486 compatibility compiling of the kernel that was a conservative move. If Ttuuxxx compiles programs for 386 that still makes sense as it is a reliable code base.

_________________
Puppy WIKI
Back to top
View user's profile Send_private_message Visit_website 
ttuuxxx


Joined: 05 May 2007
Posts: 10821
Location: Ontario Canada,Sydney Australia

PostPosted: Sat 11 Sep 2010, 00:20    Post_subject:  

jemimah wrote:
ttuuxxx wrote:


I agree with Xorg and kernel, but I guess it could be reduced with only 1 cpu, and maybe a bit older kernel, There was something I read where the latest kernels have been growing 1000 lines of code a day!!!.
ttuuxxx


My netbook is about a year old and the first kernel that really worked well on it was 2.6.33 (before that the drivers are nonexistant or extremely buggy). Removing hyper-threading support would be also be deal-breaker for most netbook owners (Plus I doubt it really would reduce the size of the kernel significantly).

I'm perfectly happy to keep making netbook forks - but my uneducated guess is that the netbook market is larger than the ancient computer market or will be soon as prices continue to drop. Moving forward seems important too!


The difference is posted at ibiblio linux_kernel-2.6.29.6-tickless_smp-2-p4.pet <--23MB
linux_kernel-2.6.30.5-tickless_smp-7-p4.pet <--35MB
at one time 12MB compressed in puppy meant a lot, heck back a couple years ago we used to try to save 30kb and less on a app. Now we toss 12MB compressed out the door and release very large versions.
jemimah you do produce a great release and probably it would be in puppies main interest to have a specific version for netbooks/laptops. Would be nice if the kernel-2.6.29.6 was patched and only 1MB or less was added for what you need and then we could have both in one release.
ttuuxxx

http://distro.ibiblio.org/pub/linux/distributions/puppylinux/pet_packages-woof/

_________________
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games Smile
Back to top
View user's profile Send_private_message Visit_website 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Sat 11 Sep 2010, 00:29    Post_subject:  

Lobster wrote:
Running on the 486 was an exercise in futility, more problems than solutions.
It doesn't have to be though - its just the wrong package selection and configuration. 486 systems should have most background processes turned off by default, a different package selection (predominantly gtk1 and/or fltk) and the install should default to full instead of frugal. Amigo has quite a large collection of gtk1 apps that I have built. For your next 486 foray try Pup'nGo with amigo's gtk1 patched rox-1.2.2 on a full install.
_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send_private_message 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Sat 11 Sep 2010, 00:36    Post_subject:  

ttuuxxx wrote:

The difference is posted at ibiblio linux_kernel-2.6.29.6-tickless_smp-2-p4.pet <--23MB
linux_kernel-2.6.30.5-tickless_smp-7-p4.pet <--35MB
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/pet_packages-woof/

With the zdrv-cutter the size of the kernel package due to extra modules is less relevant since they don't need to be installed if we have the zdrv-cutter as an installation option. Does it actually make the modules themselves significantly bigger? ... because I think Barry referenced building extra modules for some kernels and not for others.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send_private_message 
Patriot


Joined: 15 Jan 2009
Posts: 734

PostPosted: Sat 11 Sep 2010, 04:52    Post_subject:  

Hmmm .....

Just browsing thru ...

technosaurus wrote:
"Some areas where a higher architecture would be acceptable are encoders/decoders"


This is an area which I agree with you. There are 2 spectrum ends of en/decoders. The lower end and the higher end. The lower ends like mp3s are already highly optimized to benefit from an fpu and that is not even mmx. A i486dx-66 can do mp3s without choking on itself. The higher ends and more complicated pure software en/decoders like h264 (which is gaining more and more prominence each day) needs at least a p3-800 with fast sub-systems to barely scrape through doing 480p. A properly optimized and efficient decoders with proper arch support works best in this area. (I still haven't found a decoder that can beat CoreAVC. Heck, it's still the fastest even when wrapper-wrapped in linux).

technosaurus wrote:
I would agree at least for the underlying libraries except that:
"glibc no longer supports 386" ... are they both using eglibc now?
http://www.linuxfromscratch.org/lfs/view/6.5/chapter05/glibc.html


Laughing I just have to dig up something that I stumbled upon sometime ago that basically says, "one needs i486 emulation in kernel to run on actual i386 hardware" ... please read at http://people.debian.org/~joey/pr/3.1/i386.html

Frankly, I'd go for a generic i586 kernel meself and do a max'ed out fully optimized custom machine tuned kernel whenever necessary. Sure, I like the old k2.6.21.7 for the simple reason of being surrounded by antique/classic hardwares. Yeah, I still have a i386DX-20mhz board with 8MB (70ns) FP RAM SIMMs (that's 70nanoseconds Fast Page RAM Single Inline Memory Modules for those wondering). Sure, it still boots up fine but no one's gonna make me boot linux on it (unless you're paying me for a demo, haha). Yeah, I also have a couple i486DX2-66mhz board with 16MB (60ns) EDO RAM ... One of it is running Freesco right now ... Puppy? Don't think so, it's gonna choke-n-sputter if I put puppy on it ...

So, I guess that the most logical and rational base hardware suitable for puppy testing is a pentium 133 with at least 64MB RAM. Yeah, I have in my collection the complete range from iP75 right up to iP233mmx ... But I'd prefer to run at least a Cyrix mII-300 or a K6-2/400 with 128MB RAM for base h/w puppy testing ...

I was interested with the xcore86 SoC when edubook came out ... but not anymore after it became clear to me why it's sluggish even at 1Ghz. A similar ARM SoC at 1Ghz would be running circles around it ...

Anyway, techno, what's the point of "arguing" about which arch to base on? I'm sure you're more than qualified to decide the cut-off point for h/w support (just don't forget to set a reasonable acpi bios cut-off date, ok?). Stretching support for older hardware is fine but there should be a limit to it. All those ancient/antique/classic hardwares have their places but it doesn't seem to make sense to me to force the latest and greatest linux (apps/kernel) down their throat. I'm happy to plonk in a k2.6.21.7 on these old classics and I have no qualms doing a custom config kernel, libs and apps if there's a need for the latest h/w.

techno, you just do what you think and feel is right, whether its i486, i586, tickless, smp, nosmp, hyperthreading or whatever. However, if I may make a suggestion, offering a couple of official kernel to cater for uniproc/smp/ht can be beneficial in the long run ...


Rgds
Back to top
View user's profile Send_private_message 
ttuuxxx


Joined: 05 May 2007
Posts: 10821
Location: Ontario Canada,Sydney Australia

PostPosted: Sat 11 Sep 2010, 07:35    Post_subject:  

ok I'll make it very simple, puppy 5 was bloated in my eyes and I never downloaded it, If puppy 6 goes beyond i486, well that will make 2 versions I won't participate in. There won't be a third, I'll either stick with 2.14X or move on to another distro, Or start one up.
ttuuxxx

_________________
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games Smile
Back to top
View user's profile Send_private_message Visit_website 
Iguleder


Joined: 11 Aug 2009
Posts: 1923
Location: Israel, somewhere in the beautiful desert

PostPosted: Sat 11 Sep 2010, 10:45    Post_subject:  

We can't have support for both older hardware and newer hardware. I'm on jemimah's side Smile

SMP is a MUST for all netbooks and all PCs since ... 2006-7 or so. You can't tell people "you spent all your precious money on a PC with 6 cores and hyperthreading, so you've got 12 cores, but I let you use only one" ... give the user a free copy of Windows 98 in a DVD case with a red ribbon and forget it Laughing

The only way to go is 2 "main" puppies or the way things work now, one main Puppy for newer hardware and new packages and community puplets for those who don't get along with it.

i386 is a very bad choice because many packages don't know it, notably glibc. i486 or i686 are more suitable. I use i486 for my own distro and don't see any drop in performance.

Also, a SMP kernel is a must. Two menu entries, one with SMP and another with nosmp pretty much solve this problem. Also, there's kexec, we can compile two kernels, one minimal kernel with SMP support that starts the normal kernel and adds nosmp if you have only one processor. Just an idea.

A top ten distro can't be some legacy operating system built around packages dating back to 2005/6/7. Newer hardware like touch screens and netbook simply won't work. Having two branches, one with the latest and greatest packages and another with old packages is the only way to go.

Of course, some may say they want a GTK 1 or FLTK Puppy, but let's face it: that thing can't be the official Puppy. We're in 2010. Time to face it and drop i386 support and support for all hardware that can't boot any mini-distro of the current generation.

I say it's time to move on to i586 or i686 or i486 with multimedia packages for i686. Newest X, newest kernel, newest GTK, newest applications except some rollbacks where needed. Superb hardware support for average computers, laptops and netbooks. Support for old hardware is a good feature, but once ancient hardware support harms the user experience under average hardware, it's better to give up on it. Completely. No dial-up, no i386, no legacy packages from late 90's or early 2000's.

_________________
My homepage
Back to top
View user's profile Send_private_message Visit_website MSNM 
ICQ 
Display_posts:   Sort by:   
Page 5 of 24 Posts_count   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, ..., 22, 23, 24 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1369s ][ Queries: 12 (0.0184s) ][ GZIP on ]