Groxx

Yep. Takes a while to get everyone over the "someone's coming, MANIC CLEANING TIME!!" urge, but I find it a lot more pleasant to just... help clean if something needs cleaning? It's a shared space. I don't clean for fun, but it is rather nice to remove a bit of stress from a friend's plate.

There also used to be pretty strong social expectations to host and visit such parties. That was essentially gone by like 1990, for my area, and I always kind of got the feel that everyone was glad to see the expectation disappear.

They can be fun, but I and almost everyone that I'm friends with much prefer to simply visit and hang out with no plans at all. Just be there, maybe chat a bit, maybe ignore each other and read a book for a few hours, maybe find something to eat / do a lightweight potluck. Which rather sucked that COVID ended up shutting down almost all of our communal places to visit for that.

But we used global warming to eliminate winter! For the shareholders!

Kinda. If there's a versioned release at the same SHA, the next `go mod tidy` will replace it with the version.

And while the go.sum file in a module is returned by proxy.golang.org (somewhat surprisingly), that only includes the module's dependencies, not itself. So you're still stuck trusting a goproxy to serve you the correct data.

Also look at their advertising. Endless "X% faster" mentions that often get significant visual space, but when was the last time you saw "security updates 7 days earlier" or "tagged memory for better safety"? Even a single mention of "security" on a phone's manufacturer page is uncommon, and that's usually just mentioning a normal Android feature, or something like Knox or Secure Folder and not "we made choices that make a common class of attacks much more difficult or impossible".

The numbers aren't zero, certainly. Nor does it imply directly proportional levels of effort. But they are incredibly obviously given wholly different levels of attention on nearly all phones, by nearly all phone manufacturers.

I mean OsmAnd - other mapping apps don't slow down anywhere near this much.

OSM-rendering apps are a fair bit more computationally-expensive than many apps, so I do expect them to show the allocator's cost more, but OsmAnd stands out quite starkly against every other app on my phone.

I quite liked the Despecialized editions when I watched them quite a while ago, for anyone who hasn't seen them - the audio remastering is very appreciated (VHS rarely has good audio), but certainly not the poorly-fitting CGI additions.

And those weird ewok blinks that are half way between Jim Hensen and Bettie Boop...

The fairly obvious answer here is "OEMs don't care about security because very few people will pay for it, either with $ or time". Benchmaxxing sells better.

Huh. Yeah, it is noticeably faster on my 9a with that disabled. I wonder what they're doing differently...

As a counter-anecdote: I've had such consistently bad results from its AI summaries that I've changed over to the no-AI page entirely - well over half have been very obviously incorrect or answering something completely different but spelled similarly (but not the same, especially true for chemical names), and the links it includes as references often directly oppose its summary.

I suspect the model might just be too small? Which makes sense when exposing it for free, but it's still a bad experience.

Yeah, it still very much tastes like Google in many of the worst ways :/ clearly Google isn't actually running the project, it's far too well run for that, but the same general "why would anyone need [that thing nearly the entire open source world does outside Google's monorepo]?" ignorance pervades a lot of it.

Which is a shame because there is quite a lot to like about Go in practice. And in spite of it all I'm thrilled that it is eating into Python's share in a lot of places.

None of this seems particularly different from doing <i>spans</i> inline (what if you forget to close one? or they overlap?), but it has a major benefit of being very backwards compatible, supporting future variants in parallel for gradual migration, and doesn't require any changes to search tools. And separating markup instructions from content is generally a very good idea.

And you could use markdown. Just get the rendered spanned text result and transpile it. This would be true for any editor as well, just get convert it to spanned text, edit, convert back.

And with HTML you'll still have to specify what subset you support, and many tools won't support that either. Markdown suffers from this too, by supporting embedded HTML, though at least commonmark is pretty baseline and well supported.

Go is not really an outlier for not having signed packages (there are a fair number that have it, but far from most)... but definitely stuck behind common accepted practice. By decades, if comparing against some (e.g. Java).

Which keeps happening with stuff they rebuild from scratch - an excellent and somewhat unique first showing, far beyond what most first attempts manage, but followed by near-complete stagnation while issues that everyone familiar with the field predicted from miles away pile up.

I broadly like Go's "the import is the hosted location (or a pointer to it)" quite a lot, as it largely solves name-squatting and ownership and a lot more (while allowing major risks with domain sales/abandonment), but yeah - I really do wish they baked a SHA into the go.mod (not just go.sum) so you could find a library and get a known-good download from any proxy with any name. A few languages now have content-addressed imports/packages, instead of just adding hashes as verification, and I hope we see more in the future.

