Date: Mon, 14 Nov 2011 16:57:17 -0500 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: Ed Schouten <ed@80386.nl> Cc: Tim Kientzle <tim@kientzle.com>, Doug Barton <dougb@freebsd.org>, mike@karels.net, arch@freebsd.org, Robert Watson <rwatson@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: The strangeness called `sbin' Message-ID: <CAOgwaMu7nY2JAESKwDBU4DtJOUt8u6f5qg8qokSdgPjGPb0nkw@mail.gmail.com> In-Reply-To: <20111114193434.GC2164@hoeg.nl> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <alpine.BSF.2.00.1111141745001.94325@fledge.watson.org> <20111114193434.GC2164@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 14, 2011 at 2:34 PM, Ed Schouten <ed@80386.nl> wrote: > Hello Robert, others, > > Before I get to the subject, please excuse me for not commenting on all > your emails individually. I am afraid that if I would do that, the > discussion will fragment. > > The first thing I noticed is that some of the emails mention that the > work I proposed was a solution searching for a problem. I have to > emphasize this is clearly not my intention. It was something that I > started to notice when I was working on the utmpx code in 2009, where > half of the utilities were stored in /usr/bin, while the others were > placed in /usr/sbin. The reason why I let it wait until now, is because > even though I was considering moving the tools around back then, I > realized that this causes major headaches for our users, because if they > don't run `make delete-old' (which isn't even described in the handbook, > by the way), they'll end up having two copies. I reasoned that > performing a merge of sbin to bin automatically fixes this. Combined > with the arguments that I gave in my opening email, I am under the > impression that this is something that we should consider. > > The reason why I brought it up last week, is because I got reminded of > the issue by seeing the Fedora discussion. So to summarize: the reason > why I proposed this, is _not_ because the Fedora folks think it's cool, > it's because work in this area was (is?) on my TODO list anyway. The > fact that the Fedora folks are also discussing this, was only a > confirmation for me that this is a point of discussion in a larger part > of UNIX-land -- not just FreeBSD. > > Now let me respond to Robert's email specifically, as it raises an > interesting point, which I already thought about, but had not > specifically mentioned in the introduction email. > > From now on, let us assume we're discussing the patchset I have sent to > the list initially -- not the discussion between Doug and I, where we > discussed a full merge into /bin and /lib. > > * Robert Watson <rwatson@FreeBSD.org>, 20111114 18:48: > > Ditto. I agree with Ed that it is more aesthetically pleasing and in > > keeping with the actual design principles we have, but it would be > > quite disruptive for downstream users. Especially if the source tree > > is rearranged, since not all revision control systems (or import > > methods) take kindly to large-scale renaming of subtrees with > > substantial patches. <snip> > > So let us divide our users in two groups; regular users and vendors. > > Group 1: regular users > ---------------------- > In my opinion the patch isn't really disruptive for our end users. One > of the things that I don't want to do, is perform the merge of the > sbin and games directories automatically. This is because one small > error or assumption in our scripts can render many the system > unbootable. If it turns out we don't have anything to worry about, we > could eventually automate this through some means. If committed to SVN > in its current form, users will experience the following upgrade > procedure: > > - csup or svn up the source tree > - The user compiles the source, installs the kernel, reboots, etc. > - The user runs `make installworld', but it will simply print a message, > asking the user to read /usr/src/UPDATING, which contains four simple > shell commands that perform the merge. > - When done, the user runs `make installworld', which will now continue > to work properly. > > So all in all this is a pretty simple procedure. The total overhead is > only four small shell commands on a single `make installworld'. Compared > to the /usr/X11R6 -> /usr/local migration, it should be trivial, to say > the least. > > Group 2: vendors > ---------------- > So a pretty serious point that Robert raises, is that changes to source > tree layout are really irritating for our vendors. Now keep in mind that > I have mentioned nothing in particular about source tree layout. Even > though it would be a lot more consistent if those directories are merged > as well, I have not been promoting this. > > We could easily put the following policy in place: any new (or massively > rewritten?) utilities installed in /bin or /usr/bin _must_ be placed in > src/bin/ and src/usr.bin/. The src/sbin/ and src/usr.sbin/ directories > are left the way they are. In other words: the directory src/usr.sbin/ > can be described as "applications that were historically installed in > /usr/sbin". > > So vendors shouldn't notice that much of the transition. They can just > build on top of our source tree the way they currently do. The only > merge conflicts they could experience, are lines of code where we > replace path names, but conflicts in that area are as likely as any > other changeset. > > I think this message covers most of the things I wanted to say for now. > I really hope we can continue this discussion in a fruitful manner. I > have noticed that even though there has been criticism, there have also > been many people that have expressed support for this work, both > privately and on the mailing list, so it would be nice if this > discussion actually leads to something useful. > > Just because certain aspects have so far not been worked out completely, > doesn't mean the idea as a whole is a bad thing. And if it turns out to > be a bad thing, then so be it. At least it has served as a lesson. Maybe > it's worth asking yourself this question: "say, we were to merge sbin > with bin, what kind of problems can we walk into and how should they be > resolved?" > > Thanks, > -- > Ed Schouten <ed@80386.nl> > WWW: http://80386.nl/ I am not against any rearrangement in the executable directory contents , but there is one important problem . In Windows , any one installing a program which requires administrator privilege , stores anything they want into \Windows\... directories , even configuration files . This structure is making the so called operating system areas a real garbage bin : It is nearly impossible to maintain a clean operating system copy because of additional garbage where it is absolutely possible to store such files into another directory external to \Windows . My fear is that , in FreeBSD , combination of executables into a single directory will make it like the so called operating system ( impossible to maintain its integrity ) . Some time later , I will start to assemble an operating system from only permissive sources . My first candidate will be FreeBSD . My plan is as follows : Make /root directory in a ( SDHC ) DRIVE . Move all of the root usable binaries into /root/bin . Eliminate any super user possibility from user accounts or access to root related executables . When the root logs out , the /root drive will be removable . Allow root login when computer is booted . After login of a user , and logout , do NOT allow root login . Make /bin and other configuration , etc. files a ( SDHC ) DRIVE . Make /boot and its related parts a ( SDHC ) DRIVE . Make user definitions stored into a /users directory and in a ( SDHC ) DRIVE . Install ALL packages , ports etc. by ALL users into /usr in a ( SDHC ) DRIVE . Install ALL user directories in another Fixed disk DRIVE or external USB stick , SDHC cards , external hard disks ( by defining their platforms , drives in their user definitions ) and mount them by using their specified LABELs when the user logs . Do NOT use any global /tmp , for each user , use /home/user/tmp , for root /tmp in a ( fixed or external ) external hard disk or other kind of removable drive . Install a boot manager into a ( SDHC ) DRIVE to manage booting of required/wanted operating systems stored in ( SDHC ) DRIVEs , mountable by their LABELs , by scanning attached drives , generating loadable kernels menu from attached drives or from its fixed menu . After login of user , by using a global_fstab , generate a suitable fstab entries selection for the user . Scan all of the operating system sources , and define all of ( 1) the operating system file names ( 2 ) the package related file names into symbolic constant header files with their access mode kinds . Change all writable files to /home/*/tmp . /user/*/var , etc. , root related files to /root/var/ in a write-possible ( fixed ) hard disk . Make file access privileges more detailed and improve robustness of usage of files ( for example copy is possible , not possible ) . Include a suitable X version into base . Include a suitable window manager into base with properly defined menus ( not empty ) for operating system parts . Allow use of multiple monitors allocatable to console , window(s) , virtual terminal(s) . Improve package managers to allow installation of packages into user home directories when they are used by the users , into operating system related directories by the root in the producer computer to prepare ( SDHC) DRIVEs for the usable computers . REASON : - In school laboratories , public computing platform , and like places : Store ( SDHC ) DRIVES within the computer case as inaccessible by the users , therefore without any possible modification . Let the users to use their removable drives for their homes . - In safety critical applications : Maintain a computer to prepare the above mentioned parts , then attach them to other computers . Keep producer computer in a physically secure place . I have collected all related hardware . I am waiting the FreeBSD 9.0 Release to start study of the sources and make modifications one by one toward generation of an applicable version such as defined above . All over the years during computer usage , my most irritating disappointment is the invasion of our systems by the malicious software . Now I want to generate an operating system which will be physically unpenetrable . Such a physical arrangement will prevent operating system related software , parameter modifications , placement of malicious software into operating system areas . When security requirements are not fulfilled even a little more , any other arrangements will not be so attractive or important when the speeds of the present processors and hard drives ( conventional or SSD ) is extremely fast . Thank you very much . Mehmet Erol Sanliturk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMu7nY2JAESKwDBU4DtJOUt8u6f5qg8qokSdgPjGPb0nkw>