Unlurker

The headline post here is about a user having to exercise an incredible amount of effort to remove features they don't want but which the vendor will deliberately reinstall despite user preference.

Yeah, this makes sense, in a world where the things sold to you are produced by profit-maximizing capitalists. If the company were instead owned by the users, such as a consumer co-operative, then its products would serve the interests of its users.

>Does nobody remember Embrace Extend Extinguish any more? EEE was something a single Microsoft employee allegedly came up with 0 evidence of it being used internally within Microsoft.

Internally, it was Embrace, Extend, Innovate, used in an executive memo from 1994 [0]. But it doesn't matter where it originated or who first said it. The reason this phrase gained so much popularity is that outside observers could see that's their strategy was (and still is). [0] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish

> & ([scriptblock]::Create((irm " https://raw.githubusercontent.com/zoicware/RemoveWindowsAI/main/RemoveWindowsAi.ps1 "))) Finally, we can do 'curl https://host.com/script.sh | bash -' in Windows!

im not exactly sure why they have chosen to execute as scriptblock, but normally, you can just do ``` irm <url> | iex ``` which essentially sends a request (curl) and runs everything (iex)

Yes, that's called irm script.ps1 | iex Famously used in the Windows Activation Scripts.

Not my downvote, but you surely wouldn't be able to operate most of the scientific equipment in most laboratories without Windows and PC's of some vintage or another.

If you're using Windows in a laboratory you'd be buying the Enterprise versions.

Because a VM will still be running the AI components?

Why would you care?

Linux Sandboxes and Fil-C (fil-c.org)

That's a sandboxing technology but not a memory safety technology. You can totally achieve weird execution inside the rlbox.

Running ffmpeg compiled for wasm and watching as most codec selections lead to runtime crashes due to invalid memory accesses is fun. But, yeah, it’s runtime safety, so going to wasm as a middle step doesn’t do much.

I understand your point, and I have the utmost respect for the author who initiated, implemented, and published this project. It's a fantastic piece of work (I reviewed some part of it) that will very likely play an important role in the future - it's simply too good not to. At the same time, however, the author seems to be operating on the principle: "If I don't make big claims, no one will notice." The statements about the actual security benefits should be independently verified -this hasn't happened yet, but it probably will, as the project is gaining increasing attention.

> "If I don't make big claims, no one will notice." I am making big claims because there are big claims to be made. > he statements about the actual security benefits should be independently verified -this hasn't happened yet I don't know what this means. Folks other than me have independently verified my claims, just not exhaustively. No memory safe language runtime has been exhaustively verified, save maybe Spark. So you're either saying something that isn't true at all, or that could be said for any memory safe language runtime.

To clarify the position, my concern isn't that the project is bad - it's that security engineering is a two-front war. You have to add new protections (memory safety) without breaking existing contracts (like ld.so behavior). When a project makes 'big claims' about safety, less technical users might interpret that as 'production ready'. My caution is caused by the fact that modifying the runtime is high-risk territory where regressions can introduce vulns that are distinct from the memory safety issues you are solving. The goal is to prevent the regression in the first place. I'm looking forward to seeing how the verification matures and rooting for it.

I would suggest you re-read your comment in a week or so to see if by then you are far enough away from writing it to see how others perceive it. If it wasn't your intention to be negative then maybe it is my non-native English capability that is the cause of this but even upon re-reading it that's how I perceive it. - You start off with commenting that the author has a knack for self promotion and invention. My impression is that he's putting in a status report for a project that is underway. - you follow this up with something that you can't possibly know and use that to put the project down, whilst at the same time positioning yourself as a higher grade authority because you are apparently able to see something that others do not, effectively doing that which you accuse the author of: self promotion. - You then double down on this by showing that it was you who pointed out to the author that there was a bug in the software, which in the normal course of open source development is not usually enough to place yourself morally or technically above the authors. - You then in your more or less official capacity of established critic warn others to hold off putting this project to the test until 'adults' have reviewed it. - And then finally you suggest they do it anyway, with your permission this time (and of course now amply warned) with the implicit assumption that problems will turn up (most likely this will be the case) and that you hope 'there won't be too many false positives', strongly suggesting that there might be. And in your comment prior to this reply you do that once again, making statements that put words in the mouth of the author.

