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.

* * *

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.