tleb_

Can you clarify how this better helps express swing compared to a piano roll?

So this is about visualisation more than different behaviour? There are still N static notes with a cursor moving from start to end, looping over. It's not clear from the blog. Still, I always enjoy experiments in that domain, thanks

Do you have references to objections? I couldn't find any on the lkml threads.

-fplan9-extensions adds even more, it is not an alias: https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Unnamed-Fields...

One of the link of past discussions was from Apr 2018 and discusses it. At that time GCC -fplan9-extensions support was too recent (gcc-4.6) to be considered. https://lore.kernel.org/lkml/20180419152817.GD25406@bombadil...

Now the reasoning isn't present in the patch but it probably is because they want step increments and -fms-extensions is a small-ish first step. Maybe -fplan9-extensions could make sense later, in a few years.

The Linux Foundation (LF) is sort of this. A non-profit aimed at corporate members to sponsor work on many open-source projects (~900).

> For example, my blog search engine, which indexes on the order of 500,000+ words across 1,000+ documents, can return results in < 10ms because the indices can be queried incredibly quickly.

This is odd. Let's do a back-of-the-envelope estimation. DDR4 bandwidth is at least 12GB/s. 500k words is around 3MB. So, reading this amount takes 0.25ms, ignoring CPU caches. It sounds reasonable to assume the matching algorithm can run in-between that speed and 40 times slower for the 10ms mark.

This is one example where precomputation is probably not needed: bruteforce if N is small enough.

I disagree.

Applications want to receive/provide a stream (X sample-rate, Y sample format, Z channels) and have it routed to the right destination, that probably is not configured with the same parameters. Having all applications responsible for handling this conversion is not doable. Having the kernel handle this conversion is not a good idea. The routing decision-making needs to be implemented somewhere as well. Let's not ignore the complexity involved in format negotiation as well.

The scenario of a DAW (pro-audio usage) is too specific to generalise from that. That is the only kind of software that really cares about codec configuration, latencies and picking its own routing (or rather to let the user pick routing from the DAW GUI).

I have trouble understanding how people work for such big companies. Of course if the scale is 1000 employees "the company" cannot care about you; it is an institution not a bunch of people anymore. There is no upper layer to blame, the structure and scale themselves are the culprit.

I decided against that and work in a small company. Work-life balance is nice, we are friends and we all care (at least some bit) about the company itself. That is, because "the company" is us.

I see two differences: (1) the software stack on the server side and (2) I guess there is JS to be sent to the client side for HTMX support(?). Both those things make a difference.

What about plain HTML & CSS for all the websites where this approach is sufficient? Then apply HTMX or any other approach for the few websites that are and need to be dynamic.

In my MIDI controller case, the "compute state and send update" code takes about 8µs, up to a spike of 15µs. The worst case of the code in article is a sort on each frame on a 100ish array, it sounds safe to ignore. Profile before optimizing.

Another way to describe what has been done: implement a pure function and avoid storing additional state. It sounds way less dumb that way. It is not really a pure function but the spirit is here.

I've done the same during a refactoring of a side-project recently. It handles the input/output to a MIDI controller with many buttons, knobs and matching LEDs. Instead of computing what LED should change at regular interval, I am switching to recomputing the whole state each time. No more complex logic, no more mutable data. Only a pure function that outputs the desired LED state based on software internal state. Then a diff is computed and only changes lead to MIDI messages. Code is less efficient (for 100-ish LEDs) but much more straight forward.

The article from renehersecycles.com does not really agree with your comment, and explains why.

Apparently not.

.deb file: http://archive.raspberrypi.org/debian/pool/main/r/rpi-connec...

It contains two Go executables in its /usr/bin path: rpi-connect and rpi-connectd.

For reference, sort(1) has -n, --numeric-sort: compare according to string numerical value.

I agree the format is interesting. What are some other examples of short stories about technology, recent or less so?

I do not agree. Commits in my patch series have no link whatsoever with the chronology of my work. I wouldn't call it "Git history" as long as it is the branch I'm working on. It becomes history once it is merged inside a more persistent branch.

Then use a tree if you need a tree?

Well it has scaled up until now, which is a sign it could fit the scale of almost all software projects.

This is usually called container_of in C projects. It is compile-time safe as well, though the error won't be pretty. Linux, Qemu, musl, U-Boot, iproute2 & uclibc-ng each have a copy from the few project I've looked at. Two interesting implementations:

- Linux, compile-time checks that ptr is the same type as the member: https://elixir.bootlin.com/linux/v6.6/source/include/linux/c...

- musl, minimal: https://elixir.bootlin.com/musl/v1.2.4/source/ldso/dynlink.c...

I'm interested in doing the same thing but using PipeWire only. What kind of processing do you use Reaper for?

I've worked on a project that required a bigger swiotlb as well, I don't remember the exact details though. I guess it's not that uncommon, but indeed the default value looks good.

I see two use cases for a "big" swiotlb buffer: (1) many devices concurrently, as you said, or (2) ring buffers for devices that write continuously. Combine both and you require even more space; knowing the usecase and doing testing becomes required at this point.

Unit testing doesn't account for many lines in the Linux kernel. I see 33 test suites.

    $ find include/kunit/ -type f | xargs wc -l --total=only
    2418
    $ git grep -lE '^kunit_test_suites\(' | xargs wc -l --total=only
    17838

I agree Wikipedia is well designed

Both the GitHub project you linked to and the webpage in the posted article use a bounding box; has the webpage changed in the last two hours?

That is because there is a read to p[x]. If it gets removed, the malloc and free disappear. volatile shouldn't appear in such code that does not handle MMIO memory.

We've not seen yet any project at that scale, which approaches terraforming. What makes you think we are capable of such? And is there anything that indicates we can obtain the natural resources to achieve them?

This Wikipedia page mentions the following, with a link to the toxic plant that is probably described by the article author:

> Sometimes S. nigrum is confused for the more toxic deadly nightshade (Atropa belladonna)

That sounds like the concept of Factorio: the abstraction level we play at rises with time. Most of the achievements are about skipping manual labor at various points in time.