Re: [oi-dev] OI Project

[Aurélien Larcher]

Hi,
Welcome!


> I was wondering if you guys are looking for contributors. I have been
> looking for a project to get involved into and I fell in love with Oi ever
> since I learned of it.


Yes we are always happy to welcome new contributors. :)


> Who am I? I am no developer as I am only learning C and would not dare
> call myself as one. But I am persistent and committed and I would love to
> get involved in some way, maybe some easy bite-size tasks which would help
> me along with learning C. Or some other way, something that needs
> addressing?
>

There are different areas of contribution:
1) Documentation
2) Packaging
3) Development

I wrote a Community page to describe this briefly:
https://www.openindiana.org/community/

Depending on your interests you can contribute in any of these areas.
I have a personal TODO list when it comes to Xorg and compilers (they are
mainly packaging and porting bits), and there are other tasks on the menu
(to be completed):

https://www.openindiana.org/overview/roadmap/

Depending on what is your focus (desktop, server) we can certainly make
suggestions.

When it comes to development in C, I think Alexander had ideas for
improving the Installer, ... there is also better integration of the ZFS
snapshot browser in Caja, better integration of Pulseaudio with the OSS4
implementation found in illumos, resurrecting the package manager GUI
(Python/C) ...
I am also in contact with an Enlightenment developer who is interested in
having better support on illumos. I do not have time to work on it myself
but this is also a possibility.

Feel free to discuss your ideas on the mailing list :)

Kind regards

Aurelien

>
>
> Let me know your thoughts.
>
>
>
> Regards
>
>
>
> Cezary
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
>



-- 
---
Praise the Caffeine embeddings
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] OI Project

[Cezary Podbilski via oi-dev]

Hello Oi community


I was wondering if you guys are looking for contributors. I have been looking 
for a project to get involved into and I fell in love with Oi ever since I 
learned of it. Who am I? I am no developer as I am only learning C and would 
not dare call myself as one. But I am persistent and committed and I would love 
to get involved in some way, maybe some easy bite-size tasks which would help 
me along with learning C. Or some other way, something that needs addressing?


Let me know your thoughts.



Regards



Cezary

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Bob Friesenhahn]

On Sun, 12 May 2013, Garrett D'Amore wrote:


We're going to have to support a 32-bit userland for some time to 
come, unfortunately, but we should no longer make that the default, 
and we should deliver all of our system utilities in 64-bit only 
form, IMO; and we could entirely kill off the 32-bit kernel.


If 32-bit userland is no longer the default, then GCC should start 
producing 64-bit code by default.  Currently GCC does not seem to 
support being compiled to produce 64-bit code by default (at least 
last I tried doing that).  GNU libtool needs a small patch to compile 
64-bit C++ code with working exceptions support.


Probably quite a lot of Solaris-targeted user-space code has issues 
when compiled for 64-bit because it was not compiled that way before.


The GCC that comes with 64-bit Linux systems produces 64-bit code by 
default, but is capable of compiling 32-bit code.


The OpenIndiana/Illumos folks would need to work with the GCC folks to 
make sure that a GCC can be built which produces 64-bit by default.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Marion Hakanson]

garrett.dam...@dey-sys.com said:
> So, out of curiosity -- *who* is actively running illumos on 32-bit kit
> today?  I'm not interested in hypothetical uses or kit that is sitting around
> in your garage waiting for you to do something with it…. I'm interested in
> people who would be immediately impacted and severely so if illumos were not
> available on 32-bit CPUs right now.  (To give a counter example: I have a
> 32-bit Atom netbook, that I have OpenIndiana on.   I turn it on once every
> year or so… if that often … so I can't seriously claim that I would be
> negatively impacted if illumos were to move to 64-bit only.) 

And,

garrett.dam...@dey-sys.com said:
> Older hardware must be *really* old.  Over 5 years.  For servers, probably
> over 10 years.  I've thrown away my Pentiums and Pentium IIs.  I suppose
> there could be some Pentium IIIs and IVs out there, or AMD Athlons
> (pre-Athlon64), but they'd all be really really slow by today's standards.
> Do people run illumos on such kit?  I'm highly doubtful, unless that kit is
> around just to answer the question of whether 32-bit kernels still work. :-) 

I do.  Been running OI on my Pentium IV 2.8GHz machine since oi148, which
is when I converted it from Solaris-10.  It has 2GB RAM and a couple 1TB
drives in a mirror acting as ZFS backup server for other family members'
Mac's, and also gets used daily as my personal home desktop machine (Firefox,
Thunderbird, OpenOffice, xsane, gimp, exmh/MH, rcs/svn, wireshark, etc).  And,
it runs a Solaris-10 zone brought forward to run two binaries I haven't yet
found the time to port/compile on OI, gnucash and gnome-perfmeter.

But hey, don't let me hold up progress.  I'm used to feeling like the last
person in the world still using a Solaris-based desktop.  If I had the money,
I'd replace it.  I ran Solaris-x86 on my previous home machine for about 10
years before replacing it with the present one, so I guess I'm nearly due.
Spent my entire career working in the non-profit sector, and my Dad had a
rock crusher in his business that was about 90 years old when he retired it,
so I'm pretty much doomed to be a Junk-Whisperer (:-)

Regards,

Marion



___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Udo Grabowski (IMK)]

On 12/05/2013 00:17, Garrett D'Amore wrote:

But nobody else has built a compelling Linux or Unix desktop with a reason to exist 
besides being "free".

> And there is no commercial value in just being "free" ...

But there are other values than commercial values; i.e.,
being "free" OI is not a commercial distribution and
was started with that reason, being a noncommercial distribution.
The desktop/workstation is NOT dead (I can't imagine doing
science on a tablet, really!), that's just commercial wishful
thinking. This all sounds like you have attended a Bilderberg
conference on killing Open Source desktop software...




smime.p7s
Description: S/MIME Cryptographic Signature
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Christopher Chan]

On Sunday, May 12, 2013 06:17 AM, Garrett D'Amore wrote:

The exception here is the Chromebook experience and OLPC…. they were able to do something cool and 
make a compelling argument.  But nobody else has built a compelling Linux or Unix desktop with a 
reason to exist besides being "free".  And there is no commercial value in just being 
"free" -- you can't make up in volume unless you have some revenue. :-)

It's ironic that Chromebook appears to have fulfilled the meme "the 
network is the computer"


Innovation is a weird creature.

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[G B]

To move OI forward I think 32-bit kernels should be dropped.  I had been 
looking for alternatives for my web/mail servers but have always liked 
Solaris and would like to continue to leverage my knowledge and have 
mostly decided to go with OI.




 From: Garrett D'Amore 
To: OpenIndiana Developer mailing list  
Cc: "oi-dev@openindiana.org"  
Sent: Sunday, May 12, 2013 5:14 PM
Subject: Re: [oi-dev] OI project reboot required
 

Don't misunderstand me.  I want to eliminate 32 bit kernels and delivery of 
certain 32 bit versions of system utilities. This should in no way affect any 
3rd party apps.  We need to keep the 32 bit app runtime for the foreseeable 
future. 

Sent from my iPhone

On May 12, 2013, at 12:51 PM, "Nikola M."  wrote:

> On 05/12/13 07:10 PM, Garrett D'Amore wrote:
>> On May 12, 2013, at 9:02 AM, Jim Klimov  wrote:
>> 
>>> 
>>> I believe, 32-bit should be retained. While it is of little utility
>>> for ZFS and other huge-RAM jobs, it may be required for some netbooks,
>>> older hardware repurposed for tests and SOHO servers, as well as for
>>> resource-constrained testing VMs. So I'd vouch for this fork/patch
>>> approach if this upstream is still followed.
>> We've been doing this for years now.  I'm now starting to think -- 3 years 
>> later on -- that this argument feels specious today.  Who runs illumos on a 
>> netbook?  I did, once.  Not any more.  (And modern netbooks have 64 bit 
>> support!)
>> 
>> Older hardware must be *really* old.  Over 5 years.  For servers, probably 
>> over 10 years.  I've thrown away my Pentiums and Pentium IIs.  I suppose 
>> there could be some Pentium IIIs and IVs out there, or AMD Athlons 
>> (pre-Athlon64), but they'd all be really really slow by today's standards.  
>> Do people run illumos on such kit?  I'm highly doubtful, unless that kit is 
>> around just to answer the question of whether 32-bit kernels still work. :-)
> Maybe it's called backward compatibility. I think Firefox and
> Thunderbird are 32-bit. Isn't the Multiarch what defined Solaris, like
> always? I don't want we should loose Solris10 zone if someone needs that
> in some moments untill some moment in the future. (There are still
> people not migrated from S10)
> 
> There is still many older computers that could be useful with Illumos
> distro.
> Some Oracle decisions are a bit also insane, like removing support for
> Floppy disk (why removing when not already used much) and support for
> Smart card identification for a Workstation/server.
> 
> Openindiana, Illumos have also an advantage of supporting older
> hardware, that Oracle removed support for.
> We should not forget that market of people using Just FINE servers that
> large corporations throw out but could be used for years.
> Removing support for still widest-supported architecture on the planet
> could be a bit short-sighted in our current market position (not
> counting those high-end cloud Illumos consumers, but ordinary people).
> If there is some netbook that needs to be used, or older but fine
> notebook as a control console, Illumos distro could work on it for
> years, since one of the `advantages` of slow development moving of
> Illumos could be lower need of changing hardware over years. Or bigger
> stability and backward compatibility.
> 
> Of course, nothing is set in the stone, it will be how developers want.
> If 32-bit needs to be moved to separate place or cut of from newest
> advanced be it. But not if it is not necessary.
> 
> GDA: Will there ever be "Release" or "Version" of Illumos? Unlike
> current rolling-releases?
> Will Illumos ABI,API remain stable, like on Solaris?
> 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[G B]

To move OI forward I think 32-bit kernels should be dropped.  I had been 
looking for alternatives for my web/mail servers but have always liked Solaris 
and would like to continue to leverage my knowledge and have mostly decided to 
go with OI.





 From: Garrett D'Amore 
To: OpenIndiana Developer mailing list  
Cc: "oi-dev@openindiana.org"  
Sent: Sunday, May 12, 2013 5:14 PM
Subject: Re: [oi-dev] OI project reboot required
 

Don't misunderstand me.  I want to eliminate 32 bit kernels and delivery of 
certain 32 bit versions of system utilities. This should in no way affect any 
3rd party apps.  We need to keep the 32 bit app runtime for the foreseeable 
future. 

Sent from my iPhone

On May 12, 2013, at 12:51 PM, "Nikola M."  wrote:

> On 05/12/13 07:10 PM, Garrett D'Amore wrote:
>> On May 12, 2013, at 9:02 AM, Jim Klimov  wrote:
>> 
>>> 
>>> I believe, 32-bit should be retained. While it is of little utility
>>> for ZFS and other huge-RAM jobs, it may be required for some netbooks,
>>> older hardware repurposed for tests and SOHO servers, as well as for
>>> resource-constrained testing VMs. So I'd vouch for this fork/patch
>>> approach if this upstream is still followed.
>> We've been doing this for years now.  I'm now starting to think -- 3 years 
>> later on -- that this argument feels specious today.  Who runs illumos on a 
>> netbook?  I did, once.  Not any more.  (And modern netbooks have 64 bit 
>> support!)
>> 
>> Older hardware must be *really* old.  Over 5 years.  For servers, probably 
>> over 10 years.  I've thrown away my Pentiums and Pentium IIs.  I suppose 
>> there could be some Pentium IIIs and IVs out there, or AMD Athlons 
>> (pre-Athlon64), but they'd all be really really slow by today's standards.  
>> Do people run illumos on such kit?  I'm highly doubtful, unless that kit is 
>> around just to answer the question of whether 32-bit kernels still work. :-)
> Maybe it's called backward compatibility. I think Firefox and
> Thunderbird are 32-bit. Isn't the Multiarch what defined Solaris, like
> always? I don't want we should loose Solris10 zone if someone needs that
> in some moments untill some moment in the future. (There are still
> people not migrated from S10)
> 
> There is still many older computers that could be useful with Illumos
> distro.
> Some Oracle decisions are a bit also insane, like removing support for
> Floppy disk (why removing when not already used much) and support for
> Smart card identification for a Workstation/server.
> 
> Openindiana, Illumos have also an advantage of supporting older
> hardware, that Oracle removed support for.
> We should not forget that market of people using Just FINE servers that
> large corporations throw out but could be used for years.
> Removing support for still widest-supported architecture on the planet
> could be a bit short-sighted in our current market position (not
> counting those high-end cloud Illumos consumers, but ordinary people).
> If there is some netbook that needs to be used, or older but fine
> notebook as a control console, Illumos distro could work on it for
> years, since one of the `advantages` of slow development moving of
> Illumos could be lower need of changing hardware over years. Or bigger
> stability and backward compatibility.
> 
> Of course, nothing is set in the stone, it will be how developers want.
> If 32-bit needs to be moved to separate place or cut of from newest
> advanced be it. But not if it is not necessary.
> 
> GDA: Will there ever be "Release" or "Version" of Illumos? Unlike
> current rolling-releases?
> Will Illumos ABI,API remain stable, like on Solaris?
> 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Garrett D'Amore]

Don't misunderstand me.  I want to eliminate 32 bit kernels and delivery of 
certain 32 bit versions of system utilities. This should in no way affect any 
3rd party apps.  We need to keep the 32 bit app runtime for the foreseeable 
future. 

Sent from my iPhone

On May 12, 2013, at 12:51 PM, "Nikola M."  wrote:

> On 05/12/13 07:10 PM, Garrett D'Amore wrote:
>> On May 12, 2013, at 9:02 AM, Jim Klimov  wrote:
>> 
>>> 
>>> I believe, 32-bit should be retained. While it is of little utility
>>> for ZFS and other huge-RAM jobs, it may be required for some netbooks,
>>> older hardware repurposed for tests and SOHO servers, as well as for
>>> resource-constrained testing VMs. So I'd vouch for this fork/patch
>>> approach if this upstream is still followed.
>> We've been doing this for years now.  I'm now starting to think -- 3 years 
>> later on -- that this argument feels specious today.  Who runs illumos on a 
>> netbook?  I did, once.  Not any more.  (And modern netbooks have 64 bit 
>> support!)
>> 
>> Older hardware must be *really* old.  Over 5 years.  For servers, probably 
>> over 10 years.  I've thrown away my Pentiums and Pentium IIs.  I suppose 
>> there could be some Pentium IIIs and IVs out there, or AMD Athlons 
>> (pre-Athlon64), but they'd all be really really slow by today's standards.  
>> Do people run illumos on such kit?  I'm highly doubtful, unless that kit is 
>> around just to answer the question of whether 32-bit kernels still work. :-)
> Maybe it's called backward compatibility. I think Firefox and
> Thunderbird are 32-bit. Isn't the Multiarch what defined Solaris, like
> always? I don't want we should loose Solris10 zone if someone needs that
> in some moments untill some moment in the future. (There are still
> people not migrated from S10)
> 
> There is still many older computers that could be useful with Illumos
> distro.
> Some Oracle decisions are a bit also insane, like removing support for
> Floppy disk (why removing when not already used much) and support for
> Smart card identification for a Workstation/server.
> 
> Openindiana, Illumos have also an advantage of supporting older
> hardware, that Oracle removed support for.
> We should not forget that market of people using Just FINE servers that
> large corporations throw out but could be used for years.
> Removing support for still widest-supported architecture on the planet
> could be a bit short-sighted in our current market position (not
> counting those high-end cloud Illumos consumers, but ordinary people).
> If there is some netbook that needs to be used, or older but fine
> notebook as a control console, Illumos distro could work on it for
> years, since one of the `advantages` of slow development moving of
> Illumos could be lower need of changing hardware over years. Or bigger
> stability and backward compatibility.
> 
> Of course, nothing is set in the stone, it will be how developers want.
> If 32-bit needs to be moved to separate place or cut of from newest
> advanced be it. But not if it is not necessary.
> 
> GDA: Will there ever be "Release" or "Version" of Illumos? Unlike
> current rolling-releases?
> Will Illumos ABI,API remain stable, like on Solaris?
> 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Garrett D'Amore]

I have a hard time believing you would choose to switch to Linux instead of 
taking the time to upgrade the hardware.  A two or three year or even five year 
old system will probably be a big upgrade and cost less than the labor to 
switch to Linux. 

Sent from my iPhone

On May 12, 2013, at 12:13 PM, Dmitry Kozhinov  wrote:

> I am running a small web and ftp server at university on a 32-bit AMD Athlon. 
> So I would be affected.
> 
> However I cannot argue for retaining 32-bit support in OI, because any 
> baggage certainly should be dropped in order for OI project to proceed.
> 
> I can upgrade the hardware (unlikely);
> I can switch to Linux (reluctantly).
> 
> - Dmitry.
> 
>> So, out of curiosity -- *who* is actively running illumos on 32-bit kit 
>> today?  I'm not interested in hypothetical uses or kit that is sitting 
>> around in your garage waiting for you to do something with it…. I'm 
>> interested in people who would be immediately impacted and severely so if 
>> illumos were not available on 32-bit CPUs right now.
> 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Nikola M.]

On 05/12/13 07:06 PM, Garrett D'Amore wrote:
> We're going to have to support a 32-bit userland for some time to come, 
> unfortunately, but we should no longer make that the default, and we should 
> deliver all of our system utilities in 64-bit only form, IMO; and we could 
> entirely kill off the 32-bit kernel.
>
> Alternatively, if there is sufficient demand, one could imagine a separate 
> architecture for ia32, that is the 32-bit variant port.  That would not need 
> to carry the 64-bit support.   Admittedly going this route reduces the 
> likelihood of keeping certain bits capable of running 32-bit mode (e.g. 
> device drivers), but one would argue that 32 bit systems are unlikely to 
> adapt new devices, etc.  precisely because they are *so* friggin' old.
>
Not only x86. There is also SPARC with it's 32-bit apps to count for. (I
don't use 32-bit but on Eeepc)
As I understand 32-bit SPARC apps run faster then 64 , unlike on x86
where amd64 apps are faster.
And what about if Illumos starts running/being ported on ARM (64Bit) and
have need of supporting KVMs with tons of 32-bit ARM applications? Will
it also work if 32-bit is ditched right now?
I don't expect 32-bit applications/userland to stop being important so soon.

