Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Linux

Rust-Based 'Resources' is a New, Modern System Monitor for Linux (omgubuntu.co.uk) 57

Posted by EditorDavid from the utilization-graphs dept.
An anonymous reader shared this article from the Linux blog OMG! Ubuntu: The System Monitor app Ubuntu comes with does an okay job of letting you monitor system resources and oversee running processes — but it does look dated... [T]he app's graphs and charts are tiny, compact, and lack the glanceability and granular-detail that similar tools on other systems offer.

Thankfully, there are plenty of ace System Monitor alternatives available on Linux, with the Rust-based Resources being the latest tool to the join the club. And it's a real looker... Resources shows real-time graphs showing the utilisation of core system components... You can also see a [sortable and searchable] list of running apps and processes, which are separated in this app.
It's also possible to select a refresh interval "from very slow/slow/normal/fast/very fast (though tempting to select, 'very fast' can increase CPU usage)." And selecting an app or process "activates a big red button you can click to 'end' the app/process (a submenu has options to kill, halt, or continue the app/process instead)..."

"If you don't like the 'Windows-iness' of Mission Center — which you may have briefly spotted it in my Ubuntu 23.10 release video — then Resources is a solid alternative."
This discussion has been archived. No new comments can be posted.

Rust-Based 'Resources' is a New, Modern System Monitor for Linux More

Rust-Based 'Resources' is a New, Modern System Monitor for Linux

