sgarland

THANK YOU. I feel exactly the same way.

https://news.ycombinator.com/item?id=49769812

From TFA, on combinators vs. loops:

    items.iter().enumerate().filter(|(_, i)| cond(i)).map(|(idx, i)| Pointer::idx(i, path, idx)).collect()

    while (i < cursors.len) {
        if (actual_index < arr.items.len) { cursors[i] = .{...}; i += 1; }
        else iteration.remove(i);
    }

I’ve been slowly learning Rust, and this style is my main gripe against it, because I feel like I’m being gaslit. Its proponents praise its readability and ease of use, and just… no. It looks deranged. A simple loop is immediately obvious to anyone who’s programmed in any language. Even Python’s list comprehensions are loop-ish.

On-prem.

I’m simply exhausted at needing to refute incorrect LLM answers professionally.

Unless they’ve been elided, there were no indices other than the PK on any table, and no additional statistics. There are correlated columns here: a given country may have produced more movies in a given range of years, as its movie industry built up; a given country may produce more TV series than movies, etc.

Nearly every time I’ve seen someone resorting to hints for a query, it’s because their statistics are incorrect. Adding hints is papering over the problem, and can backfire later if the data shape changes.

This is interesting, and I would like to know how it actually works, but I can’t understand the tech page. I tried.

Could you write that by hand? It would make it a lot easier to understand. I’d also recommend removing the various mentions to previous versions, or at least shifting them to footnotes. It’s confusing to be reading an implementation and then finding out later that it isn’t the approach that was taken.

> The editors that live in the terminal either have steep learning curves built around modal paradigms, or they are too limited to be genuinely useful.

> txt is not trying to replace your main IDE. It is the editor you reach for when you just need to edit something

These two are in conflict. If you just want to edit something, and don’t know [n]vi[m] or emacs, then use nano. If you want line numbers, code folding, syntax highlighting, etc. then it sounds like you should spend the time to learn a more powerful editor.

Honestly, vi isn’t that hard to learn the absolute basics, and you should spend the 15 minutes to do so, because it’s practically guaranteed to be available everywhere. :wq and i are about all you need to “just edit something.”

You’re in luck, the Duo has Touch ID and a big screen.

Houses are also often poorly laid out. I’m not sure if it’s a side effect of open concept, or cheap builders, but it’s definitely a thing. I toured a new build community north of Austin once that mostly had < 2000 sf homes, and they felt spacious, because the layouts were excellent. In contrast, the house we wound up getting was 2600 sf but felt roughly the same to me, because the layout was just “make square rooms.” The primary bedroom was 400 sf, for crying out loud. We put a couch in there we never used, just to fill some of the space.

I agree. I grew up poor, was accepted to every college I applied to, but couldn’t afford any of them so I joined the Navy instead.

10 years later, after a brief stint as an Electrical Distribution Engineer, Samsung hired me because one of their Directors at their Austin plant was specifically seeking out Navy Nuclear-trained Electronics Technician senior leaders — pure luck. While I was there, working nights on a 4/3 - 3/4 schedule, I got into UT Austin’s SWE MS program. That was hard work, and those 2 years are largely a blur. My wife also pulled more than her fair share of work taking care of our extremely young kids, lest I claim I was the I only one working hard.

After that, I convinced a hiring manager that I could do SRE work despite having zero industry experience, because I explained how I had done most of their job description at home. That was a mix of hard work and luck, I guess? Then it’s like any other industry: if you have experience, you can get interviews.

Meanwhile, I have family on both sides who have worked much harder than I have, and have far less to show for it. Tech pays absurdly well in many sectors, and I think people often forget that on here.

Most non-techie people I know have a smart TV without an external streaming box like an Apple TV, Nvidia Shield, Roku, etc.

You can skip `tr` as well - works on BSD awk and GNU awk.

    {
        $0 = tolower($0)
        gsub(/[^[:alpha:]]/, "\n")
        for (i = 1; i <= NF; i++) {
            if (!($i in freq)) order[++n] = $i
            freq[$i]++
        }
    } END {
        for (i = 1; i <= n; i++)
            printf "%d %s\n", freq[order[i]], order[i]
    }

> CERN has clarified that their focus with the migration is on their industrial accelerator-control computers while data centers and experimental computing remain on RHEL/AlmaLinux.

For control systems, it’s perfectly reasonable to be using old stuff. Other than power consumption, you aren’t really losing anything, and I think that they famously have some other equipment there that consumes a touch more power than some old servers.

DHH compared Romani people to wolves [0].

I am so very, very tired of having to even consider, let alone make decisions about, the technical vs. political merits of products. It’d be so great if CEOs would keep their views to themselves.

0: https://world.hey.com/dhh/wolves-sheep-and-gypsies-ba44af6a

> 20 million videos are uploaded to YouTube every day.

Tangentially, assuming a median length of 4:03 [0], and a bitrate of 8192 Kbps (8 Mbps for video, 192 Kbps for audio), that’s almost 5 PB per day. That is insane.

0: https://tubestats.io/statistics/video

I assumed this would be a rant against cloud services, but alas, no.

I do find it doubtful that OP couldn’t skip most of their setup, though; if you have HomeAssistant (which they do), and there’s a direct path from Blink -> Alexa, I’m fairly certain HA could then handle triggering the Google Home Mini devices on its own.

Or, you know, doorbell chimes.

Matter is a communications standard, not a protocol. You can have Matter over Thread, Matter over WiFi, etc.

WRT IKEA, if they’re the Thread-only device, I found one page [0] claiming that some of them can be forced into Zigbee mode.

0: https://automatedhome.com/the-hidden-trick-inside-ikeas-new-...

Immutable records which are retained for legal purposes should be in object storage, not a database.

