ufmace

I'm in the exact same boat. I was a little unhappy with the ads etc in Windows, but perfectly willing to give Windows 11 a try. But Microsoft decreed that my admittedly a bit old but perfectly workable CPU was incompatible, due to not having a feature I wasn't interested in. I'd need to replace most of my existing hardware to switch. So why not try Linux? It certainly seems reasonable when Windows apparently needs more command-line hackery to maybe work for a while than Linux.

So to Fedora I went! So far, I've been pleasantly surprised. All of the software I want to use installed easily and works, via Flatpak. All of my hardware works fine, and there are actually fewer weird hardware quirks than under Windows. I also appreciate that there are options to turn off behaviors I found annoying in Windows.

It's a bit sad to have to switch due to Microsoft trashing their own OS rather than Linux becoming superlatively awesome, but what can you do.

I get what you're saying, but I don't think punishing bad behavior is practical here. It's like a "enumerating badness" problem - there's way more bad actors with nothing to lose and not much practical way to punish them. There's too many of them and they all have no reputation to damage.

Not saying I have a better solution, just that it's a hard problem. Maybe dissuading some good people who have genuine security issues but don't feel like paying just has to be a cost of doing business.

That's just the thing though - it seems like, to get really good code out of an LLM, a lot of the time, you have to describe everything you want done and the full context in such excruciating detail and go through so many rounds of review and correction that it would be faster and easier to just write the code yourself.

What I'm wondering - their future cash flow may be massive compared to any conceivable rational task, but the market for servers and datacenters seems to be pretty saturated right now. Maybe, for all their available capital, they just can't get sufficient compute and storage on a reasonable schedule.

Okay, it makes sense that that's what it is. Still, it seems to me like that's more of an optimization technique that's applicable to certain specific scenarios rather than a mindset to view all software development as.

I have actually heard of something like that, as arena allocation, though mostly as something to use in a GCed language to either avoid or reduce the impact of GC cycles, also for certain specific scenarios.

I don't get the "individual" vs "grouped" element thing at all. I guess you could interpret everything as a list, where null is actually empty list, but it seems like that would be a ton of boilerplate and architecture astronomy, not a universally better way of programming. I don't see any decent explanation of what "grouped-element" programming is and why it's universally better and more advanced.

If that was really true, you should be able to point to a subset of code developed with this supposedly better mindset and demonstrate that it's actually better in terms of some objective measure like speed, memory efficiency, features, security vulnerabilities, etc. I don't see anything like that though. What are the odds that it really is a better way of programming versus a theory some guy made up? If you're familiar with the "no silver bullets" thing, a ton of things have been promoted by various people in the industry as a universal solution to general problems of software quality at various times, but vanishingly few of them have ever made a real difference.

It seems to me that advances in memory management have been one of the few advancements promoted over the decades to make programming genuinely better and more reliable. Witness the dominance of garbage-collected languages for virtually everything that could possibly be done with them, and the advantages of moving things that can't use GC to languages with more solid non-GC memory management like Rust, which are becoming more clear. I think that's the best element we can lean on for software quality, not this grouped-element stuff.

Oh, I've run Linux on the desktop before all right, for years. I eventually decided, at the time, that Windows was drastically better at "just working" for desktop applications and it wasn't worth the bother.

Now, though, Microsoft's antics with Windows 11 is starting to make me think that might not be the case anymore.

I disagree with AI being part of the OS. IMO, any desktop OS should have absolutely nothing to do with AI. It's only a platform for managing other applications and resources. Remote AI stuff should be on websites only, available only if I choose to go to them and interact, or in apps specifically designed to be AI, like Claude Code or Antigravity.

All the nonsense in Windows 11 has me thinking about trying Linux desktops again for the first time in decades.

Rust might be worth a look. It gets much closer to the line count and convenience of the dynamic languages like Python than Go, plus a somewhat better type system. Also gets a fully modern tooling and dependency management system. And native code of course.

I disagree with the overall point of the article.

I guess maybe they're worse for professional phone reviewers, who switch phones all the time, but I'm not one. In my experience, I think about two-thirds of the time I've gotten a new phone and wanted to switch to it, the SIM card size had changed, so I needed to get a new one anyways, which could only be done by mail order, so took a few more days. And about half of the time the same SIM card did physically fit, something else went wrong, like the APN names wrong, carrier didn't want to let it activate, RCS failed to work, all of which are virtually impossible to troubleshoot. IMO, the dream of universal SIM card portability has been dead for at least a decade, if not longer, and started long before eSIMs came out.

The eSIM on my current phone Just Worked as far as activating. I haven't tried switching to a new phone with it yet, so I guess I'll have to see how well it works when that happens.

