Navigation is supported, with travel times given for walking, ox cart, pack animal and horse. The feature is a bit hidden: you need to click the place marker at the bottom right.
Vending machines outside is pretty much the standard for ramen restaurants. Most of them will take passmo/suica, which most foreigners are also likely to have since it is also used for all public transport.
Even with all the GNU tools available there are still a lot of system-specific things that you may need to know: supported C version, supported C++ version, how to invoke the compiler, correct compiler flags for warnings / desired C or C++ version / etc, where to install things, how to install them and set the right owner and permissions and many many more. Autotools (and cmake) can figure all of that out for you. If you operate in a monoculture and, for example, only deal with a single Linux distribution on a single architecture most or all of this may not be relevant for you. But if you target a more diverse set of environments it can save you a lot of headaches.
Let me change that a bit: "it's pretty ubiquitous in the US". It's not common everywhere. My personal observation (in NL) is that with the transition from cash to contactless payment it seems to be becoming less common over time. Payment terminals here are not setup to ask for a tip (with very rare exceptions) - you just pay the amount on the receipt directly.
What matters is that there is nothing listening on port 80 on the same IP address. That may be hard to control if you are using an environment with shared ingress.
/mnt historically was used as a single mount point. This became problematic when it became common to have multiple temporary mounts, for example a CD-ROM and a USB stick. /media solved that by stating mountpoints are folders inside it, eg /media/cdrom.
It primarily existed to standardise paths between different Linux distributions. This, along with the LSB, was intended to make it possible to ship software that would work on all distributions.
> Just because the header is set, it doesn’t mean it’ll do anything
But they can track proxy metrics for this. For example people using GMail's builtin unsubscribe feature more than once with the same unsubscribe link for different emails is a pretty good indicator the unsubscribe did not work.
It's even worse: you can not access Mail's settings until you have configured an email account in Mail. Before that the settings options is greyed out.
zserio [1] has the former at least. It isn't intended for the same use cases as protobuf/capnproto/flatbutter though; in particular it has no backward or forwards compatibility. But it's great for situations where you know exactly what software is used on both ends and you need small data and fast en-/decoding.
The WISPr[0] standard was created for this purpose, and is (or was by now?) used by companies such as iPass to their customers to transparently log in to most WiFi hotspots. I don't think that standard is accessibly anywhere these days. I made a Python implementation [1] that should still work.
Reading the article they are not generated files, but files that are never touched by developers. Translators will work with those files. I expect that for translators they have a different sparse checkout that only fetches .xlf files for their target languages.
WebRTC still requires you to implement your own signalling layer, which is where most of these problems occur. Using XMPP for signalling in combination with WebRTC is very common.
It has probably been 20 years since I did anything with deb and rpm, but I think this still holds true:
The deb and rpm formats had a very different philosophy to handling dependencies: the deb format relies completely on package names, while the rpm format also allows you depend on the existing of files (or other things?). That implies that the doing/deb ecosystem only works if you manage the entire OS, while rpm (at least theoretically) allows you to use rpms in a system managed in some other way. Of course that capability in the package format itself did not mean people used that.
The file formats are also slightly different: dpkg/deb is completely build using tar and ar, while rpm is a custom binary based on cpio. That also made the deb format flexible enough to not have needed any changes in 30 years, which is pretty amazing.
The source formats have a lot more differences, but I don’t know enough about those. From what I remember srpm used to be more powerful, but Debian’s source format has caught up by now.
A nice side effect of only Debian using dpkg/deb, at least historically, was that when you got a deb file it was guaranteed to work on your Debian system, but for an rpm you could never predict if it would work on your RedHat/SuSe/Mandriva/TurboLinux/etc. system.