<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html><head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

    <meta name="generator" content="Osso Notes">

    <title></title></head>

<body>

Blame is as useful as ignorance and accusation.

<br>

Perhaps this is the right development model for this project.

<br>

I genuinely hope that OI and Illumos succeed.

<br>

With regards to sparc, as much as I like the modular Solaris kernel, Dtrace etc, it makes more sense on this occassion to investigate Gentoo as it is a free project with active sparc developers.

<br>

I do have a number of spare disks and sparc hardware, so can help out if things improve on the sparc front.

<br>

Thank you for your time.

<br>

<br>Regards,

<br>

Peter.

<br>

<br>----- Original message -----

<br>> Hello.

<br>>

<br>> I'd like to say that upstream illumos-gate is stable and is the least

<br>> our problem.

<br>> We've seen only 3 breakages in a year:

<br>> 1) DTrace change which required additional patching for some software

<br>> (IIRC mysql, mariadb, percona and perl DTrace providers were affected)

<br>> 2) One change in ipv6 handling which broke VNC server (was fixed almost

<br>> immediately after discovering)

<br>> 3) Several changes which broke packaging (were fixed soon enough, in day

<br>> or two after discovering)

<br>> And one change which could break grub on OI was fixed during review

<br>> phase.

<br>>

<br>> There were also some changes removing software (like ntfsprogs) which

> required us to add it to oi-userland.

<br>> Additionally we had to add one (!) simple patch to illumos-gate to allow

<br>> building with Perl versions > 5.10.

<br>>

<br>> So, I don't say that interaction with illumos-gate dev team is a

<br>> problem.

<br>> All the times illumos devs were extremely friendly and I think that

> attempts to blame them are just FUD and provocations.

<br>>

> As for real problems...

> If you mention SPARC - yes, it is slowly becoming second class citizen.

<br>> But as far as I know, all SPARC-related patches coming from Igor

> Kozhukhov or Gary Mils were accepted.

<br>> The reason for this state is that SPARC is some kind of sacred cow for

<br>> illumos.

<br>> Noone wants to drop SPARC support (I think most reasons for this are

<br>> religious), but only several men

> really do something to keep it alive.

<br>> I'm personally one of those who don't care about SPARC, so I wouldn't

> say that it's the main OI problem.

<br>>

<br>> The main problem is the lack of developers. The other are coming from

<br>> this one.

<br>> I'd say that a lot of outdated software or software which can't be

> easily rebuilt is a problem.

<br>> I think that software coming from JDS and XNV consolidations which is

> still out of oi-userland is a problem.

<br>> I think that binary blobs (e.g. /usr/bin/make or motif) which can't be

> easily rebuilt is a problem.

<br>> I'd say that lack of software usual for FreeBSD or Linux user (e.g.,

<br>> postfix, smartmontools, hhvm on server side,

<br>> fresh python, perl, ruby versions for developers or audio and video

<br>> codecs, virtualbox, wine for desktop users)

> is a problem.

<br>> ---

<br>> System Administrator of Southern Federal University Computer Center

<br>>

<br>> Peter писал 13.09.2014 11:23:

<br>> > ----- Original message -----

<br>> > > On 12 September 2014 17:28, Peter <<a href="mailto:jini@zeus.net.au">jini@zeus.net.au</a>> wrote:

<br>> > > > That's rich, a project with no stable release baseline to measure

<br>> > > > binary compatibility against won't accept patches unless ...

<br>> > >

<br>> > > Actually, our stated goal of "FCS quality all the time" means that we

> > > intend to treat _every commit_ in the gate as a stable release.

<br>> > > Things are only integrated when they work, and once they're

<br>> > > integrated, documented, and people are able to use them, we intend to

<br>> > > keep supporting them compatibly.

<br>> > >

<br>> >

<br>> > Building and testing only on the developers computer before

<br>> > integration isn't sufficient to be considered stable and those who

<br>> > would contribute, don't have the resources to test widely enough to

> > satisfy the stable contribution only model.

<br>> >

<br>> > Current policy also denies would be community developers the benefits

<br>> > of an experimental branch; peer review and wider testing.   There may

<br>> > be exceptional developers who's code is perfect, but I am not one of

<br>> > them.

<br>> >

<br>> > For the rest of us, a second set of eyes helps to develop well

<br>> > considered api's and better quality code, and this includes a skunk

<br>> > build and wider testing.

<br>> >

<br>> > If this is the Illumos development model, the community needs to find

> > a way of working with it.

<br>> >

<br>> > It sounds like Joyent has an internal experimental branch and it

<br>> > sounds like that's what OI needs in order to enable community based

> > developers to participate similarly to Joyent developers.

<br>> >

<br>> > I think it's also important to have stable snapshots for users to

<br>> > report bugs against.

<br>> >

> > I would be prepared to contribute via OI, if this is possible.

<br>> >

