Pinus

The text mentions troff and PIC. I wonder whether the author still has the source code... Even if re-rendering with modern tools ("modern" meaning "actually runs on platforms readily available today, e.g. groff and gpic") is more work than he’s willing to put in (which I quite understand), there ought to be someone on the Internet who is enough of a compsci/typography nerd to do it...

Doesn't that get confusing with the "@" sign often being called "kanelbulle" (cinnamon bun, https://commons.wikimedia.org/wiki/File:Kanelbulle.jpg for the non-Swedes :-) )

Googling around for answers to Mac related problems, I can easily see that about half the people "answering" questions are completely clueless, just cargo-culting various voodoo stuff. I suspect that among the other half, half of those are equally clueless, but I can't tell which ones because I'm myself not mac-savvy enough!

And Xcode itself does not help. I install Xcode. Well, actually, I didn't, because you need to actually start Xcode for it to completely install itself. It seems to come with a complete set of command-line tools; I can compile and run plain Unix stuff from the command line. Great. Except when you try to run Homebrew, that complains that you don’t have the True Command Line Tools; you need to run xcode-select --install to install what appears to be a completely different copy of the same things. Wtf?

Isn’t there an entire Unicode block for the symbols on the Phaistos disc? Yes: https://en.wikipedia.org/wiki/Phaistos_Disc_(Unicode_block) . I suppose those occur in quite a few documents about the disc, even though the disc itself is the only known document written in those symbols.

In Sweden, it is often said that men with names ending in -y have a significantly worse outlook in life than the average. Article from Swedish public-service radio (in Swedish, but Google Translate handles it nicely): https://sverigesradio.se/artikel/4743711 . TL;DR: such names were popular in disadvantaged socioeconomic groups.

Applied to the problem of picking a toilet at a music festival: https://www.youtube.com/watch?v=ZWib5olGbQ0 .

I skimmed the comments quite quickly so I may have missed it, but it seems that nobody has mentioned what I think is one of the biggest issues with make (as actually used, as opposed to some ideal): recursive runs. I have seen several packages (and I used to work with one rather large code base) which were subdivided into multiple directories, sometimes in several levels, each with its own Makefile and some rule that did

  for d in $(SUBDIRS); do cd $d && $(MAKE); done

A top-level make run would take ages just to recurse through everything to decide that nothing needed to be done, and dependency tracking did not work across modules, so the only way of making sure you got everything rebuilt was to ‘touch’ everything. (The advantage of the setup was that you could check out just part of the tree and build it separately.)

It would be really nice if make could read all subdirectory Makefiles, build one global dependency graph and then have at it.

