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

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

Notices by LisPi (lispi314@udongein.xyz), page 2

  1. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Monday, 27-Apr-2026 05:00:14 JST LisPi LisPi
    in reply to
    • 【Ξnigmatico】:misskey:
    @enigmatico I think the argument is silly though.

    Why does knowing reality is false matter at all?

    The question should be whether you like it or not.
    In conversation about a month ago from udongein.xyz permalink
  2. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Saturday, 25-Apr-2026 03:58:29 JST LisPi LisPi
    in reply to
    • iced depresso
    • anna
    @icedquinn @mia @navi > dhall wanted to use it to avoid being reliant on github, but claimed latency was problematic. they went to github dependence.

    That's kind of a mismatch of purpose. Uneven zero-guarantees seeding should be used for high-latency/delay-tolerant purposes more so than anything that requires immediacy.

    > buttcoiners dropped out of ipfs when the NFT astroturfing failed.

    That's good they're not welcome.

    > its still a neat piece of tech but something about the tree model needs to be refactored for it to be useful (there are some attempts to make a new ipfs that does that; i'm not convinced they will succeed.)

    I see.
    In conversation about a month ago from udongein.xyz permalink
  3. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Saturday, 25-Apr-2026 03:43:09 JST LisPi LisPi
    • anna
    @mia @navi Last I checked IPFS' main problem was the lack of an anonymization layer.

    Has something annoying happened to it?
    In conversation about a month ago from udongein.xyz permalink
  4. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Saturday, 25-Apr-2026 02:53:00 JST LisPi LisPi
    • Rich Felker
    @ska @dalias I'm getting the vague impression you mean something different by "crowbar" than the prying tool I'm thinking of.
    In conversation about a month ago from udongein.xyz permalink
  5. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Friday, 24-Apr-2026 13:10:03 JST LisPi LisPi
    in reply to
    • 翠星石
    • prettygood
    • Poppy (Back from tha dead) :neofox_flag_trans:
    • david
    @radmin @Suiseiseki @prettygood @dps910 Cooperating or collaborating with authoritarians, being one of the "good ones", doesn't work.

    Anyone with basic skill at pattern recognition would've noticed it across the decades.
    In conversation about a month ago from gnusocial.jp permalink
  6. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Wednesday, 22-Apr-2026 16:11:13 JST LisPi LisPi
    Sometimes my brain has funny ideas.

    For about half an hour the other day I had the amusing misconception switching endianness would require full mirroring of the bytes.

    I'm also almost certain I've either posted or read something similar (of someone having this experience) on Fedi.
    In conversation about a month ago from udongein.xyz permalink
  7. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Wednesday, 22-Apr-2026 16:11:12 JST LisPi LisPi
    in reply to
    • LisPi
    While that's wrong and it's solely relevant for multi-byte values, I'm now wondering how weird it would be if that was actually the case and what could've led to such a thing happening for real.

    (The order is arbitrary, after all.)
    In conversation about a month ago from udongein.xyz permalink
  8. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Wednesday, 22-Apr-2026 11:23:11 JST LisPi LisPi
    in reply to
    • Rich Felker
    @dalias I'm thinking of say... a component with 8-bit or 16-bit wide access to another.

    The ordering of the pins which represents 0 and which represents 7 or 15 seems not to vary.

    Is that purely a consequence of most early designers speaking English and the whole left-to-right ordering progression?
    In conversation about a month ago from udongein.xyz permalink
  9. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Wednesday, 22-Apr-2026 10:55:20 JST LisPi LisPi
    in reply to
    • Rich Felker
    @dalias CPUs all seem to order their words the same way, which probably matters as far as mapped registers & electrical interconnection goes.

    But surely there were some early attempts that did not coordinate and ordered it differently?

    Or did pre-existing electrical standards lead to that just not happening in the first place?
    In conversation about a month ago from udongein.xyz permalink
  10. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Wednesday, 22-Apr-2026 10:51:41 JST LisPi LisPi
    • Rich Felker
    @dalias I'm vaguely curious why there was unanimity over word ordering.
    In conversation about a month ago from udongein.xyz permalink
  11. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Wednesday, 22-Apr-2026 02:52:33 JST LisPi LisPi
    in reply to
    • Rich Felker
    @dalias Isn't that something compiler-checkable in C now?
    In conversation about a month ago from udongein.xyz permalink
  12. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Wednesday, 22-Apr-2026 02:27:35 JST LisPi LisPi
    in reply to
    • Rich Felker
    @dalias > contractual constraints that analyzers can't see.

    How does that work?
    In conversation about a month ago from udongein.xyz permalink
  13. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Wednesday, 22-Apr-2026 01:58:06 JST LisPi LisPi
    in reply to
    • Tom (tired of the computer)
    • Rich Felker
    • Burger B Burger
    @dalias @burger @masklayer Generally one should always use such cables if it's an option, for exactly that reason.
    In conversation about a month ago from udongein.xyz permalink
  14. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Tuesday, 21-Apr-2026 07:54:50 JST LisPi LisPi

    Has there been a reckoning for the employees, pilots & so on that knew and did nothing?

    In conversation about a month ago from udongein.xyz permalink
  15. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Monday, 20-Apr-2026 11:06:48 JST LisPi LisPi
    in reply to
    • Rich Felker
    • anna

    @dalias @navi On regular files, yes.

    But if one builds FUSE filesystems for purposes similar to sysfs endpoints, that analogy breaks.

    And the index limit for mmap is just a uint64 (this lacks equivalent infinity semantics).

    One write use-case that comes to mind is a hash/checksum FUSE filesystem, where the input can indeed be of any length, from zero to infinite (though the trigger write to finish the digest will never happen in that last case).

    Such "special" files are typically non-seekable, too.

    (Yes, the ability of FUSE to serve as a poor man's 9p IPC interface is something I care about.)

    In conversation about a month ago from udongein.xyz permalink
  16. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Monday, 20-Apr-2026 10:36:40 JST LisPi LisPi
    in reply to
    • Rich Felker
    • anna
    @dalias @navi Does mmap cope with infinite streams?

    I'm just trying to think of reasons why read/write may be necessary.
    In conversation about a month ago from udongein.xyz permalink
  17. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Monday, 20-Apr-2026 10:24:59 JST LisPi LisPi
    • anna

    @navi It really is. Most of that stuff has no place in the kernel.

    For performance FUSE also have io_uring support, though it seems unavailable in Debian.

    In conversation about a month ago from udongein.xyz permalink
  18. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Saturday, 18-Apr-2026 07:14:21 JST LisPi LisPi
    in reply to
    • Haelwenn /элвэн/ :triskell:
    • iced depresso
    • [object Object]
    • anna

    @icedquinn @zzt @lanodan @mia @navi DIY supports autonomy, can't have that.

    Of course the only people that learn how to do things for themselves are <insert favorite horseman of the infocalypse>.

    In conversation about a month ago from udongein.xyz permalink
  19. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Friday, 17-Apr-2026 12:35:18 JST LisPi LisPi
    in reply to
    • Taggart :ifin:
    • Fluffy Kitty Cat
    • Christine Lemmer-Webber
    @fluffykittycat @mttaggart @cwebber Unsurprisingly, abusers don't like it when they can't isolate their victims anymore.
    In conversation about a month ago from udongein.xyz permalink
  20. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Wednesday, 15-Apr-2026 02:57:21 JST LisPi LisPi
    in reply to
    • Rich Felker

    @dalias What I see is that they still failed to armor the cabin properly so the users will still die horribly the next time a deer or moose decides to throw itself in front of them.

    The parts they armored are all the parts that don't matter because they were already engineered as a safe crumple zone.

    What they did do is increase its lethality against children and pedestrians. A complete failure of a design.

    In conversation about a month ago from udongein.xyz permalink
  • After
  • Before

User actions

    LisPi

    LisPi

    Hi, I'm Lispi, Lisp (Technomancer) Wizard (to eventually be).You might know me from @lispi314@mastodon.top I like Free Software, #Emacs and resilient computing a lot.I also like anime girls, animes with cute girls doing cute things and artwork with them too. Cute stories are good too.Some Pins:Software and Assumed Privilege, common problems: https://mastodon.top/@lispi314/111253066257920146Writing Privacy-preserving software & services 101: https://mastodon.top/@lispi314/110849018589421824#Kopimism #FreeSoftware #CommonLisp

    Tags
    • (None)

    Following 0

      Followers 0

        Groups 0

          Statistics

          User ID
          209694
          Member since
          6 Nov 2023
          Notices
          1012
          Daily average
          1

          Feeds

          • 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.