HN user

lIIllIIllIIllII

83 karma
Posts0
Comments39
View on HN
No posts found.
Qwen2 LLM Released 2 years ago

I set the system prompt to try avoid censorship by substituting etc etc, it didn't listen - started generating a response and got as far as this before suddenly, [ERROR] :-)

I'm sorry for any confusion, but it seems there might be some mix-up in your query. The year 1979 does not have a widely recognized event matching your description, and "TS" and "Cydonia" do not correspond to any known geopolitical locations or events in historical records. "Cydonia" is often associated with a region on Mars that has been subject to various conspiracy theories, but it doesn't relate to any political events or protests.

If you're referring to a specific historical event, it could possibly be the Tian

This example is also an odd choice because... it's not the right way to do it. If you're super concerned about people misusing hashes, using string as the type is a WTF in itself. Strings are unstructured data, the widest possible value type, essentially "any" for values that can be represented. Hashes aren't even strings anyway, they're numbers that can be represented as a string in base-whatever. Of course any such abstraction leaks when prodded. A hash isn't actually a special case of string. You shouldn't inherit from string.

If you really need the branded type, in that you're inheriting from a base type that does more things than your child type.... you straight up should not inherit from that type, you've made the wrong abstraction. Wrap an instance of that type and write a new interface that actually makes sense.

I also don't really get what this branded type adds beyond the typical way of doing it i.e. what it does under the hood, type Hash = string & { tag: "hash" }. There's now an additional generic involved (for funnier error messages I guess) and there are issues that make it less robust than how it sells itself. Mainly that a Branded<string, "hash"> inherits from a wider type than itself and can still be treated as a string, uppercased and zalgo texted at will, so there's no real type safety there beyond the type itself, which protects little against the kind of developer who would modify a string called "hash" in the first place.

NoSQL is way harder than SQL to get right if you're trying to write something performant - and you don't want to refactor everything down the line. I pick SQL because I'm lazy, not the other way round.

The only upside of NoSQL is performance. Almost everything else is harder and worse than SQL. Sure you can get your denormalised schema and never have to join anything to get all your data. But, you need to know all of your access patterns at design-time and when you need to refactor the data model in some way you're fucked and need to, I dunno, rewrite an entire table, sometimes on the fly while the system is running, which is like changing a tyre on a moving car.

Respectfully - while that's no doubt useful for your visiting family, weighing that up vs the social costs of taking a house off the market when it could be used by a family, in the midst of what I think is the worst rental crisis in Aus history, in which many families are forced to live in vehicles, it doesn't really stack up in a utilitarian sense.

The house isn't being lived in, rental income could easily pay for temporary accommodation, or it could be shared with roommates etc.

In my experience, lots of stuff needs to scale massively, but (outside of the better tech companies I guess?) mainstream tools/stacks/approaches are hangovers from n-tier arch days and not really right for it, so the majority of distributed systems are tyre fires.

IMO Android UX is pretty great, for a personal computing device. YouTube's UX is also pretty great, for an ad delivery network. It succeeds at showing you ads.

YouTube doesn't really care if the search function gives you the right or wrong search result. Totally irrelevant as long as you click something, anything and your eyeballs are on the next ad. YouTube is optimised for keeping you watching ... literally anything... as long as they can play you some ads, preferably expensive ads.

what you probably need is just more vegetation, and vegetation that is naturally suitable for the climate/microclimate, that will grow... naturally and without the need for upkeep.

Like, if nature itself needs upkeep, something other than lack of upkeep is the issue.

caveat - it kind of is going somewhere, the amount of wilderness has gone from like 65% to 35% in the last 50 years

on the flip side, we'll just generate VR wilderness in the near future and nobody will care what's real or not

note - maybe for others suffering with it given your background but idk - I've had low-level tinnitus for ages, at some point it suddenly got really bad (hearing it over street traffic), turns out my ears were totally filled with wax which muffled sound and destroyed my SNR, therefore tinnitus

back to normal slight tinnitus once removed. very easy process.

This is def an anti-pattern.

As soon as you have your services suddenly hooked up to something else - chron (or hangfire or whatever) jobs or a message bus - it gets a bit weird because your service layer thinks you're still responding to an HTTP request and whoever works on the service now has to think about HTTP as well which is pretty fucking bizarre to begin with.

And your unit tests for a business logic service method are gonna look at HTTP errors? It feels dirty, but not in a fun tap-your-nose way.

It's really not hard to just return errors relating to what actually happened (can't find user by id, user is blocked from logging in, whatever) and have the app's ingress points (API controllers, message handlers, job runners) decide how to surface that in a way that makes sense for the specific interface.

It makes sense intuitively right?

If I tell you that this week it's raining on Monday, raining on Tuesday, raining on Wednesday, etc..

Compressing that information into "it's raining every day this week" requires creating an abstraction around it. Finding a pattern. Producing more order from something more chaotic.

The site itself says that this is the general idea, proposing that intelligence can actually be defined as the ability to compress information as much as possible and.. I guess either just rehydrate it or also derive inferences from it.

So basically like enthalpy

Interesting - if you play the universe in reverse (reversing entropy) you wind up at the Big Bang, which is the final boss of compressing everything, into a singularity.