3 ms·

Microsoft charges, Linux does not.

by number6 2y ago

Rinzler89 2y ago
>Linux does not Red Hat, Suse and Canonical do charge.
- crowcroft 2y ago
  This is a valid point, but I wonder how many installs are managed through a commercial contract. My assumption is that it would be a small number of high value contracts, but the bulk of installs are just free Ubuntu/Debian/Fedora installs.
- tcmart14 2y ago
  They do charge for extra benefits, if you need them. But you can deploy a server to production today on Debian and be fine. Unless your in the case where you need to pay for support (regulatory). Just because RH, Suse and Canonical charge, does not mean those are requirements. You can always opt to have linux and not pay for their support.
  - firesteelrain 2y ago
    > Just because RH, Suse and Canonical charge, does not mean those are requirements You are leaving a gaping hole in your servers if you are not patching them (the distro's that charge and you decide not to pay)
    - pxc 2y ago
      If you can handle the churn of building against a new platform every year or two instead of every decade or more, you can keep all your stuff patched without an extended support license.
  - pxc 2y ago
    Right. Linux vendors charge for services; Microsoft charges rents.
- firesteelrain 2y ago
  [Removed comment because it responded to wrong parent] https://news.ycombinator.com/item?id=41038604#41038791 https://news.ycombinator.com/item?id=41038604#41038791
  - riskable 2y ago
    What does that have to do with paying? Only RHEL requires that you pay for patches/updates. If you're running Debian, Ubuntu, etc you get all your patches and updates for free; no need to pay.
    - deleted 2y ago
      [deleted]
    - firesteelrain 2y ago
      Regarding Ubuntu - if your requirements of your org require you to go beyond 5 years on Ubuntu LTS then you do need to pay for Ubuntu Pro. also, many org's opt to pay for Ubuntu Pro for piece of mind.
      - number6 2y ago
        Beyond 5 years - I never ran into major problems doing release upgrades.
        pxc 2y ago
        The release upgrades for Ubuntu were a little rough whenever they changed init systems (sysv -> upstart, upstart -> systemd), and occasionally there has been some other weirdness. But the real key is that do-release-upgrade sucks because it's too conservative because they roll back when there are any errors or dependencies they can't resolve. If you do your release upgrades manually, you can always work through those issues. Debian/Ubuntu busybox includes dpkg, so even if you end up in a very broken state (glibc version mismatch, coreutils don't work, bash is broken, etc.). You just need a copy of busybox installed, tmux, and maybe a portable SSH daemon and a statically compiles curl, and you can do everything the release upgrade process does but with the ability to rescue a failure instead of rolling back or dying. It's probably good to follow the same upgrade path as that tool likes though (only directly upgrade between adjacent releases or from one LTS to the next LTS), so you may have to do this a couple of times if your servers are really old. (I guess you don't really even need any of those statically compiled tools, either— you can just use Nix to provide whatever you need instead since no Nix-provided tools care about the libs provided by the underlying Ubuntu system.) At a past job I upgraded in-place some Ubuntu 14.04 web servers to 20.04 through some release-upgrade failures this way. It's generally better to rebuild on a new, clean image, but in-place upgrades on Linux rarely fail and are pretty much always rescuable when they do.
- znpy 2y ago
  yes but here's the main thing: - you can choose to pay RedHat, Suse and Canonical - you cannot choose not to pay Microsoft

Microsoft charges, Linux does not.

Rinzler89 2y ago

>Linux does not Red Hat, Suse and Canonical do charge.

crowcroft 2y ago
This is a valid point, but I wonder how many installs are managed through a commercial contract. My assumption is that it would be a small number of high value contracts, but the bulk of installs are just free Ubuntu/Debian/Fedora installs.
tcmart14 2y ago
They do charge for extra benefits, if you need them. But you can deploy a server to production today on Debian and be fine. Unless your in the case where you need to pay for support (regulatory). Just because RH, Suse and Canonical charge, does not mean those are requirements. You can always opt to have linux and not pay for their support.
- firesteelrain 2y ago
  > Just because RH, Suse and Canonical charge, does not mean those are requirements You are leaving a gaping hole in your servers if you are not patching them (the distro's that charge and you decide not to pay)
  - pxc 2y ago
    If you can handle the churn of building against a new platform every year or two instead of every decade or more, you can keep all your stuff patched without an extended support license.
- pxc 2y ago
  Right. Linux vendors charge for services; Microsoft charges rents.
firesteelrain 2y ago
[Removed comment because it responded to wrong parent] https://news.ycombinator.com/item?id=41038604#41038791 https://news.ycombinator.com/item?id=41038604#41038791
- riskable 2y ago
  What does that have to do with paying? Only RHEL requires that you pay for patches/updates. If you're running Debian, Ubuntu, etc you get all your patches and updates for free; no need to pay.
  - deleted 2y ago
    [deleted]
  - firesteelrain 2y ago
    Regarding Ubuntu - if your requirements of your org require you to go beyond 5 years on Ubuntu LTS then you do need to pay for Ubuntu Pro. also, many org's opt to pay for Ubuntu Pro for piece of mind.
    - number6 2y ago
      Beyond 5 years - I never ran into major problems doing release upgrades.
      - pxc 2y ago
        The release upgrades for Ubuntu were a little rough whenever they changed init systems (sysv -> upstart, upstart -> systemd), and occasionally there has been some other weirdness. But the real key is that do-release-upgrade sucks because it's too conservative because they roll back when there are any errors or dependencies they can't resolve. If you do your release upgrades manually, you can always work through those issues. Debian/Ubuntu busybox includes dpkg, so even if you end up in a very broken state (glibc version mismatch, coreutils don't work, bash is broken, etc.). You just need a copy of busybox installed, tmux, and maybe a portable SSH daemon and a statically compiles curl, and you can do everything the release upgrade process does but with the ability to rescue a failure instead of rolling back or dying. It's probably good to follow the same upgrade path as that tool likes though (only directly upgrade between adjacent releases or from one LTS to the next LTS), so you may have to do this a couple of times if your servers are really old. (I guess you don't really even need any of those statically compiled tools, either— you can just use Nix to provide whatever you need instead since no Nix-provided tools care about the libs provided by the underlying Ubuntu system.) At a past job I upgraded in-place some Ubuntu 14.04 web servers to 20.04 through some release-upgrade failures this way. It's generally better to rebuild on a new, clean image, but in-place upgrades on Linux rarely fail and are pretty much always rescuable when they do.
znpy 2y ago
yes but here's the main thing: - you can choose to pay RedHat, Suse and Canonical - you cannot choose not to pay Microsoft