This is only true if they use another toolkit. If they choose GTK or Qt it's fine. Edit: it's GTK so no problem
Many app developers have complained that even within Gnome, apps developed using GTK get a very high number of bugs that are caused by unique customizations that the user may have installed and no one else does. These bugs, despite being significant in number, consume an even more outsized amount of resources and energy because they are very difficult to reproduce. System76 is only adding to that mess.
"Significant in number" is a funny way of writing statistically insignificant.
GTK deprecated Glade, so it's really not the fault of the Rust bindings. But to be honest, Glade's only useful if the language doesn't have good syntax for creating widgets defining properties on those widgets. Creating GTK applications purely in C is a nightmare. Vala makes it manageable. Rust also perfects it with tools like https://docs.rs/relm4-macros/latest/relm4_macros/attr.widget...
If that's perfect, then I'm a monkey's uncle. It's definitely more code and less ergonomic than the previous procedural methods. You can also see Rust's syntax bursting at the seams when they declare widgets...
if you're writing an application, it's generally ideal to have everything declared consistently in the same language. I'd personally rather not have to edit XML files by hand, and try to shoehorn XML-declared widgets into a Rust application.
You mean the one that you forked 12 days ago? What are you trying to accomplish by acting like it has been packaged all along? https://github.com/pop-os/nvidia-docker/commit/aa9fbcff6e6e5... This changes nothing about my story of the Pop OS developers previously thinking it could be replaced with their bespoke custom tooling.
This is a new repository that replaces a pre-existing nvidia-container-runtime repository that we've been using since 20.04 that does the same thing. It still remains that tensorman would not function without NVIDIA docker container support, because it's literally just a convenient frontend for interacting with Docker's CLI.
I never said otherwise. As you know, nvidia-containter-toolkit only very recently merged with nvidia-docker, and you know perfectly well that you have not always packaged or supported nvidia-docker.
“CUDA functionality” and nvidia-docker are not the same thing and you know it. This is the attitude that has me turned off off. Just acknowledge and we could move on! Unless you deleted them, anyone can search your github to find your comments telling users to use your bespoke tensorman tool instead of installing nvidia-docker, acting like one is a replacement for the other. And with the same presumptive attitude.
I have no idea why you're trying to argue with me over absolutely nothing. You could have saved so much time by asking questions instead of accusing me of things I haven't done, and spreading misinformation about it. CUDA support in Docker requires nvidia-docker+nvidia-container-toolkit+libnvidia-container, and that is the whole point of having nvidia-docker installed. We validate that CUDA functions inside of Docker…
OK here is a question: Why do you tell people to use tensorman instead of nvidia-docker when they have problems with nvidia-docker?
> I know that open source and Linux in general don't need/want another DE Unpopular opinion, but more DEs is fine and good, especially if they will have teams that are either (a) large or (b) well-funded. Plasma and GNOME are very good, and Unity was actually great to use in its heyday. Imo what we don't really need more of are the conservative, under-resourced 'classic look and feel' DEs like most of the minor playe…
>more DEs is fine and good I tend to disagree here. I recently switched back to MacOS after years of running both. The DEs on Linux are just one generation behind. Things have gotten better, but macOS and to an extend Windows are ahead. Linux DEs would be well advised to onboard more graphics and UI experts to make them more user-friendly and stable. Desktop metaphors have more or less stabilized and it's counter-pro…
It's interesting how people want so different things. I can't stand windows for 5 minutes before it's user interface starts to really annoy me. And mac looks great but all the Linux technology underneath is from the Stone Age.
Just to explain why I love Linux so much - when I'm in Gnome, I'm not bothered by any alerts or notifications or popups or sounds or ads or anything! It's a silent, stable, good looking desktop that runs my programs and doesn't get in my way at all. It's amazing! I truly love it.
If its good or not is a matter of taste in the end, but not the entire point. It also hijacked Super+L which was screen lock (like on windows). And then cosmic was even worse by changing the behavior of the super key completely. Both of these things broke my workflow for things i never asked for. I like pop and their polish compared to ubuntu [0]. I really hate it when software breaks my workflow. [0] https://news.yc…
It had to be hijacked because HJKL are often used for keyboard navigation for people who prefer right-handed home-row navigation. Super+Esc is the shortcut you're looking for.
If its good or not is a matter of taste in the end, but not the entire point. It also hijacked Super+L which was screen lock (like on windows). And then cosmic was even worse by changing the behavior of the super key completely. Both of these things broke my workflow for things i never asked for. I like pop and their polish compared to ubuntu [0]. I really hate it when software breaks my workflow. [0] https://news.yc…
It had to be hijacked because HJKL are often used for keyboard navigation for people who prefer right-handed home-row navigation. Super+Esc is the shortcut you're looking for.
What percentage of your user base never activates tiling?
Are you sure you had to break things for them instead of only hijacking it when tiling is enabled?
And that still doesn't address hijacking the super key completely with cosmic.
Sorry but imo these things have been handled really poorly.
> I know that open source and Linux in general don't need/want another DE Unpopular opinion, but more DEs is fine and good, especially if they will have teams that are either (a) large or (b) well-funded. Plasma and GNOME are very good, and Unity was actually great to use in its heyday. Imo what we don't really need more of are the conservative, under-resourced 'classic look and feel' DEs like most of the minor playe…
>more DEs is fine and good I tend to disagree here. I recently switched back to MacOS after years of running both. The DEs on Linux are just one generation behind. Things have gotten better, but macOS and to an extend Windows are ahead. Linux DEs would be well advised to onboard more graphics and UI experts to make them more user-friendly and stable. Desktop metaphors have more or less stabilized and it's counter-pro…
If the majority of companies that rely on Linux use it as a server for some kind of service(s), desktop environments or even graphics are not a priority. That's not to say that such use-cases don't exist. But the focus is, generally, not on outshining another OS or platform through the user interface or graphics.
Any recommendations for good tiling managers for KDE?
You can also use i3wm as tiling window manager. It replaces KDE‘s default window manager. I had good experiences with that. Guide: https://userbase.kde.org/Tutorials/Using_Other_Window_Manage...
True but you lose a lot of integration that is really nice to have. This why I never chose this option even though I use i3 on more barebones systems.
Because this is written in Rust and given how hard it is to hire Rust engineers, this will be abandonware in no time. Remember vala anyone? Although I want this to succeed if it is infact more performant and smoother than GNOME.
> given how hard it is to hire Rust engineers, That's not given. > Remember vala anyone? Vala is nothing like Rust, doesn't solve the same problems, and is much more narrow in scope (Gnome development). https://webcache.googleusercontent.com/search?q=cache:AcldYn...
For the reasons I mentioned above, adoption of vala by projects in 2010 is exactly like adoption of Rust.