> Our Kafka setup started the way most things do in a fast-moving engineering team: pragmatically.

> Every change required SSH and port-forwarding. Our Kafka instances had no URL. You accessed them via localhost.

That isn’t pragmatism, it’s lift-and-shifting your test environment into prod. You can in fact run stuff on VMs in a repeatable and sane way; it’s called Ansible + Packer (or any other similar combo you’d prefer).

There’s no need to reverse engineer it, just build a Voron 2.4.

Oh shit, I didn’t realize that had been cracked. Nice, I’m gonna switch ASAP.

I bought a P2S, and then literally a few days later, the X2D came out. Thanks Microcenter, and your excellent customer service and return policy. The X2D is everything the P2S is, but with another nozzle.

Agreed. I have an M1 Air base model (also an M4 Pro), and hated the squared-off change for the M2. The wedge was the entire point.

> How many engineers really understand isolation levels?

I feel like there’s no excuse for this one. You need to know how your data store will interact with your query and others.

The problem, I think, is what the tail end of that is, and is what you hinted at when discussing locks: RDBMS interaction. I have come around on this recently (quite recently - after reading and re-reading this article, and the comments), so forgive me if any past comments in my history indicate otherwise.

It is unreasonable to expect a developer to administer an RDBMS. If you're a small startup, you kind of have to out of necessity; maybe if you're lucky, you hire a dev who's also done infra work, and if the stars align, they've specifically administered an RDBMS at scale. But what counts as administration? Let's look at adding a secondary index, possibly the most common DDL.

AFAIK, no ORMs / frameworks (I am assuming here that most devs are using some kind of abstraction for RDBMS access) default to "safe" builds - no `CONCURRENTLY` for Postgres, and no reducing `lock_wait_timeout` to something sane for MySQL (I've no idea about MSSQL nor Oracle, though I also assume that if you're running one of those, you probably have a DB team). So already, there is an implicit assumption that they've read the pertinent manual section[s] for their RDBMS, which seems unlikely. Even if they did, there's a chance they would also need to have read and understood the paragraphs on handling invalid index builds (Postgres), or the impact that foreign key constraints can have on metadata locks (MySQL).

Let's say the line gets drawn at "devs should be able to understand that they [probably] need secondary indices," with implementing those being entirely on another team or service. OK - how much do they need to understand? I think it's reasonable to expect a developer to understand B+trees; after all, they're just a data structure. Should they need to be able to internalize that such that they can understand why doing a range scan on a column in the middle of a multi-column index removes everything to the right of it from B+tree filtering? Probably, but now we're significantly deeper into specifics. Should they know that there are different kinds of indices, like GIN? Maybe. What about different operator classes (Postgres) for them? Maybe, maybe not. What about knowing about its `fastupdate` option, and the related `gin_pending_list_limit` configuration item? I'd love to say no, those are squarely in the world of ops, but then why should they be allowed to create the index at all if it's going to increase someone else's operational burden?

For all these reasons, I don't think it's prudent to have dev teams managing their own DBs. But then, you get into the fight that most places seem to be in, where the devs want to do something to the DB that the ops team knows will be a headache later, they push back, product gets mad that they aren't shipping, ops capitulates, and then the headache predictably becomes real months down the road. Rinse and repeat.

I have no clue how to fix this while maintaining the modern trend of velocity dominating everything else.

Agreed. Plus, if you can get an entire team to tell the PM “this is fucking stupid, we aren’t doing it,” what are they gonna do - axe an entire team? I doubt it. Maybe at big companies, but small ones? Nah.

The older speakers are stuck on an older version of the app (it’s a wholly different app, called S1) which doesn’t have that behavior AFAIK.

The majority of companies are building their stuff entirely in the cloud, where network speed scales with the instance size. I have had to explain this to multiple engineers at multiple companies, who are surprised to learn that network bandwidth isn’t unlimited.

As to your database comment, IME most of the time the bottleneck is the ORM and/or language. The amount of work an ORM does to generate a representation of a row is frankly shocking. Not understanding the cost of context-switching is the language half of it: Python, of course, is single-threaded, but you can use greenlets to cheat, because they’re I/O bound — except for all of them serializing behind a single process handling serdes for the queries.

Sonos’ app is another example of this. As a very brief tl;dr if anyone isn’t aware of it, Sonos is a wireless speaker company that can group speakers in different rooms into zones, so you can have different music playing in different rooms, or all the same, or at different volumes, etc. The quality isn’t going to blow away audiophiles, but IMO they’re legitimately great.

The original design had the speakers setting up a private mesh network, and the app would send commands directly to the speakers via your LAN. Then, they got the brilliant idea to route commands via their cloud service. The app would send commands to an endpoint, which would send them back to your speakers. Imagine trying to smoothly fade volume with a WAN hop. This went over as well as you’d expect, and they’ve since promised to work on performance. Thus far they seem to have been doing so; it isn’t as snappy as the original, but it’s quite a bit better.

They have what amounts to an unlimited budget for AI spend. If it’s so fantastic, why can’t they let it crawl over every piece of their codebase, every metric, every log, and spot these problems before they occur?

“We misconfigured a sidecar” is something I would think AI could quite easily find and fix.

Serious question: do you think your 6 year old is learning coding from prompting an AI?

I have had excellent results from using AI, but it’s only because I understand what it is I’m asking it to look at, and know when it’s wrong. This is proven on a nearly daily basis at my job, where, with identical agents and prompts, I see designs being pushed with objectively incorrect facts, sub-optimal code in PRs, and a general explosion of slop. That tells me that it still very much matters if you know how to do the job without the help of robots.

I guess I just don’t see the point for most applications. If you’re using a DBaaS, as most are, object storage from the same provider is almost certainly going to be cheaper, and it’s a trivial amount of code to handle the separate push / pull code.