Re: [CentOS] Date question
On Wed, Feb 17, 2021 at 1:57 PM Jerry Geis wrote: > SO from the man page on date I can do > > current=`TZ=":America/Indianapolis" date` > echo $current > current=`TZ=":America/Los_Angeles" date ` > echo $current > > And I get correct data. LA is 3 hours earlier. But doing this: > > current=`TZ=":America/Indianapolis" date +%s` > echo $current > current=`TZ=":America/Los_Angeles" date +%s` > echo $current > > I get the same data - its not 3 hours different. > > What am I not doing correct ? > > Thanks, > > Jerry > Hi All - I did figure this out. I was close the first time - but just not right. FROM_DATE_TIME=`TZ="America/Los_Angeles" date --date '120 sec ago' +'%Y-%m-%d %H:%M:%S'` TO_DATE_TIME=`TZ="$America/Los_Angeles" date --date '1 sec ago' +'%Y-%m-%d %H:%M:%S'` and my server is set for Indianapolis time. The above worked. Thanks! Jerry ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to install XFCE on CentOS 8?
On Thu, 18 Feb 2021 at 04:47, Simon Matter wrote: > > > > Smooge, you know I feel your pain, but becoming a maintainer in EPEL has > > a pretty high bar (lots of new tools and methods to work with, amongst > > other things) -- as it SHOULD, given that it's intended as an addon to > > EL and needs to be very tightly controlled. It's just more difficult to > > get started these days relative to when anyone could build an rpm as > > long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' > > back when building as root in a non-reproducible buildroot wasn't a > > cardinal sin. > > > > I've just started reading https://fedoraproject.org/wiki/EPEL/FAQ and > realized this became a problem which hurts EPEL much more than Fedora. > > IMHO it simply got too difficult to maintain packages for quite a number > of software tools. It explains why there are so many missing, outdated or > dead packages in Fedora and more so in EPEL. > > What worries me even more is that things have changed to be worse with > every release than becoming better. > > To put it bluntly, is that there are multiple issues going on: 1. We have a large number of people who have gotten used to someone else doing the work for them and not having to care about the software themselves. In doing so they have this idea that building the software is exactly like it was when they got into computers. [* This isn't a new phenomena] 2. Software gets more complicated and more interdependent to do the many things software consumers expect it to accomplish. 3. Software changes more rapidly because more people are able to work on code and people have this odd thing of deciding that whoever wrote the code last was a complete idiot and this new method/language is much better. [The only time it is funny is the once a week where a git blame shows you that the last idiot was you.] 4. With millions of software consumers, there are millions of 'opinions' of what they need and Linux being a system which allows you to shoot your foot in a billion ways tries to accomplish all of them. * When I was getting into software in the 1990's there were a lot of people who had been using Unix systems from the 1970's who found 'modern' software to be too complicated to build and coders were out of their minds for adding in such complexity when no one needed an editor more than ed. At the time I thought they were 'joking' but when I went to work at various places I found they were dead serious. The change is that where in the 1990's there were only hundreds of people like that, now there are maybe a low million. Trying to build large amounts of divergent code and make it stay working is very hard. As much as modules are a bane of my existence, something like them is absolutely necessary for many complicated stacks from desktop software to web applications. Writing basic rpms is even more complicated than in 1999 because there are so many corner cases which have to be dealt with. Writing modules is adding more layers of indirection on top of that because it is trying to keep the Rube Goldberg machine of each individuals 'choices' going. Frankly unless someone can figure out a way to make the packaging janitorial work sexy enough to have people interested in it.. or people who need this stuff actually pay people to do it.. this is all going to fall apart like all infrastructure which was 'someone else's problem'. > Regards, > Simon > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > -- Stephen J Smoogen. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to install XFCE on CentOS 8?
> > Smooge, you know I feel your pain, but becoming a maintainer in EPEL has > a pretty high bar (lots of new tools and methods to work with, amongst > other things) -- as it SHOULD, given that it's intended as an addon to > EL and needs to be very tightly controlled. It's just more difficult to > get started these days relative to when anyone could build an rpm as > long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' > back when building as root in a non-reproducible buildroot wasn't a > cardinal sin. > I've just started reading https://fedoraproject.org/wiki/EPEL/FAQ and realized this became a problem which hurts EPEL much more than Fedora. IMHO it simply got too difficult to maintain packages for quite a number of software tools. It explains why there are so many missing, outdated or dead packages in Fedora and more so in EPEL. What worries me even more is that things have changed to be worse with every release than becoming better. Regards, Simon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to install XFCE on CentOS 8?
> On Thu, 18 Feb 2021 at 04:47, Simon Matter wrote: > >> > >> > Smooge, you know I feel your pain, but becoming a maintainer in EPEL >> has >> > a pretty high bar (lots of new tools and methods to work with, amongst >> > other things) -- as it SHOULD, given that it's intended as an addon to >> > EL and needs to be very tightly controlled. It's just more difficult >> to >> > get started these days relative to when anyone could build an rpm as >> > long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' >> > back when building as root in a non-reproducible buildroot wasn't >> a >> > cardinal sin. >> > >> >> I've just started reading https://fedoraproject.org/wiki/EPEL/FAQ and >> realized this became a problem which hurts EPEL much more than Fedora. >> >> IMHO it simply got too difficult to maintain packages for quite a number >> of software tools. It explains why there are so many missing, outdated >> or >> dead packages in Fedora and more so in EPEL. >> >> What worries me even more is that things have changed to be worse with >> every release than becoming better. >> >> > To put it bluntly, is that there are multiple issues going on: > > 1. We have a large number of people who have gotten used to someone else > doing the work for them and not having to care about the software > themselves. In doing so they have this idea that building the software is > exactly like it was when they got into computers. [* This isn't a new > phenomena] > 2. Software gets more complicated and more interdependent to do the many > things software consumers expect it to accomplish. > 3. Software changes more rapidly because more people are able to work on > code and people have this odd thing of deciding that whoever wrote the > code > last was a complete idiot and this new method/language is much better. > [The > only time it is funny is the once a week where a git blame shows you that > the last idiot was you.] > 4. With millions of software consumers, there are millions of 'opinions' > of > what they need and Linux being a system which allows you to shoot your > foot > in a billion ways tries to accomplish all of them. > > * When I was getting into software in the 1990's there were a lot of > people > who had been using Unix systems from the 1970's who found 'modern' > software > to be too complicated to build and coders were out of their minds for > adding in such complexity when no one needed an editor more than ed. At > the > time I thought they were 'joking' but when I went to work at various > places > I found they were dead serious. The change is that where in the 1990's > there were only hundreds of people like that, now there are maybe a low > million. > > Trying to build large amounts of divergent code and make it stay working > is > very hard. As much as modules are a bane of my existence, something like > them is absolutely necessary for many complicated stacks from desktop > software to web applications. Writing basic rpms is even more complicated > than in 1999 because there are so many corner cases which have to be dealt > with. Writing modules is adding more layers of indirection on top of that > because it is trying to keep the Rube Goldberg machine of each individuals > 'choices' going. > > Frankly unless someone can figure out a way to make the packaging > janitorial work sexy enough to have people interested in it.. or people > who > need this stuff actually pay people to do it.. this is all going to fall > apart like all infrastructure which was 'someone else's problem'. Well, unfortunately yes, EPEL is on a good way to go where DAG, ATrpms, NUX, freshrpms and all the others already are. Ironically, CentOS was the reason for other clones like Scientific Linux to vanish, now CentOS Linux vanishes itself. The same goes with EPEL, it was one nail in the coffin of so many third party repositories, now it seems to go there as well. What is even more sad is the fact that everybody is now waiting for Navy Linux, Rocky Linux and AlmaLinux to get their huge work done to produce three, technically mostly identical systems. They'll still all lack the same thing which is a good package repository for things not found in RHEL. Doesn't it mean burning a huge amount of CPU cycles and storage for little additional gain in the end? Sadly, that's not how open source works best. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to install XFCE on CentOS 8?
On Thu, 18 Feb 2021 at 12:04, Simon Matter wrote: > > On Thu, 18 Feb 2021 at 04:47, Simon Matter > wrote: > > > >> > > >> > Smooge, you know I feel your pain, but becoming a maintainer in EPEL > >> has > >> > a pretty high bar (lots of new tools and methods to work with, amongst > >> > other things) -- as it SHOULD, given that it's intended as an addon to > >> > EL and needs to be very tightly controlled. It's just more difficult > >> to > >> > get started these days relative to when anyone could build an rpm as > >> > long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' > >> > back when building as root in a non-reproducible buildroot wasn't > >> a > >> > cardinal sin. > >> > > >> > >> I've just started reading https://fedoraproject.org/wiki/EPEL/FAQ and > >> realized this became a problem which hurts EPEL much more than Fedora. > >> > >> IMHO it simply got too difficult to maintain packages for quite a number > >> of software tools. It explains why there are so many missing, outdated > >> or > >> dead packages in Fedora and more so in EPEL. > >> > >> What worries me even more is that things have changed to be worse with > >> every release than becoming better. > >> > >> > > To put it bluntly, is that there are multiple issues going on: > > > > 1. We have a large number of people who have gotten used to someone else > > doing the work for them and not having to care about the software > > themselves. In doing so they have this idea that building the software is > > exactly like it was when they got into computers. [* This isn't a new > > phenomena] > > 2. Software gets more complicated and more interdependent to do the many > > things software consumers expect it to accomplish. > > 3. Software changes more rapidly because more people are able to work on > > code and people have this odd thing of deciding that whoever wrote the > > code > > last was a complete idiot and this new method/language is much better. > > [The > > only time it is funny is the once a week where a git blame shows you that > > the last idiot was you.] > > 4. With millions of software consumers, there are millions of 'opinions' > > of > > what they need and Linux being a system which allows you to shoot your > > foot > > in a billion ways tries to accomplish all of them. > > > > * When I was getting into software in the 1990's there were a lot of > > people > > who had been using Unix systems from the 1970's who found 'modern' > > software > > to be too complicated to build and coders were out of their minds for > > adding in such complexity when no one needed an editor more than ed. At > > the > > time I thought they were 'joking' but when I went to work at various > > places > > I found they were dead serious. The change is that where in the 1990's > > there were only hundreds of people like that, now there are maybe a low > > million. > > > > Trying to build large amounts of divergent code and make it stay working > > is > > very hard. As much as modules are a bane of my existence, something like > > them is absolutely necessary for many complicated stacks from desktop > > software to web applications. Writing basic rpms is even more complicated > > than in 1999 because there are so many corner cases which have to be > dealt > > with. Writing modules is adding more layers of indirection on top of that > > because it is trying to keep the Rube Goldberg machine of each > individuals > > 'choices' going. > > > > Frankly unless someone can figure out a way to make the packaging > > janitorial work sexy enough to have people interested in it.. or people > > who > > need this stuff actually pay people to do it.. this is all going to fall > > apart like all infrastructure which was 'someone else's problem'. > > Well, unfortunately yes, EPEL is on a good way to go where DAG, ATrpms, > NUX, freshrpms and all the others already are. > > Many of those ran out of steam because software got more and more complicated, and consumers demanded MORE of it but put less into it. "There is no such thing as a free lunch" but it doesn't seem to stop people assuming there has to be. > Ironically, CentOS was the reason for other clones like Scientific Linux > to vanish, now CentOS Linux vanishes itself. The same goes with EPEL, it > CentOS was not the primary reason Scientific Linux (and some other rebuilds) vanished, it was the convenient excuse. The staff who were working on Scientific Linux had continual budget cuts over a decade while also an increase in what people wanted from it. There were several 'your team has been told to retire' before they combined with CentOS. It is a problem that the other past clones ran into and I expect the future ones will also have to grapple. It takes a lot of resources to build an OS even if it is recompiling the source code others made available to you. Without a constant renewal and growth of those resources, the people volunteering (or even being paid) to do the work run out of
