Posts
4417
Following
315
Followers
471
Linux kernel hacker and maintainer etc.

OpenPGP: 3AB05486C7752FE1
Edited 11 months ago
@argv_minus_one Because it will allow to compile kernel with a compiler with proprietary changes. It is permissive but not self-governing.

You can still obviously do that for Linux but it is limited useful given that you would have to build that compiler from scratch.
1
0
0
@pinkforest LOL, I don't still think that completely renders out my point ;-)
0
0
0
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
2
4
6
Edited 11 months ago
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
1
2
4
@sami There's tons of great immediate mode vector graphics frameworks all over the place these days. That could be also the reason...
0
0
1
Proactive misuse of MPE is the latest. Before I tried it sometimes as experiment. Now it is like the first thing I ever fill before trying anything else because of "tracker feeling". Also when MPE parameters have been allocated to the full note operators can give surprising results and have more dimensions.
0
0
0
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
1
0
0
Everything was clipping in every patch I've done for that time now that I checked :-) Now I also know what to check and where in the future, and hopefully start to get out some actually usable sounds This is why switching DAW is not something that you want pursue too often. Every DAW have few of these. That said, still happy that I switched from #Ableton Live.
0
0
0
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
1
0
1

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

0
0
3
That said, file path complete in vim is great (C-x and f) if that is considered as auto-complete :-)

Right and BTW I use ctags [not lsp] ;-)
0
0
0
@oherrala It is still better than auto-complete lottery, Internet forums and ChatGPT ;-)
1
0
2

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

2
4
21
#audija #kickdrum is really a game changer plugin. E.g. can resize the window freely. There is also 2.0 upcoming.

And despite being simple it has added value to using stock plugins of a #DAW, given that EQ curve is calculated and thus does not cause phasing issues.

#musicproduction
1
0
1
Love this #YouTube channel: www.youtube.com/@ConsoleCowboys. So much useful and applicable content. Whoever #ConsoleCowboys is, I'm your fan.
0
0
0
@montar It is a mystery but people get upset and fork a lot these days.

Like I got EGLIBC fork from the past (despite I respect Ulrich Depper's amazing contributions to open source, cpumemory.pdf is still always at hand ;-)) but these days people in my opinion are way too sensitive and get upset way too easily.

I don't think Linux could have happened if world had worked like this 1991.
0
1
1
@montar It is a mystery but people get upset and fork a lot these days.

Like I got EGLIBC fork from the past (despite I respect Ulrich Depper's amazing contributions to open source, cpumemory.pdf is still always at hand ;-)) but these days people in my opinion are way too sensitive and get upset way too easily.

I don't think Linux could have happened if world had worked like this 1991.
0
1
1
Edited 11 months ago
@oleksandr @gromit @vbabka I'm looking into how I could possibly make it compile Zig by stealing ideas from https://dev.yorhel.nl/ncdu, which did such conversion (used to be a C project). If a few core data structures were a bit more robust and safe that would make a difference (but since zig is very interoperable with C no need to turn all things around).

I.e. first just replace main.c with with main.zig, autotools with build.zig and rewrite perl generator scripts in zig but no other changes. That makes it easier compilation job at least ("./autogen.sh && ./configure && ./make" vs "zig build"). And rename the program as "zmbsync" so that it does not name conflict with the Fedora package.
0
0
0
Show older