The Yad problem`s probably something with my work PC. I`ll have to try it on one of my others.
"yad --file-selection" is the same as "yad --file". It gives the file dialog not the directory dialog.
I`ve seen some of the parsing code you show, it can help for sure. Bash is so temper mental.
pBurn; I`ve always thought a progress bar would be better than the text output.
Something about the CD load display I didn`t quite like either.
It`s been awhile since I`ve used it so I can`t remember what it was.
I`ll be burning a few in the next week, so I`ll post back and let you know.
.
A custom File & Folder selector.
Hmm just to check are we talking about
yad --file-selection --directory
the directory chooser option?
By the way yad --file give me an unknown option message.
Bash ..one version ignores the trailing '|' in my example, another does not...fun stuff.
My pburn was forked at around version 1.0 so bears little resemblance.
Yes it is a busy log...perhaps it should be warnings/errors only plus a progress bar...
mike
yad --file-selection --directory
the directory chooser option?
By the way yad --file give me an unknown option message.
Bash ..one version ignores the trailing '|' in my example, another does not...fun stuff.
My pburn was forked at around version 1.0 so bears little resemblance.
Yes it is a busy log...perhaps it should be warnings/errors only plus a progress bar...
mike
Hummm. Oddly that does work.! Thanks again for the help, now I think yad.filer.dlg is done!
But the help doesn`t indicate that`s how it works. ( What a surprise...)
I was thinking Bash is portable, but then again... So how to fix that?
pBurn: As usual, I suggest a tabbed interface, they`re most easily accessible.
The front panel is the burn control and progress, the back panel is log display.
Most CLI utilities ( vobcopy, etc. ) seem to use 2> for outputing progress.
But the help doesn`t indicate that`s how it works. ( What a surprise...)
Code: Select all
File selection options:
--file Display file selection dialog
--file-selection Alias for --file
--filename=FILENAME Set the filename
--multiple Allow multiple files to be selected
--directory Activate directory-only selection
--save Activate save mode
--separator=SEPARATOR Set output separator character
--confirm-overwrite=[TEXT] Confirm file selection if filename already exists
--file-filter=NAME | PATTERN1 PATTERN2 ... Sets a filename filterpBurn: As usual, I suggest a tabbed interface, they`re most easily accessible.
The front panel is the burn control and progress, the back panel is log display.
Most CLI utilities ( vobcopy, etc. ) seem to use 2> for outputing progress.
Code: Select all
vobcopy ( args.) > /tmp/vobcopy.info
percent=`cat /tmp/vobcopy.info |sed '$!d;s#^.*(##;s#).*$##'`hmm yes I noticed that with a quick test of cdrecord... oh well .Most CLI utilities ( vobcopy, etc. ) seem to use 2> for outputing progress.
The help may slightly lie at times
--file Display file selection dialog
--file-selection Alias for --file
perhaps this is the case in a later version...
Hmm iirc the problem with a tabbed log was no way to have a log monitoring a file in gtkdialog.
Hmm it was bash 3.0 (puppy 4.12) that left the ! and 3.1 is fine...these are older versions so perhaps can be ignored.... I used ${ITEM%!*} which does nothing if the ! is not present.
mike
One to jiggle at
gtkdialog4 built on puppy 4.12..... just shows yer can
only needs libgio if not present.
not bad for a senile non programmer
mike
gtkdialog4 built on puppy 4.12..... just shows yer can
only needs libgio if not present.
not bad for a senile non programmer
mike
- Attachments
-
- gtkdialog4-pup4.tar.gz
- (90.18 KiB) Downloaded 330 times
Back porting again are we.?
Building apps. is different than programming, though there`s many similar tasks.
Same with O.S. design and work, but programming is the glue to stick it together.
Puppy-4.xx sure has hung around awhile, must be significantly smaller I guess.
Newer Puppies should run well on old PCs I think, but maybe not so...
I never had much luck with the 4 series on my old Semperon and Pentium-D.
I was glad when the 5 series Lupu / Lucid Puppies came along.
# Good to hear from you Mike.!
If you make lots of apps., perhaps you would be willing to share app. dep. lists.?
My current problem is the endless building of dep. package lists for Ubuntu Pups.
The easiest way would be to dump all the libs. into a dir. and use ldd to list them.
But this would only work for me, it`d be a pain in the arse for everyone to do.
Each distro. lists deps. by their packages. Not a very easy way to build apps.
So I`m making dep. URL lists for each app., for each distro. release.
The releases mostly remain the same, but some apps. change deps. occasionally.
# I`m working on Virtual Apps.
Download and run the file and it gets the packages straight from Ubuntu. No hosting.
They`re small ( ~ 100+ KB zipped ), so they can be posted anywhere. ( Like here...)
.
Building apps. is different than programming, though there`s many similar tasks.
Same with O.S. design and work, but programming is the glue to stick it together.
Puppy-4.xx sure has hung around awhile, must be significantly smaller I guess.
Newer Puppies should run well on old PCs I think, but maybe not so...
I never had much luck with the 4 series on my old Semperon and Pentium-D.
I was glad when the 5 series Lupu / Lucid Puppies came along.
# Good to hear from you Mike.!
If you make lots of apps., perhaps you would be willing to share app. dep. lists.?
My current problem is the endless building of dep. package lists for Ubuntu Pups.
The easiest way would be to dump all the libs. into a dir. and use ldd to list them.
But this would only work for me, it`d be a pain in the arse for everyone to do.
Each distro. lists deps. by their packages. Not a very easy way to build apps.
So I`m making dep. URL lists for each app., for each distro. release.
The releases mostly remain the same, but some apps. change deps. occasionally.
# I`m working on Virtual Apps.
Download and run the file and it gets the packages straight from Ubuntu. No hosting.
They`re small ( ~ 100+ KB zipped ), so they can be posted anywhere. ( Like here...)
.
Not so much back porting as side porting.
amazing how dependency needs diminish with a bit of tweaking...not only versions but quantity too. eg mplayer normally is built with a need for the painfully obsolete libsambaclient (its all done in the kernel now) which is an instant 5mb+ hit for no real use..(erm I just click on a networked file...isn't it supposed to be a transparent file system?)
Another one is debian in particular force unneeded minimum versions for such as glibc...not one thats fun to replace.
As for this one it seems older users are supposed to mess about with major core transplants for the sake of a little gui so I thought i would give it a curious shot. The only change was to rename 2 deprecated function names in one source file...the functions remain the same....more of that gtk2 fun really. Does have some shiny features I noticed and a drop in replacement for gtkdialog3 so the new maintainer does seem to be doing a nice friendly job.
4.12...mine rolls in at under 100MB with gimp, pidgin, vlc and firefox and the usual stuff though I must mention I transplanted a slax6 kernel many moon ago... was not keen on those 4 series kernels. Does mean a bundle of slax modules can be loaded on the fly too..... I just replaced those horrible drive icons with a gtkdesklet special too.... anyway I am digressing.
programming... something I did in machine code yonks ago... oh and php..I get on with that......the scripty stuff as you know,....flash action script....a driver in c to talk to smart batteries via the printer port.....
Hey I even wrote my own bitmap printer driver for a commadore 128 using pokes to bung it into place.
C...just hacking...I got to backport a usb soundcard driver from the 3 kernels to work in 2 series/alsa 1.0.20.
But its a primative language...not one I can look at a problem and create a solution as I can in other languages....
First programming BASIC on yer TRS-80 in the shop as a spotty teen.... though it all a bit boring and carried on delving into hardware lol...oh well who needs money anyway
I think we lurk in different corners of the forum most of the time....thats why I post here now and then.
Actually slightly on topic I tried yad as a log file monitor with pburn but got a mysterious 100% cpu usage but only with that combination...its fine with other binaries but the output from cdrecord sent it doo-lally. Someone suggested Xdialog but that does not scroll properly for the job. I went back to gtklogfileviewer but it was odd as it was not a hard 100% cpu...it seemed to simply use up idle cycles as fifo buffering of cdrecord was not affected.
ok long post over
Mike
amazing how dependency needs diminish with a bit of tweaking...not only versions but quantity too. eg mplayer normally is built with a need for the painfully obsolete libsambaclient (its all done in the kernel now) which is an instant 5mb+ hit for no real use..(erm I just click on a networked file...isn't it supposed to be a transparent file system?)
Another one is debian in particular force unneeded minimum versions for such as glibc...not one thats fun to replace.
As for this one it seems older users are supposed to mess about with major core transplants for the sake of a little gui so I thought i would give it a curious shot. The only change was to rename 2 deprecated function names in one source file...the functions remain the same....more of that gtk2 fun really. Does have some shiny features I noticed and a drop in replacement for gtkdialog3 so the new maintainer does seem to be doing a nice friendly job.
4.12...mine rolls in at under 100MB with gimp, pidgin, vlc and firefox and the usual stuff though I must mention I transplanted a slax6 kernel many moon ago... was not keen on those 4 series kernels. Does mean a bundle of slax modules can be loaded on the fly too..... I just replaced those horrible drive icons with a gtkdesklet special too.... anyway I am digressing.
programming... something I did in machine code yonks ago... oh and php..I get on with that......the scripty stuff as you know,....flash action script....a driver in c to talk to smart batteries via the printer port.....
Hey I even wrote my own bitmap printer driver for a commadore 128 using pokes to bung it into place.
C...just hacking...I got to backport a usb soundcard driver from the 3 kernels to work in 2 series/alsa 1.0.20.
But its a primative language...not one I can look at a problem and create a solution as I can in other languages....
First programming BASIC on yer TRS-80 in the shop as a spotty teen.... though it all a bit boring and carried on delving into hardware lol...oh well who needs money anyway
I think we lurk in different corners of the forum most of the time....thats why I post here now and then.
Actually slightly on topic I tried yad as a log file monitor with pburn but got a mysterious 100% cpu usage but only with that combination...its fine with other binaries but the output from cdrecord sent it doo-lally. Someone suggested Xdialog but that does not scroll properly for the job. I went back to gtklogfileviewer but it was odd as it was not a hard 100% cpu...it seemed to simply use up idle cycles as fifo buffering of cdrecord was not affected.
ok long post over
Mike
What part of the forum do you frequent? I`m usually asking Qs in Programming of course.
So many things need fixing, and little is done about any of it.
No wonder Linux is declining. But I haven`t seen Android for the desktop yet, sooo...
They do have those convert-a-tablets, I guess they just intend to create a new PC.
I`ve got a post about getting SpaceFM to work like RoxFiler and recognize RoxApps.
I`ll get the click-to-run part working, but the RoxApp icon may be hard to do.
There`s a lot of chatter about directions for Puppy, I suggested forming dev. groups.
Barry`s working on a Ubuntu specific Puppy builder. I think it`s a good idea considering.
A Q Mike... What do you think about all this, and what plans if any do you have.?
.
So many things need fixing, and little is done about any of it.
No wonder Linux is declining. But I haven`t seen Android for the desktop yet, sooo...
They do have those convert-a-tablets, I guess they just intend to create a new PC.
I`ve got a post about getting SpaceFM to work like RoxFiler and recognize RoxApps.
I`ll get the click-to-run part working, but the RoxApp icon may be hard to do.
There`s a lot of chatter about directions for Puppy, I suggested forming dev. groups.
Barry`s working on a Ubuntu specific Puppy builder. I think it`s a good idea considering.
A Q Mike... What do you think about all this, and what plans if any do you have.?
.
I suppose my main area is where new users to linux fall in ... I like to help and encourage regardless of what they end up using .... just realising we do have choices is a good start. Having played with puppy since version 1 I hope I have accumulated some useful general knowledge on that subject too.
Otherwise I nosy around for ideas and join in sometimes.
I tried getting in to the dev side posting fixes and such but found the lack of organisation/interest in such things too frustrating. The joke of a bugtracker was my last straw (you remember it?) where bugs were called 'features'
But others get similar ideas so I can sometimes help with their inspirations.
puppyfied ubuntu eh...well I have added several puppy bits to slax but would never call it puppy...
Puppy is a great place to learn...how to and how not too. Reminds me of the yamahas I used to constantly tinker with to improve....(their early 4 strokes were a bit erm dubious)
Actually after several years of puppy I still find fixes and improvements I can make... on slax I have never had to once fix its boot wrappers/structure and only added the save to archive feature which took a few lines of script. Of course making xfce4 how I want it and updates of the binaries still go on but thats more to do with linux in general ( slackware does not to me make for a good source of binaries) Building around a well written core makes for a boring but reliable life.
Retired barry? well the last time that happened Lucid appeared... a brief one before that was 4.21 and dpup so another wonder puppy might be on the way.... no doom and gloom really. Its important to sail up the right river.
Tablets...well on the bigger picture the PC to many consumers became an unreliable power and money guzzling behemoth bogged down by self destructive software ... to a user a tablet may be limited but at least it does the job reliably in comparison. We know better and can make yer IBM pc put a mac to shame but a small minority are we...a similar small minority can even make windows fly reliably too so the saying that comes to mind is 'be the change you want to see'.
Low power x86 compatible boards are one branch thats of interest...with the right system its a winning combination especially if your use of a computor goes beyond you tube , emails and facebook.... ie that huge world of creative software floating around out there.... an area where yer tablets don't quite provide the goods.. Of course such hardware gets the most benefit from optimising ... my hatred of any form of bloat comes in there.
Well you did ask
mike
Otherwise I nosy around for ideas and join in sometimes.
I tried getting in to the dev side posting fixes and such but found the lack of organisation/interest in such things too frustrating. The joke of a bugtracker was my last straw (you remember it?) where bugs were called 'features'
But others get similar ideas so I can sometimes help with their inspirations.
puppyfied ubuntu eh...well I have added several puppy bits to slax but would never call it puppy...
Puppy is a great place to learn...how to and how not too. Reminds me of the yamahas I used to constantly tinker with to improve....(their early 4 strokes were a bit erm dubious)
Actually after several years of puppy I still find fixes and improvements I can make... on slax I have never had to once fix its boot wrappers/structure and only added the save to archive feature which took a few lines of script. Of course making xfce4 how I want it and updates of the binaries still go on but thats more to do with linux in general ( slackware does not to me make for a good source of binaries) Building around a well written core makes for a boring but reliable life.
Retired barry? well the last time that happened Lucid appeared... a brief one before that was 4.21 and dpup so another wonder puppy might be on the way.... no doom and gloom really. Its important to sail up the right river.
Tablets...well on the bigger picture the PC to many consumers became an unreliable power and money guzzling behemoth bogged down by self destructive software ... to a user a tablet may be limited but at least it does the job reliably in comparison. We know better and can make yer IBM pc put a mac to shame but a small minority are we...a similar small minority can even make windows fly reliably too so the saying that comes to mind is 'be the change you want to see'.
Low power x86 compatible boards are one branch thats of interest...with the right system its a winning combination especially if your use of a computor goes beyond you tube , emails and facebook.... ie that huge world of creative software floating around out there.... an area where yer tablets don't quite provide the goods.. Of course such hardware gets the most benefit from optimising ... my hatred of any form of bloat comes in there.
Well you did ask
mike
Yes I did Mike. Most of it reflects my own thoughts.
My experience also, few folks seem interested in focused efforts for solid improvements.
Debian when they`re heading for a release, they have a week long bug swatting effort.
Bugs as features, I thought M$ had the market cornered on that concept.!
My "recurring" Puppy bafoo today was adding an SFS and having to rebuild my desktop.
Really... Every time you make a change in the union stack structure it destroys the desktop.?
It`s just stupid and Puppy defeating to leave crap like this from generation to generation.
And Puppy not being able to handle changing desktop/wm properly for many of them.
But part of it`s the folks making the various packages, and the rest is poor old Puppy itself.
Yeah, that and many other reasons are why I think Ubuntu as a Puppy base is a good idea.
It solves a whole host of these problems that obviously aren`t going to be solved here. Ever.
There`s Debian and Slackware, but I think Ubuntu is more progressive and main stream.
True, announced retirement may be yet another ruse. But I think he`s serious in thought.
It may be "testing the waters" to see how the community responds, and if there really is one.
Tablets will probably replace desktops, when they have more power and better O.S.s.
For desktop use you`ll still need a keyboard and a big monitor, and maybe a mouse.
Parting shot: I really would like to see Barry create a targeted Ubuntu to Puppy builder.
Not just the generic builders he`s made, but one focused on the latest Ubuntu releases.
This would allow a number of folks to continue creating up-to-date Puppies for awhile.
# Always good talking to you Mike. Terry B.
.
My experience also, few folks seem interested in focused efforts for solid improvements.
Debian when they`re heading for a release, they have a week long bug swatting effort.
Bugs as features, I thought M$ had the market cornered on that concept.!
My "recurring" Puppy bafoo today was adding an SFS and having to rebuild my desktop.
Really... Every time you make a change in the union stack structure it destroys the desktop.?
It`s just stupid and Puppy defeating to leave crap like this from generation to generation.
And Puppy not being able to handle changing desktop/wm properly for many of them.
But part of it`s the folks making the various packages, and the rest is poor old Puppy itself.
Yeah, that and many other reasons are why I think Ubuntu as a Puppy base is a good idea.
It solves a whole host of these problems that obviously aren`t going to be solved here. Ever.
There`s Debian and Slackware, but I think Ubuntu is more progressive and main stream.
True, announced retirement may be yet another ruse. But I think he`s serious in thought.
It may be "testing the waters" to see how the community responds, and if there really is one.
Tablets will probably replace desktops, when they have more power and better O.S.s.
For desktop use you`ll still need a keyboard and a big monitor, and maybe a mouse.
Parting shot: I really would like to see Barry create a targeted Ubuntu to Puppy builder.
Not just the generic builders he`s made, but one focused on the latest Ubuntu releases.
This would allow a number of folks to continue creating up-to-date Puppies for awhile.
# Always good talking to you Mike. Terry B.
.
Was not aware of this 'feature' but I wrote my own sfs on the fly loader.My "recurring" Puppy bafoo today was adding an SFS and having to rebuild my desktop.
I modded my pups so the main sfs is at the bottom of the stack so any added sfs are layered on top..... no need for any hacks then...perhaps its those that are causing the problem...I noticed such scripts were painfully large.
Ubuntu..my objection would be the inclusion of the Out house sink with every addional app. Every possible option is enabled... this might be fine for a several gig full install but does not provide for a sleek mini portable distro.... pups seem very large compared to what I am used to and slower for it...and ubuntuness must be a major factor. Its probably why 1-2gig save files are common too.
I would suggest be a real distro and build all the binaries specifically and optimised for the intended purpose....the kernel is so why not the rest.
Once a compiling base is established its not a major job and would help considerably when it comes to compatability. Core libs could still be versioned to match such as a ubuntu release for those who want to use their packages.
Bear in mind some core binaries are nothing like the versions of the 'matching' ubuntu release anyway.... more pic'n'mix than the adverts claim.
Other thoughts are have such as puppy configure apps such as browsers with settings optimised for low profile sizes. (actually why is this not done anyway) DSL had this approach which made sense.
Another point is that by the time all the wrinkles have been ironed out from using some elses release that someone else has moved on to the next version.
As for up to date this seems a little at odds with us older hardware bunnies.... or perhaps the question is what are they keeping up to date with?..all I found with some 3 kernels stuff I tried was a whole new bag of problems with no apparent gain...intel video...linux finally catches up with the stuff...thats the only benefit that comes to mind.... but that same improvement seems to all to easily break other video hardware. But the perhaps the monolithic xorg is not such a good idea generally...one cards fix is anothers problem...I am digressing
should the topic title change ..... ha ha
regards
Mike
what am I working on..... forgot to answer... random small projects in this context .... in this instant a sulking printer...we fall out now and then.
Lots of other folks seem to favor the "build it all from scratch" approach also ( PFS ).
I understand the need for a tool chain, but compiling is not for average users.
I struggle getting binary built apps. to work properly, and failures for compile attempts.
Both have one big problem... Lists of needed files. And compiling needs instructions.
To control "getting the Out house sink", add the packages and then remove libs. not in ldd list.
In general I think of SFS or RoxApp type packages, so the app. isn`t part of the main FS.
Any other deps. usually seem to be not so optional in that the app. is hobbled without them.
Up to date`s mostly apps., basic hardware hasn`t changed much since USB-3, new graphics.
Mixing Puppy built files and Ubuntu ones is nutty. It`s all Ubuntu files, or compile them all.
An all Ubuntu base would be okay to complie on, just so the tool chain is complete.
If a builder just downloads the binary files and adds scripts, then new releases should work.
Tweeking`s always needed for any custom setup. And PuppyFromScratch needs it too.
Following the "Puppy Future" threads, the PFS guys seem most down on continuing Puppy.
The normal users ( average guys ) seem more gung ho on keeping it going. Pretty normal...
If Barry creates an Ubuntu builder that normal users can operate, then Puppy may survive.
Few "old school" devs. are left here, so PFS doesn`t seem like a realistic possibility at all.
I asked if any variant builders were left that intend to continue. No answers yet...
If one or two would maintain a base Puppy O.S., and then a support group of app. builders.
Without an O.S. maintainer there is no Puppy, unless Barry makes an easy to use builder.
We`re just chatting up a storm here, and it mirrors a lot of the other thread conversations.
But it`s good to talk 1 on 1 without 10 conversations going at once. I like it.!
Your friend. Terry B.
I understand the need for a tool chain, but compiling is not for average users.
I struggle getting binary built apps. to work properly, and failures for compile attempts.
Both have one big problem... Lists of needed files. And compiling needs instructions.
To control "getting the Out house sink", add the packages and then remove libs. not in ldd list.
In general I think of SFS or RoxApp type packages, so the app. isn`t part of the main FS.
Any other deps. usually seem to be not so optional in that the app. is hobbled without them.
Up to date`s mostly apps., basic hardware hasn`t changed much since USB-3, new graphics.
Mixing Puppy built files and Ubuntu ones is nutty. It`s all Ubuntu files, or compile them all.
An all Ubuntu base would be okay to complie on, just so the tool chain is complete.
If a builder just downloads the binary files and adds scripts, then new releases should work.
Tweeking`s always needed for any custom setup. And PuppyFromScratch needs it too.
Following the "Puppy Future" threads, the PFS guys seem most down on continuing Puppy.
The normal users ( average guys ) seem more gung ho on keeping it going. Pretty normal...
If Barry creates an Ubuntu builder that normal users can operate, then Puppy may survive.
Few "old school" devs. are left here, so PFS doesn`t seem like a realistic possibility at all.
I asked if any variant builders were left that intend to continue. No answers yet...
If one or two would maintain a base Puppy O.S., and then a support group of app. builders.
Without an O.S. maintainer there is no Puppy, unless Barry makes an easy to use builder.
We`re just chatting up a storm here, and it mirrors a lot of the other thread conversations.
But it`s good to talk 1 on 1 without 10 conversations going at once. I like it.!
Your friend. Terry B.
ok a slight misunderstanding there. I was not proposing the gentoo approach. I was suggesting those who profess to be 'devs' actually building the software rather than plagarising someone elses work. Optimisation...compiling mplayer without encoding stuff and uneeded junk like sambaclient produces a 35% smaller binary (its pretty static in this case) and a 40% drop in dependancies with no real loss of functionality as a player....its more than just leaving out bits from debs.I understand the need for a tool chain, but compiling is not for average users.
One funny one was I saved arouns 5% of the sfs size by restripping all the libraries in puppy 4.12 (normal strip no options) so there is the aspect of better 'quality control' when the job is done 'in house'
Another aspect...puppy is well known for its ability to work with wifi when the big boys fail... thats because that part of puppy IS built here and the builder makes sure it works by working closely with users....thats what I want to see more of because it can only produce a better puppy.
mike
I know of that which you speak. I figured you ment mostly apps. except where the "fixes" are needed.
I`d think Puppy`s good WiFi is the result of scripts that make the standard services work like they should.
A good O.S. is choosing the best files and then good setup, config. scripts, and other files so it`ll work.
For most utilities and services there are few choices. Computers, they just do what they`re told to do.
This binary vs compile perspective... Files are files, just so they work, who cares where they come from.?
plagiarising Ubuntu... Isn`t that what most of the Linux distros out there do.?
And for a good reason...
I`m not down on compiling, especially in the core O.S. But making apps. should be easy for most users.
That`s why I appealed in several threads for app. dep. lists. These are the king pin of app. building.
There`s dep. files, but unless you have file to pkg. ( urls ) then file lists ( ldd ) don`t help.
Source is a bit different, the pkgs. are just the utility, service, or app. No extra crap Ubuntu decided to add.
Mplayer A terrible or excellent example I`m sure you`ll agree. I think Xine`s better, need to try VLC.
Mplayer is definitely a shining example of "needs to be fixed in so many ways". Custom setup is the norm.
Most apps. aren`t this messy. The important and messy apps. ( only a few...) can be made by "experts".
The virtual apps. I`m tinkering with have URL files, and allow script to fix anything ( del. crap. from pkgs. ).
The Xfe virtApp I made had /etc/xferc, the script simplifies by moving the file to /usr/share/xfe and del. /etc
From what I understand, Gentoo hasn`t worked out so well. I always opt. for a "middle of the road" approach.
Compile the critical stuff of course. And probably messy stuff also. But choosing an easy route isn`t bad.
.
I`d think Puppy`s good WiFi is the result of scripts that make the standard services work like they should.
A good O.S. is choosing the best files and then good setup, config. scripts, and other files so it`ll work.
For most utilities and services there are few choices. Computers, they just do what they`re told to do.
This binary vs compile perspective... Files are files, just so they work, who cares where they come from.?
plagiarising Ubuntu... Isn`t that what most of the Linux distros out there do.?
And for a good reason...I`m not down on compiling, especially in the core O.S. But making apps. should be easy for most users.
That`s why I appealed in several threads for app. dep. lists. These are the king pin of app. building.
There`s dep. files, but unless you have file to pkg. ( urls ) then file lists ( ldd ) don`t help.
Source is a bit different, the pkgs. are just the utility, service, or app. No extra crap Ubuntu decided to add.
Mplayer
A terrible or excellent example I`m sure you`ll agree. I think Xine`s better, need to try VLC.Mplayer is definitely a shining example of "needs to be fixed in so many ways". Custom setup is the norm.
Most apps. aren`t this messy. The important and messy apps. ( only a few...) can be made by "experts".
The virtual apps. I`m tinkering with have URL files, and allow script to fix anything ( del. crap. from pkgs. ).
The Xfe virtApp I made had /etc/xferc, the script simplifies by moving the file to /usr/share/xfe and del. /etc
From what I understand, Gentoo hasn`t worked out so well. I always opt. for a "middle of the road" approach.
Compile the critical stuff of course. And probably messy stuff also. But choosing an easy route isn`t bad.
.
The good wifi does have working scripts but its also a pile of firmware included and tweaked and extra drivers built as users request them... tempestous seems to be the bunny that makes most of this happen. Without the latter any distro is dead in the water regardless of how good the wifi setup is.
Ubuntu..erm who builds their files... themselves nowadays I believe....and those builders decide what is enabled...usually everything possible just for the one in several million user who might possibly need it and forced versioning which I assume is part of their release cycling...but their target market is not quite the same. Its the same with windows...for corporate clients all that surplus 'bloat' suddenly has a purpose (ok one that could be argued with) but a stipped XP works perfectly well for joe public.
I dont want my apps dragging in needless dependencies making them larger and slower and necessitate many extra redundant libraries.
I care about where my files com from cos I want them to work and not drag in more than really needed. Filtering a built package will not alter the dependency needs.
Mplayer..I'd say typical example ... a rough estimate would be 90% of binaries/apps/libraries from ubuntu/deb could be built needing less dependencies.
Note the attempts here to build a slimmer vlc. Xine uses ffmpeg... that can be trimmed too. I seem to compile more and more and this is usually the reason.... but seems a bit rough when really I am the user not the 'dev'. 'I wrote some scripts and borrowed some files' seem the qualification to be a distro maker..... bit like the showroom salesman claiming to be the car manufacturer.
Today we are sculpting with blender.... the first program for me that needed a tutorial in order to save a file
regards
Mike
Ubuntu..erm who builds their files... themselves nowadays I believe....and those builders decide what is enabled...usually everything possible just for the one in several million user who might possibly need it and forced versioning which I assume is part of their release cycling...but their target market is not quite the same. Its the same with windows...for corporate clients all that surplus 'bloat' suddenly has a purpose (ok one that could be argued with) but a stipped XP works perfectly well for joe public.
I dont want my apps dragging in needless dependencies making them larger and slower and necessitate many extra redundant libraries.
I care about where my files com from cos I want them to work and not drag in more than really needed. Filtering a built package will not alter the dependency needs.
Mplayer..I'd say typical example ... a rough estimate would be 90% of binaries/apps/libraries from ubuntu/deb could be built needing less dependencies.
Note the attempts here to build a slimmer vlc. Xine uses ffmpeg... that can be trimmed too. I seem to compile more and more and this is usually the reason.... but seems a bit rough when really I am the user not the 'dev'. 'I wrote some scripts and borrowed some files' seem the qualification to be a distro maker..... bit like the showroom salesman claiming to be the car manufacturer.
Today we are sculpting with blender.... the first program for me that needed a tutorial in order to save a file
regards
Mike
Again... I hear what you say, and you`re right of course. A truly tuned system would be entirely LFS.
With this in mind, Puppy really would need a legion of very capable devs. Not gonna happen.
So there must be some middle ground somewhere. # Any ideas what that could be.?
Perhaps compile scripts for the really dicey apps., and binary scripts for the nice ones...
The amount of work for all the apps. out there is over whelming. Not to mention the O.S.
Hummm. Blender, sounds like my use of OpenShot. A pro quality editor, very unintuitive.
.
With this in mind, Puppy really would need a legion of very capable devs. Not gonna happen.
So there must be some middle ground somewhere. # Any ideas what that could be.?
Perhaps compile scripts for the really dicey apps., and binary scripts for the nice ones...
The amount of work for all the apps. out there is over whelming. Not to mention the O.S.
Hummm. Blender, sounds like my use of OpenShot. A pro quality editor, very unintuitive.
.
Hmm ok.... well perhaps when you use the term 'backporting' for me its building an app to run on as meny versions as possible.
eg my rebuild of mplayer circa 2009...a pretty useful version....will run on puppy 2.0 and anything newer. So take a messy app and make a tidy version that runs on anything... that in itself reduces the workload as only one build would be needed. A stock of allrounders if you will.
Building the core libraries makes sense for stability plus of course it automatically would mean that part of an apps dependency tree would already be streamlined..... the common apps doo tend to pull in a similar fileset after all..
pulling in some other distros builds as desired ...I do it all the time ... but have puppy friendly builds of the hairier commonly wanted stuff. At the end of the day if someone wants kde or gnome or related software its going to be messy regardless.... some people want to use their sports car as a pick up truck...so be it
In fact that paints a picture of puppy at an earlier state of its life..
ok late evening calls
regards
Mike
eg my rebuild of mplayer circa 2009...a pretty useful version....will run on puppy 2.0 and anything newer. So take a messy app and make a tidy version that runs on anything... that in itself reduces the workload as only one build would be needed. A stock of allrounders if you will.
Building the core libraries makes sense for stability plus of course it automatically would mean that part of an apps dependency tree would already be streamlined..... the common apps doo tend to pull in a similar fileset after all..
pulling in some other distros builds as desired ...I do it all the time ... but have puppy friendly builds of the hairier commonly wanted stuff. At the end of the day if someone wants kde or gnome or related software its going to be messy regardless.... some people want to use their sports car as a pick up truck...so be it
In fact that paints a picture of puppy at an earlier state of its life..
ok late evening calls
regards
Mike