On Monday 30 January 2012 06:26:52 pm Gerard Beekmans wrote: > > I think this concept is one of all/most the old farts are moving on...to > > be taken over by the youngens who are now thinking that they are the > > masters when thye haven't a clue for history. > > > > I will take the ways of unix from the 70's, It is that way for many > > _good_ reasons. > > Yes, you're right, certain things from the 70s were like that for many > good reasons but some of them have become bad reasons as technology has > evolved. > > What follows is a "devil's advocate" point of view in an attempt to keep > an open mind and consider all sides equally. > > 40 years ago hardware and software were extremely limited compared to > today's standards. If we never changed anything, we'd still be on 8-bit > systems today with little RAM and HDD. A lot of people disliked the > "recent" 64-bit change as well. In some ways it was a royal headache to > deal with. Now we all but live & breathe it and are (mostly?) happy for > 64-bit architectures because it allows us to address a lot more RAM and > HDD. All that additional RAM and HDD allows us to virtualize systems on > just about any system and save a lot of money. LFS development is faster > & cheaper this way. 10 years ago it wasn't as easy of efficient having > multiple computers around my desk so I could test instructions on one > machine while writing the book on another. > > There is a fine line between following a "tried, tested & true" method > with philosophies such as "why break what wasn't broken in the first > place" and being at the far end of that spectrum called "stuck in the > past". Change is sometimes painful but not all change is ultimately bad. >
Just don't fall into change for the sake of change. > I think it's important for everybody to at least keep an open mind. > Another example is that nobody wants the Internet of the old days back > when 2400 baud and slower modems were around. It wasn't necessarily > broken; it worked fine, just slow. Now we have GigE Internet readily > available. Progress comes at the price of adopting paradigm shifts and > letting go of "old and outdated ways". When we arrive on the other side, > we sometimes are better off for it. Now a lot of people wouldn't dream > of going back to a "simpler time" of 2400 baud, 8-bit computers and a > couple of kilobyte of RAM. Sometimes simpler times are also the thing > that hold you back from beneficial improvements. Ah yes I would like to go back to those days. > > As for systemd specifically, I have to agree it feels messy and less > than ideal. I wouldn't be overly happy if I were to be forced into using > it. Some of its benefits do make sense even if the implementation is > rough around the edges. I'm trying to at least see past that and keep an > open mind for the time being. Perhaps its final implementation down the > road won't be so bad. If nothing else, it's something new to play with. > Whether it makes it into the LFS book is a whole different matter. > > There are valid plus sides to the merging /usr debate. I can't remember > if this was mentioned on the freedesktop.org page linked by Bruce. If > everything OS provided is together in one top level directory, it would > make a lot of things simply more elegant. Backups being one of them. > Lookup the bumblebee fiasco on google, The bumble devs had a line rm -rf /usr /lib<what ever> in a install script so you installed the app and your /usr was gone. Do you really want everything in /usr? I don't, I mess up more that I straighten up ;) > Sure, all those separate mount points existed for a number of very good > reasons. Those reasons evolved over the decades and maybe we're truly > coming to a point where they can be considered obsolete. One of those > reasons was due to hard drive capacity problems. There wasn't always > enough room to store all of /, /usr, /var, /tmp, /home and others on the > same drive when all you had was 100-300 MB per physical drive. Having a > few tools in /bin and /sbin was by some considered a work-around/hack so > you could boot a mini system with enough tools to repair & bring up all > the other partitions into a full system that may have spanned half a > dozen drives. Now that we don't have that hard drive size problem and > more intelligent file systems that are harder and harder to corrupt, do > we still need to stick with those work-arounds? The work-arounds have > become common practice and we've adopted them as "the only true way of > doing things". But they were considered work-arounds by some, and > eventually a work-around is removed when the original issue no longer > exists or has been fixed by other means. > I still like the filesystem as it is now. I don't see all the pain/problems that folks say it is causing. > Nowadays with multi-TB size drives space at least is no longer a > concern. There were other good reasons to have separate partitions. For > example, if /home filled up it wouldn't necessarily crash the system as > /var wouldn't fill up. Subsystems such as email would continue to work. > That concept still applies today in my opinion but we also have other > ways of accomplishing that with, for example, file system quotas. It was > a real nuisance in the old days when one partition ran out of space but > you had tons of space on another partition. Ugly work-arounds to work > around other work-arounds came to be such as symlinking across > partitions so you could use a portion of /var inside /home/someuser. LVM > addresses some of that where you can resize partitions dynamically > without danger of data loss (unlike resizing actual partitions which is > more dangerous). Yes I use LVM, best thing since sliced mangos > > If everything lived under one large 1 TB partition, all those woes of > the past go away. Just like that. You need to be smart about it and > definitely use quotas to keep processes from filling up a drive by > accident. That has never been a big concern in my mind. > Or one giant mess. I am good at creating messes, just ask my wife. I would rahther have a gaggle of lvm partitions with different parts on them. At least then I could find what it is I am looking for. > Having said all of that, I personally like separate partitions for > different types of data. I may or may not implement that setup on the > new LFS server. I'm at least considering other options. Just because > I've been doing something for a while doesn't mean the reasons are still > 100% valid today. > I do that as well and I ain't changing it. > Anyways, I don't mean to step onto a soapbox here. I just wanted to > provide examples where "evolution" was welcome, but often only in the > very end. While we were going through the changes we grumbled a lot. Now > I feel silly that I ever did. I would have pushed harder and advocated > for more changes in the distant past if I knew then what I know today. I > hope to learn from those revelations and not always push back against > new ideas in present day. > > Just some food for thought. > > -- > Gerard Trying to keep up with all the latest changes is difficult and for some that is all they seems to get done is chasing the upgrade path. This is not for me........ I just want something that works and nothing more. Everybody can purse the change if that is what they want, just leave enough of the old for me. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
