Announcement

Collapse
No announcement yet.

Debian Sticking With Merged /usr Plan

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by DanL View Post

    Yes, you are missing that this news is about Debian and not Arch. So is there a point to your comment other than you being a typical Arch Linux fanboy/girl?
    The news is about the /usr merge. I guess my point is that 1) Debian is a little behind as others have done it along time ago 2) the sky didn't fall in 3) I'm surprised it is even still being discussed. Thanks for the rudeness.

    Comment


    • #62
      Originally posted by LaeMing View Post
      Is /bin read/write? /sbin?
      you are getting it backwards. you can read from readwrite partition. you can't write to readonly one. main benefit of readonly /usr is it can be shared between many systems. but to answer your question, they are both readonly and symlinked to /usr/{s,}bin
      Originally posted by LaeMing View Post
      Is there any rule against direct sub-folders of root not being read-only? (Obviously not since, as you so sagely pointed out, /usr is read-only)
      obviously 3 separate readonly mounts is 3 times more than 1. and how your stupid idea of ditching /usr would work in this case? by making 15 readonly submounts in / and symlinking /usr/* to them?
      Last edited by pal666; 03-07-2019, 09:14 PM.

      Comment


      • #63
        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/Filesy...archy_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?!

        Comment


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

          Comment


          • #65
            Originally posted by Kano View Post
            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/Filesy...archy_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.

            Originally posted by hreindl View Post

            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."

            Comment


            • #66
              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.

              Comment


              • #67
                Originally posted by hreindl View Post
                systemd developers are a lot smarter as you haters
                People who reinvent the wheel and with poorer results are not smart. Their fans are fanatic maniacs, who shout for jesus and call other people idiots.

                Comment


                • #68
                  Originally posted by hreindl View Post

                  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 ?

                  Code:
                  /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..
                  Last edited by tuxd3v; 03-09-2019, 04:06 PM.

                  Comment


                  • #69
                    Originally posted by hreindl View Post
                    becaue /var is for persistent data and /run for volatile data idiot
                    /var is for variable data, persistent or not, it should be there!!

                    Originally posted by hreindl View Post
                    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.

                    Originally posted by hreindl View Post
                    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

                    Originally posted by hreindl View Post
                    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..

                    Originally posted by hreindl View Post
                    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..

                    Code:
                    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..
                    Originally posted by hreindl View Post
                    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..

                    Originally posted by hreindl View Post
                    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..
                    Last edited by tuxd3v; 03-09-2019, 04:46 PM.

                    Comment


                    • #70
                      Originally posted by hreindl View Post
                      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:
                      Code:
                      /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
                      Last edited by tuxd3v; 03-09-2019, 05:35 PM.

                      Comment

                      Working...
                      X