Comments Filter:

  • Rust is actually pretty good, but is anyone even programming anything with it?

    • Re:Rust (Score:5, Informative)

      by ArmoredDragon ( 3450605 ) on Sunday October 15, 2023 @05:05PM (#63927179)

      It's my go to language for like...everything I make, and for numerous reasons.

      Lots of really good tooling is written in it as well. Some I use all the time:
      ripgrep (think grep, only asyncronous and parallel, so it's much faster, and getting surrounding context doesn't break pipes like grep does)
      fd-find (same as find, but again async and parallel)
      exa (like ls -cl, only more opinionated and compact)
      du-dust (think du, only much faster at traversal, and you get a text based tree view so it's a lot more useful)
      bat (think cat with syntax highlighting, git integration, and optionally show non-printable characters)

      Somebody also wrote a complete drop-in replacement for gnu coreutils in rust, only better because it's far more portable and it's MIT licensed so no more of RMS's bullshit.

      • Fwiw I think exa is unmaintained now but eza is.
      • As a Rust developer, aren't you fighting the borrow checker all the time? Isn't that a bit masochistic? Does it even work out for complex code? Moreover, isn't the compilation speed utterly slow for any big project having a combined total of 10K+ lines? Why wouldn't you just use Go, for instance?

        • Re: Rust (Score:5, Insightful)

          by ArmoredDragon ( 3450605 ) on Sunday October 15, 2023 @11:57PM (#63927831)

          No, I'm not fighting the borrow checker. You just decide where you want your variables to live, and the rest of the dominos fall right into place.

          The borrow checker actually makes complexity easy to deal with. I'm used to users of other languages, especially C/C++, not liking the idea of mutating memory across threads. Or avoiding multithreading outright. This is because in most languages, including golang's goroutines, it's really easy to fuck it up. This is because instead of giving you an easy way to solve complexity, golang simply hides it, and C/C++ just assumes that you're incapable of making mistakes.

          In rust however, it's hard to fuck it up. You literally have to go way out of your way to cause a data race. In fact, merely using unsafe isn't enough. In literally every other language, your code will still compile if you use data structures that aren't intended to be used in parallel or aren't intended to be moved across threads. Instead you have to find out the hard way at runtime. In rust, the compiler, together with the borrow checker, guarantee that you can't fuck up data concurrency.

          That said, you can get as granular as you want with rust. You can quickly write code that isn't optimized but gets the job done and still runs reasonably fast and might have a few conditions that result in a crash.

          Or you can write code that is highly optimized, and is also guaranteed to never crash under any circumstances outside of a hardware fault or an OS fault. While I don't always heavily optimize, I do take the time to write code that handles all possible error states and never crashes. Either way, I spend a LOT less time debugging, and my code tends to (but not always) work right on the very first release.

          • One way in which I think about programming languages now is based on the expressiveness of their type system. This goes from say Javascript to Python to Go to Rust to Haskell to Idris to Coq. Along this spectrum, there is a tradeoff of flexibility for safety. I don't think that Rust is the final word in this spectrum by any means, and I also realize that there is a development-time cost to this safety. The counterargument is that if one wants crash-proof code, why shouldn't one go beyond Rust, further along

        • Re: (Score:2)

          by jma05 ( 897351 )

          Only initially. In my case, I am not even a system developer. I do use it like Go with extra steps. So why not just use Go? I didn't like many of the design choices in Go. Some of those complaints have been addressed since, but I have not bothered. I want an algebraic type system and macros. I chose it over OCaml, even though it is a better fit for me. When I want more ease of use, but still want performance (than small binaries, low memory, and safety), I opt for Julia.

          Compilation speed is mainly an issue

      • Re:Rust (Score:5, Interesting)

        by Beryllium Sphere(tm) ( 193358 ) on Monday October 16, 2023 @12:48AM (#63927873) Journal

        I looked into Rust out of my usual curiosity and wound up delighted.

        The composable iterators are fun, the Result type combined with the terminal question mark operator makes for concise and safe error checking, and I've been tempted to start a cult to worship the build/test/package management system. Yes, that's right, a Cargo cult.

        There's a lot more to Rust than the memory management features.

        The largest downsides IMO are the slow compiles and the learning curve.

      • Somebody also wrote a complete drop-in replacement for gnu coreutils in rust, only better because it's far more portable and it's MIT licensed so no more of RMS's bullshit.

        More portable? That sounds like bullshit.

        Also what's with the FSF hatred? Are really sore that you can't take the code for GNU ls and put your own proprietary shit on top of it?

      • RMS's bullshit is why there are essentially no proprietary forks of the Linux kernel, or the GNU userland. (Almost. Red Hat have finally figured out the loophole. And f them. But companies like Apple like permissive licenses like MIT and BSD because they can take what they want and give nothing back to the community.) RMS's bullshit is why share-alike licenses exist. RMS's bullshit is why there was a *nix userland available to put on top of Linus' college hobby project. He may not be popular, nor woke, but

    • Rust is actually pretty good, but is anyone even programming anything with it?

      Of course they are! Can't you tell with TFS being delivered via shout to the rooftops?

    • Nope

    • Re: (Score:2)

      by ebunga ( 95613 )

      Did you see the latest TIOBE index the other day? It's one place above Classic Visual Basic and a few spots behind FORTRAN. FORTRAN has growth, Rust is stagnant.

  • Only available as a Flatpak (Score:4, Informative)

    by jenningsthecat ( 1525947 ) on Sunday October 15, 2023 @04:44PM (#63927145)

    AFAICT, 'Resources' only comes as a Flatpak, which I avoid using. Too bad - it sounds interesting, but not interesting enough to go to the trouble of building it.

  • Rust (Score:5, Informative)

    by Anonymous Coward on Sunday October 15, 2023 @04:45PM (#63927151)

    This system monitor binary is only available as a snap and takes up 1.6gb of space.

    • Amazing.

    • Re: (Score:1)

      by Anonymous Coward

      Aren't snap users embarrassed by snap at this point? If not, why not?

    • Re: (Score:2)

      by vbdasc ( 146051 )

      SSD manufacturers approve of this.

    • Re:Rust (Score:4, Informative)

      by F.Ultra ( 1673484 ) on Monday October 16, 2023 @06:36AM (#63928281)
      Funny, but no. It is available either as source or as a 4MB flatpak.

      • Funny, but no. It is available either as source or as a 4MB flatpak.

        Plus 1.3GB of dependencies. Specifically (on my machine):

        org.gnome.Platform.Compat.i386//45 - 204.8MB
        org.freedesktop.Platform.GL.defaul//23.08 - 163.6MB
        org.freedesktop.Platform.GL.default//23.08-extra - 17.8MB
        org.freedesktop.Platform.openh264//2.2.0 - 944.3kB
        org.gnome.Platform.Locale//45 - 365.1MB
        org.gtk.Gtk3theme.Adwaita-dark/3.22 - 1.5kB
        org.gnome.Platform//45 - 370.5MB

        I'm sure if you're using a lot of GNOME-based flatpaks most of these would already be installed, but it still seems like a lot.

        • Funny, but no. It is available either as source or as a 4MB flatpak.

          Plus 1.3GB of dependencies. Specifically (on my machine):

          [...]

          Note that after installing GNOME Builder (per project recommendations), cloning Resources from Github, figuring out how to build the flatpak, figuring out how to install the flatpak, and figuring out how to install the dependencies, if the Resources binary is actually installed somewhere I can't find it and it didn't get registered in my application menus.

          Sigh. If you're not going to do the right thing and distribute .debs and .rpms, at least distribute source that can be built and installed in the normal

        • Ah, wasn't aware that flatpaks downloaded dependencies separately. Just saw that the package was 4MB on the download page (I don't use flatpak or any such other than the forced snap version of Firefox on Ubuntu).

  • Oh no... (Score:3)

    by fahrbot-bot ( 874524 ) on Sunday October 15, 2023 @04:59PM (#63927167)

    The System Monitor app Ubuntu comes with does an okay job of letting you monitor system resources and oversee running processes — but it does look dated...

    [rolls eyes and sighs]

  • Iâ(TM)ve seen this talked about a lot in the past day, but no mention or comparison to other tools that already do this, like System Monitoring Center or Mission Centerâ¦.

    Other than rust, what makes this one better?

  • btop (Score:1)

    by Anonymous Coward
    btop [github.com] is also written in Rust, and does the same thing (except GPU monitoring) but in the terminal.

    • Re: (Score:2)

      by ewhac ( 5844 )
      "Well, Actually..." No, btop is written in C++ (check the src directory under your link).

      There is a very primitive Rust utility called btop that is clearly little more than a proof of concept at this stage.

      Nevertheless, thanks for the link -- btop looks quite cool.

      • I think grandparent refers to bottom [github.com], which is a similar system monitor for the terminal which is indeed written in Rust.

  • CLI (Score:2, Interesting)

    by manu0601 ( 2221348 )
    But when I need this kind of tool to find why the system is on heavy load, I tend to have trouble running command line utilities like ps or top. How a slower GUI tool can help?

  • Another wheel reinvented (Score:3)

    by jvkjvk ( 102057 ) on Sunday October 15, 2023 @07:19PM (#63927439)

    So, here's why they are doing this:

    "but it does *look dated*... [T]he app's graphs and charts are tiny, compact, and lack the glanceability and granular-detail that similar tools on other systems offer."

    So, oh no, a "dated" interface! Glanceability! Granular-detail! Any other thing we can steal from Edward Tufte! After all, I'm sure there's so much new data on systems these days compared to before that this Must be Fixed Immediately.

    Is Rust destined to be a programming language to implement already tried and true applications with because the originals look "dated"? It appears to be so! This appears to be the fate of many programming languages before they fall away.

    I looked at a list of "24 awesome Rust programs" or something like it and most of them are derivatives, nothing new. Nothing on the surface that is enhanced by the "goodness of Rust". What I saw mostly? More and different Web server frameworks built with Rust. As if, as even. I think one way to tell if a language is failing is what is produced by it. When the best things it can produce are more intermediate layers that appear to be totally unnecessary. We are downing in intermediate layers that people just slap on another one because you need it for things to "work".

    The only thing I saw going for Rust is in academia, creating different facilities for the OS and see how they work together. Acknowledge current problems and break the system to try and fix them. But using it for stuff like a system monitor? I guess, if you need some practice in the language. Other than that, why? Are you querying system resources by some new Rust mechanisms? Are you doing some awesome data manipulation?

    Why did you make it? Why Rust? Who's going to use it? I guess if you can answer these three questions to your own satisfaction that's all that matters, but some people are going to make fun of you for your responses.

    • The only thing I saw going for Rust is in academia, creating different facilities for the OS and see how they work together.

      Rust is mostly good for systems-level programming, IMO. Stuff that must be rock solid, especially from a security perspective. It's a replacement for C and C++, basically, languages which aren't great for user applications anyway (excepting games that need maximum performance).

      I work on Android and we're seeing significant benefits from transitioning to Rust. System components that have been rewritten in Rust have high performance and so far have proven to be basically bulletproof thanks to Rust's inheren

  • So much wasted white space in this 'new rust app'.

  • If you try to compile it, it will fail if you have anything less then gtk-4.8. Ubuntu-22 has GTK-4.6 and to upgrade you've got to compile from source... Too much trouble for one program.

  • If it was written in Vala it wouldn't even be mentioned.

  • Not Rust but (Score:3)

    by Teun ( 17872 ) on Monday October 16, 2023 @09:19AM (#63928661)
    I don't see much wrong in how the KDE system monitor displays.

Slashdot Top Deals

Some people manage by the book, even though they don't know who wrote the book or even what book.

Close