Clearly there are cases when both are better. eSIMs are nice for being able to switch carriers immediately, get set up in a new country you're visiting smoothly, and recover the number from a physically lost phone. Physical SIMs are nice if you want to try out a different phone model, assuming they support the same SIM size and you can find the little tool. And also if your phone is seriously damaged but not physically lost. So not everyone necessarily loves them, but I don't think it's a case of the big bad big tech companies are enshittifying everything.

I wonder if it's the opposite actually. When there is a human running a convenience store type of thing, people don't generally spend time trying to convince them of obviously absurd things, particularly if they work for the same company as you. Nobody wants to risk the employee refusing to sell anything to you because you're a time-wasting jerk or maybe their manager telling them to stop wasting time messing with their co-worker.

Having ridden a few of them in the area, I think they're worth it.

Waymos are 100% reliable. If you book it and it says it's coming at X time, it will definitely actually show up at X time. No more of, driver cancelled at the last minute because they don't actually want to drive to destination Y but Uber etc gave it to them anyways and they get dinged if they just cancel instead of claiming not to be able to find the rider etc. Or driver got lost or stopped for food or gas or something so is late.

It also gets to the destination exactly when it says it will. No weird routes because of the driver's whim or driving too fast or too slow. And no chance of bad music, loud conversation in some foreign language, annoying commentary, etc.

And I want them to be profitable to run too, so they have plenty of incentive to expand the program.

I've come to think that adding halfway-typing to languages designed from the start to be dynamic is mostly not worth the bother. It may help a little bit sometimes, but there's always going to be holes. If you really want strong typing, it's better IMO to bite the bullet and move to a language designed for it. Let Ruby be Ruby, ditto Python, Javascript etc. Pick up some JVM, .NET, Rust, Go, etc if you really want strong types.

It sounds like the kind of job you really want is going to be a bit of a unicorn. That means those kinds of jobs don't get advertised in job boards and have professional recruiters running around looking for candidates that fit. That in turn means that finding such a job is going to be a lot of networking and shoeleather. You'll probably have to go to a bunch of conferences, talk to people, and make contacts, and hope you can discover a place where your unique skills are a greater value to somebody's project than anyone with expertise in only one of those fields could be.

In addition to the other sibling comments, I think there's also a factor of greatly increased computing power. Back in the 90s and earlier, we just didn't have the computing power generally to encrypt everything with super-strong algorithms in realtime. This probably also affects who can practically do development work on state-of-the-art algorithms.

I recall, when it was originally created, SSL was a rarity, a thing only for the your bank account and the payment page for online stores, because nobody could afford the CPU load to encrypt everything all the time. Now, it's no big deal to put streaming video behind TLS just to ensure your ISP can't mess with it.

This isn't about things that happened decades or centuries ago though. It's about how right now, today, the UK is arresting 12,000 people a year, 30 a day, for supposedly "offensive" posts on social media.

https://freespeechunion.org/police-make-30-arrests-a-day-for...

Thanks! This is a much better link than the OP, and better preempts the usual round of "why not my other pet language X instead"? questions. Clearly this choice and strategy has been in the works for a long time and the team has carefully thought out all options.