<br>> > The ARM port sounds interesting, ARM64 is a different architecture and

<br>> > doesn't share the 32 bit isa.

<br>> >

> > So SPARC is presently unmaintained.

<br>> >

<br>> > While I couldn't commit to maintaining it, as it is a significant

<br>> > undertaking, I could run tests and help debugging and contributing

<br>> > some improvements.

<br>> >

<br>> > Regards,

<br>> >

<br>> > Peter.

<br>> >

<br>> >

<br>> >

<br>> > > Accidents happen; negligence cannot.    We may not be perfect, but we

<br>> > > _strive_ to be, and to fix bugs (or revert integrated changes) as

> > > quickly as is possible so that the software remains unbroken.

<br>> > >

<br>> > > > The logical solution is to maintain a stable kernel release

<br>> > > > version at OI, then use that as a baseline for patches and submit

<br>> > > > patches upstream to Illumos from OI rather than from individual

<br>> > > > developers.

<br>> > >

<br>> > > Working on your own distribution-specific fork of illumos-gate is a

<br>> > > reasonable idea -- it's the model we use for SmartOS at Joyent.    If

<br>> > > your intent is to avoid work creeping up on you, I would recommend

<br>> > > that you merge changes into your fork early, and often.    At Joyent,

<br>> > > we

<br>> > > merge into the SmartOS fork, illumos-joyent, on most business days. 

<br>> > >     I

<br>> > > can't recall a time when we experienced serious difficulty from

<br>> > > changes we received through these syncs.    We also try to minimise

<br>> > > our diff from upstream periodically by submitting chunks of our work

<br>> > > for integration into illumos-gate.

<br>> > >

<br>> > > > That will put your patches on an equal footing as those with

<br>> > > > commercial interests.

<br>> > >

<br>> > > No, the _only_ thing that will put your patches on equal footing with

<br>> > > the commercial interests is to do the software engineering required

<br>> > > to produce quality, tested changes.    There are not different sets of

<br>> > > rules for different contributors -- the same attention to quality,

<br>> > > testing, sensible architecture, etc, is expected from all

<br>> > > contributors.

<br>> > >

<br>> > > > I'd ignore the FUD about legacy platforms, projects that support

<br>> > > > multiple architectures are more stable for it.

<br>> > >

<br>> > > I whole-heartedly agree that operating systems that run on more than

<br>> > > one architecture are less likely to see particular classes of bugs

<br>> > > that are hidden by some architecture-specific implementation detail;

<br>> > > e.g. byte ordering, different core system hardware drivers, etc.

<br>> > > Unfortunately, if there are no _active_ OS engineers using and

<br>> > > working on a particular architecture, it will absolutely rot over

<br>> > > time; eventually becoming an obstruction to important changes where

<br>> > > those changes require architecture-specific work.

<br>> > >

<br>> > > > With regard to sparc, there are a number of current chip

<br>> > > > manufacturers, Aeroflex, Fujitsu, Oracle, FeiTeng. How hard would

<br>> > > > it be to support sparc v8? What about ARM64?

<br>> > >

<br>> > > Robert Mustacchi, myself, and a few others, have been investigating

<br>> > > (and in Robert's case, working on) an ARM port of the OS.    It's a

<br>> > > lot of work -- work which is entirely uninteresting to our employer,

<br>> > > so it's a spare time project.      I would love to see it completed,

> > > and hopefully we will get there in time.

<br>> > >

<br>> > > > It's clear that Illumos isn't the right place for me to contribute

<br>> > > > directly, but the whole community will benefit if I and others

<br>> > > > like me can contribute via OI.

<br>> > >

<br>> > > Why is that?    If you want to procure and operate SPARC hardware, to

<br>> > > fix build issues as they arise, and to write SPARC-specific code for

<br>> > > changes that require it, why not do it in illumos?    If you (and

<br>> > > others

<br>> > > like you) do not step up to maintain the SPARC bits, then they truly

> > > are dead weight and need to be removed.

<br>> > >

<br>> > > --

<br>> > > Joshua M. Clulow

<br>> > > UNIX Admin/Developer

<br>> > > <a href="http://blog.sysmgr.org">http://blog.sysmgr.org</a>

<br>> >

<br>> >

<br>> > _______________________________________________

<br>> > oi-dev mailing list

<br>> > <a href="mailto:oi-dev@openindiana.org">oi-dev@openindiana.org</a>

<br>> > <a href="http://openindiana.org/mailman/listinfo/oi-dev">http://openindiana.org/mailman/listinfo/oi-dev</a>

<br>>

<br>> _______________________________________________

<br>> oi-dev mailing list

<br>> <a href="mailto:oi-dev@openindiana.org">oi-dev@openindiana.org</a>

<br>> <a href="http://openindiana.org/mailman/listinfo/oi-dev">http://openindiana.org/mailman/listinfo/oi-dev</a>

<br><br></p>

</body>

</html>