glmdev

In _theory_ using a thin-client and booting into a cloud machine means you can "upgrade" your machine in a couple years w/o having to replace the thin-client.

Could be easier for grandma, could reduce e-waste, will definitely be used to pigeon-hole us into an endless hell of subscription software.

I also think "adoptability" should be a consideration. Perhaps AsciiDoc would be a slightly better fit, but every developer I know is already familiar with MarkDown and at the end of the day convincing people to write good docblocks is easier if they don't have to pick up new syntax.

I use VaultWarden to store my 2FA info which (aside from being very handy) replicates the codes offline on each device I sync my vault to.

I think Go's generics are reasonable, but not quite powerful enough to scale.

It's all well and good to generalize basic containers and functions (good, in fact), but I wish the language was better at inferring types.

I'm sure this is something that will improve with time, but a bit after generics were released, I tried to build a type-safe language evaluator in Go using generics and found them lacking the kind of type-narrowing necessary for fully-generic architecture.

Short write-up of my conundrum on SO, if anyone is interested: https://stackoverflow.com/questions/71955121/how-to-type-swi...

TypeScript has me spoiled. :)

I think this is an interesting idea, though I suspect "on net the status quo is worse environmentally" is a hard question to answer w/o the aforementioned in-depth reviews (at least to an extent; obviously the current system has problems).

The concept sounds good in theory, but I think it's going to be nigh unworkable in practice. The NCLB/high-stakes testing era exposed many problems with tying educator pay to student outcomes -- chief among them that student outcomes didn't improve.

It's not needed right _now_, perhaps, but wait a few months or a few years. Next time the job market shifts back to the employers, the incentives will align the other way.

The auto-completion alone is worth it IMO. I've been using fish for 6 or 7 years now, and having it hint ahead some obscure command that I only use once a month saves me so much time reading MAN/searching online.

Pair that with tldr and it's a really good experience.

Surprised I had to scroll this far to see this. It's an objectively cool project, even if it doesn't make the most financial/business sense. Doesn't seem like that's the point.

I keep a .dotfiles git-repo similarly. The configs/custom scripts/etc are organized into separate folders by what they do (shell config/work tools/...) and I use GNU Stow to symlink them into my home directory. Makes setting up super easy:

    git clone <repo> .dotfiles && cd .dotfiles
    stow --target=$HOME --dir=packages shell-config
    stow --target=$HOME --dir=packages work-stuff

I've found this to be much more manageable than tools like yadm since I can pick-and-choose sets of configs/scripts based on the machine I'm using them on.

One particularly annoying case comes up when using IIFEs:

    let c = a + b
    (() => { ... })()

This is evaluated as:

    let c = a + (b(() => {...}))()

which usually results in "TypeError: b is not a function." Obviously this can be solved with a semicolon after the "let c..." line, but another common approach is to just prefix all IIFEs with semicolons, since empty statements are no-ops in JS:

    let c = a + b
    ;(() => {...})()

I personally prefer to forego semi-colons, but I have a hard time getting worked up over it either way.

I have, in moments of desperation, `chattr +i /etc/resolv.conf` before. I understand the rationale behind managing that with a more robust service, but in my experience that's much more prone to the black-box effect.

This seems like a cool concept, but I didn't try it out because the demo requires FULL READ-WRITE access to my GitHub account, its organizations, and private details! Surely reading basic user info would suffice.

Not sure if it's just me, but the website is -really- slow in Firefox. Like, the refresh rate/frame rate is terrible.

I 100% assumed that's what this would be until I clicked on it. I feel like a large portion of (especially beginner) SSH users don't really understand asymmetric encryption enough to understand the implications there.

This is true, though Ethernet seems to be an endemic problem. I have a ~$300 Dell WD19TB that works flawlessly to drive a couple displays, audio out, USB hub, and card reader, but the Ethernet died after a few months.

So now, comically, I have to have a type-C Ethernet adapter connected to the back of my Thunderbolt dock...

I mean, assuming you run the server for this app on the same LAN as your CalDAV server, you don't have to directly expose it to the internet.

That said, my Radicale server is exposed to the internet, and I haven't had any issues. The *DAV protocols are mostly just HTTPS requests with Basic Auth.

From the article it sounds like the main issue is that they lost years worth of building their brand/community/user-base and aren't sure they'll ever be able to publish to the play store under their name again.

Not saying you're wrong, but do you have a source for the 60/1000x number? Curious to read more.

I use an add-on called Codeblocks. It lets you select a block of text and will format it as monospace w/ syntax highlighting in various themes.

Not quite as good as native support (e.g. doesn't update dynamically), but otherwise it's pretty solid.