[OpenIndiana-discuss] openindiana state
Lou Picciano
loupicciano at comcast.net
Mon Dec 13 16:55:04 UTC 2010
Deano,
I can only contribute to this discussion from the perspective of:
We are in precisely the same boat, one I'd define as:
- Love openIndiana, and the direction it's taking.
- Appreciate it's a lot of work, especially for those most closely involved in the 'core effort'
- Often build a lot of our own stuff
- Would like to contribute materially to the Oi effort, by providing these packages and compiler builds/time/effort...
- Not clear how to start - more specifically, how to 'fit in' most efficiently to the existing framework, both organizational and technical.
- Recognize the project-based constraints; IE, internal guys will often feel it's much faster to 'just do it' than to spend critical time in laying out a mechanism for broader contribution.
(I guess this message, then, stands as 'support' for your position... but doesn't offer much by way of solution, except as a reiteration of an interest in helping!)
Lou Picciano
----- Original Message -----
From: "Deano" <deano at rattie.demon.co.uk>
To: "Discussion list for OpenIndiana" <openindiana-discuss at openindiana.org>
Sent: Monday, December 13, 2010 11:36:39 AM
Subject: Re: [OpenIndiana-discuss] openindiana state
Alan Wrote
> That's partially inherited from OpenSolaris and Solaris before it.
>
> No one at Sun ever built all the consolidations - each was done by its own
> team and while we tried to have some coordination on things like a common
> compiler version, we never worried about all the other details, and
certainly
> never designed a "make World" process or unified set of required packages
> to build them all.
Hmm perhaps rather than complaining, I've found my first item to work on for
OI :) Whilst people are paid to work on a code base, and can pop over to the
build guru cubicle for a quick chat, complex builds aren't that much of a
problem (well until you get told to update one...) but IMHO for open source
projects, the lower the cost to entry the better.
I'm more than happy to have a go but whilst I have many years of experience
with compilers and builds never before have I reached into Solaris country,
so will likely have lots of stupid questions along the way.
The first set of which are perhaps the hardest to answer... Where to start?
I'll use myself as an example, as newbie use cases, for several areas I
wanted/want to get my feet wet in.
Use case 1:
Wanted to make a small tighter build, as looking to take OI into production.
Classic reduce the attack vector optimizations, for that I want to remove a
whole bunch of stuff, kermel modules, drivers and applications. This is more
of distribution issue rather than build environment issue, but a debootstrap
style minimal install is a great place to start to create custom JEOSs. As
OI is so new, the smaller its footprint in production the better whilst it
stabilizes.
Use case 2:
Install fresh OI 147/148 and doesn't quite support a piece of hardware. So
want to write/fix a driver. What should the package I download (IPS?)
contain to allow me to do that? Is it purely enough to have a compileable
Illumos environment? Or is Illumos itself fractured so that its better to go
into Illumos first and make it work with a smallest set of requirements?
Or... am I barking up the wrong tree? And driver writing is doable somehow
else?
Use case 3:
Installed fresh OI 147/148 and want to compile and run latest version of
popular open source programs (for example Nginx), perhaps port and optimize
for the OI platform. This is I think already covered somewhat by the GNU
packages but even that gets confusing as there are several and have pathing
issues.
All these use cases are ideal candidates, to make easier to get started, as
they are all fairly usual entry points for new developers.
Any thoughts?
Deano
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss at openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
More information about the OpenIndiana-discuss
mailing list