decasia

@tptacek I think my question about your post is this — right now people rely on a lot of apps written by professionals for things like mobile banking, messaging, medical providers, mobile payments, and subscription services (music, tv, etc). The interests of the app publishers aren’t aligned with total user freedom — banking app developers don’t want a totally malleable OS where there are no process separations or trust partitions. Rather, they want to rely on OS level guarantees that their code is isolated from other apps, that the binaries are signed, that the platform is somehow trusted.

I love your idea of an OS where users write their own apps as they want. But if they want to connect to third party services or use commercial software, won’t there still have to be a lot of security guarantees? I don’t just mean the depressing “browsers must implement DRM or you can’t watch streaming video.” I mean “how will medical providers trust your device enough to give you your lab results” if you are thinking of majorly changing the mobile device security model.

It’s not a hostile question, I’m genuinely curious about this design tradeoff.

Ok, I found these:

https://www.instagram.com/reel/Da3NGbfk6Lo/

https://heated.world/p/another-summer-day-stolen

I have been trying to find the original source of this quip for a long time. It stays in my head but I don’t know quite where I saw it.

The CCTV footage was one of the most heartbreaking things I have seen on the internet lately.

It makes me think a bit of the Johnstown flood from 1889:

https://en.wikipedia.org/wiki/Johnstown_Flood#/media/File:Th...

Yeah, I just discovered this and was also amazed.

https://decasia.org/tech/2026/02/raise-not-a-reserved-word.h...

This being said, I don't think there is any requirement technically that every core method can also be re-implemented in Ruby... There are so many methods that are just thin interfaces to something written in C, whether because they are touching VM internals, or for perf reasons, or because they make system calls or call external libraries.

It's a neat project. Write cross platform desktop apps in C. Presumably it would not have been very usable in practice in the late 1980s, because of all the OTHER system interfaces that still weren't portable, even if the windowing system was available in a portable way.

I can remember the subsequent period in which Java desktop apps were relatively common. They had cross platform UI by default. But the problem was:

1) cross platform GUIs are ugly by default, compared to fully native desktop apps, because they don't entirely replicate the affordances or the style of the platform;

2) in the Java case, it seemed heavyweight to install and sluggish compared to native apps;

Point 2 would not have applied to stdwin, as it would have produced small compiled binaries I suppose, but Point 1 would have.

So in the end, obviously web apps (and partly, Flash) took over the niche that "cross platform desktop apps" had once tried to fill, and then it was something of a dead zone until Electron, as far as I remember.

I had a long conversation with a fellow parent sitting next to me at soccer practice today. Never met her before in my life, but we just started chatting about soccer logistics, and then I just started asking her about her life. I learned about her 5 kids, her tough relationship situation with her spouse of 16 years, her having moved here from Arkansas as a child, her feelings about how gentrification damaging local communities, her dream of moving out of the USA to another country, how there are the same kinds of social problems most places, how we can come to empathize more with our parents as we get older, and probably more things too I'm not remembering. These are the kinds of things you can talk about if you happen to have good rapport with someone and they feel like it...

I won't say I have conversations with strangers like that all the time, but it is 100% possible, and a lot of people really do appreciate it if you bother to talk to them. People often like being asked about themselves (I used to do cultural anthropology research so I have had quite a bit of practice too...).

There are of course reasons why it doesn't always work or becomes awkward. For example, gender is a factor - a significant part of the population is much more comfortable having same-sex conversations with strangers - not to mention other sociological factors around race, class, nationality, all the obvious things.

Counterpoint: I thought it was a useful analysis — I was very disappointed when the local Joann's closed and this added a bunch of context I would not have had otherwise.

Strongly agreeing with this comment…

I realized early on in my enterprise software job that if I produce code faster than average for my team, it will just get stuck in the rest of our review and QA processes; it doesn’t get released any faster.

It feels like LLM code gen can exacerbate and generalize this effect (especially when people send mediocre LLM code gen for review which then makes the reviews become painful).

This reminds me exactly of "The Art of Turboing"[1]

