nurple

Days since an LLM screwup cost a company money: 0

I still love using DNSBL as part of a score-based approach. Add Bayesian filtering, spf/dkim scoring, a greylist, and postfix options like RDNS checks.

I see a few spam a week, have never seen a false positive. I think greylisting made the biggest difference after sane-sender checks.

Agreed. Having been part of the internet since its genesis, every day I mourn the loss of the critical mass of the weird and curious that pervaded it. I absolutely abhor the exploiters that came from behind and effected a nerd diaspora to simply transformed it into the same manipulative, self-congratulating trash hole that is so widely lauded as "normal".

I lost my job in a layoff over 6 months ago and really struggled to find something in the state that tech has been in since zirp and section 174 went away.

If there's any positive I see from all of this is that there are a lot of weird nerds out there feeling unmoored, unmotivated, and are looking for somewhere to fit in and do the greatest work of their career. I think that someone(s) with resources who creates such a nerd commune will create something truly special, something that transcends the "normal", giving these misfits something that they fully own, drive, but still share with the same world that looks down on them as "divergent". I have never met a more passionate or selfless group of people.

I think Steve Jobs was an example of this type of nerd whisperer. He knew what drove the people that actually create things in this world, and he gave them a powerful outlet to show their value. I think he deeply felt and meant what they were selling at the time: "the people who are crazy enough to think they can change the world, are the ones who do".

https://invidious.privacydev.net/watch?v=VCz_SiPD_X0

I had a "friend" like you once. We got along well, he would excitedly dive deep with me in tech because he wanted to learn programming, and I would excitedly dive deep with him into creating coffee and beer because I find the stricture in creation leading to creativity endlessly interesting.

However, whenever he'd have his "cool" friends over for parties I wouldn't get an invite, in fact never met any of his other acquaintances. He explained to me once that he likes to keep his different social lives separate, and I was apparently the only one in his "tech" social circle.

That made me feel like shit, and reinforced my self-view as failing to be a normal human.

This is a theme that's continued with multiple "friends" throughout my life, to the point where I eventually just gave up trying, gave up giving of myself to others to simply be siloed or discarded once they got what they wanted from me. I got tired of the lack of reciprocation in giving me a chance to be a part of their actual life even though they were apparently getting enough from me that they were willing to keep me around when it suited their needs.

I hope some day you gain some compassion and can see that people who are different than you are still people, and that treating them as lesser except when you can get something from them (like an interesting dnd game) is a huge part of the problem in these types of people retreating even more from the social and emotional norms.

At this point, why in the hell do you think I would even _want_ to be willful part of the society you inhabit, that treats other humans as you do?

If you think money will motivate the dev, why not lead with that in your issue? I don't think offering to pay money is against TOS.

However, there is a large number of FOSS devs that don't give two shits about your money. Oh hey! Isn't that nice? Doing something you love, and something that brings value to your fellow human, without it being tainted by money?

Some people view the need of money as the problem, and the lack of it involved in their project a very conscious decision.

Stuff like this should be done however the author wants. Your view of FOSS is perverted.

Your post is complete hype, all about people saying things instead of showing things that've actually been done.

For me, 2024 was the LLM exposed as basically pure hype year.

There is no expert of any field I follow online where they're posting up results from AI tooling for any other reason than to show how awful it is. I consider myself an expert in software, and LLMs specifically have only caused me great pain.

Even the one situation where you describe someone describing the ability to work in an absolute vacuum sounds like a huge negative to me. The recent push for DEI policies were even ostensibly about the importance of people of diverse backgrounds and viewpoints working together.

The most important thing you're missing a perspective of scale on is the step you describe as "quality check it". On things I don't know, and have attempted to enlist an LLMs help on, in every case I have had to go back and just actually learn how something works, after time wasted struggling with subtle wrongness in the output.

At least I have the background expertise to do that, however, I have seen a Jr dev's mind get literally rotted by too much time in pure LLM land. Besides the cost of rewriting their code, the company was now the proud owner of a young dev with a mind filled with nonsense.

How do you even weigh the cost of fixing a corrupted human mind?

How does AGPLv3 impact a lab's ability to do research on an implementation?

Crap, I always get that wrong. Thanks for the reminder!

ETA: like I told my kids, if we don't police each other, the LLMs will never learn. ;)

Deregulation is not returning power to the people, it's bestowing carte blanche privatization of profits to corpos, in the wake of near complete regulatory capture, while they dump the negative externalities on the public.

It's a bad pattern for the employee, but a good pattern for employers and the healthcare industrial complex. The possibility that you could be bankrupt if you let your insurance lapse is an enormous concern for employees that may want to leave but can't; much more powerful, and cheaper, than golden handcuffs.

