or substituted its own SSH host keys,

why would the backdoor do that? It would immediately expose itself because every ssh client on the planet warns about changed host keys when connecting.

does it support foobar2000 plugins?

probably not, since those are windows dlls. So here’s a short list of what I’d want from a fb2k replacement:

• a UI plugin with the power and flexibility of Facets/Refacets
• browse library by folder structure OR tags (most only do one or the other)
• powerful query language to actually find what I’m looking for
• binaural stereo for headphones plugin
• convolver
• convert to opus and replaygain scanning
• DR Meter
• handle my >100k tracks library without constantly crashing or being incredibly slow

Most alternatives I’ve tried can’t even deliver on half of those.

Do you really think OpenRC or runit or any of the other init systems people are using have any similarity to SysV init?

Yes? OpenRC is certainly much closer to sysvinit than systemd and in many ways just expands upon it.

I’d recommend sway and waybar. Waybar offers some cool customizable templates. Currently I also use bemenu as a launcher and dunst/poweralertd for notifications. I make heavy use of stacked or tabbed layout during general use.

sway has pretty decent mouse support, but for optimal productivity try to get used to the keyboard shortcuts. As soon as moving/resizing windows and changing desktops becomes muscle memory it’s a whole different ball game.

same as @denissimo@feddit.de I use foobar2000 + wine. ffmpeg is alright, but fb2k is very convenient (especially for replaygain tagging). Afterwards I usually give the files a Picard treatment to get proper tags + covers.

Tip: You will save heaps of space by not embedding the cover on each file, just put a cover.jpg in the albums folder, virtually any player will pick it up.

Except when streaming the file or copying a random file to another location. embedded art is pretty convenient, 500x500 is plenty large enough and doesn’t take a lot of space (~50KB)

LC3plus isn’t really HiFi. It’s designed to be low-complexity & low energy: https://hydrogenaud.io/index.php/topic,122575.0.html

Xiph really won the lossy codec scene with Opus and I transcoded all my junk to that format. Hitting (my personal) transparency on 128k vbr is flat out impressive

Same here. I’ve left myself a bit of a safety margin at 144k vbr, but having my whole library at transparent quality AND portable size is very convenient.

Though, now that opus 1.4 is out I feel a bit of anxiety whether i should re-encode everything from flac->opus1.4

For context, LDAC is one of the few wireless audio codecs stamped Hi-Res by the Japan Audio Society and its encoder is open source since Android 8

LDAC is great, but simply stating that the encoder is “open source” is quite misleading (while technically correct). The codec is owned by Sony and heavily licensed. It’s a savvy business move of Sony to make the encoder free to use though, so everyone else can support their standard while charging manufacturers who want to integrate it into their headphones.

If we want a really free and open high quality codec, we should push for opus support via bluetooth

If system security is the most important criteria above everything else, switch to using BSD.

nice bait mate.

But that being said I think it may actually be good to merge it. It seems that there is lots of interest and the maintainers will be around to keep improving it.

Yeah I think people shouldn’t hold it against bcachefs to have some issues in experimental stages and going mainline is a good way to catch obscure & rare bugs.

Look at BTRFS. It was known for data loss but now seems to be pretty stable with lots of eyes and lots of work.

IMHO it’s pretty unfair how people like to give new, complex, filesystems a ‘reputation’ immediately, when there are some issues. I hope not the same is done with bcachefs and it gets its fair shake. Occasional issues popping up now (like in your blog post), hopefully, will also allow some of its cult followers to touch grass and get a reality check (filesystem = difficult). IMHO Kent really should remove the obnoxious “The COW filesystem for Linux that won’t eat your data.”-sentence from his website as it encourages such nonconstructive attitudes. I’m sure he is aware that, at this point, btrfs is less likely to eat your data by many orders of magnitude compared to his draft filesystem (and that’s mainly because most of those data eating bugs have been found and fixed in btrfs, not because it’s somehow impossible to corrupt by design).