A bit off topic: Like Amazon, Fnac.com seems to be drifting towards being a "marketplace" rather than a vendor. (I have only shopped in their brick-and-mortar shops, as a tourist in France, so maybe it has always been like this; I don't know.) Do they have the same issues as Amazon with counterfeit goods?

The M-W article says that "it appears to have won some measure of acceptance" in en_UK, and quotes the Daily Mail for an example...

Somebody noticed (https://www.openstreetmap.org/user/StephaneP/diary/390290) that OSM isn't even consistent about which datum it uses. (Discussed in HN at the time: https://news.ycombinator.com/item?id=20460596 ). (Though to be fair, the datum error is probably smaller than e.g. GPS error in most cases.)

As for the "why" bit, the answer is probably "store and report whatever the user reports".

At one point in time, they would have, had they existed at all: https://pubmed.ncbi.nlm.nih.gov/31283950/ "Intra-rectal tobacco insufflation as a resuscitation method for drowning victims: A gold-standard in the 18th century"

I agree that TeX sources are often damn near impossible to read. That stuff is... ugly. But at least it's there. You can see it. You can manipulate it. You can understand it (though it sometimes takes more time flipping through the TeXbook than any sane person is willing to spend). In comparison, WYSIWYGgery is like boxing with an invisible opponent. Where do I click, what magic check box three levels deep in dialogs do I need to check? Why does that word come out in a different font? How do I move the cursor across the italic/roman boundary? Why is there extra space here, but not there? How can I interact with things that I cannot see?

You sometimes see people ask fairly simple Python questions on Stack Overflow, that could be solved by five lines of plain Python, and be answered with some Pandas magic incantation that happens to do what they want with one call. I always find this a bit sad, because it seems to take away the idea that programming is about assembling composable parts, replacing it by a search for the right magic thing from a box of ready-made magic things.

(Plain)TeX always seems the opposite of this. There is never a keyword that does what you want, but you can always do it by using five different mechanisms in concert. You always feel like you are trying to trick the system into doing something it was not designed for.

Cartographic generalization is an AI-complete problem. It is doable for a human to decide what to show or not, in order to get a useful map without too much clutter. It is much harder to program a computer to do it. It is very tempting to turn down contrast to make a cluttered map less "loud".

Not quite as wild, but there was a similar thing in Sweden 50 years ago, where an oil burner was retrofitted to the cancelled nuclear power plant at Marviken: https://en.wikipedia.org/wiki/R4_nuclear_reactor . The reactor, which was more or less completed but never loaded with nuclear fuel, was used for various experiments related to reactor safety.

In the early days of Vuescan, you got unlimited updates for something like $40 and, as far as I can tell, those agreements are still being honoured. I suppose Hamrick could have said "Sorry, your license is for Vuescan, but now it’s vu-scan, that’s different", but he hasn’t.

There is a legend in Sweden, that during some power struggle in the 16th century, several high-ranking persons had put their seals on a document which, after a change in political tides, put them at a very real risk of losing their heads in the event now known as "the Stockholm bloodbath". One of them — the bishop Hans Brask — then cracked open his seal to reveal a note saying (in 15xx Swedish) "I'm being forced to do this". He got to keep his head, and the word "brasklapp" (literally "Brask note") now means a reservation or caveat.

(Fellow Swede here). I really want to agree with you, but in practice, the difference between "internal" and "external" is not always clear. For example, if I was producing a printed document in Swedish, I would definitely use decimal commas. (By the way, the time now is not 10:54 — it's 10.54, if you are to believe "Svenska Skrivregler" :-) ) However, when printing output in a terminal window, a comma means that I can't copy-paste that number into that interactive Python session in another window. Coordinates as lat, lon means I can't copy-paste into PostGIS. Makes one long for those LISP systems of the legends, where the system kept track of where things on screen came from, so if the program printed a coordinate and you copied it from the terminal, it was copied as a coordinate, not as text...

Very likely. For some background on the Hershey fonts, the tech stack where they were born, and mr. Hershey himself, there is this presentation by Frank Griesshammer: https://vimeo.com/178015110 .

For a site called "drawing matter", it is interesting that with, I think, one exception the illustrations have no direct connection with the text.

If you're pulling in LAPACK anyway, wouldn't just calling dgels to compute the least-squares solution directly be easier?

It's probably possible to do this in a one-liner using half of the stuff in itertools, but just changing the output data structure to a dict (at least temporarily; one can always make a list from it at the end) would yield code that is short, understandable and gets the job done without linear searches.

Essentially, I'm agreeing with eska's comment, with the addition: "...but consider your data structures!"

groupby looks neat, but it requires sorted input, so it's very easy to convert an O(n) problem to an elegant but O(n log n) program.

EDIT: one could also do it with a one-liner in pandas, which means that as long as the input is less than ten million lines or so, the "import pandas as pd" statement is going to take longer than the actual program...

Back in the day, this got published in SIGGRAPH proceedings: https://www.researchgate.net/publication/220721478_Ray_traci... .

IIRC what happened in France was indeed that the platforms were out of spec, or perhaps the specs were out of platform. The rolling-stock people asked the tracks-and-platforms people for the specs, and got the latest version. The fact that several older platforms still in use were built to an earlier set of specs got lost somewhere along the way...

Wasn't there a period recently — around 1995 or so — when the Linux kernel had to be compiled with a C++ compiler?

There is a legend that (ABBA) sound engineer Michael B. Tretow used to have a small (and completely illegal) FM transmitter in the studio. When he thought he had the mix right, he'd patch the sound out to that and then go down to the car park to listen to the song on his car stereo. If it still sounded good, fine, else, it was back to the draw... er, mixing board.

About error messages: There are quite a few questions on Stack Overflow where understanding the error message followed by a tiny bit of debugging would have found the problem. I always wonder whether such questions are the effect of people simply not understanding the error message. One would think that "'NoneType' object has no attribute 'foo'" would lead the asker to think "oh, my variable is None, now why did that happen, oh, bar() returns None if..." but they're stymied. Maybe the "NoneType" is confusing.

Similarly, there are questions where people claim to have been struggling (or watching YouTube videos!) for hours, while spending 30 seconds reading the manual for the function they are calling would have made it obvious that it does not do what they think it does.

I wonder whether the printing of tracebacks simple causes there to be too much text. I use some tools at work that spew out hundreds of lines when everything goes well, and thousands — most of them useless — when things go wrong. I always hate trying to hunt down errors in those, because I have not yet developed the skill to read them at a glance, so I need to look at all of it. I can read a Python traceback quickly, but a beginner probably can't.

I have noticed that when a Stack Overflow question says "the problem can't possibly be X, because <something>", that is very often exactly where the problem is (and <something> is a misunderstanding).

Isn't "not knowing how to type in a URL" what the web was supposed to be like? The URL:s were supposed to be a behind-the-scenes thing; the users were just supposed to navigate hypertext? Instead URL:s ended up front and center, and we got monstrosities like a domain name for a single movie, because that's the only way of making a short-enough-to-remember URL.

Also, not knowing what application to open a PDF with... isn't that what we have tried to turn user interfaces into ever since someone invented the document metaphor?

The official "keeper of place names" in Sweden is Lantmäteriet, the Swedish geodetic survey. Unfortunately, the search feature at minkarta.lantmateriet.se seems to be down at the moment. However, OpenStreetMap lists at least five islands or islets named "Bjurön", several neighbourhoods, villages and such named Billsta, two farms named Biby, a village named Bertby in (largely Sweish-speaking) Österbotten in Finland, several villages and farms named Bergsbo, etc. My guess would be that nearly all of those names that are plausible Swedish place names actually exist somewhere.