On 25/02/2021 13:37, Stephen John Smoogen wrote: <snip>> They run into the same interdependency.. but because they have organically > grown their distro every day, those dependencies grew 1 at a time. > > For EPEL and other EL repos you have to jump multiple Fedora releases to > catch up. So in EL6 we were Fedora Linux 12. In EL7.0 we had to jump and > rebuild from scratch a lot of Fedora Linux 18 and Fedora Linux 19 and then > progressed up to about Fedora 24 as various parts got rebased and upgraded > to 7.9. For EL8, we have to jump to Fedora Linux 28 and then each dot > release rebase parts while keeping other parts back because rebasing is > focused. [This means that if something needs glibc-2.32 you can't put it in > EL8 without a lot of patching to make it work with whatever changed... but > some other related components may be able to recompile fine.] > > Thus you need people who enjoy that kind of work to do this because EPEL is > nearly all volunteer work. I had to work after hours or take vacation time > to work on getting EPEL-8 out so that I could get focused effort on it. > Most people don't have that 'luxury' and so the number of volunteers is > small but the expectation that it will be there is large. > > > >> Tony Schreiner >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> https://lists.centos.org/mailman/listinfo/centos >> > >I was recently looking at Raymond's book "The Art of UNIX Programming" from 2003. He, along with contributors Thompson (inventor of UNIX), Kernigham (C and AWK), Korn and others of that callibre, espouse creating "little tools" that do one job reliably and well. The likes of Gnome or systemd certainly would never fit into this philosophy. I really think we have lost a lot of maintainability and ease of management over the last 20 years as applications are stretched to do ever more. -- J Martin Rushton MBCS
> > > On 25/02/2021 13:37, Stephen John Smoogen wrote: > <snip> >> They run into the same interdependency.. but because they have >> organically >> grown their distro every day, those dependencies grew 1 at a time. >> >> For EPEL and other EL repos you have to jump multiple Fedora releases to >> catch up. So in EL6 we were Fedora Linux 12. In EL7.0 we had to jump and >> rebuild from scratch a lot of Fedora Linux 18 and Fedora Linux 19 and >> then >> progressed up to about Fedora 24 as various parts got rebased and >> upgraded >> to 7.9. For EL8, we have to jump to Fedora Linux 28 and then each dot >> release rebase parts while keeping other parts back because rebasing is >> focused. [This means that if something needs glibc-2.32 you can't put it >> in >> EL8 without a lot of patching to make it work with whatever changed... >> but >> some other related components may be able to recompile fine.] >> >> Thus you need people who enjoy that kind of work to do this because EPEL >> is >> nearly all volunteer work. I had to work after hours or take vacation >> time >> to work on getting EPEL-8 out so that I could get focused effort on it. >> Most people don't have that 'luxury' and so the number of volunteers is >> small but the expectation that it will be there is large. >> >> >> >>> Tony Schreiner >>> _______________________________________________ >>> CentOS mailing list >>> CentOS at centos.org >>> https://lists.centos.org/mailman/listinfo/centos >>> >> >> > I was recently looking at Raymond's book "The Art of UNIX Programming" > from 2003. He, along with contributors Thompson (inventor of UNIX), > Kernigham (C and AWK), Korn and others of that callibre, espouse > creating "little tools" that do one job reliably and well. The likes of > Gnome or systemd certainly would never fit into this philosophy. I > really think we have lost a lot of maintainability and ease of > management over the last 20 years as applications are stretched to do > ever more. > -- > J Martin Rushton MBCSOr you can say it with Henry Spencers words: Those who don't understand Unix are condemned to reinvent it, poorly.
On Thu, Feb 25, 2021 at 02:12:39PM +0000, J Martin Rushton via CentOS wrote:> I was recently looking at Raymond's book "The Art of UNIX Programming" from > 2003. He, along with contributors Thompson (inventor of UNIX), Kernigham (C > and AWK), Korn and others of that callibre, espouse creating "little tools" > that do one job reliably and well. The likes of Gnome or systemd certainly > would never fit into this philosophy. I really think we have lost a lot of > maintainability and ease of management over the last 20 years as > applications are stretched to do ever more.If every tool we used were self-contained, build-it-all-from-scratch, our desktops would be a huge mess. Nothing would work with another tool, you'd have widely varying user interfaces, you'd never have something like X11 or Wayland. Sure, that attitude is fine for command line tools, but a huge part of the open source world is taking advantage of toolkits provided to make life easier for the programmer. The world is a lot more complicated than in the K&R days. When I worked at Princeton, Kernighan was teaching courses using Python (and Go now, I think). (Really cool guy) Heck, 'systemd' is a really complicated beast, but it doesn't have a huge number of interconnected dependencies. I think bringing it up isn't really appropriate for this thread, since it actually does a pretty good job of keeping the requirements down, so it can run in minimal instances. -- Jonathan Billings <billings at negate.org>
On Thu, 25 Feb 2021 at 09:13, J Martin Rushton via CentOS <centos at centos.org> wrote:> > > On 25/02/2021 13:37, Stephen John Smoogen wrote: > > I was recently looking at Raymond's book "The Art of UNIX Programming" > from 2003. He, along with contributors Thompson (inventor of UNIX), > Kernigham (C and AWK), Korn and others of that callibre, espouse > creating "little tools" that do one job reliably and well. The likes of > Gnome or systemd certainly would never fit into this philosophy. I > really think we have lost a lot of maintainability and ease of > management over the last 20 years as applications are stretched to do > ever more. >Maybe but everytime someone says "I think these are too complex" they then turn around and say "but I really need this to do this one more thing." Also the complexity of tools is generational. The oldschool 1970's Unix people were screaming that the 1980's software was too complex because various flags had been added to central commands. The 1980's people complained that even early Linux was too complex because it had so much more software that depended on each other. And so forth. In the X11 world, there were as many people saying FVWM was way too complex when twm was all you needed and it was making software too hard to build. BUT could you get twm to work on our new monitor which has a different view screen feature that made the fonts look like crap. The counter argument I heard from a 1970's Unix era person was "Software gets more complicated over time as we find that more problems need to be solved. You either keep up with it, or get out of software." He was working in software until his death a short while ago in his 80's.> -- > J Martin Rushton MBCS > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >-- Stephen J Smoogen.
Am 25.02.21 um 15:12 schrieb J Martin Rushton via CentOS:> > > On 25/02/2021 13:37, Stephen John Smoogen wrote: > <snip> >> They run into the same interdependency.. but because they have >> organically >> grown their distro every day, those dependencies grew 1 at a time. >> >> For EPEL and other EL repos you have to jump multiple Fedora releases to >> catch up. So in EL6 we were Fedora Linux 12. In EL7.0 we had to jump and >> rebuild from scratch a lot of Fedora Linux 18 and Fedora Linux 19 and >> then >> progressed up to about Fedora 24 as various parts got rebased and >> upgraded >> to 7.9. For EL8, we have to jump to Fedora Linux 28 and then each dot >> release rebase parts while keeping other parts back because rebasing is >> focused. [This means that if something needs glibc-2.32 you can't put >> it in >> EL8 without a lot of patching to make it work with whatever changed... >> but >> some other related components may be able to recompile fine.] >> >> Thus you need people who enjoy that kind of work to do this because >> EPEL is >> nearly all volunteer work. I had to work after hours or take vacation >> time >> to work on getting EPEL-8 out so that I could get focused effort on it. >> Most people don't have that 'luxury' and so the number of volunteers is >> small but the expectation that it will be there is large. >> >> >> >>> Tony Schreiner >>> _______________________________________________ >>> CentOS mailing list >>> CentOS at centos.org >>> https://lists.centos.org/mailman/listinfo/centos >>> >> >> > I was recently looking at Raymond's book "The Art of UNIX Programming" > from 2003.? He, along with contributors Thompson (inventor of UNIX), > Kernigham (C and AWK), Korn and others of that callibre, espouse > creating "little tools" that do one job reliably and well.? The likes of > Gnome or systemd certainly would never fit into this philosophy.? I > really think we have lost a lot of maintainability and ease of > management over the last 20 years as applications are stretched to do > ever more.Well, do "ldd /bin/awk" and you see interconnected dependencies. I see it the same way and if I want, I would see it the same way with a broader view. Do one job well - interaction with the user, Gnome. Do one job well - when a service is stopped, it is stopped (systemd). So it depends of the scope of view. Sure, there are tools that try to do everything. One that came into my mind is YasT from SuSE. That one I would classify as not fitting into the common unix philosophy. -- Leon