GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Blurry Moon (sun@shitposter.world)'s status on Saturday, 22-Feb-2025 23:57:11 JST Blurry Moon Blurry Moon
    Linus finally stepped in on the kernel mailing list and told Christoph to shut up. He finally is saying something and that is good.

    He also said this though:

    > So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise
    that they don't *have* to deal with Rust.

    I don't have a citation but I remember reading last year complaints from C developers that they were being harassed by Rust maintainers to document their code better and stop making so many changes because it added a lot of difficulty to maintaining their Rust bindings and they didn't like the work of having to figure out how to safely use the APIs by having to read and understand the C code. There are various technical and historical details for why the C part operates like this.

    So while it appears that Christoph is being unreasonable I have this little voice in the back of my head that reminds me of working with people and being told that I wouldn't have to change my process etc. And then, slowly, more and more soft demands are placed on you and your time, if you don't do it you're called not a team player, holding back progress, etc. And you end up in fact having to do more work to accommodate these soft demands.

    Maybe this is just the reality of working in a team, but it doesn't change the fact that the claim is disingenuous, you will be expected to do more work, your work will be materially changed by having to work with these other people doing something you have no interest in, that none of this would be happening if you didn't have to accommodate this thing you don't care about that you were promised wouldn't affect you.

    But this is all speculation. If Linus does what he says then it's not a problem. I would hold him to that and bring it up if people came to me with soft demands that I change my process. I would also file a code of conduct complaint if the person making demands decided to get people to dogpile me on social media, or put my name on a secret blacklist that they quietly give to new contributors to pre-spoil my working relationship with them.
    In conversation about 8 months ago from shitposter.world permalink
    • lainy and Johnny Peligro like this.
    • Embed this notice
      Blurry Moon (sun@shitposter.world)'s status on Saturday, 22-Feb-2025 23:59:50 JST Blurry Moon Blurry Moon
      in reply to
      The most important thing, or maybe the only important thing though, is that it felt before like Linus was fence-sitting and now he's actually saying how it's going to be, which is great and the right thing for BDFL.
      In conversation about 8 months ago permalink
      Johnny Peligro likes this.
    • Embed this notice
      Blurry Moon (sun@shitposter.world)'s status on Sunday, 23-Feb-2025 01:41:33 JST Blurry Moon Blurry Moon
      in reply to
      • Ignas Kiela
      @ignaloidas I am not going to say that there's no badly designed interfaces in there but the issue seems to be that everything in the kernel is in C where you have to manage a lot of stuff yourself because of decades of design decisions you can't change; and written without strongly opinionated abstraction because they can't assume how it will be used in other parts of the kernel. Here is a post by an Asahi kernel Rust dev talking about it:

      https://vt.social/@lina/113056457969145576
      In conversation about 8 months ago permalink

      Attachments

      1. No result found on File_thumbnail lookup.
        Asahi Lina (朝日リナ) // nullptr::live (@lina@vt.social)
        from Asahi Lina (朝日リナ) // nullptr::live
        I think people really don't appreciate just how incomplete Linux kernel API docs are, and how Rust solves part of the problem. I wrote a pile of Rust abstractions for various subsystems. For practically every single one, I had to read the C source code to understand how to use its API. Simply reading the function signature and associated doc comment (if any) or explicit docs (if you're lucky and they exist) almost never fully tells you how to safely use the API. Do you need to hold a lock? Does a ref counted arg transfer the ref or does it take its own ref? When a callback is called are any locks held or do you need to acquire your own? What about free callbacks, are they special? What's the intended locking order? Are there special cases where some operations might take locks in some cases but not others? Is a NULL argument allowed and valid usage, or not? What happens to reference counts in the error case? Is a returned ref counted pointer already incremented, or is it an implied borrow from a reference owned by a passed argument? Is the return value always a valid pointer? Can it be NULL? Or maybe it's an ERR_PTR? Maybe both? What about pointers returned via indirect arguments, are those cleared to NULL on error or left alone? Is it valid to pass a NULL ** if you don't need that return pointer?
    • Embed this notice
      Ignas Kiela (ignaloidas@not.acu.lt)'s status on Sunday, 23-Feb-2025 01:41:35 JST Ignas Kiela Ignas Kiela
      in reply to

      @sun@shitposter.world I don't have a citation but I remember reading last year complaints from C developers that they were being harassed by Rust maintainers to document their code better and stop making so many changes because it added a lot of difficulty to maintaining their Rust bindings and they didn't like the work of having to figure out how to safely use the APIs by having to read and understand the C code. There are various technical and historical details for why the C part operates like this.Tbh that's just bad maintainership. Rust people try to write their interfaces in a way that you can't misuse them, and when trying to do that, they find code that's hard to impossible to not misuse, and the maintainers just don't want to fix their shit.

      In conversation about 8 months ago permalink
      Johnny Peligro likes this.
    • Embed this notice
      Ignas Kiela (ignaloidas@not.acu.lt)'s status on Sunday, 23-Feb-2025 01:44:20 JST Ignas Kiela Ignas Kiela
      in reply to

      @sun@shitposter.world yeah, but managing you can abstract over

      you can't abstract over "the only reason this doesn't leak in other drivers is because it leaks on shutting down" https://vt.social/@lina/113051677686279824

      In conversation about 8 months ago permalink

      Attachments

      1. No result found on File_thumbnail lookup.
        Asahi Lina (朝日リナ) // nullptr::live (@lina@vt.social)
        from Asahi Lina (朝日リナ) // nullptr::live
        I'm going to describe the drm_sched mess because honestly, I think it needs to be documented outside of the mailing list arguments which are honestly painful to read. A "fence" is just an object that can be signaled, waited on, and have callbacks attached to it. It is used to signal completion of some process between different pieces of code (some GPU work finishing might trigger more GPU work or a frame to be displayed on the screen). The concept behind drm_sched is relatively simple. You create a scheduler (ignoring entity/rq stuff, I use it 1:1 with schedulers). Then you create jobs, which might depend on other things via attached fences. When you push a job into the scheduler, you transfer ownership of the job into it, and receive a scheduler fence representing job completion. The scheduler's job is to wait on the dependency fences of the oldest pending job, then once they signal ask the job whether it is ready to run (which might return another fence to wait on for busy hardware resources), then once that is ready, actually call the job run callback. That callback returns another fence representing hardware completion (the "hw fence"). The scheduler then arranges for that fence, when signaled, to also signal the job completion fence that it associated with the job (the "job completion fence"). The scheduler can run multiple queued jobs in parallel. As jobs complete in the hardware, they signal their hw fences, and the scheduler cleans up and frees the job objects.
      Blurry Moon likes this.
    • Embed this notice
      Blurry Moon (sun@shitposter.world)'s status on Sunday, 23-Feb-2025 01:47:28 JST Blurry Moon Blurry Moon
      in reply to
      • Ignas Kiela
      @ignaloidas I think that the problems can be categorized into:

      1. design decisions largely based around having to manually manage resources across primitive building-block APIs, these APIs complexity are various mixes of "not ideal" and "necessary"
      2. objectively bad APIs
      In conversation about 8 months ago permalink
      Johnny Peligro likes this.
    • Embed this notice
      Blurry Moon (sun@shitposter.world)'s status on Sunday, 23-Feb-2025 01:55:16 JST Blurry Moon Blurry Moon
      in reply to
      • Ignas Kiela
      @ignaloidas I think the reason that greg and linus speak in aggression and platitudes about this when forced to talk about it at all is because they all know the truth, which is that an extremely large, extremely old, and extremely decentralized open source C project doesn't have the code discipline to be interfaced with Rust without confronting historic bad decisions that should be rewritten but this would entail huge cost and risk. This directly and obviously conflicts with claims that Rust, which needs consistency and quality to make a safe shim, won't change anything, and forces out in the open issues with the perceived "quality" of the kernel.
      In conversation about 8 months ago permalink
      Johnny Peligro likes this.
    • Embed this notice
      Ignas Kiela (ignaloidas@not.acu.lt)'s status on Sunday, 23-Feb-2025 01:57:03 JST Ignas Kiela Ignas Kiela
      in reply to

      @sun@shitposter.world yeah, I feel like with rust, all of the worse code will end up getting exposed, and I guess some people just don't want that

      In conversation about 8 months ago permalink
      Blurry Moon and Johnny Peligro like this.
    • Embed this notice
      Blurry Moon (sun@shitposter.world)'s status on Sunday, 23-Feb-2025 02:02:16 JST Blurry Moon Blurry Moon
      in reply to
      • Ignas Kiela
      @ignaloidas Yeah, I think the complaints of the Rust devs seem to be true whenever I look at it. Sometimes I get hung up on a tangential issue to a topic. In this case, Rust may be good for the kernel long-term but I am really bugged by people saying "it won't affect you" when I can tell it will.
      In conversation about 8 months ago permalink
      Johnny Peligro likes this.
    • Embed this notice
      Pete Zaitcev (zaitcev@shitposter.world)'s status on Sunday, 23-Feb-2025 02:17:41 JST Pete Zaitcev Pete Zaitcev
      in reply to
      • Ignas Kiela
      @sun @ignaloidas so basically Rust is like gay marriage
      In conversation about 8 months ago permalink
      Blurry Moon and Johnny Peligro like this.
    • Embed this notice
      نبي الحيوان (mono@shitposter.world)'s status on Sunday, 23-Feb-2025 04:37:47 JST نبي الحيوان نبي الحيوان
      in reply to
      • Ignas Kiela
      @sun @ignaloidas that guy (hector martin aka asahi lina) is a huge fag who tried to cancel RMS
      In conversation about 8 months ago permalink
      Blurry Moon and Johnny Peligro like this.
    • Embed this notice
      Johnny Peligro (mischievoustomato@tsundere.love)'s status on Sunday, 23-Feb-2025 04:43:21 JST Johnny Peligro Johnny Peligro
      in reply to
      • Zero :zt_think: :artix:
      • Ignas Kiela
      @sun @ignaloidas what annoys me from this person is that they said that they found a lot of bugs or wrong stuff in the kernel C code and... did nothing beyond saying they could easily fix them "in rust".

      cc @zero you made a post about this, I remember
      In conversation about 8 months ago permalink
    • Embed this notice
      Johnny Peligro (mischievoustomato@tsundere.love)'s status on Sunday, 23-Feb-2025 04:44:13 JST Johnny Peligro Johnny Peligro
      in reply to
      • Zero :zt_think: :artix:
      • Ignas Kiela
      @zero @ignaloidas @sun do you have the screencaps?
      In conversation about 8 months ago permalink
    • Embed this notice
      Zero :zt_think: :artix: (zero@strelizia.net)'s status on Sunday, 23-Feb-2025 04:44:14 JST Zero :zt_think: :artix: Zero :zt_think: :artix:
      in reply to
      • Ignas Kiela
      • Johnny Peligro
      @mischievoustomato @ignaloidas @sun yes
      In conversation about 8 months ago permalink
    • Embed this notice
      Blurry Moon (sun@shitposter.world)'s status on Sunday, 23-Feb-2025 04:45:08 JST Blurry Moon Blurry Moon
      in reply to
      • Zero :zt_think: :artix:
      • Ignas Kiela
      • Johnny Peligro
      @mischievoustomato @ignaloidas @zero it was in other people's code, the other people have ownership over that code so he can't unilterally fix it.
      In conversation about 8 months ago permalink
    • Embed this notice
      Johnny Peligro (mischievoustomato@tsundere.love)'s status on Sunday, 23-Feb-2025 04:45:36 JST Johnny Peligro Johnny Peligro
      in reply to
      • Zero :zt_think: :artix:
      • Ignas Kiela
      @sun @ignaloidas @zero what about *reporting*. All we know is that they just found shit but did nothing beyond shill rust
      In conversation about 8 months ago permalink
    • Embed this notice
      Blurry Moon (sun@shitposter.world)'s status on Sunday, 23-Feb-2025 04:46:29 JST Blurry Moon Blurry Moon
      in reply to
      • Zero :zt_think: :artix:
      • Ignas Kiela
      • Johnny Peligro
      @mischievoustomato @ignaloidas @zero it's less like "I found a bug" and it's more like "you designed this completely wrong and it is making everything worse for everyone else"
      In conversation about 8 months ago permalink
      Johnny Peligro likes this.
    • Embed this notice
      Johnny Peligro (mischievoustomato@tsundere.love)'s status on Sunday, 23-Feb-2025 04:47:06 JST Johnny Peligro Johnny Peligro
      in reply to
      • Zero :zt_think: :artix:
      • Ignas Kiela
      @sun @ignaloidas @zero they literally said they found bugs
      In conversation about 8 months ago permalink
    • Embed this notice
      Blurry Moon (sun@shitposter.world)'s status on Sunday, 23-Feb-2025 04:48:08 JST Blurry Moon Blurry Moon
      in reply to
      • Zero :zt_think: :artix:
      • Ignas Kiela
      • Johnny Peligro
      @mischievoustomato @ignaloidas @zero I don't know then, marcan was probably just building a dossier to attack people then
      In conversation about 8 months ago permalink
      Johnny Peligro likes this.
    • Embed this notice
      :blank: (i@declin.eu)'s status on Sunday, 23-Feb-2025 04:48:22 JST :blank: :blank:
      in reply to
      • Zero :zt_think: :artix:
      • Ignas Kiela
      • Johnny Peligro
      @mischievoustomato @ignaloidas @sun @zero and the maintainers literally said get the fuck out of my directory with your patches
      In conversation about 8 months ago permalink
      Blurry Moon likes this.
    • Embed this notice
      Blurry Moon (sun@shitposter.world)'s status on Sunday, 23-Feb-2025 04:48:36 JST Blurry Moon Blurry Moon
      in reply to
      • Zero :zt_think: :artix:
      • Ignas Kiela
      • :blank:
      • Johnny Peligro
      @i @ignaloidas @zero @mischievoustomato really? totally unacceptable then
      In conversation about 8 months ago permalink
    • Embed this notice
      Johnny Peligro (mischievoustomato@tsundere.love)'s status on Sunday, 23-Feb-2025 04:49:22 JST Johnny Peligro Johnny Peligro
      in reply to
      • Zero :zt_think: :artix:
      • Ignas Kiela
      • :blank:
      @i @ignaloidas @sun @zero huh? i dont remember this happening after the whole thing
      In conversation about 8 months ago permalink
    • Embed this notice
      :blank: (i@declin.eu)'s status on Sunday, 23-Feb-2025 04:53:17 JST :blank: :blank:
      in reply to
      • Zero :zt_think: :artix:
      • Ignas Kiela
      • Johnny Peligro
      @mischievoustomato @ignaloidas @sun @zero don't worry, the bugs only happen if someone were to use their code wrong, like in a binding without an improved interface
      In conversation about 8 months ago permalink
      Johnny Peligro likes this.
    • Embed this notice
      Johnny Peligro (mischievoustomato@tsundere.love)'s status on Sunday, 23-Feb-2025 04:53:29 JST Johnny Peligro Johnny Peligro
      in reply to
      • Zero :zt_think: :artix:
      • Ignas Kiela
      • :blank:
      @i @ignaloidas @sun @zero alright
      In conversation about 8 months ago permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.