2,007 karma · joined December 12, 2012
Throwing an async mutex to fix the lack of atomicity before yielding is basically telling me that "i don't know when I'm calling await in this code so might as well give up". In my experience this is strongly correlated with the original designer not knowing what they are doing, especially in languages like JavaScript. Even if they did understand the problem, this can introduce difficult-to-debug bugs and deadlocks that would otherwise not appear. You also introduce an event queue scheduling delay which can be substantial depending on how often you're locking and unlocking.
IMO this stuff is best avoided and you should just write your cooperative multi-tasking code properly, but this is does require a bit more advanced knowledge (not that advanced, but maybe for the JS community). I wish TypeScript would help people out here but it doesn't. Calling an async function (or even normal functions) does not invalidate type narrowing done on escaped variables probably for usability reasons, but is actually the wrong thing to do.
I know people mention 1 pixel lines (perfectly horizontal or vertical). Then they go multiply by 1.25 or whatever and go like: oh look 0.25 pixel is a lie therefore fractional scaling is fake (sway documentation mentions this to this day). This doesn't seem like it holds in practice other than from this very niche mental exercise. At sufficiently high resolution, which is the case for the display we are talking about, do you even want 1 pixel lines? It will be barely visible. I have this problem now on Linux. Further, if the line is draggable, the click zones becomes too small as well. You probably want something that is of some physical dimension which will probably take multiple pixels anyways. At that point you probably want some antialiasing that you won't be able to see anyways. Further, single pixel lines don't have to be exactly the color the program prescribed anyway. Most of the perfectly horizontal and vertical lines on my screen are all grey-ish. Having some AA artifacts will change its color slightly but don't think it will have material impact. If this is the case, then super resolution should work pretty well.
Then really what you want is something as follows:
1. Super-resolution scaling for most "desktop" applications.
2. Give the native resolution to some full screen applications (games, video playback), and possibly give the native resolution of a rectangle on screen to applications like video playback. This avoids rendering at a higher resolution then downsampling which can introduce information loss for these applications.
3. Now do this on a per-application basis, instead of per-session basis. No Linux DE implements this. KDE implements per-session which is not flexible enough. You have to do it for each application on launch.
https://github.com/Shopify/ghostferry/blob/main/tlaplus/ghos...
I also was able to find an concrrency bug before a single line of code was written with the TLC which saved a lot of time. It took about 4 weeks to design and verify the system in spec and about 2 weeks to write the initial code version, which mostly survived to this day and reasonably resembles the TLA+ spec. To my knowledge (I no longer work there) the correctness of the system was never violated and it never had any sort of data corruption. Would be a much harder feat without TLA+.
See https://m.youtube.com/watch?v=4DaaafyAUqA and https://m.youtube.com/watch?v=oLsPK2ATJcY. He is a pianist and he bought a novus5 to replace his own upright piano...
So I think protectioism is fine as long as we properly setup an environment that allows for and encourages competition and innovation. However, that doesn't seem to be a path we are used to taking .
Your call out to BYD is a good one, because it is conceivable that even western-made cars will be made non competitive in 10 years and it seems that we are sleeping through the news (or even encouraging it). I hope I'm wrong, but the road ahead is filled with challenge because the direction is fundamentally wrong, and it will take a lot of effort to reverse course, if that is even possible.
Now maybe these companies are likely just mismanaged and the cost of North American engineering is too high? That said, it still seems like there is a structural problem here that very few hybrid software-hardware companies succeed.
If you put a capability in, people will use (and abuse) it.
Granted, I don't fully understand how they intend to holdback, but even if they cache the results of the attestation such that 10 calls in a row fails to attest, they can't cache it infinitely. Website can employ traditional fingerprinting techniques/cookies in combination with attestation to build pretty foolproof systems to not serve the user based on attestation results.
In the context I'm working with (1000Hz hard real-time), the software has to be "performant" (running algorithms like collision detection) in a deterministic manner as each loop iterate has less than 800us of time. When developing such a system, the developer needs to accurately know the performance characteristic of the software ahead of time.
In another system, fast might mean 5ms, which is unacceptably slow in the context above.
The series is mostly complete, except one to two posts on more advanced topics like validation and lockless programming.
My personal killer app would be a significantly revamped plotting library/app. While matplotlib is great, it is fundamentally based on imaged-based plotting. The next generation of data visualization, imo, will likely be interactive. Having an interactive plotting library that allows you to produce publication-quality plots faster and simpler (think of all the time spent aligning text manually..) could be a big deal, but it could also not matter as no one else wants the same things I do.
For large projects with multiple developers, readability should win over writability every time, most code are read more than they are written (my hypothesis). You can see evidence of this, given the success of languages like Python and Go.
That said, for scientific compute, in a lot of cases, writability matters way more, as your job as a scientist is to produce results as fast as possible, code quality be damned. However, only a small number of scientists are expert developers and have climb the learning curve and can write code with ease. The vast majority of them are junior at best, and Python's approachability (which is rooted from its readability of course), wins. With most of the people using Python, the ecosystem develops and there are no other viable alternatives. In the long run, I suspect even languages like MATLAB and Mathematica will die out as the open source stack becomes more mature and (eventually, if not already) significantly more capable. Julia might be a wildcard due to its (potential) performance advantages, but the aesthetics of the programming language is simply not in the minds of 99% of the scientific compute users out there.
I suspect the main reasons are:
1. Python's guiding philosophy of "There should be one-- and preferably only one --obvious way to do it". With later additions to the language, this is getting less true (3 different ways to format strings, asyncio, type hinting, etc). Some libraries also don't conform to this (matplotlib). That said, it's a lot better than the Ruby code I've encountered, which is like the wild west.
2. Python's syntax is reasonably simple to teach. The object model could be condensed into something very simple if you don't need a lot. With very basic knowledge, you can go a long way. Ruby's a bit more chaotic with things like inheritance, extend, and include; proc, block, lambda; having to use attr_accessor; syntax things like a = b could be a function call or not; if/unless; and many more things that are confusing.
3. Even basic things like loops in Ruby is not idiomatic as it wants to apply a function/block instead. Beginners, especially those with a bit of background, like their loops better than functional programming.
As I've spent many years working on Ruby code base I still get lost all the time. Python in my experience has been a lot better, although recent Python versions have regressed a bit as it introduced more syntax to do the same things.
While on that thought experiment, perhaps in general if you can use BPF/USDT to help trace/debug RT programs? I'm thinking of being able to verify/visualize timing for better tracing? Or maybe there are already tools that existing that I don't really know how to use (like ftrace + trace compass, maybe)
The author's mentioned that you can trace MySQL with USDT, which is a tracepoint inserted by the developer at select locations in the code. This kind of tracepoints form a "stable interface" for tracing/performance debugging, whereas uprobe, which hooks into select userspace functions, are unstable as the binary is recompiled. Unfortunately, the USDT tracepoints (via DTrace) have been removed in MySQL 8.0. This makes it significantly more difficult to trace MySQL, although it's not impossiblhttps://news.ycombinator.com/item?id=29772927e. I've done a proof of concept of tracing MySQL with uprobe instead of USDT in this repo[1], which can kind of give you the same results (and possibly more stuff, as I can more easily read arbitrary memory address due to how the old USDT tracepoints are structured). This is not stable tho, as any MySQL upgrade may introduce incompatibility with the trace script, as I read memory address based on offsets (whereas with USDT this can be kept pretty stable). My appeal to Oracle to re-add this functionality[2] has unfortunately been rejected, which I think is a mistake given the wide range of possibilities unlocked via BPF.
[1]: https://github.com/shuhaowu/mysqld-bpf
[2]: https://bugs.mysql.com/bug.php?id=105741
Another thing that I've been recently thinking of is using BPF to validate programs written for real-time Linux (via PREEMPT_RT). To my understanding, one of the main thing to avoid is page faults [3]. With the proper BPF tracing scripts, I think we can validate that programs indeed avoids page faults in integration testing. I'm not sure if it is super useful yet, but as I'm trying to write a few RT programs, it's something that came to my mind.
[3]: https://lwn.net/Articles/837019/
In addition to tracing (so bpftrace-based/bcc-based tools), I've recently discovered that there there are:
1. ebpfsnitch (https://github.com/harporoeder/ebpfsnitch): which is an application-level firewall without kernel modules.
2. ebpf-traffic-monitor (https://source.android.com/devices/tech/datausage/ebpf-traff...): which appears to be using BPF to account for traffic for different apps on Android.
3. kubectl trace (https://github.com/iovisor/kubectl-trace): Run tracing on k8s.
There are apparently also use cases in the context of security, but I'm not familiar with it.
This kind of multi-modal behaviour can be very hard to capture with A/B test. You get a large influx of people that more than offsets the loss in the other audience pool. It's also anyone's guess on which group is better. From a pure business perspective, it's probably okay to lose me, as I use adblock and/or youtube-dl to watch the videos, which means I don't really drive revenue. That said, I've noticed some second order effects: as I'm more technical, I would recommend these type of content to others who will listen to my advice. I've noticed similar effects with others. If the more technical people are in the second group and are driven away, I wonder if this kind of stuff makes a difference with the long term health of a channel/content generator, which could be very difficult to quantify.
In any case thanks for your videos and insights.