A vote for a modular use of Puppy Linux

For talk and support relating specifically to Puppy derivatives
Message
Author
User avatar
RSH
Posts: 2397
Joined: Mon 05 Sep 2011, 14:21
Location: Germany

#41 Post by RSH »

Hi.

For the misunderstandings that have come up here, I should have posted Information -now available at the second post- maybe much earlier.

So, just repeating: I have updated the second post of this here thread/topic.

Now hopefully anyone further interested and maybe here involved, will get a more "whole picture" of it.

Of course, anyone now will be able to check this out, using HIS FAVORITE PUPPY!

RSH
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#42 Post by MochiMoppel »

RSH wrote:
Me wrote:As most of you already know, I'm using my several LazY Puppy Systems strictly modular and without the use of a save file.
This is just the intro sentence and it is also just the truth. I don't use a save file at all.
That wouldn't be of any interest if you wouldn't continue
RSH wrote:..there is too many postings on the forum, about problems with the use of a save file (Help, my save file is filling up, can't use XXX after installing YYY etc.pp.) followed by lots of pages of instructions, how to "fix" such.

This is boring and of course it doesn't really help to make people willing and able to change from Windows (or any other Linux OS) to Puppy Linux and to become a Puppy Linux Newcomer.

That's why I want to make a vote for a modular use of Puppy Linux
Never explained "problems" with the save file are clearly one cause for you to vote for a modular Puppy. You praise Lazy as a modular system. Lazy makes it hard to create a save file. My only question: why? I don't know how much you are involved in Lazy and if you are the right person to give an answer. If not, just say so. Your personal tricks to save your settings are irrelevant, as are mine ( I also don't use save files ), but I'm genuinely interested to know how the creators of Lazy expect a normal user to do it. If it's a good solution, I will adopt it.
Please, please: go away and stay away using save file and PET installs.
You should try harder to be respectful. I'm not a mosquito. I came here not for fun or to harass people but to get answers. Didn't work out.
Sorry to all other people over here. The mean part follows right now
Can't hardly get any meaner...

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#43 Post by mikeb »

