• 3 Posts
  • 149 Comments
Joined 1 year ago
cake
Cake day: June 23rd, 2024

help-circle
  • Agreed. But he’s also an abrasive know-it-all. A modicum of social skills and respect goes a long way towards making others accept your pet projects.

    This isn’t what I get when reading bug reports he interacts in. Yeah, sometimes he asks if something can’t be done another way – but he seems also very open to new ideas. I rather think that this opinion of him is very selective, there are cases where he comes off as smug, but I never got the impression this is the majority of cases.

    I wasn’t talking about the protocol, I was talking about the implementation: PulseAudio is a crashy, unstable POS. I can’t count the number of hours this turd made me waste, until PipeWire came along.

    PipeWire for audio couldn’t exist nowadays without PulseAudio though, in fact it was originally created as “PulseAudio for Video”; Pulse exposed a lot of bugs in the lower levels of the Linux audio stack. And I do agree that PipeWire is better than PulseAudio. But it’s important to see it in the context of the time it was created in, and Linux audio back then was certainly different. OSS was actually something a significant amount of people used…




  • Well with your DVDs the “HD resolution” question is easily answered: you don’t get HD resolution. Weird comparison there. Especially since you complain about Disney+ not going beyond 480p in your specific case - so why buy DVDs with the same shitty resolution?

    While I generally agree here, resolution isn’t everything, bitrate also plays a role, and some content in streaming services has been compressed rather badly so that you get artifacts that you don’t have on DVDs. A DVD will certainly look better than 480p streaming content despite a much older codec which light only exists as a reason for an upsell.

    I think the way to go is a Homeserver (could even be a raspberry pi) where you can somewhat secure your storage with appropriate redundancy.

    And how would you get stuff onto your homeserver legally?







  • Yeah, this one is on Kent… again.

    He posted on Patreon that there’ll be a DKMS module. In my opinion, this should have been the option from the very beginning and upstreaming at a later point in time. It would have avoided a lot of drama. And now bcachefs is kind of tainted. The only way I ever see it back in mainline is there is an independent downstream of Kent’s kernel that has no connection to him whatsoever.

    Shame because I had very good experience with the filesystem. Definitely better than when btrfs was new. But Linus is unfortunately right; Kent is unable to follow agreed collaboration rules.

    Unfortunate situation that could have been avoided entirely. Though I don’t want to be too harsh on Kent. He spent a lot of time and work on bcachefs and it’s his most important project. As such, he’s more passionate about all of this. But the same can be said for Linus and the kernel on the other side.









  • The issue is not only complexity, though it does play a role. You can also run into issues with pure text parsing, especially when whitespace is involved. The IP thing is a very classic example in my opinion, and while whitespace might not be an issue there (more common with filenames), the queries you find online in my opinion aren’t less complex.

    Normal CLI output is often meant to be consumed by humans, so the data presentation requirements are different. Then you find out that an assumption you made isn’t true (e.g. due to LANG indicating a non-English language) and suddenly your matching rules don’t fit.

    There are just a lot of pitfalls that can make things go subtly wrong, which is why parsing general CLI output that’s not intended to be parsed is often advised against. It doesn’t mean that it will go wrong.

    Regarding Python, I think it has a place when you do what I’d call data set processing, while what I talk about is shell plumbing. They can both use JSON, but the tools are probably not the same.