pwnna

Trying to see if I can implement psychoacoustic bass enhancements and other advanced DSP techniques to improve Linux laptop speakers.

HW video decoding is now available and by default on in Chrome on at least Ubuntu with my Intel iGPU. I was also surprised when they turned it on under the radar. I saw this the other day debugging a problem and saw others see it too: https://www.reddit.com/r/Ubuntu/comments/1ojydv9/comment/nm8...

I actually made this patch a while ago on lineageos but lost the patch. It is a very invasive change where I filtered for the world amber and the French equivalent...

Does this impact the western digital and SanDisk brands too? IIRC those brands got folded into Crucial.

For single-threaded, cooperative multitasking systems (such as JavaScript and what OP is discussing), async mutexes[1] IMO are a strong anti pattern and red flag in the code. For this kind of code, every time you execute code it's always "atomic" until you call an await and effectively yield to the event loop. Programming this properly simply requires making sure the state variables are consistent before yielding. You can also reconstruct the state at the beginning of your block, knowing that nothing else can interrupt your code. Both of these approaches are documented in the OP.

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.

[1] https://www.npmjs.com/package/async-mutex

This is like fighting complexity with even more complexity. Nix and bazel are definitely not close to actually achieving hermetic build at scale. And when they break the complexity increases exponentially to fix.

So I don't understand where the meme of the blurry super-resolution based down sampling comes from. If that is the case, what is super-resolution antialiasing[1] then? Images when rendered at higher resolution than downsampled is usually sharper than an image rendered at the downsampled resolution. This is because it will preserve the high frequency component of the signal better. There are multiple other downsampling-based anti-aliasing technique which all will boost signal-to-noise ratio. Does this not work for UI as well? Most of it is vector graphics. Bitmap icons will need to be updated but the rest of UI (text) should be sharp.

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.

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

Neat! I worked on a similar formal verification of Ghostferry, which is a zero downtime data migration tool that powers the shard balancing tool at Shopify, also using TLA+:

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+.

Devil's advocate: my bridge fell down because I didn't know the concrete didn't meet spec still seem like negligence?

There is the kawai novus5 which is a digital piano with the action and soundboard of a real upright piano and enough speakers to sound almost exactly like a real piano. There are also some new roland models I haven't tried. Many dealers lump these into their acoustic piano offering and don't market them differently because they are that good.

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...

If I want to learn about this field and is somewhat familiar with only the classical approach to robotics, how should I get started?

Comparing gas vs electric seems incorrect. Should be comparing with induction instead. It is way more energy efficient (altho not necessarily more cost efficient). It produces no combustion byproduct like gas (which your air quality meter may or may not be able to detect), and it is way faster and gives you better control. It also is safer without flames or leaks, and less likely to burn you. It is the way to cook in 2024 imo.

I think people focus on protectionism because that is the traditional tool to fight things like foreign government's unfair subsidy practices. However, you cant just have protectionism without fostering competition and innovation in order to succeed in creating a more competitive product/market. Example would be USA protectionism against Canada's bombardier. It only protected Boeing but didn't actually make Boeing make better planes, as we can see from all the recent issues.

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 .

You're exactly right. I'm not asking for people to choose an inferior, pricier product. My thoughts is that China has the environment to have extreme competition which is leading to better product. This is distinctly not the case here. This is the structural problem that will eventually lead to a loss of competitive edge.

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.

The progressive loss in consumer robotics company in the West to their Chinese counter parts has been disappointing. Much like drones, I suspect this is short sighted as the underlying technology eventually have national security concerns.

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.

Yeah but we also would revoke their license..

How would you even differentiate between retries? If you isolate it by domain, the website can redirect you 10 times, each collecting an attestation token. They could perform statistical analysis with cookies. Websites could even force logged in users to conform to a particular browser (banking apps already do this). It's difficult for me to understand how the authors can miss these implications. They even said that with holdbacks the websites can still perform statistical analysis. Statistical analysis is not just a tool for aggregate data. It can be applied to a single client with enough other identifiers.

McDonalds app requires safetynet (effectively the same as this proposal) passing to access their app. Is that really required?

If you put a capability in, people will use (and abuse) it.

I don't understand how a probabilistic holdbacks can be effective if you can requests for the attestation token multiple times. If the holdback percentage is 10%, the probability of getting no attestation for 10 calls in a row would be something like 0.1^10 = 1e-10. This seems trivial to implement and use to block users.

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.

You're right, but I think it's mostly semantic and depends on how you define "performant" or "fast". Real-time software is about being "fast enough", every time. After all, slow and fast is subjective measures that varies wildly depending on the context.

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.

I found this to be hard-ish to get started as well. However, it turns out you just need to write your program to be performant, and know a few tricks to tune the OS and the scheduler. After looking on the internet and failing to find material about this, I wrote a series of blog post for this topic recently, starting with this post: https://shuhaowu.com/blog/2022/01-linux-rt-appdev-part1.html

The series is mostly complete, except one to two posts on more advanced topics like validation and lockless programming.

Still looking? What is the best way to contact you? Keybase?

I love both spreadsheets and Python/Jupyter. But neither is Excel the silver bullet? The reason the error is caught (and the real lesson) is more because he tried to reproduce his work as opposed to a particular technology stack.

Thanks for the link. Makie.jl looks interesting. I didn't find it last time I looked into Julia. I'll get it a shot at some point to see how usable it is.

Python is sufficiently readable, and with the right extension, it is sufficiently fast for vast majority of the purposes. For Julia to truly gain momentum, I think it needs a "killer app/library". However, I'm not sure what it would be that would not already be built for Python.

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.

A language like Ruby can be very productive for someone who has climbed the learning curve to learn all its ins and outs. However, in my experience, this turns into a large productivity drain the moment someone else (who is less of an expert) has to touch it.

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.

As someone that have spent a lot of time in both Ruby and Python (and specifically a lot of hours in the Python scientific compute stack), I would say that Python is significantly more readable. Python is also significantly easier to teach as opposed to Ruby, especially if the target audience already has a bit of programming experience (from MATLAB, or other courses).

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.

Yeah you're right on that one. I probably over-extended the use case here as I'm still just learning about this and thus tried to apply it to everywhere. I guess one thing you can maybe do is to use CI to validate that mlockall indeed has been called, haha. That said it's probably overkill as other tools can probably do this too.

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)

BPF is indeed a pretty interesting technology. As the knowledge about it becomes more widespread, I anticipate that we will unlock some new capabilities both in terms of tracing. Brendan Gregg's book (https://www.brendangregg.com/bpf-performance-tools-book.html) serves as a good intro to this, although you probably only need to read a small chunk of it as a lot of it is reference-book-style material.

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.

Maybe both your observation and HN is right: the distribution is multi-modal in the sense that (presumably) there is a large majority of people where the thumbnail works for and views the content, and then there is a small (and possibly vocal) minority of people who absolutely hate it and treat it as an anti-signal. I know I belong in the latter group and will lose all interest in the video once I see the weird face and the edited icon. I've seen a few of your videos and they're indeed very good. That said, I've noticed that I semi-consciously would avoid your video due to the icon which triggers an immediate reaction from me to stay away. It's a shame, because I know that the videos can be good, but the thumbnail is actively driving me away. In a way, I'm no different than the people who clicks on these videos, as I am also judging a book by its covers.

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.