This is a collection of random questions and my best attempts at answering them. It is not exactly an FAQ, because I've never actually been frequently asked these questions; it's more like, *I* have had these questions, and I've searched the net, and I didn't really find a satisfactory answer elsewhere. So this is more of an ATRQ--Answers to Random Questions. It is also somewhat of an itch-scratching exercise--I am putting these here so that *I* can reference the answers as well. I will attempt to be as objective as I can when answering these questions, but I can't promise that all questions will be possible to answer this way.

You might be wondering why I don't just put this on some other site, say Quora or StackExchange. Technically speaking, I could do that, but I am more of a believer in the decentralized web. I don't think it makes as much sense to centralize all the information on those sites, where they are going to show you ads and make things generally annoying (i.e. "in order to see this answer, you need to sign in"). Another reason is that it's just more fun this way!

Also, when I say "random", it means that I don't have the questions or topics organized into any kind of categories. Maybe I will do this somewhere down the line if the number of questions/answers increases, and it makes more sense to do so.

Q1. Do Android phones automatically adjust for Daylight Time, even if they are in airplane mode?

• It is difficult to answer this for all Android devices, as there are many variations and versions out there. I can say, though, that Android 7 ("Nougat") running on an LG Aristo does indeed change automatically to Daylight Time, even in airplane mode. I personally encountered this situation in 2022, where I was using my phone for an alarm clock. I started the Clock app and created the alarm to wake up the morning after the transition from Standard Time to Daylight Time. I noticed that the Clock app was already taking the Daylight Time transition into account when it was telling me "this alarm will ring in [HH] hours [MM] minutes".

  As it turned out, I had difficulty sleeping that night, and I woke up early, even before the alarm went off. I checked my phone and noticed that the lock screen clock was showing an hour later than the weather widget clock was showing (after I unlocked the phone). I took the phone out of airplane mode, requested an update in the weather app and it resynced the clock. So it appears to me that the Android internal clock was updating correctly, similar to how Unix clocks handle this transition; it was just the weather app that was lagging behind. I suspect that this may be the source of many answers given on the web in general, which are basically of the form "your phone will automatically sync via the network." Which is great and all, but the point of the original question is in airplane mode.

Q2. How do Unix clocks handle the daylight/standard time transition?

• The question of daylight/standard time is mostly contained in the broader concept of timezones. This is because there are lots of let's say "quirks" involved with this kind of information. Various governments/countries all over the world like to make their own particular decisions about how to observe time. So computers need a "quirks table" of sorts to keep track--the earth and the various countries/governments are not regular enough to simply use a computer-based algorithm to figure it all out.

  With this said, the traditional method of maintaining the system clock on a Unix system is to synchronize it with UTC, or Coordinated Universal Time, under the hood and apply a timezone offset for mere mortal display purposes. This means that the system clock under the hood never has to worry about adjusting the clock an hour ahead or an hour back during daylight/standard time transitions, because there are no "daylight time" or "standard time" concepts in UTC: UTC is just UTC.

  So all that is needed is to have the "quirks table" encode the appropriate information about how to transition the time display and when to do so. On most Unix systems that I am aware of, the quirks table package is known as "zoneinfo" or "tzdata" (Wikipedia). If you have a modern Unix system at your disposal, you can usually find the quirks table files in /usr/share/zoneinfo. And to pick a particular timezone for display purposes, either the administrator or the system automatically creates a symbolic link at /etc/localtime which points to the particular file under /usr/share/zoneinfo (another method is to just copy the particular file under zoneinfo to /etc/localtime).

  By the way, I believe this is also how Android phones know how to adjust for daylight time automatically: Under the hood, the system clock is using UTC, and the zoneinfo file is used to apply an offset for various display purposes.

  Another theory that I've read is that phones can basically receive GPS data even while in airplane mode, because they don't necessarily have to transmit anything in order to do this (airplane mode for a phone basically means "don't transmit anything via any kind of wireless"). And if there is anything in the GPS data that would tell the phone that a standard/daylight transition is coming up, the phone can receive and process that information even while in airplane mode. I'm not completely sure if this is true or not, as I don't know enough details about how Android or GPS work.