> Ban all advertisements. (I'm all for it, at this point.)

What would that actually look like though?

Take something that could be considered an ad, but probably most people agree is a good thing. Say you post on here that task X is such a pain in the butt to do all the time as a general gripe, then I say hey, I built a cheap subscription webapp to solve task X easily that you might want to check out. You sign up for it and use it and like it. Seems like everybody wins - you get a problem solved for a small amount of money, I make a little money and get my project used and my work validated etc. But it's still technically an ad.

Lots of stuff like that could be considered an ad. Every "Show HN" could be considered an ad. Suggesting people vote for candidate X or party Y could be considered an ad too - plenty of organizations do pay for actual ads just like that already. Product placements is a type of ad, but it's pretty hard to not do. I don't know how you even make a movie or TV show with people driving cars without showing a particular model of car.

I don't expect that's the kind of ad that everybody is complaining about. Okay, but then how do you legislate the difference? Can you, or anyone, actually write down a definition of the ads you want to ban and the ads you don't? And how will people distort or abuse those definitions? There's billions of dollars in advertising (maybe trillions?), it's not going to all just go away because somebody passed a law. What happens when all of that money gets poured into attempting to abuse such individual personal recommendations? That's already happening on Reddit now, though at small scales for now.

You don't necessarily have to if you're just getting a speeding ticket. But in order to write a speeding ticket, you have to hand over a valid Driver's License so they know who to ticket. Exactly what should they do if the driver refuses to provide their Driver's License?

I don't think this makes a lot of sense because, if the password is quick and easy to type, it can probably be cracked by any such device in the time it takes for a single keystroke. A long and complex password might hold up okay, but for it to actually be secure, you would have to type in the whole password on a phone keyboard every single time you opened the app, which sounds like a terrible experience.

I think, if you were actually willing to do that, it would probably be about as convenient and at least as effective to leave the device powered off and rely on the device full disk encryption and hardware security to protect the data at rest, only powering it on occasionally to check or send messages, then immediately powering back off.

Exactly what "rolling over" would that be?

Maybe you don't believe Durov's statement[0] about it. But is there any actual evidence anywhere that they've ever violated the secrecy of non-e2e private groups or messages for anyone? I've yet to find any.

[0] https://t.me/durov/342

Speaking of, maybe I started paying attention at the wrong time, but I could swear I've seen like 10x more post/comment volume whining about how annoying the "Rust evangelism strike force" supposedly is than actual excessive Rust evangelism

Reminds me of the Oceangate disaster as proof that things at least that dumb can happen in real live involving substantial amounts of money. Including everyone who is actually an expert in the field telling them that this is idiotic and usually quitting.

Where's the meme of the guy who gets hired on to a tech company, fixes one bug that always annoyed them, then quits immediately

"Pro-war" seems like an odd assertion here. They're recognizing the status quo in a reasonably neutral way, which seems anti-war to me.

It seems like you're advocating for Western powers to take a position, using either soft or hard power, on a war that already ended many decades ago. Sounds quite a bit like imperialism to me, and pretty far from being anti-war.

An anti-war position, at least from the perspective of a Westerner and Western companies, is more like, you guys lost, suck it up and stop asking us to intervene on your behalf.

I don't particularly like this article, mostly because he seems to have spent the great majority of it ranting about people on the internet supposedly yelling at him about not being "on the cloud" and semantics about exactly what constitutes "the cloud". I'd be much more interested in reading exactly what he was spending that money on at AWS and how he moved it all onto one or a few bare-metal boxes.

I don't think AWS is particularly expensive at all. In fact, it's rather cheap at quite a few things if you know what you're doing and use the right services. I've got all my server backups going to S3, for which I pay a whopping penny a month. I also host a handful of Docker images on ECR for 7 cents a month - way cheaper than any other private hosting service I know of.

Now RDS, and the equivalent at every other hosting provider I know of, gets quite pricey indeed. IMO, you shouldn't bother unless you have pretty serious needs for reliability and speed. Apt install your DB server of choice on bare metal goes quite far. Or possibly pull a container of it into whatever you're using to manage containers.

Actually I think I might be a little misguided here - confusing a mutex with an awaitable lock method versus blocking, and a mutex whose LockGuard is Send and can be held across other await points.

To clarify, I do still think it's probably wise to prefer using a mutex whose LockGuard is not Send. If you're in an async context though, it seems clearly preferable to use a mutex that lets you await on lock instead of possibly blocking. Looks like that's what that Safina gives you.

It does bring to mind the point though - does it really make sense to call all of these things Mutexes? Most Mutexes, including the one in std, seem relatively simplistic, with no provision for exactly what happens if multiple threads/tasks are waiting to acquire the lock. As if they're designed for the case of, it's probably rare to never for multiple threads to actually need this thing at once, but we have to guard against it just to be certain. The case of this resource is in high demand by a bunch of threads, we expect there to be a lot of time spent by a lot of threads waiting to get the lock, so it's actually important which lock requesters actually get the lock in what order, seems different enough that it maybe ought to have a different name and more flexibility and selection as to what algorithm is being used to control the lock order.

Considering this issue did also make me think - maybe the real footgun here is the async mutex. I think a better "rule" to avoid this issue might be something like, don't just use the tokio async mutex by default just because it's there and you're in an async function; instead default to a sync mutex that errors when held across awaits and think very hard about what you're really doing before you switch to the async one.

Assuming this quote from the article is true, it sounds like the only villain here is the school principal:

> It said the AI alert was sent to human reviewers who found no threat - but the principal missed this and contacted the school's safety team, who ultimately called the police.

So the company AI reviewers correctly determined that there was no actual gun, and the police responded appropriately to a report by a person (the school principal) who claimed to have seen this student with a gun. The question then is what the heck is this principal doing? Why do they have access to this pre-verified AI information, and why are they going off and calling the police with this information before doing any verification themselves?

Well also, none of the coverage includes what was said to the dispatcher, but maybe they screwed up too - I would expect a dispatcher to question the caller in more detail about what's going on. Like, what kind of gun was it, is it in their hand or in a pocket or what, did they point it at anyone or threaten anyone with it or are they just carrying it around, etc, and such information could be used for a more appropriate police response.