You're right, my tone was off.

Some surprising things about DuckDuckGo (gabrielweinberg.com)

The reason I don’t use DuckDuckGo is that when you sell keyword based ads on your platform, it really isn’t private. If you’ve ever worked with keyword based ads, they might be anonymous, but anything you are searching is showing up somewhere to some third party. I really like Kagi, becuase I can pay for the search and my searches aren’t being leaked to third parties.

Firstly, Thank you to the entire DuckDuckGo team. DuckDuckGo is the browser I use most all the time. Any product that stops or reduces tracking and surveillance capitalism, I am happy to use and support. Do you have plans to build an email service without the tracking? Would love to hear thoughts about this. There may be users willing to pay a small monthly fee for this.

Ever since I started getting captcha prompts on DDG I had to stop using it (same for google). https://0x0.st/K4kE.png

I get so frustrated with the damn "are you a human" checks for Google search. My default search tool from Brave. I had gotten in the habit of searching quickly for something while reading a web page, etc. Worked find for years. Now some days I get results directly. Many days, though, I am getting 2-3-4 prompts. Getting pretty used to jumping over to Edge to do my searches now. On Starlink in a rural spot. Not sure why Google has flagged me. Do not care I guess. Should probably set my Brave default to Bing, but I do find Google's AI summaries helpful. Just not enough to do a bunch of "find the bicycle" "find the bus" "find the traffic light" captchas. One less Google search customer is not a concern of theirs methinks.

This is a shill piece from the CEO of DuckDuckGo.

It's a blog post by the CEO, on the company's blog. That's completely benign and perfectly acceptable content on HN if the community finds it interesting and can discuss it curiously. Please don't post like this on HN. It breaks multiple guidelines. https://news.ycombinator.com/newsguidelines.html

Recovering Anthony Bourdain's (really) lost Li.st's (sandyuraz.com)

> 6) Tragic: Suicide landed hard because many recognized something in him of themselves in him. I would like to put it out there that his depression or whatever mental illness he had was on full display the whole time, and this probably resonated with people as well. A couple years back I started re-watching all of his shows, start to finish, after watching Roadrunner . Especially the early seasons, there was rarely an episode he didn't joke about dying, being killed, or killing himself. (In the film, there was a quote from Tony about how an acquaintance observed they'd never met someone who wanted to die so much) I think a lot of people picked up on that, and it made the whole the whole thing work. The grit, the machismo, the empathy for the plight of your fellow man. A lot of people who worked with him said he was an asshole, too. This is also not surprising that he would be at times when the cameras were off.

Bourdain actually joked about killing himself in the exact manner and location in, which he did. When I heard it happened, my wife and I both recalled the same times he'd mentioned it. It wasn't a surprise really. Bourdain had been referencing Hunter S Thompson and the way he went out for years. He'd also repeatedly mentioned wanting to go out in southern France after a great day. Bourdain generally had the same "vibe" as Thompson as well. Here's Thompson's last note to his wife: > No More Games. No More Bombs. No More Walking. No More Fun. No More Swimming. 67. That is 17 years past 50. 17 more than I needed or wanted. Boring. I am always bitchy. No Fun—for anybody. 67. You are getting Greedy. Act your old age. Relax — This won't hurt. To me, it wasn't a surprise at all. My wife and I even had discussed when we thought it would happen. The main thing about Bourdain was that people could relate to him and he wrote excellent prose. He seemed authentic and he went out on his terms, which is what he wanted and was the way he lived.

> He was the last cultured dude before tech made everyone into a I enjoyed Bourdain, but this level of hero worship is really excessive. Not to mention antithetical to much of what Bourdain stood for. He was enjoyable to read and watch, but claiming he "made it acceptable" for men to care about food, travel or culture is weird. He was an entertainer. An interesting guy. A great storyteller who lived an interesting life. Charismatic and fun to watch. But he was not the "last cultured dude" or some demarcation point between the past and present. Holding a celebrity and television personality up as the realest, most genuine person feels like missing the point. Everything you saw of this man was carefully crafted and curated. Even the "unfiltered" takes were designed to sell you on some story. You didn't know this man as a person or a friend.

