Announcement

Collapse
No announcement yet.

Bcachefs Looks Like It Won't Make It For Linux 6.6

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Anux View Post
    One should ask the question if we really want code in the kernel from people that are to incompetent to use a simple mailing list. Their code probably consists of snippets from stackoverflow and some brand new AI code generator.
    Way to show off your elitist attitude. Just because someone doesn't like one tool or method of doing something doesn't make them incompetent, but being logical about it wouldn't let you feel all smug inside, would it?

    Comment


    • #22
      Originally posted by avis View Post
      Looks like you believe those are developed by wannabe developers submitting crap AI generated code.
      Hu? You might read again what I wrote and this time try to understand it. Also a hint, try to adhere to statement logic instead of wild assumptions.

      Originally posted by WereCatf View Post
      Just because someone doesn't like one tool or method of doing something doesn't make them incompetent
      I don't like mailing lists either but the argument was that valuable developers are being held from contributing to the kernel. I'm not even a kernel dev, just a hobby script kiddie and I can handle mailing lists.
      Last edited by Anux; 08 September 2023, 08:54 AM.

      Comment


      • #23
        Originally posted by mxan View Post
        What even are the real (and I mean *real*) advantages of Bcachefs over Btrfs?
        It supports LZ4 which is the best set and forget compressor. I consider it better than Zstd for active data inline compression. Even better than that, it supports foreground and background compression. That means you can have it set to LZ4 for foreground stuff and have it compress it to Zstd when you're not doing anything.

        I can't tell if Bcachefs supports different Zstd or Gzip levels. Not supporting levels is a big nope from me since Zstd is pointless on a drive w/o being able to set levels...especially for Root on an SSD or NVMe where any compression level that isn't zstd-fast or LZ4 will severely limit your drive speeds. BTRFS doesn't support negative (fast) Zstd levels. AFAIK, only OpenZFS does...but it doesn't have foreground/background compression and it supports LZ4 so users don't have to find the optimal zstd-fast level to use (anecdotally, -500).

        LZ4 is probably the most important thing for people who don't take advantage of all the features available. Using that over Zstd or LZO on BTRFS will result in a more responsive system.

        From there it supports most all the other advanced features OpenZFS and BTRFS users might want. Encryption, snapshots, using multiple disk volumes with just the FS tooling, cache drives, and more.

        Comment


        • #24
          There is the idea that in conflict, if the person/people involved can resolve that conflict, there is great opportunity for growth. I don't really know the background here more than some "he said, she said" from reading here and reading some of the mailing list stuff. But I do hope this gets resolved and the parties involved can find some common ground. I have been getting more and more into filesystem stuff, and this one does interest me. I watched the video not too long ago that Kent posted about it and how it all worked, and was intrigued even if from a non-expert in that domain, it just seemed like a lot of thought had gone into it all. Here is to hoping things get resolved and all those involved are able to move forward in a more harmonious fashion! Doesn't need to be perfect, we all have our differences, just a more constructive path ahead for all involved.

          Comment


          • #25
            Originally posted by erniv2 View Post
            Tbh. that it was not in linux-next is a clown comment, since it was allready submitted for 6.5 and axed there aswell and nobody noticed that ?

            I understand the frustation.
            That's because their mailing list workflow is fscking stupid. Homie developed Git for this very damn reason but we'll still have to pry the mailing list from his cold, dead hands.

            Comment


            • #26
              Originally posted by Anux View Post
              and I can handle mailing lists.
              That right there: you're still trying to assert that people who don't want to use mailing lists are incompetent and that you're superior to them, ie. you are still being an elitist.

              I, for example, could use mailing lists if I wanted to, but they're terrible god damn shite and I wouldn't want to use one even if I got paid for it. It has nothing to do with not being able to "handle mailing lists".

              Comment


              • #27
                Originally posted by skeevy420 View Post

                That's because their mailing list workflow is fscking stupid. Homie developed Git for this very damn reason but we'll still have to pry the mailing list from his cold, dead hands.
                I think a certain Mr. Torvalds might lay claim to instantiating git. Junio Hamano has been the maintainer, and de facto lead developer for it for some time, though,

                I'm glad you pointed out that the mailing list workflow, is in your opinion, lacking. The mailing list itself is a communications tool, and the criticised workflow is a set of processes built around use of the communications tool.
                It is common for people presented with a system that has been built up over time in response to incremental needs to regard that system as irretrievably rococo; and to think that an often simpler system that they do understand to be 'better'. It is sometimes necessary to understand why things are done in a certain, apparently inefficient, way before replacing them. IT history is littered with failed projects to replace creaky old systems with efficient, but not fit for purpose, new ones.

                This is not to say that the current kernel development workflow could not be improved. It surely can. I believe it would be naïve to think there is a simple replacement.

                Comment


                • #28
                  Originally posted by avis
                  There are literally tens of dozens of unreplied posts with serious issues in LKML every month.
                  chromium's bug tracker laughs at your 'tens of dozens of unreplied posts every month'. systemd's github issues page finds it mildly amusing.

                  Comment


                  • #29
                    Originally posted by WereCatf View Post
                    That right there: you're still trying to assert that people who don't want to use mailing lists are incompetent and that you're superior to them, ie. you are still being an elitist.
                    What? All I tried to say is, that developing code for the kernel is a much more challenging task than using a mailing list. If you can do the first the latter is just a minor annoyance.

                    If you hate it and don't want to use it, than that's a totally different thing and there are probably C haters that wont contribute to the kernel and I didn't say a word about them either. Although I find it kind of childish and it's probably just an excuse to not do something.
                    It's like "I hate left driving traffic, therefore I won't help this blind man crossing the street".

                    Comment


                    • #30
                      Originally posted by Anux View Post
                      What? All I tried to say is, that developing code for the kernel is a much more challenging task than using a mailing list. If you can do the first the latter is just a minor annoyance.
                      That's a non-sequitur; the two are not related in any way to one another. The kernel is lots of code, the mailing list and their use of it as both a communication tool and as a patch submission tool are two entirely different things.

                      Originally posted by Anux View Post
                      It's like "I hate left driving traffic, therefore I won't help this blind man crossing the street".
                      Another non-sequitur.

                      Comment

                      Working...
                      X