Imnebuddy - pronounced “I am any buddy”

AuDHD, techie, commie nerd

  • 10 Posts
  • 30 Comments
Joined 5 years ago
cake
Cake day: March 17th, 2021

help-circle


  • Imnebuddy@lemmy.mltoLinux@lemmy.mlLinux and RISC-V by 2030
    link
    fedilink
    English
    arrow-up
    3
    ·
    5 months ago

    Here’s a video (YouTube) I saw recently that talks about the experience of using a Milk-V Jupiter in 2025.

    I have a Star64 from Pine64 that I have been meaning to play with. I would say 2030 may be early to expect daily driving a RISC-V device, but you can start playing with RISC-V and becoming familiar with the system so the transition becomes easier once the platform becomes more mature.


















  • Imnebuddy@lemmy.mltoSocialism@lemmy.mlThe worst human experiment
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    1 year ago

    Life expectancy has dramatically improved from feudalism

    To be fair, isn’t the reason life expectancy improved is largely attributed to China uplifting over 800 million people out of poverty?

    While yes, the overthrow of feudalism, which prevented scientific progress as it had threatened the ruling class’s power, led to medical advancements, better food production and access, etc., capitalism negated a lot of improvements toward life expectancy because of deadly working conditions, genocide, wars, colonialism, etc.

    I do agree with your point that capitalism is often a necessity to eventually enable a socialist revolution to be possible once it faces crises from its contradictions and did contribute, at least indirectly, to increased life expectancy, Russia/USSR and China, as mentioned above, are examples of nations that were able to achieve socialism earlier, and their impact towards humanity cannot be understated.





  • I’m not denying that major flaw of Signal, in which part, yes exposing your phone number tied to your Signal account basically negates Signal’s security, as well as Signal’s centralized server being proprietary. Nevertheless, when using Matrix, you need to ensure you and everyone you communicate with uses a client that isn’t still using the deprecated libolm cryptography backend (and that it uses vodozemac).


  • https://lemmy.ml/comment/15999861

    In the blog posts I read where the author, a security engineer, audited and/or reported vulnerabilities with two E2EE chat protocols commonly recommended as Signal alternatives–Matrix and XMPP–both had implemented half-baked solutions or refused to solve the issue at all in some regards, and both had evangelists that gave dismissive responses. The XMPP chud dev gave a laughably childish response, and the Matrix dev even admitted the team being aware of the olm vulnerability and deliberately refused to fix it for years. Not that Signal cultists are any better and not negating the legitimate security and trust issues with the Signal platform, but Signal is still a decent platform for most people’s threat model, though it would be nice if there was an alternative that could compete with Signal to recommend to most people instead. If you care about metadata resistance and your threat model involves high stakes if your assets are compromised, the blog author suggests Tor-based solutions such as Cwtch and Ricochet Refresh.


  • I’m with you there. This wasn’t meant as an argument against your statement. I brought up the issues regarding Matrix and XMPP as they are often recommended as alternatives to Signal, and after learning about this blog in a previous conversation I had about this topic, I thought it would be a good resource to bring up so people can be informed about those platforms and some alternatives that may be better than Signal while being metadata resistant.


  • Many Signal alternatives also have security issues of their own, often making them less secure than Signal. This includes Matrix and XMPP. In the blog post regarding XMPP+OMEMO, the author replies to a question about which would be better than Signal, Matrix, and XMPP with this suggestion:

    Anyone who cares about metadata resistance should look at Cwtch, Ricochet, or any other Tor-based solution. Not a mobile app. Not XMPP. Not Matrix.

    In regards to Ricochet, not having a mobile app version makes it difficult to recommend to less tech savvy people.




  • Imnebuddy@lemmy.mltoLinux Phones@lemmy.mlWhat Apps Are Missing on Mobile Linux?
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    2
    ·
    edit-2
    2 years ago
    Tangent

    I find Android not having almost any option for various apps. I just want a touchscreen keyboard friendly text editor which saves txt files in my phone’s home directory, for example. The only thing that really exists is emacs or using Termux, and using a modal text editor on a mobile keyboard is a massive pain.

    To clarify, I prefer installing open source applications on F-Droid on Android, and yes, I could get some stunning 8K resolution text editor SUPER FAST NO ADS on the Play Store which requires GSF and is developed by some random dude, but I want a well-established text editor that Android doesn’t have, like VSCode or Kate. This is why Linux phones appeal to me, but they still have various issues and limitations.

    Maybe it’s because I use my phone like a computer, but I do not like using single purpose, clunky apps that obfuscate the filesystem. Linux, even on arm alone, has so many different apps that Android has no equivalent for. Not denying there’s still much work to do for mobile Linux.

    I believe the Linux infrastructure for mobile devices needs priority.

    Tangent

    I had difficulty getting images from various operating systems to work (or not crash from updating) on my PinePhone. I need to eventually get Gentoo crossdev setup so I can compile packages for the PinePhone. Curious how well existing Android devices with Linux support fare currently.

    Not sure if debugging and fixing issues would satisfy your itch, but I guess one idea to consider is porting some Linux applications only available on the x86_64 architecture to arm/arm64/etc., and develop mobile friendly guis for current applications that are still primarily suited for desktop.