Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 26 Oct 2014, 04:04
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Suggestions
Follow the /opt standard for added software
Moderators: Flash, Ian, JohnMurga
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 2 of 3 Posts_count   Goto page: Previous 1, 2, 3 Next
Author Message
Q5sys


Joined: 11 Dec 2008
Posts: 1073

PostPosted: Sat 17 Dec 2011, 13:54    Post_subject:  

Aitch wrote:

I guess Barry really needs to chip in on this, though I'm glad it's being discussed....thanks for starting a new thread, Q5sys Very Happy

Imagine a possible future headline:
Quote:
Download Puppy Ver.xxx - with the first ORGANISED linux file system


Oh no, it's that dreaded word again.....where's everyone gone....? Wink Laughing

Aitch Smile


cough cough... you mean 'organized'. Silly Brit's putting a 's' where a 'z' goes. Wink

Yea it would be nice if Barry would give us his thoughts. I personally like /opt because it keeps things neat and tidy. I am not a zealot for the idea though. Us talking it out and getting everyones ideas and opinions on the matter is really the best benefit of this thread.
When the idea came in the slacko thread, i realized (Aitch, notice the z there, Wink haha)... wow, I have no clue what anyone elses opinion on this issue is.


(and if anyone cant tell, my s vs z banter is just sarcasm from a colonial to a royalist. Wink heh)

_________________



Back to top
View user's profile Send_private_message Visit_website 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Sat 17 Dec 2011, 14:19    Post_subject:  

Iguleder wrote:
Wow, so much ... anger Laughing

Let me explain why I like putting packages under /opt. There are three reasons for this.

First, these packages I built may conflict with the built-in ones and they're "unofficial", or, as some of you may describe them, optional. Packages such as libav (the FFmpeg fork) have the same file names and I don't want to ruin users' systems.

Second, /opt is extremely useful for whole suites of packages that need to be separated from the core system. A good example for this is Trinity (the KDE 3.x fork), which depends on Qt3. Since we don't want conflicts between Trinity and KDE (or between Qt3 and Qt4), putting it under /opt/trinity brings two major advantages: packages do not even attempt to link against Trinity or Qt3 (since this is a "non-standard" path) and the system is much more organized and elegant, since Trinity has dozens of executables and libraries, which get installed in their own directory instead of getting merged with /usr, which is messy anyway.


Iguleder does a nice job explaining the situations in which opt should be used. Opt is for portable apps or those that don't play nice with the rest of the os.

Compiling everything as a portable app is convenient for the user, but not small.

Generally it's good to keep things out of /usr/local - reserve that for the user's local programs.

Personally, I don't think moving a bunch of stuff to /opt makes things any less confusing.

What I do is make a rox-app (done using a script added to the end of fixmenus) for each menu item and put it in /root/my-roxapps. This makes it easy to find your apps and put them on the desktop and you don't have to care where they are in the filesystem.
Back to top
View user's profile Send_private_message Visit_website 
Aitch


Joined: 04 Apr 2007
Posts: 6825
Location: Chatham, Kent, UK

PostPosted: Sat 17 Dec 2011, 14:28    Post_subject:  

Ah, thanks Jemimah
I was just coming back to say I'd posted a link here in the Saluki thread, and Barry's Blog

Quote:
cough cough... you mean 'organized'. Silly Brit's putting a 's' where a 'z' goes Wink


Now, now, no 'cross the pond wars' please....if the English had their way, you'd all fail your English exams.... Laughing

Thankfully, the world's full of foreigners....

Aitch Smile
Back to top
View user's profile Send_private_message 
Q5sys


Joined: 11 Dec 2008
Posts: 1073

PostPosted: Sat 17 Dec 2011, 14:46    Post_subject:  

Aitch wrote:


Quote:
cough cough... you mean 'organized'. Silly Brit's putting a 's' where a 'z' goes Wink


Now, now, no 'cross the pond wars' please....if the English had their way, you'd all fail your English exams.... Laughing

Thankfully, the world's full of foreigners....

Aitch Smile


the funny thing is I still catch myself spelling colour with a 'u'. One of my elementary teachers was British and she taught us the 'proper' spelling of those words. However the rest of my teachers in my educational career did not appreciate that trend. haha
I got nothing but love for the Brits, still hoping to marry a sweet British girl one of these days. haha