[1] https://www.macwhiz.com/blog/art-of-turboing/

I thought this was a really good piece of writing. It’s rare to do something like this because the job discourages it by putting PR filters on everything you say.

My uncle was a pretty big pop star in the 1960s. His group at one point had a big fanzine, they were household names across the country, over time they had stalkers and weird fans and all that, made movies and albums, had big parties and knew other famous people, pretty much all those things that the OP writes about (circa 50 years later, some of it has changed but not that much).

He could be charismatic and surprisingly eloquent and I could picture him writing a piece like this, if the mood had struck.

He also lost pretty much all the money through mismanagement (several times over), eventually moved out of LA, had a tumultuous family life with numerous spouses and wasn’t around much for his kids, and after his 40s was trapped in a sad cycle of reunion tours because the band still needed the money. The tours still had some level of excitement and crowd enthusiasm, even pretty late in life and I guess he always loved the stage, the performing, all that. But in the end, I kinda felt it seemed like a lonely existence. Hard to form really deep connections when you’re always traveling and often away in your head.

My current org uses this:

https://libyear.com/

I misinterpreted the title and was hoping that this was going to be a post about realtime algorithmic music generation from the Postgres WAL, something like the Hatnote “listen to Wikipedia edits” project.

http://listen.hatnote.com/

Agreeing with most of the other comments here that this discussion needs more context which we don't have...