Signed modules / including the signature hash would also solve a lot, e.g. it'd mean domain sales no longer silently inherit full permissions. It's sorta a shame that Go keeps doing such a good job at a minimum-viable wheel-rewrite, but then lets it linger for so long without catching up to the rest of the programming world.

Go monomorphizes quite a lot, so that's mostly incorrect - it'd be relatively true for Java, for comparison, ignoring Graal. https://github.com/golang/proposal/blob/master/design/generi... there are only exceptions when you instantiate multiple different types that share an underlying type/layout, all other cases (including different types) are monomorphized. E.g. `type x struct{a int, b float32}` and `type y struct{b int, a float32}` share codegen, but if you even just swap the type order (float32 then int) they wouldn't.

The primitive generic atomics in the stdlib don't run into those details, so you really do get pretty much exactly the compiled code as what you'd write inline by hand:

>In particular, fundamentally different built-in types such as int and float64 are never in the same gcshape. Even int16 and int32 have distinct operations (notably left and right shift), so we don’t put them in the same gcshape.

Yeah, channels are the main pain point. In addition to the axioms being simply weird (because it's an easy set to implement), another major problem is that you're essentially forced to use them because they're the only things that can work with `select`, and that's the only reasonable option for many operations. Especially if you touch other code, like the stdlib.

That and the lack of tooling around mutex usage / concurrency correctness. The race detector is legitimately excellent and every language needs it, but it can only catch races that you trigger in tests/builds with it enabled, and few projects write anywhere near sufficient concurrent tests to catch issues in practice. There isn't even a "this var claims to be protected by lock X, but it is not held [here]" lint, or "this var is atomic but used non-atomically [here]" (though this one is significantly less of an issue with generics, as safe zero-cost abstractions now exist).

The amount of garbage has also dramatically increased lately, spending a lot of that attention in places other than a normally-not-attacked-at-all entirely internal system.

It really isn't a high profile target, lots of fairly obvious issues is to be expected. Which is not at all a good thing, but very obviously the status quo for large software.

There are adblock filters and extensions for that fwiw.

YouTube does make some kind of changes significantly harder to build than simple scripting will handle though. I do definitely see some reasons for specialized apps, and video is a fairly prime example of where they're often more capable or more (power/time/whatever) efficient.

One only needs to encounter AI-Enhanced™ products a few times to develop a strong distaste for the whole field.

More compact lenses are a constant improvement, but one of the main things here is just moving compute and power off of your head. Which many have done before.

Honestly I don't know why that's not more common. I've used puck-based ones, they're great - far less heat and mass on your face is a major benefit. They're also usually easier to plan upgrades for, as the two most costly pieces (which do very different things and have very different progress cycles) are separated.

Yeah, I've switched to ultra-light rimless glasses and I really do not want to go back. I no longer have sore nose-pad dents at the end of the day.

(I have a fairly strong prescription, so the literal glass in my glasses does weigh a fair bit more than for most people. Yay modern optional media! It's so much nicer than it used to be)

I suspect they meant it as "they claim it is already calibrated, but it can't be, because there is no universally correct calibration", and not "it is not possible to calibrate Jev", but I read it as the latter at first too.

Like onion/ipfs/many others, I'd expect gateways to pop up if it grows relatively popular. If LLM scrapers don't destroy them immediately, at least.

I've had multiple that do it. they're quite visible in the right light. you can also see it when your yellow cartridge runs out, despite printing exclusively black and white, while the other color ones are full.

"most" might not, I can't claim anything there and EFF claims most don't, when they were checking on it in 2015-2017. I'm pretty darn sure that some do though.

It's also not subject to signal loss issues like anyone who uses a phone is quite familiar with. Unless you have narcolepsy.

The Shepard tone of "progress"

You can use "the" in the original sentence just fine if the pool had been established earlier, like with planning a pool party. Then the pool is the pool that you'd be using, and not simply a pool that will be found at some point in the future.

GET requests can have bodies too, and many low-level APIs will allow it - given how few things seem to be aware of this, you could probably sneak stuff through that way too.

>This leads to passkeys being the perfect fit for a corporate environment, but a poor fit for personal security.

I 100% agree - almost everything about them screams "this is The Ideal Corporate Solution".

This isn't a bad thing, it's nice to have a standard for corporate uses. And the attestation-DRM stuff makes perfect sense there, you already have MDM and it fits with that perfectly....... though not all that differently than using MDM to set up client-side certificates. But app/OS support is better, for some reason. Why didn't they just improve that flow?

For personal use though, they seem outright hostile to people living in the real world with common failure modes. It's outrageously clear that normal people were a distant afterthought - just look at how hostile it was to syncing at the beginning, and how long it took to get key exporting (and how directly hostile they were to anyone building a stopgap in the meantime).