Debian Sticking With Merged /usr Plan

[Kano]

Some of the comments are really curious. First of all the /bin to /usr/bin symlink on usrmerged systems will be NEVER removed as there is a FHS standard.

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Second, the use of "#!/usr/bin/bash" or similar is absolutely bad style - you could use that for your private scripts, but if you publish them everybody with a not usrmerged distribution has to "fix" it.

Some really still think that /bin/sh points to /bin/bash by default. Little hint: since several years most distributions use dash for sh because of speed reasons - and for my part I had no big issues to remove most bashisms. The "&>" example is one of those trivial changes - it is shorter but if this is the "only" reason why you need bash in first case then you do something wrong. My goal is to write mainly POSIX compatible scripts which can be run by dash, some scripts use bash tricks, those have got bash in the shebang. Using bash all the time is bad style IMHO.

Last thing to mention is that all projects which want that there code is packaged by different distributions have to write portable code. That's becoming a little bit harder if you do some checks in a way that will only work on usrmerged systems. As many of you should know, I don't use Fedora or Arch to write my own scripts and most my scripts are not used outside of Kanotix (or Debian based systems) but I still write em as portable as reasonable - what should be the reason to write code that only runs on the latest distro of choice if the changes needed to write portable code are trivial?!

[Kano]

Most likely you don't publish your scripts or do you?

[ssokolow]

Some of the comments are really curious. First of all the /bin to /usr/bin symlink on usrmerged systems will be NEVER removed as there is a FHS standard.

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Second, the use of "#!/usr/bin/bash" or similar is absolutely bad style - you could use that for your private scripts, but if you publish them everybody with a not usrmerged distribution has to "fix" it.

Some really still think that /bin/sh points to /bin/bash by default. Little hint: since several years most distributions use dash for sh because of speed reasons - and for my part I had no big issues to remove most bashisms. The "&>" example is one of those trivial changes - it is shorter but if this is the "only" reason why you need bash in first case then you do something wrong. My goal is to write mainly POSIX compatible scripts which can be run by dash, some scripts use bash tricks, those have got bash in the shebang. Using bash all the time is bad style IMHO.

Last thing to mention is that all projects which want that there code is packaged by different distributions have to write portable code. That's becoming a little bit harder if you do some checks in a way that will only work on usrmerged systems. As many of you should know, I don't use Fedora or Arch to write my own scripts and most my scripts are not used outside of Kanotix (or Debian based systems) but I still write em as portable as reasonable - what should be the reason to write code that only runs on the latest distro of choice if the changes needed to write portable code are trivial?!

Agreed. That's why I always ensure shellcheck and syntastic are installed when I'm writing code, since it'll catch bashisms that slip through if you specify a non-bash shebang.

and that's why it's shit to rely on /bin/bash or /usr/bin/bash doing the right thing - there is nothing wrong with bashisms at all

I think you got that backwards. You just said "And that's why it's shit to rely on actually getting bash if you ask for bash." followed by a sentence which, as phrased, implies a reading of "There's nothing wrong with asking for "a Bourne-compatible shell" then depending on it being bash rather than dash."

[tuxd3v]

Looking at this plan to merge /usr/{bin,sbin,lib}/ on /usr..

I am more in favour of merging /run into /var/run, for several reasons..FHS 3.0 turned this backwards..
/var/run was already a very well established place for var data, and it could be used for systemd, and non-systemd usage, at all levels..

If systemd needs something new it could be /var/run/[ systemd | sockets | whatever ]
systemd could on startup mount the usual tmpfs, and then later bind to /var/run

It would be cleaner, and consistent.

[tuxd3v]

jesus christ!

the whole point of /run is that it is a tmpfs and available at EARLY BOOT while /var in fact can be a own partition/disk NOT available at that point of time and your comment shows why the systemd developers are a lot smarter as you haters (and yes, i know the bullshit you have posted in the past well)



how do you idiot imagine mount /var/run/systemd as tmpfs when the phyiscal drive /var is not mounted at that pointin time and so the subfolder don#t exist and what do you do when mounting /var fails?

Like I acknowledge before, /run is ofcourse a tmpfs, moron.
It doesn exist...then create it!!
You have /run in initramfs, why not /var...since its for variable data???????
Then, bind later the existing subfolders on /var/block_device_subfolders to /var, simply as that idiot.
And the system will start to be organised..


