ufmace

I don't really agree with this. I'd phrase it more as, you have to learn to really understand what the borrow checker is trying to do and how it makes you architect your programs and consider that ahead of time. Once you understand that, you'll rarely have problems with the borrow checker. It does preclude significant chunks of styles and data structures often used in other languages though.

The article here is basically PR from the Tor project. I suspect most reader here would find this relatively high-level technical analysis of the attack more interesting:

https://delroth.net/posts/spoofed-mass-scan-abuse/

Why doesn't this apply both ways? Red voters in Blue states are just as likely to stay home because they think their votes won't count. And ditto the other point, Red voters in Red states may not feel like it's worth the bother to vote when they already know their state is going their way.

If you're already using Tor, what's the point of having a VPN too?

I agree. Calling this a "RCE Vulnerability" is ridiculously exaggerated.

What's next, are we going to declare web browsers to have a "RCE Vulnerability" because they allow you to download programs from any site which may or may not be secure and then execute them?

Or, hey everyone, did you know that if you live in an authoritarian state, the Government can do bad things to you?

I feel like all of this is true, but represents the larger background forces. I think a big factor in why it's hitting relatively hard now is the Musk takeover of Twitter - he laid off a ton of engineers, and nothing much happened. I think that was a shock to much of Big Tech that most of their orgs are really feather-bedded with people who aren't actually doing much to support the core business.

The whole design process for them is based around launches being expensive and taking a long time to plan. It will be very interesting to see what happens when the whole process gets used to launches being relatively cheap and frequent. No need to spend years making sure the design is perfect and will definitely last a long time if you can launch a new one in a week if you make a mistake.

I'm not sure what value adding a DeadManService would have then. Probably simpler to just have the attorney's instructions say, "Hire a technical consultant to carry out the following:".

> You seem to never been in that shoe (from a country no one hires from).

Why do you say that? I do have sympathy for people in such countries and circumstances, but this isn't about that. It's about corporate compliance. For better or worse, corporations cannot just do something because it's a nice thing to do. They have to comply with the law in both the country they are based in and operate in, as well as in any country any prospective remote workers might be in.

I also never claimed to have any concrete knowledge. It's entirely possible they are doing everything correctly. I just find it odd that they are reportedly doing something that many companies do not do due to it being legally complex, and also their CEO is spouting off a bunch of unwise statements on public forums while being actively sued, which any sane corporate lawyer would strongly advise them not to do.

This actually makes me really suspicious about Automattic. Companies generally don't refuse to hire outside of certain countries just to be jerks, they do it because complying with international tax obligations while paying employees in dozens of countries is complex and expensive.

Given that, and the behavior we've seen from Matt and Automattic so far, what are the odds that they've actually got a bunch of really great international accountants and are doing everything correctly everywhere, versus they're just ignoring all of the tax laws and winging it, and are therefore at high risk of getting smacked down once the relevant authorities get wind of what's going on there?

That, and the whole thing about Matt M going on a scathing rant about how bad WPEngine supposedly is[0], supposedly because they don't support WP page revision control as well as he'd like. Seems a bit over-the-top and breathless to me.

I figure the whole thing is a corporate whine-fest over who makes more money from actually hosting Wordpress sites.

[0] https://wordpress.org/news/2024/09/wp-engine/

I run my own Wordpress server for a blog, and IMO it's basically fine if you use reasonable deployment management practices and don't install 500 random crap plugins and themes. The basic install is about as bulletproof as it gets in the mainstream web software business.

I don't particularly love PHP, but you don't need to touch it if you don't try to write any plugins. Yes, some of its practices are pretty wacky, like every plugin has full access to the filesystem and database to do basically anything, and the system expects to be able to update code files in place from web requests, but meh, just give it it's own $5 server and let it do its thing, and definitely be very careful which plugins you use and how you get them.

What you get in return for this is a perfectly fine CMS that anyone with basic computer skills can run. Yeah, static site generators are cool and all that from a tech expert's perspective, but nobody who isn't a tech expert can actually do anything with them, and oh, by the way, the ability to make any changes at all typically involves at the very least SSH access to the host server with full write permissions.

Thanks for the perspective. I don't own an EV, but I have taken road trips in a friend's Tesla. My impression was that the supercharger network (at least in the Northeast US) is dense and reliable enough and the route planning software good enough that road trips basically anywhere in the region are reasonably practical, though you'll be spending much more time at superchargers than you would at gas stations in an ICE car and have less ability to choose any route you like. Interesting to know that that's actually the highest level of EV practicality and many other models are substantially worse.

