[OpenIndiana-discuss] forum creation

[Bruce Lilly]

On Thu, Feb 26, 2015 at 7:31 PM, Nikola M <minikola at gmail.com> wrote:

> Regarding managing services on Unix-like OSes, illumos and Opensolaris
> descendent OS'es enjoy Service management Facility (SMF), maybe you could
> comment how it stand for you, comparing to other service management ways
> you mentioned? If you have OI installed, you could try it out. (And see if
> it could be improved).
>

SMF is mostly OK after the usual learning curve.
What's not OK:
1. XML sucks
2. "Restarting too quickly" seems to happen too frequently for some
services on reboot (usually for services where the daemon forks).
3. Poor support for conversion from init scripts (and XML sucks).
http://wiki.loopback.org/index.php/How_to_add_a_service_to_svc helps, but
XML sucks.

Aha and not to forget, if you do name "critical things that seems to be
> ignored", at your opinion,
> I am sure we'll all be much obliged , because that's kind of things that
> are needed to make fire star :)
>

Some background to keep things in perspective:
I've used mostly System V and System V-like systems for a long time, so
OpenIndiana had an advantage (over e.g. BSD and BSD-like systems with their
peculiar make, peculiar ps, oddball shells, etc.).
A few decades ago, somebody convinced me to try Linux instead of spending
$75 on an OpenSolaris license, so I've been using mostly Linux systems
since then.
After trying a few others, I settled on SuSE, later openSUSE.
Systemd has broken too many things, too many times, and is wasting too much
of my time fixing and re-fixing things that shouldn't have been broken in
the first place; and alternatives (e.g. sysvinit) have been dropped).
The one fast, reliable, stable journaled filesystem previously supported on
openSUSE (viz. Reiserfs) has been dropped.
So it's time to move on.

One issue with OpenIndiana encountered early on is limited networking
driver support; specifically, OpenIndiana has no built-in support for
Marvell "yukon" series Gigiabit Ethernet.
I was able to find a Solaris driver from Marvell's web site, burn it to
physical media, and sneakernet it; it works, but I wonder whether it will
continue to work for future releases...

Minimum system requirements are unclear; one place says 512MB RAM, another
says 768MB.
I have 4 32-bit (Pentium III, actually) machines which have *very* stable
oscillators serving as NTP servers. They are equipped with the maximum
amount of RAM supported by the motherboard -- 512 MB.
So that's a critical issue (those machines have run Linux (including GUI),
and 3 of the four currently run NetBSD).
I have not found any similarly stable machines to replace those, so they'll
keep running "forever" as my primary ntp servers.
All four use PPS signals from GPS, so require (and have) real serial ports;
the trend on newer hardware is to abandon real serial ports in favor of
polled once every million-or-so nanoseconds USB with its 57 flavors of
connector variants, and that won't work for PPS.

32-bit and 64-bit issues with OpenIndiana are a major problem.
The 32-bit time_t issue arrives in just a few years (NetBSD has already
solved this on 32- and 64-bit systems).
Some in the OI community seem to be of the opinion that all 32-bit systems
will magically disappear; they won't (see above).
Some seem to be working actively to kill 32-bit support (e.g. on this list
within the past 24 hours!).
Even if 32-bit hardware vanished and 32-bit OS support were dropped, the
issue would remain because the default for building executables -- on
64-bit systems, mind you -- is to produce 32-bit executables.
Even though 64-bit code has performance advantages.
Even though there is support for selecting 32-bit or 64-bit executables at
run-time (isaexec, sometimes called a hack, but it works and being able to
put one ISO disk in 32- or 64-bit systems to load the OS is a nice feature).
Sure, it's possible to force building 64-bit code with -m64 -- but try
linking that code with (for example) the 32-bit only libgamin library; NG.
So to really get 64-bit code, one has to build all needed libraries (and
their dependencies) from source, with -m64; there ought to be a better way.
This was a show-stopper; I need to support 32-bit systems with limited RAM
for critical functions that have to continue to work past January 19, 2038.
And I don't want to have to build every damned library from source to get
64-bit versions on 64-bit systems.

Lack of support for hardware monitoring is another major issue.
The illumos web site lists as a possible project porting lm-sensors.
When I last looked (until just now, and I see it's changed (slightly)),
contributing required a build environment using an unobtainable compiler
and toolchain; so that was a dead end.
So I tried to at least get temperature data from SMART-equipped hard disk
drives.
No port of hddtemp.
smartmontools doesn't work for IDE drives.
smartmontools really doesn't work for SATA drives even though it's claimed
to work (it doesn't because the driver for SATA drives (on SATA-only
motherboards, no less!) is pci-ide, and that's the part that doesn't work).
So no hardware monitoring at all, not even basic temperature information.
Another show-stopper.

I wasn't able to find anything about support for CPU power management
(frequency scaling), but in light of the other issues, I haven't looked
very hard.

Software packages and management is a mish-mash.  Some packages are
supported with pkg, but there's also OpenCSW and the Joyent/SmartOS
pkgsrc/pkgin stuff (interestingly, pkgsrc was developed for NetBSD).

And there's a bunch of niggling little annoyances.
For example, cron has a hard-coded /sbin:/bin path, and /bin/awk is an
ancient broken version, so simply running an awk script via cron requires
extraordinary measures to work around those issues.

Everything else, Netbsd is missing even more :P


Despite my aversion to BSD make, BSD ps, and broken shells, those are
easily worked around via pkgsrc/pkgin gmake, heirloom-ps, ast-ksh, etc.
smartmontools works, so I have at least basic temperature hardware
monitoring.
Runs fine on 32-bit systems with 512 MB RAM, and will continue to do so
past 2038.
Separate ISOs needed to install on 32-bit and 64-bit systems, but the
64-bit systems have true 64-bit code and default builds from source on
64-bit systems produce 64-bit code.