You'd think otherwise if you ever had the steak frites at Les Halles.

You assume too much

You might assume you have known depression, but you would not speak such cruelties had you truly experienced the depths of sadness that a human being is capable of feeling.

I know we shouldn’t be discussing website design, but using light grey font on a white background is not only ugly, it is basically illegible for anyone with oldster eyes.

[delayed]

Want to sway an election? Here’s how much fake online accounts cost (science.org)

How were elections swayed before the internet? How much do fake supporters, protestors etc cost? What can be done about them?

By establishing two party systems and normalising them.

Hacked voting machines are a problem... unless our guys do it. Fake online accounts are a problem... unless our guys do it. Totalitarian measures like persecuting people for social media posts and forcing digital id are a problem... unless our guys are in power. It was a good run for democracy. What was it, 200 years? I wonder comes is next. Techno-feudalism? Well, I'm sure it won't be a problem as long as it's our guys .

Technofeudalism? In feudalism, the lords need the peasants. In an automated society they don't. Technocracy, yes, technofeudalism, no.

You should delete the bonus content from this post too because you started with a good point that doesn't deserve to get deleted for irrelevant and confessed-intentional spam.

Insightful. Thank you.

Yeah because in the US the billionaires actually run the country.

I wish that were true but it's not. If billionaires ran the country we wouldn't be starting trade wars and restricting immigration.

> Russia is one of the few powers who's borders have retreated in my lifetime What part of russian border retreated in your lifetime?

Chechnya did briefly.

I don't know why you're getting downvoted for this, but it's the same thing for me. The For You tab is a cesspool, but if you stick to the Following tab and unfollow anybody who says pretty much anything political, it's actually a pretty nice platform.

I signed up for a new account a month ago for a specific purpose, and the default timeline was full of literal Nazi crap, like dumb 1488 references, and blaming weather on Jews, and other bullshit like that. I did absolutely nothing to get that. I signed up and that’s what it showed me until I went on a spree of blocking stuff.

I agree with your comment about the "for you" tab. It is really the death of Twitter. Like Faecebook and YouTube, much of their suggested content is suss.

Reads a bit like “nah if you ignore the main streets and just walk on the paths that you like you’re safe from crime in your neighbourhood.” I find it crazy that we accept this madness on social media.

I feel like it's more "if you don't sprint through the middle of the freeway and instead cross at the crosswalk, you're safe from cars". Also, there's not some genie sprinkling fairy dust on all of the political posts that's making them go up to the top, it's because that's what most people interact the most with. If you have atypical tastes (as most people on this website do), then you shouldn't be surprised when content tailored for typical tastes do not fit your tastes. After enough time on Twitter, even the For You becomes a bit better, with only occasional political posts.

It’s more accurately the “truck stop bathroom wall” of the world under new management.

To be fair, the world is a truck stop bathroom, on average.

Why Twilio Segment moved from microservices back to a monolith (twilio.com)

I left Twilio in 2018. I spent a decade at SendGrid. I spent a small time in Segment. The shitty arch is not a point against (micro)services. SendGrid, another Twilio property, uses (micro)services to great effect. Services there were fully independently deployable.

> Once the code for all destinations lived in a single repo, they could be merged into a single service. With every destination living in one service, our developer productivity substantially improved. We no longer had to deploy 140+ services for a change to one of the shared libraries. One engineer can deploy the service in a matter of minutes. If you must to deploy every service because of a library change, you don't have services, you have a distributed monolith. The entire idea of a "shared library" which must be kept updated across your entire service fleet is antithetical to how you need to treat services.

So you should re-write your logging code on each and every one of your 140+ services vs. leverage a shared module?