Probably more like you own a large enough percentage of the company and have enough day-to-day control over it that actually trying to sell a significant amount of your stock could trigger other investors to panic, wondering if you have some secret information about how the company is about to fail rather than just wanting to buy another island or mega-yacht today.

IMO it's very understandable to not know about this sort of thing starting out. Everybody was new once, and it's much easier to get motivated to build cool stuff than to read about all the fine details of all of the technologies we're using. I say, go ahead and take the shortcuts and build some cool things in a maybe sloppy way as long as the traffic and stakes aren't too high. Then, once you've got something cool built, take some time every now and then to seek out and read about more of the details of some of the systems and tools you're using.

I've never actually set up CVS myself, so I suppose I can't accurately say how easy or not easy it is. The "nobody" might deserve an asterisk - I'm sure it's not literally not a single person, but it seems to be pretty rare in my impression. Nevertheless, AFAIK, the non-distributed nature seems pretty limiting.

In Git, I can just create a local repo for anything, and I don't have to decide where I want it. I could never push it anywhere, or push it to a private hosted repo to collaborate with a person or team, or push it to a public repo to open-source it, and change between any of those at any time. I don't think you can really do that with these hosted systems. You could spin up a local CVS server if you really wanted to, but if you later decided you wanted to open-source it on Sourceforge, don't you have to abandon the history and publish it there as-is?

A quick check on the contributors page shows ~8ish heavy contributors working over the course of 6 years and 13k commits. That's a good thing to check for any project you're thinking about integrating with IMO.

That said, my experience has been that adding business features in Rust apps is quite fast indeed!

I think a lot of people who've only learned programming in the last 10 years or so don't realize that Git, and even more so the large-scale popularity of Git, is actually pretty new. A lot of programming happened before Git was created, and before it became mature and popular enough to be the default for everyone.

Many of these earlier systems sound terrible and hacky to us, but they were the best that was available at the time. Systems to "lock" files you were working on were pretty common because basically nobody did merges well. Most of them were based on having a server to manage the whole thing too, so they were only really common in corporations and larger and more mature hobbyist teams - this was also before you could spin up a cloud server for most things with a few keystrokes and $5 a month. It's low-effort to spin up a local Git repo to track your work on a tiny personal project, but nobody's going to set up a CVS server for that.

Anybody remember Joel On Software's 12 Steps [0], written in the year 2000, 5 years before the Git project was started? Where "use source control" is Step 1? There's a reason why that's there - at the time it was written, source control was clunky and a pain in the ass to set up, so a lot of smaller companies or ones with less mature development teams never got around to it.

I may be getting a little "old man yells at clouds" here, but be really thankful that Git is FOSS, ubiquitous, works great for 98% of projects, and is superlatively awesome compared to everything that came before it.

[0] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

The way this stuff seems to work, it doesn't make sense to go theory-first. We can spin up a bazillion theories about it, with no clue which if any are anywhere near true. We've got to just try it, gather experimental data, and see if we can build any more solidly-backed theories around that data.

Yup, that sounds about right.

I'd also note that one of the reasons I prefer doing such things in person is (in addition to not taking up too much of the candidate's free time) that if they misinterpreted something or are going off in the wrong direction or something, I can correct them right away instead of letting them waste a bunch of time. This also lets you see how they tend to interpret instructions and take criticism and corrections.

It's also IMO a failure mode for a candidate to get a simple task that should be done in 5-20 lines of simple code and try to build some over-complex super-modular and extensible thing for it, and resisting correction on it not needing to be that over-engineered.

We have a hour total per interviewer. The basic FizzBuzz is intentionally incredibly simple, no reason anyone qualified to be a full time software engineer should take more than 10 minutes to build it in a pre-set-up environment in their language of choice.

Yup, I've developed a workflow that starts with writing a brain-dead easy fizzbuzz and gradually adds features and complexity. The way I've done it, it gives you a way to judge levels as well as basic competency.

If you can't, or can just barely, complete fizzbuzz in the allowed interview time with a lot of coaching in your language of choice, then you definitely aren't ready to work as a SWE. If you breeze through all my extra sections in half the time, then you're great. Partway through, and you're probably a decent junior to senior engineer.

It's pretty much the definition of a functional state that the police can gather more resources faster than any group of criminals. By the time you gather enough criminals to hold off the police for even a few minutes, most of the time, combined with the sibling's point of not that much physical money being stored at banks, there's not much money to go around to that many people.

