• 0 Posts
  • 799 Comments
Joined 1 year ago
cake
Cake day: July 16th, 2023

help-circle

  • Well, now you are hitting on my real recommendation which is to use Distrobox. Distrobox allows you to install multiple userlands that are all isolated from each other but all seem native on your system and give you full access to shared files and resources ( even the GUI desktop ).

    It is very common to work on something not that just has outdated packages but that targets a specific distribution. If you are building something that will target an Alpine container in the cloud, it is handle to create an Alpine Distrobox to have all the same libraries. Similarly an app might target a specific version of Ubuntu. One of the products I worked on last year was based on Ubuntu 18.04. I could easily create an Ubuntu 18.04 Distrobox to work on that.

    Distrobox also means I can prevent the build-up of cruft from all the little specialty tools and dependencies that projects require that I will not need long term. Remove the Distrobox and remove all the junk.

    This is different than pure Docker to Podman though since Distrobox still gives you full access to your base system. You only have to install what you uniquely need in Distrobox. So i am not necessarily installing all my tools in Distrobox. Just the specialty ones.

    Anyway, this is a more complicated answer and setup. In my view, the host environment still matters a lot and what I said above still stands.



  • Not the OP but he may mean that application authors have unintentionally made Windows a monopoly.

    Either way, I am not sure I agree about the intentionality. App devs didn’t slip and support only Windows by accident. They may not have explicitly intended all the consequences of Windows monopoly but one dominant platform is an advantage for the app vendors too. Too many targets to support is part of what keeps commercial software off Linux.

    The only ones hurt by a Windows monopoly are the consumers. Well, and commercial Windows alternatives obviously. But all the app makers are fine with it.

    Valve ( makers of Steam ) can be seen as an alternative platform for gaming. This is why you see Valve investing so heavily in Linux even though they make all their money on Windows.


  • I cannot speak for the OP but most of the pepper claiming they are waiting will not switch. They may use an illegally patched or trimmed version of Windows 11. Many won’t even do that.

    The biggest risk for Microsoft is that everybody stays on Windows 10 without updates. Or that massive customers will force them to push back the “enterprise” date over and over. To encourage migration, expect Microsoft to make Windows 10 just as bad as 11 before support expires.


  • Windows is a platform for Office. Linux is not a supported platform for Office. Most businesses will not migrate their desktops off Windows because they will not migrate their workforce off Office.

    Beyond that, Windows is not as important to Microsoft as it used to be. The real money makers are Azure and Office. With Azure, they do not care if you run Linux. They even have their own distro ( Azure Linux — previously CBL Mariner ).

    Azure is the future ( even for Office ).

    Since Windows is less strategic, Microsoft is looking to milk it as a cash cow while they can. So, Product Management is tasked with finding new ways to monetize it. Data is worth a lot of money. The best way to farm data from users these days is to frame it as security ( or AI ).

    Expect a lot more SIngle Sign On. Expect a lot more AI. Expect a lot more cloud integration. Expect all of these to focus on data harvesting.

    A bit later, expect “services” for Linux that attempt the same. Like Google on Android. This is harder though as Windows does not have monopoly control over Linux as a platform. I am sure they are having many meetings about how to change that.




  • Newer kernel matters and can actually make the distro more new user friendly for sure.

    Newer packages as well which prevents you from having to find newer versions in PPAs and other places. In my view, this makes a distro less stable and harder to maintain.

    In fact, I think Arch can be more stable than Ubuntu precisely because Arch users hardly ever have to look beyond the repos. I think Arch users really less on Flatpak for the same reason. In theory the AUR is no different than a PPA but it causes way fewer problems in practice ( especially conflicts ). There is something about APT as well that handles conflicts by removing stuff ( stuff you may really need ). Pacman and dnf do not seem to do that.



  • Video gets higher engagement. If you want your information to be consumed, video is a better bet.

    That will not stop every video from having a top comment complaining about it though.

    I prefer written content myself. But, as you say, I am happy for content in whatever form I can get it. I did not pay for it. How it is generated and shared is not up to me.

    Soon I hope, we will have a bot that transcribes every video. Then that can be the top comment instead of the endless complaining.



  • LeFantome@programming.devtoLinux@lemmy.mlLinux middle ground?
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    6 days ago

    I like the idea of a stable distro as the host OS and Distrobox with Arch and the AUR for applications.

    For most of my machines, I do not need the latest kernel or even the latest desktop environment. But it is a pain to have out of date desktop apps and especially dev tools.

    I think this strikes a nice balance.




  • I will just say that SUSE 4.2 was not built off the same base as SUSE 1.0 either. It is not going to be as clear cut as finding a cloned Red Hat source code repository.

    SUSE 4.2 was really version 1.0 of the distribution we call OpenSuse today ). It was a reboot. This version was no longer based on Slackware and it was the first version using RPM.

    Debian introduced packages in 1995 ( before Debian 1.0 ). RPM did not appear until Red Hat Linux 2.0 in the fall. SUSE 4.2 came out in 1996 and could have used either one.


  • I was not trying to cause any offence. Mad respect for SUSE. As I hinted, I was simplifying. It is hard to talk about this stuff both accurately and concisely.

    SUSE is certainly not a Fedora “fork” as Fedora Core was not even conceived until considerably later. Neither was OpenSUSE really. So you cannot take my first comment too literally.

    Let’s remember how early SUSE was in the Linux timeline. Back then, everybody was downloading their software from the same FTP sites. A huge component of what made a Linux distribution different from an FTP repo was the package manager and those came from Red Hat or Debian.

    The provenance of SUSE is also a bit complicated as the first versions were explicitly based on Slackware. Starting with 4.2 ( a made up version number meant as a nod to Douglas Adam’s I think ), SUSE became Jurix + RPM. So it is a Jurix fork in that sense. However, I cannot imagine more than a handful of people ever used Jurix. I would be interested to know the numbers. In contrast, in terms of both users and industry awareness, Red Hat was THE Linux distro back then.

    Red Hat was certainly an influence on SUSE beyond the source code. Red Hat and SUSE were not just communities or collections of code. Red Hat and SUSE were two of the earliest company backed distros. Both had clear commercial ambition. It is no accident that they both evolved into explicitly “enterprise” subscription products flanked by explicitly community distros. SUSE and Red Hat were more like each other than they were like other Linux players ( especially in the days before Ubuntu ). It is not far wrong I think to think of SUSE as the Red Hat of Europe with Red Hat attracting American infrastructure giants like Oracle and SUSE becoming the platform for big European players like SAP.

    SUSE is not a fork in the sense that we are going to find an import into the source code version control system from Red Hat ( other than RPM itself of course ). Again though, we should note that this is not how stuff worked back then ( see comment about FTP sites ).

    RPM could have been a purely technical choice for SUSE but, in my view, they had a clear desire to use Red Hat as a template more broadly. That is what I meant by saying SUSE could be seen as a fork while also acknowledging that the statement is not quite fair ( or perhaps more that it is not technically accurate in the strictest sense of what the work fork means even if it instructive as a historical perspective ).