I've taken the quantum track at #Brilliant (actually registered it just because of this track).

After going through it my feeling of the topic is that the psychological impact of mystifying it makes it more complex than the topic itself.

It is just a new computational model, which is a superset of Turing model (a single isolated qubit has computational power of a Turing machine).

I.e. it is a just new board game with its own rules for states and ports. I'd figure that in the early days of computing it felt similar "unreachable" mystery as you had bunch of scientists describing it.

Lately I've had to learns some bits of processing of IR inside LLVM. That is about as complicated as understanding qubits. Engineers will get it when they need it ;-)

#quantum #qubit #programming

#LKML QOTD from @torvalds:

"'[…] no [#Linux] #kernel developer should spend one single second worrying about out-of-tree modules.

It's simply not a concern - never has been, and never will be.

Now, if some out-of-tree module is on the cusp of being integrated, and is out-of-tree just because it's not quite ready yet, that would maybe be then a case of "hey, wait a second".

But no. We are not going to start any kind of feature test macros for external modules […]'"

https://lore.kernel.org/all/CAHk-%3Dwg1w6%2BXup%3DamYtYUCLO-SRYoy9R0z6BG-uGV%3Dy2f6yFWA@mail.gmail.com/

This resonates :D https://en.wikipedia.org/wiki/Impostor_syndrome

The PsychoPAC put up a new billboard outside Mar-a-Lago, and it is beautiful.

Thanks @gtconway3.

I ended up first in the oldskool demo competition of this year's Assembly. This wasn't self-evident, as there were several high-quality entries in the compo.

Technically, it's a one-file C-64 demo mostly consisting of character-mode animation made with the same tools I've used for a few VIC-20 demos. As for the social/poltical message, I also feel I'm repeating things I've said earlier, but perhaps I'm somewhat clearer this time.

"Transcend the Game" by PWP (which turned 30 years old a couple of weeks ago)
csdb.dk/release/?id=244634
youtube.com/watch?v=9HqOD1QUP3…
#demoscene

There is something endearing in that many people still post their computer specs and highlights of their on the KVR Forum as part of their signature :-------)

One idea for fully legal #ransomware alike software that could exploit #AI code generation:

1. Do the initial research where the code is scavenged for the ML consumption.
2. Do the initial research on how generate meaningless code with the property that it has a signature that could be detected.
3. Create automatically and in volumes malicious and meaningful Git repositories or fake profiles that contain seemingly legit projects but actually are not.
4. License projects with GPL3.
5. Create a framework for scanning binaries from which you can detect your signature.
6. Sue all the parties with conflict with the licensing.

Some steps have open holes but I think this pattern could potentially made to work in some form.

The future of #malware lies strongly in conning the AI. Why bother with social engineering (e.g. calling to the company) and risking yourself when you can just con the AI through the Internet. AI does not only make producing bad quality code easier - it also makes hacking systems factors easier.

Another angle would be to con AI to pick a pattern that leaves a backdoor to the implementation. People who rely on Copilot are not that likely to review the generated code, I'd guess.

#infosec

Glad to finally have #Zstd compression enabled for #AlpineLinux's linux-firmware package exactly half a year (minus a few hours) after originally opening the merge request during our post-Fosdem #postmarketOS hackathon!

If you're running Alpine (or postmarketOS) and have all linux-firmware packages installed, the on-disk space will go down from around a gigabyte to around half a gigabyte or so, which I think is pretty decent.

I've used a tool call yq for some time. It is like jq but parses also the document types that I have actually use for such as CSV, XML and yaml (not sure about toml):

https://github.com/mikefarah/yq

I've never used jq because I haven't parsed a single JSON file in my lifetime so cannot really compared to that.

Wondering how #Bevy implements the parameter discovery for e.g. add_systems.

#rust #rustlang

The first job interview was today of many that I'm going to have after the holidays. It included also live coding but since I did not expect it I passed it ;-)

If I had knew it, I would probably have failed. I'm really bad dealing with that type of stress even tho can stand a lot of pressure in IRL situatation.

@pinkforest LOL, I don't still think that completely renders out my point ;-)

#BUSL would be great for #audio #plugins ;-) .

https://lwn.net/Articles/984249/

I don't think #Rust should have any business in any core features of #Linux #kernel before there is GPL licensed toolchain for it. #rustlang

