VMware Workstation Shifting From Proprietary Code To Using Upstream KVM

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

  • ssokolow
    replied
    Originally posted by mirmirmir View Post
    Least deranged KDE fan
    To be fair, half of those are things I was working on for other reasons anyway.

    For example:
    • The PyQt rewrite of part of Geeqie is so I can use it as a GUI for an SQLite-backed image tagging and databasing tool that refers to images by SHA256 instead of by path (I know that having things silently vanish from collections when I forgot/failed to do the moving inside Geeqie has happened to me and is effectively a data loss bug) which I've wanted to write for over a decade. (And to finally rid myself of the endless parade of new crash bugs that seem to crop up in Geeqie.)
    • Workrave just isn't flexible enough to function the way I want and I have most of the work already existing in the half-finished Qt rewrite of an ancient project I wrote before discovering Workrave named The Procrastinator's Timeclock. (Plus, Workrave is written in C++. I'm not being paid enough to contribute to a C++ project.)
    • PlayOnLinux is EOLing their Python-based UI, I don't like their JavaFX GUI, and I already have an experimental "Lutris, but QWidget"-esque thing for exploring new design ideas that I could contribute to launchers like Lutris and I was planning to shove a Wine backend into it. (Granted, at the moment, most of the work has gone into refining the heuristic "guess title from filename" code for the fallback "point me at a folder of manually downloaded indie/fan-games" backend.)

    Also, another, more practical reason to use Qt-based apps. With GTK, the devs have to put in extra effort to support custom toolbar and dock layouts. With Qt, the devs have to put in extra effort to not support custom toolbar and dock layouts.

    (Source: I've written applications against both. In Qt, toolbar and dock customization are built-in and on by default and the only part you actually have to do for best experience is three lines of code to save window state on window close and another three to restore it on window open... and that's three lines at most. One of them is instantiating a QSettings and one is to persist window geometry too.)

    It feels like every time a new minor version of Inkscape gets released (eg. the 1.4 that just dropped), I have to play "OK, where did they move the toggle to put the toolbar back at the top this time?". With Qt, there's just a drag handle you can grab.
    Last edited by ssokolow; 01 November 2024, 05:08 PM.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by NM64 View Post
    I'm by far no Linux guru, but while I don't tend to mind the aesthetic of GTK3 applications (though GTK4 is a bit much...), I do find it maddening that they don't obey Fitts' Law (and, of course, neither does GTK4 - my personal pet theory is that the GTK devs don't see the problem because GNOME defaults to having the panel at the top).

    I don't know about your distro, but simply installing the gtk3-nocsd package seemed to make all GTK3 apps actually obey Fitts' Law (with the exception that Firefox and LibreWolf are no longer able to have tabs up against the top of their maximized window to take advantage of Fitts' Law for tab-switching, but my primary albeit rather small-time web browser is offered in a GTK2 flavor anyway)

    From the official github page:
    I used to use that, since it's packaged for Lubuntu's use, but, since I started using Flatpak to make it easy to upgrade/downgrade Inkscape (it's already saved me from a crash-inducing regression once), it's just become too difficult to reliably inject a custom LD_PRELOAD.

    If I didn't want to stay on an LTS distro, I'd consider switching to Arch for the gtk3-classic package. (It's a patchset to make GTK 3.x behave more like GTK+ 2.x. Screenshots)

    Maybe I'll look into how one goes about making a custom build of org.gnome.Platform and abuse their Testing an app with a different runtime instructions.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by eszlari View Post
    flatpak-kcm is part of Plasma since 5.27.
    Oh? Nice. That means it's Kubuntu's fault I don't have it and I don't even have to wait for my 22.04 LTS to 24.04 LTS bump if I track down the correct release to package myself. (22.04 LTS has 5.92.0 but no flatpak-kcm)

    Originally posted by eszlari View Post
    virt-manager respects SSD.
    So does Inkscape. GTK's menu code bugs out if KWin temporarily suspends compositing because you full-screened a video player on another monitor and starts drawing huge "I'll eagerly turn on ARGB visuals but require an application restart to turn them off again" black borders on menus.

    (I normally keep compositing off to maximize bug-free uptime, but I need to toggle it on when I'm playing a game and need vsync and that's when all my GTK applications take the opportunity to switch on their ARGB visuals.)

    Leave a comment:


  • jabl
    replied
    (Now what would be funny would be vmware dropping esxi in favor of KVM)

    Leave a comment:


  • SViN
    replied
    Originally posted by eszlari View Post
    virt manager frankly needs an entire UI/UX rework if you ask me.

    Leave a comment:


  • Danny3
    replied
    Now if the fucking Oracle would want to upstream more of its VirtualBox code...

    Leave a comment:


  • slalomsk8er
    replied
    Originally posted by Quackdoc View Post

    that's only one m tho
    Have a look at the top left of the site:

    image.png

    Leave a comment:


  • SteamPunker
    replied
    Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post
    Nice! Now Oracle just needs to start advancing the VirtualBox KVM backend from Cyberus and ditch the existing one.
    Indeed! Now that even VMware is embracing KVM, that leaves upstream VirtualBox as the odd man out. VirtualBox already switched WHPX on Windows hosts and to HVF on macOS hosts, so it really makes no sense that they continue to cling to their proprietary hypervisor, which requires and out-of-tree kernel module that taints the kernel.

    It's cool that Cyberus forked VirtualBox to add support for this, but why is Oracle continuing with such boneheaded policies? Oracle gonna Oracle, I supposed.

    Does anybody here have any idea if the VirtualBox proprietary hypervisor core still has any relevant advantages over KVM?

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by slalomsk8er View Post
    that's only one m tho

    Leave a comment:


  • Sethox
    replied
    Originally posted by Sonadow View Post
    Enterprise users have no fucking time to toy with the command line just to spin up, modify or manage a VM. If every damn option and the kitchen sink is not included in the graphical manager interface, it's useless garbage. End of story.
    True, but a good user tend to the minor details to become greater at it's job. Which is why a user documents and learn those minor details in what ever documentation/support exists to manage their systems in a better way.
    Time is just another thing users have to manage and plan for, just like any other resource.

    Leave a comment:

Working...
X