• 2 Posts
  • 40 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle
  • I’m not the biggest distrohopper but I have tried a few, both on my laptop and desktop. I still keep windows around on a dual-boot but I’m basically only using it for the odd game or two and also onenote (obsidian + excalidraw comes close but nothing really has a seamless transition between pen and typing text like OneNote)

    Early 2018 and before:

    Windows only

    2018-19:

    • Ubuntu 18.04 (desktop),
    • Ubuntu 18.04/18.10/19.04 (laptop)

    2019-2022:

    • Manjaro w/ KDE (desktop),
    • Arch Linux w/ GNOME (laptop)

    2022-2023:

    • NixOS (laptop, for literally a day because it didn’t have a package I needed to make my laptop work correctly)
    • EndeavourOS (kde on laptop, qtile on desktop)

    2024:

    • No changes to the desktop setup,
    • NixOS w/ KDE and also a half-functioning hyprland setup on the laptop now that the package got added.

    Future?

    Maybe if I can get my NixOS config to a point where I’m happy with it I’ll switch my desktop setup to that as well, in theory it should be pretty painless since i’m already using a flake setup split across multiple modules. I do really like that I can experiment with my setup without the risk of actually breaking anything since NixOS is semi-immutable.

    If I don’t stick with NixOS I’ve also been thinking about trying fedora, opensuse, or an immutable distro, or otherwise just moving my laptop back to either Arch or EndeavourOS since that’s what I’m familiar with.


  • It’s also worth noting I’ve recently been seeing a lot of Linux posts from people who just switched, this was somewhat of a trend on Reddit as well but imo the Linux posting has gotten noticeably less toxic toward newer users and a lot more understanding of the “using Linux without wanting to spend hours configuring everything” perspective.

    Side point that’s somewhat related to that: I wonder how the growth of other platforms FOSS platforms like Lemmy, Mastodon, Matrix, etc. has impacted Linux project development. Not sure if it’s just me but it seems like it’s helped a lot with making Linux communities more accessible.





  • If you’re worried about using the terminal you could always install one of the frontends for pacman like the one Manjaro uses. Manjaro might be a pain if you’re using AUR packages (really depends on what packages you use, some niche ones like specific game modloaders or the professional JetBrains IDEs are only on the AUR) because Manjaro’s repos are delayed by around 2 weeks, but the AUR isn’t delayed at all. Depending on the packages you’re using that could break updates sometimes.

    Depending on how familiar with programming you are you could also try NixOS which has an absurd number of packages in their official repo but NixOS’s config files can be kind of a pain sometimes.

    Edit:

    It’s also worth noting that you could start off with Manjaro and then jump over to something like EndeavourOS/Arch once you get more familiarized with using the terminal down the line. That way you wouldn’t have to relearn commands/setups when you switch, since they’re ultimately all arch-based and have the same underlying structure.



  • Software optimization is mostly not a language-level problem. I’ll be dailying my 3-year-old OnePlus 9 Pro until it starts missing out on security updates, but it will probably still be “usable” long after that. Support/updates aside, my 6-year-old galaxy s9 can still run most normal apps. Hell, I got the most recent lineageOS running on a pixel 2 XL from the year before that and it straight up felt fast as long as I wasn’t playing some super intensive game or something. This isn’t an android vs. iOS problem, it’s a “developers of [insert flashy new app here] either not bothering to put effort in to optimize their code or being forced to push out a minimum viable product ASAP” problem.

    Edit: fixed my hyphen use


  • Another big thing that doesn’t get covered by big O analysis is the potential for parallelization and multi threading, because the difference created by multi threading only amounts to one of those dropped coefficients.

    And yet, especially for the workloads being run on a server with 32-128 cores, being able to run algorithms in parallel will make a huge difference to performance.






  • Zangoose@lemmy.onetolinuxmemes@lemmy.worldnuclear take:
    link
    fedilink
    arrow-up
    13
    ·
    edit-2
    2 months ago

    In the grand scheme of things the difference between C, C++, and Python isn’t meaningful when operating over a network (edit: for a single-user system). It’s very likely that the difference for thread OP is just caused by weaker connections to specific repos.

    We’re talking about a package manager, not a game, network server, etc. On a basic level the package manager only needs to download files from a network and install them (OS syscalls for reading/writing files, these are exposed C functions or assembly routines), or delegate to a specific package’s build setup (which will also likely be written in a compiled language)



  • Not really sure how archinstall factors in since it wasn’t around yet when I first installed, but I love EndeavourOS. I’ve installed arch before, but I really can’t be bothered if I’m just going to end up installing all of the same packages the GUI could give me in less time anyway. Yeah, EndeavourOS is just arch with some small extra packages and a GUI installer, but that’s exactly why I like it.


  • That’s partially my point. You can never be 100% safe, but there’s a lot you can do to increase your safety besides just relying on intuition (edit: because intuition is usually the weakest link, see social engineering/phishing tactics). Anti viruses (when they aren’t just bloatware) are part of that.

    Your second point about not meaningfully defending against backdoors and vulnerabilities is kind of against the point. You can totally defend against backdoors by not giving apps admin privileges, limiting network access, etc. so that damage can be limited even if an exploit happens. Then, if some backdoor or exploit is discovered, it’s only as dangerous as the permissions you give that app.




  • That’s the thing though, because it’s kind of a paradox. If you had a single team working on it, then sure, it might be easier to just learn Rust. However, on an open source project, especially a volunteer driven one, that isn’t necessarylily the case. Your average enterprise dev probably isn’t even considering rust as an option yet, because it’s still in early stages in terms of tooling and support infrastructure.

    I made another comment in this post, but as it is right now languages like Java and C# make up significantly more projects/job positions than rust. If you want to get more contribution from volunteer devs, it needs to be in a language that devs are comfortable with. Most people won’t want to learn a whole new programming language for a volunteer project when they’re already working a full-time job in a different language. I explained this in the other post, but that’s why I think having both projects is still beneficial. Sublinks and Lemmy can (hopefully) continue to exist at the same time and benefit from each other’s development, especially if they stay API compatible. Sublinks will have a lower barrier to entry (thus maybe a quicker development cycle with more people involved), while Lemmy will help contribute to the validation of rust as a language for production code.

    Also “rust is the future” implies that’s the only programming language that is worth learning, which is simply not the case. Different languages are better at different things. There will never be a single language that’s best at everything. Even for a specific task, multiple languages are good at doing the same thing. For example, Go, Rust, C#/any .NET, and Java/any JRE can all do REST services like Lemmy pretty well. Of those, I wouldn’t even say Rust is the best choice, because its frameworks are all still pretty new.

    Other languages are growing and evolving as well. Even old languages like Java and C++ have had significant improvements in their modern standards (Java records, C++ smart pointers, etc.). Hell, even COBOL got a new standard version as of 2023 (if I had to guess, this didn’t do much for it though). Just because certain languages are bad right now doesn’t mean they will stay bad forever.