Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploring System76's New Rust Based Desktop Environment

blog.edfloreshz.dev

Post reply on HN
Print view View original

371–380 of 408 posts

Re: Exploring System76's New Rust Based Desktop Environment

#371

Post by nopenopenopeno »

mmstick76 wrote: post #350
nopenopenopeno wrote: post #301

Earlier quoted context omitted.

I’m sorry, I don’t quite recall the details but it was a few different things. The main one is forcing certain Nvidia libraries in the package manager so you need to take a few steps to undo some of the Pop OS Nvidia installation, which breaks other Pop OS stuff, of course.

There is no need to undo anything. We regularly test CUDA functionality with our packaging, and it's the whole point of having the packaging in the first place. So you don't have to manually install things from a third party repository or deb.

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

Re: Exploring System76's New Rust Based Desktop Environment

#372

Post by mmstick76 »

1_player wrote: post #295
k_kalupe22 wrote: post #290

Earlier quoted context omitted.

They do this for getting higher ranks here at hackernews. What turns me off most is that they succeed, which in turn indicates that large parts of hackernews readers are biased towards Rust. Personally, I'm pretty sick of this evangelism and hype because I fell for it some years ago and started a project with Rust. Countless problems and dark corners. I moved in time to a mature garbage collected language. There's a…

Especially when you have top voted sibling comments saying "Some of the deepest issues that users need solved are ones that Rust was designed to solve at the language and compiler level." What?! The year of the Linux desktop hasn't been eluding us because of buffer overflows and memory safety. The Rust hype train is incredible. The Linux desktop problems have nothing to do with the goal Rust sets out to solve. It's d…

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.

Re: Exploring System76's New Rust Based Desktop Environment

#373

Post by southerntofu »

pjmlp wrote: post #369
southerntofu wrote: post #363

Earlier quoted context omitted.

Yes, pretty much like that. The author put "unsafe" blocks everywhere and the rest is history. Unsafe as a keyword is a kind of pledge: as a dev, you swear to the compiler that you've checked this part for correctness/safety. If you don't, you may get bitten, but the simple fact that "grep -R unsafe" will yield most (if not all) instances of potential memory fuckups is a huge win for auditability.

Rust's unsafe wouldn't have done anything to protect against an hypotetical log4r. As for the memory fuckups you are right, pity that they are using a C GUI library. Even if the binding has been deemed safe upon validation, if only remains a valid certification until the next Gtk version update, even minor ones might break the assumptions validated on the unsafe code block.

> Rust's unsafe wouldn't have done anything to protect against an hypotetical log4r.

You are correct. No programming language will protect you from writing flawed application logic.

> pity that they are using a C GUI library. (...) Gtk version update, even minor ones might break the assumptions

I don't know about that. GTK is more "battletested" than most frameworks, and has a lot of contributors to fix bugs. Also, and that's a very important point, GTK cares for accessibility! Using any other framework would have meant excluding a lot of people from the GUI.

As for assumptions, i certainly hope GTK devs don't push breaking changes to the ABI on minor updates. But i guess that's yet another assumption that can be broken.

Re: Exploring System76's New Rust Based Desktop Environment

#374

Post by nopenopenopeno »

ShamelessC wrote: post #222
stonogo wrote: post #205

Earlier quoted context omitted.

They occasionally have driver mismaatches between the upstream containers and the distro-provided driver. This happens because nVIDIA only supports Ubuntu LTS releases and Pop moves faster. I solved it forever by pinning nvidia's repos to a higher priority. Otherwise I can't figure out what "unmaintained project" you're talking about, or what "tooling standards" are.

They are most likely referring to `tensorman` https://support.system76.com/articles/tensorman/ which is regrettably premised on the notion that you have any intention of using Tensorflow in the first place. Unfortunately, the `tensorman` article shows up first (after several complaint/support threads) in a google search result for the subject https://www.google.com/search?hl=en&q=nvidia%20docker%20pop%... In all actu…

It wouldn’t be a significant if the Pop OS developers weren’t telling users that they don’t need nvidia-docker. Of course, they can tell users whatever they want, but I’m not going to trust their OS if this is how they plan to handle things like this.

Re: Exploring System76's New Rust Based Desktop Environment

#375

Post by mmstick76 »

lawl wrote: post #175
mkdirp wrote: post #165

Earlier quoted context omitted.

Right. And so Pop!_OS gives you a decent tiling window manager, with sane defaults, without having to spend hours on customising your configuration. What's more, the tiling they provide is an optional feature. You can enable and disable it at any time without messing with you config for hours.

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.

Re: Exploring System76's New Rust Based Desktop Environment

#376

Post by magicjosh »

wmf wrote: post #109
pkulak wrote: post #64

I know that open source and Linux in general don't need/want another DE, but selfishly... I really want System76 to succeed. They give me the same kind of feeling I had when Apple was kicking butt in the early 2000s. And I think that for them to become a general-audience company, they need to really own more of their software. They have some great ideas, and they've already plugin'ed Gnome to within and inch of it's…

DEs are just the window dressing and computer management. That's how you end up in a situation where the contents of the window clash with the dressing because more and more apps can't be themed. If they want a consistent look they'll need to fork or write a whole new set of apps.

As a Linux newbie I'm wary of distributions that include many of their own custom apps. I know most of these teams are just a few people and I doubt in their ability to create the "Apple" (OS + Apps) experience. Alas, I'm new to this so perhaps I'm missing something.

Do any Linux experts out there feel the same way?

Re: Exploring System76's New Rust Based Desktop Environment

#377

Post by mmstick76 »

nopenopenopeno wrote: post #360
mmstick76 wrote: post #349

Earlier quoted context omitted.

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.

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.

Re: Exploring System76's New Rust Based Desktop Environment

#378

Post by mmstick76 »

nopenopenopeno wrote: post #371
mmstick76 wrote: post #350

Earlier quoted context omitted.

There is no need to undo anything. We regularly test CUDA functionality with our packaging, and it's the whole point of having the packaging in the first place. So you don't have to manually install things from a third party repository or deb.

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

Re: Exploring System76's New Rust Based Desktop Environment

#379

Post by mmstick76 »

nopenopenopeno wrote: post #374
ShamelessC wrote: post #222

Earlier quoted context omitted.

They are most likely referring to `tensorman` https://support.system76.com/articles/tensorman/ which is regrettably premised on the notion that you have any intention of using Tensorflow in the first place. Unfortunately, the `tensorman` article shows up first (after several complaint/support threads) in a google search result for the subject https://www.google.com/search?hl=en&q=nvidia%20docker%20pop%... In all actu…

It wouldn’t be a significant if the Pop OS developers weren’t telling users that they don’t need nvidia-docker. Of course, they can tell users whatever they want, but I’m not going to trust their OS if this is how they plan to handle things like this.

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.

Re: Exploring System76's New Rust Based Desktop Environment

#380

Post by hderms »

pjmlp wrote: post #309
SkyMarshal wrote: post #264

Earlier quoted context omitted.

> they are the defaults in Rust. Exactly, this is what I should have explicitly said. Language defaults have a powerful effect on a project's norms and culture. > You have to go out of your way to get these things wrong. Yes, you actually have to try to write shitty Rust code, at least where there are defaults that prevent it. Thus the average Rust program will have that baseline level of quality. Like TQM/TPM/Six-Si…

Like ActixWeb?

Isn't the whole reason you're mentioning actix-web because the community mostly balked at the amount of unsafe code in it? Surely that should be some evidence that the norms in Rustland are qualitatively different in many ways to what you'd find elsewhere?
Post reply on HN