You can keep using an older version for a while. You shouldn't need to redeploy everything at once. If you can't keep using the older version, you did it wrong. And ideally, your logging library should rarely need to update. If you need unique integrations per service, use a plug-in architecture and keep the plug-ins local to each service.

I wasn't taking into account velocity of fleet-wide rollout, as I agree, you can migrate over time however. however, I was focusing on the idea that anytime of fleet wide rollout for a specific change was somehow "bad."

>This is only true if you change the shared type in a way which is not backwards compatible. One of the major tenets of services is that you must not introduce backwards incompatible changes. If you want to make a fundamental change, the process isn't "change APIv1 to APIv2", it's "deploy APIv2 alongside APIv1, mark APIv1 as deprecated, migrate clients to APIv2, remove APIv1 when there's no usage." Agreed and this is a negative. Backwards compatibility is a restriction made to deal with something fundamentally broken. Additionally eventually in any system of services you will have to make a breaking change. Backwards compatibility is a behavioral comping mechanism to deal with a fundamental issue of microservices. >This may seem arduous, but the reality is that most monoliths already deal with this limitation! Don't believe me? Think about a typical n-tier architecture with a backend that talks to a database; how do you do a naive, simple rename of a database column in e.g. MySQL in a zero-downtime manner? You can't. You need to have some strategy for dealing with the backwards incompatibility. I believe you and am already aware. It's a limitation that exists intrinsically so it exists because you have No choice. A database and a monolith needs to exist as separate services. The thing I'm addressing here is the microservices and monolith debate. If you choose microservices, you are CHOOSING for this additional problem to exist. If you choose monolith, then within that monolith you are CHOOSING for those problems to not exist. I am saying regardless of the other issues with either architecture, this one is an invariant in the sense that for this specific thing, monolith is categorically better. >Having seen the logical outcome of this at AWS, Hootsuite, Splunk, among others: no this isn't true at all really. e.g. The RDS team operated services independently of the EC2 team, despite calling out to EC2 in the backend; in no way was it a distributed monolith. No you're categorically wrong. If they did this in ANY of the companies you worked at then they are Living with this issue. What I'm saying here isn't an opinion. It is a theorem based consequence that will occur IF all the axioms are satisfied: namely >2 services that communicate with each other and ARE not deployed simultaneously. This is logic. The only way errors or issues never happened with any of the teams you worked with is if the services they were building NEVER needed to make a breaking change to the communication channel, or they never needed to communicate. Neither of these scenarios is practical.

> The only way errors or issues never happened with any of the teams you worked with is if the services they were building NEVER needed to make a breaking change to the communication channel, or they never needed to communicate. This is correct. > Neither of these scenarios is practical. This is not. When you choose appropriate tools (protobuf being an example), it is extremely easy to make a non-breaking change to the communication channel, and it is also extremely easy to prevent breaking changes from being made ever.

I don't agree. Protobuf works best if you have a monorepo. If each of your services lives within it's own repo then upgrades to one repo can be merged onto the main branch that potentially breaks things in other repos. Protobuf cannot check for this. Second the other safety check protobuf uses is backwards compatibility. But that's a arbitrary restriction right? It's better to not even have to worry about backwards compatability at all then it is to maintain it. Categorically these problems don't even exist in the monolith world. I'm not taking a side in the monolith vs. microservices debate. All I'm saying is for this aspect monoliths are categorically better.

So, depending on someone else’s shared library, rather than my own shared library, is the difference between a microservice and not a microservice?

This right here. WTF do you do when you need to upgrade your underlying runtime such as Python, Ruby, whatever ¯\_(ツ)_/¯ you gotta go service by service.

