[HN Gopher] Dtui - TUI for introspecting the state of the system...
___________________________________________________________________
Dtui - TUI for introspecting the state of the system/session dbus
Author : diggan
Score : 129 points
Date : 2024-07-23 19:02 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| metadat wrote:
| No screenshots.. that's unfortunate for a TUI app on the front
| page of HN :)
|
| The odds I'll try it without having any idea of what it'll be are
| low. And this one might be really interesting and innovative!
|
| Edit: Ooh I see it now, thanks @dodos! My mistake, it didn't load
| before. Please flag this embarrassment :)
| dodos wrote:
| I can see a screenshot in the readme.
| 1oooqooq wrote:
| dbus and rarely used systemd features (like trusting values from
| BIOS to create files in your fs root) included for vms but left
| laying around on baremetal builds will be the major attack
| vectors on linux for years to come.
|
| upvoted as we need as much visibility on all this mess.
| aumerle wrote:
| Wave your hands harder, you might achieve lift-off.
| creshal wrote:
| It's not just a systemd thing, all the sandboxing/apppification
| frameworks (flatpak, snap, etc) heavily rely on dbus as their
| primary way of communicating with the sandboxed apps, and are
| constantly adding new dbus interfaces. It is the biggest and
| most obvious attack surface for sandbox escapes, and the more
| opaque dbus is, the harder it is to assess their risks.
| progval wrote:
| > like trusting values from BIOS to create files in your fs
| root
|
| What are you referring to? And what's wrong with trusting the
| BIOS for that specific thing when you already trust it for
| everything else?
| nonlogical wrote:
| Looks neat! It would be really nice if someone makes a fuse FS
| that allows exploring/interacting with dbus, in keeping with
| everything is a file UNIX philosophy.
| integricho wrote:
| Is it normal for all rust projects to have sooo many
| dependencies? I tried scrolling through them to see what was used
| for the TUI itself, and was amazed by a neverending list of
| dependencies. Reminds me of the JS dependency hell that exists..
| I somehow feel this is DRY gone in the wrong direction.
| Groxx wrote:
| Relatively.
|
| tbh I think it's a natural outcome of any system where it's
| easy and reliable to add a dependency......
|
| .. and where there isn't any ongoing feedback about the costs
| associated with doing so (binary side, build time, etc) so you
| don't notice things slowly getting worse. It's just "rust
| builds are slow" not "why does this one thing I don't use take
| two minutes".
|
| I'm not convinced the large number is actually a problem, but
| the lack of feedback definitely is.
| creshal wrote:
| > I'm not convinced the large number is actually a problem
|
| Supply chain security always matters, and the more random
| dependencies you introduce, the worse it gets.
| _flux wrote:
| But are the dependencies random?
| creshal wrote:
| If you have the time, I invite you to take the project's
| cargo lock file and analyse for every single one of them
|
| - what does it to justify its inclusion
|
| - who wrote it
|
| - who else has commit access to the repositories
|
| - how do these people secure their git access
|
| - are these people susceptible to state actor pressure
|
| - will these people never in the future add new
| maintainers who are moles/blackmailable/have sloppy
| security hygiene
| _flux wrote:
| I mean just this solely person already could tick all
| those boxes or I don't have a way to access that
| information.
|
| By glancing the direct dependencies of this project it is
| pretty easy to see why they have been selected. Yes, it
| would be more prudent to check all transitive
| dependencies as well, in addition to _reviewing their
| source code_ , but frankly that's just too much effort.
| Does this mean the dependencies are random?
|
| But it does seem like it would be cool to have a tool to
| collect as much of that information as possible.
| Groxx wrote:
| There also can _and should_ be mechanical checks on
| libraries, to reduce the number of things that need heavy
| ongoing human review.
|
| E.g. if a library provides a pure function, does it
| matter if the owner changes? It's still pure. If it
| becomes _not_ -pure, yes that's immediately concerning,
| but in the meantime its ability to do anything nefarious
| is infinitely smaller than most current module systems
| allow, and your review-budgets should probably be spent
| elsewhere.
| _flux wrote:
| Are you looking at the direct dependencies? Because that list
| isn't neverending:
| https://github.com/Troels51/dtui/blob/main/Cargo.toml
|
| For TUI it uses ratatui.
|
| The transitive dependencies can get quite large, though! I've
| never found the direct dependencies of any package to have
| superfluous dependencies (perhaps I haven't looked carefully
| enough?); they are always seem to be useful or easily provide
| functionality users expect to see, such as nice command line
| options and nice usage for them.
| integricho wrote:
| Yes, but one cannot count transitive dependencies as if they
| are not your dependencies. They are still all needed to build
| your project, thus they are effectively yours as well. I find
| the pure number of dependencies involved worrying tbh (and
| this is not strictly related to your project, but if this is
| the case throughout the whole rust ecosystem, then it is a
| global problem).
| codr7 wrote:
| I second that reaction to many Rust projects I've compiled.
| Anything JS these days tends to look similar.
|
| I think part of the issue is that it's just so easy to get
| a package included in "the" central registry, and for many
| programming adepts that's like a badge of honor. So you get
| many tiny libraries, and many turn into balls of mud. Then
| they learn about reuse and happily pull in all dependencies
| they can think of.
|
| In Rust there seems to be a tendency to keep stuff out of
| the standard library, so everyone depends on their favorite
| solutions to everyday problems, which depends on their
| favorites and so on.
|
| But it is a problem, because somewhere along the line one
| of those indirect dependencies is going to start
| conflicting with something else in the graph; the bigger
| the graph, the more conflicts.
|
| And finally risk, because if a major indirect dependency
| goes belly up, that may well cause serious problems for
| your direct dependencies, which then makes it your problem.
| Also directly related to graph size.
| dagurp wrote:
| I feel like the trend is going the other way in modern JS
| codr7 wrote:
| God I hope so!
| technojamin wrote:
| I've definitely seen "zero-dependency" as a selling point
| for several packages in the past few years, that's always
| very refreshing.
| giyanani wrote:
| > But it is a problem, because somewhere along the line
| one of those indirect dependencies is going to start
| conflicting with something else in the graph; the bigger
| the graph, the more conflicts.
|
| Rust is statically compiled, so it's possible to have
| different versions of the same dependency in your
| dependency graph without build issues. Yes, that can lead
| to binary bloat and slower build times and some related
| problems, but in practice the compiler is good at dealing
| with those issues.
| _flux wrote:
| Yes, there is trust involved in assuming that others also
| include useful dependencies. So far I have not seen it
| being brought up as a concrete example that there is a
| _single_ useless dependency in the project. Seems like it
| should be easy to show, as between the lines there seems to
| be the claim that there are many.
|
| I agree that having a great number of sources needed to
| build your program is worrying from the point of supply
| chain attack, but at the same time most developers enjoy
| focusing on the core problem they are solving, not problems
| that others have already solved for them.
|
| Vendoring dependencies might be a partial solution, though
| practically speaking it seems locking dependencies via git
| hashes would be effectively the same.
| diath wrote:
| ...and the build folder adds up to 700MB, that's quite grim for
| a program like this.
| jeroenhd wrote:
| Depends on what you consider "many dependencies". Does this
| tool _need_ async tasks, a code generator for argument parsing,
| variable log level tracing hooks and JSON logging output?
| Probably not. A lot of this stuff is just developer
| convenience.
|
| I've seen other projects just include entire third party
| software repositories into their source tree rather than use a
| dependency manager, which works, I guess, but doesn't make the
| dependency tree all that obvious.
|
| When I use languages that don't have an easy dependency
| manager, I often still try to use common libraries, but I find
| that there are fewer easy dependencies. In C, I would just not
| bother with async I/O rather than import a library that makes
| it easy to do. I would use a shitty "works-for-me" string
| replace rather than a compliant parser for formats like JSON or
| XML. I'd steal some random SHA code rather than link to a
| library.
|
| I don't think this is that much of a problem as long as you're
| somewhat conservative in the kinds of dependencies you add.
| There's a trade-off between doing something yourself (and thus
| correctness) or stealing/vendoring the source code, and making
| use of a thriving library ecosystem.
| resonious wrote:
| Yup, Rust as an ecosystem feels very similar to JS.
|
| Part of this might be because some core Rust facilities are
| lacking. For example, many projects use the "anyhow" library
| for error handling. It could also be because having a good
| package manager makes it so easy to add dependencies, and that
| reduced friction just naturally makes people tend to add many
| dependencies.
| giyanani wrote:
| "Lacking" implies it's an unintentional deficiency.
|
| Rust has deliberately taken a "batteries not included"
| approach due to learned experiences in python, where many
| std-lib packages are basically abandoned/not recommended
| anymore.
|
| This gives the ecosystem time to develop better approaches to
| things, rather than ossifying around the initial
| implementation.
|
| Yes, it does lead to a larger set of dependencies, but some
| of the most common packages (including anyhow) were written
| and are maintained by members of the rust lang
| organization/team itself.
| WesolyKubeczek wrote:
| When Rust's ecosystem was booming, the JS/npm way of a myriad
| small libraries was viewed as superior. I think that there have
| been dozens of articles pre-left-pad about why it is good and
| why it's the future.
|
| I don't quite blame them, remembering how Python's ecosystem
| tried to mimic Java back in the day, how PHP tried, consciously
| or not, to do the same.
|
| I'm just wondering what the 2024-2025 dominant fad is going to
| look like.
| steveklabnik wrote:
| Crates.io never had the behavior that led to left-pad, so it
| didn't really change any opinions here.
|
| Small dependencies are not inherently good. Large
| dependencies are not inherently bad.
| troels51 wrote:
| Author here: Great to see people be interested in my small
| project! I am currently working on getting method calls and
| properties working
| synergy20 wrote:
| I use 'busctl tree', 'dbus-monitor', 'dsub-send' etc, so far
| worked well
| bandie91 wrote:
| it can not call dbus methods. can it? how is it better than say
| "qdbus" or dbus-call? apart of course from the TUI vs CLI aspect?
| troels51 wrote:
| It can't yet. That's currently what I'm working on. I am not
| trying to make something better than those tools, this is more
| like a TUI version of dfeet or d-spy
| rjzzleep wrote:
| Not fully on topic but does any one know why people use seatd
| over logind? I noticed that when you use swaymsg exit and you
| exit the window manager to go back to sddm I noticed that the
| logind session is not closed. Why is that and how should that be
| fixed ?
___________________________________________________________________
(page generated 2024-07-24 23:13 UTC)