Why doesn't all this obviously good stuff/ideas have found its way into Puppy Linux and/or any Puppy Linux Derivative?
Well some do ... the file structure / layering of the puppy we know now follows the slax way , its just how its implemented that differs.
On the other hand see what's happening in this thread.... not exactly productive when good ideas are getting lost but this is pretty typical and note very little activity in this forum alone reaches the main puppy releases.
Aufs will do this, but I hardly think it`s very efficient.
I suspect this notion comes from unionfs which slowed down considerably with only a few layers. I regularly have 20 to 40 sfs loaded by default and get no appreciable performance hit on pentium 3 machines which noticed the drag of the standard drive icons in puppy. I noticed mention of some problems with recent kernels and aufs ... not sure of the current situation as 2.6.33 is the newest I normally use.
I also have sfs as small as 200-300k in the set...one per app usually.
This question has been bugging me for quite some time. I do not want/need this layer. I see it as redundant, as all my puppies run in pupmode=5 - no save file. Is there a way to remove it ... editing this part of init?
Drifting away here...but you have to have some form of read/write layer for the system to work. Not having a save file layer on the other hand I find beneficial.

mike

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#44 Post by mikeb »

edit mail failure...

User avatar
oldyeller
Posts: 889
Joined: Tue 15 Nov 2011, 14:26
Location: Alaska

#45 Post by oldyeller »

This all sounds good, but how does one go about doing this type of system? How would you link to a Appdir or load more than 6 SFS?

If you load by the menu when needing a program, does it unload when it is closed? Are the SFS done automatically for loading and unloading and no need for SFS-load on the fly?

I know that seaside has done stuff with SFS files before.

How does a Appdir work? Do you have scripts to open the apps that are in it? And does the same principle work for a Dir with SFS?

User avatar
RSH
Posts: 2397
Joined: Mon 05 Sep 2011, 14:21
Location: Germany

#46 Post by RSH »

@MochiMoppel

My personal tricks to save settings aren't a part of the Modular Concept.

I just linked this as an reply to nooby!

It is not relevant for this thread, because I can use this Modular Concept(and so the user does) also when using a personal storage file (save file).

Got it NOW?!?!?!

And by the way, just to keep you informed: there is no LazY Puppy Creators (as a multiple) - there is only one: ME.

You should have already know this, if you were able to read and to understand what currently reading.

And again: this here is not for LazY Puppy. Go complain in its EN Forum, if you would have anything to complain about it. Though, I doubt you would get any further answer from me.

This is my last reply to you in this here thread. To me, sorry I have to say this, you are now OUT!
mikeb wrote:I suspect this notion comes from unionfs which slowed down considerably with only a few layers. I regularly have 20 to 40 sfs loaded by default and get no appreciable performance hit on pentium 3 machines which noticed the drag of the standard drive icons in puppy. I noticed mention of some problems with recent kernels and aufs ... not sure of the current situation as 2.6.33 is the newest I normally use.
I also have sfs as small as 200-300k in the set...one per app usually.
Yes, I usually also do have around 30 to 40 SFS Modules loaded, without any noticeable result to Operating Systems performance.

I have SFS Modules from 11KB up to 300+ MB. The funny thing I have noticed so far: time to laod an SFS seems not really to make a difference, if the SFS is sized in KB or even in MB.

That's why I've suspected that there must be a difference between loading an SFS at boot up and loading an SFS via sfs_load.
On the other hand see what's happening in this thread.... not exactly productive when good ideas are getting lost but this is pretty typical and note very little activity in this forum alone reaches the main puppy releases.
Yeah, already noticed this. Though, there is no reasonable point for me to see, why this hasn't changed in those 10 Puppy Linux years.
oldyeller wrote:If you load by the menu when needing a program, does it unload when it is closed? Are the SFS done automatically for loading and unloading and no need for SFS-load on the fly?
If the SFS's application is a real binary, I can freely define if the SFS should be unloaded after its application is exited. Please note the onformation at second post, and there especially read the thread of multi-session CD/DVD (my solution, created for 8-bit). For the use of the Modular Concept, how I do prefer and suggesting it, the use of sfs_load is needed!

This Modular Concept is built on top of sfs_load and all its pretty comfort would get lost immediately, if there wouldn't be shinobar's sfs_load. Though, I'm currently using a little modified version to be able to load SFS from different locations (and not only from boot partition or boot directory). I'm convince by now, I would be able to create this also for the use without shinobar's sfs_load. But why should I try so?
How would you link to a Appdir or load more than 6 SFS?
To laod more than 6 SFS Modules (I assume, you do mean at boot up, when using a save file) also sfs_load can be used. Itself uses a file /etc/init.d/sfs_load for this.

While running the OS, shinobar's sfs_load generates mount point directories automatically for each SFS to load.

There is no need to link to AppDirs, because you can run them from every location you want to store it. But AppDirs aren't really a part of this here. It could be a nice addition, but I'm not an expert for this - still learning while doing some of this stuff (like the RoxApp Builder, which isn't a part of this here as well). If you want to know anything about AppDirs or RoxApps or Program Folders, go to RoxApp Builder thread in Puppy Projects Forum and do read my information over there. There are also some links to a few RoxApp Dirs for the use on un-unioned SFS Modules (I think, un-unioned means: not mounted to the pup_roX directories, instead mounted to /mnt or anywhere else).
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#47 Post by mikeb »

I think it was shinobars sfs load I looked at ..... as mentioned it or whatever it was did load to ram if there was enough space ...that would take longer the larger the file but the same would apply to one at boot.
If we are dealing with aufs itself I have noticed it can take a few seconds for files to propagate through the system when dealing with an sfs with thousands of files...the devx is a good example, but it probably takes longer for menus to sort out so its not a problem as such.

Just as an aside I am fiddling with the initrd at the moment and it takes 1.5 seconds to run the init script including loading a 94mb pup sfs to ram on a pentium 3.

Here's the module activate/deactivate script I have on puppy in use at the moment. I am a slob and should tart it up but it does the job.
Its in the right click rox menu and toggles load/unload.

Code: Select all

#! /bin/sh

## script to insert and remove sfs files.....for puppy kernel 2.6.21 and above seem fine with this..

MODULE="$1"
NAME="`basename $MODULE | tr ' ' '_' `"  ##remove spaces for later...easier life

if [ "`mount | grep "$NAME "`" = "" ]; then
	## insert module...note if mounted already will not try and insert...probably a good thing
	## TODO.....resize and add into tmpfs if enough room...or small....or the rest loaded .. hmmmm..
	##note slax only does this if inside the union....need test for this? 
	MODE="activate"
	#must remember to makes nodes if all used
	NEXT=$(losetup -f 2>/dev/null) 
	if [ "$NEXT" = "" ]; then
		NR=$(find /dev/loop* | cut -b 10- | sort -n | tail -1)
		NR=$(expr $NR + 1)
		NEXT=/dev/loop$NR
		mknod $NEXT b 7 $NR 2>/dev/null
	fi
	mkdir -p /initrd/$NAME
	mount-FULL -o loop -t squashfs "$MODULE" /initrd/$NAME
	busybox mount -t aufs -o remount,add:1:/initrd/$NAME=ro unionfs /
	if [ $? -eq 0 ]; then
		#fixmenus
		touch /root/.config/xfce4/desktop/menu.xml
		[ "`pidof X`" != "" ]&& Xdialog --timeout 4 --msgbox "Inserted $NAME" 5 40
		echo "Inserted $NAME"
		exit
	fi
else
	MODE="deactivate"
	busybox mount -t aufs -o remount,del:/initrd/$NAME unionfs /
	busybox umount /initrd/$NAME
	rmdir /initrd/$NAME
	if [ $? -eq 0 ]; then
		#fixmenus...do first before dialog as faster
		touch /root/.config/xfce4/desktop/menu.xml
		[ "`pidof X`" != "" ]&& Xdialog --timeout 4 --msgbox  "Removed $NAME" 5 40
		echo "Removed $NAME"
		exit
	fi
fi

[ "`pidof X`" != "" ]&& Xdialog --timeout 4 --msgbox "Unable to $MODE $NAME" 5 40
echo "Unable to $MODE $NAME"
note fixmenus is there but commented out as I have xfce4.
note 2...this mounts the sfs just under the rw layer which logic dictates it should be.

mike

dancytron
Posts: 1519
Joined: Wed 18 Jul 2012, 19:20

#48 Post by dancytron »

I've mainly contributed by answering simple questions occasionally, but I've thought about this for awhile. I think to do what RSH is talking about, the first thing is to build an infrastructure that makes it accessible to mere mortals (as opposed to Woof, which is only accessible to real developers).

The first step is to produce a barebones main sfs file that only has what is necessary to install and run the system. Just the stuff to configure the hardware, a desktop, the Load SFS program, Remaster Script and Pupsaveconfig. That would be the base to allow creating a modular system. Pupsaveconfig lets you decide how to handle the save file. Load SFS lets you add modules to the system.

Then create another sfs that has setup utilities, including the PPM, Gparted, all the utilities to configure the desktop, all the utilities to create and edit pets and sfs files, etc etc. All the stuff to setup Puppy, as opposed to just use it.

Finally, you'd have a DevX sfs file that has the compiling tools just like it does now.

With these three pieces, you can then create sfs files to make a modular system, create pet files to install to save file (or use as a basis to remaster the main sfs file), use the PPM to install Ubuntu or Slackware packages to install to save file (or use to remaster the main sfs file), compile programs from the source etc.

It gives a lot of flexibility to create custom modular (or not modular) distributions without dealing with Woof.

Anyway, just a thought.

User avatar
RSH
Posts: 2397
Joined: Mon 05 Sep 2011, 14:21
Location: Germany

#49 Post by RSH »

mikeb wrote:If we are dealing with aufs itself I have noticed it can take a few seconds for files to propagate through the system when dealing with an sfs with thousands of files...the devx is a good example, but it probably takes longer for menus to sort out so its not a problem as such.
Yes.

As far as I know, shinobar's sfs_load is mounting an AUFS, to load SFS Modules. Also I have noticed a -sometimes- huge delay until the sfs_load GUI to execute an application from the currently loaded SFS appears on the screen. I have noticed also, this is dependent to the WM in use.

My experiences:

- JWM needs sometimes to be refreshed manually (though, it is fast)
- IceWM is also fast and I did never ever need to refresh it manually
- Openbox is really fast, even for a full menu like I do have over here (currently 821 .desktop files in /usr/share/applications)

BUT:

- when FbPanel is used as the panel for Openbox these 821 .desktop files (menu entries) resulting in an huge delay
- this huge delay is related to FbPanel itself
- the code, producing this issue is to be found in /usr/sbin/fixmenus

Code: Select all

if (grep "openbox" /etc/windowmanager) then
	[ `which variconlinks` ] && variconlinks #100404 for my fbpanel pkg.
	[ `which tempicons` ] && tempicons
fi
- responsible line is: [ `which variconlinks` ] && variconlinks #100404 for my fbpanel pkg
- this line creates a huge amount of icons from all over the running OS for the FbPanel to use

Currently I don't have any other WM/Panel installed, than Openbox and Tint2. If loading my LP2_WindowManagers.sfs Openbox (the OS) will use automatically FbPanel instead of tint2. Therefor I have modified /usr/sbin/fixmenus to execute refresh/rebuild of Openbox menu at first - before any else WM/Panel is refreshed/rebuild.

So, while FbPanel is stiil updating its icons, I can run any newly added application from Openbox menu immediately.

Also, I don't use sfs_load as it is supposed to use. I do use it only as back end script, since I have my own GUI to load/unload SFS Modules and all the menu entries already built into the OS. So, there is no need to run /usr/sbin/fixmenus when loading an SFS by the use of sfs_load in back end (console) mode. That's why shinobar has introduced option --skip-fixmenus in sfs_load version 1.9 and above. Especially for the use of the SFS P.L.U.S. RunScripts!

Code I usually do use, to load any SFS Module:

Code: Select all

sfs_load --cli --skip-fixmenus --quiet "$LP2BDL/$SFS_file"
Code I usually do use, to unload any SFS Module:

Code: Select all

sfs_load --unload --cli --skip-fixmenus --quiet "$LP2BDL/$SFS_file"
$LP2BDL is current boot directory, like: /mnt/sdd1/LazY
$SFS_file is the SFS Module to load, like LP2_WindowManagers.sfs
Just as an aside I am fiddling with the initrd at the moment and it takes 1.5 seconds to run the init script including loading a 94mb pup sfs to ram on a pentium 3.
Mine is a bit slower than yours, since I've added some stuff to be able to load each SFS Module I want to load at boot up - just by an option to be placed in a boot menu entry in menu.lst (or even entered in console)

This

Code: Select all

lpextsfs=LP2_XorgHigh.sfs
will load the XorgHigh automatically at boot up. It goes straight to where the zdrv.sfs usually goes: /intird/pup_z.

However, I really don't care about the speed of booting the OS, if it has been done in 20, 40 or even 60 seconds etc.pp. since I'm usually brushing my teeth, washing my face, entering the bathroom or pulling off my clothes when returning to home, at such boot times. :lol:
Here's the module activate/deactivate script I have on puppy in use at the moment. I am a slob and should tart it up but it does the job.
Its in the right click rox menu and toggles load/unload.
Yes, I can load/unload SFS Modules by clicking it as well. Plus: I do have a Openbox menu Category (menu pipe), which offers to me all current loaded SFS Modules to be unloaded, when clicking its menu entry.

Sorry, but can't post an image at the moment, because I'm still using the MochiMoppelTest-called LazY Puppy 2.0.2-005 EN version by using the created save file - still works, but this version hasn't included above named Openbox feature.
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]

User avatar
RSH
Posts: 2397
Joined: Mon 05 Sep 2011, 14:21
Location: Germany

#50 Post by RSH »

dancytron wrote:I've mainly contributed by answering simple questions occasionally, but I've thought about this for awhile. I think to do what RSH is talking about, the first thing is to build an infrastructure that makes it accessible to mere mortals (as opposed to Woof, which is only accessible to real developers).

The first step is to produce a barebones main sfs file that only has what is necessary to install and run the system. Just the stuff to configure the hardware, a desktop, the Load SFS program, Remaster Script and Pupsaveconfig. That would be the base to allow creating a modular system. Pupsaveconfig lets you decide how to handle the save file. Load SFS lets you add modules to the system.

Then create another sfs that has setup utilities, including the PPM, Gparted, all the utilities to configure the desktop, all the utilities to create and edit pets and sfs files, etc etc. All the stuff to setup Puppy, as opposed to just use it.

Finally, you'd have a DevX sfs file that has the compiling tools just like it does now.

With these three pieces, you can then create sfs files to make a modular system, create pet files to install to save file (or use as a basis to remaster the main sfs file), use the PPM to install Ubuntu or Slackware packages to install to save file (or use to remaster the main sfs file), compile programs from the source etc.

It gives a lot of flexibility to create custom modular (or not modular) distributions without dealing with Woof.

Anyway, just a thought.
Hi.

This sounds like you could be the one to get involved in development of my latest version of the SFS P.L.U.S.!

If you are interested in this, let me know.

RSH
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#51 Post by mikeb »

Yes I notice fixmenus did some mad stuff making it slow..I hacked it down in lucid and dumped it a long time ago in the rest.
Xfce4 uses xdg desktop file handling so it just needs a trigger to refresh it when a module loads...at least the version on puppy does but its quick.

Hmm once upon a time '_525.sfs' on the end of an sfs would mean it would load at boot...no configs, no boot parameters...just add the file and done.
The simplicity of such a system was ok as a no brainer to get a modem module built before I knew anything about linux.

My speed point was that even with a bundle of modules there is only a few seconds involved....one reason is the usually contiguous nature of the sfs files. fast boots and shutdowns for that matter are more significant on anything battery powered....and for impatient users like me :D

Slax does things a little differently to puppy at boot.
It actually builds a bare union with ONLY the tmpfs for changes (or save file or folder) The modules themselves including the core system are all then loaded on-the-fly afterwards in the same manner as the finally booted system. Layer order is determined by the module naming order with say 001 at the bottom...zzz at the top so giving full control in that area. Does make for a very simple boot script....(the functions used are in a file which is common to the initrd and main system since they are identical) One other difference is there is one shared tmpfs for both modules and the read/write layer which does give a simpler picture of ram space usage. It also means there is no need to resize the tmpfs to fit in further modules and determining space left is easier. I tried sharing tmpfs on puppy and it worked but could not be done without moving certain union mount points so upsetting some scripts.

Dancytron...a build a bear puppy...like the slax live builder... always seemed like a good concept. Being modular the kernel can be a drop in too.

mike

User avatar
RSH
Posts: 2397
Joined: Mon 05 Sep 2011, 14:21
Location: Germany

#52 Post by RSH »

Hmm once upon a time '_525.sfs' on the end of an sfs would mean it would load at boot...no configs, no boot parameters...just add the file and done.
Nice option. Did never heard of that.

Sounds smarter to me than the so-called ADRV option made by jemimah (hm, can't remind the name of the OS, I think Carolina is a successor of it)
My speed point was that even with a bundle of modules there is only a few seconds involved....one reason is the usually contiguous nature of the sfs files. fast boots and shutdowns for that matter are more significant on anything battery powered
Ok, I see.

I'm only using desktop computers. Do not own any other and don't want to.
I tried sharing tmpfs on puppy and it worked but could not be done without moving certain union mount points so upsetting some scripts.
I doubt, I could do such things. So, seems that you are more an expert than I'm (of course I'm not).

However, I will try now to add to latest version of my SFS P.L.U.S. suggestion by mavrothal of ability to download SFS Modules at first boot (from CD) to be able to have some testings without to install the OS first.

I might be offline for a few days. Hopefully returning back to here exploring lots of new and interesting posts (maybe some more individual used solutions for a Modular Concept?).

RSH
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]

dancytron
Posts: 1519
Joined: Wed 18 Jul 2012, 19:20

#53 Post by dancytron »

RSH wrote: Hi.

This sounds like you could be the one to get involved in development of my latest version of the SFS P.L.U.S.!

If you are interested in this, let me know.

RSH
I'd be happy to do some testing and give feedback. I'm not sure if I'd be any help doing actual development.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#54 Post by mikeb »

The tmpfs merge was just to see if it can be done...its ok as is as tmpfs can be resized on the fly and I try to keep to the puppy layouts for compatability.

The _525.sfs was the puppy 1 and 2 way... a simple
ls /path/to/drive/*_${PUPPYVERSION}.sfs detected any sfs.

I added _uni.sfs for modules that are ok on many puppy versions such as thunderbird with _sfs4.sfs for later kernels.

Have offline fun

Mike

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#55 Post by sunburnt »

mikeb; Yes, I think you`re right that running aufs is it`s main cpu/ram load.
Adding more layers after that probably doesn`t effect things as much.
Which makes it pretty usable for what RHS is talking about.