It's a good video, but I think some people may miss the point.

You SHOULD be working with a good lawyer ahead of time. You should NOT be regularly suing your clients. Actually suing is expensive, time-consuming, and painful.

You should have a solid, enforceable contract set up ahead of time that you require new clients to sign, and get your lawyer involved if they want to change anything. The contract should ensure that you are within your rights to stop work and take away things they want if they aren't paying on time. If you do it right, you have a smooth and easy escalation path for non-payment, they're the ones who find themselves in a bad situation and have the option of either trying to sue you or just pay you the originally-agreed-upon amount.

I'm not a lawyer or your lawyer and don't even know what jurisdiction anyone is in, so don't do anything without consulting one. But the idea is something like, you only transfer control of servers and services to the customer upon being paid in full, no exceptions, and if they are behind on payment by some particular time and amount, you are explicitly within your rights to shut down services or block their access until such time as their account is paid up.

It's interesting how a good contract is kind of like a good program. The happy case is only like 20% of the work, the other 80% of the code or contract is all about detailing every possible way the happy case could go wrong and exactly what happens when each particular way of going wrong happens.

In a perfect world, studies should not only be required to include the code, any of the following should also be a reason to reject a publication:

* The code can't be run outside the original researcher's undocumented special snowflake system

* A fellow scientist who understands the domain can't understand what the code is doing and so is unable to verify that it isn't making any mistakes

* It'd be really nice if there were some sort of test cases that could verify that the code in question produced results in line with what the scope of the paper in question considers to be established science in that domain before it was applied to the experimental data - probably not always possible, but it'd be good to at least try

Yeah I know this doesn't touch the dozens of other reasons the whole institution is in trouble, and for those reasons usually nobody who has the skill and time to properly review the code actually reviews it carefully. For that matter, most scientists aren't very good at writing code that's easy to understand and will run everywhere. Just one more set of things that ought to go on the list of things that really should be changed.

Well yeah. But:

1. That's exactly why I prefer a plain old analog mattress that needs zero tech or support from anyone ever

2. Even with that being the case, for the average consumer who wants an electronic/controllable bed, it's still a better deal than anything that requires a custom home automation setup. Check out the prices for hiring somebody who can actually troubleshoot that.

I think this goes right back to the parent's point.

I presume you personally could set that up. I probably could too. But 99% of the world isn't tech experts and can't do that. Or fix it if something goes wrong. Even if you can, you might just want to go to bed and not have to debug a broken assistant integration first.

The benefit of cloud integration, for that 99%, is that there is a professional out there to keep it working.

That probably is the better way to see it at this point. There's already enough bad actors out there that it's not really worth keeping track.

I'd be willing to bet that they have comprehensively sloppy and terrible infosec practices and that we'll never hear any details about it - most of their customers wouldn't understand, and it would only expose how bad they are at all of this if they did.

This, I find passkeys very difficult to understand.

It seems I can use my phone as my "passkey". Okay nice, that should mean I can use the same one on multiple devices, just like with a hardware Yubikey, right? Well apparently no. Use a phone as a passkey on one device for a web account, try to log into the same account on another device, using the phone passkey, and it doesn't work, claims there is no passkey. I can't see what passkeys are actually present on the phone, so I don't know what's wrong.

There's so many different ways to have and use passkeys, and no way to tell what the status is. I have no idea how the less-technical users are supposed to be able to figure this stuff out.

AFAIK it's not at all clear that solar and wind are really cheaper when making up a substantial part of a large-scale power grid that meets our current expectations of 100% consistent and reliable power everywhere, no matter what.

The unreliability of solar and wind requires either hot (constantly running and spinning) non-renewable backups or grid-scale power storage (has never been done so ? on cost to build and upkeep) to guarantee reliable voltage and AC frequency. The cost of that should be factored into determine the true cost of these power sources.

The stability of the grid is dependent on the collective physical inertia of the many tens of thousands of huge and heavy spinning turbine-generator sets that make up the majority of the current generating capacity. Most current solar power sources rely on grid-following inverters, which are not stable without a grid stabilized by a preponderance of large spinning turbines. There has been some work on grid-forming inverters that are less impacted by this, but AFAIK there aren't currently any that can replicate the grid stability provided by that physical inertia.

I'm less certain about wind turbines, but I think they have this problem too. I don't think they're controllable enough to be mechanically synced to the grid frequency.

I'd love to be wrong about this, please prove me so if you can! But I don't often hear these points addressed, and we're not helping anything by ignoring the complexity of the real world.