COBRA is a joke, as if most could afford multi-thousand dollar a month bill when unemployed.

What that communicates to me is that those in power, both of the gov and of businesses, are primarily concerned with forcing productivity to make line go up than they are with incentivizing treating people humanely. But really I don't think that's so surprising considering the timeline we find ourselves in.

Couldn't agree more. In the SMEs that I've been involved with, this has had a huge chilling effect on both hiring and innovation. I think that the change is a primary contributing factor to the layoffs and offshoring that have seized the market ever since.

I'm not convinced that this wasn't the intent of the change in the first place.

Here here. The only thing SOC2 has done in my opinion is to create a multibillion dollar business that mainly just drains resources from companies that may not have them, with no guarantees you're actually secure. This usually devolves into security theatre where the CISO and underlings are putting in tools that drown teams with so much noise it's hard to detect the signal.

The people running these programs rarely understand the security space well enough to even tell you what a lot of the hits even mean, which ramps up disdain and division between the groups. This is arguably more detrimental to security as the scanners give execs/management a false sense of security while the noise makes it incredibly difficult to run a holistic security strategy.

My experience with it was a PM creating a ticket for our ops group with the title "install posthog" targeting our onprem k8s infra. He had included a link to the helm chart, but that's about it.

When I cracked open the chart I just started laughing. It installs not just clickhouse (via the operator), but also kafka and zookeeper!

This is _not_ a product I would ever self host unless you're planning to provide a handful of FTEs to install, manage, and fix some of the most complicated software you can run on Kubernetes.

This is a lot like how couchdb handles MVCC. There is a `_rev` field that represents some specific mutation of a document, old revisions stay available until compaction, and you will receive an error if you attempt to write to a document with a different revision than you read.

Snapshot isolation, after all, is basically a method for implementing MVCC. I guess it's no big surprise that this isolation level is problematic for people that don't implement the other half.

Reminds me of early in my career as I was struggling with turning errors in my code into useful messages to the user. I thought exceptions were so cool and that I could just pop them up the stack and voila `print(err.msg)`.

It took me awhile to realize that good error reporting was part of the UX as much as any other feature I wanted to create for users, and that it deserved a seat at the table of the API interfaces.

I think handling timeouts properly is exactly the same case; like TFA mentioned, there is no such thing as a safe/general way to externally terminate a thread of execution. If you want timeouts to be part of your UX, you need to build it just like any other feature.

I kind of agree with your assessment, it would even speak to the popularity of document DBs coming up around the same time. However, I would argue that the decline in deep RDBMS integrations is exactly because of their excessive complexity. Modern software development methods left them behind because their change velocity is awful. This is doubly apparent when you look at features like TFA is talking about, exactly because it's extremely complex to stand up, manage, and make changes to.

I personally left in the era of ORMs exactly because it let me build systems in high-productivity languages and frameworks, but also because the cost benefit of RDBMS integration just wasn't there. The DB is absolutely the highest-risk place to put logic in any stack, if something goes wrong _everything_ breaks and it's the most difficult place to fix things.

I don't know what the future looks like for DBs, but I think we'll continue to see them become even more transparent. Devs just want to persist entities, and integrating at the RDBMS level is a slog.

Ever since the war of stored procedures, I've been very reticent to put any more logic than absolutely necessary into the database. The simple truth of the matter is that the DB server codebases are awful, complicated, places to develop this kind of functionality. I strongly believe these features should be handled at higher layers.

At my last job, in fintech, we used application-level shard routing with each aggregate root served by a particular RPC service (users, accounts, transactions, etc). When one of these aggregate services were asked to pull data, they would query a central routing service for the server and shard the requested data resided in.

Between them and the DB servers we had a cluster of pgbouncer instances to handle connection oversubscription and the routing of queries around DB instances in the face of failures or maintenance.

While this was pretty effective, the work to manage sharded Postgres, DDL updates, caching, locating, and balancing data was still very complicated and error prone, and was the root of many production outages.

I didn't design this system, but after a couple years leading a platform migration, which necessitated getting into all this at a deep level, I would do it differently. Instead of query routing and DB sharding, I would shard the aggregate root services themselves. Each "sharded" set of these instances would have a simple PG instance (with replica chain) behind it that knows nothing about any other set.

At this point, instead of routing being done by the aggregate root services locating and querying data from DB shards on huge vertically-scaled servers, each set only pulls data from their dedicated DB. A routing facade is placed in front of the set of sets that sends requests from consumers to the one holding the desired data.

With this architecture, the complexity of sharding and vertically scaling at the DB layer, and handling connection oversubscription with a query router like PGbouncer, just falls away.