# There`s a lot of terminology floating around.

no-install apps. = Any app. that`s ready to run ( SFS and AppDir ).
non-union = Using a image file ( Squash-SFS or Save ) without unioning it ( AppDir ).
AppDir = Same as RoxApp. Rox now calls RoxApp - Appdir.


# RHS; What`s your opinion of a bare O.S. with only base apps., using app. modules only.?
Reduces download bandwidth, and users don`t have to ask how to delete unwanted apps.
Only a dev. or two are needed to maintain the O.S., but many app. builders are needed.
.

User avatar
Moose On The Loose
Posts: 965
Joined: Thu 24 Feb 2011, 14:54

#56 Post by Moose On The Loose »

RSH wrote:
Moose On The Loose wrote:Doing it wrong can lead the the problem of incompatible shared libraries and the like.
Such would mostly be an (unsolvable) problem by using PET instead of SFS. Some of my LazY Puppy Systems have Jack Audio installed which conflicts with two of my VLC SFS Modules, because of different shared QT libraries
In the past, I have solved the library issue with scripts that set up links to stuff. It works out a lot like plugging and unplugging SFS. The programs can't be used at the same time when that is done.

I also can on some things get the source and do a compile with static linking. It makes the programs bigger but it can solve some shared library issues.

Since a pet is really just a TGZ archive, an "installer" could be made to create an SFS for each new thing you install as a pet so the SFS modularity method can be transparent to the user.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#57 Post by mikeb »

Version conflicts... the idea of building your apps on a base system so they will work is a valid one.... debian squeeze apps will work on debian squeeze.

Random packages built on random systems is the problem here and the desire to grab packages from the big boys who have a totally different build agenda.

The other way is to build on a system (the target one!!!!) that steps back a year or two.... much more likely to produce a universal result.... such as libreoffice do this. With puppy this probably makes the best sense as there are so many variations.

Static binaries... yes one approach ...again adopted by many builders especially games I find.... not just static binaries but statically linked libs so all is in one folder. The thoughts about the build system still apply...I cannot use most of the programs on portable linux as they are built on a recent ubuntu.

Building a system around rox is nice but hits the snag of what happens with a different desktop/window manager and file browser.

I think RSH is away for a few days so might be a while before he replies.

mike and his toes

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#58 Post by sunburnt »

Yep, as amigo keeps saying: Tool chain, tool chain, tool chain. Puppy badly needs one...
Yeah, most portable apps I`ve tried are not so portable. Good idea, bad implementation.
Ubuntu is bloated, but size isn`t important ( ask your girl friend :lol: ). Lots of good apps.
Any pkg. type has trouble changing WM, desktop, taskbar, themes, graphic tool kits, etc.
One of Puppy`s big sore spots ( sooo many...). And it would be a fairly easy one to fix too.

