6 ms·

Also, I rather like IPS packaging. Please explain how it sucks. It's written in Python (because they wanted to attract developers) and it doesn't allow for pre

Also, I rather like IPS packaging. Please explain how it sucks. It's written in Python (because they wanted to attract developers) and it doesn't allow for pre- and postinstall scripts, nor does it allow pre- and postremove scripts. If you're doing very large scale configuration management with OS packaging, you're screwed really deep and really hard, because with IPS, all of that pre- and postinstall as well as pre- and postremove scripting has to be completely redesigned into self-assembly SMF methods, which is a gargantuan, extremely financially expensive effort. It's slow, so the core parts had to be rewritten in C. Might as well have started with C to begin with. Since they didn't want to allow scripting, they had to put in special hacks like "actuators" and driver hooks. At which point they might as well have put in scripting, but no, they remained stubborn. Another big sin. It's because both Hahn and Smaalders were/are for some bizarre reason absolutely convinced that scripting in packaging is bad and fragile, which is utter nonsense. So wrong assumption begat wrong, busted architectural decisions. The design was actually an experiment by one Dr. Stephen Hahn. It had some good ideas like delta in-place upgrades (like SGI IRIX's inst(1M)), and incorporations (like IRIX inst(1M)'s depots) but the implementation sucks so horribly, with such horrible technical choices as Python that it should have never made it past the prototype stage. Apart from OmniOS and OpenIndiana, it is shunned by other mainstream illumos-based operating systems. The automated installer which leverages it and was meant to replace JumpStart(TM) is an overcomplicated disaster. The biggest sin of IPS though, is collateral damage: because IPS is so architecturally busted, sparse zones, a truly revolutionary and phenomenally useful capability had to be abandoned (to be brought back in SmartOS, thankfully). I hate IPS with the burning passion of 30 trillion suns. Thanks, Dr. Stephen Hahn & Co.! Post scriptum: I kept trying to tell them to license IRIX's inst(1M). They kept ignoring me. Now inst(1M) is bit rotting away in some vault and IPS is an obscure packaging mechanism preventing OmniOS from reaching its adoption potential. All around win-win.

cryptonector 9y ago
Not allowing for {pre,post}-{install,remove} scripts is almost the key point. To be precise: IPS does allow install scripting, just not immediately at pkg install/remove time but deferred so that such scripts only ever run in the context of the running OS. Back in the days of SVR4 packaging, the scripts had to be extremely limited in what user-land features they could use because they had to be able to run in many different environments, including a) two minor releases back (so, S8 for S10 pkgs), b) netboot, c) boot media. This was insanely hard to support -- I know, because I was there at Sun. By deferring execution of pkg scripts, IPS avoids the problem altogether. Instead, the scripts can only run in the running OS instance on which a pkg was installed (or from which it was removed). This is much, much cleaner than traditional pkg scripting. So much so that I'm shocked this technique hasn't been more widely adopted.
- Annatar 9y ago
  IPS does allow install scripting, just not immediately at pkg install/remove time but deferred so that such scripts only ever run in the context of the running OS. This is patently wrong: if I'm running self assembly from SMF, that has nothing to do with IPS. If I invested the tremendous amount of engineering and funding, I could do the exact same thing from SVR4 packaging, which I have done in some packages. What do I need IPS for then? I don't! But wait, there is more!: Back in the days of SVR4 packaging, the scripts had to be extremely limited in what user-land features they could use because they had to be able to run in many different environments, including a) two minor releases back (so, S8 for S10 pkgs), b) netboot, c) boot media. This was insanely hard to support Auto- and thin client capability was ditched, so the very argument used to fuel this nonsensical course of action was made moot. And even with Auto- and thin client argument, that was not enough to justify the atrocities committed by IPS. No thanks. If I can't have IRIX inst(1M) or HP-UX swinstall(1M), I'll stick with good old SVR4 packaging. Since Snoracle killed AutoClient and thin client support anyway, configuration management with SVR4 works wonderfully. I have my scripting in the immediate installation context for configuration management in tandem with SMF and it's great. IPS can remain an obscure packaging technology nobody's using anyway for all I care. And that is good so: it's a totally botched implementation of inst(1M) and swinstall(1M). By deferring execution of pkg scripts, IPS avoids the problem altogether. Instead, the scripts can only run in the running OS instance on which a pkg was installed (or from which it was removed). This is much, much cleaner than traditional pkg scripting. So much so that I'm shocked this technique hasn't been more widely adopted. That is exactly what killed the adoption of IPS and severely handicapped the adoption of OpenSolaris and all operating systems which were IPS based. I cannot believe you (plural) are still refusing to see it! As if the entire Solaris ecosystem didn't have enough adoption problems, this just piled on and made it far worse. To someone like me who grew up on and deeply, deeply cares about Solaris and illumos and SmartOS, it's absolutely infuriating. You made your own lives easier but it cost you the company (Sun Microsystems), and it cost me having to primarly work on GNU/Linux based operating systems these days. We all lost. Empathy is still a core engineering value. With IPS, there was no empathy. All your customers wanted was more freeware bundled with the OS and automatic dependency resolution for easier patching, things which could have been easily added to SVR4 packaging. They didn't need or want someone's doctoral disertation implemented as an experiment.

