351–360 of 408 posts
Earlier quoted context omitted.
gnome =! gtk sure they are a bit more related then KDE and QT, still but the same at all
We all know that. I assure you. Gnome uses GTK and evidently Cosmic 2.0 will use GTK
Earlier quoted context omitted.
Do you think Actix Web would be safer if it were written in C++?
Probably not, the point was that being in Rust wasn't either.
But is it going to be faster, what I really want out of a Linux desktop is for it to look nice, but not eat up in indefinite amount of RAM.
Original Nautilus and early GNOME developer here. I am very out of touch with what is current, so excuse some possibly ignorant questions. How is this a Rust-based environment if it is based on GTK? I assume GTK is still essentially the C-based GTK we used with some improvements. Why is this called Rust-based? I’ll do some more research but would like to get some insight from more knowledgeable sources.
Also GTK4 means they are still at the mercy of GNOME which changes APIs often and without consideration for third parties. Wasn't the whole point of the project to emancipate themselves from GNOME? If they rely on GTK they will fail.
UI toolkit doesn't equal a desktop environment. There is tons of stuff in the GNOME ecosystem (some of which it will make a lot of sense for System76 to reuse, no doubt) that can be entirely ignored when you're using GTK to, essentially, draw your UI widgets for you.
Earlier quoted context omitted.
That seems like a lot of revisionist history. From what I've seen GTK never had good cross-platform development support. Programs like GIMP and Inkscape always looked and behaved very oddly to me on other platforms. The little support that's there is because interested parties contributed it. If this is what you want, it's self-defeating to refuse to contribute it. If you do not want to use Rust, you can always use a…
> From what I've seen GTK never had good cross-platform development support. From the start, GTK was written so that it would have good cross-platform support. GTK itself (not GNOME or Glib) is perfectly system agnostic, and as you've mentioned, it compiles and runs on other platforms. Not sure why you'd knock the way GIMP and Inkscape LAF on other systems; they both look perfectly native on Windows, and much better…
Earlier quoted context omitted.
Solus OS' BOFH got tired of Gnome and he will switch the entire stack in to Enlightenment. And inb4 "E17 and such have Gaudy theming", last E has a flatish theme, so something like Arc for E would be really easy to implement. https://www.enlightenment.org/
This Enlightenment? https://what.thedailywtf.com/topic/15001/enlightened Definitly a good choice. /s Enlightenment was a nice window manager back in the mid-1990's, nowadays who cares if it still compiles.
https://www.enlightenment.org/
EFL has been supported by Samsung and Tizen, so I expect a full rewrite soon. They are doing really good changes now.
Earlier quoted context omitted.
> I really want System76 to succeed Succeed at what ? Re-implementing Gnome in Rust ?
Hopefully not. Not re-implementing Gnome. Not re-implementing macOS which Gnome strives to imitate. OTOH I see the value of that: many people got used to macOS, and making things similar, and the cognitive load of switching low, makes business sense. Same as with Windows in early 2000s.
Apple had fiery fest of sales in Q4 2021, outsold all Wintel manufacturers, let alone Chromebooks. And after that, guess what, they now have 8% of desktop/laptop market share, instead of 6% they used to have. You can guess who covers most of the other 90+ percent.
Sent from my 2021 M1 Max MBP.
Earlier quoted context omitted.
Asking as someone who's never spent significant time/effort working with Gtk/GObject in C (only a bit in Python). Isn't it still generally desirable to have the compiler yell at you, if you can't convince it you know what you're doing? Rather than allowing the possibility of memory corruption. I do agree that the code in the example is far from beautiful. I wonder if we were to redesign GObject from scratch, if we co…
The work you have to do to show your compiler that certain constraints hold (say that i and j point inside the same array and that i can be extremely cumbersome, even in cases where it’s obvious that they do hold. That makes it not seem worth the trouble. Of course, that obvious may turn out to be incorrect for some edge condition. Basically, that’s the same reason why mathematicians don’t put all proofs through a pr…
In rust, that's what the unsafe keyword is allowed. It doesn't mean that the code is actually unsafe, but rather that the compiler should trust you on this one.
Earlier quoted context omitted.
Gnome doesn't want thousands of developers implementing their own visions for their projects and others don't want to donate their time to implementing gnomes vision. The proper thing for them all to do is all implement their own visions and people to use or work on what they please. Nobody asks why Tesla, Ford, and Toyota are wasting everyone's resources by being different company. Nobody suggests having different c…
> Gnome doesn't want thousands of developers implementing their own visions for their projects and others don't want to donate their time to implementing gnomes vision. This is definitely looking more-and-more like the case. The GNOME team's insistence on cutting people out of their workflow has left them with less contributors... which leaves them with a worse desktop and a roadmap that's being pushed further-and-fu…
[0] After initially attempting Kinoite, which has some rather unfortunate problems that don't seem to be being addressed.
Earlier quoted context omitted.
Nvidia-docker is not the same as nvidia-container-toolkit, and neither of them have official support for 21.10 the last time I checked (a few months ago).
It is a component of nvidia-container-toolkit. Take one minute to browse the Pop repository and you'll find three packaging repositories forked from NVIDIA. libnvidia-container, nvidia-container-toolkit, and nvidia-docker. Installing nvidia-docker installs support for the whole system. Now you have functioning NVIDIA support in containers.
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.