If multiarch "bitness" priciple is ditched from building Illumos , that
would ditch one thing that is present only on Illumos until now and not
elsewhere.
I guess there is still no 128-bit CPUs? Will multiarch need to be
reinvented when they arrive?


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Nikola M.]

On 05/12/13 07:10 PM, Garrett D'Amore wrote:
> On May 12, 2013, at 9:02 AM, Jim Klimov  wrote:
>
>>
>> I believe, 32-bit should be retained. While it is of little utility
>> for ZFS and other huge-RAM jobs, it may be required for some netbooks,
>> older hardware repurposed for tests and SOHO servers, as well as for
>> resource-constrained testing VMs. So I'd vouch for this fork/patch
>> approach if this upstream is still followed.
> We've been doing this for years now.  I'm now starting to think -- 3 years 
> later on -- that this argument feels specious today.  Who runs illumos on a 
> netbook?  I did, once.  Not any more.  (And modern netbooks have 64 bit 
> support!)
>
> Older hardware must be *really* old.  Over 5 years.  For servers, probably 
> over 10 years.  I've thrown away my Pentiums and Pentium IIs.  I suppose 
> there could be some Pentium IIIs and IVs out there, or AMD Athlons 
> (pre-Athlon64), but they'd all be really really slow by today's standards.  
> Do people run illumos on such kit?  I'm highly doubtful, unless that kit is 
> around just to answer the question of whether 32-bit kernels still work. :-)
Maybe it's called backward compatibility. I think Firefox and
Thunderbird are 32-bit. Isn't the Multiarch what defined Solaris, like
always? I don't want we should loose Solris10 zone if someone needs that
in some moments untill some moment in the future. (There are still
people not migrated from S10)

There is still many older computers that could be useful with Illumos
distro.
Some Oracle decisions are a bit also insane, like removing support for
Floppy disk (why removing when not already used much) and support for
Smart card identification for a Workstation/server.

Openindiana, Illumos have also an advantage of supporting older
hardware, that Oracle removed support for.
We should not forget that market of people using Just FINE servers that
large corporations throw out but could be used for years.
Removing support for still widest-supported architecture on the planet
could be a bit short-sighted in our current market position (not
counting those high-end cloud Illumos consumers, but ordinary people).
If there is some netbook that needs to be used, or older but fine
notebook as a control console, Illumos distro could work on it for
years, since one of the `advantages` of slow development moving of
Illumos could be lower need of changing hardware over years. Or bigger
stability and backward compatibility.

Of course, nothing is set in the stone, it will be how developers want.
If 32-bit needs to be moved to separate place or cut of from newest
advanced be it. But not if it is not necessary.

GDA: Will there ever be "Release" or "Version" of Illumos? Unlike
current rolling-releases?
Will Illumos ABI,API remain stable, like on Solaris?


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Dmitry Kozhinov]

I am running a small web and ftp server at university on a 32-bit AMD 
Athlon. So I would be affected.


However I cannot argue for retaining 32-bit support in OI, because any 
baggage certainly should be dropped in order for OI project to proceed.


I can upgrade the hardware (unlikely);
I can switch to Linux (reluctantly).

- Dmitry.


So, out of curiosity -- *who* is actively running illumos on 32-bit kit today?  
I'm not interested in hypothetical uses or kit that is sitting around in your 
garage waiting for you to do something with it…. I'm interested in people who 
would be immediately impacted and severely so if illumos were not available on 
32-bit CPUs right now.



___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Peter Tribble]

On Sun, May 12, 2013 at 6:06 PM, Garrett D'Amore  wrote:

>
> On May 12, 2013, at 8:51 AM, Alan Coopersmith 
> wrote:
>
> > It has been a few years since Oracle upstream dropped 32-bit i386
> support,
> > so that's just one of the decisions OI has to make - track upstream as is
> > or fork/patch as needed to continue to support 32-bit on i386.
>
> Yep.  And that has sweeping consequences; lots of things depend upon it
> this decision.
>
> I'm of the opinion that enough time has passed that we should seriously
> consider doing the same.  Its been about a decade since  64-bit  x86
> systems came on the scene (Opteron was released in June 2003).
>

I seriously considered killing all support for 32-bit CPUs in Tribblix
from the start. The main reason I didn't is that it's (currently) extra
work to strip out 32-bit from the packages.

I haven't seen a serious use of a 32-bit only CPU in production in over 5
> years.


My OI laptop is 32-bit only. It's on its deathbed, only waiting for me
to find a newer one that Illumos will actually boot and install on.

 And I think most hobbyists upgrade their kit more frequently as well -- I
> have to believe almost everyone is on 64-bit kit these days.  Furthermore,
> most interesting systems (based on illumos) require more memory than is
> practical with a 32-bit only CPU.
>

I think that argument is specious, though. Tribblix gives you a fully
functional graphical desktop in 512M (OK, so you're not going to run
firefox for very long!).

The other area is that "test" or play systems tend to be older ones that
aren't in use for front-line service. That's also an interesting area for
Illmuos distros, as we might be in better shape for driver support on
something that isn't brand new. (As a case in point, none of my available
sparc test systems will run S11, as support for all of them was dropped
as well.) The same is true of people taking home retired office kit, it's
not
new.


> I have to believe we could eliminate a *lot* of baggage by nixing 32-bit
> support.  I *know* we can, because I've nixed a bunch of system utilities
> in our DEY environment that were delivered in both 32 and 64 bit variants.
>

Not to mention simplification by eliminating the isaexec dance.


> We're going to have to support a 32-bit userland for some time to come,
> unfortunately, but we should no longer make that the default, and we should
> deliver all of our system utilities in 64-bit only form, IMO; and we could
> entirely kill off the 32-bit kernel.
>
> Alternatively, if there is sufficient demand, one could imagine a separate
> architecture for ia32, that is the 32-bit variant port.
>

I think the key there is to manage the transition. Provided those who
want to continue with a 32-bit platform are able to do so, I don't see
a problem. But I can imagine distros producing a "final" 32-bit release,
and then moving on. I know I would. It just has to be announced and
planned for - it's really a rather major flag day.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Garrett D'Amore]

On May 12, 2013, at 11:31 AM, Jim Klimov  wrote:

> On 2013-05-12 19:06, Garrett D'Amore wrote:
>> So, out of curiosity -- *who* is actively running illumos on 32-bit kit 
>> today?  I'm not interested in hypothetical uses or kit that is sitting 
>> around in your garage waiting for you to do something with it…. I'm 
>> interested in people who would be immediately impacted and severely so if 
>> illumos were not available on 32-bit CPUs right now.  (To give a counter 
>> example: I have a 32-bit Atom netbook, that I have OpenIndiana on.   I turn 
>> it on once every year or so… if that often … so I can't seriously claim that 
>> I would be negatively impacted if illumos were to move to 64-bit only.)
> 
> Indeed, I can't vouch for such systems, even my old home-NAS which was
> my first victim of illumos/OI endearment had a Pentium-D with x86_64
> support (though likely not virtualization acceleration features -
> which would IIRC require VMs to be 32-bit). This box would be in my
> production today, had it not broken while I am on a prolonged trip
> away from that home; but it won't be impacted by a 64-bit only OS,
> indeed (it did have some VMs for a test farm though, and they might
> be impacted).

Your VMs should be migratable to a more modern hypervisor, if the one you have 
can't run x64.

> 
> Also I know of many small (SOHO) storage boxes which can be made to
> work with OpenSolaris and illumos-based OSes, and of those only the
> HP N36 and N40L have (known to me) 64-bit AMD CPUs and ECC support;
> most other such boxes are built around Atom, and often 32-bit with
> some 2GB RAM. While this is not "interesting" for intensive production
> use, some users of these boxes as reliable (ZFS) home storage might
> be hurt by move to 64-bit only OS. Arguably though, lack of ECC did
> probably burn my home-NAS causing some corruptions poorly-explicable
> otherwise. While I wouldn't recommend non-ECC ZFS NASes for any use,
> at least as a newly built rig, people that have a black box which
> just works, and aren't keen on spending time and money to buy and
> setup regular upgrades, are kind of stuck with it until the HW dies.

The thing is… most of these "in place systems" aren't likely to want or need 
the continuous stream of updates.  We can argue about bug fixes, and security 
considerations, but your average home NAS isn't sitting out there exposed on 
the internet.  

Anyone building a new box like this would use a newer Atom that supports x64.  
(And Atom is entirely unsuited to this due to lack of ECC, as you mentioned, 
but hey, most SOHO users don't care about that, although they should.  The ones 
who use ZFS because they worry about silent data corruption are probably *also* 
smart enough to understand the risks of running without ECC.)

I think *most* users of these SOHO boxes are *not* using illumos, even those 
who use illumos in other capacities, but are instead relying on FreeNAS, or the 
commercially supplied solution.

- Garrett



___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Jim Klimov]

On 2013-05-12 19:06, Garrett D'Amore wrote:

So, out of curiosity -- *who* is actively running illumos on 32-bit kit today?  
I'm not interested in hypothetical uses or kit that is sitting around in your 
garage waiting for you to do something with it…. I'm interested in people who 
would be immediately impacted and severely so if illumos were not available on 
32-bit CPUs right now.  (To give a counter example: I have a 32-bit Atom 
netbook, that I have OpenIndiana on.   I turn it on once every year or so… if 
that often … so I can't seriously claim that I would be negatively impacted if 
illumos were to move to 64-bit only.)


Indeed, I can't vouch for such systems, even my old home-NAS which was
my first victim of illumos/OI endearment had a Pentium-D with x86_64
support (though likely not virtualization acceleration features -
which would IIRC require VMs to be 32-bit). This box would be in my
production today, had it not broken while I am on a prolonged trip
away from that home; but it won't be impacted by a 64-bit only OS,
indeed (it did have some VMs for a test farm though, and they might
be impacted).

Also I know of many small (SOHO) storage boxes which can be made to
work with OpenSolaris and illumos-based OSes, and of those only the
HP N36 and N40L have (known to me) 64-bit AMD CPUs and ECC support;
most other such boxes are built around Atom, and often 32-bit with
some 2GB RAM. While this is not "interesting" for intensive production
use, some users of these boxes as reliable (ZFS) home storage might
be hurt by move to 64-bit only OS. Arguably though, lack of ECC did
probably burn my home-NAS causing some corruptions poorly-explicable
otherwise. While I wouldn't recommend non-ECC ZFS NASes for any use,
at least as a newly built rig, people that have a black box which
just works, and aren't keen on spending time and money to buy and
setup regular upgrades, are kind of stuck with it until the HW dies.

My 2c of theoreticizing :)
//Jim Klimov


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Piotr Jasiukajtis]

On May 12, 2013, at 7:10 PM, Garrett D'Amore  wrote:

> 
> On May 12, 2013, at 9:02 AM, Jim Klimov  wrote:
> 
>> On 2013-05-12 17:51, Alan Coopersmith wrote:
>>> On 05/12/13 05:19 AM, David Höppner wrote:
 I noticed Oracle upstream moves aggressively to amd64 only;
 installing amd64 just in bin not in bin/$(MACH64).
>>> 
>>> It has been a few years since Oracle upstream dropped 32-bit i386 support,
>>> so that's just one of the decisions OI has to make - track upstream as is
>>> or fork/patch as needed to continue to support 32-bit on i386.
>> 
>> I believe, 32-bit should be retained. While it is of little utility
>> for ZFS and other huge-RAM jobs, it may be required for some netbooks,
>> older hardware repurposed for tests and SOHO servers, as well as for
>> resource-constrained testing VMs. So I'd vouch for this fork/patch
>> approach if this upstream is still followed.
> 
> We've been doing this for years now.  I'm now starting to think -- 3 years 
> later on -- that this argument feels specious today.  Who runs illumos on a 
> netbook?  I did, once.  Not any more.  (And modern netbooks have 64 bit 
> support!)
> 
> Older hardware must be *really* old.  Over 5 years.  For servers, probably 
> over 10 years.  I've thrown away my Pentiums and Pentium IIs.  I suppose 
> there could be some Pentium IIIs and IVs out there, or AMD Athlons 
> (pre-Athlon64), but they'd all be really really slow by today's standards.  
> Do people run illumos on such kit?  I'm highly doubtful, unless that kit is 
> around just to answer the question of whether 32-bit kernels still work. :-)
I have used 32bit before illumos was born. It was really painful though. 
I think if someone is capable of running illumos based system on 32bit these 
days, he should also be capable of maintaing 32bit fork for his own needs.

--
Piotr Jasiukajtis


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Garrett D'Amore]

On May 12, 2013, at 9:05 AM, Magnus  wrote:

> 
> On May 12, 2013, at 12:02 PM, Jim Klimov wrote:
>> 
>> 
>> I believe, 32-bit should be retained. While it is of little utility
>> for ZFS and other huge-RAM jobs, it may be required for some netbooks,
>> older hardware repurposed for tests and SOHO servers, as well as for
>> resource-constrained testing VMs. So I'd vouch for this fork/patch
>> approach if this upstream is still followed.
> 
> Not to mention intriguing projects like 
> http://wiki.illumos.org/display/illumos/Raspberry+Pi+Bring-Up
> 

ARM11 is only 32-bit, and has nothing to do with the discussion of whether we 
would retain *x86* 32-bit mode support.

- Garrett

> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Garrett D'Amore]

On May 12, 2013, at 9:02 AM, Jim Klimov  wrote:

> On 2013-05-12 17:51, Alan Coopersmith wrote:
>> On 05/12/13 05:19 AM, David Höppner wrote:
>>> I noticed Oracle upstream moves aggressively to amd64 only;
>>> installing amd64 just in bin not in bin/$(MACH64).
>> 
>> It has been a few years since Oracle upstream dropped 32-bit i386 support,
>> so that's just one of the decisions OI has to make - track upstream as is
>> or fork/patch as needed to continue to support 32-bit on i386.
> 
> I believe, 32-bit should be retained. While it is of little utility
> for ZFS and other huge-RAM jobs, it may be required for some netbooks,
> older hardware repurposed for tests and SOHO servers, as well as for
> resource-constrained testing VMs. So I'd vouch for this fork/patch
> approach if this upstream is still followed.

We've been doing this for years now.  I'm now starting to think -- 3 years 
later on -- that this argument feels specious today.  Who runs illumos on a 
netbook?  I did, once.  Not any more.  (And modern netbooks have 64 bit 
support!)

Older hardware must be *really* old.  Over 5 years.  For servers, probably over 
10 years.  I've thrown away my Pentiums and Pentium IIs.  I suppose there could 
be some Pentium IIIs and IVs out there, or AMD Athlons (pre-Athlon64), but 
they'd all be really really slow by today's standards.  Do people run illumos 
on such kit?  I'm highly doubtful, unless that kit is around just to answer the 
question of whether 32-bit kernels still work. :-)

- Garrett


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Garrett D'Amore]

On May 12, 2013, at 8:51 AM, Alan Coopersmith  
wrote:

> On 05/12/13 05:19 AM, David Höppner wrote:
>> I noticed Oracle upstream moves aggressively to amd64 only;
>> installing amd64 just in bin not in bin/$(MACH64).
> 
> It has been a few years since Oracle upstream dropped 32-bit i386 support,
> so that's just one of the decisions OI has to make - track upstream as is
> or fork/patch as needed to continue to support 32-bit on i386.

Yep.  And that has sweeping consequences; lots of things depend upon it this 
decision.

I'm of the opinion that enough time has passed that we should seriously 
consider doing the same.  Its been about a decade since  64-bit  x86 systems 
came on the scene (Opteron was released in June 2003).  The only 32-bit only 
variants that I'm aware of that are even vaguely recent are the older Atom 
processors (still about 4-5 years old), AMD Geode (last released 2009, though I 
guess they are selling them for embedded customers until 2015 or thereabouts), 
and certain Via processors (although all current Via products support x86_64).

Of these, I'm only aware of the following 32-bit CPUs that might be out there 
running illumos code that aren't also truly ancient (a decade or so old):

* Intel Atom systems -- there were a few of these, but they are really 
really low performance systems
* AMD Sempron
* Pentium 4 (certain systems dating back to about 2004)

There were some older virtualization products where it made sense to run 
illumos in a 32-bit VM, but all those hypervisors have *long* since been 
updated to support amd64.

None of the others have, afaik, ever been used to run illumos or Solaris 
outside of experimental cases just to see if it would work.

I haven't seen a serious use of a 32-bit only CPU in production in over 5 
years.  And I think most hobbyists upgrade their kit more frequently as well -- 
I have to believe almost everyone is on 64-bit kit these days.  Furthermore, 
most interesting systems (based on illumos) require more memory than is 
practical with a 32-bit only CPU.

I have to believe we could eliminate a *lot* of baggage by nixing 32-bit 
support.  I *know* we can, because I've nixed a bunch of system utilities in 
our DEY environment that were delivered in both 32 and 64 bit variants.

We're going to have to support a 32-bit userland for some time to come, 
unfortunately, but we should no longer make that the default, and we should 
deliver all of our system utilities in 64-bit only form, IMO; and we could 
entirely kill off the 32-bit kernel.

Alternatively, if there is sufficient demand, one could imagine a separate 
architecture for ia32, that is the 32-bit variant port.  That would not need to 
carry the 64-bit support.   Admittedly going this route reduces the likelihood 
of keeping certain bits capable of running 32-bit mode (e.g. device drivers), 
but one would argue that 32 bit systems are unlikely to adapt new devices, etc. 
 precisely because they are *so* friggin' old.