cryptonector 9y ago

Not allowing for {pre,post}-{install,remove} scripts is almost the key point. To be precise: IPS does allow install scripting, just not immediately at pkg install/remove time but deferred so that such scripts only ever run in the context of the running OS. Back in the days of SVR4 packaging, the scripts had to be extremely limited in what user-land features they could use because they had to be able to run in many different environments, including a) two minor releases back (so, S8 for S10 pkgs), b) netboot, c) boot media. This was insanely hard to support -- I know, because I was there at Sun. By deferring execution of pkg scripts, IPS avoids the problem altogether. Instead, the scripts can only run in the running OS instance on which a pkg was installed (or from which it was removed). This is much, much cleaner than traditional pkg scripting. So much so that I'm shocked this technique hasn't been more widely adopted.

Annatar 9y ago
IPS does allow install scripting, just not immediately at pkg install/remove time but deferred so that such scripts only ever run in the context of the running OS. This is patently wrong: if I'm running self assembly from SMF, that has nothing to do with IPS. If I invested the tremendous amount of engineering and funding, I could do the exact same thing from SVR4 packaging, which I have done in some packages. What do I need IPS for then? I don't! But wait, there is more!: Back in the days of SVR4 packaging, the scripts had to be extremely limited in what user-land features they could use because they had to be able to run in many different environments, including a) two minor releases back (so, S8 for S10 pkgs), b) netboot, c) boot media. This was insanely hard to support Auto- and thin client capability was ditched, so the very argument used to fuel this nonsensical course of action was made moot. And even with Auto- and thin client argument, that was not enough to justify the atrocities committed by IPS. No thanks. If I can't have IRIX inst(1M) or HP-UX swinstall(1M), I'll stick with good old SVR4 packaging. Since Snoracle killed AutoClient and thin client support anyway, configuration management with SVR4 works wonderfully. I have my scripting in the immediate installation context for configuration management in tandem with SMF and it's great. IPS can remain an obscure packaging technology nobody's using anyway for all I care. And that is good so: it's a totally botched implementation of inst(1M) and swinstall(1M). By deferring execution of pkg scripts, IPS avoids the problem altogether. Instead, the scripts can only run in the running OS instance on which a pkg was installed (or from which it was removed). This is much, much cleaner than traditional pkg scripting. So much so that I'm shocked this technique hasn't been more widely adopted. That is exactly what killed the adoption of IPS and severely handicapped the adoption of OpenSolaris and all operating systems which were IPS based. I cannot believe you (plural) are still refusing to see it! As if the entire Solaris ecosystem didn't have enough adoption problems, this just piled on and made it far worse. To someone like me who grew up on and deeply, deeply cares about Solaris and illumos and SmartOS, it's absolutely infuriating. You made your own lives easier but it cost you the company (Sun Microsystems), and it cost me having to primarly work on GNU/Linux based operating systems these days. We all lost. Empathy is still a core engineering value. With IPS, there was no empathy. All your customers wanted was more freeware bundled with the OS and automatic dependency resolution for easier patching, things which could have been easily added to SVR4 packaging. They didn't need or want someone's doctoral disertation implemented as an experiment.