• @[email protected]OPM
    link
    fedilink
    13 years ago

    From Reddit:

    Just handed Microsoft the best talking point ever. Imagine giving up the war in order to win a few minor licensing battles. Microsoft has been telling companies this would happen with open source forever, even the biggest companies. Now no one can argue with them. Amazing.

    This commenter on the article said it best:

    This is not a suicide, this is a murder done by corporate pigs from IBM

  • Ephera
    link
    fedilink
    13 years ago

    Yeah, I don’t think that CentOS Stream thing itself is necessarily a bad idea, but they could’ve called that “RHEL Beta” and not cannibalized a project, which’s whole shtick has always been that it is just RHEL without support contract.

    Well, at least the CentOS-type projects don’t rely on IBM to be best friends with them and the community can just put out another such effort.

    • @[email protected]OPM
      link
      fedilink
      0
      edit-2
      3 years ago

      CentOS was the non-subscription version of RedHat Enterprise Linux (RHEL), and was massively popular as a server operating system. Now that CentOS is killing its stable version, no sane person would keep using it on their servers, so they’ve thrown away most of their market share, likely in a bid to get people to use RHEL.

        • @[email protected]
          link
          fedilink
          13 years ago

          Fedora is alive and well. It suits better as a workstation or testing server operating system, using it on production isn’t a good idea.

          Rhel unlike fedora is very stable and I believe it has support for over 8yrs which is a lot. Rhel unstable however doesn’t have a support time and can be unpredictable. It isn’t as unstable as fedora but is compared to Rhel Stable.

          So the fact that cent os which was previously based on Rhel stable is a huge issue. Because lots of production servers rely on it and don’t want to purchase the incredibly expensive Rhel stable license.

      • @[email protected]
        link
        fedilink
        03 years ago

        My understand is that the non stable branch can’t be too bad but if people want surity of stability I guess they’ll migrate to Debian or something.

          • Halce
            link
            fedilink
            -13 years ago

            Doesn’t the change just mean it’s going to be a rolling release? As long as they push quality updates, I can’t see why it would be unstable. In fact, wouldn’t security vulnerabilities get patched sooner?

            • @[email protected]OPM
              link
              fedilink
              1
              edit-2
              3 years ago

              I don’t know about how CentOS handled security patches for its stable releases, but Debian does backports of security updates (AFAIK there can be issues but it works fine for the important packages). The main problem is that rolling release can package conflicts and subtle issues, and depending on what branch the actual packages are on, they can be unstable or have many bugs (Nvidia drivers were the bame of my existance both when I ran Arch/Manjaro and OpenSUSE Tumbleweed). I’m not a sysadmin, but everywhere I read not to use rolling release for a production server.

          • @[email protected]
            link
            fedilink
            -2
            edit-2
            3 years ago

            It’s 50/50 for me based on my anecdote experience as a small business owner.

            I used to run production server on RHEL 7 until the server AMD EPYC 7452 had issues with RHEL 7 provided kernel and packages that disrupt the functionality of the server. (We’re talking HARD FREEZES that killed the server and forcing you to power it off and reboot it. RHEL support refused to fix it or disable Packagekitd which is also another reason why server crashes and they won’t fix cockpit server.)

            With the latest hardware like EPYC servers, we had to choose the latest version of Linux, we tried RHEL 8 and that didn’t work either. So frustrated that I’ve try doing the right thing by choosing stable Linux distro, I opt to go “my way” on it and do things differently while being aware of the risks involved.

            So we opted for Arch Linux (shocking I know), and it worked out of the box from there since we minimize the risks with a few key factors:

            1. Reduce Number of dependencies
            2. Organizing an Upgrade-cycle to monthly cycle
            3. Regular Snapshot/Backup
            4. Versioned the compiler/runtime

            There are few advantages to this that I can reduce amount of space that software take to deploy to server from like 2.8 gb to only 240 mb deployment, because I don’t have to static link as often since I know the server and my workstation are at relatively similar version especially with LLVM dependencies and compilers. With a given on minimal dependencies that boil down to updating systemd, bash, coretools, Linux kernel, and other base-system dependencies and the chosen dependencies for what my project required, the risk factor of server failing become very minimal as opposed to RHEL out of the box distro.

            As for upgrading/updating the server, before we actually conduct an upgrade for production servers, we run a test on them in a KVM that emulate the EPYC server processors and run various tests to ensure that it’s fully functional after upgrade including PostgreSQL upgrades. When doing an upgrade on Production Server, we just simply do a full incremental backup and then do an update from there and do a reboot about every month which prompts the server to have about 99.98% availability for JUST that server since it takes about 10 minutes to reboot after running a RAM check and other boot sequences. The overall service is actually closer to 99.999999% to 100% availability, because we’re not running ONLY that server, but running 3 more other servers with load balancing that can pick up the stack if other server failed.

            There are some dependencies that definitely require careful consideration like PostgreSQL which require an upgrade plan and prior testing on virtualized environment. I only upgrade PostgreSQL once a year or so and it tend to work fine for quite a while.

            • @[email protected]
              link
              fedilink
              -23 years ago

              This sounds awesome, thanks for the great write-up. People like to poo-poo on Arch as a server but it’s really such a great option so long as you have backups and are careful. The AUR is crazy handy too.