From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.cs.ucla.edu (mail.cs.ucla.edu [131.179.128.66]) by sourceware.org (Postfix) with ESMTPS id 2CEE33858D33 for ; Wed, 12 Apr 2023 23:36:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2CEE33858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 031BE3C097AFA; Wed, 12 Apr 2023 16:36:52 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QqqGqli6_1gW; Wed, 12 Apr 2023 16:36:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id B88DB3C097AFD; Wed, 12 Apr 2023 16:36:51 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu B88DB3C097AFD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1681342611; bh=Q/8Md9E0uwW15GYW7doD9oIorGrRrbp71J4SfCTpT+E=; h=Message-ID:Date:MIME-Version:To:From; b=J4AaXjauz9V3YqSAVEx3fCpbIF201mm9tnlnE7MHCsmqetmzP4U7b6DH7baynQLkz WkZLsVCoT7Jy8aSFoqTcInLEWE09E7rZRsOJdCKLC9Xody0hvfcJUgOAh6pwl/qgv7 yQQeK9sNeFMTjX5v4+pO/tYazG1wqe4lpKKrZIyTbeVr7QiYvmZkZ2bLOu5UAAATuX 1kWryZzjPP2IC0fYa5Ydk6+JQlqIJ892WVHGcEEnTjjuzLmMnzg/WL7BD1IeKJ7G5k SKZTmKF+PHBsuFfqvsh7FXlKs1dH0j95JT5TbHYZbkp4qpIt2BhUXLMl55VUuRm1WD tIlp86J9A/aeQ== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xbugRnitFPV4; Wed, 12 Apr 2023 16:36:51 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id A17753C097AFA; Wed, 12 Apr 2023 16:36:51 -0700 (PDT) Message-ID: <50e93d93-219b-afd8-b06f-8c54f4863302@cs.ucla.edu> Date: Wed, 12 Apr 2023 16:36:51 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32 Content-Language: en-US To: Thorsten Kukuk , libc-alpha@sourceware.org References: <20230208102225.GA5543@suse.com> <7485b79473614eaa994d3ea79c91629a@DB6PR04MB3255.eurprd04.prod.outlook.com> <20230208103819.GA6177@suse.com> <901005ca-640f-3a8f-a199-c1374f3cf141@linaro.org> <20230214082409.GA29974@suse.com> <3230d2f8fa214c268cba52e699c14ae2@DB6PR04MB3255.eurprd04.prod.outlook.com> <20230216135920.GA1706@suse.com> <20230411114052.GA29920@suse.com> <99c1f0eb-da72-f760-d200-4318a2da8759@cs.ucla.edu> <20230412065501.GA19883@suse.com> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <20230412065501.GA19883@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,JMQ_SPF_NEUTRAL,KAM_NUMSUBJECT,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 4/11/23 23:55, Thorsten Kukuk via Libc-alpha wrote: > At least "pinky" does not read wtmp but utmp. Oh, you're right, so it's just "who", "users" and "uptime". And "users" isn't that useful for reading wtmp, and a lot of people use procps-ng "uptime" rather than coreutils "uptime", so "who" is the biggest problem here. > there are better ways to find out I'm sure there are, but the problem is that users might be relying on these older ways of finding out. > I don't understand for what this should be good? People wrote shell scripts before "last" became common, or didn't know about "last", or wanted to be portable to old systems that lack "last", or whatever. > That's the equivalent of "last". Since there will be no wtmp anymore, you > have to use "last" (gives you the same informations) or we have to > implement wtmpdb support into who. Don't know if this makes really > sense. If you want to decommission this coreutils functionality, I suggest taking it up with the coreutils maintainers - that's a better spot than this mailing list.