mmstick76

It looks sluggish because it's a GIF. cosmic-comp is written from scratch in Rust.

We do not use JavaScript. It is Rust from top to bottom. The native applets are written with iced/libcosmic, and the same is true of the shell components in the compositor.

And now System76 has proven that there is money to made in the Linux desktop if you sell Linux desktops.

Larger organizations with a lot of salaries to pay are also typically risk averse and therefore much less willing to make huge bets on adventurous experiments into the unknown.

I can also confidently say that most people using Pop aren't using it because of the theme, and Pop!_OS is actually marketed to STEM and developers rather than gamers. It's just that a lot of PC gamers like what Pop!_OS has to offer to them, so it seems that way by word of mouth.

Let's be realistic. There's only two GUI frameworks on the Linux desktop right now. GTK4 and KF5/Qt. The GUI libraries in the Rust space have been evolving over the last couple years. Soon you're going to start seeing applications written in Druid, Slint, Iced, Tauri, and Dioxus. Former Qt employees have established a company and business model around Slint. Druid and Iced are making excellent progress. Tauri and Dioxus are alternatives to Electron.

There's potential for that but I wouldn't expect it until after 1.0

The key is that the QA team validates all kernel updates and other changes on all System76 systems, and provides professional support that you can reach out to that are experienced with providing support for Pop.

Subscriptions are awesome and completely matches up with the way we developed all of our applications and services.

The maintainer is on vacation and we just started fully committing to it. Check it again in a couple weeks to see how we're doing!

Yeah COSMIC will resolve this kind of issue once and for all. The current setup is very dependent on a person not tampering with expected features and packages.

Every high quality Linux desktop needs a high quality desktop experience. Clevo isn't as bad as people make it out to be. People conveniently forget that Dell, Lenovo, and even Apple have their systems manufactured in the same region with similar factories.

The COSMIC desktop isn't ready for anything either so they're a perfect match made for each other. There's no better time to invest in a new GUI library than doing so as you're already building a new desktop from scratch. Imagine how much money and effort would be wasted if we settled for GTK4 today and then later had to rewrite everything to Iced after someone else did the work for us. System76 would rather push the envelop and resolve this chicken & egg scenario instead of waiting around for consensus.

People also underestimate the talent that works at System76 and the amount of work required to bring Iced up to speed. Iced has already proven itself, and its using an architecture (Elm) which has also already proven itself. It's the best way to develop a GUI in Rust, without a doubt. Jeremy has developed an entire desktop OS from scratch, including making a GUI toolkit for it, so it's not like we're oblivious to the effort required.

Iced already has a fully functioning layout and rendering system so that webbrowser and JS engine analogy is complete. There's just a handful of features that are missing that are either partially implemented or we've already got 5 developers working on it full time to do the rest.

Color palette adjustments alone would bring it pretty close. We can automatically generate them on the fly.

Rest assured that anyone with experience with a GTK3/4 application is going to have an easy time with the COSMIC designs. A lot of aspects will be similar. Maybe even a bit more standardized in some ways.

We will have our own file dialogs as we complete the Iced GUI library.

At the top of the article you'll see that it's outdated. System76 has firmware hosted on LVFS and has a good relationship with him today. The lapse in communication was simply because Pop!_OS was consuming all engineering time, and we needed more time to get back him, which made him think that we abandoned the effort. He implemented a desired feature that we were concerned about having (disable tracking of downloads), helped us get adjusted to the firmware upload process, and the rest is history. We in turn have helped HP get the HP Dev One on LVFS too. Unfortunately, some people are still trying to weaponize this as FUD against System76.

In regards to System76, he spreads a lot of FUD. Purely because we had some technical disagreements about themes over an anti theme petition and his pet project libadwaita. He's been an ass towards us ever since. Even going so far as collecting a list of grievances out of spite. He's one of the most toxic people you'll find there. Looking forward to his next blog post.

You can add memory modules for 32 or 64 GB

The max is 64GB

You can upgrade it to 64 GB

It is upgradeable to 64 GB.

It is upgradeable to 64 GB.

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.

"Significant in number" is a funny way of writing statistically insignificant.

Since when have we told anyone that they don't need nvidia docker packages installed? You can validate that the Debian packaging has always shown nvidia-container-runtime/nvidia-docker as a recommends for CUDA support.

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 when pushing updates to nvidia-container-toolkit and friends.

Tensorman is not a replacement for nvidia-docker, and you're not going to get anywhere by trying to convince me about the functionality of something that I personally wrote. It is quite literally just a simple command-runner that runs docker commands, specifically for the purpose of managing the official Tensorflow Docker images, and getting a more streamlined setup for managing your local Docker images based on them. The sole purpose is to replace our previous tensorflow packaging in Pop!_OS that became impossible to package because newer versions of Tensorflow did not build beyond 18.04. Tensorflow themselves recommend using their docker images instead of trying to package and install their libraries on your host OS.

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.

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.

Actually, a lot of the early Linux desktop was hampered by this exact problem. I remember in the late 2000s experiencing segfaults constantly in a lot of applications, Mesa/X11, the kernel, and even the desktop environment itself. You had to spend a lot of time tracking down a setup that works and sticking to it when you find it. It's gotten remarkably better since then, but GNOME Shell is still really fragile with segfaults when developing extensions for it.

That said, this is not the sole benefit of Rust. It is more of a side effect of aliasing XOR mutability than the primary benefit of Rust as a whole. Let's take a look at the C and Vala landscape as a comparison. Neither support message passing with channels, and async support is virtually an unmaintainable hack. Vala has generics thankfully, but C doesn't have generics and it's really bad. It also doesn't help that your only options for building software is pretty much almost entirely GLib and whatever sparse set libraries might be available for the package manager. Whereas with Rust there's a vast immutable repository of libraries you can leverage, and publishing open source libraries on the platform is easy.

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...