On 10/4/19 10:40 AM, Valeri Galtsev wrote:> My impression is younger generation doesn't value rules that > programmers were following 2-3 decades ago. One of which is: > > Do not make any changes [in the program] unless they are absolutely > necessary. >I have in the past agreed with this assessment more than once.? And I _am_ somewhat of an old hand at this, having run Unix and Unix-like systems for a bit over 30 years. The fact of the matter is that, even though some of the old ways work just fine and don't need to be changed, many more times I've seen that, if the old way was a kludge to begin with, maybe there really is a better way to do it.? Take the transition from horse and buggy to automobile for instance.? Iron rim tires work just great for the buggy, not so great for the automobile; a change had to be made in an old technology (the wheel) to meet the needs of the new automobile.? Lots of wheelwrights probably fought that change, too. I've seen the old ways, and there are more kludges out there than some would like to admit.? (obOldWayRef: article on 'the kluge' from the 1966 Datamation book 'Faith, Hope, and Parity.')? Just remember: the old ways back then was punch card and batch; what do you mean you want more than one person to use such an expensive thing as a computer live, wasting its valuable time?? Many seem to forget just how subversive Unix was back in the day relative the the old ways.> ... > Yet one more thing is: building superstructure on top of what actually > works.The definition of what works can and does change over time.? Sure, an iron rim wheel can work for the new automobile, but the basic change in what the wheel needed to do (with buggy the wheel doesn't need to provide good traction, that's what hooves are for, and narrow and smooth work best; with the automobile all of a sudden the drive wheels need to provide traction, and even though the iron-rim wheel still works after a fashion on smooth ground, there is a better way to do it).? I can just hear the old-school wheelwrights saying "well, if it gets stuck in the mud then just don't go in the mud!"? or "why would anyone want to go faster than the horse-drawn buggy could?" or "why would you need to turn that quickly and at that speed?" or "why in the world would you want brakes to stop you that quickly?" and the list goes on..... I _am_ old-school in thought, but I do consciously make the effort to understand the newer reasoning, rather than be the greybeard that constantly talks about how I did it in the old days.? Heh, in the old days I made it work with K&R C, 1MB of RAM, and an 8MHz CPU.... and I griped about the misfeatures then!..... Today, I'm doing things with containers, virtualization, dynamic load balancing, software-defined infrastructure/IaaS, etc that the old ways simply cannot handle.? NetworkManager/systemd/etc in CentOS are far from perfect, but at least they're trying to solve the newer problems that the old ways in many cases simply cannot.
On 10/4/2019 8:17 AM, Lamar Owen wrote:> On 10/4/19 10:40 AM, Valeri Galtsev wrote: >> My impression is younger generation doesn't value rules that >> programmers were following 2-3 decades ago. One of which is: >> >> Do not make any changes [in the program] unless they are absolutely >> necessary. >> > I have in the past agreed with this assessment more than once. And I > _am_ somewhat of an old hand at this, having run Unix and Unix-like > systems for a bit over 30 years. > > The fact of the matter is that, even though some of the old ways work > just fine and don't need to be changed, many more times I've seen > that, if the old way was a kludge to begin with, maybe there really is > a better way to do it.? Take the transition from horse and buggy to > automobile for instance.? Iron rim tires work just great for the > buggy, not so great for the automobile; a change had to be made in an > old technology (the wheel) to meet the needs of the new automobile.? > Lots of wheelwrights probably fought that change, too. > > ... > > Today, I'm doing things with containers, virtualization, dynamic load > balancing, software-defined infrastructure/IaaS, etc that the old ways > simply cannot handle.? NetworkManager/systemd/etc in CentOS are far > from perfect, but at least they're trying to solve the newer problems > that the old ways in many cases simply cannot.This is a bit orthogonal, though. (Witness the effort to remove systemd requirements from containers.) An engineer is expected to understand the component parts rationally to arrive at some sort of professional conclusion that something is likely to work properly. This is not helped by a switch from imperative and deterministic to declarative and dynamic, which underlies many of the changes we've had to deal with in the past decade. There is a time and place for the latter, and it's good to have options available... but there are many times and places (especially in the Enterprise space) where the opposite is necessary, and it's FAR more reasonable to layer dynamic manipulation on top of a deterministically-configured core than the other way around. -jc
On Fri, 4 Oct 2019 at 18:11, Japheth Cleaver <cleaver at terabithia.org> wrote:> > On 10/4/2019 8:17 AM, Lamar Owen wrote: > > On 10/4/19 10:40 AM, Valeri Galtsev wrote: > >> My impression is younger generation doesn't value rules that > >> programmers were following 2-3 decades ago. One of which is: > >> > >> Do not make any changes [in the program] unless they are absolutely > >> necessary. > >> > > I have in the past agreed with this assessment more than once. And I > > _am_ somewhat of an old hand at this, having run Unix and Unix-like > > systems for a bit over 30 years. > > > > The fact of the matter is that, even though some of the old ways work > > just fine and don't need to be changed, many more times I've seen > > that, if the old way was a kludge to begin with, maybe there really is > > a better way to do it. Take the transition from horse and buggy to > > automobile for instance. Iron rim tires work just great for the > > buggy, not so great for the automobile; a change had to be made in an > > old technology (the wheel) to meet the needs of the new automobile. > > Lots of wheelwrights probably fought that change, too. > > > > ... > > > > Today, I'm doing things with containers, virtualization, dynamic load > > balancing, software-defined infrastructure/IaaS, etc that the old ways > > simply cannot handle. NetworkManager/systemd/etc in CentOS are far > > from perfect, but at least they're trying to solve the newer problems > > that the old ways in many cases simply cannot. > > > This is a bit orthogonal, though. (Witness the effort to remove systemd > requirements from containers.) An engineer is expected to understand the > component parts rationally to arrive at some sort of professional > conclusion that something is likely to work properly. This is not helped > by a switch from imperative and deterministic to declarative and > dynamic, which underlies many of the changes we've had to deal with in > the past decade. There is a time and place for the latter, and it's good > to have options available... but there are many times and places > (especially in the Enterprise space) where the opposite is necessary, > and it's FAR more reasonable to layer dynamic manipulation on top of a > deterministically-configured core than the other way around. > >On the other hand, most of the idea that the old config scripts were deterministic and imperative was built on a large amount of hacks to try and make it so. Having spent more time than I want dealing with systems which seem to be just like everything else but coming up with eth0 being eth4 (I am looking at you 40 Dell, HP and IBM boxes) on a reboot half the time.. I have come to see that a lot of scripts are full of race conditions and slowdowns to try and stop those race conditions from happening. If anything messed up from a kernel change, bios update, a switch update?, etc and you could be completely in the weeds wondering why imperative was failing. It was failing because it was never absolutely true. The problem is that as hardware rollouts have grown larger and larger spending time trying to figure out why 400 to 1000 out of 10,000 systems are weird.. is too much time. You want something which will try to figure it out itself and do the 'right' thing.. even if it means that eth4 on those 400 boxes are now the main interface versus the eth0 on the 3600. And yes.. as an non-neurotypical person.. I find that incredibly infuriating.. however I have also realized that most businesses don't care I and others find it that way. They just want those 10,000 to 100,000 systems to come up and work.> -jc > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos-- Stephen J Smoogen.
On Fri, 2019-10-04 at 11:17 -0400, Lamar Owen wrote:> On 10/4/19 10:40 AM, Valeri Galtsev wrote: > > Do not make any changes [in the program] unless they are absolutely > > necessary.Especially with production programs.> Take the transition from horse and buggy to automobile for instance. > Iron rim tires work just great for the buggy, not so great for the > automobile; a change had to be made in an old technology (the wheel) to > meet the needs of the new automobile.Technically it was never an "upgrade" but a brand new and alternative system.> Just remember: the old ways back then was punch card and batch;With a minimum of 3 tapes; disks had not been invented. Some British universities had a magnetic drum.> I _am_ old-school in thought, but I do consciously make the effort to > understand the newer reasoning, rather than be the greybeard that > constantly talks about how I did it in the old days. Heh, in the old > days I made it work with K&R C, 1MB of RAM, and an 8MHz CPU....Luxury. Try running on a 32k single processor computer, started with booting the card reader which read cards that booted from a tape.> Today, I'm doing things with containers, virtualization, dynamic load > balancing, software-defined infrastructure/IaaS, etc that the old ways > simply cannot handle.No comparison between 50+ years ago with this constantly developing and fascinating New World. However KISS remains valid. If it works smoothly, don't mess it up. Regards.
On 10/5/19 2:14 PM, Always Learning wrote:> Technically [the new automobile] was never an "upgrade" but a brand new and alternative > system. > ...The automobile was originally billed in many areas as the 'horseless carriage,' an upgrade.> Luxury. Try running on a 32k single processor computer, started with > booting the card reader which read cards that booted from a tape. > > ...Frontpanel, 256 words (12-bit words), and paper tape.? But I also never had that straight-8 on the net, either, but, via uucp, I did have the T6K on Usenet.> No comparison between 50+ years ago with this constantly developing and > fascinating New World. However KISS remains valid. If it works smoothly, > don't mess it up.But that's the point; the previous solution didn't work as smoothly for all use cases as one might want to believe.