Hi everyone. During the release of recent versions of openSuse, I remember seeing discussions in this forum about making future versions of openSuse immutable. After installing openSuse Leap 16.0, I noticed that I didn’t have a bin directory for my normal user login. Can anyone tell me if this is probably a consequence of something going wrong during the installation process, or if this is supposed to be a gentle nudge to let me know I should be getting used to using user-created scripts in some completely different way because openSuse is about to become immutable?
I didn’t really do anything particularly noteworthy during the installation process. I thought it was strange that, unlike the installers for pervious versions of openSuse Leap, when I changed the first language option from EN-US to EN-GB, the change did not cascade through the rest of the installer’s options, but that was the only thing of note in the whole process.
Can someone please tell me if this missing ~/bin directory is intentional please? The /root/bin directory is present and empty like I’d expect for my normal user login, though.
Normally “/etc/skel” is used as a skeleton for initializing the user home. And the content of “/etc/skel” is much smaller in Leap 16.0 than it was in Leap 15.6.
This change has nothing to do with whether or not immutability becomes a part of the standard distributions (I haven’t seen anything that suggests that is happening; Aeon and Kalpa, along with MicroOS are the immutable variants for those who want that).
Well that’s a relief. The discussions I’m talking about were happening when a version of openSuse Leap had just been released. I think was around the release of 15.2. I’m glad to see that openSuse Leap isn’t on the path to becoming immutable. So does this mean I should be fine to make a $USER/bin directory and use it as normal, or is the absence of the directory still intended to be a hint about something?
As best I recall, $HOME/bin was traditionally used in unix. But if you wanted that, you had to create if for yourself. And, by the way, configuration files such as “.profile” you also had to create for yourself.
Well, the /etc/skel directory has been in use for a long time. It apparently first appeared in the late 80s as part of AT&T SVR4 dating to circa 1989. I found some references to it in some SunOS release 5.7 documentation (which is a bit more recent, late 90s/early 2000s).
That was it - I was trying to remember/find the info about it, but hadn’t been able to locate it. The factory discussion was much longer ago than I thought it was.
An immutable operating system is about making the “system files” read-only. The user part, that includes all in a users home directory, is of course not part of that. A user can always create change and/or remove files from within his/her home directory. Thus the question as formulated in the title (and answered above) has nothing to do with immutable operating system.
BTW, re the existence or not of ~/bin.
When it isn’t there (created by useradd using /etc/skel) and you need it and thus created it yourself, you should then be sure it is in your PATH variable, else it still does not function as it did by default earlier.
You’re absolutely right, Henk. Thanks for the conceptual correction. I thought immutability would be intended to make system files read only and to prevent modification/creation of anything executable by a regular user. That way they’d be protected from doing something like running a script they found lying around on the internet, that might contain an as-yet unknown privilege escalation exploit.
Aha! Exactly the kind of answer I was hoping for.
Hah! Well I guess if anything illustrates my need for my own $HOME/bin directory, where I can put scripts that only I will need to use because I don’t use the commands/variables often enough to stop me forgetting them or getting mixed up, I guess it’d asking “where did my $USER/bin directory go?”
I knew there was something I’d have to do if I were to create the bin directory manually, but I couldn’t remember exactly what it was. This looks like exactly that thing. I went with what @malcolmlewis said because that was the cleanest solution and meant I wouldn’t have to modify anything, but thanks for the reminder.
User-specific executable files may be stored in $HOME/.local/bin. Distributions should ensure this directory shows up in the UNIX $PATH environment variable, at an appropriate place.
That may be, but why? $HOME/bin is as good as that one. And in openSUSE it was created at user creation and also included in the PATH. A good default action IMO.
So many people, so many ideas. But in the end every user might decide for her/himself.
And in ~/.local there is all sort of stuff that is stored there by all sorts of applications. A place where a user most of the time does not know what is there and barely goes there.
OTOH ~/bin is a good visible place with a revealing name.