So, out of curiosity -- *who* is actively running illumos on 32-bit kit today?  
I'm not interested in hypothetical uses or kit that is sitting around in your 
garage waiting for you to do something with it…. I'm interested in people who 
would be immediately impacted and severely so if illumos were not available on 
32-bit CPUs right now.  (To give a counter example: I have a 32-bit Atom 
netbook, that I have OpenIndiana on.   I turn it on once every year or so… if 
that often … so I can't seriously claim that I would be negatively impacted if 
illumos were to move to 64-bit only.)

- Garrett


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Magnus]

On May 12, 2013, at 12:02 PM, Jim Klimov wrote:
> 
> 
> I believe, 32-bit should be retained. While it is of little utility
> for ZFS and other huge-RAM jobs, it may be required for some netbooks,
> older hardware repurposed for tests and SOHO servers, as well as for
> resource-constrained testing VMs. So I'd vouch for this fork/patch
> approach if this upstream is still followed.

Not to mention intriguing projects like 
http://wiki.illumos.org/display/illumos/Raspberry+Pi+Bring-Up

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Jim Klimov]

On 2013-05-12 17:51, Alan Coopersmith wrote:

On 05/12/13 05:19 AM, David Höppner wrote:

I noticed Oracle upstream moves aggressively to amd64 only;
installing amd64 just in bin not in bin/$(MACH64).


It has been a few years since Oracle upstream dropped 32-bit i386 support,
so that's just one of the decisions OI has to make - track upstream as is
or fork/patch as needed to continue to support 32-bit on i386.


I believe, 32-bit should be retained. While it is of little utility
for ZFS and other huge-RAM jobs, it may be required for some netbooks,
older hardware repurposed for tests and SOHO servers, as well as for
resource-constrained testing VMs. So I'd vouch for this fork/patch
approach if this upstream is still followed.

//Jim


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Jim Klimov]

On 2013-05-12 16:54, ken mays wrote:

Hello,

Just so we can tack up a goal for the visionaries who like roadmaps and
such...

Proposed list of 'core' updates for oi_151a(8-9):

*   Bump illumos to 19e11862653b
 Implement accept4()
 stack overflow due to zfs lz4 compression
 Fast reboot support in ixgbe
  Chelsio 10GbE driver support
 Support LSI SAS2008 (Falcon) Skinny FW for mr_sas(7D)
 Allow ixgbe to use unsupported SFP modules
 detect socket type of newer AMD CPUs
*   New JDS package updates (2013-04-09)
from: http://pkg.opensolaris.cz/osol/en/index.shtml
*   Wifi Stack improvement patches (enrico)


I have some more suggested milestones, though not necessarily
holding back some imminent release (just something that would be
good to do soon, and likely requiring not much work to complete).
Maybe, this might make it into oi_151a9 (if a8 would be packing
up what we already have in JDS and illumos-gate today)?

If possible to RTI by then, or just post to some "testing" repo,
there has been some good work done about other networking drivers,
at least those that concern me - in particular, ndis 64-bit for
Broadcom WiFi by Jean-Pierre Andre, and I'm in touch with Masa
Murayama (The Free NIC Drivers project) regarding my rge/gani
NIC. It turned out to be a newer RTL8168 chip than was supported
by gani-2.6.9, so he sent me an updated version for testing,
which "just works" on my laptop. Now I have both wired and
wireless connectivity in OI, working and stable. This was a
good month! I've also set up failover with IPMP :) Earlier I've
had other computers where Masa's drivers were also invaluable.

Masa didn't reply yet whether he'd personally cooperate on RTI'ing
his works, but he didn't say "no" either, and they are BSD-licensed,
so... I don't know if there's any other upstream than occasionally
updated source+binary code tarballs (note that bins are GLDv2 default,
and should be easily recompiled for GLDv3) here on his site:
  http://homepage2.nifty.com/mrym3/taiyodo/eng/

I hope that the extended sets of networking drivers can sooner or
later get into illumos-gate and/or directly into OI (including the
installer's Live environment) as the versatile distro that is set up
on very varied hardware (i.e. laptops made of whatever is available
du-jour and cheap to their designers).

HTH,
//Jim Klimov


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Alan Coopersmith]

On 05/12/13 05:19 AM, David Höppner wrote:

I noticed Oracle upstream moves aggressively to amd64 only;
installing amd64 just in bin not in bin/$(MACH64).


It has been a few years since Oracle upstream dropped 32-bit i386 support,
so that's just one of the decisions OI has to make - track upstream as is
or fork/patch as needed to continue to support 32-bit on i386.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[ken mays]

Hello,

Just so we can tack up a goal for the visionaries who like roadmaps and such...

Proposed list of 'core' updates for oi_151a(8-9):

*   Bump illumos to 19e11862653b 
    Implement accept4()
    stack overflow due to zfs lz4 compression
    Fast reboot support in ixgbe
 Chelsio 10GbE driver support
    Support LSI SAS2008 (Falcon) Skinny FW for mr_sas(7D)
    Allow ixgbe to use unsupported SFP modules
    detect socket type of newer AMD CPUs
*   New JDS package updates (2013-04-09)
           from: http://pkg.opensolaris.cz/osol/en/index.shtml
*   Wifi Stack improvement patches (enrico)

Hope that helped,
Ken Mays





 From: Andrzej Szeszo 
To: OpenIndiana Developer mailing list  
Sent: Sunday, May 12, 2013 7:11 AM
Subject: Re: [oi-dev] OI project reboot required
 


Hi Piotr

I made some choices without consulting anyone but it allowed me to get 
something set up in a short period of time.

oi_151a8 is based on sfw-gate, that's correct. Milan built JDS against 
oi_151a8. Because oi_151a8 and JDS bits were already available I thought it 
would be a shame to not to include them in the repo I was preparing.


/experimental, oi-build, illumos-userland didn't really took off. I know they 
exist but it would take time to figure out in what shape the binary package 
repos are. I thought it would be a better idea to start fresh in terms of 
binary packages. Build recipes however we should reuse. The github repo 
currently does not produce anything else other than few meta-packages. Build 
recipes from oi-build or illumos-userland can be added to the tree and should 
just work. There is an option of enabling disabled Oracle provided packages as 
well.

This time I wanted to keep things really simple. There is single publisher now 
- 'openindiana.org' - but pointing at different repo. And single source repo -  
https://github.com/OpenIndiana/oi-userland. Any fixes or additions should be 
made in the github repo.

In terms of fixes to the packages that came from SFW , I recommend using 
equivalent package from one of the userland-style repos. The idea is to not to 
have to compile SFW or run distro-importer ever again :)

Correct me if I am wrong, but illumos-userland is dead. I don't see a point 
using it directly. Build recipes should be borrowed from it though :)

I have heard about libffi. Not sure what the problem is. It doesn't look like 
it would be difficult to provide userland build recipe for it in case we need 
an updated version.


Andrzej






On 12 May 2013 12:09, Piotr Jasiukajtis  wrote:

Andrzej,
>
>oi_151a8 is still based on sfw-gate, wouldn't be better to resurrect 
>/experimental which was based on illumos-userland?
>
>To me it was hard to manage different IPS versions along with the build 
>environments/zones because some were based on /experimental while my main host 
>was /dev.
>Another source of confusion are 3 different source repositories: sfw, oi-build 
>and illumos-userland. Which one to use if I need a new package on my 
>production systems? and no, I don't want to touch SFW anymore :)
>
>Maybe create another version based on illumos-userland in the /dev let say 
>oi_152a1 or something?
>
>
>Btw, someone mentioned about some libffi issues on oi_151a8.
>I barely checked that and it seems pkg and python do work but I don't know 
>what the issue was. Is that fixed?
>
>Thanks for doing that :)
>
>--
>Piotr Jasiukajtis
>
>
>On May 12, 2013, at 10:30 AM, Andrzej Szeszo  wrote:
>
>> Hi All
>>
>> Apologies for a delay. Some things are set up now.
>>
>> New IPS repository is up: http://pkg.openindiana.org/hipster/. It is a clone 
>> of the /dev repo + oi_151a8 bits from Jon Tibble and JDS bits from Milan 
>> Jurik merged in. Run commands below to update your system. You can ask Jon 
>> Tibble where the name of the repo came from :)
>>
>> pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org
>> pk install -v pkg://package/pkg
>> pkg update -v
>>
>> Latest Oracle userland hg repo was converted to git and uploaded to 
>> https://github.com/OpenIndiana/oi-userland/. Most of the components were 
>> masked and don't build by default. I have only unmasked few meta packages to 
>> test if things build/publish correctly.
>>
>> Quick Jenkins instance that automatically builds packages and publishes them 
>> directly to http://pkg.openindiana.org/hipster/.
>>
>> To start hacking, fork a repo on github, make your changes (unmask packages, 
>> add new ones) and submit pull request. If you are an existing contributor, 
>> give me a shout and I will give you direct access to the repo.
>>
>> Please let me know if you have a

Re: [oi-dev] OI project reboot required

[Andrzej Szeszo]

pkg.depotd is misbehaving when you publish packages directly to it. I am
looking at it now.

Andrzej


On 12 May 2013 14:19, David Höppner <0xf...@gmail.com> wrote:

> I actually get a permissions error.
>
> $ sudo pkg set-publisher -O http://pkg.openindiana.org/hipster/
> openindiana.org
> pkg set-publisher: Could not refresh the catalog for openindiana.org
>
> http protocol error: code: 403 reason: Forbidden
> URL: '
> http://pkg.openindiana.org/hipster/openindiana.org/catalog/1/catalog.attrs
> '.
>
>
> I noticed Oracle upstream moves aggressively to amd64 only;
> installing amd64 just in bin not in bin/$(MACH64).
>
> -- David
>
> On 12 May 2013 10:30, Andrzej Szeszo  wrote:
> > Hi All
> >
> > Apologies for a delay. Some things are set up now.
> >
> > New IPS repository is up: http://pkg.openindiana.org/hipster/. It is a
> clone
> > of the /dev repo + oi_151a8 bits from Jon Tibble and JDS bits from Milan
> > Jurik merged in. Run commands below to update your system. You can ask
> Jon
> > Tibble where the name of the repo came from :)
> >
> > pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org
> > pk install -v pkg://package/pkg
> > pkg update -v
> >
> > Latest Oracle userland hg repo was converted to git and uploaded to
> > https://github.com/OpenIndiana/oi-userland/. Most of the components were
> > masked and don't build by default. I have only unmasked few meta
> packages to
> > test if things build/publish correctly.
> >
> > Quick Jenkins instance that automatically builds packages and publishes
> them
> > directly to http://pkg.openindiana.org/hipster/.
> >
> > To start hacking, fork a repo on github, make your changes (unmask
> packages,
> > add new ones) and submit pull request. If you are an existing
> contributor,
> > give me a shout and I will give you direct access to the repo.
> >
> > Please let me know if you have any questions.
> >
> > Let's see if the process works out.
> >
> > Kind regards,
> >
> > Andrzej
> >
> >
> >
> > On 11 May 2013 18:28, Andrzej Szeszo  wrote:
> >>
> >> Hi Alasdair
> >>
> >> I would like to try setting up a repo on github, give trusted people
> >> direct access and support pull requests from independent developers. And
> >> then have jenkins publish packages incrementally to publicly accessible
> >> repository. In theory, it should only take few minutes from a push to a
> >> published package in a repo.
> >>
> >> It is a variation on the process which was tried earlier. I think it
> might
> >> work this time.
> >>
> >> I did some prep work last night. Will try to have something usable by
> >> others later tonight.
> >>
> >> Cheers,
> >>
> >> Andrzej
> >>
> >>
> >>
> >>
> >> On 10 May 2013 14:04, Alasdair Lumsden  wrote:
> >>>
> >>> Andrzej,
> >>>
> >>> Your vision is pretty much the same one I had. The challenge is this:
> >>>
> >>> "Existing releng process and contribution process prevent anything from
> >>> happening though. I would like to help to change that."
> >>>
> >>> How?
> >>>
> >>>
> >>> On Fri, May 10, 2013 at 12:54 PM, Jim Klimov  wrote:
> 
>  On 2013-05-10 02:19, Garrett D'Amore wrote:
> >>
> >> There is little "commercial future" in the desktop for Linux
> >> distributions as well yet almost all of them have a graphical
> desktop.
> >
> >
> > I would be entirely *unsurprised* if distro vendors like RedHat and
> > Oracle simply *ditched* their desktop support at some point in the
> future --
> > its clear to me at least that folks aren't running those distros on
> the
> > desktop.
> 
> 
>  Well, Oracle does provide and promote SunRays, and while admittedly
> most
>  of their market targeting is about VDI and access to virtual
>  Windows desktops, there are many requests on the SRSS mailing list
>  about adding support for server-side Ubuntu as the SRSS terminal
>  server, because certain apps only exist for Linux and tunneling
>  of connections makes their graphics lag, and RHEL/OEL/Solaris
>  desktops are argued to be not so user-friendly (I have no opinion
>  on this, to me X11 is a means to display more characters on screen
>  than possible in a text mode).
> 
>  Not that Oracle seems to care to address that demand, at least
>  publicly - just recently they began supporting versions 6 of RHEL
>  and OEL as server-side Linuxes. But there is certain demand for
>  non-MS/Apple desktops, and one linked to commercial interest as
>  well. I am not sure if OI/illumos can ride that tide, though.
>  Maybe with some other terminal client technologies (ThinLinc,
>  Wyse, etc)?..
> 
>  //Jim
> 
> 
> 
>  ___
>  oi-dev mailing list
>  oi-dev@openindiana.org
>  http://openindiana.org/mailman/listinfo/oi-dev
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Alasdair Lumsden
> >>>
> >>> http://www.everycity.co.uk
> >>>
> >>> EveryCity Managed Hosting
> >>> Stud

Re: [oi-dev] OI project reboot required

[David Höppner]

I actually get a permissions error.

$ sudo pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org
pkg set-publisher: Could not refresh the catalog for openindiana.org

http protocol error: code: 403 reason: Forbidden
URL: 
'http://pkg.openindiana.org/hipster/openindiana.org/catalog/1/catalog.attrs'.


I noticed Oracle upstream moves aggressively to amd64 only;
installing amd64 just in bin not in bin/$(MACH64).

-- David

On 12 May 2013 10:30, Andrzej Szeszo  wrote:
> Hi All
>
> Apologies for a delay. Some things are set up now.
>
> New IPS repository is up: http://pkg.openindiana.org/hipster/. It is a clone
> of the /dev repo + oi_151a8 bits from Jon Tibble and JDS bits from Milan
> Jurik merged in. Run commands below to update your system. You can ask Jon
> Tibble where the name of the repo came from :)
>
> pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org
> pk install -v pkg://package/pkg
> pkg update -v
>
> Latest Oracle userland hg repo was converted to git and uploaded to
> https://github.com/OpenIndiana/oi-userland/. Most of the components were
> masked and don't build by default. I have only unmasked few meta packages to
> test if things build/publish correctly.
>
> Quick Jenkins instance that automatically builds packages and publishes them
> directly to http://pkg.openindiana.org/hipster/.
>
> To start hacking, fork a repo on github, make your changes (unmask packages,
> add new ones) and submit pull request. If you are an existing contributor,
> give me a shout and I will give you direct access to the repo.
>
> Please let me know if you have any questions.
>
> Let's see if the process works out.
>
> Kind regards,
>
> Andrzej
>
>
>
> On 11 May 2013 18:28, Andrzej Szeszo  wrote:
>>
>> Hi Alasdair
>>
>> I would like to try setting up a repo on github, give trusted people
>> direct access and support pull requests from independent developers. And
>> then have jenkins publish packages incrementally to publicly accessible
>> repository. In theory, it should only take few minutes from a push to a
>> published package in a repo.
>>
>> It is a variation on the process which was tried earlier. I think it might
>> work this time.
>>
>> I did some prep work last night. Will try to have something usable by
>> others later tonight.
>>
>> Cheers,
>>
>> Andrzej
>>
>>
>>
>>
>> On 10 May 2013 14:04, Alasdair Lumsden  wrote:
>>>
>>> Andrzej,
>>>
>>> Your vision is pretty much the same one I had. The challenge is this:
>>>
>>> "Existing releng process and contribution process prevent anything from
>>> happening though. I would like to help to change that."
>>>
>>> How?
>>>
>>>
>>> On Fri, May 10, 2013 at 12:54 PM, Jim Klimov  wrote:

 On 2013-05-10 02:19, Garrett D'Amore wrote:
>>
>> There is little "commercial future" in the desktop for Linux
>> distributions as well yet almost all of them have a graphical desktop.
>
>
> I would be entirely *unsurprised* if distro vendors like RedHat and
> Oracle simply *ditched* their desktop support at some point in the future 
> --
> its clear to me at least that folks aren't running those distros on the
> desktop.


 Well, Oracle does provide and promote SunRays, and while admittedly most
 of their market targeting is about VDI and access to virtual
 Windows desktops, there are many requests on the SRSS mailing list
 about adding support for server-side Ubuntu as the SRSS terminal
 server, because certain apps only exist for Linux and tunneling
 of connections makes their graphics lag, and RHEL/OEL/Solaris
 desktops are argued to be not so user-friendly (I have no opinion
 on this, to me X11 is a means to display more characters on screen
 than possible in a text mode).

 Not that Oracle seems to care to address that demand, at least
 publicly - just recently they began supporting versions 6 of RHEL
 and OEL as server-side Linuxes. But there is certain demand for
 non-MS/Apple desktops, and one linked to commercial interest as
 well. I am not sure if OI/illumos can ride that tide, though.
 Maybe with some other terminal client technologies (ThinLinc,
 Wyse, etc)?..

 //Jim



 ___
 oi-dev mailing list
 oi-dev@openindiana.org
 http://openindiana.org/mailman/listinfo/oi-dev
>>>
>>>
>>>
>>>
>>> --
>>> Alasdair Lumsden
>>>
>>> http://www.everycity.co.uk
>>>
>>> EveryCity Managed Hosting
>>> Studio 18 Bluelion Place
>>> 237 Long Lane, London, SE1 4PU
>>>
>>> general: 020 7183 2800
>>> support: 020 7183 2801
>>> email: a...@everycity.co.uk
>>>
>>> Every City Limited
>>> Registered in England and Wales, No. 5689474 Registered Office: Roper
>>> Yard, Roper Road, Canterbury, CT2 7EX
>>>
>>> ___
>>> oi-dev mailing list
>>> oi-dev@openindiana.org
>>> http://openindiana.org/mailman/listinfo/oi-dev
>>
>>
>

