I really want to dive in with Cue, but one thing that I got burned on when using jsonnet to generate CloudFormation templates years ago was lack of discoverability for newcomers to the repo.
Taking your sample code as an example, someone might look at the myapp deployment definition and ask: “does this deployment get created in the default namespace or does it automatically create a myapp namespace? What’s the default number of replicas? Are there any labels or annotations that get automatically added?” Etc.
On the flip side, there’s potential lack of “greppability.” The user may have found a problem with a deployed resource in, say, the development cluster, and go to grep for some resource-specific string in the repo, only to come up empty because that string is not in the source but rather generated at by the templating system.
To be clear, both of these problems can affect any method of generating config, be it yoke, helm, ksonnet, kustomize, or cue. It’s like a curse of abstraction. The more you make things into nice reusable components, the easier it is for you to build upon, and the harder it is for others to others to jump in and modify.
At least with Cue you get properly typed values and parameter validation built in, which puts it miles ahead of “everything is a string” templating systems like the helm templates the article complains about.
Ubuntu's installer supports bootstrapping ssh access with this method. Put in your GitHub username and it takes care of the rest. Works for interactive and headless installs.
Ping uses ICMP. Windows blocks ICMP by default, so yes `ping <windows-host>` doesn't work by default. Is your system your father was trying to ping a Windows system as well?
The other thing to check is if he was running another VPN on his machine at the same time. Running multiple VPNs at the same time (both Windows and Linux) requires extra fiddling to map the routing correctly to prevent their rules from overlapping/breaking each. https://tailscale.com/kb/1105/other-vpns
Oh yeah, forgot to mention. On a given tailnet, users can only reach their own machines. Each machine that joins the network has an “owner” shown under the machine name in the admin portal. By default users can only reach their own machines, not everyone’s else’s. As the network admin you can manage that through the ACLs tab.
What is the alternative, here? Letting all machines on a tailnet talk sounds like a security issue. Maybe a better onboarding flow that prompts you to set ACLs when inviting a new user?
It seems you're assuming the firewall or my machine configuration was the issue rather than a tailscale "sharing" feature issue.
I am, among other things, a network engineer, and previously I shared my tailnet with my brother's windows machine by logging him into my account directly, and it worked flawlessly.
I want TS to win, but they've got product and engineering work to do if they're serious.
> That Go uses arbitrary-precision for constant expressions seems dangerous to me.
I'm somewhat baffled by this statement. If a Go program compared a constant expression float against a runtime computed float, it could have unexpected results, but comparing floats in general is dangerous. I don't see how this language quirk increases that danger in a meaningful way.
It's not an issue an issue about whether or not efficient float formats are dangerous to work with rather one of whether they are consistent to work with in a language. It's simple enough to remember when reading about it but will you and everyone else know this from the start and remember it every time it comes up without fail?
That said, for the negatives it comes with it does come with positives as well and I think that makes it worth it.
It's one thing if a language outputs one, two, or zero for this expression. Two and zero are mathematically wrong, but at least they're predictable.
It's another thing if a language sometimes outputs two and sometimes outputs one depending on the syntax of the request. This is reasonable where that syntax change is not an explicit cast to double precision or single precision, but dangerous if it uses a behind-the-scenes default of arbitrary precision in compiled literals and a default of FP32 in implicitly typed literal assignments.
> inefficient raycasts aren't some sort of pathological edge case.
You're right that raycasts aren't an edge case in terms of usage, but Juan Linietsky's point is that the inefficient path used for this API call is a rare exception to the efficient paths used by the vast majority of the API.
I don't blame you for switching from Darktable at all. Darktable can be quite powerful but it suffers from ease of use and discoverability issues. It's not reasonable for a photo processing application to expect its users to deeply understand how it all works under the hood in order to get good results.
As someone who did a deep dive into understanding DT's scene-referred modules, it changed the way I think of photo processing. I now have a hard time using any other photo software.
What did you use as a resource for this? I struggle with DT on every update to get my photos looking like I want when the semantics of a module change or a module is replaced with something theoretically better but practically with more controls that I now need to relearn.
Yup, I have the same experience even in smaller ways. Wavelet decomposition, parametric masks, Lab curves -- these things are fundamental to how I think of image processing now, and it all came out of forcing myself to be productive with Darktable.
None of those things are available in commercial processing software.
(Granted, it was a few years ago I did photography stuff last, so this may well have changed since then.)
I recently upgraded my system and now I can't even open a folder in Darktable, I have to add it to some bullshit "library", put the library in a "collection", and then open a "film roll" from the collection. Why can't I just browse a filesystem tree and click a folder, damnit ...
Taking your sample code as an example, someone might look at the myapp deployment definition and ask: “does this deployment get created in the default namespace or does it automatically create a myapp namespace? What’s the default number of replicas? Are there any labels or annotations that get automatically added?” Etc.
On the flip side, there’s potential lack of “greppability.” The user may have found a problem with a deployed resource in, say, the development cluster, and go to grep for some resource-specific string in the repo, only to come up empty because that string is not in the source but rather generated at by the templating system.
To be clear, both of these problems can affect any method of generating config, be it yoke, helm, ksonnet, kustomize, or cue. It’s like a curse of abstraction. The more you make things into nice reusable components, the easier it is for you to build upon, and the harder it is for others to others to jump in and modify.
At least with Cue you get properly typed values and parameter validation built in, which puts it miles ahead of “everything is a string” templating systems like the helm templates the article complains about.