> 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. 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. 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. 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. 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). 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. 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. 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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
