Earlier quoted context omitted.
> But I'm always skeptical when underlying language choice is featured prominently as a selling point for any new project. > It tells me, this is a technology-first, users-second enthusiast project. > And thus, I'll be surprised if it tackles the deepest issues users need solved. Some of the deepest issues that users need solved are ones that Rust was designed to solve at the language and compiler level. 1. System st…
Ok, but GTK uses Javascript, which is where most of that toolkit's defects (both security flaws and slowdowns) come from, not C. Calling javascript from Rust isn't going to be a materially different experience than calling javascript from C.
Exploring System76's New Rust Based Desktop Environment
221–230 of 408 posts
Re: Exploring System76's New Rust Based Desktop Environment
#222Earlier quoted context omitted.
I left PopOS and never looked back when I needed nvidia-docker to do some deep learning work and learned they had knowingly made it difficult to impossible to reliably use nvidia-docker with PopOS, and they recommended their own unmaintained project that doesn’t even intend to be a replacement for nvidia-docker. It couldn’t have been more useless to me. Breaking compatibility with Ubuntu-compatible dev tools is one t…
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.
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 actuality, the correct article to reference is https://support.system76.com/articles/cuda/ but alas, this is presently broken on PopOS 21.04 unless you pin nvidia's repo's as you've suggested.
At the very least, an unpleasant experience. Probably some blame to be shared by system76 and nvidia.
Re: Exploring System76's New Rust Based Desktop Environment
#223Earlier quoted context omitted.
History and experience tells a different story [1]. Never trust a library that is maintained by GNOME. 1.: https://github.com/thestinger/termite
libadwaita exists solely to move Gnome specific stuff out of GTK into libadwaita. And it's hard to see how an open source project with as many developers as Gnome/GTK have can have some secret agenda that is counter to what they are saying publicly and creating libraries and code publicly to implement.
How many serious Gnome/GTK developers are there who are not IBM employees?
Re: Exploring System76's New Rust Based Desktop Environment
#224Earlier quoted context omitted.
Sounds like you just want to keep using MacOS. All of that should be more or less easy to tweak on Linux but that’s currently the trade-off. What you’re asking for is someone to rip off MacOS but it’s only acceptable if it’s a rigid and as well supported as MacOS which is developed by a trillion dollar company. That or perhaps join the Elementary OS QA team so that it can have a chance at reaching that really solid _…
> Sounds like you just want to keep using MacOS This is the essence of the issue. As someone who started on PCs running Windows and Linux for decades, I moved to MacOS for work because it's a zero config Unix based system with a productive and ergonomic desktop environment. I don't have an inherent bias towards Apple/MacOS and currently no longer use it (though I have an old x86 MacBook I use when not working on my d…
The DE included software might not get you there but there’s seems to be plenty of variations you could install. Again it’s not as polished but I’m not super picky about the specifics of how my OS appears to function.
I’m looking to add some niceties myself to KDE soon as apart of an attempt to learn some C++ and/or Rust.
Re: Exploring System76's New Rust Based Desktop Environment
#225Earlier quoted context omitted.
> But I'm always skeptical when underlying language choice is featured prominently as a selling point for any new project. > It tells me, this is a technology-first, users-second enthusiast project. > And thus, I'll be surprised if it tackles the deepest issues users need solved. Some of the deepest issues that users need solved are ones that Rust was designed to solve at the language and compiler level. 1. System st…
> It's like buying a Toyota, you know from the brand alone that you're getting a certain baseline level of reliability, maintainability, durability, and longevity. Rust is like the Toyota of programming languages - it can produce many different types of cars/programs, but they're all guaranteed to come with a baseline level of assurance, and to eliminate common classes of problems that degrade the end-user experience…
True.
> Rust is no exception.
Also true.
> Nobody should derive any confidence from the language a product is written in.
This, on the other hand, is a non-sequitur, or at least it's too strong, because Rust can do things that C can't do: safe deterministic memory management and safe concurrency without data races. These things are not just available, they are the defaults in Rust. You have to go out of your way to get these things wrong. So, I wouldn't derive absolute confidence from an application being written in Rust. But I'd be willing to bet a whole lot that it has fewer memory bugs than an equivalent application written in C.
Re: Exploring System76's New Rust Based Desktop Environment
#226I think I would've tried Pop!_OS by now if not for the name - I know it is totally irrational, but having a ! in there really pisses me off.
It's not just you. I have trouble going near CockroachDB because of its name. It's absolutely unjustifiable from an engineering perspective, but the effect (for me, at least) is real.
Re: Exploring System76's New Rust Based Desktop Environment
#227Earlier quoted context omitted.
> But I'm always skeptical when underlying language choice is featured prominently as a selling point for any new project. > It tells me, this is a technology-first, users-second enthusiast project. > And thus, I'll be surprised if it tackles the deepest issues users need solved. Some of the deepest issues that users need solved are ones that Rust was designed to solve at the language and compiler level. 1. System st…
> It's like buying a Toyota, you know from the brand alone that you're getting a certain baseline level of reliability, maintainability, durability, and longevity. Rust is like the Toyota of programming languages - it can produce many different types of cars/programs, but they're all guaranteed to come with a baseline level of assurance, and to eliminate common classes of problems that degrade the end-user experience…
You shouldn't dervive all confidence in a product from it's implementation language, but when you are looking at all available products and need to filter down to ones you might be interested in. Implementation language can be a useful litmus test for understanding how it might behave without doing a complete in depth evaluation.
For example if I learn that a desktop application is written in javascript, it is likely to be using electron or an OS webview. Or if an application is written in C++ it is unlikely to have GC pauses cause stuttery UI. Both of those assumptions may not be true (Sciter for JS and Boehm GC for C++ respectively). However those assumptions are a useful starting point unless proven otherwise.
Re: Exploring System76's New Rust Based Desktop Environment
#228I 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…
I left PopOS and never looked back when I needed nvidia-docker to do some deep learning work and learned they had knowingly made it difficult to impossible to reliably use nvidia-docker with PopOS, and they recommended their own unmaintained project that doesn’t even intend to be a replacement for nvidia-docker. It couldn’t have been more useless to me. Breaking compatibility with Ubuntu-compatible dev tools is one t…
Re: Exploring System76's New Rust Based Desktop Environment
#229Earlier quoted context omitted.
Then they would need to either 1) do the yak-shaving and create a whole new GUI stack in Rust (which would be an absolute boon to the Rust community but will be a tremendous effort), or 2) switch to Qt (and basically become KDE) Thinking about it, maybe Sciter ( https://sciter.com/ ) would be an okay foundation to build a DE in (lightweight stack, flexible theming, solid Rust bindings). But then it isn’t open source…
create a whole new GUI stack in Rust Is there a reason iced is not good enough (other than not being accessible)? https://iced.rs/ https://github.com/iced-rs/iced/issues/552
https://en.wikipedia.org/wiki/Input_method
https://github.com/iced-rs/iced/pull/686
See the challenges of properly supporting IME in Druid, another Rust toolkit:
Re: Exploring System76's New Rust Based Desktop Environment
#230Earlier 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…
The core of TLS 1.3 was proved before it shipped. But, the proof makes an assumption which has consequences. It assumes when communicating using an agreed shared secret† you have a separate shared secret for every such pairing. So Alice and Bob need a shared secret but (and this is where humans trip up compared to what was actually proved) the proof says Bob and Alice also need a shared secret different from the one for Alice and Bob.
The consequence of this accidentally missed assumption is the Selfie attack. Alice and Bob share a secret S and communicate over the Network using TLS 1.3. Bob fed the cat half an hour ago. The cat has employed Mallory to trick Alice into feeding it even though Bob already did. Alice sends a message on the Network. It is encrypted with S and it says "Did you feed the cat?". Mallory doesn't know S and can't read this message or tamper with it. But Mallory simply redirects the message back to Alice. Alice receives a message, properly encrypted using S, which says "Did you feed the cat?". She presumes this message is from Bob, so she answers "No, go ahead and feed the cat". Mallory redirects this response back to Alice too. Alice receives "No, go ahead and feed the cat" and she concludes Bob hasn't fed the cat so she feeds it again.
Oops.
The proof was fine, but we brought an assumption along that we did not clearly articulate.
† You never use this mode in your web browser, but IoT things might do this because it's easier than all that stuff with certificates.