Software Engineer & DevOps Architect. Mbin contributor (and creator of the fork).

He/him 🇳🇱🏳️‍🌈

Mastodon - Matrix - Telegram - Homepage - Donate me

  • 0 Posts
  • 100 Comments
Joined 1 year ago
Cake day: June 20th, 2023
  • melroy@kbin.melroy.orgtoFediverse@lemmy.world•Mastodon gets a very good write-up in Stuff Magazine
    1·
    20 days ago

    Picture is just JPG. But like I said, it’s the activity pub message which I believe Lemmy can’t handle very well (or at all?). Its using a so called “attachment” attribute to the message. Here Mastodon also supports it: https://docs.joinmastodon.org/spec/activitypub/#properties-used

    Here an example of this:

    {"@context":["https:\/\/www.w3.org\/ns\/activitystreams","https:\/\/kbin.melroy.org\/contexts"],"id":"https:\/\/kbin.melroy.org\/m\/fediverse@lemmy.world\/t\/506689\/-\/comment\/4458544","type":"Note","attributedTo":"https:\/\/kbin.melroy.org\/u\/melroy","inReplyTo":"https:\/\/lemmy.ca\/post\/30865604","to":["https:\/\/www.w3.org\/ns\/activitystreams#Public","https:\/\/lemmy.ca\/u\/otter"],"cc":["https:\/\/lemmy.world\/c\/fediverse","https:\/\/kbin.melroy.org\/u\/melroy\/followers"],"sensitive":false,"content":"\u003Cp\u003EHere is the image.\u003C\/p\u003E\n","mediaType":"text\/html","source":{"content":"Here is the image.","mediaType":"text\/markdown"},"url":"https:\/\/kbin.melroy.org\/m\/fediverse@lemmy.world\/t\/506689\/-\/comment\/4458544","tag":[{"type":"Mention","href":"https:\/\/lemmy.ca\/u\/otter","name":"@otter@lemmy.ca"}],"published":"2024-10-13T14:36:34+02:00","contentMap":{"en":"\u003Cp\u003EHere is the image.\u003C\/p\u003E\n"},"attachment":[{"type":"Image","mediaType":"image\/jpeg","url":"https:\/\/kbin.melroy.org\/media\/12\/4f\/124f315062cb3fd1d8ae68e43c50805c64cf4d0b5ad5935837f9f9a1b55a15df.jpg","name":"Tips \u0026 Tricks to quit twitter","blurhash":"LdQ,2c~CS4-pMd$%R+af$MMyofRj","focalPoint":[0,0],"width":2480,"height":3354}],"image":{"type":"Image","url":"https:\/\/kbin.melroy.org\/media\/12\/4f\/124f315062cb3fd1d8ae68e43c50805c64cf4d0b5ad5935837f9f9a1b55a15df.jpg"}}
  • melroy@kbin.melroy.orgtoReddit@lemmy.world•Reddit is DOWN for thousands of users
    2·
    1 month ago

    What you all mention here are valid issues and concerts. The point is that everything you mentioned is related on how the ActivityPub protocol works, which inherently create this situation of semi-decentralizing in form of instances and federation. If we want to get rid of that, we need a fully different protocol that resolves all your issues in a decentralized way, which isn’t always scaling, or leaking the technical advances to do so. Or you could even argue that ActivityPub is currently de facto standard (which also includes Mastodon, etc).

    The only way to solve all the issues mentioned is to fully replace ActvityPub by another protocol. Which doesn’t relay on instances, and no DNS, and no global identity… Which are technically very challenging subjects on its own. Fediverse is well… federated, but not decentralized.

    Disclaimer: I’m the developer of Mbin project. And previous contributor of kbin.

  • melroy@kbin.melroy.orgtoReddit@lemmy.world•Reddit is DOWN for thousands of users
    1·
    1 month ago

    impression the devs and admins were really interested in a poor man’s Reddit

    No, not at all. It’s just that sh*t things happens and instances goes down. Remember that kbin (and now Mbin) is development by software engineers doing their job in the free time. And instance owners also. Most don’t get paid for all this work, and if they do… we are talking about 5 dollar per month.

    At the same time devs also have families, full time job and other things. While I heard from the Lemmy dev is able to full time work on Lemmy now.

  • melroy@kbin.melroy.orgtoLinux@programming.dev•Linux boots in 4.76 days on the Intel 4004
    171·
    1 month ago

    Here you go:

                       -`
                  .o+`                 user@intel4004
                 `ooo/                 ----------------
                `+oooo:                OS: Arch Linux BCD oriented
               `+oooooo:               Host: Intel 4004 @ 740 KHz
               -+oooooo+:              Kernel: 0.0.1-custom
             `/:-:++oooo+:             Uptime: 3 hours, 12 mins
            `/++++/+++++++:            Packages: 3 (pacman)
           `/++++++++++++++:           Shell: sh 0.5
          `/+++ooooooooooooo/`         CPU: Intel 4004 (4-bit) @ 740 KHz
         ./ooosssso++osssssso+`        Memory: 0.64 KB / 8 KB
        .oossssso-````/ossssss+`       Storage: None (Using Paper Tape)
       -osssssso.      :ssssssso.      GPU: None (Terminal Only)
      :osssssss/        osssso+++.     Display: None (TTY Only)
     /ossssssss/        +ssssooo/-     Network: None (Hand-delivered punch cards)
   `/ossssso+/:-        -:/+osssso+`
  `+sso+:-`                 `.-/+oso:
 `++:.                           `-/+/
 .`                                 `/
  • melroy@kbin.melroy.orgtoLinux@programming.dev•20 years later, real-time Linux makes it to the kernel - really
    4·
    2 months ago

    I got this back from ChatGPT (most likely false info!):

    ChatGPT response (you have been warned)

    The compromise for integrating PREEMPT_RT into the Linux mainline kernel, including the handling of printk, required several changes and concessions over time. These compromises made it possible to finally integrate real-time (RT) capabilities while maintaining the overall philosophy and structure of the Linux kernel. Key Compromises Made:

    1. Soft-Real-Time Focus:

      One of the biggest compromises was accepting that Linux would focus on soft real-time capabilities instead of hard real-time guarantees. This was crucial for widespread acceptance in the mainline kernel, as hard real-time guarantees were too difficult to meet without significant changes that would have disrupted the kernel’s general-purpose use cases. PREEMPT_RT was designed to offer deterministic behavior with reduced latencies, but it doesn’t provide the strict guarantees of traditional hard real-time systems like VxWorks or QNX.

    2. printk Latency Handling:

      Non-blocking printk: One compromise involved updating printk to avoid long blocking during logging operations. It was changed to be more asynchronous, reducing the impact on real-time scheduling. Deferred printing: Another approach was to defer the actual printing of log messages to avoid introducing large latencies in time-critical paths. The goal was to prevent printk from stalling critical tasks, especially those with real-time priority.

    3. Voluntary Preemption Points:

      Voluntary preemption was introduced, allowing kernel code paths to insert preemption points that allow the scheduler to preempt running tasks, improving latency. However, this does not guarantee immediate preemption, which is another compromise compared to true hard real-time systems. These preemption points had to be carefully placed to balance performance and responsiveness without destabilizing the general-purpose kernel.

    4. Threaded Interrupts:

      Another significant compromise was the conversion of hard IRQs (interrupts) into threaded interrupts. While this allows real-time tasks to take precedence over hardware interrupts (which would traditionally have a higher priority), it involves some overhead and performance trade-offs. Not all interrupts could be threaded easily, and this change required reworking many drivers to ensure that they were compatible with threaded interrupts.

    5. Preemptible Spinlocks:

      Spinlocks in the kernel traditionally prevent preemption. To enable real-time preemption, spinlocks were made preemptible, allowing real-time tasks to preempt even code holding spinlocks. This change wasn’t trivial, as it involved significant reworking of kernel locking mechanisms to ensure the system remained stable and avoided deadlocks, without degrading performance in non-real-time scenarios.