And I know systemd uses it,
That's what a lot of folks here are discussing..
And the unique response from you is that Debian is 7 years late, when I don't think so..

Because /{bin,sbin,lib} are of greatest importance than the shitty /run, since they are really needed( and I can have /run inside /var )..

How will you then, separate /lib from /usr/lib, or /bin from /usr/bin, or /sbin from /usr/sbin???

Or you will merge essential tools with non-essential tools?
Any clue sh*t head ?

/bin         - Essential command binaries that need to be available in single user mode; for all users, e.g., cat, ls, cp.
/sbin        - Essential system binaries, e.g., fsck, init, route.
/lib         - Libraries essential for the binaries in /bin and /sbin.
/lib<N>      - Alternative format essential libraries. Such directories are optional, but if they exist, they have some requirements.

/usr         - Secondary hierarchy for read-only user data; contains the majority of (multi-)user utilities and applications.[8]
/usr/bin     - Non-essential command binaries (not needed in single user mode); for all users.
/usr/include - Standard include files.
/usr/lib     - Libraries for the binaries in /usr/bin and /usr/sbin.
/usr/lib<N>  - Alternative format libraries, e.g. /usr/lib32 for 32-bit libraries on a 64-bit machine (optional).
/usr/local   - Tertiary hierarchy for local data, specific to this host. Typically has further subdirectories, e.g., bin, lib, share.[9]
/usr/sbin    - Non-essential system binaries, e.g., daemons for various network-services.
/usr/share   - Architecture-independent (shared) data.
/usr/src     - Source code, e.g., the kernel source code with its header files.
/usr/X11R6   - X Window System, Version 11, Release 6 (up to FHS-2.3, optional).

What I am proposing is to unify /var,
since /run was introduced, it was a drawback, in De-fragmenting Filesystem Hierarchy and you can just start by that place..

[tuxd3v]

becaue /var is for persistent data and /run for volatile data idiot

/var is for variable data, persistent or not, it should be there!!

you don't fucking idiot - modern distributions don't for 7 years now for damned good reasons - deal with it

Well a lot of them don't, for damn good reasons, deal with it idiot.

you don't fucking idiot - these days the essential tools when everything fails are in the initrd

So you want more things in initramfs?...fool and idiotic

other than your fucking sysvinit crap systemd and dracut knows an emergency mode

Well your systemd drap is always crashing and we have to be there to solve that sh*ty problems for the work of redhat incompetent people, who created it..

irrelevant crap from decades ago where you did not have an initrd in a wy you have these days
[/CODE]
Irrelevant, well that tools should't be irrelevant since are more primordial than other things..

What I am proposing is to unify [B]/var[/B],
since [B]/run[/B] was introduced, [U]it was a drawback, in De-fragmenting Filesystem Hierarchy[/U] and you can just start by that place..

it was not shithead - the whole point of /run is that it's volatile data but needs to be present for obvious reasons as soon as possible, /var *don't matter at all* at that point of time when boot the system

That /run should be in /var has a tmpfs, it doesn't make sense outside, its even ugly..
You like initramfs, so create /var in initramfs, and mount there a /run, we will bind on /var all the other folders needed to be persistent.
That should be the way from the beginning..

you little shithead still live in the 1970's but things changed dramatically, either suck it and deal with it or you and your little "knowledge" becomes meaningless, well you are already

No I just have more than 20 years behind keyboard, on Unix/Linux, and god knows what more..

You are just a crappy MS Windows boy,
With aspirations to be a Unix/Linux expert, but without following the Guidelines, and wanting it to be like MS Windows way..
Some sort of an Hybrid..

[tuxd3v]

and the additional complexity is deserved how?

huuhh,
So now you are preoccupied with the complexity of mounting correctly /run on /var ??
But you are not preoccupied with the problems that merging the following bellow will bring:

/bin         - Essential command binaries that need to be available in single user mode; for all users, e.g., cat, ls, cp.
/sbin        - Essential system binaries, e.g., fsck, init, route.
/lib         - Libraries essential for the binaries in /bin and /sbin.
/lib<N>      - Alternative format essential libraries. Such directories are optional, but if they exist, they have some requirements.

