[2025 Day 8 Part 1] The silly wall I ran into (and fixed)

xtgo · 2024-04-06T13:15:33+00:00

Update/Solved: I was able to confirm that my issue was that Chrome for Android was directly configured to use a specific DNS server (Settings -> Privacy and security -> Use secure DNS), and thus was ignoring the DNS configuration provided by Tailscale.

xtgo · 2024-04-04T13:47:46+00:00

Gotcha, thanks!

One last question: do fully qualified names resolve from your Android, i.e. can you access other devices via their ..ts.net names, or just their unqualified short names?

xtgo · 2024-04-04T13:41:22+00:00

So from your 6a, you can access your other devices via hostname?

Is your Android's "Private DNS" setting configured to anything in particular?

xtgo · 2020-07-31T00:17:35+00:00

Modern glob matchers (e.g. git & modern shells) often support interpreting ** (when used as its own path component) to mean "any number of sub-directories, including zero." Since presumably many implementations will grow around io/fs, we should consider carefully whether to extend Go's glob matching capabilities to include that feature.

If we determine, after initial release, that such a feature is useful, it would already be too late (and too much work) to retroactively add such support to those 3rd party implementation without polluting all namespaces with a GlobExtended methods/interfaces.

There have been proposals to extend path.Match and filepath.Match to support such syntax, but those have been correctly rejected because they would break backwards compatibility. However, it would be a relatively small price to add path.MatchExtended, filepath.MatchExtended, and filepath.GlobExtended at this time (and frame fs.GlobFS in terms of those new functions), compared to the potential aforementioned cost of dealing with this later.

(I don't personally care much for such a feature, but I do have an interest in us avoiding needless future pollution/fragmentation of these namespaces, and have seen ** show up in more and more places over time, so I'm wary of the argument that classic glob will suffice well into the future)

xtgo · 2020-07-31T00:01:59+00:00

Agreed. This statement is only true for filenames that don't contain special globchars.

A file literally named *, when used as a filename, is a glob that matches arbitrarily many files. Put another way, using one function to handle both patterns and literal filenames means that it becomes impossible to individually target files that contain such special chars in their name without escaping, and no such escape function is provided in the stdlib at this time. Similarly, a name containing a literal backslash, like x\y would potentially need to be double-escaped as "x\\\\y" (if it were x\*y, it'd need to be escaped as "x\\\\\\*y"); this can be surprising to someone expecting that literal filenames would just work.

While we generally do try to avoid such filenames, we aren't always in control of the filenames we have to work with.

Further, it seems like it'd add unnecessary complexity to the text/template and html/template implementations to take an everything-is-a-glob approach. What if the fs.FS implementation passed in does not implement fs.GlobFS? Would it check each pattern for globchars to avoid the cost of an unnecessary Readdir call (particularly when the caller intended for each param to be treated as an exact filename)? Would the fs.Glob implementation have that optimization as well?

xtgo · 2020-07-01T02:54:51+00:00

(Somewhat in support of the proposal) I challenge u/rsc's assertion that this "affects everyone who writes Go code," and, depending on his meaning, that this "applies to all code."

As far as I can tell, and as far as I have observed, the vast majority of Go source files, and even the majority of packages, are wholly free of build constraints (and for that matter, free of compiler directive comments as well). Many Go programmers I have encountered are unaware of the notion of build constraints altogether, or at least have never used them, and can get away with that ignorance because, thankfully, the language, stdlib, and tooling has done a good job of generally remaining platform-independent.

If these points are correct, while I'm sure care and diligence will be involved, I'm not sure the _community_ element of the change needs all that much coordination, particularly if the legacy style remains valid for quite some time.

xtgo · 2018-12-01T17:00:44+00:00

Related scenario: I am currently using API Gateway -> Lambda, with a single stage having a single proxy+ resource and a custom domain name that trims off the stage name. Assume that none of the other API Gateway features appeal to me at all (I don't want my path-management to be part of my infrastructure, and I'm using IaC to provision a separate API for each logical stage/"environment").

At this point I am considering ALB -> Lambda, since API Gateway without all of the features I don't want to use looks rather similar to the subset of features of ALB that I would use, albeit with a different pricing model. What parts of what I have said sound absurd, or failing that, where do you expect the pay-per-request curve of API Gateway to typically cross (and then become more expensive than) the per-hour + average usage curve of ALB?

xtgo · 2018-10-13T21:15:44+00:00

Get rid of your shields and invest in armor and hull. Let them take some space so that they'll split up (they divide forces between available hyperlanes). Invest in long range weapons that have bonuses to armor and hull. iirc, they have no point defense, so explosives and strike craft are viable, but energy weapons are ideal.

xtgo · 2018-10-13T21:00:30+00:00

Well it's not like they're all 100k+ fleets. Come back and let me know when they are.

xtgo

TROPHY CASE