dathery

Windows 7 is older today (15 years) than Windows 95 was when Windows 7 was released (14 years).

I've usually seen it come up when people try to hash the objects to use as dictionary keys or in sets, and then encounter very hard-to-troubleshoot issues later on. Obviously it's a bit weird to hash a bunch of objects of different types, but it's just one example of the footguns that namedtuples have and why I prefer other approaches.

Another problem brought about by their design being backwards-compatible with tuples is that you get wonky equality rules where two namedtuples of different types and with differently-named attributes can compare as equal:

    >>> Foo = namedtuple("Foo", ["bar"])
    >>> Baz = namedtuple("Baz", ["qux"])
    >>> Foo(bar="hello") == Baz(qux="hello")
    True

This also happens with the "new-style" namedtuples (typing.NamedTuple).

I like the convenience of namedtuples but I agree with the author: there are enough footguns to prefer other approaches.

How does lack of understanding of the mechanism by which something works imply that it is useless at best? I do not think that follows and can think of many counterexamples.

I hate to run PR for Uber, but the battery story is just urban legend. If you dig into the headlines, they all trace back to one article written by a small Belgian newspaper [1] which is barely more than a blurb. The evidence in the article is one very casual experiment:

> Dernière Heure conducted a test using two smartphones, one with 84% battery and the other with 12%, to request a ride from their office in Brussels to Tour & Taxis in the centre.

> The result showed a significant price difference, with the phone at 12% battery being charged €17.56 and the phone at 84% battery being charged €16.6 for the same service.

Uber also denies it in the article. Obviously you don't have to believe them but IMO it's more likely that the "significant price difference" (less than one euro) is explained by some other variable that the author wasn't able to identify.

[1] https://www.brusselstimes.com/449143/uber-fares-allegedly-li...

That makes sense. I was thinking they could use something like DTLS [1] and tunnel just the one UDP port needed for their VXLAN connections, rather than use full-blown VPN software. I have never actually tried this myself though.

[1] https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Secur...

Is there reason to think AES used appropriately would be any less secure here? Not trying to be argumentative, genuinely curious.

My understanding is that AES has some design warts that make it not ideal (basically, it's easy to both implement and use in ways that leak information if you're not careful) but that it's still essentially perfect symmetric encryption if you're using it as recommended. Is that wrong?

FWIW, the reason I brought up performance was because the OP spends a large chunk of the post talking about it, so I assume it's an important requirement for them.

Really cool article, I enjoy reading through all the details behind the decision making.

Just spit-balling a little, but I wonder if Wireguard is the best tool here given that the author is only using it for a single point-to-point link and they control the devices on both ends. That CPU supports AES-NI and probably does it a lot faster than Wireguard's ChaCha20 (hard to get numbers for their server CPU, but the tiny little x86 mini PC I use as my router does AES XTS at 43Gbps according to `cryptsetup benchmark`).

You might see better performance by tunneling the vxlan connection using a different technology which can use AES-NI? Then again, Wireguard is definitely still a good tool for stuff like this, and maybe the performance penalty isn't a big deal here.

Right, but I was trying to understand the author's motivation, and this was me handwaving about if it could be about compiler trust. The article discusses bootstrapping but not explicitly why the author cares—is it just a fun exercise (they do mention fascination)? Are they using an obscure architecture where there is no OCaml compiler and so they need the short bootstrap chain? _Is_ it about compiler trust?

(Again since it can come off wrong in text, this was just pure curiosity about the project, not dismissiveness.)

Not dismissing the usefulness of the project at all, but curious what the concrete benefits of that are -- is it mainly to have a smaller, more auditable bootstrap process to make it easier to avoid "Reflections on Trusting Trust"-type attacks?

It seems like you'd need to trust a C compiler anyway, but I guess the idea is that there are a lot of small C compiler designs that are fairly easy to port?

Not a traditional streaming service, but Plex offers sonic analysis: https://support.plex.tv/articles/sonic-analysis-music/

> Plex Media Server uses a sophisticated neural network to analyze each track in the music library, cataloging a wide variety of characteristics of the track. Think of it as things like female vs male, vocals vs not, sad, happy, rock, rap, etc. All these various characteristic constitute a “Musical Universe” and the server is determining where that particular track exists within it.

> For the math-savvy, the Musical Universe consists of points in N-dimensional space. But what’s important is that this allows us to see how “close” anything in your library is from anything else, where distance is based on a large number of sonic elements in the audio.

I haven't tried it so can't speak to its effectiveness.

It would be hard to do end-to-end TLS (where the server proxies the raw connection) because

(a) you can't share one TLS connection to the host between multiple clients; if you wanted multi-client support while preserving end-to-end TLS, the host would need to maintain a TLS connection with each client and waste bandwidth re-uploading the same image

(b) there is no client software requirement, so you would have to do the TLS decryption clientside in the browser (maybe via WASM) unless you're OK with having viewers download software

The bacteria behind botulism can't grow in oxygen-rich environments, so I think the makeup of the solution is the main thing to worry about. That's why botulism is mainly a concern with canning, oil suspensions, etc.