Q3. What are the differences between the most popular freeware BSD Unix-derived operating systems?

• This of course is going to involve a lot of my own opinion; others may have differing opinions.

  OpenBSD:

  This is my personal favorite of all of them. The development of this system is very vibrant. The project has attracted and still attracts a fair number of developers, although the project is not truly gigantic (that is, the number of active developers at a time is less than 1000). But they are popular enough that developers want to work on the system. They also attract quite a lot in the way of funding. A number of years back, the OpenBSD Foundation was established to act as an independent entity to support the development of the project. Ever since that happened, it has been pretty easy to see that they usually attract quite a lot in the way of monetary funding. Of course, hardware can also be donated to the project, especially new or interesting hardware that might pique a developer's interest.

  I find that the system itself makes for a very nice, very consistent Unix environment with probably the best set of built-in documentation (man pages) that I have ever seen in a Unix flavor. You can tell that the developers care quite a bit about the quality and usability. Indeed, the system is pretty regularly used as the primary system used by its developers; another way of putting it is that they "eat their own dogfood."

  Quite a number of technologies that have originated in OpenBSD have made their way into other systems, a few notable examples being OpenSSH, the "pf" firewall and the "tmux" screen multiplexer (a more exhaustive list). They frequently introduce security technologies into the system and are savvy enough to realize whether a security technology will be usable by most people who are not developers; after all, if a security technology is too hard to use for most people, it will be used incorrectly, or not at all, so what good is it then?

  The project is way less-willing than many others to compromise on the freedom of code as well. With limited exceptions, only BSD or ISC-licensed code is accepted into their base OS source tree (a greater variety of licenses can be found in their "ports" tree, which is a collection of software that might be useful, but either isn't good enough to be in the base OS, is licensed more unfavorably, or just flat-out doesn't meet the goals of the developers). The primary reason the system is developed is for the developers; if non-developers would like to use the system too, and they are happy with using it, that is why the project makes its code available to all. Most developers who work on the system are essentially volunteers, so there is not a ton of willingness to bow to the demands of random people on the net who are just using the system. There is an ethic of "if you really want something in the system, be prepared to either write the code yourself, or to hire somebody to write the code for you; and then make convincing arguments as to why it should be accepted into the project.

  The project also believes in developing and running on actual target hardware. For them to claim they support a particular hardware architecture, they generally want to have actual, physical hardware of that architecture. I like this strategy, because I think it generally leads to actual, real-world running systems, instead of "in theory it should run on this system, because I got it working in some emulator." For a fair amount of time now, the project has been pretty quick to support new alternate architectures, and they are not afraid to cease supporting architectures that cannot be properly maintained. For this reason, you will not see current support for systems such as really, really old Motorola 68000-series CPU-based Macs. Again, if somebody really wants something like this, they have to be prepared to do the work to bring the architecture up to snuff.

  Historically speaking, the project originated from NetBSD, so this is probably the main other BSD that is related the closest. If you look in OpenBSD's code history, you will see a lot of "from NetBSD", since at one point (and probably still to this day, to some degree) it was probably easiest to import code from NetBSD. I should mention here that there is a very long history of the BSD projects sharing code back and forth between the individual projects, so mentioning this is not meant to be a criticism of OpenBSD, just a reality of how BSD projects work; the license itself is meant to encourage sharing. And these days, I suspect somewhat (just a gut feeling though) that more OpenBSD code goes into NetBSD, rather than the other way around.

  OpenBSD also was the first project that I was aware of who did time-based releases; since pretty much the inception of the project, they put out a new release every 6 months. They were doing this years before Ubuntu on the Linux side adopted the same release strategy. In fact, I think this makes OpenBSD years ahead of their time in this regard. Many projects have since moved to time-based releases, but I can't really think of any other substantial project doing this prior to OpenBSD; I consider them to be pioneers in this area, just as they pioneer so many other technologies.

  Of all the BSD projects, I think OpenBSD has the best sense of taste. You can tell that they aren't a project that is attempting to put on airs and act like a standard boring corporation from the business world. The motto (maybe unofficial) is "shut up and hack." I mean, the code doesn't write itself. They have an interest in producing artwork and came up with their own legendary logo, Puffy.

  Finally, I should mention that this is the primary BSD that I run personally; I don't really run any of the others currently. :)

  DragonFlyBSD:

  I probably like this one second-best, or maybe it's a tie for second place with FreeBSD, I haven't decided yet. I generally have a more favorable opinion of this project because they decided to go off in a majorly different direction than the parent project (which is FreeBSD). This is the newest of the major BSD projects, as far as I am aware. Lots of people think they can start a new BSD project, but I think few are prepared for the amount of work it is going to be. (By the way, this point also goes for OpenBSD; both of these systems were started by a single individual who basically said "I'm going to make my own BSD" and actually pulled the stunt off by creating a long-lasting project that attracted a critical mass of developers and interest.)

  So, I mentioned above that I really only run OpenBSD. :) At points in the past, I have attempted to install DragonFly, only to find that it didn't work on the hardware I was trying it on. This is not meant to be a severe criticism of the project; perhaps I didn't try hard enough. And it was a long time ago; perhaps circumstances are different now. As a result, I cannot give an "insider's" view as someone who actively runs the system, but rather just an outsider's view of what the project looks like. I think they are kinda underdog-ish, but they have managed to hang in there for a fair amount of time now, which I find impressive. They also appear to be a well-run project as well (I think likewise of OpenBSD, and probably FreeBSD as well). Like OpenBSD, they came up with their own logo, which I find "okay"; personally I like Puffy better. :)

  Like most of the BSD's besides OpenBSD, I believe they are more willing to accept code that is licensed under, say, the GPL version 3, so if you are attracted to BSD systems because of their license, watch out for this. As an example, I believe the standard system compiler is GCC version 8, which is definitely GPL version 3-licensed. In contrast, instead of just accepting GPLv3 versions of GCC into OpenBSD, that project stopped using GCC as its primary system compiler for many of the popular architectures, and they switched to the Apache 2-licensed LLVM/Clang (and honestly, they probably only accepted Apache 2 grudgingly).

  FreeBSD:

  As I mentioned, this is probably either a close 3rd, or in a tie for second with DragonFly. I have also personally run into more difficulties installing this system. Once we get here, we also start running into the "can't you just make up your mind?" effect. So, for example, for firewalling, OpenBSD uses "pf", which is their own homegrown firewall (it's also very nice!). That's really the only firewall available on OpenBSD--they put all their effort into improving it to meet their needs.

  I believe FreeBSD doesn't necessarily do this. So, not only is pf available for FreeBSD (because they ported it from OpenBSD), there are other firewalls available like ipfw (and maybe dummynet, if that is a separate one?). To me, this seems like they can't really decide what is best, and just focus on that, so you start to get this weird choice of firewall packages where it seems like they should both do the same thing. Maybe DragonFly does this also, I'm not completely sure.

  I think FreeBSD has the largest sheer number of developers among the BSD's, and it is one of the oldest, along with NetBSD. OpenBSD developers have mentioned that they are indebted to FreeBSD developers like Kirk McKusick who wrote a lot of the original filesystem code used by all the BSD's, and Bill Paul, who has written driver code for a large number of Ethernet devices. I think FreeBSD in general also tends to attract a good amount of funding, possibly being the most popular of all the BSD's, although perhaps OpenBSD fans would take exception to that. :)

  I get a bit of a feel of "run by committee" from this BSD project, but I'd say it doesn't seem to completely stifle their progress, and I guess that is good. They seem to tout themselves as similar to a standard boring corporation, in my eyes. They revamped the "BSD daemon" logo a number of years back; I was and am not very impressed with the result. But hey, only my opinion; I'm just random dude on the net writing my random stream of consciousness. :)

  By the way, this web page is served by FreeBSD because that's what the BSD fans at this particular "tilde project" decided to use. For editing this web page (using vi), I find FreeBSD to be just fine.

  NetBSD:

  And now we come to the BSD project that, from my view, seems to be in the most trouble overall. So, at one time, their claim to fame was that their code could run on the most sheer number of hardware architectures (and they still publicize the motto "of course it runs NetBSD"). These days, I'm not so sure this really fits. It does in some regard, as some folks on the net have shown off somewhat radical pieces of hardware with NetBSD running on them. But, for example, check out the list of sparc64 systems that OpenBSD supports, and compare that to the corresponding NetBSD list (hint: OpenBSD's list seems bigger to me).

  NetBSD does not appear to me to be attracting a lot of funding. The monetary thermometer on their main project page seems to be stuck at $3,403.00 raised, with a $50,000.00 goal. Are they just not updating the value, or are they truly not really raising much? Contrast this with the OpenBSD Foundation pages which show them taking in usually more than $300,000.00 per year, for at least the past 5 years or so. Maybe NetBSD's developers contribute monetarily as well to the project, and this funding is not reflected in the thermometer. Either way, to me, it doesn't look very auspicious for the project.

  NetBSD also seems to have "make up your mind!" syndrome. In my opinion, they probably have this syndrome the worst out of all the BSD's. As an example, they imported pf, but then decided to go their own way and make "npf", which sounds the same, but is a completely different implementation. They then try to tout npf as a distinguishing factor for their system, but I go read their mailing lists, and it sounds like npf doesn't have all the features that pf has. And that npf seems to be buggier than pf; for a firewall, that doesn't sound good to me. To top it off, I believe NetBSD also offers alternate firewalls like FreeBSD does. Make up your mind, folks!

  Again my opinion, NetBSD seems to be the "stodgiest" of all the major BSD's. They give me the impression the most that they are trying to act like random boring corporation. Their original logo was interesting, but of course, was often considered offensive, since it evoked wartime victory. Their replacement logo is probably, if you ask me, the worst of the bunch. I mean, it's not necessarily horrible in its own right, but no way it holds a candle to Puffy, like not even close. And it seems to me that they could have tried harder to come up with something more original than a basic, orange flag. So, I'd argue that NetBSD probably has the least sense of taste of all the major BSD's. They may be more "run by committee" than FreeBSD; I think in their case, this committee effect is directly impacting the project negatively.

  Also like the others besides OpenBSD, I have encountered problems trying to get this system to run on my hardware. If I really step back and try to be objective, NetBSD probably offers the least number of reasons that I should run their system. At one point, they may have arguably "held their own" compared to OpenBSD. These days, I would struggle to find a reason to run NetBSD over OpenBSD. Although, I will say that technically-speaking, if you want to run a BSD on a really old 68000 CPU-series Mac, NetBSD claims to still support them. Maybe their latest versions will really run on that hardware; I believe a number of years ago, they stopped doing builds on actual, physical hardware of each architecture, instead switching to an elaborate cross-compiler and emulator-based strategy. Don't take that as fact, though; I don't follow the project closely enough to really tell.

  NetBSD started inflating their version numbers a number of years back now. For a while, they seemed to use the OpenBSD style of increasing version numbers, but then they started cranking their major number much more frequently. As such, you might think that NetBSD has put out more releases than OpenBSD, because "9.3" sounds bigger than "7.1", and I'm not sure that's the case. (As an aside, I think OpenBSD did a one-shot major version number crank at the very beginning, to distinguish themselves from the NetBSD version number. After that, I think they stopped caring about what NetBSD's version number was.)

  At least of of NetBSD's original founding developers (Charles Hannum) has stated that NetBSD has stagnated to the point of irrelevance. Again, this does not appear to be auspicious for the project. As far as I could tell, the project's response was "thanks for the feedback and your past contributions; we are taking away your source code commit privileges", and that's it. Basically a standard corporate PR-style response. I guess you can take that for what it's worth.

Q4. Which common Unix flavors/distributions still support the 32-bit "i386 PC" architecture?

• Many Unix flavors/distributions have done a hard switch over to the 64-bit amd64 architecture and no longer support running 32-bit with their latest versions. The popular ones that still do support running 32-bit "natively" that I am aware of are are most of the BSD's (except for DragonFly), and on the Linux side, Debian, Alpine and Void. Some of the BSD's have cautioned that their 32-bit i386 versions are not very well-tested on actual hardware any more compared to their amd64 versions (an example of this being OpenBSD). This basically boils down to the classic case of having developers being willing to run on older, more limited hardware, which is the same deal as, for example, whether a Unix flavor still chooses to run on PowerPC Mac platforms or the DEC Alpha. It all doesn't just happen by magic--somebody has to be willing to put in the time and effort.

Q5. What are the differences in the life-cycle characteristics of various current flavors of Unix?

• I'm going to try this in table format:

  minor patch releases

  Name	Version Number Description	Version Number Inflation	Life-cycle Description	Long-Term Support (LTS) Releases	Examples
  OpenBSD	Mostly increments by 0.1 with each release	Perhaps a one-time version bump to 2.0 towards the beginning, otherwise no	OpenBSD produces a new release every 6 months. They have been doing this a long time now, since the late 1990's. Each release is supported for a year. The version number can be thought of roughly as a decimal number, so the version after 6.9 is 7.0, not 6.10 (i.e. "six dot ten"). OpenBSD describes version 7.4 as their 55th release; this means you could consider it "version 55" if you were to think of each release as an integer ordinal instead of a decimal.	No	... 6.8, 6.9, 7.0, 7.1 ...
  Ubuntu	Tied to the date of the release	Not really applicable, because the date is the version number	Also produces a new release every 6 months, like OpenBSD (which is probably where they got the inspiration from :). Each release is supported for 9 months, except for LTS releases which are supported anywhere from about 3-5 years (and sometimes payment is required for longer-term support).	Yes	... 19.10, 20.04 LTS, 20.10, 21.04, 21.10, 22.04 LTS ...
  Debian	Increments by 1.0 with each release, with 0.1 minor "patch" releases	No	Debian seems to use a "when it's ready" mentality for when major releases are made. Major versions are produced roughly every 2-3 years.	Not formally, but they do seem to support their releases for a fairly long time	10.0, 10.1, ... 11.0, 11.0, ...
  Red Hat (RHEL)/CentOS/Rocky/etc	Similar to Debian, mostly increments by 1.0 with each release, with 0.1 minor patch releases	Perhaps a one-time version bump to 2.x near the beginning? Otherwise, no	Red Hat produces a new version of RHEL roughly every 4-5 years, with some variation (they are not strictly time-based releases as far as I can tell). Once a new version is released, it is maintained with patch releases that increment the version number by 0.1. Patch releases can sometimes result in versions like 5.11 and 6.10 (i.e. "five dot eleven" and "six dot ten").	Yes (basically every major release is an LTS)	5.0, 5.1, ... , 5.10, 5.11 6.0, 6.1, ... , 6.9, 6.10 7.0, 7.1, ... , 7.8, 7.9
  FreeBSD	Also similar to Debian	No	Likewise, not strictly time-based; seems to be more "when it's done."	Similar to Debian	12.0, 12.1, ... 13.0, 13.1, ...
  Solaris	Hard to keep track of, but mostly seems to increment by 0.1 these days?	Yes, version 2.6 was inflated to version 7	Solaris version numbers are a little chaotic. They were going along in the "2.x" series for a while, then decided to drop the "2 dot" part of it, so version 2.7 was dubbed "version 7". Then 8, 9 and 10. Once we got to 11, they seemed to switch to 11.1, 11.2, 11.3, etc. Ever since Sun was gobbled up by Larry Ellison, Solaris has basically been on life support.	Not really	See description
  NetBSD	Mostly similar to Debian these days	Yes, version 1.6 was inflated to 2.0	NetBSD seemed to start out with an OpenBSD-style of version numbering: 1.3, 1.4, 1.5, 1.6. Then they switched to Debian/FreeBSD-style numbering with the 2.0 series + patches, 3.0 + patches, etc.	Seemingly similar to Debian	8.0, 8.1, ... 9.0, 9.1, ...
  Windows	All over the place	No? Really tough to say	Trying to follow the version "numbers" of Windows is somewhat of an exercise in futility. Microsoft seems to support the "decent" versions of Doze for a pretty long time, and tries to quickly exit-stage-left the "bad" versions.	I'd say yes, for the "decent" versions	See description