• 0 Posts
  • 1.31K Comments
Joined 2 years ago
cake
Cake day: July 16th, 2023

help-circle


  • I think it is a smart play.

    They are getting lots of press in the places where the people that care go.

    On their website, they focus on the benefits of their platform for customers. From that perspective, the new COSMIC is just a refinement on what they were shipping before.

    And this is just the beginning. COSMIC itself is still fairly basic. And the “new” Pop!OS is based on an LTS base that is already 2 years old. None of that is a problem but it is not a hand they want to overplay.

    They may actually make a bigger deal about the benefits when 26.04 ships. Things will be a bit more “industry leading” by then.


  • Fair enough.

    But before you scare anybody off, it is worth pointing out that Pop!OS 24.04 is quite up-to-date in those areas.

    • kernel 6.17
    • Mesa 25.1
    • NVIDIA 580 drivers
    • current Wayland (COSMIC)

    Those are what is going to drive your GPU and Wayland experience and they are about the same as you get in Kubuntu 25.10

    A lot of the 24.04 packages will be older for sure but it is not fair to compare COSMIC in Pop!OS to the old KDE version you would have been using on Ubuntu 24.04 (Kubuntu).

    And I expect Pop!OS 24.04 LTS to see steady COSMIC updates on the road to 26.04. It would kind of shock me if they do not harmonize the desktops between those two releases.




  • This is a dramatically misinformed comment. You have clearly never used Distrobox.

    1. The first bullet is the worst. This is like saying that Flatpak will break your host. It will not break the host OS. Learn what a container is.

    2. It is not tools on top of tools. It is tools in a container that you can optionally create entries for in your app menu. Apps in the container execute directly on the host kernel in the container. If you are in a shell, you are either in the container or out and the full environment will reflect that.

    3. It is not for “new users”. That said it dramatically simplifies many intermediate ones and make some advanced things possible. Once again though, there are no “stacks on stacks”.

    4. The exact opposite. Containers do not change the host. If something goes wrong in the container, you can purge it completely without impacting the host.

    In fact, one of my core uses for Distrobox is to keep my host system clean. I use Distrobox to setup dev environments, to try out new software, to work around Distro constraints, and a host of other tasks. It is great.

    There seems to be quite a fundamental misunderstanding of what a container is. Everything runs directly on the host kernel. Apps outside the container run on the host OS and do not interact with the container. Apps in the container run in the environment inside the container. The only interaction apps in the container have with the host is the kernel, the filesystem, and via servers like Wayland, Pipewire, and XDG portals.

    The entire point of a container is to create an application environment that looks exactly like an application expects regardless of system it is running on. It is clean and consistent between deployment. This is the exact opposite of what the above comment implies.

    In practice, it “feels” like apps in Distrobox are running native on the host OS but in fact everything above the kernel is running inside the container and each container is distinct from the others.

    The “example” is totally wrong. GCC is either on the host or it is not (from the host). GCC is either in the container or it is not. They do not interfere with each other. They do not even share C libraries. However, the can see the same source files.

    Distrobox is absolutely nothing like Homebrew. Homebrew is a package manager. If you are using a package manager in Distrobox, it will be the one intended to work with whatever distro you are running in Distrobox. This is a fantastic illustration of the confusion of ideas at work here.

    If you have to compare Dostrobox to something, compare it to Flatpak.






  • The GNU projects that people actually use are primarily hosted, maintained, and developed by Red Hat (IBM). They are the primary code contributors. Not just GPL, GNU specifically.

    This is just a fact.

    https://sourceware.org/ (Previously known as sources.redhat.com)

    There is more permissively licensed code in most Linux distributions than there is GPL code. Not only is that permissive code not being “stolen” by “mega corps” but the majority of it is corporately funded.

    Again, just facts. All pretty easy to verify if facts matter at all to you.

    What part did not make sense? Just that the facts do not agree with your opinion?

    The comment I responded to was stating things that sounded like facts that are not at all supported by the evidence. And if I ask for some, I am pretty sure the cherry-picked examples will be mostly companies “stealing” projects that they wrote to begin with.

    The thesis that permissive licenses result in less Open Source code is wrong. In fact, they lead to greater corporate participation and employees write more code than unsponsored individuals. That is what the evidence shows.

    Use whatever licenses you want. Not wanting companies to use code you wrote is a totally valid choice. But you should not have to misrepresent reality to convince other people to do the same.








  • Android and Chromium. Is listing two projects that were created almost entirely by the same company and gifted to the Open Source world the best way to make your point? I mean, they sure are shafting us with Kubernetes too right?

    I would say that Google is screwing us with Clang and LLVM except Apple and Microsoft contribute a lot to that too so they deserve some of the blame.

    But, I mean clearly GCC is the better project. I mean sure LLVM resulted in Rust (corporate project), Swift (corporate project), and Zig but GCC is where the real innovation is. I mean GCC just added COBOL and Algol 68.


  • GPL code is code for the community by the community.

    Lets list some GPL code developed on servers owned and operated by IBM (because they are the core developers):

    • Glibc
    • GCC
    • binutuls
    • GNU CoreUtils
    • systemd
    • pipewire
    • Podman
    • Flatpak
    • elfutils

    Do you use any of those? About half of those projects were started by IBM. It was them that chose the GPL as a license. I wonder who forced them?

    Who are the Top Contributors to the Linux kernel?

    • Intel
    • Google
    • Red Hat
    • Oracle

    Ya, let’s keep those mega corps from using all that GPL code that YOU write.

    FreeBSD just released a new version. It is entirely permissively licensed. It is clearly an anomaly that half the new features in this release have the names of companies that contributed them in the release notes. Who are these Netflix people?

    I would say “how about gaming” but very little of that code is GPL. Any permissively licensed code used in gaming?

    • WINE
    • proton
    • Xorg
    • Wayland
    • Mesa
    • FEX
    • LLVM

    To your point, those projects must have been totally stolen by greedy mega corps right? I mean, X has been around for decades so there has been lots of time to push Xorg out of the market.

    These Valve guys are big in gaming. Surely they must be stealing all our code and not giving back right? I mean, only the license would stop them (as you say). Obviously they took that MIT WINE thing and made Proton proprietary.

    Right?