also many watches are incredibly thick and I apparently routinely get my wrist within millimeters of darn near everything. a thin one (pebble time round) solved that, and being light also means it doesn't slide around or require a very tight strap.
21,070 karma · joined December 16, 2009
Contact me: hn@username.is . The "hn" helps me organize; it's unnecessary, but appreciated.
I'm also currently @groxx@hachyderm.io
also many watches are incredibly thick and I apparently routinely get my wrist within millimeters of darn near everything. a thin one (pebble time round) solved that, and being light also means it doesn't slide around or require a very tight strap.
Anecdotally: at work I saw quite a lot of github-uptime-related issues, and because they're the central host for everything they become *cough* load bearing for a huge amount of the company. Stability and performance has been dramatically worse than the self-hosted phabricator+gitolite before it.
Which is claiming I'm doing nothing because you haven't seen it. The implication is that you're disregarding "my ideals" unless I do something so impactful that you would have passively noticed.
I fully believe that's not what you intended, but that is a rather straightforward read of what you typed out, so I pointed it out.
This is the world-hunger-equivalent bit fwiw. It's rather explicitly "if you care about this, why haven't you solved it", an over-the-top bad-faith argument.
Something is being done, urgently (vastly faster than the larger legal system), and public outrage is loud and annoying and widely visible, which is indeed what I want. Beyond that it isn't especially fair to say "if you like to eat, why haven't you solved world hunger", particularly when those EPA/zoning laws aren't in place yet, so I'll just ignore that part.
Surely that's obvious to other people aside from me. It's an attended system, not a headless server in a rack hundreds of miles away that must not ever alert someone.
I agree that'll be a much better end-state to be in, but is it the best right now? ... idk. We're in an increasingly blatant "smash and grab" phase for major corporations right now, and they need to be stopped quickly.
So people fight by pattern recognition: abnormally incentivized and extremely large? Kill it with fire immediately. It's mostly reasonable and more effective than anything else at the moment.
I agree the total usage isn't particularly large, and any "they'll use up all the fresh water everywhere" FUD is flat out wrong. But it can be a large jump for an area, and they've broadly shown themselves to be incredibly amoral and willing to fight legal battles with infinite money just because they can. They are not good neighbors.
Evolve is one of a relative few that have been around and growing for a long time, and easily have months of (gradual) content. Worth a try if these appeal to you and you haven't tried it yet.
There are many reasons to not like these things nearby (anywhere it affects power or water too). And on top of that they've been "somehow" getting massive incentives and tax cuts, despite bringing in very little money or employment, which costs the area even more in future years.
It's everything combined, and pushback has been somewhat successful. Success in a protest tends to help bring more success to the same protest elsewhere.
But sometimes you do this kind of thing to avoid useless test brittleness: does your test check that `doSomething()` does what you expect, or do you have another test for that and this test only checks that `nowSomethingElse()` changes the object in a predictable way, e.g. updates a calculated field?
If it's the former, then it might be two tests masquerading as one, and this might make sense.
If it's the latter, you've changed a test that only checks what it cares about, and now you have a test that depends on unrelated implementation detail and will probably break unnecessarily in the future. Plus you've removed the assert that was documenting what it expects, so it's harder to tell if fixing it should mean updating both checks, or only the second one.
The two weekend days don't seem enough to catch up to the accumulated work-time, especially if your commute is relatively long (which is true for a large chunk of the USA), so you're just constantly in a deficit until you retire... which is more of an "if" than a "when" in many cases.
Which is clearly a problem, but I don't think computers are the cause.
Long form though? Still pretty bad. Probably getting worse in practice, as people have them write larger and larger chunks of text without paying any more attention to the result.
Plus they're extremely easy to build if you truly have a good use for one, particularly with generics.
Alice can send anything in any cryptographic scheme involving two parties, the only real safety in any of it is "are the odds of an accepted different value low enough to be impractical for an attacker". Does that apply here too?
Select, however, is encouraged very widely, and is used very widely, because it's very useful to be able to wait on any of multiple things efficiently. Select is great, you quickly grow to miss it in languages that don't have it. But select only works with channels, and often that means you're essentially forced to use channels where a mutex is much simpler and more natural. It also means tons of APIs are channel-centric because it's kinda the only non-blocking option (atomics exist, but that's a very different kind of non-blocking, and dramatically more error-prone for normal humans to write).
Once you go channel-centric for things like streams or concurrent RX style stuff, it does work, and some libraries do exactly that. But then you run into the historical limitations on generics, which makes for sometimes unnatural code, and channel performance is usually significantly worse than mutexes (it's still very fast, but you don't want to use it for extremely small things). And you are pretty much required to use those channels directly with select by hand because wrapping channels changes some semantics. And the semantics of those libraries are not mutex-y and are different from what most are already used to, because few other languages are channel-centric.
So you end up with high-level channel-oriented concurrency libraries that people only want to use for large expensive operations, thus are only designed for large expensive operations, which means it's not very common over all, and few develop the habit. E.g. there are quite a lot of goroutine-pool-helping libraries for ~seconds of work, but few functional-flavored generic parallelizing ones for opportunistic use.
It's part ecosystem, part language design, and part language history. You can do most of the Java stuff in Go with enough effort, but it just isn't done in practice very much, and it'll look and feel quite different.
Go's generics are getting a fairly important improvement soon though! Generic methods, finally! It should help open up some more ergonomic patterns: https://tip.golang.org/doc/go1.27
Java leans heavily in the other direction: a lot of concurrency is added externally, without changing existing code, often in very declarative-flavored ways.
E.g. Future<T> serves as a foundation for a ridiculous amount of stuff, while Go forces channels for `select` whether they model your problem nicely or not, and they're very difficult (often impossible) to wrap without changing semantics.
There are very obviously lots of counter-examples for both langs (`synchronized`, rill in Go, etc), and I expect Go to become more Java-flavored in time (it already has moved this direction somewhat, and 1.27 will enable a lot more). But I think it's a fair summary of broad ecosystem habits.
1: https://tip.golang.org/doc/go1.27 (not yet released)
>A file’s metadata was stripped through format conversion, re-saving, screenshots, or other means
Ah. So what essentially every single consumer-oriented media host does. Gotcha.
I fully recognise this is a hard problem, but hopefully metadata isn't the only method for media. Standard procedure is to shrink files for storage and privacy reasons, and non-visual metadata goes out the window by default.
... though I'm not sure why that would be preferable over a coarse rolling checksum over all of the output. Seems like that wouldn't influence output, would be equally imperceptible, and probably easier to calculate (compared to "hash seed times running all LLMs supported times number of RNG algorithms, to see if output matches").
Presumably there's some other trick, or it's a red herring / failed experiment and not what they actually do in practice.