Out of the blue my Steam started picking a random font I had in my user fonts dir: Virgil, the Excalidraw font.
That triggered me all sorts of emotions, ranging from laugh to total incredulity. I initially thought the root cause was a random derping from Valve but the Internet seemed quiet about it, so the unreasonable idea that it might have been my fault surfaced.
Who doesn’t love a good technology mystery story?
That’s pretty interesting, although I’d like to know a bit more about why steam or it’s dependencies are scanning the fonts. Does it build a database of installed fonts every time it runs?
Whilst it seems a bit weird that Steam should be scanning fonts on startup, it’s not exactly unusual. A lot of apps will do the same. For something like Steam, it’s probably for portability (not every system has the same fonts, looking at you, Linux), accessibility (some people find some fonts easier to read, see Comic Sans and the dyslexic community), and localisation (not every font has every character in every language)
Obviously, if you install a font that’s easier to read, because for some reason the default is illegible to you, you’ll want the app to pick it up on a restart.
The123king,
Searching for an answer, just now I did an strace of the steam client and I did not observe it doing a file scan of the system fonts directories, at least on my computer. So my guess is that steam does not normally scan the fonts at all. fc-cache might have corrupted the font cache database independently from steam, although I’m not familiar with how it works.
The steam interface doesn’t have a font selector as far as I can tell. Even if it did, it shouldn’t have to scan the fonts at launch, only when the dialog is opened. It’s not a big deal, I’m just curious.
Did you touch the font dir? It only updates the database if something has changed.
Remember Steam is implemented using CEF an embedded chromium fork, since a lot of the menus are using HTML it needs the fonts scanned for the HTML/CSS font selection to work.
Carewolf,
I tested it again after touching a font, and steam did not scan the fonts or stat the file. I understand what you are saying, however steam itself does not seem to trigger the re-scanning process. Maybe one has to install new software before it does, however it didn’t do it at startup, nor do I think it should as it would defeat the purpose of having a cache.
Yes, all font using apps scan the fonts on startup to generate a font database. You have to read and parse installed fonts to know what font names they will match.
Carewolf,
I don’t think scanning fonts at startup is typical because most software uses the system’s database instead.
https://www.freedesktop.org/wiki/Software/fontconfig/
It’s goal is “efficiently and quickly find the fonts you need among the set of fonts you have installed, even if you have installed thousands of fonts, while minimzing memory usage.”
fc-cache is used to update the database and rescan the underlying fonts, although I’m not sure what actually triggers it.
https://linux.die.net/man/1/fc-cache
Fontconfig isn’t very good, and often doesnt have the lookup queries you need. Though with it, you can often just list the entire fontconfig database, and create a better lookup database. Without having to scan actual files,
The first computer that I learned how to program on looked like a cash register and in 8th grade science class I programmed that computer to play tic-tac-toe and kept upgrading the program until nobody could beat it no matter if you went first or second.
The second computer I learned to program on was an IBM Model 15/D where I learned COBOL, FORTRAN, RPG2 and BASIC.
I would program on mainframes until 1997. While everyone else was still using 2 digit years in 1994 I had started modifying mine to 4 digit years (I worked at a bank) because I didn’t think I would be leaving the bank or leaving mainframe programming until after the year 2000 and I didn’t want to have to scrambled in 1998/1999 to change to four digit years so I started in 1994 and was finished by the end of 1996. I ended up leaving the bank shortly after that for another job where I didn’t program on mainframes anymore but solely only PCs (which I had also been doing since 1984).
In 1998 when OS/2 (my OS/2 of choice at the time) was being killed off by IBM (due to internal IBM idiocy and only partially due to Microsoft) and knowing that there was zero change me of moving to Windows I was looking at other OSs to use.
In 1995 there was BeOS (there is an open source version of it called Haiku) but that company went bankrupt due to illegal business moves by Microsoft (see Microsoft anti-trust lawsuit in the mid 1990s which was set off in part due to Be Inc not being able to install BeOS on computers due to an illegal contract with PC vendors) but Be was bankrupt and gone (though I still have all the boxes of licensed BeOS software I ever bought).
There was also Linux. I have over a dozen different BRANDS for distributions of Linux on my shelves but I never found one I was happy with. Linux, being a clone of UNIX, doesn’t have a 2038 date issue. No version of UNIX has it that I’m aware of.
That led me to Mac OS X which had birthing and growing pains. But that is what I’ve been using, happily, since Mac OS X 10.5 and I haven’t looked back. It doesn’t have a 2038 date issue since the base of MacOS (the current name of the OS) is UNIX.
I have ZERO regrets never using Windows at home for my main OS. I only used it to see how much it sucked vs everything else and it never failed to be near the bottom of the reliability scores. Even hobby OSs scare better with reliability than Windows does. At least for anything I used OSs for (work, games, pleasure, etc.).
FWIW, the “life lesson” I would take from this story: Don’t mess with the clock on your main system; it’s too hard to predict everything that might break or might just be left in a state that’s confusing to you later. Use a virtual machine just for the application that needs it. Of course, this is easy for me to say when I’m using a Qubes OS system that makes that relatively easy to do, whether the motivation is security or something else. In other situations, people might reasonably decide on a different trade-off between up-front work and risk of problems.
Granted, with my suggestion, Steam would probably still have had the problem, but at least the rest of the system would definitely be unaffected, and there might be additional options for recovery, such as rolling back to a previous snapshot of the virtual machine (which is also relatively easy in Qubes OS).
Matt McCutchen,
Most people wouldn’t have a reason to use the wrong date, although I do recall some software (ie xlite) implementing a date based kill switch.
Developers might consider dog fooding their software with the date set into the future to catch problems in development before they become a bigger problem later. The whole w2k debacle should have been resolved by 1990. It was mostly mainframes that stored years as 2 EBCDIC characters. Other platforms tend to measure time as binary number starting at an arbitrary epoch such as unixtime. Year 2000 had no effect on them, but many of these systems will roll over in 2038.
https://www.businessinsider.com/2038-software-32-bit-date-problem-2014-5
Frankly we should be fixing all software with 32bit times today (including the bug discovered by the author) long before it rolls over in 2038. What are the chances we as an industry have learned anything though? Haha.