/usr         - Secondary hierarchy for read-only user data; contains the majority of (multi-)user utilities and applications.[8]
/usr/bin     - Non-essential command binaries (not needed in single user mode); for all users.
/usr/include - Standard include files.
/usr/lib     - Libraries for the binaries in /usr/bin and /usr/sbin.
/usr/lib<N>  - Alternative format libraries, e.g. /usr/lib32 for 32-bit libraries on a 64-bit machine (optional).
/usr/local   - Tertiary hierarchy for local data, specific to this host. Typically has further subdirectories, e.g., bin, lib, share.[9]
/usr/sbin    - Non-essential system binaries, e.g., daemons for various network-services.
/usr/share   - Architecture-independent (shared) data. /usr/src     - Source code, e.g., the kernel source code with its header files. /usr/X11R6   - X Window System, Version 11, Release 6 (up to FHS-2.3, optional).

And you even agree that lots of things could be in initramfs, so why not 2 f*ck!ng path's?
/var
/var/run
Why?

You want lots of stuff in initramfs,... but 2 paths is a lot for you...really??
Is that so much more work, than putting all needed tools and libs merged in /usr????
will you merge them with the other stuff??and the Other distributions out there??
You are only looking to your belly,
Wanting to create a lot of changes, but you complain in creating 2 paths in the initramfs, and fix what was broken several years ago, by the systemd folks...

[QUOTE=hreindl;n1085538]
the problem is that your state of mind is still the same as 20 years ago
[/CODE]
No,
The problem is that some people want only to introduce changes that interest for them, based on their Windows experience..
Kidding around, instead of thinking in gradual changes, that could actually beautify and clarify the Filesystem Hierarchy for newcomers..

/var
some_volatile_stuff:
run/{,lock,systemd_xyzw,rpc_stuff,locks} , and so on..
rest_of_variable_non_volatile_stuff:
{backups,cache,lib,local,log,mail,opt,spool,tmp}

Always reinventing the wheel,
And because of that, we start from almost zero always...without end...puff

[tuxd3v]

because /run won't be remounted in any way and has to preserve it#s state from the first second to avoid useless complexity

And who asked for remount?
Why you don't just mount it from beginning in /var( which is the correct place for it, by the way )????
yes, has a tmpfs...

nothing was broken, everything is working perfect in that context

little fucker most of that changes where gradual over the past 8 years, it's not my fault that you lived under a stone for that long

I am not your father,
If I were...believe-me you were a different kid, for sure
I would make of you a MAN, not a hybrid thing you are..

idiot!

Don't look in the mirror

most of the stuff below /var and especially /var/lib is *not* volatile, try "rm -rf /var/" and look where your databases, samba configs, package managment and so on is gone while /run don#t contain anything relevant after reboot and hence that two things are sepearated instead introcude complexity just because you little fucker have one folder less in /

You are such an idiot, that you don't even understand that before you were touching the keyboard I already knew that a lot of things in /var are persistent..
And If you were smart enough, you had already acknowledged, that I am precisely speaking about that..

when you can't distinct between reinventing the wheel and useful changes over nearly a decade it's your fault alone

Useful things??

What are the useful things, you are talking about?
Because until now, you spoke none!

[cybertraveler]

hreindl - Do you want to have arguments and create drama? If that's what you want, you're going the right way about it.

You know: assuming you're a conscious being with free will: you can choose how you want to be. Same for all of us.

So much damn drama on a tech forum :P

[tuxd3v]

don't you realize that /var can be a own partition or even a sepperated disk and so /var/systemd don't exist that early at boot and mount later a real filesystem on a non-empty mount-point maybe possible but is far away from clean and nice?

Of Course /var can be even a separate filesystem, and not be in root fs phisically..
I realised that some 20 years ago( but I passed the faze you are in .. )

Again, I was talking about this:

