Announcement

Collapse
No announcement yet.

Linux 6.6-rc3 Released With MG Timestamps Removed

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

  • Linux 6.6-rc3 Released With MG Timestamps Removed

    Phoronix: Linux 6.6-rc3 Released With MG Timestamps Removed

    With roughly just about one month to go until the stable release, Linux 6.6-rc3 was released today as the newest test release of Linux 6.6...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Will 6.7 have bcachefs? I hope so!

    I don't understand why the timestamp stuff didn't get tested appropriately before merge. That's a very critical kernel part.

    Comment


    • #3
      Originally posted by timofonic View Post
      Will 6.7 have bcachefs? I hope so!

      I don't understand why the timestamp stuff didn't get tested appropriately before merge. That's a very critical kernel part.
      you all sound so smart compared to Linux developers that I wonder why you waste your time here instead of making your own kernel (10x better than Linux, of course!)

      Comment


      • #4
        Originally posted by timofonic View Post
        Will 6.7 have bcachefs? I hope so!

        I don't understand why the timestamp stuff didn't get tested appropriately before merge. That's a very critical kernel part.
        Looks like the same code can be better or worse, depending on the ending of your email address. Code posted by *@.microsoft.com, *@.google.com, *@.meta.com, *@.amazon.com, *@.nvidia.com, etc is inherently perfect (until proven shitty) and should be merged asap. Otherwise the code is inherently awfull (until proven decent) and should no be merged during this decade. If you want your code merged, you'd better get such an email, or spoof one if you can't...

        PS. Before bashing me for including other companies, the only reason I did not include them is that I already had wasted enough time and had enough disgust typing shitty company names.

        Comment


        • #5
          Originally posted by marios View Post

          Looks like the same code can be better or worse, depending on the ending of your email address. Code posted by *@.microsoft.com, *@.google.com, *@.meta.com, *@.amazon.com, *@.nvidia.com, etc is inherently perfect (until proven shitty) and should be merged asap. Otherwise the code is inherently awfull (until proven decent) and should no be merged during this decade. If you want your code merged, you'd better get such an email, or spoof one if you can't...

          PS. Before bashing me for including other companies, the only reason I did not include them is that I already had wasted enough time and had enough disgust typing shitty company names.
          You could have just reverenced the corporations from https://www.linuxfoundation.org/about/members

          Comment


          • #6
            Is it smart or is it captain obvious that a likely crap change that might be hiding dragons probably shouldn't exist and actually did contain dragons? I predicted that mg timestamps would be hiding awfulness on the article introducing them and I'm dumb as hell. Luckily it got vetted albeit a little late, better than a cve disclosed in a decade.

            Comment


            • #7
              Using bits in a field not designed for such information had a taste of bad design...

              Comment


              • #8
                Regarding mg timestamps.

                Why doesn't Linus have an outburst about that? I'd love to read that
                Why, you might wonder?

                In the past there have been pull requests that were essentially in development still. Not fleshed out features. And some of those got the famous outbursts.
                The intent on the kernel dev side seems to be that you work on a feature in a feature branch and then work your way up to whatever is the appropriate branch for pulling (ex. linux-next). That flow seems to , or that's how i read it, prevent in-development features from being merged and subsequently for the kernel to become unstable because of in-dev features.

                Now for mg timestamps. If you manage to get that pulled and "unpulled" in the same cycle then you clearly have not done the fleshing out of a feature. It clearly was work in progress else you don't change your mind mid-cycle. So where's that juicy outburst?

                Credits to the mg timestamp devs for asking it to be reverted, that was the fair thing to do!

                Comment


                • #9
                  Originally posted by slalomsk8er View Post

                  You could have just reverenced the corporations from https://www.linuxfoundation.org/about/members
                  But Platinum ones are the best to be an elite kernel dev!

                  Screenshot_20230925_135231_Firefox Nightly.jpg

                  Choose your flavor. Merge your code without submitting them before to linux-next or other branches/repos

                  Microsoft has extra EEE points!

                  Conspiranoid? Anyone forgets history?

                  Comment

                  Working...
                  X