You can use a pH meter to monitor the sauce while it's fermenting if you'd like some extra assurance. Hot sauce is one of the safer things to do at home (in terms of things like botulism risk) due to the acidity and saltiness.

You can have Caddy return the user's IP address directly: https://caddy.community/t/caddy-server-that-returns-only-ip-...

Similar things are also possible with nginx and Apache.

I could see this happening. Zoom for example already uses ultrasonic sound to detect what conference room a laptop is in for one-click screen sharing.

I'm very interested to see what that kind of competition would do to ticket prices. I've often seen Ticketmaster painted as the "designated fall-guy" for consumers to hate instead of the venues and acts which are (according to this argument) the source of a lot of the junk fees. This is also the position that Ticketmaster claims as a defense [1], so it's hard to know what to believe in the absence of competition.

[1] https://www.cnn.com/business/live-news/ticketmaster-taylor-s...

Here's a similar project with a PlayStation 1 if people like this kind of thing: https://bitbuilt.net/forums/index.php?threads/ps-hanami.6279...

It also creates a bad safety culture to over-punish mistakes, because then people don't report them for fear of being fired and the system can't be improved to minimize future mistakes.

My experience has been that it's really easy to damage your USB-C port like this if you keep your phone in your pocket while walking/running. I always end up with the port loose and making poor connections.

I ended up buying a small battery-powered Bluetooth-to-3.5mm receiver that I keep in my left pocket, and then send Bluetooth audio to it from my phone in my right pocket. It's a pretty ridiculous setup.

Previously people basically didn't bother to write multithreaded Python at all due to the GIL. Threads were primarily used when you had multiple pieces of work to do which could end up blocked on independent I/O. Which is common and useful of course, but doesn't help with the performance of CPU-bound Python code.

Even outside of high-intensity CPU work, this can be useful. A problem lately is that a lot of code is written using Python's native asyncio language features. These run single-threaded with async/await to yield execution, much like in NodeJS, and can achieve pretty good throughput even with a single thread (thousands of reqs/second).

However, a big problem is that any time you do _any_ CPU work, you block all other coroutines, which causes all kinds of obscure issues and ruins your reqs/second. For example, you might see random IO timeouts in one coroutine which are actually caused by a totally different coroutine hogging the CPU for a bit. It can be very hard to get observability into why this is happening. asyncio provides a `asyncio.to_thread()` function [1] which can help to take blocking work off the main thread, but because of the GIL it doesn't truly allow the CPU-bound to avoid interfering with other coroutines.

[1] https://docs.python.org/3/library/asyncio-task.html#asyncio....

Yes, which is why it's not ideal to reuse the folder metaphor here. Users have an idea how directories work on well-known filesystems and get confused when these fake folders don't behave the same way.

Directories actually exist on the filesystem, which is why you have to create them before use and they can exist and be empty. They don't exist in S3 and neither of those properties do, either. Similarly, common filesystem operations on directories (like efficiently renaming them, and thus the files under them) are not possible in S3.

Of course it can still be useful to group objects in the S3 UI, but it would probably be better to use some kind of prefix-centric UI rather than reusing the folder metaphor when it doesn't match the paradigm people are used to.

By this logic isn't it still better to make whatever profit they can by releasing it? Yes they would increase their net income (and thus tax burden), but they should still end up ahead (it's not like they're paying >100% marginal tax rate on those dollars). It must be more complicated somehow, right?

Could you identify the strawman attacks you see? I'm trying to interpret your comment charitably but I'm having trouble identifying what you object to specifically.

I don't think it's much of a stretch to assume these kind of laws will be used to censor topics like "race, gender, and sexuality". There is a ton of precedent in recent years of e.g. books on these topics being banned from public libraries (not just school libraries) under the guise of protecting children. It seems like a reasonable inference that the same topics would be targeted in online content if the laws allowed it.

You don't need active coordination for this. APs serving the same SSID could verify client certificates issued from any other AP by verifying that the certificate is signed by a trusted certificate authority. You'd just need each AP to use the same CA to issue signatures from.

You could give each AP its own intermediate CA tracing back to the same root CA to avoid sharing private keys and allow easily revoking certificates signed by a compromised AP.

You would only need coordination for revoking client certificates (but you can't really avoid that regardless of model).

They're talking about transformative with regard to copyright law where it is an important part of determining fair use, not the dictionary definition you're using here.

I can't take NY Times articles, translate them into Spanish, and then sell the translations under fair use, even though clearly I've transformed the original article content.

I get why Chrome has to prioritize the things it does, but this kind of reasoning feels so backwards to me.

I'm sorry that blocking cross-site tracking makes it harder for ad companies to make money, but that's just not my concern. My browser is supposed to act in _my_ interests. It's the _user_ agent, after all. I'm not going to give any sympathy to the company that built the internet into the ad-supported hellscape that it is when they now use their browser monopoly to try to protect their business model.

I don't think this is meaningfully true for modern phones. The passcode is used by the phone's TPM to derive the actual encryption key, which never leaves the TPM. TPMs are designed to be impossible to retrieve the secret key from without being physically destroyed to prevent the kind of attack you describe.

This is why phone cracking devices like Cellebrite rely on exploits in phones rather than just cloning the disk and trying the small number of possible passcodes.