Announcement

Collapse
No announcement yet.

Busd Taking Shape As A D-Bus Broker Written In Rust

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Vorpal
    replied
    An interesting talk (though hard to watch, stage presence was not his strong suit). It seems like a good option to use Rust for this, since the dbus broker is privileged and talks to unprivileged processes. It thus forms a security barrier.

    I'm a bit surprised by the choice of tokio, since zbus uses async-std instead. I wonder what the reason for tokio here was. I also wonder how the work stealing of tokio will work out for battery usage (my understanding is that work stealing scheduling works well when the system is almost fully loaded or very lightly loaded, but has issues with in between where threads compete for work to do causing un needed churn).
    ​​​
    I look forward to seeing how this evolves.
    ​​

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by zaps166 View Post
    Another (third) software doing the same thing with the same speed, but more complicated compilation?
    true. I hate how hard it is to build busd

    cd code
    git clone https://github.com/dbus2/busd.git
    OR
    wget https://github.com/dbus2/busd/archiv...s/0.3.1.tar.gz
    <extract if needed>
    cd busd
    cargo build --release
    install ...

    Leave a comment:


  • intelfx
    replied
    Originally posted by bkdwt View Post
    Have you noticed that Rust fans only know how to rewrite pieces of software and rarely create something new?
    No, we didn't. Not many people are capable of noticing things that are not true.

    Leave a comment:


  • zaps166
    replied
    Another (third) software doing the same thing with the same speed, but more complicated compilation?

    Leave a comment:


  • Quackdoc
    replied
    will try this at some point, if when I swap over nothing breaks, that would be a succsess in my books.

    Leave a comment:


  • elduderino
    replied
    Originally posted by archkde View Post
    how do "terrible CPU usage" and "just as fast" go together?
    Sometimes you do sacrifice CPU at the alter of going faster. On such case is using polling instead of interrupts for higher throughput on IO. Another is to let multiple threads do work that might overlap a little bit (say query a cache and query a db at the same time, throwing the slower one away). Maybe mipmap'ing an image into different LOD levels even though you only need one immediately so that you can switch while zooming. So across disciplines there are cases.

    The case where I think there is work still to be done here is in thread/pool/task/async type things. How you go from 0 workers to 1 worker (extremely common) can often be wasteful. (Do you wake up all threads saying I have a job for you? Do you round robin a fixed pool? Do you work steal? Do you create n_cpu threads at startup? Do you create a heartbeat thread? etc)

    Anyway, this is why we should be profiling and using that profiler data to have meaningful conversations about software implementation.

    Leave a comment:


  • rmfx
    replied
    People are not tired of moaning about rust ?
    Just learn the language and stop being offended.
    Rust is C 2.0, you like it or not. They will never state it that clearly, but that's the case.
    It's the second system language in the kernel, the us gov wants it more and more, it's not going to go away, so jump in or be left behind.

    Leave a comment:


  • archkde
    replied
    Originally posted by mobadboy View Post
    I love how they don't show the (terrible) memory usage or the (terrible) CPU usage. It can be just as fast as dbus, but you can't get the same memory/CPU footprint from a managed language as you can with trusty, safe C. I remember the days when very clever programmers would even rely on assembly to optimize their programs. Now you have these snowflakes even pushing back against that or, worse, replacing the well-crafted assembly with (EW) Rust.

    Rust is at least nice because it segments all of the non-coders into one group.
    Rust is not a managed language, and how do "terrible CPU usage" and "just as fast" go together?

    Leave a comment:


  • archkde
    replied
    Originally posted by bkdwt View Post
    Have you noticed that Rust fans only know how to rewrite pieces of software and rarely create something new?
    Have you noticed that C fans only know how to rewrite pieces of software and rarely create something new? (This comment brought to you by dbus-broker.)

    Leave a comment:


  • Errinwright
    replied
    Originally posted by ahrs View Post

    Rust is a systems programming language and it has an "unsafe" escape hatch that allows for all the same weird tricks you can do in C, including playing with raw/dangling pointers, etc. It can be just as fast as a good implementation in C but obviously needs to be similarly optimised in order to do so.
    Even unsafe Rust undergoes equivalent safety-checks [but not all apply], making it significantly safer than C irrespective.

    Leave a comment:

Working...
X