Re: Docs and Porteus info. don`t give clear picture.
Posted: 12 Aug 2012, 21:29
I use aufs in Puppy all the time, Now I`m using it in Porteus for the first time.
It`s great for those who insist on messing with the file systems ( like us...).
But little ever needs to be changed in a working O.S. that`s not a test bed.
The base Squash file is small, 30-50 MB with xorg, quick for users to rebuild.
Ultimately my envisioned O.S. is ment for users, not tinkering.
I suggested at the Puppy forum to make the union an option ( no interest ).
But I understand that they`re very happy with Puppy the way that it is.
wread; That may have been a better place for this discussion.
As usual I tend to get into related subjects that should probably have their own thread.
fanthom; Dividing R/W and R/O throws most folks who have seen this idea.
And it does limit what can be done with the file system by the user.
It`s good in the case of noobs and normal usage: web stuff, media, docs, etc.
But this is the proper foundation for a well designed "Squash file based" O.S.
It`d be nice to reorganize Linux along these lines, but that`d be way too much work.
The apps. are modded AppDir packages ( Rox ). AppPkg will do more than AppDir will.
They can contain multiple apps., with self-contained or shared deps., or mixed usage.
In the case of clicking an AppPkg containing multiple apps. a selection menu pops up.
They`re kept in a dir. and used from there. Only 2-3 links are needed for each app.
One link for each of the app`s dir./files that are in /usr/share:
/usr/share/applications/(App).desktop ___ ( for sys. menu / desktop )
/usr/share/pixmaps/(App).png ___________ ( for sys. menu / desktop )
/usr/share/(App) _______________________ ( for dep. dir. "if needed" )
# And, I don`t intend for Porteus to change, it`s just ideas...
brokenman; Yes, an O.S. with a good tool chain should have no problems.
A poor tool chain results in conflicting apps. and broken libs. To name a few...
I got my test O.S. working by modding Tiny Core Linux as it has no union.
Puppy with so many boot methods and the union = complex boot scripts.
I realized that the app. packages were the critical part, so I made AppPkg.
It`s great for those who insist on messing with the file systems ( like us...).
But little ever needs to be changed in a working O.S. that`s not a test bed.
The base Squash file is small, 30-50 MB with xorg, quick for users to rebuild.
Ultimately my envisioned O.S. is ment for users, not tinkering.
I suggested at the Puppy forum to make the union an option ( no interest ).
But I understand that they`re very happy with Puppy the way that it is.
wread; That may have been a better place for this discussion.
As usual I tend to get into related subjects that should probably have their own thread.
fanthom; Dividing R/W and R/O throws most folks who have seen this idea.
And it does limit what can be done with the file system by the user.
It`s good in the case of noobs and normal usage: web stuff, media, docs, etc.
But this is the proper foundation for a well designed "Squash file based" O.S.
It`d be nice to reorganize Linux along these lines, but that`d be way too much work.
The apps. are modded AppDir packages ( Rox ). AppPkg will do more than AppDir will.
They can contain multiple apps., with self-contained or shared deps., or mixed usage.
In the case of clicking an AppPkg containing multiple apps. a selection menu pops up.
They`re kept in a dir. and used from there. Only 2-3 links are needed for each app.
One link for each of the app`s dir./files that are in /usr/share:
/usr/share/applications/(App).desktop ___ ( for sys. menu / desktop )
/usr/share/pixmaps/(App).png ___________ ( for sys. menu / desktop )
/usr/share/(App) _______________________ ( for dep. dir. "if needed" )
# And, I don`t intend for Porteus to change, it`s just ideas...
brokenman; Yes, an O.S. with a good tool chain should have no problems.
A poor tool chain results in conflicting apps. and broken libs. To name a few...
I got my test O.S. working by modding Tiny Core Linux as it has no union.
Puppy with so many boot methods and the union = complex boot scripts.
I realized that the app. packages were the critical part, so I made AppPkg.