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.
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).
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.
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.
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.
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:
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.
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.