# df -hP /test
Filesystem      Size  Used Avail Use% Mounted on
[B]tmpfs[/B]           1.0M     0  1.0M   0% [B]/test[/B]
[B]# tree -L 2 /{var,test}[/B]
[B]/var[/B]
├── backups
├── cache
│   ├── apt
│   ├── cups
│   ├── debconf
│   ├── dictionaries-common
│   ├── fontconfig
│   ├── fonts
│   ├── ldconfig
│   ├── man
│   ├── PackageKit
│   └── pm-utils
├── lib
│   ├── alsa
│   ├── apt
│   ├── aptitude
│   ├── aspell
│   ├── avahi-autoipd
│   ├── colord
│   ├── dbus
│   ├── dhcp
│   ├── dictionaries-common
│   ├── dpkg
│   ├── emacsen-common
│   ├── exim4
│   ├── gconf
│   ├── ghostscript
│   ├── git
│   ├── hp
│   ├── initramfs-tools
│   ├── initscripts
│   ├── insserv
│   ├── ispell
│   ├── libreoffice
│   ├── libxml-sax-perl
│   ├── live
│   ├── logrotate
│   ├── man-db
│   ├── mecab
│   ├── misc
│   ├── mlocate
│   ├── nfs
│   ├── ntp
│   ├── os-prober
│   ├── PackageKit
│   ├── pam
│   ├── polkit-1
│   ├── python
│   ├── security
│   ├── sgml-base
│   ├── snmp
│   ├── sudo
│   ├── synaptic
│   ├── systemd
│   ├── tex-common
│   ├── texmf
│   ├── ucf
│   ├── udisks2
│   ├── update-rc.d
│   ├── upower
│   ├── urandom
│   ├── usb_modeswitch
│   ├── usbutils
│   ├── vim
│   ├── wicd
│   ├── xfonts
│   ├── xkb
│   └── xml-core
├── local
├── lock -> /run/lock
├── log
│   ├── alternatives.log
│   ├── apt
│   ├── auth.log
│   ├── bootstrap.log
│   ├── btmp
│   ├── ConsoleKit
│   ├── cups
│   ├── daemon.log
│   ├── debug
│   ├── dmesg
│   ├── dmesg.0
│   ├── dmesg.1.gz
│   ├── dmesg.2.gz
│   ├── dmesg.3.gz
│   ├── dmesg.4.gz
│   ├── dpkg.log
│   ├── exim4
│   ├── faillog
│   ├── fontconfig.log
│   ├── fsck
│   ├── gufw.log
│   ├── hp
│   ├── kern.log
│   ├── lastlog
│   ├── live
│   ├── messages
│   ├── ntpstats
│   ├── pm-powersave.log
│   ├── refractainstaller_error.log
│   ├── refractasnapshot_errors.log
│   ├── slim.log
│   ├── speech-dispatcher
│   ├── syslog
│   ├── ufw.log
│   ├── user.log
│   ├── wicd
│   ├── wtmp
│   ├── Xorg.0.log
│   └── Xorg.0.log.old
├── mail
│   └── mail
├── opt
│   └── vivaldi
├── run -> /run
├── spool
│   ├── anacron
│   ├── cron
│   ├── cups
│   ├── exim4
│   ├── libreoffice
│   ├── mail -> ../mail
│   └── rsyslog
└── tmp
[B]/test[/B]
├── backups
├── cache
│   ├── apt
│   ├── cups
│   ├── debconf
│   ├── dictionaries-common
│   ├── fontconfig
│   ├── fonts
│   ├── ldconfig
│   ├── man
│   ├── PackageKit
│   └── pm-utils
├── lib
│   ├── alsa
│   ├── apt
│   ├── aptitude
│   ├── aspell
│   ├── avahi-autoipd
│   ├── colord
│   ├── dbus
│   ├── dhcp
│   ├── dictionaries-common
│   ├── dpkg
│   ├── emacsen-common
│   ├── exim4
│   ├── gconf
│   ├── ghostscript
│   ├── git
│   ├── hp
│   ├── initramfs-tools
│   ├── initscripts
│   ├── insserv
│   ├── ispell
│   ├── libreoffice
│   ├── libxml-sax-perl
│   ├── logrotate
│   ├── man-db
│   ├── mecab
│   ├── misc
│   ├── mlocate
│   ├── nfs
│   ├── ntp
│   ├── os-prober
│   ├── PackageKit
│   ├── pam
│   ├── polkit-1
│   ├── python
│   ├── security
│   ├── sgml-base
│   ├── snmp
│   ├── sudo
│   ├── synaptic
│   ├── systemd
│   ├── tex-common
│   ├── texmf
│   ├── ucf
│   ├── udisks2
│   ├── update-rc.d
│   ├── upower
│   ├── urandom
│   ├── usb_modeswitch
│   ├── usbutils
│   ├── vim
│   ├── wicd
│   ├── xfonts
│   ├── xkb
│   └── xml-core
├── local
├── log
│   ├── alternatives.log
│   ├── apt
│   ├── auth.log
│   ├── bootstrap.log
│   ├── btmp
│   ├── ConsoleKit
│   ├── cups
│   ├── daemon.log
│   ├── debug
│   ├── dmesg
│   ├── dmesg.0
│   ├── dmesg.1.gz
│   ├── dmesg.2.gz
│   ├── dmesg.3.gz
│   ├── dmesg.4.gz
│   ├── dpkg.log
│   ├── exim4
│   ├── faillog
│   ├── fontconfig.log
│   ├── fsck
│   ├── gufw.log
│   ├── hp
│   ├── kern.log
│   ├── lastlog
│   ├── live
│   ├── messages
│   ├── ntpstats
│   ├── pm-powersave.log
│   ├── slim.log
│   ├── speech-dispatcher
│   ├── syslog
│   ├── ufw.log
│   ├── user.log
│   ├── wicd
│   ├── wtmp
│   ├── Xorg.0.log
│   └── Xorg.0.log.old
├── mail
│   └── mail
├── opt
│   └── vivaldi
[B]├── run
│   ├── acpid.pid
│   ├── acpid.socket
│   ├── agetty.reload
│   ├── alsa
│   ├── avahi-daemon
│   ├── blkid
│   ├── console
│   ├── ConsoleKit
│   ├── console-kit-daemon.pid
│   ├── console-setup
│   ├── crond.pid
│   ├── crond.reboot
│   ├── cups
│   ├── dbus
│   ├── dhclient.pid
│   ├── elogind.pid
│   ├── exim4
│   ├── initctl
│   ├── initramfs
│   ├── irqbalance.pid
│   ├── lock
│   ├── minissdpd.pid
│   ├── minissdpd.sock
│   ├── motd.dynamic
│   ├── mount
│   ├── network
│   ├── ntpd.pid
│   ├── pm-utils
│   ├── rpcbind
│   ├── rpcbind.lock
│   ├── rpcbind.pid
│   ├── rpcbind.sock
│   ├── rpc_pipefs
│   ├── rpc.statd.pid
│   ├── rsyslogd.pid
│   ├── screen
│   ├── sendsigs.omit.d
│   ├── shm
│   ├── slim.auth
│   ├── slim.lock
│   ├── sm-notify.pid
│   ├── sshd
│   ├── sshd.pid
│   ├── systemd
│   ├── udev
│   ├── udisks2
│   ├── user
│   ├── utmp
│   ├── uuidd
│   ├── wicd
│   └── xtables.lock[/B]
├── spool
│   ├── anacron
│   ├── cron
│   ├── cups
│   ├── exim4
│   ├── libreoffice
│   ├── mail -> ../mail
│   └── rsyslog
└── tmp

Can you know see that /test/run is **not** a symbolic link..?
The same can be made in initramfs for
/var
/var/run
instead of /test( used here only for tests purpose )

The Rest of the places were mounted from /var separated fs..

/run always made sense in /var, since its variable data.

http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/var.html

I know its old... but old doesn't mean bad, means knowledge..
And anyone is supposed to make is homework, before trying to reshape, respectable work..

frankly there is a lot of crap below /usr/share/locale, /usr/share/man, /usr/share/licenses and /usr/share/docs which is *real* ballast and not needed at all on most setups - when i have 100-300 MB useless crap on 40 vservers and than some clown like you comes with "my god there is a single folder with non-persistent data" i wish some asteroid makes that whole pile of shit of humanity an end

discuss about /run is as dumb as something can be

Yes there is some stuff, at locales level I agree that should only be locales for the system in use, and not for the "entire world"..

Well,
When some kids( coming from MS Windows ) were starting "assassinating" the Linux environment, and feed hate, and insulting everybody,
At that time...,
I just wished that some asteroid would come into that pile of flesh shit, so that they don't f*ck up the work, with their tinny mentality, that others are trying to do..

But you know what..,
Unfortunately, that desire doesn't happened..