Announcement

Collapse
No announcement yet.

A Vast Majority Of Linux's Input Improvements Are Developed By One Individual

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

  • #31
    Originally posted by 144Hz View Post
    No Redhat no GNOME. People need to remember this.
    fixed

    Comment


    • #32
      Originally posted by cacarr View Post
      The guy needs some dang help with laptops for testing. He doesn't have nearly enough of them as far as I can tell. libinput being nearly a one-man show is kind of ridiculous.
      A lot of open source projects are one-man shows (remember openssl? but that was 2-man if I remember correctly). This is ridiculous that some fundamental things are so underfunded, when others earn millions.

      Comment


      • #33
        Originally posted by pal666 View Post
        it doesn't work that way. redhat can hire someone who has made himself replacement, that's all. redhat can't tell someone to become replacement
        Sure they can, because otherwise that person is fired or put elsewhere. Hutterer's replacement needs to know how to maintain libinput and such, and if he/she can't then someone else will have to. That person being a complete replacement isn't happening overnight, but, he can be replaced if necessary.

        Comment


        • #34
          Originally posted by schmidtbag View Post
          Sure they can, because otherwise that person is fired or put elsewhere.
          that's how you would run company, not how redhat works. redhat hires experts, not tells people what to do. btw this is why only moron would accuse redhat of developing something. when redhat is left without btrfs devs, redhat switches to xfs

          Comment


          • #35
            Originally posted by starshipeleven View Post
            fixed
            broken. both ways: gnome is developed by not only redhat and redhat develops not only gnome

            Comment


            • #36
              Originally posted by Dave_A View Post
              Having those things 'thanos-snapped' out of existance would be an overall improvement for enterprise/server Linux (eg, for headless VMs that never run a UI other than bash)....
              some windows or macos idiot's dream

              Comment


              • #37
                Originally posted by pal666 View Post
                that's how you would run company, not how redhat works. redhat hires experts, not tells people what to do. btw this is why only moron would accuse redhat of developing something. when redhat is left without btrfs devs, redhat switches to xfs
                Exactly my point... They hire experts. They're not going to put someone in Hutterer's position who doesn't know a thing about what they're doing. That's why if whoever they do hire doesn't know what they're doing, they have the resources to find someone else. How are you not getting this?

                Comment


                • #38
                  Originally posted by schmidtbag View Post
                  Exactly my point... They hire experts. They're not going to put someone in Hutterer's position who doesn't know a thing about what they're doing. That's why if whoever they do hire doesn't know what they're doing, they have the resources to find someone else. How are you not getting this?
                  how are you not getting that there's no other libinput expert to hire atm? did you read article?

                  Comment


                  • #39
                    Originally posted by pal666 View Post
                    how are you not getting that there's no other libinput expert to hire atm? did you read article?
                    How are you not getting that it doesn't take a genius to maintain libinput, and that libinput is already in really good shape? If you're an expert in Xserver or Wayland, you can probably figure out how to maintain libinput without mentoring. After all, there are still people pitching in changes to it. Sure, Hutterer is absolutely right that someone should be mentored, since taking precautionary measures is always a smart choice. But my point is the worst-case scenario (where he is unexpectedly unavailable with no trained replacement) will not result in any significant issues. It will not be an ideal situation, but libinput isn't going to suddenly crumble without him.

                    Comment


                    • #40
                      Originally posted by schmidtbag View Post
                      Hmm, for whatever reason I thought upstart came after systemd. My bad.
                      That's because of the typical propaganda about Red Hat doing no wrong and Canonical being the devil. Essentially the stuff you are still perpetuating.

                      Originally posted by schmidtbag View Post
                      Regardless of how bad Gnome 3 was, Unity (which also was pretty broken to start with) was still heavily dependent on it. Rather than make their own fork, Canonical could've just helped Gnome 3 get better and speed up the process. Remember: the reason people gripe about Canonical is because of how many times they fork things. It's not always something as big as Unity or Mir either.
                      Anyway, I'm aware there were other forks, but to my knowledge, most of them were basically just mashups of different environments. Unity was far more ambitious, and the greatest issue is Canonical actually had the resources to fix Gnome 3. Instead, they just decided to do things their own way. Same applies to Mir.
                      This is a dumb point. Why doesn't Gnome just fold up shop and help KDE "get better and speed up the process"? Why don't all distributions just fold up and help Debian get better? Maybe it's because they have their own goals, and it's impossible to achieve them without agreement from others unless you own the codebase yourself?

                      Canonical didn't develop Unity just because "they wanted to do their own thing". They had disagreements with Gnome developers on what should be done, and obviously could not get the changes they wanted done in Gnome for that reason. Even the performance updates that were added recently took months of discussion. The only reason Canonical has changed course now is because they are dropping everything to do with the desktop. This will bite them in the future as they are now at the mercy of the Gnome project. You know that whole "NIH" thing you are complaining about? Yeah, Gnome and Red Hat do that all the time. Except when they do it, people adopt their systems and call it community driven. It's nothing but propaganda.

                      Comment

                      Working...
                      X