Hi,
I am transferring some posted "showstopper" questions and ideas from OI,
I am sure they would get better answered on illumos list:
On 02/28/15 12:22 PM, Bruce Lilly wrote:
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.
The question about SMF and XML is a question for illumos.
I am sure there are some workarounds that can make life easier.
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...
I have one 32bit driver working on 32-bit only laptop, for Marvel yukon.
Since Solaris drivers (expecially network ones) tend to work for a long
time on newer releases (like from S8 on today's illumos - think no other
platform but maybe windows could beat that actually)
Otherwise, it is illumos question.
Regarding abandoning Linux due to systemd:
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).
Seems like that systemd thing on Linux , e.g. moving away from it is
like catching up.
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.
Oscillators issue aside (surely there are also some modern hardware
solutions these days), and with the fact there are still PCI-e x1 serial
port cards,
I understand what you are saying, you need _stable_ supported illumos
distro that would fit your memory requirements, to do it's job and to
have long time support for critical issues.
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).
This is truly question for illumos.
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.
It is true on x86, that 64-bit implementation invented at AMD has
performance beneits over 32bit,
only I would remind that it is not the case for SPARC, where 32-bit is
faster, so maybe it's something in that line of doing things the same
way on both platforms
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).
I like ability for same DVD/Usb to work on both 32bit and 64bit hardware
very much.
And pointing that both 64 and 32bit binaries work fine from same install.
Questioning about abandoning 32bit, put all those nice,unique things in
danger.
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.
This is clearly illumos question.
It could be contributed to it, but surely illumos guys are to answer it.
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.
This is also illumos question.
Might be best to ask, how to keep promise of compatibility with old
binaries and to move things forward with core tools. Maybe illumos
branded zones or something else.
-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com
