Date: Mon, 14 Nov 2011 14:09:54 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> Cc: Ed Schouten <ed@80386.nl>, Doug Barton <dougb@freebsd.org>, mike@karels.net, Tim Kientzle <tim@kientzle.com>, arch@freebsd.org, Robert Watson <rwatson@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: The strangeness called `sbin' Message-ID: <20111114220953.GE1455@elvis.mu.org> In-Reply-To: <CAOgwaMu7nY2JAESKwDBU4DtJOUt8u6f5qg8qokSdgPjGPb0nkw@mail.gmail.com> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <alpine.BSF.2.00.1111141745001.94325@fledge.watson.org> <20111114193434.GC2164@hoeg.nl> <CAOgwaMu7nY2JAESKwDBU4DtJOUt8u6f5qg8qokSdgPjGPb0nkw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'd just like to throw in my regular bit of sacrilege and ask if what we would be moving to would conform to any standard, perhaps a linux or sysv model, otherwise a departure from BSD "standards" to something totally new seems really unwise if all we are aiming to do is reduce the number of directories in $PATH. -Alfred * Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> [111114 13:57] wrote: > 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 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111114220953.GE1455>