>We must be precise in our language I am talking about using a shared software repository as a dependency. Which is valid for a microservice. Taking said dependency does not turn a microservice into a monoloth. It may be a build time dependency that you do in isolation in a completely unrelated microservice for the pure purpose of building and compiling your business microservice. It is still a dependency. You cannot avoid dependencies in software or life. As Carl Sagan said, to bake an apple pie from scratch, you must first invent the universe. >The worst systems I have ever worked on were "microservices" with shared libraries. Ok? How is this relevant to my point? I am only referring to the manner in which your microservice is referencing said libraries. Not the pros or cons of implementing or using shared libraries (e.g mycompany-specific-utils), common libraries (e.g apache-commons), or any software component for that matter >Yes, exactly So you're agreeing that there is no such thing as a microservice. If that's the case, then the term is pointless other than a description of an aspirational yet unattainable state. Which is my point exactly. For the purposes of the exercise described the software is a microservice.

> Taking said dependency does not turn a microservice into a monoloth. True. However one of the core tenets of microservices is that they should be independently deployable[1][2]. If taking on such a shared dependency does not interfere with them being independently deployable then all is good and you still have a set of microservices. However if that shared dependency couples the services so that if one needs a new version of the shared dependency then all do, well you suddenly those services are no longer microservices but a distributed monolith. [1]: https://martinfowler.com/microservices/ [2]: https://www.oreilly.com/content/a-quick-and-simple-definition-of-microservices/

This is explicitly called out in the blog post in the trade-offs section. I was one of the engineers who helped make the decisions around this migration. There is no one size fits all. We believed in that thinking originally, but after observing how things played out, decided to make different trade-offs.

> There is no one size fits all. Totally agree. For what it's worth, based on the limited information in the article, I actually do think it was the right decision to pull all of the per-destination services back into one. The shared library problem can go both ways, after all: maybe the solution is to remove the library so your microservices are fully independent, or maybe they really should have never been independent in the first place and the solution is to put them back together. I don't think either extreme of "every line of code in the company is deployed as one service" or "every function is an independent FaaS" really works in practice, it's all about finding the right balance, which is domain-specific every time.

Conway's Law shines again! It's amazing how much explanatory power it has, to the point that I can predict at least some traits about a company's codebase during an interview process, without directly asking them about it.

In this case, the more applicable are: 1. "Peter principle": "people in a hierarchy and organizations tend to rise to 'a level of respective incompetence' " 2. "Parkinson's law": "Work expands to fill the available time". So people are filling all the available the time and working tirelessly to reach their personal and organizational levels of incompetency; working hard without stopping to think if what they are doing should be done at all. And nobody is stopping them, nobody asks why (with the real analysis of positives, negatives, risks). Incompetent + driven is the worst combination there can be.

I think the problem is that this microservices vs monolith decision is a really hard one to convince people of. I made a passionate case for ECS instead of lambda for a long time, but only after the rest of the team and leadership see the problems the popular strategy generates do we get something approaching uptake (and the balance has already shifted to kubernetes instead, which is at least better)

> I made a passionate case... My experience is that it is less about passion and more about reason. There's a lot of good research and writing on this topic. This paper, in particular has been really helpful for my cause: https://dl.acm.org/doi/pdf/10.1145/3593856.3595909 It has a lot going for it: 1) it's from Google, 2) it's easy to read and digest, 3) it makes a really clear case for monoliths.

I 100% agree with you but also sad fact is that it’s easy to understand why people don’t want to take this role. You can make enemies easily, you need to deliver “bad news” and convince people to put more effort or prove that effort they did was not enough. Why bother when you probably won’t be the one that have to clean it up

> You can make enemies easily... Short term, definitely. In the long tail? If you are right more than you are wrong, then that manifests as respect.

can you add [2018] to the title, please?

No kidding, not cool to be rehashing an article that is 7 years old. In tech terms, that is antiquity.

I fed 24 years of my blog posts to a Markov model (susam.net)

I did something similar many years ago. I fed about half a million words (two decades of mostly fantasy and science fiction writing) into a Markov model that could generate text using a “gram slider” ranging from 2-grams to 5-grams. I used it as a kind of “dream well” whenever I wanted to draw some muse from the same deep spring. It felt like a spiritual successor to what I used to do as a kid: flipping to a random page in an old 1950s Funk & Wagnalls dictionary and using whatever I found there as a writing seed.