After working with RISC-V CPU's produced by SocHub, and CVA6 running on FPGA and projects like Keystone Enclave during my "industry sabbatical", here's my thoughts on the topic enumerated in random and chaotic order:

1. Specifications are ambiguous and sometimes plain incomplete. WFI opcode is a great example of ambiguity. The lack of ability to define caching properties (like MTRR on x86 ) for physical memory is a great example of incompleteness.
2. IRQ handling is worst I've seen in any modern CPU architecture. It is slow and badly engineered.
2. CPU's behave quite differently depending on vendor, especially cache. For this reason I spent almost two months fixing trivial page table boostrapping code for Keystone Enclave (on CVA6).
3. Commercial CPU's are proprietary as hell given that the "openness" means that companies just fork and tailor and obviously do not publish any changes back to the community.
4. There is neither shared repository for hardware definition in VHDL nor Verilog.
5. There's no open source community. There is only corporate body called OpenHW Group. It is all about companies doing together an open hardware brand, not individuals making together great things.

To have actually open hardware the design and HDL should be copyleft licensed. Not sure if that is commercially realistic but otherwise it is all just as fake as having a BIOS based on Tianocore, and claiming that BIOS is open source.

It is more open to have a proprietary vendor that either sells CPU's (Intel) or licenses the spec (ARM). It is also better for individual because you have an entity that talks you back if you are a customer of them.

#riscv #hardware #opensource #sifive #arm #intel

https://www.theregister.com/2024/07/16/jon_kern/

With the overhauling modulation capabilities in #Bitwig, there's still need for manual curves, so I've taken this somewhat fixed strategy in order to not get confused about all options:

1. At most one manual curve per track and I always record it to mod-wheel. That way it translates from hardware to every plugin and have different meanings.
2. Rest of the automation and "wiggling" with modulation capabilities
3. Proactively (mis)using MPE parameters (pressure timbre etc) exactly to sequence automation. It feels pretty natural as it is like note effects in trackers. Like in a bass I might map pressure to subtone, so that it can be taken away while harmonics are kept in same voulme.

Sometimes modulation crap becomes too convoluted. In those situations I make a new track and record the curve there as. #MIDI CC 1 (modwheel).

Have been a bit with confused for couple of years how and when, when there is lot of options, but this is now what I'm converged into.

#MusicProduction

Took me two years to pay attention this setting for filters in the Poly and FX Grid devices of #Bitwig.

I've been wondering why they just don't feel or sound right but could not have pointed my finger. So I just put this it to +12 dB. and problem fixed.

With stock devices (not necessarily with some analog emulated plugins) sound does not destroy. If you add let's 20 dB gain boost and bring it down the same amount it should be perfectly recovered (assuming that signal path is "stock-only").

#MusicProduction

I started my own fork of #isync (or #mbsync)

https://codeberg.org/jarkko/isync

It has now couple of commits:

❯ git log --oneline -2
8ea62c9 (HEAD -> main, origin/main) fix: compile with -fno-lto
f5782aa refactor: open code FORCEASYNC far and near parameters

The first is the fix for crash in #Fedora. The second open codes FORCEASYNC:

diff --git a/src/common.h b/src/common.h
index 940e74d..22bd827 100644
--- a/src/common.hb
+++ b/src/common.h
@@ -120,7 +120,8 @@ BIT_ENUM(
        ZERODELAY,
        KEEPJOURNAL,
        FORCEJOURNAL,
-       FORCEASYNC(2),
+       FORCEASYNC_F,
+       FORCEASYNC_N,
        FAKEEXPUNGE,
        FAKEDUMBSTORE,
 )

I plan to do this for all of those, as it allows to cut some slack out from bit_enum_get.pl. That will lead to a roadmap where eventually the whole ugly script can be rendered out replaced with BIT_UL macro from kernel (msync is GPL 2.0 licensed).

There is also a #zig branch but before build can be defined properly the C codebase first needs to be made sound in terms of the build. Then it is relatively easy task to repeal and replace main.c with main.zig.

#email

The only #Rust tutorial you ever need is:

cargo doc --open -p <crate>

This opens documentation in the web browser for any crate that a project might be using.

Example would end up opening documentation for env_logger:

cargo add env_logger
cargo doc --open -p env_logger

#rustlang