On 02/10/2018 18:46, Larry Martell wrote:
> I got 2 years of work solving the year 2000 issue.
I don't think I've ever said this but I am very envious of all these
people who had loads of work due to Y2K or were paid obscene amounts of
money to tend systems over new year's eve/day.
I was working
Our new-to-us Isilon is handling NFSv4 ACLs differently than other NFS
file servers we've had. In particular, something causes an 'O' to pop
up in the permission field, but I cannot find any documentation of it.
For example,
[Linux]$ nfs4_getfacl TODO
A::OWNER@:tTcCy
A::GROUP@:tcy
If you do that make sure it's a system you're happy to junk and
reinstall. I have painful memories of trying to sort out systems we
rolled forward over Y2K. Amongst other things the license manager
became convinced we were trying to fiddle things. :-(
On 02/10/18 20:07, Gordon Messmer wrote:
>
On Tue, Oct 02, 2018 at 10:39:52AM -0500, Johnny Hughes wrote:
>
> I don't specifically mind tutorials being posted to the list .. BUT .. I
> would like them to be in CentOS Namespaces. So either on
> wiki.centos.org or blog.centos.org.
Either is a proper venue as content can be peer-reviewed
On 10/2/18 10:41 AM, Johann Fock wrote:
Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
If you define the problem as the limitations of system clock based on a
32-bit representation of seconds relative to the epoch, then the answer
is "yes." The Linux kernel uses a 64-bit
> On Tue, Oct 2, 2018 at 1:42 PM Johann Fock wrote:
>>
>> Hallo
>> Im using CentOS 7
>> Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
>
> I got 2 years of work solving the year 2000 issue. In 2038 I will be
> 79 - maybe I will have to come out of retirement to work on that.
>
On Tue, 2 Oct 2018 at 13:42, Johann Fock wrote:
>
> Hallo
> Im using CentOS 7
> Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
>
I doubt there is any one answer without a deep audit of all the
binaries involved. Most date/clock code in 64 bit should be too big to
care, but if you
On Tue, Oct 2, 2018 at 1:42 PM Johann Fock wrote:
>
> Hallo
> Im using CentOS 7
> Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
I got 2 years of work solving the year 2000 issue. In 2038 I will be
79 - maybe I will have to come out of retirement to work on that.
Hallo
Im using CentOS 7
Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
Thanks
Johann Fock
Von meinem iPad gesendet
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
On 09/28/2018 10:10 PM, Yves Bellefeuille wrote:
> As someone else already noted, "Could you please not post self-
> promotional "tutorials" to the list?"
>
> Thanks for your understanding.
>
I don't specifically mind tutorials being posted to the list .. BUT .. I
would like them to be in
Hi,
I've applied the latest kernel upticks of kernel and
microcode_ctl for L1TF.
Just rpm updates and rebooted, no further changes.
kernel-2.6.32-754.3.5.el6.x86_64.rpm
kernel-firmware-2.6.32-754.3.5.el6.noarch.rpm
kernel-headers-2.6.32-754.3.5.el6.x86_64.rpm
on centos 7 I tried to install banshee from EPEL
yum install banshee
gotting this error:
Error: Package: banshee-2.6.2-11.el7.x86_64 (epel)
Requires: libgpod-sharp >= 0.8.2
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles
12 matches
Mail list logo