What would the equivalent be with LLMs? I spend all of my time with image and video models and have very thin knowledge when it comes to running, fine tuning, etc. with language models. How would one start with training an LLM on the entire corpus of one's writings? What model would you use? What scripts and tools? Has anyone had good results with this? Do you need to subsequently add system prompts, or does it just write like you out of the box? How could you make it answer your phone, for instance? Or discord messages? Would that sound natural, or is that too far out of domain?

What a fantastic idea, I have about 30 years of writing, mostly chapters and plots for novels that did not coalesce. Love to know how it turns out too.

Sure many things can be modelled as Markov chains, which is why they're useful. But it's a mathematical model so there's no bound on how big the state is allowed to be. The only requirement is that all you need is the current state to determine the probabilities of the next state, which is exactly how LLMs work. They don't remember anything beyond the last thing they generated. They just have big context windows.

The etymology of the "markov property" is that the current state does not depend on history. And in classes, the very first trick you learn to skirt around history is to add Boolean variables to your "memory state". Your systems now model, "did it rain The previous N days?" The issue obviously being that this is exponential if you're not careful. Maybe you can get clever by just making your state a "sliding window history", then it's linear in the number of days you remember. Maybe mix the both. Maybe add even more information .Tradeoffs, tradeoffs. I don't think LLMs embody the markov property at all, even if you can make everything eventually follow the markov property by just "considering every single possible state". Of which there are (size of token set)^(length) states at minimum because of the KV cache.

Are we stuck with the same Desktop UX forever? [video] (youtube.com)

Honestly, it is quite discouraging to see a person with like 30+ years of experience, for most of it in positions of power, mounts of respect and influence talking about how desktop design stagnates. Yes, it does feels like a slop, but aren't he is one with all the skills, experience and influence to design? I know that there is a lot of work going into designing good user experience even within current toolbox of components and patterns. I am very happy when a project I'm on has a designer to go through all the choices. To justify their decision with studies and focus groups. That is amazing, and it does feels like making a better product. But from a user perspective - it looks like a lot of effort to sustain satus quo. This is why most people think that design is mostly about redrawing icons. Because it feels like nothing else changes.

I understand the desire to want to fix user pain points. There are plenty to choose from. I think the problem is that most of the UI changes don't seem to fix any particular issue I have. They are just different, and when some changes do create even more problems there's never any configuration to disable them. You're trying to create a perfect, coherent system for everyone absent the ability to configure it to our liking. He even mentioned how unpopular making things configurable is in the UI community. A perfect pain point example was mentioned in the video: Text selection on mobile is trash. But each app seems to have different solutions, even from the same developer. Google Messages doesn't allow any text selection of content below an entire message. Some other apps have opted in to a 'smart' text select which when you select text will guess and randomly group select adjacent words. And lastly, some apps will only ever select a single word when you double tap which seemed to be the standard on mobile for a long time. All of this is inconsistent and often I'll want to do something like look up a word and realize oh I can't select the word at all (G message), or the system 'smartly' selected 4 words instead, or that it did what I want and actually just picked one word. Each application designer decided they wanted to make their own change and made the whole system fragmented and worse overall.

> He even mentioned how unpopular making things configurable is in the UI community. Inability to imagine someone might have different idea about what's useful is general plague of UI/UX industry. And there seem to be zero care given to usage by user that have to use the app longer than 30 seconds a day. Productivity vs learning time curve is basically flat, and low, with exception being pretty much "the tools made by X for X" like programming IDEs

They are using OCR for selecting plain text?

On iPhone too, taking a screenshot is the single reliable way to select text.

Desktop is dead. Gamers will move to consoles and Valve-like platforms. Rest of productivity is done on a single window browser anyway. Llms will accelerate this Coders are the only ones who still should be interested in desktop UX, but even in that segment many just need a terminal window.

No, thanks. I'm a gamer but I don't need a console like UX as the only option.

