3 ms·

Cadence for example, the software that the engineers design and run simulations of the latest and greatest ICs with, from HN's favorite RISC Vs to Nvidia's 4090

by okanat 3y ago

Cadence for example, the software that the engineers design and run simulations of the latest and greatest ICs with, from HN's favorite RISC Vs to Nvidia's 4090, only runs on SLES and RHEL. ANSYS fluid dynamics simulator is another. All the advanced planes, future engines have been simulated with it. CATIA and NX are advanced and very expensive CAD software (the basic licensing packages for a medium grade company can easily near a million and often exceed). Both runs only on SLES or RHEL. Many large businesses use on-prem SAP deployments which runs only on SLES.

hedora 3y ago
“Only runs on”, or “is only supported on”? Debian alien worked the last time I had to install some janky rpm-only commercial software.
- Symbiote 3y ago
  If you're spending five or six figures on a licence, paying Red Hat or SUSE on top is easy, and part of the cost. It makes no sense to try and run it on Debian.
  - hedora 3y ago
    Productivity matters though (especially at 5-6 figures per seat!). If the CAD designer can't get the rest of their job done with a Red Hat box, do you want them carrying two laptops and or using an HDMI switch, or that they spend 30-60 minutes futzing with .so's until the one special snowflake program starts working on their main machine?
- okanat 3y ago
  At this scale, the difference doesn't matter. "No support" means "only runs on". Those software makes everything we use daily and we depend our literal lives on. No sane management will risk billions of losses, the literal production and accounting of the company or possible loss of human lives on some ideological or aesthetic preferences on the OS. Moreover the licensing agreements usually prevent the licensees from even trying such things. Compared to their licensing fees, RHEL or SLES are a cent to a 100 bill. Technically the programs may or may not work. Those programs are large and even if you have access to the source code, they can be very tricky to understand. Making all of their parts and their extensively used C++ plugin systems work in a foreign distro is probably harder than reverse engineering some hardware. They are not "janky commercial software". People can and do produce cars, planes, UAVs, latest supercomputers and ICs, satellites and even nuclear warheads with them. Linux userspace libraries don't provide stability or featureset guarantees and distros patch them and worsen the compatibility. Enterprise distros guarantee them and take responsibility for that. In addition the commercial software developers and their customers get premium tier support often connecting you to the developers who curated the distro. You cannot expect community to provide any of that, especially after many years of tradition of almost intentional breaking.
  - hedora 3y ago
    Any company building safety critical stuff should be using a separate set of hardware to validate the CAD designs. Even with ECC memory and machine check exceptions, processors still corrupt stuff and make mistakes. On a practical note, I've dealt with $$$ software that only runs on enterprise Linux or particular versions of Windows. Without fail, it has been buggy as hell, and crashed if there was a slight breeze outside or under gibbous moons. Examples: "When you boot the computer, first click this, then that, and finally this." "We all need to share this one laptop. No one may use the laptop for anything but this one flow in this one program because the laptop's OS install is irreplacable, and the equipment it drives costs $250,000" "Don't run anything in the background because their verification kernel was only tested with two cores, and we can't buy CPUs that old any more" "Don't turn the printer on until after the UI is done booting up because if it sees an HP vendor ID on the USB bus it thinks it's a spectrophotometer or a license dongle or something"
dallas 3y ago
In the (now far away?) past I used chroot jails in Ubuntu containing binary-compatible dependencies for chip sim tools. Regressions would be run on proper RHEL though so tool vendor support wasn't impeded by anything even remotely suspect.
jrockway 3y ago
If it's just client applications that force people to be on RHEL, why is RHEL so heavily involved in the server-side business? OpenStack, etc.

by okanat 3y ago

hedora 3y ago

“Only runs on”, or “is only supported on”? Debian alien worked the last time I had to install some janky rpm-only commercial software.

Symbiote 3y ago
If you're spending five or six figures on a licence, paying Red Hat or SUSE on top is easy, and part of the cost. It makes no sense to try and run it on Debian.
- hedora 3y ago
  Productivity matters though (especially at 5-6 figures per seat!). If the CAD designer can't get the rest of their job done with a Red Hat box, do you want them carrying two laptops and or using an HDMI switch, or that they spend 30-60 minutes futzing with .so's until the one special snowflake program starts working on their main machine?
okanat 3y ago
At this scale, the difference doesn't matter. "No support" means "only runs on". Those software makes everything we use daily and we depend our literal lives on. No sane management will risk billions of losses, the literal production and accounting of the company or possible loss of human lives on some ideological or aesthetic preferences on the OS. Moreover the licensing agreements usually prevent the licensees from even trying such things. Compared to their licensing fees, RHEL or SLES are a cent to a 100 bill. Technically the programs may or may not work. Those programs are large and even if you have access to the source code, they can be very tricky to understand. Making all of their parts and their extensively used C++ plugin systems work in a foreign distro is probably harder than reverse engineering some hardware. They are not "janky commercial software". People can and do produce cars, planes, UAVs, latest supercomputers and ICs, satellites and even nuclear warheads with them. Linux userspace libraries don't provide stability or featureset guarantees and distros patch them and worsen the compatibility. Enterprise distros guarantee them and take responsibility for that. In addition the commercial software developers and their customers get premium tier support often connecting you to the developers who curated the distro. You cannot expect community to provide any of that, especially after many years of tradition of almost intentional breaking.
- hedora 3y ago
  Any company building safety critical stuff should be using a separate set of hardware to validate the CAD designs. Even with ECC memory and machine check exceptions, processors still corrupt stuff and make mistakes. On a practical note, I've dealt with $$$ software that only runs on enterprise Linux or particular versions of Windows. Without fail, it has been buggy as hell, and crashed if there was a slight breeze outside or under gibbous moons. Examples: "When you boot the computer, first click this, then that, and finally this." "We all need to share this one laptop. No one may use the laptop for anything but this one flow in this one program because the laptop's OS install is irreplacable, and the equipment it drives costs $250,000" "Don't run anything in the background because their verification kernel was only tested with two cores, and we can't buy CPUs that old any more" "Don't turn the printer on until after the UI is done booting up because if it sees an HP vendor ID on the USB bus it thinks it's a spectrophotometer or a license dongle or something"

dallas 3y ago

In the (now far away?) past I used chroot jails in Ubuntu containing binary-compatible dependencies for chip sim tools. Regressions would be run on proper RHEL though so tool vendor support wasn't impeded by anything even remotely suspect.

jrockway 3y ago

If it's just client applications that force people to be on RHEL, why is RHEL so heavily involved in the server-side business? OpenStack, etc.