Re: [oi-dev] OI project reboot required

[Andrzej Szeszo]

Hi Piotr

I made some choices without consulting anyone but it allowed me to get
something set up in a short period of time.

oi_151a8 is based on sfw-gate, that's correct. Milan built JDS against
oi_151a8.
Because oi_151a8 and JDS bits were already available I thought it would be
a shame to not to include them in the repo I was preparing.

/experimental, oi-build, illumos-userland didn't really took off. I know
they exist but it would take time to figure out in what shape the binary
package repos are. I thought it would be a better idea to start fresh in
terms of binary packages. Build recipes however we should reuse. The github
repo currently does not produce anything else other than few meta-packages.
Build recipes from oi-build or illumos-userland can be added to the tree
and should just work. There is an option of enabling disabled Oracle
provided packages as well.

This time I wanted to keep things really simple. There is single publisher
now - 'openindiana.org' - but pointing at different repo. And single source
repo -  https://github.com/OpenIndiana/oi-userland. Any fixes or additions
should be made in the github repo.

In terms of fixes to the packages that came from SFW , I recommend using
equivalent package from one of the userland-style repos. The idea is to not
to have to compile SFW or run distro-importer ever again :)

Correct me if I am wrong, but illumos-userland is dead. I don't see a point
using it directly. Build recipes should be borrowed from it though :)

I have heard about libffi. Not sure what the problem is. It doesn't look
like it would be difficult to provide userland build recipe for it in case
we need an updated version.

Andrzej




On 12 May 2013 12:09, Piotr Jasiukajtis  wrote:

> Andrzej,
>
> oi_151a8 is still based on sfw-gate, wouldn't be better to resurrect
> /experimental which was based on illumos-userland?
>
> To me it was hard to manage different IPS versions along with the build
> environments/zones because some were based on /experimental while my main
> host was /dev.
> Another source of confusion are 3 different source repositories: sfw,
> oi-build and illumos-userland. Which one to use if I need a new package on
> my production systems? and no, I don't want to touch SFW anymore :)
>
> Maybe create another version based on illumos-userland in the /dev let say
> oi_152a1 or something?
>
>
> Btw, someone mentioned about some libffi issues on oi_151a8.
> I barely checked that and it seems pkg and python do work but I don't know
> what the issue was. Is that fixed?
>
> Thanks for doing that :)
>
> --
> Piotr Jasiukajtis
>
> On May 12, 2013, at 10:30 AM, Andrzej Szeszo  wrote:
>
> > Hi All
> >
> > Apologies for a delay. Some things are set up now.
> >
> > New IPS repository is up: http://pkg.openindiana.org/hipster/. It is a
> clone of the /dev repo + oi_151a8 bits from Jon Tibble and JDS bits from
> Milan Jurik merged in. Run commands below to update your system. You can
> ask Jon Tibble where the name of the repo came from :)
> >
> > pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org
> > pk install -v pkg://package/pkg
> > pkg update -v
> >
> > Latest Oracle userland hg repo was converted to git and uploaded to
> https://github.com/OpenIndiana/oi-userland/. Most of the components were
> masked and don't build by default. I have only unmasked few meta packages
> to test if things build/publish correctly.
> >
> > Quick Jenkins instance that automatically builds packages and publishes
> them directly to http://pkg.openindiana.org/hipster/.
> >
> > To start hacking, fork a repo on github, make your changes (unmask
> packages, add new ones) and submit pull request. If you are an existing
> contributor, give me a shout and I will give you direct access to the repo.
> >
> > Please let me know if you have any questions.
> >
> > Let's see if the process works out.
> >
> > Kind regards,
> >
> > Andrzej
> >
> >
> >
> > On 11 May 2013 18:28, Andrzej Szeszo  wrote:
> > Hi Alasdair
> >
> > I would like to try setting up a repo on github, give trusted people
> direct access and support pull requests from independent developers. And
> then have jenkins publish packages incrementally to publicly accessible
> repository. In theory, it should only take few minutes from a push to a
> published package in a repo.
> >
> > It is a variation on the process which was tried earlier. I think it
> might work this time.
> >
> > I did some prep work last night. Will try to have something usable by
> others later tonight.
> >
> > Cheers,
> >
> > Andrzej
> >
> >
> >
> >
> > On 10 May 2013 14:04, Alasdair Lumsden  wrote:
> > Andrzej,
> >
> > Your vision is pretty much the same one I had. The challenge is this:
> >
> > "Existing releng process and contribution process prevent anything from
> happening though. I would like to help to change that."
> >
> > How?
> >
> >
> > On Fri, May 10, 2013 at 12:54 PM, Jim Klimov  wrote:
> > On 2013-05-10 02:19, Garrett D'Amore wrote:
> > Th

Re: [oi-dev] OI project reboot required

[Piotr Jasiukajtis]

Andrzej,

oi_151a8 is still based on sfw-gate, wouldn't be better to resurrect 
/experimental which was based on illumos-userland?

To me it was hard to manage different IPS versions along with the build 
environments/zones because some were based on /experimental while my main host 
was /dev.
Another source of confusion are 3 different source repositories: sfw, oi-build 
and illumos-userland. Which one to use if I need a new package on my production 
systems? and no, I don't want to touch SFW anymore :)

Maybe create another version based on illumos-userland in the /dev let say 
oi_152a1 or something?


Btw, someone mentioned about some libffi issues on oi_151a8. 
I barely checked that and it seems pkg and python do work but I don't know what 
the issue was. Is that fixed?

Thanks for doing that :)

--
Piotr Jasiukajtis

On May 12, 2013, at 10:30 AM, Andrzej Szeszo  wrote:

> Hi All
> 
> Apologies for a delay. Some things are set up now.
> 
> New IPS repository is up: http://pkg.openindiana.org/hipster/. It is a clone 
> of the /dev repo + oi_151a8 bits from Jon Tibble and JDS bits from Milan 
> Jurik merged in. Run commands below to update your system. You can ask Jon 
> Tibble where the name of the repo came from :)
> 
> pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org
> pk install -v pkg://package/pkg
> pkg update -v
> 
> Latest Oracle userland hg repo was converted to git and uploaded to 
> https://github.com/OpenIndiana/oi-userland/. Most of the components were 
> masked and don't build by default. I have only unmasked few meta packages to 
> test if things build/publish correctly.
> 
> Quick Jenkins instance that automatically builds packages and publishes them 
> directly to http://pkg.openindiana.org/hipster/.
> 
> To start hacking, fork a repo on github, make your changes (unmask packages, 
> add new ones) and submit pull request. If you are an existing contributor, 
> give me a shout and I will give you direct access to the repo.
> 
> Please let me know if you have any questions.
> 
> Let's see if the process works out.
> 
> Kind regards,
> 
> Andrzej
> 
> 
> 
> On 11 May 2013 18:28, Andrzej Szeszo  wrote:
> Hi Alasdair
> 
> I would like to try setting up a repo on github, give trusted people direct 
> access and support pull requests from independent developers. And then have 
> jenkins publish packages incrementally to publicly accessible repository. In 
> theory, it should only take few minutes from a push to a published package in 
> a repo.
> 
> It is a variation on the process which was tried earlier. I think it might 
> work this time.
> 
> I did some prep work last night. Will try to have something usable by others 
> later tonight.
> 
> Cheers,
> 
> Andrzej
> 
> 
> 
> 
> On 10 May 2013 14:04, Alasdair Lumsden  wrote:
> Andrzej,
> 
> Your vision is pretty much the same one I had. The challenge is this:
> 
> "Existing releng process and contribution process prevent anything from 
> happening though. I would like to help to change that."
> 
> How?
> 
> 
> On Fri, May 10, 2013 at 12:54 PM, Jim Klimov  wrote:
> On 2013-05-10 02:19, Garrett D'Amore wrote:
> There is little "commercial future" in the desktop for Linux distributions as 
> well yet almost all of them have a graphical desktop.
> 
> I would be entirely *unsurprised* if distro vendors like RedHat and Oracle 
> simply *ditched* their desktop support at some point in the future -- its 
> clear to me at least that folks aren't running those distros on the desktop.
> 
> Well, Oracle does provide and promote SunRays, and while admittedly most of 
> their market targeting is about VDI and access to virtual
> Windows desktops, there are many requests on the SRSS mailing list
> about adding support for server-side Ubuntu as the SRSS terminal
> server, because certain apps only exist for Linux and tunneling
> of connections makes their graphics lag, and RHEL/OEL/Solaris
> desktops are argued to be not so user-friendly (I have no opinion
> on this, to me X11 is a means to display more characters on screen
> than possible in a text mode).
> 
> Not that Oracle seems to care to address that demand, at least
> publicly - just recently they began supporting versions 6 of RHEL
> and OEL as server-side Linuxes. But there is certain demand for
> non-MS/Apple desktops, and one linked to commercial interest as
> well. I am not sure if OI/illumos can ride that tide, though.
> Maybe with some other terminal client technologies (ThinLinc,
> Wyse, etc)?..
> 
> //Jim
> 
> 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
> 
> 
> 
> -- 
> Alasdair Lumsden
> 
> http://www.everycity.co.uk
> 
> EveryCity Managed Hosting
> Studio 18 Bluelion Place
> 237 Long Lane, London, SE1 4PU
> 
> general: 020 7183 2800
> support: 020 7183 2801
> email: a...@everycity.co.uk
> 
> Every City Limited
> Registered in England and Wales, No. 5689474 Register

Re: [oi-dev] OI project reboot required

[Andrzej Szeszo]

Hi All

Apologies for a delay. Some things are set up now.

New IPS repository is up: http://pkg.openindiana.org/hipster/. It is a
clone of the /dev repo + oi_151a8 bits from Jon Tibble and JDS bits from
Milan Jurik merged in. Run commands below to update your system. You can
ask Jon Tibble where the name of the repo came from :)

pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org
pk install -v pkg://package/pkg
pkg update -v

Latest Oracle userland hg repo was converted to git and uploaded to
https://github.com/OpenIndiana/oi-userland/. Most of the components were
masked and don't build by default. I have only unmasked few meta packages
to test if things build/publish correctly.

Quick Jenkins instance that automatically builds packages and publishes
them directly to http://pkg.openindiana.org/hipster/.

To start hacking, fork a repo on github, make your changes (unmask
packages, add new ones) and submit pull request. If you are an existing
contributor, give me a shout and I will give you direct access to the repo.

Please let me know if you have any questions.

Let's see if the process works out.

Kind regards,

Andrzej



On 11 May 2013 18:28, Andrzej Szeszo  wrote:

> Hi Alasdair
>
> I would like to try setting up a repo on github, give trusted people
> direct access and support pull requests from independent developers. And
> then have jenkins publish packages incrementally to publicly accessible
> repository. In theory, it should only take few minutes from a push to a
> published package in a repo.
>
> It is a variation on the process which was tried earlier. I think it might
> work this time.
>
> I did some prep work last night. Will try to have something usable by
> others later tonight.
>
> Cheers,
>
> Andrzej
>
>
>
>
> On 10 May 2013 14:04, Alasdair Lumsden  wrote:
>
>> Andrzej,
>>
>> Your vision is pretty much the same one I had. The challenge is this:
>>
>> "Existing releng process and contribution process prevent anything from
>> happening though. I would like to help to change that."
>>
>> How?
>>
>>
>> On Fri, May 10, 2013 at 12:54 PM, Jim Klimov  wrote:
>>
>>> On 2013-05-10 02:19, Garrett D'Amore wrote:
>>>
 There is little "commercial future" in the desktop for Linux
> distributions as well yet almost all of them have a graphical desktop.
>

 I would be entirely *unsurprised* if distro vendors like RedHat and
 Oracle simply *ditched* their desktop support at some point in the future
 -- its clear to me at least that folks aren't running those distros on the
 desktop.

>>>
>>> Well, Oracle does provide and promote SunRays, and while admittedly most
>>> of their market targeting is about VDI and access to virtual
>>> Windows desktops, there are many requests on the SRSS mailing list
>>> about adding support for server-side Ubuntu as the SRSS terminal
>>> server, because certain apps only exist for Linux and tunneling
>>> of connections makes their graphics lag, and RHEL/OEL/Solaris
>>> desktops are argued to be not so user-friendly (I have no opinion
>>> on this, to me X11 is a means to display more characters on screen
>>> than possible in a text mode).
>>>
>>> Not that Oracle seems to care to address that demand, at least
>>> publicly - just recently they began supporting versions 6 of RHEL
>>> and OEL as server-side Linuxes. But there is certain demand for
>>> non-MS/Apple desktops, and one linked to commercial interest as
>>> well. I am not sure if OI/illumos can ride that tide, though.
>>> Maybe with some other terminal client technologies (ThinLinc,
>>> Wyse, etc)?..
>>>
>>> //Jim
>>>
>>>
>>>
>>> __**_
>>> oi-dev mailing list
>>> oi-dev@openindiana.org
>>> http://openindiana.org/**mailman/listinfo/oi-dev
>>>
>>
>>
>>
>> --
>> Alasdair Lumsden
>>
>> http://www.everycity.co.uk
>>
>> EveryCity Managed Hosting
>> Studio 18 Bluelion Place
>> 237 Long Lane, London, SE1 4PU
>>
>> general: 020 7183 2800
>> support: 020 7183 2801
>> email: a...@everycity.co.uk
>>
>> Every City Limited
>> Registered in England and Wales, No. 5689474 Registered Office: Roper
>> Yard, Roper Road, Canterbury, CT2 7EX
>>
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> http://openindiana.org/mailman/listinfo/oi-dev
>>
>
>
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Garrett D'Amore]

On May 11, 2013, at 10:05 AM, Nikola M.  wrote:

> On 05/10/13 02:19 AM, Garrett D'Amore wrote:
>> more constructive than whinging about it will be to find ways to either a) 
>> make a commercially viable case for it so people can get paid to work on it, 
>> or b) lead a volunteer effort to make this work.
> I think that without Desktop that is running on the server, I can not
> sell Illumos based distribution as a server product. That is because
> small companies and offices expect to have GUI working, so they can log
> in and possible do something with the machine.  I suppose that machine
> without GUI would look to them as a "blackbox" if there is just command
> line.

And yet, many people are building products on top of illumos that *are* selling 
well, and don't provide a graphical login (at least not in the traditional 
sense -- some of them offer a browser based login.)  SmartOS, Nexenta, 
GreenBytes, etc…. even Sun traditionally sold more headless systems than 
systems with a graphical desktop.  (All those rack mount systems don't need a 
graphical desktop -- but they *should* offer a compelling experience using 
other management tools -- like Browser or native mobile apps to help with 
systems management.)

> There is no desktop per se and server as a product per se. It is the
> server distribution that has desktop environment and programs for
> convenience. If I am selling it, I am selling a server. And having
> Desktop environments on server is nice. Not having desktop environment
> on server in 2013 is NOT NICE.

Actually, I think this attitude is dated for the reverse reason.  In 2013 
*desktop* doesn't matter, and that trend has only been accelerating.  Because 
people access their systems using their personal Macs, or more often using thin 
clients (tablets, mobile devices, etc.)… 10 years ago your arguments were much 
more valid, IMO.

The question is no longer about whether I need a desktop UI on my server, but 
is now moving to whether I need a desktop at all.  (I think a bunch of us *do*, 
but we're a shrinking population.)

[ cut! ]

> One thing many people do not realize is that because of advanced Illumos
> technologies, Illumos-based distributions have a potential to be
> super-desktops in some future. Maybe that IS insane, but
> I tend to see the future where I use GUI to manage servers and do things
> I can not do with CLI-only.

Hey, now you're talking!  If were (or anyone) is going to invest in an illumos 
desktop, why not do it in a way that makes sure that what we're doing is 
*better* than just another Linux distro.  Trying to keep playing catchup with 
Ubuntu is IMO a wasted effort.   If on the other hand you can *surpass* them in 
some meaningful ways, *then* you've got my attention.  The problem is that 
nobody has been able to do that  yet.

> If Fedora would ditch desktop upon install, and Ubuntu started releasing
> only server edition without Desktop environment, what would be left of
> them selling to customers? (Even if server do not run Desktop)
> What would you show to them on the presentation? Black screen of 1985?

They show GDM today.  But who really cares about that?  Of the people who are 
decision makers in any company, how many of them choose a Linux graphical 
desktop?

The exception here is the Chromebook experience and OLPC…. they were able to do 
something cool and make a compelling argument.  But nobody else has built a 
compelling Linux or Unix desktop with a reason to exist besides being "free".  
And there is no commercial value in just being "free" -- you can't make up in 
volume unless you have some revenue. :-)

> 
> I always planned to eventually sell Illumos distro as a server, but I
> want a customer to SEE it and say:
> "OK, NICE, whatever". And not: "Oh, no.., whatever".
> And that is how money could flow. If I have something to contribute back
> , but without GUI, I don't think it can sell.

I think if you believe your buyers care about the desktop, then I think you 
probably don't understand your buyers.  Or possibly I don't understand your 
market -- but in the *server* space almost *nobody* cares about the desktop UI.

- Garrett


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Nikola M.]

On 05/10/13 02:19 AM, Garrett D'Amore wrote:
> more constructive than whinging about it will be to find ways to either a) 
> make a commercially viable case for it so people can get paid to work on it, 
> or b) lead a volunteer effort to make this work.
I think that without Desktop that is running on the server, I can not
sell Illumos based distribution as a server product. That is because
small companies and offices expect to have GUI working, so they can log
in and possible do something with the machine.  I suppose that machine
without GUI would look to them as a "blackbox" if there is just command
line.
There is no desktop per se and server as a product per se. It is the
server distribution that has desktop environment and programs for
convenience. If I am selling it, I am selling a server. And having
Desktop environments on server is nice. Not having desktop environment
on server in 2013 is NOT NICE.