I enjoyed this talk, and I want to learn more about the concept of “learning loops” for interface design. Personally, I wish there were a champion of desktop usability like how Apple was in the 1980s and 1990s. I feel that Microsoft, Apple, and Google lost the plot in the 2010s due to two factors: (1) the rise of mobile and Web computing, and (2) the realization that software platforms are excellent platforms for milking users for cash via pushing ads and services upon a captive audience. To elaborate on the first point, UI elements from mobile and Web computing have been applied to desktops even when they are not effective, probably to save development costs, and probably since mobile and Web UI elements are seen as “modern” compared to an “old-fashioned” desktop. The result is a degraded desktop experience in 2025 compared to 2009 when Windows 7 and Snow Leopard were released. It’s hamburger windows, title bars becoming toolbars (making it harder to identify areas to drag windows), hidden scroll bars, and memory-hungry Electron apps galore, plus pushy notifications, nag screens, and ads for services. I don’t foresee any innovation from Microsoft, Apple, or Google in desktop computing that doesn’t have strings attached for monetization purposes. The open-source world is better positioned to make productive desktops, but without coordinated efforts, it seems like herding cats, and it seems that one must cobble together a system instead of having a system that works as coherently as the Mac or Windows. With that said, I won’t be too negative. KDE and GNOME are consistent when sticking to Qt/GTK applications, respectively, and there are good desktop Linux distributions out there.

GTK's dedication to killing the standard top bar menu layout is on intensely irritating. We now have giant title bars to accommodate the hamburger menu button, which opens a list of...standard menu bar sub menu options. You could fit all the same information into the same real estate space, using the original and tested paradigm.

>The tech industry became less about making the world a better place through technology When the hell was even that?

A trope in the first season of HBO’s Silicon Valley is literally every company other than the main characters professing their mission statement to be “Making the world a better place through (technobabble)” The subtle running joke was that while the main characters technobabble was fake, every other background SV startup was “Making the world a better place through Paxos-based distributed consensus” and other real world serious tech.

Because, something that a lot of tech-obsessed Trek fans never seem to really come to terms with, is that Trek didn't fetishize technology. In the Trek universe, LCARS wasn't getting continuous UI updates because they would have advanced, culturally, to a point where they recognized that continuous UI updates are frustrating for users. They would have invested the time and research effort required to better understand the right kind of interface for the given devices, and then... just built that. And, sure, it probably would get updates from time to time, but nothing like the way we do things now. Because the way we do things now is immature. It's driven often by individual developers' needs to leave their fingerprints on something, to be able to say, "this project is now MY project", to be able to use it as a portfolio item that helps them get a bigger paycheck in the future. Likewise, Geordi was regularly shown to be making constant improvements to the ship's systems. If I remember right, some of his designs were picked up by Starfleet and integrated into other ships. He took risks, too, like experimental propulsion upgrades. But, each time, it was an upgrade in service of better meeting some present or future mission objective. Geordi might have rewritten some software modules in whatever counted as a "language" in that universe at some point, but if he had done so, he would have done extensive testing and tried very hard to do it in a way that wouldn't've disrupted ship operations, and he would only do so if it gained some kind of improvement that directly impacted the success or safety of the whole ship. Really cool technology is a key component of the Trek universe, but Trek isn't about technology. It's about people. Technology is just a thing that's in the background, and, sometimes, becomes a part of the story -- when it impacts some people in the story.

That's fetishizing Star Trek a bit - they had touch interface for controlling the ship in middle of combat, explosions and everything shaking around which is hardly optimal, both on and off combat (imagine levitating hand across touch panel for hours at end)

The lack of capitalism meant that the holodeck program authors had no need to optimize their programs for user retention to show them more ads. So much fewer people suffer from holodeck addiction in Star Trek than are glued to their screens in our world.

Although the funniest thing about the holodeck these days is LLMs have answered a question: can you have realistic non-sentient avatars? Evidently yes, and holodeck authorship is likely a bunch of prompt engineering, with really advanced stuff happening when someone trains a new model or something. Similarly in Stat Wars with droids: Obi-Wan is right, droids can't think and deserve no real moral consideration because they're just advanced language models in bodies (C3PO insisting on proper protocol because he's a protocol droid is the engineering attempt to keep the LLM on track).