[oi-dev] Desktop Illumos Still Matters

[Andrew M. Hettinger]

My thoughts. Remember, they are probably only worth what you paid for
them! ;p

Nick Zivkovic <zivkovic.nick at gmail.com> wrote on 09/01/2012 10:42:14 AM:
>
> Yes. I am more interested in contributing drivers and the like. As far
> as packages go, to be honest, I've experienced torture at the hands of
> IPS (though that could very easily be my fault), and am reluctant go
> near it. For example I tried an image-update and it failed. So I am
> stuck on OI-147 until I backup-reinstall-import to OI-151a.
>
> I think packages are a high priority, but not as high as making sure
> the latest illumos-gate can build and run on a modern desktop. For
> example, I can't get SmartOS running on a thinkpad or my desktop
> computer. Somewhere in June 2012, a bug was introduced that prevents
> the illumos kernel from booting. If I had been building and testing
> the latest source, that bug could probably have been caught before it
> got buried in a mountain of commits. Now, I image, it is like finding
> a needle in a haystack.
>
> I am willing to assist with packages, but my time is limited, and I
> think it is more important to direct my effort to building
> illumos-gate and writing drivers. Also, making packages is still a
> black art to me, and wouldn't know where to start.

One of the biggest issues here isn't that packages are particularly HARD to
make with IPS (they aren't). It's that there are about three different
approaches to it, and we need to get that standardized. Many of the
packages are tied up in the consolidations, which DO seem to have a high
barrier to entry. I considered putting together a source-juicer-like
self-service system for building packages. If I can get the time, I'll
revisit that. It would make my (and everyone else's, I think) life easier.

> But since we are already on the topic of packages, Adam, do you think
> there is a way to make it less painful, more consistent? I'm _not_
> talking about extreme measures like changing from IPS to
> [DEB/RPM/SVR/etc]. I'm wondering if we could 1) make IPS easier to use
> by documenting stuff in an easily accessible way [the man pages aren't
> very helpful]

The wiki would be an ideal place for this to happen. Frankly, I haven't see
much trouble with the man pages from a user perspective, but from the
developer's side, it could definitely use some work. Much of this was
documented in the OS.o site, but we need to not depend on that.

> 2) document every single IPS failure and either fix the
> packages or the IPS code (depend on what caused the failure), and

First thought here is that it needs to be in the bug tracker, but that may
not be easily accessible either. Maybe a sub-page on the wiki?

> 3)
> have IPS install all userland libs to a zfs dataset named rpool/ips or
> rpool/pkgs; this way, we can zfs-send these datasets, and snap-shot
> them, and clone them, without pulling in the rest of the file-system
> heirarchy. This would make my bitterness toward IPS reduce
> significantly. This way, you can migrate different user-land configs
> between systems. Also, an easy way to do updates across a multitude of
> systems. One can share their binaries and packages via zfs-send,
> because they won't destroy an existing system's /usr /bin and so
> forth. Also, OI would benefit tremendously from offering pre-made NG
> zones on the web-site, available for downloading and running. In fact,
> we could use Zones as a delivery mechanism for things like an Illumos
> build-environment. An NG zone can contain a working and sandboxed
> version of firefox. Zones are a great technology that can make the
> system more attractive amateur power users who may become programmers
> some day (like I did). Multiple ways of sharing pre-compiled binaries
> can only help OI and Illumos. In fact I can see people sharing
> datasets with packages via bit-torrent. Plus, incremental send/recv is
> a huge benefit.

Back in the bad-old-days, (if memory serves) a basic copy of userland was
kept in /bin and /sbin that did not depend on anything. This was done to
allow you to NFS mount everything else. IIRC the decision was made to go
ahead and make them dynamicly linked because noone NFS mounts them anymore
anyway, and it meant we had to keep both a simplified and full version of
the programs. I think this will encounter many similar issues as that. If
we are going back down this road, we could consider just delivering a /bin
and /sbin we can use as you propose. It would have the advantage of
bringing back this lost (albit rarely used) functionality.

That said, there is nothing stopping anyone from delivering a basic
userland in /rpool/pkgs, although I would suggest using an alternate mount
point in /usr (/usr/zdu or some-such? solaris has a long history of
delivering alternate userlands in filesystems off of /usr).

> We might even be able to integrate a window manager (like i3 or dwm)
> so that switching virtual desktop, actually switches to another zone.

