
A smarter SmartOS? (2016) - cxrbxn
https://hypoalex.github.io/smartos/design/a-smarter-smartos.html
======
ofrzeta
The blog post is from 2016 and the referenced Github repo doesn't exist.

------
shiftoutbox
Also there was some work done back in 2015 to use the NetBSD hier and illumos
user land to start down this path . It was even shown to work back in 2006
using Solaris 10 and a super minimal install . I think both sites are long
gone and someone would need to dig around archive.org to find it .

------
cryptonector
You lost me at the linker part. Even now the GNU ld(1)/gold(1)/ld.so story is
terrible. Limited or no support for filters and auxiliary filters,
interposition control, etc? Screw that.

EDIT: Also, I rather like IPS packaging. Please explain how it sucks.

~~~
Annatar
_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
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
_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
The SMF service that runs the scripts should really have been a first class
feature of IPS, but whatever, it's there.

I don't even remember how many userlands had to be supported by SVR4 packaging
at its peak, but it was a lot, and it was difficult to test. That some of
those were removed eventually hardly matters: the problem remains, only
slightly reduced in magnitude.

Moreover, I want less package scripting. So many Linux packages want to do
stupid things like... interact with me when Ubuntu/whatever is just updating
the system. It's never appropriate for, e.g., a PostgreSQL package to create a
postgres account and configure a postgres service running as that account --
this is not how I want to run postgres, and if you stop this madness then
suddenly a postgres pkg is just code and no pkg scripts. If doing stupid
things in pkg install scripts is what you call empathy, then I want none of
it.

And by the way, IPS had nothing to do with Sun's failure. That can be chalked
to a long line of _terrible_ executive business decisions, such as:

    
    
         - suspending/killing x86 Solaris support in 2002
         - killing SunPS (especially considering how much money IBM made with theirs)
         - acquiring Cobalt and then promptly killing it
         - buying MySQL
         - not seeing the writing on the wall for Java ME when iOS came out
         - and much more
    

Oracle is not doing well either. They killed OpenSolaris, which was Sun's way
to rebuild mind-share. Oracle is built on mind-share (and subsequent vendor
lock-in) but they don't even know it. They gave the impression that they don't
care about Solaris x86 (oops). And much more.

~~~
X-Istence
> It's never appropriate for, e.g., a PostgreSQL package to create a postgres
> account and configure a postgres service running as that account -- this is
> not how I want to run postgres

I don't mind it creating a postgres account, but what I do mind is the package
automatically enabling the service, and starting the service.

Even worse, on Linux, most packages will be helpful, for example upgrading the
MongoDB package on CentOS? It'll helpfully restart the service for you.

Nevermind that you've just scripted this and it's being run on all of the
servers all at once so instead of doing a nice easy rolling upgrade WHEN you
are finally ready, it's done at the same time.

I hate this behaviour. Let me worry about the lifetime of processes, don't
auto enable them, don't auto configure them, let me worry about making sure
systemd knows it is time to start/stop them.

FreeBSD let's me upgrade packages all day long, and until I restart the
service, nothing happens. That way I can upgrade the packages, make sure
everything looks good, then restart the service.

~~~
chousuke
I think packages starting services at install time or restarting them during
upgrades is primarily Debian/Ubuntu weirdness; I don't remember seeing this
behaviour with RedHat or Fedora.

Automatic startup on install is supremely annoying. There's a way to disable
it on Debian at least, but it's terrible as default behaviour

~~~
cryptonector
SVR4 pkgs could and did do this too. I don't think it's so out of the
mainstream, but it does suck.

~~~
Annatar
Well, considering I’m the one with 74000 servers here for whom this automatic
restart via package postinstall works and works wonderfully, we are going to
disagree and I’m going to continue doing what I’m doing the way I’ve been
doing it for the past 20 years across IRIX, HP-UX and Solaris since it
provides total automation. You’re welcome to continue theorizing but I’m the
one here with a real world use case, and this approach works great. Since this
is my specialty, there is a miniscule chance that I might know what I’m doing
and what I’m writing about, however small and unenviable that chance might be.

~~~
chousuke
I'm curious how that actually works in practice.

Do you package all software by yourself? I mean, if the vendor-provided httpd
package for example started and enabled itself upon installation, how would
you structure your configuration packages so that httpd does not start until
it's actually configured? Or (theoretically) if you needed to deploy a
configuration change and an upgrade simultaneously and can't restart the
software before the new configuration is in place.

I see this being rather easy if the vendor package simply puts the binaries in
place so you can have your own packages run whatever scripts it is you need
and depend on the vendor package, but I don't see how it wouldn't be a
headache if the vendor package contained scripts to manage the service as
well, which is what primarily annoys me on Debian-likes.

~~~
Annatar
The application package delivers only the application payload and integration
with the OS; it does not start anything unless it sees its own processes
running, in which case this must be an in-place upgrade, so restart the
daemon(s) to unload the old and load the new code.

It is the *-conf package which depends on the application package, brings on
the configuration and automatically (re)starts the application.

