Posts by geoff61 38 publicly visible posts • joined 7 Nov 2014
That was stated in the penultimate paragraph of the article: "For the same reason, plugging in an external keyboard is also a no-go since freshly updated iPhones are placed in what's known as a Before First Unlock state, which prevents wired accessories from working until the passcode is entered."
Maybe we will reach that point some time in the (far) future, but LLMs are not the right route to get there. LLMs have good and bad code in their training data with no way to tell them apart. And the ratio of good to bad is only going to get worse as future LLMs contain more and more "AI slop" in their training data. The best possible quality code you could get from an LLM would be from one that has been trained only on code that has been curated by humans to remove the bad stuff, and then it could only be as good as human-produced code, not better.
Systemd did this to me in 2016. It was the first boot of a Dell XPS 13 that came with Ubuntu pre-installed. And it was worse than this Windows case: resorting to the command line to issue a shutdown command didn't work (it just produced a message from systemd saying the action would be "destructive" IIRC).
After holding down the power button to turn it off, the next thing I did was install Debian with sysvinit (which was usable back then; these days I run Devuan).
"No sign of HP-UX or IRIX et al on x86"
You're forgetting UNIXWare (the direct descendant of AT&T's SVR4, rebranded "...ware" by Novell after they bought UNIX System Labs from AT&T). I used UNIXWare 1 and then 2 for several years in the 1990's on a Dell 486 and then a custom-built Pentium Pro system. It was free for non-commercial use.
Those are just the binaries in /usr/bin. A lot of other files are needed to run those. On my oldstable Devuan:
$ apt-cache show groff-base | grep Installed
Installed-Size: 3673
$ apt-cache show groff | grep Installed
Installed-Size: 10557
Multiplying by 1024/1000000 to get MB I make that about 3.8MB for a minimal install capable of formatting man pages, or 10.8+3.8MB for the full install (roughly one-and-a-half 10s of megabytes).
> That the number of seconds reported is the same indicates that the clock isn't actually TAI.
The computer's "clock" (internal count of seconds) is what it is. The question is what set it? In order for the clock to be synced to TAI and the right/* timezones to convert that clock to the true wall-clock time, the clock needs to be set by something, e.g. an NTP implementation, that has been told to do that. The origin of the right/* timezones is the IANA timezone database, and the information at https://data.iana.org/time-zones/tz-link.html says "right/UTC can be used by chrony", so maybe that's one way.
> That's not a time "calculation"
So conversion from struct tm to time_t is a "calculation" but the opposite conversion is not? Whatever. I could have used either direction to demonstrate my point. Both conversions either use leap seconds or they don't, depending on the timezone.
> On Ubuntu (where there is no right/* timezones available)
The article was about Debian and I ran those commands on a Debian system. Strange that Ubuntu, being a Debian derivative, would remove the right/* timezones. (Or perhaps they are being removed from Debian and the change has made it into Ubuntu already but won't happen for users of Debian stable until they upgrade to trixie.)
> a=1483228826
Thanks for that. Putting it into the reverse conversion demonstrates the leap second with right/GB nicely:
$ TZ=posix/GB date -d @1483228826
Sun Jan 1 00:00:26 GMT 2017
$ TZ=right/GB date -d @1483228826
Sat Dec 31 23:59:60 GMT 2016
> To be strictly compliant with UTC it needs to accept 60, 61
Do you have a citation for that? The original 1989 ANSI (1990 ISO) C standard specified the range as [0,61] but in 1999 they changed it to [0,60], saying that the 61 was the result of a misunderstanding. IIRC, they had thought the fact that there can be two leap seconds in the same year meant tm_sec could be 61 but actually in that case they are added on 30th June and 31st Dec. The POSIX rationale for <time.h> says "The formal definition of UTC does not permit double leap seconds, so all mention of double leap seconds has been removed, and the range shortened from the former [0,61] seconds seen in earlier versions of this standard." This makes sense to me as the purpose of leap seconds is to keep the difference between UTC and UT1 to within 0.9 seconds. If two leap seconds were ever added on the same day, the 0.9 second limit would be broken.
> and 58 (1 -ve leapsecond)
What evidence do you have that glibc's mktime() wouldn't handle a -ve leapsecond correctly (with a right/* timezone) if one ever occurs?
"the file format is defined as so by the POSIX standard"
No it isn't. POSIX only defines the API used to access the utmp file, not the file format. There is no requirement that the file is just a binary containing the utmpx structures used by the API. And anyway the structure has the time as a struct timeval which has a time_t member for the seconds, and POSIX (as of the 2024 revision) requires time_t to be at least 64 bits. So on a system where the file does contain utmpx structures, the file would need to have at least 64-bit for the seconds in order to conform.
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/utmpx.h.html
> MIT-SHM exists, but it's fairly limited
I cited MIT-SHM in order to give 1991 as the date when RAMChYLD's assertion stopped being true. There have, of course, been other more capable additions since then which also don't talk to the X server via a network port.
> Wayland is vastly better when interfacing with GPUs
Better than what? With X the best ways to interface with GPUs are OpenGL and Vulkan. A bit of searching for Wayland v. X11 in GPU benchmarks suggests Wayland sometimes wins and X sometimes wins. Neither is "vastly better".
There is one, and only one, valid reason for a shell script to pass '/' (or any other pathname that resolves to the root directory) to rm, and that is to test that it reports an error, as required by POSIX (which says "if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands").
The data in question, i.e. the Maps timeline, is stored on the phone with an optional backup to the cloud. The deletion must have been caused by a bug in the Maps app.
The people who opted to enable the backup are able to restore the data to their phone. Seems to me that choice is not moronic at all.
I learned from the official user manual. Effectively what is now at https://docs.gimp.org/2.10/en/ but the version that was current 23 years ago.
Yes, POSIX calls it "the Message Passing option". It's one of a long list of options whose support can be queried via constants in <unistd.h> and calls to sysconf(). Some of the POSIX options are mandated for UNIX conformance, but Message Passing isn't one of those.
Jason, you're a little out of touch. There *were* three language bindings, but 1003.9 was withdrawn in 2003 according to https://standards.ieee.org/ieee/1003.9/1440/ and although 1003.5 doesn't seem to have been withdrawn, I can't find anything more recent than "Amendment 2", published 31 Dec 1999 (https://ieeexplore.ieee.org/document/815314) and that had Ada bindings to the ancient 1003.1-1996 C interfaces, three major revisions behind the current 1003.1-2024 standard, so it's questionable whether it is relevant any more. Also, although the shell and utilities *were* standardized in 1003.2-1992, 1003.2 was merged into 1003.1 in 2001, as I pointed out in an earlier comment.
(Note that I don't count 1003.1-2017 as a major revision, as it was just 1003.1-2008 with its two technical corrigenda rolled in. The reason it was produced is because IEEE rules require standards to be either revised or withdrawn after 10 years, which means that the IEEE website not showing the 1999 amendment to 1003.5 as withdrawn may be a mistake.)
Geoff Clare
Current Technical Editor of POSIX.1 and The Single UNIX Specification.
The output of "apt-cache show pax" includes: "This is the MirBSD paxtar implementation supporting the formats ar, bcpio, cpio, SVR4 cpio with and without CRC, old tar, and ustar, but not the format known as pax yet."
It likely conforms to POSIX.2-1992 but since it doesn't support the new "pax" format (i.e. "-x pax" in addition to the old "-x ustar" and "-x cpio") it doesn't conform to the later POSIX revisions and wouldn't be sufficient for a UNIX 03 certification.
Followed the link to the atariunix.com site and it brought back some happy memories of having a TT running SVR4 as my personal workstation for 3 years when I worked for UniSoft (who did the SVR4 port) in the 1990's. It had a fabulous 1280x1024 monochrome monitor, whereas the machine I had after that was a Dell PC (also running SVR4) which could only manage 800x600 (but with colour). SVR4 was installed on an 80MB hard drive and used almost all of it. I had a huge (physical size) 100MB external SCSI drive for my files. Part of my job was to run the X/Open XPG3 test suite on it (an ancient ancestor of The Open Group UNIX test suite that is used today to certify AIX, macOS, etc.).
"Ever used octal? You will with chmod."
I am a frequent user of chmod and I can't remember the last time I used it with octal. It's almost always quicker and/or easier to use its symbolic capabilities. For example, a command I use a lot is "chmod a-w file" to make a file read-only. To do the same using octal would mean performing these steps:
1. Use "ls -l file" to see the current permissions
2. Mentally work out what the new permissions will be without any w's
3. Mentally convert the new permissions to octal
4. Use "chmod octal file" to set the permissions
5. (optional, but a good idea) Use "ls -l file" to check the permissions came out right
Even if you want to set the permissions to something fixed, there's no need to use octal. Want read+write for the owner and just read for group and other? You can use "chmod u=rw,go=r file" - slightly more typing than "chmod 644 file" but no mental gymnasitcs needed.
There are two problems with the use of the phrase "end of Unix epoch" here.
1. Although in general use, "epoch" can mean a period of time, in computing it is an instant in time. As per Wikipedia's entry for Epoch (computing): "In computing, an epoch is a fixed date and time used as a reference from which a computer measures system time. [...] Unix and POSIX measure time as the number of seconds that have passed since Thursday 1 January 1970 00:00:00 UT, a point in time known as the Unix epoch."
2. The end point for representable time_t values on Unix and POSIX systems varies according to how time_t is defined. It is in 2038 for 32-bit signed time_t, but much later for 32-bit unsigned time_t or for time_t with more than 32 bits. In fact, the latest revision of the base volumes of The Single UNIX Specification (aka POSIX.1-2024, published earlier this month) requires implementations to have a time_t of at least 64-bits. This makes the limit on representable times not time_t, but the tm_year member of struct tm, which (with 32-bit int) can only represent times to a little over 2 billion years from now.
> in the Open Group register of UNIX® certified products, there used to be two different Linux distros, Huawei EulerOS and Inspur K/UX, both Chinese CentOS Linux derivatives. Like it or not, this means that Linux isn't "a Unix-like OS" any more. It is a Unix.
No, it means that those two specific Linux distros are (or were) UNIX. Huawei and Inspur would have had to make a huge amount of changes to their systems in order to pass the certification tests, similar to what was done by Apple to OS X (as described by Terry Lambert in a post to Quora). In fact, it could be argued that those changes mean EulerOS and K/UX are no longer Linux, since Linus Torvalds famously refused to make at least one of the changes that would be needed to make the kernel conform to POSIX. (The one I'm sure of is that POSIX requires kill(-1, sig) to include the calling process in the set of processes the signal is sent to, but Linux doesn't include it; I vaguely recall there were more such cases.)
They haven't been separately maintained since the late 1990's. After POSIX.1-1996 and The Single UNIX Specification version 2 (SUSv2, 1997) were published, IEEE, The Open Group and ISO got together and formed The Austin Group, a technical working group which created a joint standard that was published as POSIX.1-2001, SUSv3 and ISO 9945-1:2002 (likewise for subsequent revisions). They are three names for one and the same document. (Actually that should be "the base volumes of SUSv3", as SUSv3 also has a separate XCurses volume.)
The distinction between POSIX(TM) and UNIX(R) in the joint standard is that it has a lot of functionality that is optional for POSIX conformance but is mandatory for UNIX conformance (in particular the "XSI option", but other optional things too).
Interesting that the author mentions POSIX systems are required to include awk but doesn't seem to realise that POSIX also effectively requires awk to support UTF-8, and that all of the systems which were updated to conform to POSIX.2-1992 and which added UTF-8 locales in the early to mid 1990's added UTF-8 support to awk (and all the other POSIX text-processing utilities) at that time. I say "effectively" because it's only required on systems that have at least one UTF-8 locale installed, so there's a loophole there; for some systems there may have been a short time where they supported older multi-byte encodings in awk before they added any UTF-8 locales. (UTF-8 was invented by Ken Thompson and Rob Pike right around the same time that POSIX.2-1992 was approved by IEEE).
systemd-free Devuan hits stable 1.0.0 status
To those who said they voted no because they haven't had any problems running systemd: more fool you. You almost certainly will have problems one day. Problems happen when you do something that is outside your normal routine. For example...
I have a six-month old Dell XPS 13 that came with Ubuntu pre-installed. I tried out Ubuntu for a few days and all seemed fine, until one day I booted into recovery mode. I was happily typing commands into the recovery mode shell when all of a sudden systemd pipes up that something has timed out and it is going to start an emergency shell. I now have two shells running, both reading from the same terminal. And they are not getting one line of input each or one character, but something in between, which made getting out of the situation an interesting problem-solving exercise. Needless to say the next thing I did was to install a different Linux system with good old sysv init. (Not Devuan as I didn't think it was mature enough at the time, although I may switch to it sometime.)
Your knowledge of UNIX/POSIX certification history is seriously lacking.
Windows NT was never certified by X/Open. It (or more specifically, its POSIX subsystem) was certified by NIST as conforming to FIPS 151-2, which was basically POSIX.1-1990 with a few optional things mandated, i.e. way less functionality than what X/Open certification would require.
Also, X/Open did not "collapse" - it merged with OSF to form The Open Group, which owns the UNIX® trademark and still certifies UNIX systems. The most recent UNIX certification was OS X Yosemite. See http://www.opengroup.org/openbrand/register/brand3607.htm