Can you do this in zones? Frankly, all my other zones have always been on
the commandline for build environments and such, so I don't know. Zones are
already pretty sweet in my book, but if something like this is already
there, that's a whole other level.

> What kind of changes to IPS are OI willing to accept? I am willing to
> test and improve a lot of code. As I said, I dislike IPS. But I am
> willing to help make it better and more usable.

It might be good if you could say what you have in mind. I don't believe we
are particularly wedded to what Oracle does anymore, so if you have ideas
speak up!

> Also, a major problem with IPS is that Sun encouraged people to use it
> to _consume_ packages, but they didn't encourage people to _create_
> packages. We need a self-fueling ecosystem of packages.

That's not completely true. Sun did encourage package creation, that's what
Source Juicer was about. It was marginally effective, there where a number
of us outsiders who did contribute packages that way. It was just soo damn
easy, it was almost harder to NOT contribute! I strongly think we need
something like that back. I'll see what I can hack up, and see if we are
interested in officially supporting something like that when I am done.

OTOH the way they handled consolidations is a nightmare that we inherited,
but I'm not sure I know how to fix it. Many wiser then I have tried, and it
seems to always end in tears.

> I also think that SmartOS's diskless boot model is great. I think that
> booting from disk is great too. Shouldn't OI support both? I'm willing
> to contribute to this.

Personlly, I'm not interested in a diskless boot model. I think it's highly
niche, and I think SmartOS does a fine job there. In purposing the work for
that, I have to ask, what compelling element do we bring to the table?

> I know these ideas come from SmartOS to some extent, but they are
> great ideas that could make OI better! Making a new distribution is
> one way to try to make things better. But I think a metamorphosis in
> the OI distro will be more effective. I want the many Illumos distros
> to be held up as an example of triumphant collaboration, 5 years from
> now. But that will happen only if we avoid going down the path of
> NIH-inspired suicide.

I don't want an NIH-fest either, but I also think we need to be pragmatic.
I don't want to compete with SmartOS on diskless, unless we have something
to really offer. They are doing one thing and doing it well. As much as I
don't want to die to NIH, I also don't want us to be a jack-of-all-trades,
and a master of none.

> So, in short I am willing to contribute, to OpenIndiana and Illumos. I
> will get OI-151 installed today or tomorrow.
>
> I will try to build illumos-gate, and will report back with any problems.
>
> I would appreciate any pointers on making new packages.
>
> Is it possible to make a new zone without an internet connection?

The short answer is no. The long answer is kinda.

If you have a local IPS mirror, you can point it at that. There are
instructions on mirroring the repo here

http://wiki.openindiana.org/oi/Mirroring
+OpenIndiana#MirroringOpenIndiana-Oldcontentfollows

I know it's not ideal, but it is what it is.

> Where can I find the OI plans for future IPS features and improvements.

There hasn't been a lot of discussion about future improvements. I think
there has been someone looking at improving performance, but I can't recall
who right now.

>  Also, I don't know if this is available in your repos, but if not, I
> am going to port and package the i3 window manager for OI, if I have
> trouble I'll let you guys know.
>
> I am going to see what I can do about pre-built NG zones.
>
> I will try to find resources about NG zones, making new brands,
> modifying existing brands, etc.

Sweet! Although, I'm not sure what a new brand would be required for,
although I'll admit I've only been a user of zones, not looked at how it is
written in-depth.

> Also, I recommend updating the mission statement on the web page. It
> is "coming soon", and not very inspiring.
>
> I recommend something along the lines of "making cutting edge
> technology available to power users on the desktop..." and then
> advertise the technologies. Trust me, it is the power users, not the
> simple desktop users that you want. Basically an incubator for future
> illumos devs, and a platform for those who like to play with cool tech
> they won't get anywhere else.

I have the required permission to do this, but I am loathe to make changes
without some kind of meeting or at least an on-list vote to approve the
specifics. Maybe if you have something in mind you could toss it up, and
someone could approve it (AFAICT, I don't even have the authority to vote,
let alone make a unilateral decision). Otherwise I'll bang something out.

> Thanks.
>

*snipped stuff I wasn't responding to in the interests of brevity*

Andrew Hettinger
http://Prominic.NET  ||  AHettinger at Prominic.NET
Tel:  866.339.3169 (toll free) -or- +1.217.356.2888 x.110 (int'l)
Fax: 866.372.3356 (toll free) -or- +1.217.356.3356            (int'l)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20120904/08d7ce61/attachment-0005.html>