Announcement

Collapse
No announcement yet.

VirtualBox Shared Folder Driver Seeks Inclusion In Linux 5.6

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

  • VirtualBox Shared Folder Driver Seeks Inclusion In Linux 5.6

    Phoronix: VirtualBox Shared Folder Driver Seeks Inclusion In Linux 5.6

    After being added to Linux 5.4 and then being ejected a week later when it was clear not enough testing took place, the VirtualBox Shared Folder "VBOXSF" driver is now trying to make it into Linux 5.6...

    http://www.phoronix.com/scan.php?pag...red-Folder-5.6

  • #2
    That's a weird move given the fact that you're not even allowed to use the Extension Pack for commercial uses without paying up $50 / user and a minimum order quantity of 100(!) licenses. That is, 5 grand minimum cost.

    I'd prefer they took their garbage somewhere else, not in mainline.
    Last edited by anarki2; 02-09-2020, 10:25 AM.

    Comment


    • #3
      Originally posted by anarki2 View Post
      That's a weird move given the fact that you're not even allowed to use the Extension Pack for commercial uses without paying up $50 / user and a minimum order quantity of 100(!) licenses. That is, 5 grand minimum cost.

      I'd prefer they took their garbage somewhere else, not in mainline.
      I don't see how that's relevant. It even states in the article that the patch was not submitted by Oracle.

      Comment


      • #4
        Originally posted by numacross View Post

        I don't see how that's relevant. It even states in the article that the patch was not submitted by Oracle.
        In which case it makes even less sense.

        Comment


        • #5
          Originally posted by anarki2 View Post

          In which case it makes even less sense.
          It makes more sense IMHO -- Linux user says "I need XYZ to work to pay my bills" and fucking makes it so

          Comment


          • #6
            Originally posted by skeevy420 View Post

            It makes more sense IMHO -- Linux user says "I need XYZ to work to pay my bills" and fucking makes it so
            It works with out-of-tree drivers as well, without voiding your "warranty". Somehow we've managed to use VBox for a decade without this 3rdparty mainline patch. Now you'll have VirtualBox sitting at version A, and your kernel driver sitting at version B. As if VBox wasn't buggy enough without such a mismatch. Combine that with stable_api_nonsense.txt and it begs for apocalypse.

            Not to mention that maintaining 2 trees simultaneously is just duplication of efforts = dumb. But then again, it's Linux we're talking about, where duplication of efforts is considered innovative and forward-thinking and stuff. Here we prefer 10 [email protected] solutions over just one that actually works properly.
            Last edited by anarki2; 02-09-2020, 10:55 AM.

            Comment


            • #7
              Originally posted by anarki2 View Post
              In which case it makes even less sense.
              Yeah the terms of usage for more advanced VirtualBox features suck, but there are still a lot of non-commercial users that would love to see this upstreamed.

              Comment


              • #8
                Originally posted by anarki2 View Post
                Not to mention that maintaining 2 trees simultaneously is just duplication of efforts = dumb. But then again, it's Linux we're talking about, where duplication of efforts is considered innovative and forward-thinking and stuff. Here we prefer 10 [email protected] solutions over just one that actually works properly.
                I'm not gonna pretend to know the history of these two drivers or the differences between them.

                But on the latter, yeah...as someone who was reading about pmake, bmake, and gmake last night as bed time reading, that I get to some extent. It's also a variable answer depending on the subject; like graphical interfaces with GTK vs QT or build systems like Autotools, Cmake, Ninja, Cargo, bmake, gmake. QT and GTK have different priorities, design standards, etc so having multiple solutions makes sense and different languages and/or projects have different needs in regards to their build systems.

                Do we need all of those build systems or graphical toolkits or file systems or compression methods or ??? No. They're actually why we don't have nice things and why Linux & Open Source is usually an afterthought. We need someone to go full Steve Jobs and start gutting the repos, dictating standards for reasons, and run with it with an "I have a vision that can see 20 steps beyond any of you, so do it like this" attitude to make nice things.

                Just look at what Apple and Sony turned FreeBSD into -- they dictated standards for reasons and turned open source into some of the best products and profitable companies out there. No reason someone or some company can't do the same thing while keeping the core system open source -- we all know the real money is in selling hardware and taking percentages with our closed source app stores...like Google and Android, except not evil.

                Linux or BSD, once you leave the core set of GNU tools or BSD tools, are a cluster in regards to what language will be used, programming formatting standards used, make system used, graphical toolkit used, bootloader used, backup/recovery method used, and, most importantly, the fact that there are 5-20 of everything in the repos meaning that even if you (an OS maintainer) set up a really nice flow, the end user can come along and dnf/apt/pkg/portmaster/pacman it into something unrecognizable -- can't get around that without going full Steve Jobs regardless of the open source OS base used.

                EDIT: And notice with Linux how I assumed GNU/Linux. All those GNU tools have alternatives and that adds to the cluster.
                Last edited by skeevy420; 02-09-2020, 11:35 AM.

                Comment


                • #9
                  Originally posted by anarki2 View Post
                  That's a weird move given the fact that you're not even allowed to use the Extension Pack for commercial uses without paying up $50 / user and a minimum order quantity of 100(!) licenses. That is, 5 grand minimum cost.

                  I'd prefer they took their garbage somewhere else, not in mainline.
                  This is a guest driver for the VirtualBox shared folder, not the VirtualBox Extension Pack. The Extension Pack that you talk about have nothing to do with shared folders.

                  Comment


                  • #10
                    It's good that more vbox drivers end up in the kernel. It makes it much easier to keep everything up to date. I've often found that out of tree vbox guest tools and modules often fail to compile on new kernels.
                    Last edited by Spam; 02-09-2020, 02:20 PM. Reason: Spelling

                    Comment

                    Working...
                    X