Comments by "Mikko Rantalainen" (@MikkoRantalainen) on "Brodie Robertson" channel.

@kuhluhOG Mainline kernel is about having a stable release. If you want to develop your filesystem driver fast and stabilize it later, it doesn't belong to mainline kernel. And Overstreet keeps arguing that his method is so good and the code is close to perfect, and at the same time he argues that he cannot wait for comments to his patches because critical bugs need to be fixed ASAP. You cannot have it both ways. You cannot have both "close to perfect code" and lots of critical bugs at the same time!
27
Followed by "I have to move fast because users are complaining about critical bugs in production". So much code quality in reality.
5
If you want to stop cheating, stop trusting the client system. You cannot trust the client system even if it appears to be running your anti-cheat DRM system. Even pretending that DRM helps is just stupid. Always trust your own servers only and use e.g. AI to detect cheaters remotely from game input. However, do not block detected cheaters, just modify matchmaking to put cheaters against each other. That would create a new metagame for the cheaters (try to beat other cheaters) and the players playing the vanilla game would only play against other non-cheaters. If somebody cheats little enough to stay undetectable remotely, that level of cheating is probably acceptable overall. Most cheaters are lazy and stupid and would be really easy to detect remotely.
5
I agree. If the game cannot be run without administrator / system level access, it's not safe to run at all. It doesn't matter if the game runs on Windows, Linux or console.
4
@HenryLoenwind The "semantic annotations" are exactly the thing Rust wrapper adds to the C API. The C API documentation may have stuff akin "you must call free() exactly once for each successful malloc()" whereas the Rust can implement that natively on code level. In most cases where R4L have needed support from C developers has been cases where Rust developers notice that C developer has failed to even document the corner cases and when the R4L developers try to ask for the missing spec, the C developer starts a flamefest instead of simply agreeing that yes, the spec didn't specify the requested thing. If C supported encoding the require semantics in the source code, Rust wrapper could be automatically generated by the compiler with zero human maintained files. Instead we have C code with handwavy documentation in English and R4L people trying to rewrite the API into format specification that can be processed by a compiler. They simply happen to write that formal specification in Rust syntax because otherwise there would be 3rd language in the mix!
3
3:00 I think non-disclosed ads like this would be illegal here in Finland. Here the legislation specifies that ads must be clearly labeled as ads.
3
I like both C and Rust and even though I think that writing C code is "easier" than writing Rust (may be a skill issue on my part still) I have to honestly say that writing perfect C code is next to impossible. I think we can all agree that Linux kernel developers are close to most being most skilled C developers in the world. And look at the results: those top of the top developers writing C code that is publicly reviewed on LKML before being accepted in the kernel and we still end up with all kinds of CVEs. If these people are still not skilled enough to even avoid security bugs with C, maybe C is not a good solution in long run. Will the parts written in Rust ever have CVEs? Probably yes, but that will be much much much more rare event than with C. And such CVE would highly probably be about logic errors, not about memory corruption or about thread safety, unlike with CVEs dealing with code written in C. Yes, slowly switching to Rust in Linux kernel would require nearly all kernel developers to learn both C and Rust. I don't consider that too high minimum bar to join kernel developer community. The level of C understanding you currently need is pretty high already and Rust isn't that hard a language to learn if you really put some effort to learn it. That said, I totally understand that NIMBY effect works for software development, too. All the greybeards that have made an entire career with Linux and dealing only with C code will not be happy to hear that their system wouldn't be good enough and that they would need to learn to do something else. In the end, the important question will be "what's acceptable" when it comes to code quality and performance. If writing stuff with Rust is 10x harder, is it worth it if it can cut 90% of all the yearly security bugs? What about if it can cut only 20% of all the bugs?
3
I agree. I purchased GTA V for my Linux desktop and returned the game for refund once the DRM system in the game was too much pain to play the game. Make it visible to the vendors that DRM is costing them real money! In addition, the pirated version of the game is more competitive if the paying customers have to fight the DRM system even a little bit and pirated version works without DRM of any kind. If you don't want to give customers extra incentive to pirate the game, do not put DRM measures in!
2
@lussor1 You cannot block cheaters by blocking Linux desktop gamers. The only real way to block cheaters is to NOT TRUST the client system, no matter if it's desktop Windows, gaming console or Linux laptop. Trying to run some kind of DRM system on the client system doesn't work because real DRM is a mathematical impossibility. So the real solution is to run enough of the game logic on the server to avoid cheating. However, that's often computationally expensive and vendors come up with random hacks instead. I think the best compromise would be to just monitor gamer actions and label cheaters and cheaters and then change online gaming matchmaking to put cheaters only against other cheaters and players playing along the official rules to playing against each other.
2
I agree that the dot files were created accidentally. However, the concept of hidden files seem to be worth having (see example of other operating systems implenting various ways to hide files) and if dot-files were a practical way to hide files from view, it was elevated to "feature, not a bug". I think it would have been better to specify stuff like ~/.local and ~/.config a lot faster to avoid filling home directory with random dot-files in long run.
1
10:40 These open source supporters claim to support freedom but the next moment they want other people to be kicked out of the project because somebody used a word that they think should be banned?
1
I'm using picom on Ubuntu and "picom --version" says "v9" and "apt policy picom" shows that I've version "9-1" installed. For this version, I run picom like this: picom --config /dev/null --log-file /dev/null --shadow -o 0.20 -r 8 -l -8 -t -8 --corner-radius 4 --backend glx --glx-no-stencil --glx-no-rebind-pixmap --no-use-damage --xrender-sync-fence --vsync --shadow-exclude '_GTK_FRAME_EXTENTS@:c' --shadow-exclude "name ?= 'Thunderbird' && (window_type = 'utility' || window_type = 'popup_menu')" --shadow-exclude "_NET_WM_STATE:a = '_NET_WM_STATE_ABOVE' && _NET_WM_WINDOW_TYPE:a = '_NET_WM_WINDOW_TYPE_MENU'" --shadow-exclude "WM_CLASS:s = 'xfwm4-wireframe'" --shadow-exclude '! class_g && ! class_i && ! _NET_WM_WINDOW_TYPE:a' --no-fading-openclose --unredir-if-possible --unredir-if-possible-delay 50 > /dev/null 2>&1 & Note that the command line is long only because I don't use any config files so this command line defines everything. I'm running this on GTX 1060 3 GB so this should be easily fast enough on any Nvidia hardware. The shadow-exclude rules workaround broken shadows for Thunderbird, Firefox, Chrome and XFCE.
1
The problem isn't that Linux couldn't play the game, the problem is game vendor explicitly blocking Linux desktop for some reason! As long as game vendor wants to block Linux desktop, there's no point trying to make it easier to support Linux desktop. This is no different from my online bank actively blocking LineageOS while allowing OEM Android versions that no longer receive even security updates!
1
I would guess Linus is trying to keep the code in kernel because that might allow somebody to step in and start to maintain the code. It seems that Overstreet needs some middleman that tests the code and only pushes forward known good versions upstream. Kind of LTS version of bcachefs. Except that the "LTS" version here is stable for at least one kernel release cycle instead of multiple years.
1
@JPs-q1o Why copy-paste this crap to every thread? If you have personal hatred against Linus, maybe reserve a time from a local psychotherapist instead. Kernel developers have been very liberal for new developers to submit code to kernel because kernel development is hard enough that you cannot be picky about the personality if the code is good. However, there's some limit about how broken personality you can have even if your code were good. And it appears that Overstreet may be over the limit even though he has been able to maintain the bcachefs for a decade. If bcachefs wants to get into mainline, there may be need for somebody else but Overstreet to do that. Maybe that person can take the latest bcachefs at the moment kernel push window closes and then only apply pure bugfixes only until the next kernel push window opens and then submit that version for the next kernel release. That way you would get full kernel release cycle worth of waiting time to see regressions fixed without any new code being introduced at the same time. That might result in good enough code quality to be included in mainline kernel. But it seems clear that Overstreet cannot follow that process.
1
I don't understand Overstreet's behavior. First he claims that his process is so perfect the his filesystem is better than btrfs. Then he says that his bugfixes are really important and are needed ASAP because customers are complaining about bugs. You cannot have it both ways at the same time. Which one is true?
1
If you're using Intel integrated graphics, you typically want xrender backend because it requires less processing power from your GPU and intel integrated graphics is not the fastest thing in the town.
1
19:05 This part alone shows it clearly that Overstreet has no clue about mainline kernel development. The single most important rule is "no never ever break any user mode program". That basically rules out any regressions. And still Overstreet tries to argue that "it's more important to move forward". See any old flame fests where Linus has totally crapped somebody. It's always because of breaking existing stuff and causing regressions. And those things happen exactly because of inadequate testing which Overstreet doesn't seem to be ready to do.
1
I think that Overstreet is given a LOT of leaway instead of just telling him to go home already and remove whole bcachefs from the mainline is beacuse he has demonstrated that he's a smart guy and gets things done. The only problem seems to be following rules. I would expect mainline kernel rules to be improved because of this case and the improved rules will probably say something clear about the rc releases. You don't push new code or features during the rc cycles. The only accepted code during the rc cycle should be about fixing specific issues caused during the push window. If that doesn't fit your needs for your "I want to move forward fast", then your code is not mature enough to be in the kernel anyway. Try to submit it again during the next push window and spend the waiting time on testing your code.
1