Hey - I wonder if you might be able to elaborate on this? I'm on gnome and have had by and large a pleasant experience, and now I'm curious what I might be missing out on. What made it feel like a horrible OOBE for you?
Not exactly what you're asking, but multiple CVEs have been found in Intel's Management Engine (ME) which have been used in spyware.
It might not be an intentional backdoor, but it very much seems designed with out-of-band access in mind, with the AMT remote management features and the fact that the network controller has DMA (this enables packet interception).
Bit of an aside, but I'm wondering in what city this was in.
I'm going to be job hunting soon and I was planning to prioritize the Bay Area because that's the only place I've encountered a decent density of people like this, but maybe I'm setting my sights too short.
I’ve been afraid to switch from GNOME to KDE because of what I’ve heard about instability on Wayland as well as Qt being more unstable than GTK.
Are these concerns overstated? Should I bite the bullet and switch?
I’m on Debian but considering switching to Fedora.
Author here: using KDE6 with Wayland. Didn't note any instability, and it was the only desktop environment that I saw to handle HiDPI for X11 applications (except for Hyrpland, but this was clearly using a hack).
KDE is more stable than GNOME, because gnome-shell kills all apps when it dies due to GPU driver bugs or whatever. Qt/KDE has some more crash resilience going on. Not as good as Arcan, but I've never had my session go away since recent KDE6 versions.
Could someone explain just what's so bad about this?
My best guess is that it adds complexity and makes code harder to read in a goto-style way where you can't reason locally about local things, but it feels like the author has a much more negative view ("crimes", "god no", "dark beating heart", the elmo gif).
Maybe I have too much of a "strongly typed language" view here, but I understood the utility of isinstance() as verifying that an object is, well, an instance of that class - so that subsequent code can safely interact with that object, call class-specific methods, rely on class-specific invariants, etc.
This also makes life directly easier for me as a programmer, because I know in what code files I have to look to understand the behavior of that object.
Even linters use it to that purpose, e.g. resolving call sites by looking at the last isinstance() statement to determine the type.
__subclasshook__ puts this at risk by letting a class lie about its instances.
A linter would pass this code without warnings, because it assumes that the if block is only entered if x is in fact an instance of Everything and therefore has the foo() method.
But what really happens is that the block is entered for any kind of object, and objects that don't happen to have a foo() method will throw an exception.
You _can_ write pathological code like the Everything example, but I can see this feature being helpful if used responsibly.
It essentially allows the user to check if a class implements an interface, without explicitly inheriting ABC or Protocol. It’s up to the user to ensure the body of the case doesn’t reference any methods or attributes not guaranteed by the subclass hook, but that’s not necessarily bad, just less safe.
> It essentially allows the user to check if a class implements an interface, without explicitly inheriting ABC or Protocol.
Protocols don't need to be explicit superclasses for compile time checks, or for runtime checks if they opt-in with @runtime_checkable, but Protocols are also much newer than __subclass_hook__.
I don't think so. I think the other code should just stop using isinstance checks and switch to some custom function. I personally think isinstance checks benefit from having its behavior simpler and less dynamic.
> check if a class implements an interface, without explicitly inheriting ABC or Protocol
This really doesn't sound like a feature that belongs in the language. Go do something custom if you really want it.
But the moment you use a third party library, you cannot use it “responsibly” because that library, too, might use it “responsibly”, and then, you can easily get spooky interaction at a distance, with bugs that are hard or even impossible to fix.
I took the memes as largely for comedic effect, only?
I do think there is a ton of indirection going on in the code that I would not immediately think to look for. As the post stated, could be a good reason for this in some things. But it would be the opposite of aiming for boring code, at that point.
TL;DR having a class that determines if some other class is a subclass of itself based off of arbitrary logic and then using that arbitrary logic to categorize other people's arbitrary classes at runtime is sociopathic.
Some of these examples are similar in effect to what you might do in other languages, where you define an 'interface' and then you check to see if this class follows that interface. For example, you could define an interface DistancePoint which has the fields x and y and a distance() method, and then say "If this object implements this interface, then go ahead and do X".
Other examples, though, are more along the lines of if you implemented an interface but instead of the interface constraints being 'this class has this method' the interface constraints are 'today is Tuesday'. That's an asinine concept, which is what makes this crimes and also hilarious.
You better not find out about Protocols in Python then. The behavior you describe is exactly how duck typing / "structural subtyping" works. Your class will be an instance of Iterable if you implement the right methods having never known the Iterable class exists.
I don't find using __subclasshook__ to implement structural subtyping that you can't express with Protocols/ABCs alone to be that much of a crime. You can do evil with it but I can perform evil with any language feature.
> You better not find out about Protocols in Python then. The behavior you describe is exactly how duck typing / "structural subtyping" works. Your class will be an instance of Iterable if you implement the right methods having never known the Iterable class exists.
Conforming to an interface is a widely accepted concept across many popular languages. __subclasshook__ magic is not. So there is a big difference in violating the principle of least surprise.
That said, I'd be curious to hear a legitimate example of using it to implement "structural subtyping that you can't express with Protocols/ABCs alone".
> That said, I'd be curious to hear a legitimate example of using it to implement "structural subtyping that you can't express with Protocols/ABCs alone".
ABCs with __subclasshook__ have been available since Python 2.6, providing a mechanism to inplement runtime-testable structural subtyping. Protocols and @runtime_checkable, which provide typechecking-time structural subtyping (Protocols) that can also be available at runtime (with @runtime_checkable) were added in Python 3.8, roughly 11 years later.
There may not be much reason to use __subclasshook__ in new code, but there's a pretty good reason it exists.
Interesting, where I’m from in southern california, “try and” doesn’t entail completion. (The article only mentions this for “go and”, which here does indeed entail expected completion.)
Cool article! L4 stuff is always fun to read about :)
Since TCP-in-UDP seems to be involve implementing end-to-end features over UDP, I feel like a comparison to multipath QUIC might be helpful so that we can understand it better.
My impression from reading about HTTP/3 is that QUIC is just kind of better than TCP in performing a lot of end-to-end functions, like recovery, encryption, error correction, duplicate suppression, congestion control, and delivery acknowledgement, and of course multiplexing the connection. (The advantage of TCP seems like its simpler and more mature, but it's honestly not clear to me where TCP wins and I'd be interested in hearing about the situations in which TCP is better than QUIC.)
So if we're addressing middleboxes screwing with MPTCP by tunneling TCP over UDP, isn't this very similar to what multipath QUIC does? The article seems to argue this is a simpler, lower-overhead solution than VPN tunnels, which I agree, that would seem like the wrong tool for the job, but I can't really tell which of multipath QUIC and MPTCP-over-UDP is simpler; they seem really similar to me and I'd appreciate help differentiating them.
When would one prefer MPTCP-over-UDP over multipath QUIC, and vice versa? How do the two differ in functionality, stability, and ease-of-use?
TCP is a protocol with multiple implementations for several core aspects (most importantly congestion control and loss handling), so it's not exactly 1:1 comparable with QUIC, which currently is essentially both a protocol and an implementation.
TCP-in-UDP keeps TCP's battle-tested logic but wraps it to bypass middleboxes—great for legacy systems. QUIC is a clean-slate rewrite, better for new apps. Tradeoff: compatibility vs modern features.
By wrapping TCP in UDP, you essentially lose all benefits of compatibility, though. If neither middleboxes nor your OS are involved, there's not much left to be compatible with.
Here's an equivalent little script for Debian Linux (but should work on most distros), based on classhasclass's comment:
NEW_MAC=$(printf '02:%02x:%02x:%02x:%02x:%02x\n' $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256)))
sudo ip link set wlan0 down
sudo ip link set wlan0 address "$NEW_MAC"
sudo ip link set wlan0 up
You should replace `wlan0` with whatever you see in `ip link show` for your wireless interface, for me it is `wlp0s20f3`. I replaced the `openssl rand` command because it was generating some invalid MACs; this is hopefully only valid ones.
Remarkably, there isn’t a way to solve most integrals symbolically. We say that the set of “elementary functions”, i.e. ordinary looking symbolic functions, is not closed under integration. Even if you try to add special functions in you cannot feasibly make it closed under integration.
I’ll try to write something more detailed later but in the meantime you should look up Liouville’s theorem and non-elementary antiderivatives.
reply