Amigo made a AppDir setup that compiles the app into a new AppDir. Very nice...
Source packages are easy to find, so my Virtual Apps package would go well with this.
It`s an empty AppDir except for scripts to download, compile, and setup. Very small.
This arrangement will support all the variants ( OR, just have one O.S., not many ).
That... Or each app builder makes app packages, one for each variant type ( NOT good ).

>>> Sorry for straying from the modularity theme RSH.
.
Last edited by sunburnt on Thu 07 Nov 2013, 07:01, edited 1 time in total.

User avatar
RSH
Posts: 2397
Joined: Mon 05 Sep 2011, 14:21
Location: Germany

#59 Post by RSH »

sunburnt wrote:Sorry for straying from the modularity theme RSH
Ha...

I'm not really straying from the modularity theme.

But, since Linus Torvald has had said: Talk is cheap, show me the code., there is always to do some work, to be able to show some code.

I want to show you the code, which still needs some work.

Doing long posts with facts and replying to replies takes a lot of time for me to do in EN. Really, you all can't imagine that from reading my posts.

Such time is often better used, when working on progress and/or suggestions.

Even such is hard for me to do, since I'm jumping from here to there, because each work on a new suggestion often offers new ideas to me, that also often have nothing to do with the suggestion to work on. It has just happened again!

However, lot's of new and interesting postings here. So, a short post is possible for me to do.

I have made some progress and therefor some good news to publish - maybe tomorrow (we'll see).

So, (as said in the old days): stay tuned!

RSH
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#60 Post by sunburnt »

Good to hear from you RSH, I was worried you`d become disgusted with your thread.

If my idea of Virtual Packages interests you, you should see what I have done.
Current work is on a general purpose world mirrors GUI for the Virtual Apps.

Post Reply