_________________



Back to top
View user's profile Send_private_message Visit_website 
mavrothal


Joined: 24 Aug 2009
Posts: 1705

PostPosted: Sat 17 Dec 2011, 16:00    Post_subject:  

/opt make sense only for cross-distribution apps (Browsers, OOo) trying to navigate the plethora of linux variations and file system trees out there. For any given one distribution, not only it does not make sense but is a call for trouble. Apps put their files in /opt so will not conflict with distro files. If you start putting distro files in /opt, you are just inviting these conflicts!
Frankly, I doubt if a more rational and consistent file system tree was commonplace, the need for /opt would emerged.

The (arguably) most bleeding edge distribution, the one backed up by the (certainly) most successful Linux enterprise, Fedora, is moving this way with their next release, Fedora17. Here is why.
So consolidation is the name of the game. Not further dispersion.

For local/experimental stuff there is $HOME or /root/my-applications (in puppy) or anything the user wants. But not for "distro" stuff.

_________________
Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too Very Happy
Back to top
View user's profile Send_private_message 
Bert


Joined: 30 Jun 2006
Posts: 953

PostPosted: Sat 17 Dec 2011, 18:11    Post_subject:  

jemimah wrote:

Compiling everything as a portable app is convenient for the user, but not small.


The question I think is: who cares about size nowadays, when the apps live outside of the save file?

How much longer will we try to cramp modern apps into an archaic and questionable file system?

In the end only the user's convenience will count. Not some theoretical or historically grown concept.

More importantly, how will Linux ever become more mainstream, if it cannot come up with some sort of apps standard that works for everyone, everywhere? I've seen huge wastes of time and energy in the many linux forums I follow, because of old and stubborn patterns obstructing progress.

I don't pretend to know the answers, these are just my observations after years of patient reading.

_________________


Back to top
View user's profile Send_private_message 
Flash
Official Dog Handler


Joined: 04 May 2005
Posts: 11122
Location: Arizona USA

PostPosted: Sat 17 Dec 2011, 21:20    Post_subject:  

I agree with Bert. I run Puppy from a multisession DVD in a computer without a hard disk drive but lots of RAM. I keep Puppy small so it boots quickly from the DVD. Puppy comes with a good selection of application programs, so I don't need to install many more. Small apps that I find very useful (such as tree) I install and save on the Puppy DVD, but large programs, or programs I don't use very often, I save as .pets on a separate flash drive and reinstall them each time I need to use them.. Since I don't usually save to the DVD when I shut down, these do not cause bloat on the DVD.

So anyway, applications-in-a-directory (ROX-apps?) that are compiled with all their dependencies are far less of a problem for me than trying to figure out how to make a program work that is scattered all over the operating system and leaves its dependencies as exercises for the reader. Mad
Back to top
View user's profile Send_private_message 
scsijon

Joined: 23 May 2007
Posts: 1047
Location: the australian mallee

PostPosted: Sat 17 Dec 2011, 21:44    Post_subject:  

Personally,

For anything that is source independant and small, I follow the normal structure, however anything large or source dependant I've always used /opt.

Means if it 'craps out' it's easier to cleanup.

Like with my qt stuff, lib is not a small set, creator and developers all big, apps are small but are qtdependant so will be in /opt;

but games belong in /var/games and that's where I put them;

the other common base (generic) 'stuff' will go as normal into /usr/local or /usr/share depending on their structure and size;

also /opt can be a link to another partition as I have, means I can move and resize as I need to, without affecting my base or as I have two bases using a common /opt, easier to work, test and play with.

scsijon
edit: just realized that I left out copying the last line across "links to the apps in all cases added to /root/my-applications/bin when needed", sorry about that.

Edited_time_total
Back to top
View user's profile Send_private_message Visit_website 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Sat 17 Dec 2011, 22:47    Post_subject:  

Before anyone starts doing this insanity, echo $PATH and $LD_LIBRARY_PATH

If the place you are putting the binaries/libraries is outside of those ... There are several things that need to be considered ... I'm not going to get into the details but trust me ... It's more of a hassle than its worth. And IMHO much easier/better to use other methods during build.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send_private_message 
Plume

