[OpenIndiana-discuss] forum creation

[Nikola M]

On 02/28/15 12:22 PM, Bruce Lilly wrote:
> 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.

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.