I would keep these sets, and their DBs, rather small to also reap the benefits of small datasets. One of the biggest issues we had with huge DBs is the time it takes to do anything; as an example, restarting replication in a failed chain could take many hours because of the huge amount of data, and any hiccups in connectivity would quickly overrun our capability to "catch" replication up and we'd have to fall back to zfs-send to resnap.

A larger number of smaller DBs would not improve the total time needed to do something like backups or DDL mutations, but it would significantly reduce the time for any particular instance which reduces overall risk and blast radius of a DB failure.

Another thing I think small DBs can help with is data locality, DB automation, and possibly making the instances effectively ephemeral. When your dataset is small, bringing an instance up from a hot backup can take on the order of a few seconds, and could allow you to schedule the root services and their DB on the same host.

For geographical distribution, the routing facade can also send writes to the set serving that shard in some other region.

Agreed it's a good thing. Writing software today is still a slog that turns into a spaghetti bowl without focused intent by highly skilled devs. I think most devs realize this and really want there to be something better, and the only way to find something good is to find a lot of the bad around it first.

I like the thought experiment of adding a new persisted/editable field to an entity in a web app, if you've done full-stack you know all the layers that need to be touched to accomplish this and how lame most of the work turns out to be. After doing that 20 times while iterating, any dev worth their salt starts to wonder why it sucks so bad still and how it could be made better, and some will actually try.

I think it's elegant. I loved MVVM in the postback world, and with SPAs, I see view-specific endpoints as the view-model continuing to reside on the server while the view was split off to the client-side.

If ICMP is allowed into your network, your machine will most likely receive a Destination Unreachable response from the host that can't forward the packet further.

Your application won't see the ICMP message unless you configure the socket to report them(these are considered "transient" errors). On Linux this is done via the socket option IP_RECVERR.

ETA: there's not a ton of value collecting errors at this layer when you're working at L7. The errors that _do_ get surfaced for DU at your layer will be appropriate for the failure handling logic you'll inevitably have already. In this case I think it'd be a timeout, as other layers implement retries in the face of unreachable destinations.

I found these RFCs helpful re: how the TCP layer handles ICMP errors: https://www.rfc-editor.org/rfc/rfc1122#page-103

Section 4.2.3.9:

> Since these Unreachable messages indicate soft error conditions, TCP MUST NOT abort the connection, and it SHOULD make the information available to the application.

> DISCUSSION: TCP could report the soft error condition to the application layer with an upcall to the ERROR_REPORT routine, or it could merely note the message and report it to the application only when and if the TCP connection times out.

This one gets into the nitty gritty of how the stacks interact in order to study ICMP as vector for TCP attacks.

https://www.rfc-editor.org/rfc/rfc5927

Lex Fridman recently interviewed Edward Gibson, a linguist, and they talked a lot about how the brain processes language, including how someone reading code lights up a completely different part of the brain than language.

#426 https://lexfridman.com/podcast/

ETA: I believe Evelina Fedorenko, from this paper, is Edward's wife.

This is why predator drones orbiting for days over protests is so scary, this is exactly the functionality their payload powers.

https://en.wikipedia.org/wiki/ARGUS-IS

https://yewtu.be/watch?v=CpLdL8ONEm4

Which in a real way makes the threat of being left out of liquidity rounds that much more powerful a tool for keeping people looking forward to an actual windfall in their lane.

This is a killer feature IMO. Bind the ctrl-hjkl in vim/neovim for navigation and go between vim panes and tmux panes transparently, beautiful.

Is it not also powered via common-mode voltage? Love how coax engineers are always stacking frequencies, including 0Hz.

Learn Ops. All operations in decent orgs these days _is_ software engineering, and a large swath of those who do it lack deep infra experience and rely a lot on trial and error in more complicated configurations.

Been thinking of going back to college (maths) myself in my post-40s age, but I'm struggling a bit to convince myself that it's going to be the best way to meet my learning goals. The degree itself, at this point in my career, isn't all that important to me, but the social and networking aspects could be quite valuable.

I'm curious if you've made similar considerations.

The thing is that this is a private company, so there is no public market to provide liquidity. The company can make itself the sole source of liquidity, at its option, by placing sell restrictions on the grants. Toe the line, or you will find you never get to participate in a liquidity event.

There's more info on how SpaceX uses a scheme like this[0] to force compliance, and seeing as Musk had a hand in creating both orgs, they're bound to be similar.

[0] https://techcrunch.com/2024/03/15/spacex-employee-stock-sale...

Yes, it's interesting isn't it, how everyone is debunking eachother, and that hasn't changed much from the days of Petrie. Doesn't seem like the "science", after all these decades, is solid and settled yet whatever timeline you believe.