On 02/28/15 12:22 PM, Bruce Lilly wrote:
On Thu, Feb 26, 2015 at 7:31 PM, Nikola M <minik...@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.
Hi, thank you for your valuable insights.
We diverged from previous topic, (and I hope we'll continue at illumos)
but I wanted it, I got it :P
They cold be transferred to project ideas
My answers on this are obviously off-topic reagarding "forum creation"
and I would transfer all at least illumos-related ideas to illumos list.
The question about SMF and XML is a question for illumos.
I am sure there are some workarounds that can make life easier.
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.
Seems like that systemd thing on Linux , e.g. moving away from it is
like catching up.
while also many people would stay with their distros without realizing
that something changed.
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 OI - think no other
platform but maybe windows could beat that actually) I would be pretty
sure I could rely on that for some time (or change Gigabit LAN card if
in doubt, they are cheap).
Otherwise, it is illumos question.
Minimum system requirements are unclear; one place says 512MB RAM, another
says 768MB.
Answers to this kind of questions could not be answered currently on OI,
because Hipster does not value stable releases. (but could be made to do
so with releasing stable) You also mentioned 32-bit killing attitude
etc, so it could improve if OI have some kind of updatable /dev release
that is Atm in stage of an idea.
Opensolaris truly stated 512MB minimum, and with GUI, but that was in
2009.6.days.
I wouldn't count on using Solaris descendent installs (especially with
ZFS) on low end machines.
Maybe they could be tweaked but Solarises are mostly better with
partitioning larger iron with zones , zfs datasets, etc, then with
entry-level configs.
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.
Maybe people are also willing to pay for that kind of long time support,
too. It is interesting thing to consider because it seems as worth.
People tend to vote with their actions and their wallet.
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.
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!).
Yeah, I try to explain that it is wrong, especially in this state of OI
and that there is need to support at least stable 32-bit version for a
few years, before that, but I am always reminded that "users who are not
devs do not get asked" (who's asked then??) and I don' like that general
attitude.
Recent changes in Hipster "just removed" all support for 32-bit
only-graphics drivers and that's kind of unneeded and clearly going
strange way in a sense of managing things.
Maybe devising "stable" or at least "suported" /dev update release is
truly solution for this.
Graphics drivers support is a turning stone for distributions that
foster some Desktop environment.
I was on verge of abandoning OI/Hipster myself few days ago, but
freezing X server and intel driver from 20141010 worked for me on
updated Hipster-2015.
Such things truly are showstoppers, because, at my opinion, _I don't
count distro is even existing if it does not have some Graphical support
and at least some kind of desktop environment on it._
Weither one is using it or not or starting it by default on boot is
beside point.
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 current OI state of SPARC hardware availability is non-existant as
a platform.
Just to mention, SPARC machine from T2 line or so can be hosted if made
available at UK.
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.
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.
I think I have seen packages built separately as being explicitly 64bit
so one can choose them for install etc.
Maybe also building 64bit binaries by default contradicts request of
keeping 32bit support.
32bit binaries would continue to be suported and who needs 64-bit is
free to make 64bit packages he needs.
Actually no one mentioned not supporting 32-bit binaries in illumos,
they are here to stay for a long time.
illumos actually plan to abandon 32-bit hardware and stop developing
kernel support for it in the future,
but applications are expected to keep working.
Likewise OI would do the same but it is surely too early for killing
32bit hardware support, without supported OI release for 32bit.
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.
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).
Maybe pkgsrc could be made available also on OI, exactly re-using
SmartOS and installing somewhere in /opt/pkgsrc or something. If you
like it maybe you could contribute it to OI.
Or as a first step toward writing or refreshing .spec files and turning
them in publisher for IPS.
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.
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.
ok :) I just don't expect that any 32bit running machine to keeps
running with existing hardware till past 2038. I suppose hardware would
fail many times before that daate.
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.
I am generally not an optimistic that OI is going in a way of supporting
older platforms for a long time, without major intervention and
contribution from people like you in that way.
(Especially in making stable OI release or at least updatable /dev release.
Contribution paths are open and people are free to contribute changes,
migrate and keep things the way they like , infrastructure for building
and publishing is available , we still have company sponsoring OI dev
servers. So if One like illumos based distro, OI, it could recommend
project or include himself in ironing things out according to it's own
requests.
Ideas are a good start, actually ;)
Thanks Bruce and you can continue on illumos-discuss.
I am transferring your illumos-related questions to illumos-discuss list,
so you/we can continue there or at least send a message about your
comments.
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
