Docs and Porteus info. don`t give clear picture.

Post here if you are a new Porteus member and you're looking for some help.
SunBurnt
White ninja
White ninja
Posts: 13
Joined: 05 Aug 2012, 20:24
Location: Arizona, U.S.A.

Re: Docs and Porteus info. don`t give clear picture.

Post#16 by SunBurnt » 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.

User avatar
mr_hero
Black ninja
Black ninja
Posts: 43
Joined: 10 Jul 2014, 01:33
Distribution: Porteus
Location: germany

Re: Docs and Porteus info. don`t give clear picture.

Post#17 by mr_hero » 21 Jul 2014, 12:20

Ever thought about a solution for discreet division of modules?
I mean some way to isolate the modules in a way that they always prefer the libs
inside their own layer.
This would make programs (and modules) backward-compatible as long as they are
shipped with a complete set of libs.

If I got it right, all porteus-modules have to be recompiled once a year, when a
new major slackware-version (and therefore also a new porteus-version) was
released.

Upgrading porteus is a pain in the ass this way because not every program is
running with different (newer) libs. Custom system-modifications may become invalid.

The problem is that in case of dublicate libraries (based on several versions from several modules) only the versions from the last activated modules is visible to the system. A program in need for an older version can't access that version of a distinguished lib, though it's layer is active because the layers on top of it will cover it.

At least I think porteus behaves this way. Please correct me if I'm wrong.

User avatar
brokenman
Site Admin
Site Admin
Posts: 5439
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Docs and Porteus info. don`t give clear picture.

Post#18 by brokenman » 21 Jul 2014, 18:30

I mean some way to isolate the modules in a way that they always prefer the libs inside their own layer.
Interesting idea. Not sure if the preference is modifiable but this could become well complicated.
From the wiki:
When mounting branches, the priority of one branch over the other is specified. So when both branches contain a file with the same name, one gets priority over the other.
If I got it right, all porteus-modules have to be recompiled once a year
Not necessarily ALL but it is safer. Slackware recompiles everything for even minor version changes.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
fanthom
Site Admin
Site Admin
Posts: 4547
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: Docs and Porteus info. don`t give clear picture.

Post#19 by fanthom » 21 Jul 2014, 21:06

I mean some way to isolate the modules in a way that they always prefer the libs
inside their own layer.
i think GOBO linux does that so you may have a look on it. i dont think it's possible to do the same in porteus with aufs.
Please add [Solved] to your thread title if the solution was found.

User avatar
mr_hero
Black ninja
Black ninja
Posts: 43
Joined: 10 Jul 2014, 01:33
Distribution: Porteus
Location: germany

Re: Docs and Porteus info. don`t give clear picture.

Post#20 by mr_hero » 25 Jul 2014, 12:00

brokenman wrote: If I got it right, all porteus-modules have to be recompiled once a year


Not necessarily ALL but it is safer. Slackware recompiles everything for even minor version changes.
I didn't want to offense you. Release cycles are ridiculous short these days. Fedora stops support for every distribution after a year. Firefox releases every six weeks. Worst thing is that the whole linux-development isn't balanced often. E.g. libavtools released a new version a couple of weeks ago. It renders all dependent software useless, when installed. :fool: K3B, Avidemux, countless encoders and even some parts of KDE need to release new compatible versions to support the libraries. Of course they don't do it. Result: Installing these new libs is a trap to mess up the system. Don't know what's going on with these guys at libav-dev-team but it looks a bit crazy. Thing is this is perfectly normal in linux-world: Software usually is not backwards-compatible and the programs depend on each other.
Another story is the new Xorg-server not being compatible with "old" ati-cards (older than 2010). Ati decided not including drivers for HD2000-HD4000-cards in it's catalyst-package, about a year ago. At this time the newest unsupported graphics-card was only three years old! The legacy-drivers (released as an own package) don't get updated anymore and the Xorg-developers didn't get the idea (until today) making their upcoming release backward-compatible. Because of these "super-heros" all owners of "old" graphics cards have to buy new hardware when they want 3D-support in linux.

Can you give me a link to the mentioned wiki of aufs? I didn't find it on google? I've heard chroot can isolate environments in linux. Maybe combination of both (auf and chroot) is possible. I wanna study the wiki.

User avatar
brokenman
Site Admin
Site Admin
Posts: 5439
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Docs and Porteus info. don`t give clear picture.

Post#21 by brokenman » 25 Jul 2014, 14:19

No offense taken. You forgot to mention two main offenders. GTK3 and Gnome3. I gave up in the end, always having to rebuild and something gets broken.

Just paste the quote above into google to find the wiki.
http://en.wikipedia.org/wiki/UnionFS

aufs is Another Union File System
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
mr_hero
Black ninja
Black ninja
Posts: 43
Joined: 10 Jul 2014, 01:33
Distribution: Porteus
Location: germany

Re: Docs and Porteus info. don`t give clear picture.

Post#22 by mr_hero » 31 Jul 2014, 12:36

Thanks.
I'm surprised there are so many projects like unionfs. I thought there is only one. The wiki-page lists:
aufs
overlayfs
UnionFsFuse
Plan 9 from Bell Labs operating system
The GNU Hurd has UnionFS.
mhddfs
Translucent File Service in SunOS 3, circa 1986.
JailbreakMe 3.0
UbuntuLTSP,
Searching for one with a in-branch-feature (within the listed filesystems) led me to aufs (again). It's homepage has a feature -list. Some features sound promising:
- no glibc changes are required.
- pseudo hardlink (hardlink over branches)
- allow a direct access manually to a file on branch, e.g. bypassing aufs.
including NFS or remote filesystem branch.
At top of the page it reads:
- dynamic branch manipulation, add, del.
- etc...
Now I'm really curious what "etc" means and if dynamic branch manipulation in fact was the feature we are looking for. Unfortunately the website doesn't provide more details about that. However the feature in the fisrt quote "allow a direct access manually to a file on branch, e.g. bypassing aufs" seems already pretty close to a layer-preferred access of files.

Post Reply