Joined: 12 May 2008
Posts: 34

PostPosted: Sun 18 Dec 2011, 12:41    Post_subject:  

My /opt is a symlink to a separate partition which is shared by all the linuxes installed on my PC. In this place stand libreoffice and opera for instance. On an other PC I have kde coming from Slax (hard installed) in /opt and kde can be used by my Vector Linux as well.
Back to top
View user's profile Send_private_message 
JegasLLC

Joined: 19 Dec 2011
Posts: 4

PostPosted: Mon 19 Dec 2011, 14:36    Post_subject: Why the opt standard?
Sub_title: Let the haters (of standards) continue hating lol
 

/opt has been around forever

it's less wordy (keystrokes) than /home/[username]/my applications/

Who ever started putting spaces in directory paths? Its Micro-Lame in my opinion - sorry, short tangent.

I find cd /opt to get to my master list of OPTIONAL software quite brief, intuitive and fast.

I'm glad the majority are following suit with the ground work on the best Operating System that was ever available... and what the entire Linux movement is based on.

I will say along with one of the early posters in this thread that I find /usr/local and /usr ambiguous and of little value as a standard. opt makes it really clean to "remove" all your optional software in one pass (less /etc/opt/ data if present) Even though /usr and /usr/local have always been around, I think two tiers makes it complicated. if /usr/ was non OS specific/user area alone I'd probably not even give it a second thought.

Go OPT - It's not an Option (hehe) Cool
Back to top
View user's profile Send_private_message 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Tue 28 Feb 2012, 03:34    Post_subject:  

technosaurus; Unless the libs. are seldom used, then statically compile them into the app. If they`re not shared then why share them?

/opt is just another place to put stuff, as if Unix didn`t already have enough.

Consolidating all of the Unix dirs. is like loosing all of it`s other legacy crap... GOOD !
Legacy drivers, boot methods, dependence on the initrd.gz file. And probably most of all using a legacy loose file setup for read-only files.
Back to top
View user's profile Send_private_message 
amigo

Joined: 02 Apr 2007
Posts: 2262

PostPosted: Tue 28 Feb 2012, 05:44    Post_subject:  

"Consolidating all of the Unix dirs" *requires* the use of an initrd. If it weren't for all the 'legacy crap' no distro would work at all. Only because some basic assumptions are made, can things work together reliably. Imagine if every application had to search your entire system to look *everywhere* for the resources it needed.

This brings up the idea of adding a unique PATH and/or LD_LIBRARY_PATH element for each weirdly-located program or library. What that does is add more work for the system to look for these things. Most systems set up a PATH with 4-5 elements for normal users, LD_LIBRARY_PATH is normally unused and ld-linux.so.2 (the linker which actually runs your programs) looks in about 4-5 locations for libraries. So, when you 'run' a program -say from a terminal window, you tell the shell "run wget". So, the shell starts searching each element of the PATH until it finds wget. The the shell tells the *kernel* ro run the program. But, the kernel doesn't do this itself. It tells ld-linux.so.2 (BTW it fully *expects* to find ld-linux.so in a *known* location. You can change that location and name of course, by patching the kernel) -anyway, the kernel tells ld-linux.so to run the program. ld-linux begins reading the ELF header of the program to find out which libraries the thing is gonna need, if any(still has to look to see). If it needs libs, then ld-linux loads them first into RAM and dynamically links them to specific locations which it passes to the executable whe it finally runs it. So, adding elements to PATH or LD_LIBRARY_PATH or in /etc/ld.so.conf -did I mention that the linker of course will look specifically for /etc/ld.so.conf and not over the whole system?

Many of the old conventions' original motivations are no longer important for most users. But, meanwhile, innovative folks have found imaginative ways to use these assumptions/conventions to good use. The whole idea of a LiveCD relies an several of these 'crap' ideas which were made real by someone -the first LiveCD was out in 1993, IIRC.

I went through a phase where I also thought that the Linux VFS should be renamed and reorganized. I even built an example project which used a naming scheme like gobo does(long before gobo existed) -but using truly-modified paths. That approach is very high maintenance because it requires patching nearly every program and lib you want to use. I came to my senses... Apple OSX took the more reasonable approach -the kernel's VFS is unchanged -only the virtual representation of it we see. Even from the CLI, the file-system is highly virtualized. I mean, we aren't seeing raw disk block numbers there -even they are a virtualization! So, all you really need to make every 'real' underlying structure disappear, is to have shell and/or GUI which changes the way you 'see' the file system. Simple!

Somehow I find it strange that the same people who promote a dynamic and modular system might want to shun the great existing modularity and flexibility which is already available. Running from RAM is only possible because someone had a great idea a long time ago. The concept of the initrd *followed* the ramdisk concept.

UNIX gave us lots of compartments as standard -each with its' own well-thought-out motivation and implementation. They gave us enough that we rarely need to do any invention -and if we feel we must, they gave us /opt for that. If it needs to look or feel different, you can always change each little aspect in the way that you like -because they thought of that too!
Back to top
View user's profile Send_private_message 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Tue 28 Feb 2012, 17:11    Post_subject:  

Yes, we do not want to increase the length of the paths too much. And I don`t suggest removing "needed code" from the kernel ( of course ).
The initrd makes a boot time pre-run environment allowing for many different O.S. setups. How about booting from a Squash file instead?
The kernel already has Squashfs included, it`s just another type of image file. Boot directly to Puppy`s main SFS file ( requires a kernel mod. ).