I want to be able to run both legacy apps and have compatibility with
Solaris 10 in it's zone and that's about compatibility. Apps made for
Opensolaris also mostly got integrated in OI.
I want innovation in Illumos and to have separated issues of updating
desktop and GUI parts and applications  from the core OS. Having Desktop
environment that aether is started or not, does not stop innovation in
Illumos from happening and be used in practice.

If Solaris 10 (and 11) is a server operating system (GUI does not hurt
server use),
then Illumos distribution could not be hurt to have GUI available and
not to be stuck in CLI.
To me it is strange, why some people that do not care about having at
least some desktop on top of Illumos,
continuously talking about it?
New people coming to the platform FIRST discover "how much cool" GUI is
and they dig deeper IF you lure them, to at least try using it for some
time. And if they got right info they can get on the ship as users, bug
reporters and then contributors.

I came from Linux, I were a fanboy. I found better technology, I
migrated. On Linux I had everything I actually need, BUT the sense of
sanity that Solaris/Illumos have with integrated technologies in one place.

Since I too think that putting on server anything BUT Illumos-based
distribution , is having not much sense,
I want to have server distro on my *laptop* I can use, develop solution
and then apply it on remote server.

I do not want to use Windows/OSX, VMWare, Microsoft Office etc. (nor
have money to throw on Apple etc)
I want to be able to have things I use independent from hostile
proprietary vendors.
Illumos devs could use Openindiana for their development environment
and run KVM instead of VMWare. And for running Virtualbox I also need
Openindiana.

One thing many people do not realize is that because of advanced Illumos
technologies, Illumos-based distributions have a potential to be
super-desktops in some future. Maybe that IS insane, but
I tend to see the future where I use GUI to manage servers and do things
I can not do with CLI-only.
If Fedora would ditch desktop upon install, and Ubuntu started releasing
only server edition without Desktop environment, what would be left of
them selling to customers? (Even if server do not run Desktop)
What would you show to them on the presentation? Black screen of 1985?

I always planned to eventually sell Illumos distro as a server, but I
want a customer to SEE it and say:
"OK, NICE, whatever". And not: "Oh, no.., whatever".
And that is how money could flow. If I have something to contribute back
, but without GUI, I don't think it can sell.
Anyway, I expect Illumos itself in the OI to include KVM and ZFS disk
bandwidth usage scheduling.
And for GUI- those wanting GUI should care about that. Including me.


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Andrzej Szeszo]

Hi Alasdair

I would like to try setting up a repo on github, give trusted people direct
access and support pull requests from independent developers. And then have
jenkins publish packages incrementally to publicly accessible repository.
In theory, it should only take few minutes from a push to a published
package in a repo.

It is a variation on the process which was tried earlier. I think it might
work this time.

I did some prep work last night. Will try to have something usable by
others later tonight.

Cheers,

Andrzej




On 10 May 2013 14:04, Alasdair Lumsden  wrote:

> Andrzej,
>
> Your vision is pretty much the same one I had. The challenge is this:
>
> "Existing releng process and contribution process prevent anything from
> happening though. I would like to help to change that."
>
> How?
>
>
> On Fri, May 10, 2013 at 12:54 PM, Jim Klimov  wrote:
>
>> On 2013-05-10 02:19, Garrett D'Amore wrote:
>>
>>> There is little "commercial future" in the desktop for Linux
 distributions as well yet almost all of them have a graphical desktop.

>>>
>>> I would be entirely *unsurprised* if distro vendors like RedHat and
>>> Oracle simply *ditched* their desktop support at some point in the future
>>> -- its clear to me at least that folks aren't running those distros on the
>>> desktop.
>>>
>>
>> Well, Oracle does provide and promote SunRays, and while admittedly most
>> of their market targeting is about VDI and access to virtual
>> Windows desktops, there are many requests on the SRSS mailing list
>> about adding support for server-side Ubuntu as the SRSS terminal
>> server, because certain apps only exist for Linux and tunneling
>> of connections makes their graphics lag, and RHEL/OEL/Solaris
>> desktops are argued to be not so user-friendly (I have no opinion
>> on this, to me X11 is a means to display more characters on screen
>> than possible in a text mode).
>>
>> Not that Oracle seems to care to address that demand, at least
>> publicly - just recently they began supporting versions 6 of RHEL
>> and OEL as server-side Linuxes. But there is certain demand for
>> non-MS/Apple desktops, and one linked to commercial interest as
>> well. I am not sure if OI/illumos can ride that tide, though.
>> Maybe with some other terminal client technologies (ThinLinc,
>> Wyse, etc)?..
>>
>> //Jim
>>
>>
>>
>> __**_
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> http://openindiana.org/**mailman/listinfo/oi-dev
>>
>
>
>
> --
> Alasdair Lumsden
>
> http://www.everycity.co.uk
>
> EveryCity Managed Hosting
> Studio 18 Bluelion Place
> 237 Long Lane, London, SE1 4PU
>
> general: 020 7183 2800
> support: 020 7183 2801
> email: a...@everycity.co.uk
>
> Every City Limited
> Registered in England and Wales, No. 5689474 Registered Office: Roper
> Yard, Roper Road, Canterbury, CT2 7EX
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Jonathan Adams]

On 10 May 2013 14:13, Jim Klimov  wrote:

> Are there many (any?) OI-private deviations from illumos-gate?
> I thought it was built with the "vanilla kernel" already.
>

I don't believe that KVM is in the default Illumos kernel, but is in OI.

I don't know whether the planned new Wireless stack is going in Illumos, or
in userland, or would have been designated as an Implementer option ...

Jon
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Jim Klimov]

On 2013-05-10 13:43, Andrzej Szeszo wrote:

I agree with what Peter and Garrett wrote earlier. OI is lacking a clear
vision. It should be different than other illumos distros' as well to
avoid duplicating work unnecessarily.

I think, OI could be "illumos hacker distro", and:

- carry on providing GUI support, good enough for illumos hackers to use
it on their desktops/laptops
- it could potentially be based on vanilla illumos-gate; few OI specific
changes could be upstreamed or dropped
- existing OI users should be able to do pkg update to get the latest bits

Not radical or innovative at all. Different enough to what other distros
are doing though (no GUI, own illumos-gate forks).


Are there many (any?) OI-private deviations from illumos-gate?
I thought it was built with the "vanilla kernel" already.

Also, being a "hacker desktop" distro with access to all other software
packages that are available to other distros does not change the fact
that OI can be used on servers as well - efficiently, with same kernel
capabilities, scaling ability, etc? The difference may be minute, such
as compile-time flags for optimizations, default tuning, administrative
models and "the proper way to do things" (i.e. zones in OI and SmartOS
are AFAIK quite different logical models).

Meaning, that while other distros might be more suitable and optimal
for production servers with a clearly pre-defined purpose, such as a
VM server or an app server or a storage server - built for that purpose,
OI might run a desktop or a "undefined-purpose" server with possibly
smaller efficiency but higher versatility, or admin-friendliness by
means of having same administrative interface as on his desk/lap-top
or just having the interface at the console of the only server in the
small office, etc... maybe :)

//Jim


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Jim Klimov]

On 2013-05-10 14:11, Jonathan Adams wrote:




On 10 May 2013 12:54, Jim Klimov mailto:jimkli...@cos.ru>> wrote:

Well, Oracle does provide and promote SunRays ...

Actually, if you check the SunRay forums people are getting the
impression that Oracle does _not_ promote SunRays, and some of their
sales guys are actively trying to dissuade people from buying them ...
it's got to the point that a large number of the original users are
getting scared and are moving away from them to something like a WYSE
client instead.


Yes, that too. At least, they "say" that they invest more than Sun,
release more often, and such blah-blah. As for licensing... maybe
that's why I mentioned "other terminal technologies" ;)
I heard about problems with sales of some other ex-Sun products -
Oracle has little interest in meddling with small customers; often
this means purchases of thousands of licenses. Smaller volume may
be discussed, but needs approval procedures and is not guaranteed
to happen. Many of largest national companies (in market share terms,
excluding giants like banking and oil industry) have 2-3 thousand 
employees and don't really want to overpay twofold just to qualify

for a minimum-sized purchase. It gets much harder with deployments
which start as some departmental PoC with potential to scale onto
thousands of accounts, but for the starter year would have just
several tens or hundreds of users.

I can understand how it can be cost-ineffective for a bureaucratic
monster to have small customers... but why forbid partners to make
it their problem? Then again, it opens the same niches for smaller
players, including those which provide same ex-Sun technologies at
a smaller price, or just make it possible to buy in small volumes.
This monopoly actually promotes competition and innovation among
scavengers who can feel happy about leftovers from a tiger's meal ;)

my 2c
//jim

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Jonathan Adams]

On 10 May 2013 12:54, Jim Klimov  wrote:

> Well, Oracle does provide and promote SunRays ...
>

Actually, if you check the SunRay forums people are getting the impression
that Oracle does _not_ promote SunRays, and some of their sales guys are
actively trying to dissuade people from buying them ... it's got to the
point that a large number of the original users are getting scared and are
moving away from them to something like a WYSE client instead.

Apart from that and the changes in licenses that Oracle decided to levy
retroactively on our old models when we bought new ones, I love them,
they're great, they do exactly what we need ... but then we only need
access to email, internet and openoffice.
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Alasdair Lumsden]

Andrzej,

Your vision is pretty much the same one I had. The challenge is this:

"Existing releng process and contribution process prevent anything from
happening though. I would like to help to change that."

How?


On Fri, May 10, 2013 at 12:54 PM, Jim Klimov  wrote:

> On 2013-05-10 02:19, Garrett D'Amore wrote:
>
>> There is little "commercial future" in the desktop for Linux
>>> distributions as well yet almost all of them have a graphical desktop.
>>>
>>
>> I would be entirely *unsurprised* if distro vendors like RedHat and
>> Oracle simply *ditched* their desktop support at some point in the future
>> -- its clear to me at least that folks aren't running those distros on the
>> desktop.
>>
>
> Well, Oracle does provide and promote SunRays, and while admittedly most
> of their market targeting is about VDI and access to virtual
> Windows desktops, there are many requests on the SRSS mailing list
> about adding support for server-side Ubuntu as the SRSS terminal
> server, because certain apps only exist for Linux and tunneling
> of connections makes their graphics lag, and RHEL/OEL/Solaris
> desktops are argued to be not so user-friendly (I have no opinion
> on this, to me X11 is a means to display more characters on screen
> than possible in a text mode).
>
> Not that Oracle seems to care to address that demand, at least
> publicly - just recently they began supporting versions 6 of RHEL
> and OEL as server-side Linuxes. But there is certain demand for
> non-MS/Apple desktops, and one linked to commercial interest as
> well. I am not sure if OI/illumos can ride that tide, though.
> Maybe with some other terminal client technologies (ThinLinc,
> Wyse, etc)?..
>
> //Jim
>
>
>
> __**_
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/**mailman/listinfo/oi-dev
>



-- 
Alasdair Lumsden

http://www.everycity.co.uk

EveryCity Managed Hosting
Studio 18 Bluelion Place
237 Long Lane, London, SE1 4PU

general: 020 7183 2800
support: 020 7183 2801
email: a...@everycity.co.uk

Every City Limited
Registered in England and Wales, No. 5689474 Registered Office: Roper
Yard, Roper Road, Canterbury, CT2 7EX
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Jim Klimov]

On 2013-05-10 02:19, Garrett D'Amore wrote:

There is little "commercial future" in the desktop for Linux distributions as 
well yet almost all of them have a graphical desktop.


I would be entirely *unsurprised* if distro vendors like RedHat and Oracle 
simply *ditched* their desktop support at some point in the future -- its clear 
to me at least that folks aren't running those distros on the desktop.


Well, Oracle does provide and promote SunRays, and while admittedly most 
of their market targeting is about VDI and access to virtual

Windows desktops, there are many requests on the SRSS mailing list
about adding support for server-side Ubuntu as the SRSS terminal
server, because certain apps only exist for Linux and tunneling
of connections makes their graphics lag, and RHEL/OEL/Solaris
desktops are argued to be not so user-friendly (I have no opinion
on this, to me X11 is a means to display more characters on screen
than possible in a text mode).

Not that Oracle seems to care to address that demand, at least
publicly - just recently they began supporting versions 6 of RHEL
and OEL as server-side Linuxes. But there is certain demand for
non-MS/Apple desktops, and one linked to commercial interest as
well. I am not sure if OI/illumos can ride that tide, though.
Maybe with some other terminal client technologies (ThinLinc,
Wyse, etc)?..

//Jim


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Andrzej Szeszo]

I agree with what Peter and Garrett wrote earlier. OI is lacking a clear
vision. It should be different than other illumos distros' as well to avoid
duplicating work unnecessarily.

I think, OI could be "illumos hacker distro", and:

- carry on providing GUI support, good enough for illumos hackers to use it
on their desktops/laptops
- it could potentially be based on vanilla illumos-gate; few OI specific
changes could be upstreamed or dropped
- existing OI users should be able to do pkg update to get the latest bits

Not radical or innovative at all. Different enough to what other distros
are doing though (no GUI, own illumos-gate forks).

I did a quick survey on IRC and looks like there is enough talented and
capable people who would be willing to help with the model described above.

Existing releng process and contribution process prevent anything from
happening though. I would like to help to change that.

Radical and innovative ideas are welcome as well. They could be worked on
in parallel as sub-projects.

What do you think about OI being "illumos hacker distro"?

Andrzej



On 10 May 2013 03:12, Nick Zivkovic  wrote:

> For what it's worth,  I only need Xorg, xpdf and xterm to take care of my
> graphics needs. Everything that doesn't involve coding happens on linux,
> mac and winxp.
>
> As long as a distro can support Xorg, it is viable for me. So whatever you
> guys do, please don't remove the basic graphics capability!
> On May 9, 2013 7:20 PM, "Garrett D'Amore" 
> wrote:
>
>>
>> On May 9, 2013, at 4:00 PM, Bob Friesenhahn 
>> wrote:
>>
>> > On Thu, 9 May 2013, Garrett D'Amore wrote:
>> >>
>> >> Upshot, *today* anyone who thinks there is a commercial future in
>> illumos on the desktop is probably smoking something.  There are a few
>> people who would be willing to pay for it, but it needs more than a few
>> dozen people willing to pay a couple hundred dollars (more often
>> substantially less) to make this a viable and interesting (economically)
>> venture.
>> >
>> > There is little "commercial future" in the desktop for Linux
>> distributions as well yet almost all of them have a graphical desktop.
>>
>> Admittedly true.  And yet, most of them *started* on the desktop.
>>  Linux's roots are in the desktop.  Most of those distros took off because
>> they had a groundswell of support from developer users who wanted it on the
>> desktop -- they didn't have servers, and options like VMware simply didn't
>> exist at the time.  I'd argue that this is largely an artifact of history.
>> I would be entirely *unsurprised* if distro vendors like RedHat and Oracle
>> simply *ditched* their desktop support at some point in the future -- its
>> clear to me at least that folks aren't running those distros on the desktop.
>>
>> In fact, I can't think of *anyone* who's paying for a desktop OS that
>> doesn't come from either Apple or Microsoft.
>>
>> > Availability of a graphical desktop is seen as a requirement for common
>> acceptance.
>>
>> Historically true, but I seriously doubt it now.  SmartOS is the counter
>> example from this community.  I think there are others.  For example,
>> OpenBSD was highly popular for a long time for its security emphasis, but I
>> don't know *anyone* who ran it on a desktop.
>>
>> The widespread availability of virtualization like VMware, VirtualBox,
>> and Parallels means that there is little need to take over the user's
>> desktop to provide a reasonable environment.  Most people these days
>> develop using SSH, etc.  The folks I know who use Linux would, apart from a
>> few extremists, not care whether the desktop ran Linux, FreeBSD, or
>> Solaris, as long as it Just Worked and provided a familiar UNIX-like
>> backend.  (I contend that these principles have lead strongly to the uptake
>> of MacOS in the developer community…. I use an Apple laptop for my own
>> environment, even though I wouldn't *dream* of using MacOS in a server
>> capacity.)  For me, Terminal.app and ssh is along with VMware gives me
>> everything I need for doing cool things with illumos on my desktop.  I
>> explicitly *disable* the graphical login on illumos. :-)
>>
>> >  Much/most of the graphical desktop development taking place for Linux
>> does not seem to be done by the companies which popularly peddle it (e.g.
>> Canonical has been more of a desktop packager except for its useless Unity).
>>
>> Only partly true (Qt is the counter example).  But yes, a lot of the
>> desktop development in Gnome and company is done by community members who
>> are passionate about this. And guess what -- almost all those guys are
>> Linux "bigots".  There's a huge trend in those spaces to adopt technologies
>> that are Linux-specific, to the point of near active hostility towards
>> other FOSS.  That creates a huge barrier for leveraging their efforts.  Do
>> we have the kind of volunteerism here to take up a duplicate effort?  And
>> why just duplicate?  If we have *that* kind of interest and volunteerism,
>> I'd

Re: [oi-dev] OI project reboot required

[Nick Zivkovic]

For what it's worth,  I only need Xorg, xpdf and xterm to take care of my
graphics needs. Everything that doesn't involve coding happens on linux,
mac and winxp.

As long as a distro can support Xorg, it is viable for me. So whatever you
guys do, please don't remove the basic graphics capability!
On May 9, 2013 7:20 PM, "Garrett D'Amore" 
wrote:

>
> On May 9, 2013, at 4:00 PM, Bob Friesenhahn 
> wrote:
>
> > On Thu, 9 May 2013, Garrett D'Amore wrote:
> >>
> >> Upshot, *today* anyone who thinks there is a commercial future in
> illumos on the desktop is probably smoking something.  There are a few
> people who would be willing to pay for it, but it needs more than a few
> dozen people willing to pay a couple hundred dollars (more often
> substantially less) to make this a viable and interesting (economically)
> venture.
> >
> > There is little "commercial future" in the desktop for Linux
> distributions as well yet almost all of them have a graphical desktop.
>
> Admittedly true.  And yet, most of them *started* on the desktop.  Linux's
> roots are in the desktop.  Most of those distros took off because they had
> a groundswell of support from developer users who wanted it on the desktop
> -- they didn't have servers, and options like VMware simply didn't exist at
> the time.  I'd argue that this is largely an artifact of history. I would
> be entirely *unsurprised* if distro vendors like RedHat and Oracle simply
> *ditched* their desktop support at some point in the future -- its clear to
> me at least that folks aren't running those distros on the desktop.
>
> In fact, I can't think of *anyone* who's paying for a desktop OS that
> doesn't come from either Apple or Microsoft.
>
> > Availability of a graphical desktop is seen as a requirement for common
> acceptance.
>
> Historically true, but I seriously doubt it now.  SmartOS is the counter
> example from this community.  I think there are others.  For example,
> OpenBSD was highly popular for a long time for its security emphasis, but I
> don't know *anyone* who ran it on a desktop.
>
> The widespread availability of virtualization like VMware, VirtualBox, and
> Parallels means that there is little need to take over the user's desktop
> to provide a reasonable environment.  Most people these days develop using
> SSH, etc.  The folks I know who use Linux would, apart from a few
> extremists, not care whether the desktop ran Linux, FreeBSD, or Solaris, as
> long as it Just Worked and provided a familiar UNIX-like backend.  (I
> contend that these principles have lead strongly to the uptake of MacOS in
> the developer community…. I use an Apple laptop for my own environment,
> even though I wouldn't *dream* of using MacOS in a server capacity.)  For
> me, Terminal.app and ssh is along with VMware gives me everything I need
> for doing cool things with illumos on my desktop.  I explicitly *disable*
> the graphical login on illumos. :-)
>
> >  Much/most of the graphical desktop development taking place for Linux
> does not seem to be done by the companies which popularly peddle it (e.g.
> Canonical has been more of a desktop packager except for its useless Unity).
>
> Only partly true (Qt is the counter example).  But yes, a lot of the
> desktop development in Gnome and company is done by community members who
> are passionate about this. And guess what -- almost all those guys are
> Linux "bigots".  There's a huge trend in those spaces to adopt technologies
> that are Linux-specific, to the point of near active hostility towards
> other FOSS.  That creates a huge barrier for leveraging their efforts.  Do
> we have the kind of volunteerism here to take up a duplicate effort?  And
> why just duplicate?  If we have *that* kind of interest and volunteerism,
> I'd recommend actually doing something *cooler* and better.   Of course,
> that flies in the face of legacy compatibility….
>
>
> >
> > The argument about "no commerical future" is becoming worn out and tired
> since that (commercial purpose) is not why OpenIndiana/Illmos users want to
> log into a graphical desktop.
>
> Worn out and tired it may be, and *yet* people complain about the lack of
> leadership and progress.  I don't know about you, but I have to pay for
> housing, groceries, and gasoline (among other things).  So I have to work
> at things that pay the bills.  I am lucky enough that this maps well to
> things that are also interesting to me.  Maybe its unfortunate that folks
> aren't finding ways to make a living at this, so that a developer community
> will spring up around it.  But more constructive than whinging about it
> will be to find ways to either a) make a commercially viable case for it so
> people can get paid to work on it, or b) lead a volunteer effort to make
> this work.
>
> The problem with "b" is that its a very large, and often thankless, job.
>  People spend more time complaining about broken things on the desktop,
> than they do actually helping fix things.  Individual lea

Re: [oi-dev] OI project reboot required

[Garrett D'Amore]

On May 9, 2013, at 4:00 PM, Bob Friesenhahn  
wrote:

> On Thu, 9 May 2013, Garrett D'Amore wrote:
>> 
>> Upshot, *today* anyone who thinks there is a commercial future in illumos on 
>> the desktop is probably smoking something.  There are a few people who would 
>> be willing to pay for it, but it needs more than a few dozen people willing 
>> to pay a couple hundred dollars (more often substantially less) to make this 
>> a viable and interesting (economically) venture.
> 
> There is little "commercial future" in the desktop for Linux distributions as 
> well yet almost all of them have a graphical desktop.

Admittedly true.  And yet, most of them *started* on the desktop.  Linux's 
roots are in the desktop.  Most of those distros took off because they had a 
groundswell of support from developer users who wanted it on the desktop -- 
they didn't have servers, and options like VMware simply didn't exist at the 
time.  I'd argue that this is largely an artifact of history. I would be 
entirely *unsurprised* if distro vendors like RedHat and Oracle simply 
*ditched* their desktop support at some point in the future -- its clear to me 
at least that folks aren't running those distros on the desktop.

In fact, I can't think of *anyone* who's paying for a desktop OS that doesn't 
come from either Apple or Microsoft. 

> Availability of a graphical desktop is seen as a requirement for common 
> acceptance.

Historically true, but I seriously doubt it now.  SmartOS is the counter 
example from this community.  I think there are others.  For example, OpenBSD 
was highly popular for a long time for its security emphasis, but I don't know 
*anyone* who ran it on a desktop.

The widespread availability of virtualization like VMware, VirtualBox, and 
Parallels means that there is little need to take over the user's desktop to 
provide a reasonable environment.  Most people these days develop using SSH, 
etc.  The folks I know who use Linux would, apart from a few extremists, not 
care whether the desktop ran Linux, FreeBSD, or Solaris, as long as it Just 
Worked and provided a familiar UNIX-like backend.  (I contend that these 
principles have lead strongly to the uptake of MacOS in the developer 
community…. I use an Apple laptop for my own environment, even though I 
wouldn't *dream* of using MacOS in a server capacity.)  For me, Terminal.app 
and ssh is along with VMware gives me everything I need for doing cool things 
with illumos on my desktop.  I explicitly *disable* the graphical login on 
illumos. :-)

>  Much/most of the graphical desktop development taking place for Linux does 
> not seem to be done by the companies which popularly peddle it (e.g. 
> Canonical has been more of a desktop packager except for its useless Unity).

Only partly true (Qt is the counter example).  But yes, a lot of the desktop 
development in Gnome and company is done by community members who are 
passionate about this. And guess what -- almost all those guys are Linux 
"bigots".  There's a huge trend in those spaces to adopt technologies that are 
Linux-specific, to the point of near active hostility towards other FOSS.  That 
creates a huge barrier for leveraging their efforts.  Do we have the kind of 
volunteerism here to take up a duplicate effort?  And why just duplicate?  If 
we have *that* kind of interest and volunteerism, I'd recommend actually doing 
something *cooler* and better.   Of course, that flies in the face of legacy 
compatibility….


> 
> The argument about "no commerical future" is becoming worn out and tired 
> since that (commercial purpose) is not why OpenIndiana/Illmos users want to 
> log into a graphical desktop.

Worn out and tired it may be, and *yet* people complain about the lack of 
leadership and progress.  I don't know about you, but I have to pay for 
housing, groceries, and gasoline (among other things).  So I have to work at 
things that pay the bills.  I am lucky enough that this maps well to things 
that are also interesting to me.  Maybe its unfortunate that folks aren't 
finding ways to make a living at this, so that a developer community will 
spring up around it.  But more constructive than whinging about it will be to 
find ways to either a) make a commercially viable case for it so people can get 
paid to work on it, or b) lead a volunteer effort to make this work.

The problem with "b" is that its a very large, and often thankless, job.  
People spend more time complaining about broken things on the desktop, than 
they do actually helping fix things.  Individual leaders get exhausted, and 
move on.  This is a recurring theme in this community -- Nexenta desktop, 
StormOS, AuroraUX, OI, etc. 

So, it comes, for me at least, back to "a".  Figure out a way to make a 
commercially viable story so that you keep a small group of developers paid.  
Right now, I don't know of any such story, and when I bring this up, the 
responses like yours Bob, amount to nothing more than putting your h

Re: [oi-dev] OI project reboot required

[Martin Bochnig]

On Fri, May 10, 2013 at 1:09 AM, Ian Johnson  wrote:


> Oracle seems to be taking good enough care of the Solaris desktop on its
> end. I'm sure it's a peripheral part of their overall effort, but somebody
> at Oracle is keeping hardware support up to par and fixing desktop bugs.
> It's not the aforementioned commercial case and it's clearly not being
> targeted at desktop users, but for someone like me who cares more about ZFS
> and a good terminal emulator than about Netflix, it's perfectly adequate,
> and I don't think it's fair to peg Oracle for neglecting the desktop.




Ok, for x64.
But what about SPARC graphics driver support versus text-only?
All their JDS work that they still seem to keep in sync for both x64 and
SPARC is of little value, if you have no gfx drivers to start up X11. This
unbelievable direction was admittedly already taken before Oracle took
over, with the removal of Xsun in 2009.

What about the drop of sun4u in 2010 starting with Oracle Solaris Express?
sun4u servers and even the U25/U45 workstations were still sold until 2008
and (the last sun4u big iron servers until 2009).

Not to mention Fujitsu, which is still selling its sun4us line.
I know, there is a secret I cannot post in public. But to the general users
...

Anyways, the 'W' in the original Sun stock ticker symbol "SUNW" stood for
guess what: Workstations.
And then just 1 or 2 years later such complete drops??? Is that fair? If I
was a manager who spent a few hundred thousends or millions in a top 500
enterprise's infrastructure, identify a single reason why I would not
migrate to Linux x64 after such a blow.


BTW: Oracle also removed IA32 support. So if you want to run Solaris 11 on
your PentiumIV Laptop, you cannot do this.
Also consider the removal of all so called "legacy" x86 gfx driver from
Xorg, in 2010.
Only as an example.

With Linux you can still use much of the slightly older hardware out of the
box (without building your own distro).

Just my 5 Kopekes ...



%martin
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Ian Johnson]

On 2013/05/09, at 17:09, Martin Bochnig  wrote:

> On Thu, May 9, 2013 at 10:05 PM, Milan Jurik  wrote:
> enjoy it (and my private life also). And to be fair, with total lost of
> interest in desktop systems in Illumos by "core team", I have less and
> less motivation to work on it.
> 
> 
> 
> Hi Milan, 
> 
> 
> good observation.
> Sadly I must agree with you: While Oracle  sees Solaris only as wrapper for 
> their database, the Illumos sponsors only seem to be interested in selling 
> their x64 JBOD solutions and servers.
> Everything else is just "in the way" and doesn't deserve any backing, 
> especially not financial support.
> I experience this all the way along with SPARC, OpenSXCE or whatever is of 
> little commercial use to these corporations. Forget individuals like myself 
> or the other hardcore enthusiasts. But especially I'm not sure if this serves 
> the broader Solaris user base all too well, either.
> 
> Fortunately Garrett is more interested in keeping Solaris a multipurpose OS.
> But only money pays developers. And so only it is able to make a substantial 
> change.

Oracle seems to be taking good enough care of the Solaris desktop on its end. 
I'm sure it's a peripheral part of their overall effort, but somebody at Oracle 
is keeping hardware support up to par and fixing desktop bugs. It's not the 
aforementioned commercial case and it's clearly not being targeted at desktop 
users, but for someone like me who cares more about ZFS and a good terminal 
emulator than about Netflix, it's perfectly adequate, and I don't think it's 
fair to peg Oracle for neglecting the desktop. Clearly, the OI desktop usage 
case is not going to be a commercial one, so the only question is whether there 
are enough interested volunteer developers to sustain it. Various Linux 
distributions have shown that a commercial usage case is not the only way to 
sustain a general-purpose graphical OS, but they have also had a critical mass 
of users and developers to support the project instead. I don't know what the 
long-term answer to that question is for OI, but for what it's worth, the one 
thing that keeps me off of it as a desktop platform is a CJK text bug in 
Illumos and not an issue with OI itself.

Ian Johnson
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Dave Koelmeyer]

Precisely. 

Cheers
Dave

Bob Friesenhahn  wrote:

>Availability of a graphical desktop is seen as a requirement for 
>common acceptance.  Much/most of the graphical desktop development 
>taking place for Linux does not seem to be done by the companies which 
>popularly peddle it (e.g. Canonical has been more of a desktop 
>packager except for its useless Unity).
>
>The argument about "no commerical future" is becoming worn out and 
>tired since that (commercial purpose) is not why OpenIndiana/Illmos 
>users want to log into a graphical desktop.


-- 
Sent from Kaiten Mail. Please excuse my brevity.

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Bob Friesenhahn]

On Thu, 9 May 2013, Garrett D'Amore wrote:


Upshot, *today* anyone who thinks there is a commercial future in 
illumos on the desktop is probably smoking something.  There are a 
few people who would be willing to pay for it, but it needs more 
than a few dozen people willing to pay a couple hundred dollars 
(more often substantially less) to make this a viable and 
interesting (economically) venture.


There is little "commercial future" in the desktop for Linux 
distributions as well yet almost all of them have a graphical desktop. 
Availability of a graphical desktop is seen as a requirement for 
common acceptance.  Much/most of the graphical desktop development 
taking place for Linux does not seem to be done by the companies which 
popularly peddle it (e.g. Canonical has been more of a desktop 
packager except for its useless Unity).


The argument about "no commerical future" is becoming worn out and 
tired since that (commercial purpose) is not why OpenIndiana/Illmos 
users want to log into a graphical desktop.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Martin Bochnig]

On Thu, May 9, 2013 at 10:05 PM, Milan Jurik  wrote:

> enjoy it (and my private life also). And to be fair, with total lost of
> interest in desktop systems in Illumos by "core team", I have less and
> less motivation to work on it.




Hi Milan,


good observation.
Sadly I must agree with you: While Oracle  sees Solaris only as wrapper for
their database, the Illumos sponsors only seem to be interested in selling
their x64 JBOD solutions and servers.
Everything else is just "in the way" and doesn't deserve any backing,
especially not financial support.
I experience this all the way along with SPARC, OpenSXCE or whatever is of
little commercial use to these corporations. Forget individuals like myself
or the other hardcore enthusiasts. But especially I'm not sure if this
serves the broader Solaris user base all too well, either.

Fortunately Garrett is more interested in keeping Solaris a multipurpose OS.
But only money pays developers. And so only it is able to make a
substantial change.



Regards,
Martin
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Garrett D'Amore]

On May 9, 2013, at 1:05 PM, Milan Jurik  wrote:

> Hi,
> 
> OK, so start yet another distro :-)
> 
> OI needs one thing it does not have - release engineering "team". Jon is
> too busy and I cannot do that. I am happy to work on some things from
> time to time for fun but my job is more and more time consuming and I
> enjoy it (and my private life also). And to be fair, with total lost of
> interest in desktop systems in Illumos by "core team", I have less and
> less motivation to work on it.

I'm not sure who the "core team" for illumos is -- I'd guess I'm part of it, 
since I started the darn project, but we don't have any definition of core 
team, apart from the Developer Council.  As the developer council is made of up 
some of the most widely recognized illumos/Solaris leadership, and almost 
*never* actually makes any official decisions, its hard to say there is any 
group of people that you'd say "has no interest in desktop systems".

What *is* true is that there is zero commercial investment in illumos on the 
desktop, while there is substantial commercial investment on server side 
innovation.  This is not a bad thing -- we (the commercial investors in illumos 
-- the folks who use and develop it as part of our day jobs) simply recognize 
that like any tool, illumos has some tasks that it is well suited for, and 
others where other tools make more sense.

Some may attribute this type of thinking to nefarious purposes, but it really 
comes down to something much much simpler.  Economics.  Maintaining a desktop 
capable system is *hard*.  Making one that can compete against capable 
offerings from Apple, Microsoft, Google, and Canonical is *really* hard.  And 
*those* guys are fighting a battle to keep the very desktop itself, relevant, 
in the face of tablet devices.  And so how do you make a commercial case for 
investing in illumos on the desktop?  There are some specious arguments for 
supporting legacy uses, facilitating developer adoption, etc., but none of them 
have actually borne fruit, and there are known non-trivial hurdles for such 
cases.  Indeed, the very failure of OpenSolaris itself can be cited as an 
example of this failure -- Sun with not inconsiderable investment and 
resources, was unable to make a commercially viable desktop based on Solaris 
technology, even though they were clearly willing to do so even at the 
*expense* of their otherwise lucrative server business.

So most of us have learned from those failures (even though they may not have 
been our own), and moved on.

(Admittedly there are still people in Oracle working on the Solaris desktop, 
but AFAICS that mostly amounts to acting as a gateway to Microsoft systems via 
Rdesktop, or acting as a glorified webtop / kiosk front end.  And I think you'd 
be hard pressed to show those efforts as being profit centers within Oracle.  
They're mostly seen as supportive of Oracle's other more core business needs.)

Upshot, *today* anyone who thinks there is a commercial future in illumos on 
the desktop is probably smoking something.  There are a few people who would be 
willing to pay for it, but it needs more than a few dozen people willing to pay 
a couple hundred dollars (more often substantially less) to make this a viable 
and interesting (economically) venture.

What that means is that illumos desktop technologies have been relegated, at 
least for the time being, to the realm of hobbyists.  In some cases, very 
talented hobbyists -- even in some cases people who work professionally on 
illumos server technologies --, but hobbyists nonetheless.

All this said, I'd love for someone to come up with a believable, realistic 
story for making a commercial desktop product on illumos.  I think it would be 
good for illumos.  But in the absence of more compelling evidence to the 
contrary, I'd question the sanity, or sobriety, of anyone who seriously thought 
that commercial investment in illumos on the desktop made sense today.

- Garrett



___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Milan Jurik]

Hi,

OK, so start yet another distro :-)

OI needs one thing it does not have - release engineering "team". Jon is
too busy and I cannot do that. I am happy to work on some things from
time to time for fun but my job is more and more time consuming and I
enjoy it (and my private life also). And to be fair, with total lost of
interest in desktop systems in Illumos by "core team", I have less and
less motivation to work on it.

FYI, on my system I have something which is 151a8 with newer JDS but I
have no chance to push it to consumers.

Best regards,

Milan

On čt, 2013-05-09 at 10:01 +0200, Andrzej Szeszo wrote:
> Hi All
> 
> 
> (Instead of replying to a message in one of the other threads
> I thought I will create a new one.)
> 
> 
> Just wanted to say that I don't see a future for the project in its
> current form. There is simply too many packages and too much baggage
> for a handful of people to look after.
> 
> 
> I think the project needs a new vision and a reboot. If you have any
> ideas for the project and can write scripts/makefiles to generate a
> distro/live CDs/etc. - speak up! You don't have to be a leader if you
> don't want to :)
> 
> 
> Regards,
> 
> 
> Andrzej
> 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[James Winter]

Having the server is key to the linux / unix world.  Portability is the 
newer direction that several distros are moving toward so a 
multi-platform architecture is key.  Would we be able to include a few 
compilers (C / C++ etc. ) stock for when the driver is not available 
after initial install?


I have previously worked on network architecture and system monitoring.  
Lemme know where / when I can help :-)


James R. M. Winter

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Martin Bochnig]

Privet !


On Thu, May 9, 2013 at 1:45 PM, Jim Klimov  wrote:

> On 2013-05-09 13:06, Andrzej Szeszo wrote:
>
>> The process you have described sounds a lot like OI's original plan. It
>> didn't work out. There was too much baggage. No one was willing to spend
>> time learning it. It was just too ... ugly.
>>
>
> It's possible to try it differently this time :)
>


One of the main reasons why it is complicated to build OpenSolaris, is
definitely IPS itself.
Rather than just the fact, that almost every of the consolidations has
different ways in which they implemented their build, with different
locations for Makefile.master, a different directory hierarchy versus even
with pkgbuild and .spec files.
To resolve deps, that's cpu intensive like little else and also error prone.



>
> One way or another, in these consolidations we have tons of source
> code, which, one way or another, need a process to build them.
>
> Even if the system of build scripts, spec recipes, makefiles and so
> on would be changed to something else, just to develop this new build
> logic and to check validity and comparability of the resulting packages
> we (individual developers) need to be able to build it "the old way"
> and "the new way" (whatever that would be). AFAIK, very few people
> know what to do to create the binaries and packages in the old
> techniques, which makes it problematic for others (not "in the know")
> to start improvements or from-scratch rewrites.
>



Starting in 2007 I had the same dream. And I even started and made some
progress (still have it somewhere in my backup archives). My idea was, to
merge all consolidations (for MartUX) into one single Makefiles system,
namely into that of Sun's X11 group, as developed by Alan Coopersmith and
team on the basis of OS/Net's Makefiles. I think Moinak Ghosh has worked on
something similar even before me (as I learned later), and has come
further. So I stopped the effort. I recall that he released this on
belenix.org a long time ago. If I'm corerct he once called it
DistroGenerator (don't confuse this with DistroConstructor, which, btw, HE
also invented long before Sun took err stole it).The first so called
"Indiana" was in fact BeleniX in 2007!!! And is was completely unfair and
injust that Sun had hired that Ian Murdock destructor purely for marketing
reasons alone, and that he was permitted to give the stolen BeleniX his
name. This is the primary reason why those that remember all this
(including myself) could never be happy with the name "ind_IAN_a".




> Of course, some architectural overview or general framework for all
> consolidations of what we want to achieve as the new build system
> (i.e. "conforms to this list of technical requirements: A, B, C... Z")
> would be needed.
>
> I may be wrong to think that ability to build the whole beast in the
> old ways is useful to make the new building technology, but lack of
> it also hinders an ability to make new spins of the whole OI distro
> or just updated package repos, as one other commonly-requested useful
> result of the overall OI project. So far most users can rebuild the
> "kernel" part (illumos-gate) of their installations and third-party
> code like updated sendmail, apache or whatever they need to update,
> rebuilt and installed in traditional unpackaged ways into alternate
> paths or even overriding the system binaries, but that's about it.
> And this is wrong, especially for SOHO farms of several OI machines
> or zones which could otherwise reuse the in-house updated packages
> automatically and properly :)



I made bad experiences with IPS.
With SVR4 all this is a ton (1000kg!) easier, more transparent, and more
fine grained.
You can touch every package, even inside the repo, by hand.
It is not a database like monster, black box or even rather black hole,
that IPS appears to be, in my personal view (sorry about that).

Example: If you want to change a single package, maybe even a single file,
or an arbitrary number of packages, it is always easy, transparent and
doable: http://svr4.opensxce.org/sparc/5.11/

For example, if a new Firefox comes out, many users care about "the newest
version, yeah".
Here is the SVR4 way:

0.) Delete
http://svr4.opensxce.org/sparc/5.11/sunw_firefox-18.0%2cREV%3d110.0.4.2013.01.10.17.25-SunOS5.11-sparc-SUNW.pkg.gz

1.) Build FF or take the Oracle supplied redistributable bins from China
and create the package by just hitting make install in my prepared
SUNWfirefox subdir, this creates the SUNWfirefox package

2.) With a plain flat miniscript from another dir  convert it into the
pkgtool.net format

3.) Copy over or sftp upload the new file to
http://svr4.opensxce.org/sparc/5.11/

4.) ssh into http://svr4.opensxce.org/sparc/5.11/ and run bldcat
(if the server hosting http://svr4.opensxce.org/sparc/5.11/ is not a
Solaris machine, just do the previous steps but  take your local mirror of
http://svr4.opensxce.org/sparc/5.11/ and run bldcat there, then simply
upload the two ca

Re: [oi-dev] OI project reboot required

[Jonathan Adams]

On 9 May 2013 18:10, Garrett D'Amore  wrote:

> Fundamentally, the question you all should be asking is, what is the
> purpose of the project?
>

 What I want from OI is very similar to what was described by Ken Mays:

1. Provide an updated kernel userland (i.e. Illumos-gate, rev: 19e11862653b
or higher). This allows people that use OI for server-based projects to
stay in sync with Illumos development on a much wider scale.

2. Optionally, implement JDS updates already maintained by Milan

That is it. This also keeps most things consistent to other project work
dealing with GNU/userland/spec-files-extra testing with <= oi_151a7.

I personally want an Illumos kernel with a Graphical stack, that can run
Solaris programs, or at least allow for them to be compiled.

Long term I'd like to make sure that big programs (e.g. Oracle Database)
work on it, but since that's a big money item, we'll probably pay to keep
that on our Solaris Servers :(

I'm not a kernel person though, and I haven't played with other Illumos
based distributions ... I compile and configure software, and I would be
happy to try and package newer versions of software to be made available
elsewhere, if someone can hold my hand for the first couple of times :P

Where this is leading me is this….
>
> 1. Is there enough market demand/interest/skills/resources to justify a
> "legacy style" distro (something more like Solaris 10 than Solaris 11/OI,
> including SPARC distro support, etc.)  It seems there is almost enough
> talent here -- perhaps if those forces worked together more collaboratively
> we'd see something good come about?
>
> 2. Is there a need for a more forward looking distro apart from the work
> being done in OmniOS?  (To be clear, I'm not affiliated with OmniTI in any
> way -- I just hate to see pointless duplication of effort)
>

Is there an "upgrade" path for OI? Do you know if I can upgrade from OI to
OmniOS by updating the IPS package repositories or similar? is there a way
out for servers that already have this software installed?

I do agree that it would be good to avoid needless duplication.

Just my 2 cents.

Jon
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Garrett D'Amore]

Fundamentally, the question you all should be asking is, what is the purpose of 
the project?

The problem with OI has always been lack of a clear vision.  The original 
purpose, to be a free community-run clone of Solaris 11, had no future.  It was 
doomed to fail because it was an attempt to follow a leader who who did not 
want to be followed and was making changes that specifically made such an 
attempt extraordinarily difficult (like changing closed source dependencies) -- 
and the leader had also itself lost its vision, or at least altered it, such 
that it was never going to the same places that the folks behind OI wanted to 
go.

I'm a big fan of trying to build cool and interesting technologies.  Of 
innovation.

Can OI innovate?  Its not clear to me.  Thankfully, *illumos* is certainly 
innovating.  Other distros are innovating.  Some in cases that lead very very 
far from the "vision" or model of OI. (SmartOS has led the way the most -- 
challenging many of us to rethink how we manage systems, in ways that 
ultimately have been extremely beneficial for those who were able to cross the 
cognitive hurdles presented by its new administrative model.)

Can OI find a niche that sets itself apart from excellent options like SmartOS 
and OmniOS?  Is there even a purpose to such differentiation?

I don't know the answers to these questions.

I do think that there is always going to be substantial tension between those 
who want to keep compatibility with their old stuff (whether the "old stuff" be 
legacy closed source applications, scripts that they wrote 15 years ago, 
decades old SPARC kit, ancient laptops, or 10 Mbps ethernet with AUI 
transceivers), and the people who want to innovate and explore modernization 
(Gary Mills' work to support login names > 8 characters is a prime example of 
this tension).   Its a tricky balance to find, and many of the hardest working 
people (Martin Bochnig comes to mind, for example) are firmly in the "don't 
break my old stuff" camp.  The problem is that this camp is inherently change 
resistant -- and yet fundamentally OI was already too different from previous 
Solaris releases to satisfy those folks.

Where this is leading me is this….

1. Is there enough market demand/interest/skills/resources to justify a "legacy 
style" distro (something more like Solaris 10 than Solaris 11/OI, including 
SPARC distro support, etc.)  It seems there is almost enough talent here -- 
perhaps if those forces worked together more collaboratively we'd see something 
good come about?

2. Is there a need for a more forward looking distro apart from the work being 
done in OmniOS?  (To be clear, I'm not affiliated with OmniTI in any way -- I 
just hate to see pointless duplication of effort)

Again, I don't know the answers to these questions, but I *strongly* believe 
that anyone thinking of stepping up to reboot the OI project (or create any new 
one) needs to have a much clearer vision -- and needs to be a strong enough 
leader to more or less enforce this vision.  A democracy here won't work -- 
precisely because of the pressures I've already indicated.  In my opinion it 
would be better to spawn two separate projects, each of which creates value to 
serve their adherents, than to have single project that cannot make any 
progress because of the inherent inability to resolve the differences between 
the two main camps.

What I *will* say is this… regardless of what happens, I'm very pleased that 
illumos will carry on -- and continues to be a home for innovation, thanks in 
no small part to the efforts of folks like Joyent, OmniTI, Nexenta, DEY, and 
perhaps many others who've been working more quietly.  I'm incredibly grateful 
to the team that put OI together -- it filled an important gap in the 
ecosystem, and contributed significantly to the uptake of illumos -- so 
regardless of what ultimately becomes of the project, a big thank you to the 
various parties who put it together.

- Garrett

On May 9, 2013, at 1:01 AM, Andrzej Szeszo  wrote:

> Hi All
> 
> (Instead of replying to a message in one of the other threads I thought I 
> will create a new one.)
> 
> Just wanted to say that I don't see a future for the project in its current 
> form. There is simply too many packages and too much baggage for a handful of 
> people to look after.
> 
> I think the project needs a new vision and a reboot. If you have any ideas 
> for the project and can write scripts/makefiles to generate a distro/live 
> CDs/etc. - speak up! You don't have to be a leader if you don't want to :)
> 
> Regards,
> 
> Andrzej
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Alan Coopersmith]

On 05/ 9/13 04:06 AM, Andrzej Szeszo wrote:

The process you have described sounds a lot like OI's original plan. It didn't
work out. There was too much baggage. No one was willing to spend time learning
it. It was just too ... ugly.


OI's original plan was also based mainly around building the consolidations as
they came from Oracle, leveraging the work done there to keep the components up
to date with upstream versions, fixing bugs, applying security patches, etc.

Unfortunately, with the closing of the ON sources shortly thereafter, that meant
you couldn't always use the Oracle code directly, as it picked up more and more
dependencies on the closed Oracle code over time, that had to be worked around
or patched out for OI builds.

Any new plan should consider this and take it into account when figuring out 
what sources you build from where.


--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Jim Klimov]

On 2013-05-09 16:02, Bob Friesenhahn wrote:

The Tribblix approach is likely a good one.  Start off with a good
smaller core and then add more sophisticated features via packages.
This requires a new distribution though.



Two words: "backwards compatibility" ;)

Reinventing the wheel from scratch doesn't mean that it magically
becomes incompatible and should be renamed and called a new project.
If it is round, and weight can be put on an axle, it is still a wheel.

As long as the administrative (end-user) interfaces remain in place,
the ways we get there can change. In case of OI, as a multipurpose
distribution which is an upgrade path for IPS-based OpenSolaris (and
older OI) systems with SVR4 support, there is just a certain set of
properties that should remain in place. Whatever the process is under
the hood - we don't really care, all it should do is create the IPS
packages and spit them out via pkg.oi.o repository server.

I am not convinced that a new system rewritten from scratch won't be
able to make an output indistinguishable (to a reasonable compatible
extent) from whatever the current "ugly difficult" process produces.

In short, change of the process does not require that this becomes a
new distro. Especially since the impact on deployments would be minimal:
there's just a few people that know the current process and practice
its black magic, and are allegedly fed up with doing so and have little
personal attachment to have that remain in place. If a functionally
equivalent compilation technique appears, which a wider audience can
use, there are nearly zero systems that must be "converted" to it and
won't know that they should do so (i.e. flag-day changes). Likely,
those systems that fulfill this role now would be the ones that will
implement the new method first - if not develop it directly ;)

//Jim


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Bob Friesenhahn]

On Thu, 9 May 2013, Peter Tribble wrote:


And also what differentiates you from other offerings. Specifically,
thinking about other similar projects, what would OI offer that you
wouldn't get from OmniOS (which I regard as the closest distro)?


The main differentiators appear to be the ability to log into a 
graphical multimedia desktop (similar to Linux) and the ability to 
install and execute most existing Solaris binaries.



I had a completely different vision - both directionally and technically -
and ended up completely throwing away all the build system(s),
and the entire packaging and install infrastructure. Having to largely
reinvent a whole mass of functionality for Tribblix from scratch was
orders of magnitude easier than using what was inherited from
OpenSolaris.


The Tribblix approach is likely a good one.  Start off with a good 
smaller core and then add more sophisticated features via packages. 
This requires a new distribution though.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Sašo Kiselkov]

On 05/09/2013 03:55 PM, mag...@yonderway.com wrote:
> 
> 
> On Thu, 09 May 2013 15:39:39 +0200, Sašo Kiselkov 
> wrote:
> 
>> The finer details of release engineering and project architecture is of
>> course something to be debated, but probably not on a public forum.
> 
> Why not?

Cause not everybody's opinion is equally well informed. I for my part
don't give a fuck if the control information packages I'd maintain for
OI were kept in Makefiles or spec files, the bug tracker was Bugzilla or
Trac or whatever minor technical knit.

I need to know how I start working on packages, who to talk to and where
to get the details of how the process works. I don't need to improve the
process, I only need to know it.

Cheers,
--
Saso

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[magnus]

On Thu, 09 May 2013 15:39:39 +0200, Sašo Kiselkov 
wrote:

> The finer details of release engineering and project architecture is of
> course something to be debated, but probably not on a public forum.

Why not?

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Jim Klimov]

On 2013-05-09 14:45, Peter Tribble wrote:

I think you need to go back a level further. What's the project for?

Try to put together a quick mission statement (or even a mission word).
And work on an elevator pitch that can grab any member of your potential
audience.


I'd think OI is for developers working and "living in" their operating
system. It is for sysadmins eager to do small tests while on a trip or
commuting to work and back, and running the same OS on laptop and on a
datacenter numbercruncher, administered and maintained in the same way
(kind of like when Sun made an UltraSPARC-IIIi laptop to provide the
whole spectre of machinery). It is to secure laptops from bit-rot, by
storing data with copies=2 and just plain checksum reporting in ZFS on
single-spindle disks (HDD slots are in greater demand than terabytes
on most notebooks which provide one of these and many of others). Maybe
it is (wishful thinking) for home and perhaps SOHO do-it-all machines,
running multimedia playback on the bigscreen TVs and storing all the
family's data securely on ZFS and for doing some interactive work and
even gameplay (you know, there's a lot of good open-source games in
Java or made for Linux/MacOS and potentially compilable for Solaris,
and even the crappy VESA/VGA graphics is sufficient to run i.e. the
strategy games on OI while waiting for something to compile), with
minimum sprawl of PCs made for just one task. Save electrons :)

While virtualization might answer a few of these challenges, especially
for things that are currently absent or incomplete in OI itself, that
would be a workaround and with certain drawbacks/trade-offs in terms of
performance and reliability.


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Sašo Kiselkov]

On 05/09/2013 03:29 PM, Alasdair Lumsden wrote:
> It certainly had plenty of users.

Still has. What needs to be done is stop bickering about stuff on the
mailing list and starting pushing out releases. By that I don't mean
that you or anybody else in the community is doing something bad - you
did wonderful work. It's just that there's a lot of armchair experts who
like to disagree on minutia and lose overview of the big picture.

All users care about is:

 *) how stable is this release
 *) when's the next release
 *) for commercial guys: who do I blame when shit doesn't work
(having paid for shit to work in advance is of course a given)

The finer details of release engineering and project architecture is of
course something to be debated, but probably not on a public forum.

Cheers,
-- 
Saso

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Alasdair Lumsden]

Hi,

One thing to keep in mind that OI has (or at least, had) the largest
install base of any OpenSolaris derived distro, thanks to the fact it is
"upgrade compatible" with OpenSolaris. If you don't maintain that, then
there is no point in continuing with OI - you may as well start with OmniOS.

My personal view was that I wanted OI to be to illumos what Debian was to
Linux - a community maintained general purpose operating system.

If we had managed to kick OI into shape with regular releases and up to
date software, it might have had a bright future. It certainly had plenty
of users.

Alasdair


On Thu, May 9, 2013 at 2:05 PM, ken mays  wrote:

> Hello,
>
> 1. Provide an updated kernel userland (i.e. Illumos-gate, rev:
> 19e11862653b or higher). This allows people that use OI for server-based
> projects to stay in sync with Illumos development on a much wider scale.
>
> 2. Optionally, implement JDS updates already maintained by Milan from
> http://pkg.opensolaris.cz/osol/en/index.shtml.
>
> That is it. This also keeps most things consistent to other project work
> dealing with GNU/userland/spec-files-extra testing with <= oi_151a7.
>
> You can do this with very minimal manpower and not need to rebuild
> components / entire consolidations as much (aka 'project overkill'). You
> can also
> just dump the updated packages in a IPS repo for testing and review.
>
> You don't necessarily have to 'make world' right off the cuff. Start
> small, then think big.
>
> Fact: Entire distribution projects like Tribblix, Milax/OpenSXCE, EON, and
> DilOS are maintained by 1-2 people.
>
>
> Hope that helped,
>
> Ken Mays
>
>
>
>
>
>
>
>
>
>
>   --------------
>  *From:* Andrzej Szeszo 
> *To:* OpenIndiana Developer mailing list 
> *Sent:* Thursday, May 9, 2013 4:01 AM
> *Subject:* [oi-dev] OI project reboot required
>
> Hi All
>
> (Instead of replying to a message in one of the other threads I thought I
> will create a new one.)
>
> Just wanted to say that I don't see a future for the project in its
> current form. There is simply too many packages and too much baggage for a
> handful of people to look after.
>
> I think the project needs a new vision and a reboot. If you have any ideas
> for the project and can write scripts/makefiles to generate a distro/live
> CDs/etc. - speak up! You don't have to be a leader if you don't want to :)
>
> Regards,
>
> Andrzej
>
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>



-- 
Alasdair Lumsden

http://www.everycity.co.uk

EveryCity Managed Hosting
Studio 18 Bluelion Place
237 Long Lane, London, SE1 4PU

general: 020 7183 2800
support: 020 7183 2801
email: a...@everycity.co.uk

Every City Limited
Registered in England and Wales, No. 5689474 Registered Office: Roper
Yard, Roper Road, Canterbury, CT2 7EX
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[ken mays]

Hello,

1. Provide an updated kernel userland (i.e. Illumos-gate, rev: 19e11862653b or 
higher). This allows people that use OI for server-based projects to stay in 
sync with Illumos development on a much wider scale. 

2. Optionally, implement JDS updates already maintained by Milan from 
http://pkg.opensolaris.cz/osol/en/index.shtml.

That is it. This also keeps most things consistent to other project work 
dealing with GNU/userland/spec-files-extra testing with <= oi_151a7.


You can do this with very minimal manpower and not need to rebuild components / 
entire consolidations as much (aka 'project overkill'). You can also
just dump the updated packages in a IPS repo for testing and review.

You don't necessarily have to 'make world' right off the cuff. Start small, 
then think big.

Fact: Entire distribution projects like Tribblix, Milax/OpenSXCE, EON, and 
DilOS are maintained by 1-2 people.


Hope that helped,


Ken Mays







 




 From: Andrzej Szeszo 
To: OpenIndiana Developer mailing list  
Sent: Thursday, May 9, 2013 4:01 AM
Subject: [oi-dev] OI project reboot required
 


Hi All

(Instead of replying to a message in one of the other threads I thought I will 
create a new one.)

Just wanted to say that I don't see a future for the project in its current 
form. There is simply too many packages and too much baggage for a handful of 
people to look after.

I think the project needs a new vision and a reboot. If you have any ideas for 
the project and can write scripts/makefiles to generate a distro/live CDs/etc. 
- speak up! You don't have to be a leader if you don't want to :)

Regards,

Andrzej

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Peter Tribble]

Hi,

(Instead of replying to a message in one of the other threads I thought I
> will create a new one.)
>
> Just wanted to say that I don't see a future for the project in its
> current form. There is simply too many packages and too much baggage for a
> handful of people to look after.
>

I think you need to go back a level further. What's the project for?

Try to put together a quick mission statement (or even a mission word).
And work on an elevator pitch that can grab any member of your potential
audience.

Part of that is thinking about your audience - both the providers
(contributors/developers) and consumers (users/customers).

And also what differentiates you from other offerings. Specifically,
thinking about other similar projects, what would OI offer that you
wouldn't get from OmniOS (which I regard as the closest distro)?


> I think the project needs a new vision and a reboot. If you have any ideas
> for the project and can write scripts/makefiles to generate a distro/live
> CDs/etc. - speak up! You don't have to be a leader if you don't want to :)
>

Concentrate on the vision, and get people engaged. That'll give
you a start on having manpower to do the work.

I had a completely different vision - both directionally and technically -
and ended up completely throwing away all the build system(s),
and the entire packaging and install infrastructure. Having to largely
reinvent a whole mass of functionality for Tribblix from scratch was
orders of magnitude easier than using what was inherited from
OpenSolaris.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Andrzej Szeszo]

Hi David

Igor is doing great job with his CIBS stuff. Certainly worth consideration
for a project reboot.

I agree on the contribution front. I had similar experience with Vagrant.
It took probably less than 1h for my change to end up in the official repo.

Andrzej




On 9 May 2013 11:08, David Höppner <0xf...@gmail.com> wrote:

> I think Igor Pashev has done some valueable work with
> https://github.com/Nexenta/cibs
> https://github.com/ip1981/last-hope
>
> When I was core member of the Homebrew project we just used
> github pull requests.  Contributing should be simple and easy.
> If I found problems with a patch, I just fixed it in place.
>
> -- David
>
> On 9 May 2013 10:01, Andrzej Szeszo  wrote:
> > Hi All
> >
> > (Instead of replying to a message in one of the other threads I thought I
> > will create a new one.)
> >
> > Just wanted to say that I don't see a future for the project in its
> current
> > form. There is simply too many packages and too much baggage for a
> handful
> > of people to look after.
> >
> > I think the project needs a new vision and a reboot. If you have any
> ideas
> > for the project and can write scripts/makefiles to generate a distro/live
> > CDs/etc. - speak up! You don't have to be a leader if you don't want to
> :)
> >
> > Regards,
> >
> > Andrzej
> >
> >
> > ___
> > oi-dev mailing list
> > oi-dev@openindiana.org
> > http://openindiana.org/mailman/listinfo/oi-dev
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Jim Klimov]

On 2013-05-09 13:06, Andrzej Szeszo wrote:

The process you have described sounds a lot like OI's original plan. It
didn't work out. There was too much baggage. No one was willing to spend
time learning it. It was just too ... ugly.


It's possible to try it differently this time :)

One way or another, in these consolidations we have tons of source
code, which, one way or another, need a process to build them.

Even if the system of build scripts, spec recipes, makefiles and so
on would be changed to something else, just to develop this new build
logic and to check validity and comparability of the resulting packages
we (individual developers) need to be able to build it "the old way"
and "the new way" (whatever that would be). AFAIK, very few people
know what to do to create the binaries and packages in the old
techniques, which makes it problematic for others (not "in the know")
to start improvements or from-scratch rewrites.

Of course, some architectural overview or general framework for all
consolidations of what we want to achieve as the new build system
(i.e. "conforms to this list of technical requirements: A, B, C... Z")
would be needed.

I may be wrong to think that ability to build the whole beast in the
old ways is useful to make the new building technology, but lack of
it also hinders an ability to make new spins of the whole OI distro
or just updated package repos, as one other commonly-requested useful
result of the overall OI project. So far most users can rebuild the
"kernel" part (illumos-gate) of their installations and third-party
code like updated sendmail, apache or whatever they need to update,
rebuilt and installed in traditional unpackaged ways into alternate
paths or even overriding the system binaries, but that's about it.
And this is wrong, especially for SOHO farms of several OI machines
or zones which could otherwise reuse the in-house updated packages
automatically and properly :)


Individual gates provide some semi-automated ways of building things. I
don't know anyone who managed to automate them all though. No one was
able to provide equivalent of "make world" to build complete OI to date.


There are occasional requests on the list from people who are willing
to give it a try, and look at the same bits of knowledge from their
perspective. If those are shared, including the info on what works
and what doesn't and hypotheses on why it doesn't, it is possible
that just by sheer increase of the number of eyes, hands and brains
aimed at parts of the problem, it would budge and give in :)

After all, most "manual" administrative tasks can be scripted with
mega-scripts of logic based on practical observations (do this, check
that, don't do this if...). If someone formulates the problems in
English, others can translate them to bash or perl or make scripts...


There is no doubt Martin Bochnig has a lot of expertise in putting
operating systems together. I got impression that he was heavily
invested in SVR4 based systems though. OI may not be an interesting
project for him as it will probably remain IPS based for the time being.


I did lose track of what he implemented in the end, but I think his
builds did rely on existing IPS manifests, and he had fixed quite a
few, and the SVR4 packages were built using automated backports of
the IPS metadata. IF this assessment is correct, then it is more a
matter of taste - which packaging system the resulting OI distro
would use, either format would come from same sources.

//Jim Klimov


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Andrzej Szeszo]

The process you have described sounds a lot like OI's original plan. It
didn't work out. There was too much baggage. No one was willing to spend
time learning it. It was just too ... ugly.

Individual gates provide some semi-automated ways of building things. I
don't know anyone who managed to automate them all though. No one was able
to provide equivalent of "make world" to build complete OI to date.

There is no doubt Martin Bochnig has a lot of expertise in putting
operating systems together. I got impression that he was heavily invested
in SVR4 based systems though. OI may not be an interesting project for him
as it will probably remain IPS based for the time being.

Andrzej


On 9 May 2013 11:53, Jim Klimov  wrote:

> On 2013-05-09 10:01, Andrzej Szeszo wrote:
>
>> Hi All
>>
>> (Instead of replying to a message in one of the other threads
>> I thought I will create a new one.)
>>
>> Just wanted to say that I don't see a future for the project in its
>> current form. There is simply too many packages and too much baggage for
>> a handful of people to look after.
>>
>> I think the project needs a new vision and a reboot. If you have any
>> ideas for the project and can write scripts/makefiles to generate a
>> distro/live CDs/etc. - speak up! You don't have to be a leader if you
>> don't want to :)
>>
>
>
> You're probably right. I would like to help, though have limited time
> lately, and without docs similar to "Building illumos" won't really
> know where to start beside the illumos-gate. I guess many potential
> and active contributors are in the same boat.
>
> I think it would be proper to maintain a page (hosted on OI wiki)
> with copies of notes, caveats and other informational snippets about
> building the OI distro components. We have many talented people who
> can turn that knowledge into more polished narrative text, scripts
> and makefiles, paragraph at a time - but too few people who know
> what should actually be done (the content to polish). After all, you
> know how many man-months were invested into untangling this know-how
> from sources, comments, ARCs and whatnot. Please share the result :)
>
> I might guess that Martin Bochnig, who made the SPARC port last year
> single-handedly (and SVR4 backport at the same time), might also be
> quite in the know of the intricacies for the build. Possibly, he is
> now the only single person that knows it all. His contribution of the
> distro building know-how would be just as invaluable as the resulting
> distribution itself ;)
>
> Recently, it was noted that there is no equivalent for a "make world"
> in OI. I do believe that after years of development, each consolidation
> in the distro has some equivalent command to build it, as well as a
> specified build environment (such as CBE, or just particular GCC/SS12u1,
> perl, Python and other tool-chain tool versions). The consolidations
> would likely be built each with its own "make sub-world", thus a global
> "make world" for OI would run a dozen make's for the sub-worlds...
> Right? :)
>
> The build environments could be made in zones, and provisioning of
> those can be easily scripted (I think I might help in that direction).
> The build could be executed by i.e. logging in from GZ into the zones
> (or somehow harnessing the dmake's distributed properties natively,
> or by automating with CI/Hudson and its ssh-login capabilities onto
> many hosts with pieces of the code puzzle), culminating with a call to
> the distro constructor. This is all a job for a master makefile to be
> called in the GZ, and waiting a few days for it to complete.
>
> Quite possibly, the "master-builder" automations (scripts to provision
> standardized build zones, compilation environments on top of them, and
> local package servers for resulting packages accumulated from those
> zones, etc.) - these scripts and makefiles would deserve a repository
> of their own, even if just a small one for starters. This way people
> would be able to install OI (or real iron or in a VM), fetch a script
> to provision build zones, download/update source codes, clone the
> per-bug workspace, etc. all in the same standardized and well-tested
> manner, and easily start helping the project move on in whatever way
> they can.
>
> //Jim Klimov
>
>
> __**_
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/**mailman/listinfo/oi-dev
>
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Andrzej Szeszo]

Hi Sašo

Thanks for your support!

Andrzej


On 9 May 2013 10:36, Sašo Kiselkov  wrote:

> On 05/09/2013 10:01 AM, Andrzej Szeszo wrote:
> > Hi All
> >
> > (Instead of replying to a message in one of the other threads I thought I
> > will create a new one.)
> >
> > Just wanted to say that I don't see a future for the project in its
> current
> > form. There is simply too many packages and too much baggage for a
> handful
> > of people to look after.
> >
> > I think the project needs a new vision and a reboot. If you have any
> ideas
> > for the project and can write scripts/makefiles to generate a distro/live
> > CDs/etc. - speak up! You don't have to be a leader if you don't want to
> :)
>
> I volunteer to maintain packages around the GNUstep project
> (http://gnustep.org/), mainly the GNUstep frameworks and associated
> libraries.
>
> Cheers,
> --
> Saso
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Jim Klimov]

On 2013-05-09 10:01, Andrzej Szeszo wrote:

Hi All

(Instead of replying to a message in one of the other threads
I thought I will create a new one.)

Just wanted to say that I don't see a future for the project in its
current form. There is simply too many packages and too much baggage for
a handful of people to look after.

I think the project needs a new vision and a reboot. If you have any
ideas for the project and can write scripts/makefiles to generate a
distro/live CDs/etc. - speak up! You don't have to be a leader if you
don't want to :)



You're probably right. I would like to help, though have limited time
lately, and without docs similar to "Building illumos" won't really
know where to start beside the illumos-gate. I guess many potential
and active contributors are in the same boat.

I think it would be proper to maintain a page (hosted on OI wiki)
with copies of notes, caveats and other informational snippets about
building the OI distro components. We have many talented people who
can turn that knowledge into more polished narrative text, scripts
and makefiles, paragraph at a time - but too few people who know
what should actually be done (the content to polish). After all, you
know how many man-months were invested into untangling this know-how
from sources, comments, ARCs and whatnot. Please share the result :)

I might guess that Martin Bochnig, who made the SPARC port last year
single-handedly (and SVR4 backport at the same time), might also be
quite in the know of the intricacies for the build. Possibly, he is
now the only single person that knows it all. His contribution of the
distro building know-how would be just as invaluable as the resulting
distribution itself ;)

Recently, it was noted that there is no equivalent for a "make world"
in OI. I do believe that after years of development, each consolidation
in the distro has some equivalent command to build it, as well as a
specified build environment (such as CBE, or just particular GCC/SS12u1,
perl, Python and other tool-chain tool versions). The consolidations
would likely be built each with its own "make sub-world", thus a global
"make world" for OI would run a dozen make's for the sub-worlds...
Right? :)

The build environments could be made in zones, and provisioning of
those can be easily scripted (I think I might help in that direction).
The build could be executed by i.e. logging in from GZ into the zones
(or somehow harnessing the dmake's distributed properties natively,
or by automating with CI/Hudson and its ssh-login capabilities onto
many hosts with pieces of the code puzzle), culminating with a call to
the distro constructor. This is all a job for a master makefile to be
called in the GZ, and waiting a few days for it to complete.

Quite possibly, the "master-builder" automations (scripts to provision
standardized build zones, compilation environments on top of them, and
local package servers for resulting packages accumulated from those
zones, etc.) - these scripts and makefiles would deserve a repository
of their own, even if just a small one for starters. This way people
would be able to install OI (or real iron or in a VM), fetch a script
to provision build zones, download/update source codes, clone the
per-bug workspace, etc. all in the same standardized and well-tested
manner, and easily start helping the project move on in whatever way
they can.

//Jim Klimov

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[David Höppner]

I think Igor Pashev has done some valueable work with
https://github.com/Nexenta/cibs
https://github.com/ip1981/last-hope

When I was core member of the Homebrew project we just used
github pull requests.  Contributing should be simple and easy.
If I found problems with a patch, I just fixed it in place.

-- David

On 9 May 2013 10:01, Andrzej Szeszo  wrote:
> Hi All
>
> (Instead of replying to a message in one of the other threads I thought I
> will create a new one.)
>
> Just wanted to say that I don't see a future for the project in its current
> form. There is simply too many packages and too much baggage for a handful
> of people to look after.
>
> I think the project needs a new vision and a reboot. If you have any ideas
> for the project and can write scripts/makefiles to generate a distro/live
> CDs/etc. - speak up! You don't have to be a leader if you don't want to :)
>
> Regards,
>
> Andrzej
>
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI project reboot required

[Sašo Kiselkov]

On 05/09/2013 10:01 AM, Andrzej Szeszo wrote:
> Hi All
> 
> (Instead of replying to a message in one of the other threads I thought I
> will create a new one.)
> 
> Just wanted to say that I don't see a future for the project in its current
> form. There is simply too many packages and too much baggage for a handful
> of people to look after.
> 
> I think the project needs a new vision and a reboot. If you have any ideas
> for the project and can write scripts/makefiles to generate a distro/live
> CDs/etc. - speak up! You don't have to be a leader if you don't want to :)

I volunteer to maintain packages around the GNUstep project
(http://gnustep.org/), mainly the GNUstep frameworks and associated
libraries.

Cheers,
-- 
Saso

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] OI project reboot required

[Andrzej Szeszo]

Hi All

(Instead of replying to a message in one of the other threads I thought I
will create a new one.)

Just wanted to say that I don't see a future for the project in its current
form. There is simply too many packages and too much baggage for a handful
of people to look after.

I think the project needs a new vision and a reboot. If you have any ideas
for the project and can write scripts/makefiles to generate a distro/live
CDs/etc. - speak up! You don't have to be a leader if you don't want to :)

Regards,

Andrzej
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev