I have no clue if I'm aphantasic (I genuinely have trouble feeling like anyone describes anything resembling my experience in conversations like this), but I had many years of lucid dreaming from being prescribed medication for my insomnia as a kid. It started out being pretty much every night, and then slowly became less frequent until nowadays it's maybe once every month or so.
By killing Google Reader they essentially killed RSS. Yes, I know there are other clients some of us still use, but Google's was the biggest and most popular.
"Be careful with mutexes" is good advice, but I'm surprised it doesn't explicitly call out the various channels that tokio provides as alternatives (detailed here: https://docs.rs/tokio/latest/tokio/sync/index.html). There are a variety of options that fit different use cases, and you don't even need to enable the runtime feature to use them (e.g. if you want to do a single check for completion rather than await). I'd estimate that at least half of the bottlenecks I've seen with mutexes when using tokio could have been avoided by not even using a mutex at all and instead passing the data that's truly needed across different tasks with some type of channel.
The other trick I've used a few times that's a bit hacky but can get the job done is when reading a snapshot of the data under a mutex is enough without needing to prevent other changes; if that's the case, you can just clone the data and drop the mutex to allow other uses move forward at the cost of the data potentially being stale.
Tasks and channels is the way. You can get something that feels like programming a real preemptive concurrency model like BEAM languages or golang but with minimal overhead.
When you send a message in Erlang, nothing the recipient does with the message impacts anything on the sender side. That's good!
In principle, they could have used something like copy-on-write for this, but in practice they really just make a copy of the bytes.
Alas in Go, when you mutate what you received on a channel, you mutate the object the sender might still be holding. That's pretty annoying. It gets worse, because Golang has no way to declare something as `const` (like in C) nor that you are holding an immutable borrow (like in Rust). So you need to rely on conventions and perhaps a linter.
Slighty less of a tangent: task and channels and software transactional memory (STM) are all great. I see mutexes as more of an implementation detail that you can use to implement these higher level abstractions (but they aren't the only way).
Awesome! I was pretty confident you already were aware of both of those based on the level of knowledge needed for everything else in there, so I mostly was mentioning them here in case some people here might find them useful. Adding them in for others is even better though!
Semaphores are more general for sure. The common semaphore is just a counter, when you lock it you decrement the counter by one atomically. Therefore a mutex is just a semaphore with a limit of 1. I wouldn't say they're much trickier to get right, maybe just less frequently applicable in e.g. general web io tasks.
If this consistently has happened at every place you've worked in your career, I think you're luckier than you realize. Independent of the implementation, it's also still interesting as a sign of what might be supported for users down the line; I don't agree that this is how they'd write the code if they never expected to allow another provider, and other comments in the thread have already provided some insight into what the context might be (e.g. EU market).
Apple had enough experience relying on and being screwed by third parties that they have a built-in allergy to it. They do not like being boxed in and always want to be in control of their destiny.
This would’ve been useful during their bake off where they were trying to choose if they wanted to go with Google, Anthropic, or OpenAI. But even without that, they would absolutely not want to be in a situation where they had to redo everything to get off a bad partner.
They are currently getting rid of Qualcomm modems the new fold iPhone is using an Apple in house modem (C2) and due to market conditions Apple will probably have to do something with memory because of the three head cartel and the Chinese.
Apple has a long and contentious relationship with Qualcomm, and Qualcomm is big enough and important enough Apple couldn’t bully them into doing what they want.
I think it makes a lot of sense for Apple to control their own destiny there. It’s let them focus on the things they care about like power efficiency and tighter integration.
DRAM is a complete commodity. I don’t think making their own makes any sense. They don’t make their own screws. Although the reaction from iFixit would be hilarious. If Apple makes their own DRAM I don’t see how it would be any different from what SK Hynix sells.
The useful thing would be fabbing it since that’s the bottleneck. But that commits them to the insanity of running their own fabs and keeping them up-to-date and on the bleeding edge forever.
And even if they want to do that, they’d have to buy all the experienced people, the ASML machines that I assume are spoken for for the next few years, etc.
You're now confident that the other 399+ domains you mentioned are not under any sort of duress because they're controlled by people who are away of what's happening?
I feel confident that no system exposed to the internet should have a problem with 50,000 requests per month! If they do, they probably shouldn't run a public NTP server, or have a public IP address at all.
Okay, so you're just confident in exactly how many requests everyone else in the world will be making if you try to pentest resources unbeknownst to their owners.
Are you confident you are not viewing too many pages on HN? What if many other people are also trying to read this thread?
I think this line of reasoning doesn't make any sense. The internet is not an inherently safe network regardless of what we wish for; we can't wish away the bad activity, and it's only going to increase. The activity that helps prevent the bad activity from working is a net positive.
> Are you confident you are not viewing too many pages on HN? What if many other people are also trying to read this thread?
I think it's pretty disingenuous to compare viewing a couple of pages once a day with running scripting tools against over 400 websites.
> I think this line of reasoning doesn't make any sense. The internet is not an inherently safe network regardless of what we wish for; we can't wish away the bad activity, and it's only going to increase. The activity that helps prevent the bad activity from working is a net positive.
Oh good, no one has ever claimed "it's for your own good" when doing something selfish without consent.
We can quantify the impact of the scripting tools pretty easily - 1.5k requests per day! I just went on Reddit and viewed a few posts, and it caused about 500 HTTP requests in DevTools. Luckily HN is not that bloated, but I just don't see the number of requests as meaningful even if it was orders of magnitude higher.
As the OP said, they don't do anything when the server isn't vulnerable, and serving a 404 page is incredibly cheap.
Apparently they didn't just do that, they also had them make requests way more frequently than they needed to (I guess particularly surprising given that they'd already have to be fairly negligent to have the server hard-coded):
> We learned that these packets appeared to be legitimate, well-formed Simple Network Time Protocol (SNTP) version 1 queries, albeit at an inexplicably high rate from each client host. For instance, during one trace, many clients produced about one query per second. This would be highly unusual for a properly constructed SNTP client, since an application which uses SNTP is merely interested in setting its own clock relatively accurately so that its host has some reasonable notion of the current time. One query per second is ridiculous, and is far from best practice for NTP client behavior.
I'm kind of surprised to hear that was a concern because my perception is that PyO3 is more analogous to wrapping native C code in Python libraries (which is pretty well established since long before either Rust or WASM), and Pyodide seems more like something for use in browsers rather on the server-side. When I looked into this earlier this year, trying to run Python via WASM on the server side with Pyodide had a bunch of hoops I needed to jump through, and it ended up being a lot simpler to use a build of Python from one of the core Python contributors that directly targeted WASM.
reply