Puppy 4.4 CE - Phase 1: pet tests
- Max Headroom
- Posts: 421
- Joined: Wed 28 Jun 2006, 07:17
- Location: GodZone Kiwi
- Contact:
re All the Recent Discussion 'bout where's Home...
re All the Recent Discussion 'bout where's Home...
Can We Please incorporate Pizzasgood MultiUser Functionality!
http://www.murga-linux.com/puppy/viewto ... 9&start=30
http://www.murga-linux.com/puppy/viewtopic.php?t=47410
This is the ideal Opportunity to introduce this into the MainStream Dingo,
+1 for trying / upgrading to Xorg 7.5 and Xserver 1.7.1 & Opera
Cheers!
Can We Please incorporate Pizzasgood MultiUser Functionality!
http://www.murga-linux.com/puppy/viewto ... 9&start=30
http://www.murga-linux.com/puppy/viewtopic.php?t=47410
This is the ideal Opportunity to introduce this into the MainStream Dingo,
+1 for trying / upgrading to Xorg 7.5 and Xserver 1.7.1 & Opera
Cheers!
I sometimes get a little confused about where I should post certain types of questions so I apologise in advance if this isn't the greatest thread to post in. However, I was looking around for how Puppy organises itself into getting contributions for future releases.
I was reading previously that there was some mention and agreement with the notion of One Task = One Application/Utility. I'm not sure if I fully understand the extent of that philosophy as it applies to distribution development. Ie - is the idea not to have multiple applications in order to perform one application or is the idea to have applications (where possible) to only perform one task - and how broad is the notion of task?
I love Puppy, but one of the things I recently noticed was how desktop configuration elements like JWM aren't really all in one place - and are not necessarily there at all - eg configuring multiple trays without having to do it from scratch with a text file.
I was thinking it would be nice to have a JWM configuration utility that covers all of this config in one application. I see bits and pieces of this idea, but not the idea in full.
For myself I was contemplating developing a tool for my own benefit to try to cover as many aspects of JWM configuration as I can in one central utility which I could then use instead of either multiple tools or direct text configuration. I'm not sure how feasible it is (with my skillset and amount of free time) to do this, but this is what I was thinking about.
Would such an exercise fit or not fit with the notion of one task = one application? And would such an excerise actually align with the goals of putting out a Puppy - whether that's a community edition or a core edition?
Regards
Caleb
I was reading previously that there was some mention and agreement with the notion of One Task = One Application/Utility. I'm not sure if I fully understand the extent of that philosophy as it applies to distribution development. Ie - is the idea not to have multiple applications in order to perform one application or is the idea to have applications (where possible) to only perform one task - and how broad is the notion of task?
I love Puppy, but one of the things I recently noticed was how desktop configuration elements like JWM aren't really all in one place - and are not necessarily there at all - eg configuring multiple trays without having to do it from scratch with a text file.
I was thinking it would be nice to have a JWM configuration utility that covers all of this config in one application. I see bits and pieces of this idea, but not the idea in full.
For myself I was contemplating developing a tool for my own benefit to try to cover as many aspects of JWM configuration as I can in one central utility which I could then use instead of either multiple tools or direct text configuration. I'm not sure how feasible it is (with my skillset and amount of free time) to do this, but this is what I was thinking about.
Would such an exercise fit or not fit with the notion of one task = one application? And would such an excerise actually align with the goals of putting out a Puppy - whether that's a community edition or a core edition?
Regards
Caleb
- Lobster
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
@caleb72
this code might be of interest - used in dpup
http://www.murga-linux.com/puppy/viewto ... 418#293418
this code might be of interest - used in dpup
http://www.murga-linux.com/puppy/viewto ... 418#293418
gnumeric
OK! I'm on it! I actually already messed with updating gnumeric once, and found that it's dependencies were complex enough that I dropped it. But, I think I can have a new static pet within a few days. It may take me a few more to get it stripped down to puppy standards.
Tom
Tom
I apologize if this is the wrong 4.4 thread to put this in.
I was just closing some partitions on my hard drive from the pinboard and wanted to keep some mounted and others not, and thought "Man, it would be nice if there were buttons to minimize, maximize, close, AND close-&-unmount, instead of just the first three."
I have NO IDEA (not a computer guy ) how doable the idea is but is it possible to have close-and-unmount button along with the other three regulars instead of having to right click to unmount a partition?
thanks for your thoughts.
I was just closing some partitions on my hard drive from the pinboard and wanted to keep some mounted and others not, and thought "Man, it would be nice if there were buttons to minimize, maximize, close, AND close-&-unmount, instead of just the first three."
I have NO IDEA (not a computer guy ) how doable the idea is but is it possible to have close-and-unmount button along with the other three regulars instead of having to right click to unmount a partition?
thanks for your thoughts.
-
- Posts: 632
- Joined: Tue 02 Oct 2007, 07:39
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
Rox 2.10 is considered an unstable release, but I don't have a problem testing unstable releases - how else will they ever get stable? Hopefully I can access the 2.9 sources somewhere so that I can do a diff against the original sources and apply them to 2.10 (and send them upstream in case ttuuxxx didn't) Has anyone tracked down the patched sources?
Xorg could take a while to fully compile. By popular request need to remember to include Xinput.... Anything else that is currently missing that people would like to see added? DRI, GLU by default maybe?
Xorg could take a while to fully compile. By popular request need to remember to include Xinput.... Anything else that is currently missing that people would like to see added? DRI, GLU by default maybe?
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Please, don´t forget to add: Latest TightVNC 1.3.10 and Filezilla.technosaurus wrote: Xorg could take a while to fully compile. By popular request need to remember to include Xinput.... Anything else that is currently missing that people would like to see added? DRI, GLU by default maybe?
A new request: latest hiawatha version 6.17.1.
P.S: I don´t know about rxvt state, but a multitab rxvt will be good.
Thank you,
clarf
I don´t want to bother you. But I think it´s a small request.
I´ll like to see the Psearch Right click feature in Rox.
http://murga-linux.com/puppy/viewtopic.php?t=47990
Thank you again,
clarf
I´ll like to see the Psearch Right click feature in Rox.
http://murga-linux.com/puppy/viewtopic.php?t=47990
Thank you again,
clarf
appdir
That plus caleb's initiative can also mean that we can look forward to one-application-one-folder deployment (along the appdir idea).dio444 wrote:OK! I'm on it! I actually already messed with updating gnumeric once, and found that it's dependencies were complex enough that I dropped it. But, I think I can have a new static pet within a few days...
It may not be the neatest method for devs, but it is appealing to users.
EDIT: The newer technology for kernel 2.6.30 and up is sfs, see
http://code.google.com/p/sfs-technology/
The new sfs technology solves software dependencies and installation problems. It consists of a unique file that can be mounted as a normal file-system with all really needed libraries and files of the specific program. When mounted the sfslauncher will start the application stored into it. The procedure is completely transparent to the end user; Just double click on the "program.sfs" and sfslauncher will do the magic. Starting with version 1.0 we improved the integration: the operating system now knows the "sfs" file type as a native executable file.
Last edited by raffy on Sat 24 Oct 2009, 13:18, edited 1 time in total.
Puppy user since Oct 2004. Want FreeOffice? [url=http://puppylinux.info/topic/freeoffice-2012-sfs]Get the sfs (English only)[/url].
Re: appdir
Whoa!raffy wrote: That plus caleb's initiative can also mean that we can look forward to one-application-one-folder deployment (along the appdir idea).
Maybe I'm guilty of misrepresenting myself here. If I have done so, I'm terribly sorry.
I'm not ruling out contributing to Puppy, but I'm picking a project to help myself learn Genie and GTK+ programming and JWM configuration makes sense to me because I'm not 100% satisfied with Puppy's included tools (no offense at all to the developers of said tools).
I would be ecstatic to have my work become part of a Puppy distribution CE or core and I wouldn't write-off my contribution in the future, but this 4.4CE project is already at .pet testing stage, while I'm still struggling to successfully use the simple GLib XML parser functionality with Genie.
It may also be that my way of conceptualising and designing a solution really just doesn't meet Puppy's ideals. I think when I feel more confident in Genie (because I don't think Python is going to be tremendously useful for these projects), I will submit my particular design philosophies/idiosyncrasies to the relevant release coordinator(s) to see if where I would like to go aligns with where Puppy is actually going. I think Genie developers are going to be useful in a general sense to Puppy's future, but as always it's a case by case basis.
Hopefully my code doesn't ramble as much as I do.
Regards
Caleb
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I wanted to have xz capability but xarchiver is too big so I patched xarchive to use xz compression
you will need tar-1.22 or later which is not in 4.3 but it is here:
http://puppylinux.asia/members/T/444/tar-1.22-i486.pet
I can patch it to use lzop and lzma if anyone is interested in those
Edit patched for lzma as well
... to set it up as the default handler for tar.xz or tar.lzma
1. right click on a tar.xz or tar.lzma
2. left click on set run action
3. type pupzip before the "$@"
4. click on "use command"
you will need tar-1.22 or later which is not in 4.3 but it is here:
http://puppylinux.asia/members/T/444/tar-1.22-i486.pet
I can patch it to use lzop and lzma if anyone is interested in those
Edit patched for lzma as well
... to set it up as the default handler for tar.xz or tar.lzma
1. right click on a tar.xz or tar.lzma
2. left click on set run action
3. type pupzip before the "$@"
4. click on "use command"
- Attachments
-
- xarchive-0.2.8-6.pet
- (37.14 KiB) Downloaded 592 times
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
trying to build a small 7zip program to open 7z archives... only have 7zDec so far
7zDec -e some-archive.7z <-- extract all
7zDec -l some-archive.7z <-- list all
I haven't made a wrapper script for this one since it won't compress
7zDec -e some-archive.7z <-- extract all
7zDec -l some-archive.7z <-- list all
I haven't made a wrapper script for this one since it won't compress
- Attachments
-
- gun.gz
- for gz and Z
- (4.8 KiB) Downloaded 593 times
-
- lzopack.gz
- for lzo
- (8.84 KiB) Downloaded 604 times
-
- 7zDec.gz
- (15.65 KiB) Downloaded 620 times
Last edited by technosaurus on Tue 27 Oct 2009, 02:11, edited 3 times in total.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Playing with sfs on 4.3.1
Sorry if this in the wrong place.
I've done some playing about with sfs files in Pup-431, and come to some conclusions about future puppies.
What I've found:
1) Being able to mount sfs files above pup-431.sfs in the aufs stack is quite useful,
a) Being able to have a firefox.sfs that "modifies" /usr/local/bin/defaultbrowser is good,
b) Generating a patch-431.sfs that can replace any file in the release pup-431.sfs, so I don't need to rebuild pup-431.sfs
(could possibly publish an official patch sfs if this facility were part of the release puppy)
2) Some current sfs files are not suitable to be placed above pup-431.sfs.
e.g. devx_431.sfs contains the real "man" program, which is not very useful when it "covers" the more useful "man" in pup-431.sfs.
3) It is possible to dynamically mount and umount sfs files in 4.3.1.
Maybe I've mucked mine up somehow, but the attached "load_sfs_aufs2-0.1-sfs4.sfs" contains "load-sfs" and "unload-sfs" scripts that seem to work on my frugal install of pup-431.
Suggestions:
1) Persevere with the unionfs concept, it has it's challenges, but it is a powerful concept.
2) Minimise the use of the rw layer to only data that is volatile. This implies that all software should be in sfs files.
This simplifies backup, and backup is required since the rw layer is often not cleanly umounted in puppy.
3) Implement a "patch" mechanism that mounts sfs above pup-xxx.sfs only at boot. This could utilise the current BootManager facility. This one becomes more hidden, least used.
4) Implement a single, new? facility to append software sfs below pup-xxx.sfs both at boot and dynamically. It might relate to PPM. This one becomes the most visible, most used.
5) Extract the decoupling scripts, "/usr/loca/bin/defaultxxxxxxxx" from pup-xxx.sfs and place them in a zdef-xxx.sfs which could then be easily replaced to use different applications.
(Include "/usr/bin/xterm" in this as a decoupler for alternates to rxvt.)
gyro
I've done some playing about with sfs files in Pup-431, and come to some conclusions about future puppies.
What I've found:
1) Being able to mount sfs files above pup-431.sfs in the aufs stack is quite useful,
a) Being able to have a firefox.sfs that "modifies" /usr/local/bin/defaultbrowser is good,
b) Generating a patch-431.sfs that can replace any file in the release pup-431.sfs, so I don't need to rebuild pup-431.sfs
(could possibly publish an official patch sfs if this facility were part of the release puppy)
2) Some current sfs files are not suitable to be placed above pup-431.sfs.
e.g. devx_431.sfs contains the real "man" program, which is not very useful when it "covers" the more useful "man" in pup-431.sfs.
3) It is possible to dynamically mount and umount sfs files in 4.3.1.
Maybe I've mucked mine up somehow, but the attached "load_sfs_aufs2-0.1-sfs4.sfs" contains "load-sfs" and "unload-sfs" scripts that seem to work on my frugal install of pup-431.
Suggestions:
1) Persevere with the unionfs concept, it has it's challenges, but it is a powerful concept.
2) Minimise the use of the rw layer to only data that is volatile. This implies that all software should be in sfs files.
This simplifies backup, and backup is required since the rw layer is often not cleanly umounted in puppy.
3) Implement a "patch" mechanism that mounts sfs above pup-xxx.sfs only at boot. This could utilise the current BootManager facility. This one becomes more hidden, least used.
4) Implement a single, new? facility to append software sfs below pup-xxx.sfs both at boot and dynamically. It might relate to PPM. This one becomes the most visible, most used.
5) Extract the decoupling scripts, "/usr/loca/bin/defaultxxxxxxxx" from pup-xxx.sfs and place them in a zdef-xxx.sfs which could then be easily replaced to use different applications.
(Include "/usr/bin/xterm" in this as a decoupler for alternates to rxvt.)
gyro
- Attachments
-
- load_sfs_aufs2-0.1-sfs4.sfs.bz2
- Scripts to dynamically load and unload sfs files in 431
- (2.96 KiB) Downloaded 576 times
-
- Posts: 632
- Joined: Tue 02 Oct 2007, 07:39
- ttuuxxx
- Posts: 11171
- Joined: Sat 05 May 2007, 10:00
- Location: Ontario Canada,Sydney Australia
- Contact:
I use fileroller for lzma support in 2.14X. Plus Fileroller is way faster than xarchive, Here try this and tell me how long it takes to open Firefox sources and extract them ftp://ftp.mozilla.org/pub/mozilla.org/f ... ce.tar.bz2 lol well over 30Mins, if you use fileroller or xarchiveR, under 2 mins. I include XarchiveR and Fileroller in 2.14x if one doesn't work, good chance on the other will. still together under 1MB so Its worth it.
ttuuxxx
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)
- Max Headroom
- Posts: 421
- Joined: Wed 28 Jun 2006, 07:17
- Location: GodZone Kiwi
- Contact:
Xorg 7.5, Bring it On!!!
Xorg 7.5, Bring it On!!!
-
- Posts: 632
- Joined: Tue 02 Oct 2007, 07:39