If the request for additional access controls/access cleanup came from one of the Ruby Central funders, could we not know who that was and what exactly their ask consisted of? I am interested in knowing their side of the story, and what the motivation was. (But in general, cutting off long-time maintainers' access seems like a bad choice - as presumably they have long since proven their good will toward the ruby community as shepherds of these projects.)

I have a toy web application that accepts a very, very low rate of writes. It's almost all reads.

It is implemented like this:

- The front end uses react to draw a UI.

- It fetches data from a JSON file stored on S3.

- When we get a write request, a lamdba function reads the JSON file, parses it, adds new data, and writes back to S3.

The main selling point for me is that almost all of it is static assets, which are cheap and simple to host, and the tiny bit of "back end" logic is just one nodejs function.

The previous implementation used SQLite and a golang back end, but I eventually got tired of having to maintain a virtual machine to host it.

“If the devotion scholars feel toward their work is intense and sometimes irrational, it’s because this is one of the last spaces of unalienated labor”

Speaking as a former academic, I don’t really agree with this — I think academia can make you believe wrongly that it’s a kind of “unalienated labor,” but actually the alienation runs deep, all the deeper when it’s invisible at first glance.

Yes, you don’t have to make something that is sold to customers or that fits in a JIRA ticket. But when you stop and think about it, you’re going to be doing research based on topics and paradigms that other people have largely defined (advisors, peers); you have to publish in journals that are often for profit and pay you zero; when you teach you usually don’t get paid all the tuition that your students are paying per course (the institution takes a big cut); you end up doing a lot of silly things to have a solid institutional position… TLDR, it has great moments of course, but it isn’t unalienated.

Remind me to stick to my hyperlocal fast food restaurant that only has one location and probably doesn't record every conversation you have with them or use any of the other gross surveillance technology that was recorded here.

The story is really about two things. Their poor information security is pathetic, but their actual surveillance tech is genuinely kind of politically concerning. Even if it is technically legal, it's unethical to record conversations without consent.

To be clear - this isn't an endorsement on my part, just observations of why cloud-only deployment seems common. I guess we shouldn't neglect the pressure towards resume-oriented development either, as it undoubtedly plays a part in infra folks' careers. It probably makes you sound obsolete to be someone who works in a physical data center.

I for one really miss being able to go see the servers that my code runs on. I thought data centers were really interesting places. But I don't see a lot of effort to decide things based on pure dollar cost analysis at this point. There's a lot of other industry forces besides the microeconomics that predetermine people's hosting choices.

Regardless of the cost and capacity analysis, it's just hard to fight the industry trends. The benefits of "just don't think about hardware" are real. I think there is a school of thought that capex should be avoided at all costs (and server hardware is expensive up front). And above all, if an AWS region goes down, it doesn't seem like your org's fault, but if your bespoke private hosting arrangement goes down, then that kinda does seem like your org's fault.

About this, I noticed a relatively prominent gem maintainer publicly announcing his efforts to avoid rubygems security measures:

> I'll try to get a unicorn 7.x release soon but tests take forever to run on ancient HW and I need to ration releases to keep download counts low in order to stay under the MFA threshold on Rubygems.org

> I don't ever want users viewing me as trustworthy nor liable for anything I do, so no MFA nor sigs from me; just source + docs :>

If I understand correctly - the idea is that the unicorn maintainer does not want to be viewed as trustworthy and is avoiding MFA and signatures because they could build trust that isn't, in this case, wanted.

https://yhbt.net/unicorn-public/20231214230933.M299458@dcvr/

For what it's worth, I really enjoyed "Traceroute Isn't Real." I have noticed for quite a while that the data from it is at best patchy, often apparently meaningless. So it's helpful to see the explanation of why that is expected behavior:

https://gekk.info/articles/traceroute.htm

(If it's outdated I'm curious if anyone knows relevant updates?)

I spent a few years trying to work on legacy PHP systems. Would never take another job using it if I had any choice. Most large tech companies do not have large PHP codebases, and most small ad hoc PHP codebases are awful to work with (in my experience), so the intersection of "uses PHP" and "higher quality software engineering" is pretty small. I won't say it's an empty set, but it's a small opportunity space. Meanwhile, the odds of having to work on really awful codebases are... high.

Generally - we live in a world with lots of fantastic programming languages, so I would never choose PHP for a greenfield project if I had a choice, and I would not pursue professional opportunities with legacy PHP codebases except in very special circumstances.

I was trying to reinstall my rear wheel the other day after removing a bike trailer. I apparently didn't tighten it down enough and the wheel came out of the brackets as soon as I started to ride, causing an instant crash and a lot of bruises.

Things like that make me feel apprehensive about trying to learn more bike maintenance stuff myself. It's almost inevitable to have to patch flat tires though so you're always going to be reinstalling the wheel yourself, but I don't touch the brakes even if it seems like an easy fix.

Just in case you ever had any doubts about whether baseline competence or domain knowledge were important in technical leadership (and yes, I would consider disaster response a kind of technical leadership) - this kind of story makes it so clear what happens when the people doing the hiring just don't care.

We aren't expecting LLMs to come up with incredibly creative software designs right now, we are expecting them to execute conventional best practices based on common patterns. So it makes sense to me that it would not excel at the task that it was given here.

The whole thing seems like a pretty good example of collaboration between human and LLM tools.

> Information loss is an inherent property of large organizations.

That's such an interesting axiom, I'm curious if you would want to say more about it? It feels right intuitively - complexity doesn't travel easily across contexts and reaching a common understanding is harder the more people you're talking to.

It basically is like having politically motivated human chaos monkeys running around the data center randomly killing systems and seeing whether anyone notices.

To me software engineering is an interesting and kind of inexhaustible field, but the longer I do it, the more familiarity I have with the problem space, and some parts of it can become routine (it's ok to do things the boring way). And so I don't experience it as a constant adrenaline filled racecourse — often it's just an interesting professional activity. And if I decide to get deeply emotionally drawn in some of the time, that's my choice, rather than a requirement of doing my job.

(Obviously, the job evolves a lot over time and will keep doing that, but it isn't always starting absolutely from scratch every time either.)

I have to confess I am guilty of this — I used to just draw some unstructured circles and arrows on a whiteboard and call it enough.

Lately I've been trying to work my way through lots of different diagram types from https://plantuml.com/, and it does help to wrap my mind around the existing options.

Yeah, the original script I rewrote was doing about 15 different operations depending on the user input/arguments, so I guess it indeed reached the point you're describing where there were a lot of common patterns. It's just that instead of being 15 separate scripts, it was one gigantic one with a lot of conditionals and case statements.