Unix and Linux work very well the way they were designed. That doesn`t mean that they can`t be improved any. Simplify is almost always a good idea.
Boot devices and storage, network and I/O connections, attached user interface devices all have new additions and also the loss of legacy ones.

Choice pup added lib. paths for each Squash app. file it "linked". I told him that this was not necessary, that there were much better ways to do it...

No intent on shunning any of the Linux setup, but depreciating legacy items for better methods is the standard manner of change in Linux.
Back to top
View user's profile Send_private_message 
DocSalvage


Joined: 30 Jun 2012
Posts: 10
Location: Tallahassee, FL, USA

PostPosted: Sun 14 Oct 2012, 02:43    Post_subject:  

I agree amigo.

Just like a society, any system that works well enough to last as long as *nix is going to carry a lot of "cruft" and remnants of past attempts at standardization. Doesn't mean we give up. Just means we try to understand the history of what was done and why, so we can improve on it instead of making the same mistakes. It's called "progress."

re: /opt
Neither Ubuntu nor Puppy put anything in /opt as distributed so I've taken to using it as an "optional filesystem structure" to make administration easier. In keeping with the spirit of several posts like those amigo points to, I use /opt to bring all the desparate pieces of a given software package together by way of symlinks. So /opt looks something like...
Code:

    /opt/gdm
    /opt/ntop
    /opt/picasa
    /opt/rsync
    /opt/samba
    /opt/ssh
    /opt/synergy
    /opt/X11


In each subdirectory will be symlinks to the configuration files in /etc, the binaries (wherever they are), log files, etc. This gives me a 1-stop place for managing daemons and other packages. Shell scripts in particular are simplified.

re: Consolidating large directories like /bin and /usr/bin
Though commandlines are second nature to most of us, when you just want to get something done without having to remember syntax details, nothing beats a GUI. I've found most file manager GUIs choke on directories with hundreds of files. This admittedly is an implementation issue, best solved by pagination in the GUI, but the fact remains that most of them don't and we don't have time to rewrite every tool we use.

File manager authors need to recognize the move towards consolidation and make their tools handle it better by using background processes and things so control can be returned to the GUI before every file is read. In the meantime, consolidation proponents need to keep these real-world limitations in mind when dealing with directories that are already massive.

re: Read-Only vs. Read-write filesystems
I very much like the layered filesystem approach of unionfs/aufs that Puppy has adopted. It's one of the main reasons I'm switching. Adding this 3rd dimension to filesystem structure goes a long way in simplifying the locating of resources and thus improving reliability of installs and operation.

_________________
DocSalvage
www.softwarerevisions.net
Back to top
View user's profile Send_private_message Visit_website 
Display_posts:   Sort by:   
Page 2 of 3 Posts_count   Goto page: Previous 1, 2, 3 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Taking the Puppy out for a walk » Suggestions
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1231s ][ Queries: 12 (0.0064s) ][ GZIP on ]