Re: [oi-dev] Resignation
On 10/ 9/14 01:15 AM, Bayard Bell wrote: On 8 October 2014 23:36, Nikola M. minik...@gmail.com mailto:minik...@gmail.com wrote: It was probably lack of organization that killed many efforts before. From my experience trying to walk a mile in his shoes, I fully endorse Alasdair's observation that a clearly established historical problem for OI was having meetings to talk about organisation and process with people in the hope that they might contribute. When it comes to established practice, there is nothing novel about the proposition that one earns a say in the workings of an open-source community with sweat equity. One encourages people to contribute rather than bargains. If you think this claim is simply polemical, you might as well argue with the wind. Idea of reviving /dev sureley needs work. No one questions that. If you think to start polemical talk, that is no issue here. It is about exact ways of releasing /dev and that it can not be just 'releasing snapshot' without TESTING. Because next thing you know is people complain new /dev have too many bugs in it. And it is because making /dev is not possible without testing updating from current /dev to Hipster snapshot, If that is the way to go. I used and tested Hipster for a very long time and all that time i did reporting of bugs and problems with update, apps, mounting datasets in /opt, GNOME bugs, update bugs, etc. And it all went through IRC and not on mailing list, because of number of people involved actually that was fastest way to do it. So in a nutshell, things get tested and reported and I was testing everything i can for a very long time. And there are positions too that people take to contribute in distribution, that are not measured by Github logs. (And why Github but OI's own repositories etc.). ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
A related issue however is the apparent lack of ownership over the wiki. In terms of ownership, EveryCity is providing free hosting of various bits of OpenIndiana physical infrastructure, but it's down to the OpenIndiana project to determine who has ownership. There is a gulf here that nobody has stepped up to fill after my resignation. Keith Wesolowski quipped a joke about OI, referring to it as the Bernie Lomax distribution, which I think is quite apt: https://en.wikipedia.org/wiki/Weekend_at_Bernie's I don't think the project is going to succeed unless the various interested parties come together and figure out who is responsible for what. People are going to have to step up and take responsibility, otherwise it's just a lot of complaining and hot air about how nothing is happening. Regarding the wiki directly, various people, myself included, have admin accounts and can create more. If you're volunteering, I'm happy to set you up with one. If you want access to the zone confluence is running in, I can provide that also. Not that I'm involved any more and I largely just lurk, but I think the disconnect between /dev and /hipster needs to end. It's confusing. I have proposed for years now that: /hipster = rolling release /dev = snapshots of /hipster /release = /periodic snapshots of /dev that are considered more stable For example you could do automatic /dev releases every 2 weeks. /release can come out once a year, and in the month running up to a /release, you can focus on fixes rather than new features. Easy, simple. It does mean /dev and Jon Tibble's effort making way for Andrzej/ALP/etc's hipster effort. The first /release could be based on /dev as is now, but after that, my personal opinion is that Jon Tibble should help with the hipster effort. Perhaps in particular with ensuring quality /release releases and managing that bug fixing process. Also some of the peanut gallery posts on this mailing list make me want to throw up. I don't think anyone should be allowed to attend an OI meeting unless they have contributed at least X months worth of commits to the OI github account. Talk is cheap, and people should have to earn the right to have an opinion on how the project is run. Back when I was project lead, I made the mistake of soliciting input from all interested parties, which resulted in enormous weekly meetings with lots of talk and no action. It killed the project, as it became mired in indecision and a total lack of focus. What is needed is a single minded lazer sharp focus. The project is on life support. Commit or GTFO. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
On 10/ 8/14 08:19 PM, Alasdair Lumsden wrote: Not that I'm involved any more and I largely just lurk, but I think the disconnect between /dev and /hipster needs to end. It's confusing. I have proposed for years now that: /hipster = rolling release /dev = snapshots of /hipster /release = /periodic snapshots of /dev that are considered more stable For example you could do automatic /dev releases every 2 weeks. /release can come out once a year, and in the month running up to a /release, you can focus on fixes rather than new features. Don't think anything automatic is viable for /dev. Those suppose to be releases, that are tested before putting them out, that most people would use actually. (And use to report bugs that are visible after longer time.) Let automatic things be left for Hipster (numbered) releases, because, even if rolling release, Hipster also needs testing and bug fixing and referencing revisions. Prior releasing /dev , automatic update manager needs to be revived , to be able to push on actually with updates. /dev would serve no purpose if it would loose ability to signal user that next /dev update is available. It's not like in Hipster, where people actually update things themselves, there is no putting things under carpet, like - update manager not working and hot being able to update from /dev to Hipster. I witnessed certain level of not caring for making at least one Hipster snapshot cleanly updatable from /dev but that's because only One or Two guys do all the work. should help with the hipster effort. Perhaps in particular with ensuring quality /release releases and managing that bug fixing process. If there is anything left regarding quality in Hipster. Hipster is bombshell rolling release and pushing too much quality in it, can slow down things from going on. Hipster truly needs to become more in line with /dev but not sacrificing it's ability to change. In between /dev releases, Hipster lives and that is where quality control can come to life, before /dev is released. Automatic /dev from random Hipster snapshots does not sound like quality at all. It would be great to make things work like you said,actually, then many other people would come to light and be usable if the process is made - where more people could be involved. Also some of the peanut gallery posts on this mailing list make me want to throw up. I don't think anyone should be allowed to attend an OI meeting unless they have contributed at least X months worth of commits to the OI github account. Talk is cheap, and people should have to earn the right to have an opinion on how the project is run. Back when I was project lead, I made the mistake of soliciting input from all interested parties, which resulted in enormous weekly meetings with lots of talk and no action. It killed the project, as it became mired in indecision and a total lack of focus. What is needed is a single minded lazer sharp focus. Single minded never helped distributions. (See OpenSXCE) On the other hand, making process, like you partially described where more people could be involved, making /dev more of a quality thing, could work. It was probably lack of organization that killed many efforts before. 151a7 was best OI release ever, everything worked, things worked nice etc. I think that forming teams to do what they do was a very good idea. Problem that Apl pointed out is that there is too little people for that groups concept and that it should be seen who actually today care at all and who actually want do do anything and what number of people available it is. So not only regarding number of contributions on GitHub until now. - that would just further limit number of people to be involved. Everyone can do something. It is true that, if one wants to do something, he/she should can do it and present work already done and move to a next self-appointed task. Surely IF it is wanted by end users and by ecosystem that actually use distribution, of course. That is what I missed in OI from day one. Not organizing people in a processes that works. At the day OI was announced, on Live event when Alasdair presented OI as a project, someone misinterpreted my question on IRC of: How development organisation woudl be for OI and translated it to: Will it be more like Linux. So that person that asked wrong question did not do any good to OI with that. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
On 8 October 2014 23:36, Nikola M. minik...@gmail.com wrote: On 10/ 8/14 08:19 PM, Alasdair Lumsden wrote: Talk is cheap, and people should have to earn the right to have an opinion on how the project is run. Back when I was project lead, I made the mistake of soliciting input from all interested parties, which resulted in enormous weekly meetings with lots of talk and no action. It killed the project, as it became mired in indecision and a total lack of focus. What is needed is a single minded lazer sharp focus. [snip] It was probably lack of organization that killed many efforts before. From my experience trying to walk a mile in his shoes, I fully endorse Alasdair's observation that a clearly established historical problem for OI was having meetings to talk about organisation and process with people in the hope that they might contribute. When it comes to established practice, there is nothing novel about the proposition that one earns a say in the workings of an open-source community with sweat equity. One encourages people to contribute rather than bargains. If you think this claim is simply polemical, you might as well argue with the wind. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
On 09/13/14 09:58 AM, Joshua M. Clulow wrote: On 13 September 2014 00:23, Peter j...@zeus.net.au wrote: Current policy also denies would be community developers the benefits of an experimental branch; peer review and wider testing. There may be exceptional developers who's code is perfect, but I am not one of them. ... If we were to have a public experimental branch, with less (or no) restrictions on what could be committed to it, it would clearly break from time to time. Folks would (rightfully) be reluctant to use it for anything important, because it might break; it will thus not receive the wider testing and review you are espousing. This is called the Quality Death Spiral -- removing the hard requirement for quality ensures that quality will deteriorate faster and faster over time. And illumos not having actual releases, does not help distributions, but exactly push them in state you described. And at least push maintaining stable releases to many separate distributions, but maintaining it at one place, illumos. I think that maintaining continuously stable illumos is more folks tale then it could be real. - How can illumos achieve any kind of BINARY compatibility (that Solaris was known for) between RELEASES, when it does not have releases?... and does not have centralized support for maintaining them? And on OI distribution level I also remember the time when I was using Opensolaris /dev releases daily and actually I witnessed many bugs that went into releases, but were quickly fixed in next /dev after few weeks, _precisely_ because people had NUMBERED versions to reference to and because of wider testing of the whole system. Opensolaris /dev was very much useful, actually the same way OI /dev is in the same way. So there is nothing like quality of death spiral with wider use for testing on distribution level and enforcing illumos kind of development philosophy on distribution level could actually lead to quality death spiral. I understand that continuous integration on distribution level is disastrous for wider audience, like you concluded, but having distribution RELEASES is beneficiary and is a must. For the rest of us, a second set of eyes helps to develop well considered api's and better quality code, and this includes a skunk build and wider testing. Language like this is not helpful -- there are _not_ two classes of contributor. Every single contributor, regardless of affiliation, is empowered (and expected) to write changes, seek review, test their software (or arrange others to test it), and submit requests for integration. Simply because distributions not backed by large companies does not have resources to maintain separate stable illumos (but could contribute of course). That is what makes differentiation between big illumos contributors and small ones visible, without Versioned releases that are centrally maintained - it suits big players, new or small ones are even discouraged to maintain their own forked illumoses. OI Hipster followed recommendations for reference distribution but that gave us nothing production ready at all. If code review (a second set of eyes) helps you, that's great -- it helps me too! And, I definitely _build_ the software before I put it back. I also definitely seek wider testing if I feel that I am unable to test some reasonable combinations of hardware and software by myself. I now remembered to ask one question: Is KVM and per-zone disk throttling (and other things maybe) finally integrated in mainline illumos? (Or at least pushed to illumos). And if it is not, why not? Why keeping important things like that out of illumos, maybe because it would require putting release numbers in illumos, for big changes? I think it's also important to have stable snapshots for users to report bugs against. It may be important to have stable snapshots of _distributions_, which are what users actually install and thus report bugs against. If you report a bug against SmartOS, we at Joyent must first determine if it's a bug in software we have modified or added to the system, or code from upstream. It is essentially mandatory that users can tell us the datestamp from the platform image they are running in order for us to help them. The same generally applies to OmniOS and OpenIndiana, with whatever versioning schemes they are using for their shipped binary components. Ok, that supports reviving OI /dev and having numbered versions in Hipster updates. But not having stable releases of illumos is binary compatibility is bummer for distributions. So SPARC is presently unmaintained. While I couldn't commit to maintaining it, as it is a significant undertaking, I could run tests and help debugging and contributing some improvements. Yes, it _is_ a significant undertaking. That nobody has enough time or resources to step up and commit to being responsible for the whole thing, with or without help from folks like yourself, is
Re: [oi-dev] Resignation
On 09/13/14 10:00 AM, Alexander Pyhalov wrote: I'm personally one of those who don't care about SPARC, so I wouldn't say that it's the main OI problem. Main problem is that things people say being hostile to whole hardware platforms, turn people away from OI and illlumos. (like it is shown in Peter's response to another attack on SPARC) Personally I don't care for distributions that tend to lower their hardware support for unknown religious reasons. And if one call SPARC support religious and tend to dismantle and destroy any effort of supporting SPARC - is actually religious on the even bigger level. Things that someone personally don't care, should not be an obstacle for things that people DO care about. It could be only excuse to do things in Sparc incompatible ways, for personal comfort. The main problem is the lack of developers. The other are coming from this one. And it is not solved by turning them away. Or killing SPARC dev's access to mailing list... Like both illumos and OI did recently. I would like to raise a voice on such antisocial things. I'd say that a lot of outdated software or software which can't be easily rebuilt is a problem. I think that software coming from JDS and XNV consolidations which is still out of oi-userland is a problem. I think that binary blobs (e.g. /usr/bin/make or motif) which can't be easily rebuilt is a problem. I'd say that lack of software usual for FreeBSD or Linux user (e.g., postfix, smartmontools, hhvm on server side, fresh python, perl, ruby versions for developers or audio and video codecs, virtualbox, wine for desktop users) is a problem. If one keeps binary compatibility as a goal and have regular and stable releases as a goal most of those will not be a problem, e.g. would go away if software not being able to rebuild is known to be supported in exact release. (and branded zone). Not having teams (, other) and having all thing centralized is a problem. Doing everything without consulting wider audience , users and acting without thinking over it is a problem. Lack of software is also sold with having STABLE releases or at least regular releases in /dev, people could actually port software to. Targeting video codecs, audio, tools, large packages like virtualbox (binary Virtualbox from the project site for Solaris, works very well on OI BTW, unless Hipster killed compatibility in recent days.) Not having /dev releases and not having numbered versions and insisting on killing consolidations and incorporation and tendency of killing SPARC is a problem. But not creating Teams is I think biggest problem of all. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
On 10/ 6/14 09:54 AM, Alexander Pyhalov wrote: Hello. On 10/06/2014 11:33, Nikola M. wrote: But not creating Teams is I think biggest problem of all. Whom do you suppose these teams will consist of? Honestly, now we have two informal teams - RE - Adrzej Szeszo and Ken Mays and dev team (which now consists from Jon Tibble (which supports /dev) and me supporting Hipster). Plus several developers who are interested in several packages and support mostly only these packages (as Aurelian Larcher and Marcel Telka) This is the current state. We don't have problem how to organize people. We just have no people to organize. Well great, first information people need to activate themselves is what structure already exist. You provided information on current structure and that is great. We (meaning me shooting ideas all the time and you for starters) should talk about what to do. I propose reviving OI weekly meetings that are always scheduled on Thursdays, 7PM UTC at Freenode IRC channel #oi-meeting (irc.freenode.net). As topics I propose: -Creating Hipster mailing list for pre-dev discussions and changes on packages, before releasing /dev. -Making Hipster snapshots in-line with /dev releases, both from upgrade to Hipster form a8 as first phase - Releasing a10 /dev and update to it from a9 as second phase. - Not abandoning SPARC support contribution - Mailing list inclusions of exlcluded people - Plans for including more people in a structure and contribution docs Everything else that I currently don't have time to write about. nikolam ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
On 10/06/2014 13:24, Nikola M. wrote: I propose reviving OI weekly meetings that are always scheduled on Thursdays, 7PM UTC at Freenode IRC channel #oi-meeting (irc.freenode.net). As topics I propose: -Creating Hipster mailing list for pre-dev discussions and changes on packages, before releasing /dev. -Making Hipster snapshots in-line with /dev releases, both from upgrade to Hipster form a8 as first phase - Releasing a10 /dev and update to it from a9 as second phase. - Not abandoning SPARC support contribution - Mailing list inclusions of exlcluded people - Plans for including more people in a structure and contribution docs Everything else that I currently don't have time to write about. nikolam I think that gathering and discussing current issues could help. If only someone wants to solve them :) Seriously, I'd like to add several topics to this list and have a bit of conversation with all involved parties. The topics I'm interested in - Approximate snapshot schedule. How do we determine that we are ready to make new one? - What work can be imported from Hipster to Dev (e.g., it could be possible to move the whole sfw consolidation to oi-build which could make sharing code easier)? - Collaboration with other illumos distributions - DilOS and OmniOS. - Improving sites and documentation on the wiki. Currently it is a mess. - Does someone really plan to do something besides talking? ;) -- Best regards, Alexander Pyhalov, system administrator of Southern Federal University IT department ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
Aurélien Larcher писал 06.10.2014 15:47: I guess once the JDS consolidation is fully buildable in hipster things will become more streamlined ? I think it's the one which has the tightest connections with userland (sfw) consolidation (besides illumos-gate). We have a lot of dependencies in JDS on userland software. So, without porting JDS to oi-userland further work on userland is problematic. Luckily, XNV has less connections to userland, but we eventually have to move this one to oi-userland too. In any case there is enough work for at least a dozen devs. Even when we put everything to one build system, we'll have to update a lot of software. And if with server software it's rather straightforward, desktop one has much more issues. Even Gnome 2.32 is too old. And we even don't have 2.32. One more issues is software which is tricky to build or which has no sources at all (for example, make, cpp, motif). AFAIK, SmartOS uses Sun CC-built make. And porting it to GNU C++ is not trivial. There are also some sources for cpp, but I've heard that they need additional patches to behave like OpenSolaris cpp. And to replace motif with binary compatible open sourced version for me seems a very tricky task. --- System Administrator of Southern Federal University Computer Center ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
On 07/10/14 00:02, Alexander Pyhalov wrote: - Improving sites and documentation on the wiki. Currently it is a mess. Hi Alexander, I've done a fair amount of documentation work for other projects including Ekiga, Open Wonderland, and presently assist Mozilla with maintaining social media for Thunderbird. If you can identify perhaps a few key areas where things are lacking in this area I'm happy to have a look and see. A related issue however is the apparent lack of ownership over the wiki. My requests to look into certain lingering spam moderation issues, and the security holes in the current Confluence version (brought up a long time ago on discuss) have gone unanswered. I'd quite like to see some firm points of contact for whoever is maintaining the wiki (and website) back end before committing any time to it. Cheers, Dave -- Dave Koelmeyer http://blog.davekoelmeyer.co.nz ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
- Original message - On 12 September 2014 17:28, Peter j...@zeus.net.au wrote: That's rich, a project with no stable release baseline to measure binary compatibility against won't accept patches unless ... 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. Things are only integrated when they work, and once they're integrated, documented, and people are able to use them, we intend to keep supporting them compatibly. Building and testing only on the developers computer before integration isn't sufficient to be considered stable and those who would contribute, don't have the resources to test widely enough to satisfy the stable contribution only model. Current policy also denies would be community developers the benefits of an experimental branch; peer review and wider testing. There may be exceptional developers who's code is perfect, but I am not one of them. For the rest of us, a second set of eyes helps to develop well considered api's and better quality code, and this includes a skunk build and wider testing. If this is the Illumos development model, the community needs to find a way of working with it. It sounds like Joyent has an internal experimental branch and it sounds like that's what OI needs in order to enable community based developers to participate similarly to Joyent developers. I think it's also important to have stable snapshots for users to report bugs against. I would be prepared to contribute via OI, if this is possible. The ARM port sounds interesting, ARM64 is a different architecture and doesn't share the 32 bit isa. So SPARC is presently unmaintained. While I couldn't commit to maintaining it, as it is a significant undertaking, I could run tests and help debugging and contributing some improvements. Regards, Peter. Accidents happen; negligence cannot. We may not be perfect, but we _strive_ to be, and to fix bugs (or revert integrated changes) as quickly as is possible so that the software remains unbroken. The logical solution is to maintain a stable kernel release version at OI, then use that as a baseline for patches and submit patches upstream to Illumos from OI rather than from individual developers. Working on your own distribution-specific fork of illumos-gate is a reasonable idea -- it's the model we use for SmartOS at Joyent. If your intent is to avoid work creeping up on you, I would recommend that you merge changes into your fork early, and often. At Joyent, we merge into the SmartOS fork, illumos-joyent, on most business days. I can't recall a time when we experienced serious difficulty from changes we received through these syncs. We also try to minimise our diff from upstream periodically by submitting chunks of our work for integration into illumos-gate. That will put your patches on an equal footing as those with commercial interests. No, the _only_ thing that will put your patches on equal footing with the commercial interests is to do the software engineering required to produce quality, tested changes. There are not different sets of rules for different contributors -- the same attention to quality, testing, sensible architecture, etc, is expected from all contributors. I'd ignore the FUD about legacy platforms, projects that support multiple architectures are more stable for it. I whole-heartedly agree that operating systems that run on more than one architecture are less likely to see particular classes of bugs that are hidden by some architecture-specific implementation detail; e.g. byte ordering, different core system hardware drivers, etc. Unfortunately, if there are no _active_ OS engineers using and working on a particular architecture, it will absolutely rot over time; eventually becoming an obstruction to important changes where those changes require architecture-specific work. With regard to sparc, there are a number of current chip manufacturers, Aeroflex, Fujitsu, Oracle, FeiTeng. How hard would it be to support sparc v8? What about ARM64? Robert Mustacchi, myself, and a few others, have been investigating (and in Robert's case, working on) an ARM port of the OS. It's a lot of work -- work which is entirely uninteresting to our employer, so it's a spare time project. I would love to see it completed, and hopefully we will get there in time. It's clear that Illumos isn't the right place for me to contribute directly, but the whole community will benefit if I and others like me can contribute via OI. Why is that? If you want to procure and operate SPARC hardware, to fix build issues as they arise, and to write SPARC-specific code for changes that require it, why not do it in illumos? If you (and others like you) do not step up to maintain the SPARC bits, then they truly are dead weight and need to be removed. -- Joshua M. Clulow
Re: [oi-dev] Resignation
On 13 September 2014 00:23, Peter j...@zeus.net.au wrote: Building and testing only on the developers computer before integration isn't sufficient to be considered stable and those who would contribute, don't have the resources to test widely enough to satisfy the stable contribution only model. It is actually sufficient for many changes. For example: if you are modifying the grep utility, and you have written some tests to show that your change works as you expect, and you have run any existing tests to show that it still works as others expect, then it should very likely be fine. Coupled with review from at least one qualified person via direct mail, or on the developers@ list or IRC, you can be relatively sure that the vast majority of changes going into the gate actually work basically everywhere. Current policy also denies would be community developers the benefits of an experimental branch; peer review and wider testing. There may be exceptional developers who's code is perfect, but I am not one of them. It absolutely does not. If you want to have a private branch someplace, you are welcome to. You can post it on github, or bitbucket, or your own server, or just keep it on your local machine. If you want design or code review, or broader testing, you're welcome to publish changes (sources, diffs, webrevs, even binaries) in whatever form is convenient for your reviewers and testers. There's intentionally very little process right up until the point where you want your change to go into illumos-gate -- at that point, you must simply satisfy an advocate that you have achieved appropriate review and testing. The advocates are (busy) human beings -- they respect a fully complete request to integrate when they see one, but they're capable of (and generally willing to) explain what a contributor needs to do to be accepted. The illumos-gate consolidation contains the kernel and the most fundamental libraries and programs that make up the operating system. If we were to have a public experimental branch, with less (or no) restrictions on what could be committed to it, it would clearly break from time to time. Folks would (rightfully) be reluctant to use it for anything important, because it might break; it will thus not receive the wider testing and review you are espousing. This is called the Quality Death Spiral -- removing the hard requirement for quality ensures that quality will deteriorate faster and faster over time. For the rest of us, a second set of eyes helps to develop well considered api's and better quality code, and this includes a skunk build and wider testing. Language like this is not helpful -- there are _not_ two classes of contributor. Every single contributor, regardless of affiliation, is empowered (and expected) to write changes, seek review, test their software (or arrange others to test it), and submit requests for integration. If code review (a second set of eyes) helps you, that's great -- it helps me too! And, I definitely _build_ the software before I put it back. I also definitely seek wider testing if I feel that I am unable to test some reasonable combinations of hardware and software by myself. If this is the Illumos development model, the community needs to find a way of working with it. The way is: [1] talk to people and then [2] do work. We believe in rough consensus and running code. It sounds like Joyent has an internal experimental branch and it sounds like that's what OI needs in order to enable community based developers to participate similarly to Joyent developers. We don't have any secret internal branches that I am aware of. We generally all work on the master branch of illumos-joyent; hosted on github. We cut periodic releases of our broader product set (which include a bootable illumos platform image) once a fortnight. Critically, we can also create ad hoc master releases _at any time_ if we need a bug fix or new feature, so master must _always_ be production ready. We can merge illumos-gate into our fork every day because it _also_ has the property of being production ready at all times. I think it's also important to have stable snapshots for users to report bugs against. It may be important to have stable snapshots of _distributions_, which are what users actually install and thus report bugs against. If you report a bug against SmartOS, we at Joyent must first determine if it's a bug in software we have modified or added to the system, or code from upstream. It is essentially mandatory that users can tell us the datestamp from the platform image they are running in order for us to help them. The same generally applies to OmniOS and OpenIndiana, with whatever versioning schemes they are using for their shipped binary components. So SPARC is presently unmaintained. While I couldn't commit to maintaining it, as it is a significant undertaking, I could run tests and help debugging and contributing some
Re: [oi-dev] Resignation
Hello. I'd like to say that upstream illumos-gate is stable and is the least our problem. We've seen only 3 breakages in a year: 1) DTrace change which required additional patching for some software (IIRC mysql, mariadb, percona and perl DTrace providers were affected) 2) One change in ipv6 handling which broke VNC server (was fixed almost immediately after discovering) 3) Several changes which broke packaging (were fixed soon enough, in day or two after discovering) And one change which could break grub on OI was fixed during review phase. There were also some changes removing software (like ntfsprogs) which required us to add it to oi-userland. Additionally we had to add one (!) simple patch to illumos-gate to allow building with Perl versions 5.10. So, I don't say that interaction with illumos-gate dev team is a problem. All the times illumos devs were extremely friendly and I think that attempts to blame them are just FUD and provocations. As for real problems... If you mention SPARC - yes, it is slowly becoming second class citizen. But as far as I know, all SPARC-related patches coming from Igor Kozhukhov or Gary Mils were accepted. The reason for this state is that SPARC is some kind of sacred cow for illumos. Noone wants to drop SPARC support (I think most reasons for this are religious), but only several men really do something to keep it alive. I'm personally one of those who don't care about SPARC, so I wouldn't say that it's the main OI problem. The main problem is the lack of developers. The other are coming from this one. I'd say that a lot of outdated software or software which can't be easily rebuilt is a problem. I think that software coming from JDS and XNV consolidations which is still out of oi-userland is a problem. I think that binary blobs (e.g. /usr/bin/make or motif) which can't be easily rebuilt is a problem. I'd say that lack of software usual for FreeBSD or Linux user (e.g., postfix, smartmontools, hhvm on server side, fresh python, perl, ruby versions for developers or audio and video codecs, virtualbox, wine for desktop users) is a problem. --- System Administrator of Southern Federal University Computer Center Peter писал 13.09.2014 11:23: - Original message - On 12 September 2014 17:28, Peter j...@zeus.net.au wrote: That's rich, a project with no stable release baseline to measure binary compatibility against won't accept patches unless ... 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. Things are only integrated when they work, and once they're integrated, documented, and people are able to use them, we intend to keep supporting them compatibly. Building and testing only on the developers computer before integration isn't sufficient to be considered stable and those who would contribute, don't have the resources to test widely enough to satisfy the stable contribution only model. Current policy also denies would be community developers the benefits of an experimental branch; peer review and wider testing. There may be exceptional developers who's code is perfect, but I am not one of them. For the rest of us, a second set of eyes helps to develop well considered api's and better quality code, and this includes a skunk build and wider testing. If this is the Illumos development model, the community needs to find a way of working with it. It sounds like Joyent has an internal experimental branch and it sounds like that's what OI needs in order to enable community based developers to participate similarly to Joyent developers. I think it's also important to have stable snapshots for users to report bugs against. I would be prepared to contribute via OI, if this is possible. The ARM port sounds interesting, ARM64 is a different architecture and doesn't share the 32 bit isa. So SPARC is presently unmaintained. While I couldn't commit to maintaining it, as it is a significant undertaking, I could run tests and help debugging and contributing some improvements. Regards, Peter. Accidents happen; negligence cannot. We may not be perfect, but we _strive_ to be, and to fix bugs (or revert integrated changes) as quickly as is possible so that the software remains unbroken. The logical solution is to maintain a stable kernel release version at OI, then use that as a baseline for patches and submit patches upstream to Illumos from OI rather than from individual developers. Working on your own distribution-specific fork of illumos-gate is a reasonable idea -- it's the model we use for SmartOS at Joyent. If your intent is to avoid work creeping up on you, I would recommend that you merge changes into your fork early, and often. At Joyent, we merge into the SmartOS fork, illumos-joyent, on most business days. I can't recall a time when we experienced serious difficulty from changes we received through these syncs. We also try
Re: [oi-dev] Resignation
Blame is as useful as ignorance and accusation. Perhaps this is the right development model for this project. I genuinely hope that OI and Illumos succeed. 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. I do have a number of spare disks and sparc hardware, so can help out if things improve on the sparc front. Thank you for your time. Regards, Peter. - Original message - Hello. I'd like to say that upstream illumos-gate is stable and is the least our problem. We've seen only 3 breakages in a year: 1) DTrace change which required additional patching for some software (IIRC mysql, mariadb, percona and perl DTrace providers were affected) 2) One change in ipv6 handling which broke VNC server (was fixed almost immediately after discovering) 3) Several changes which broke packaging (were fixed soon enough, in day or two after discovering) And one change which could break grub on OI was fixed during review phase. There were also some changes removing software (like ntfsprogs) which required us to add it to oi-userland. Additionally we had to add one (!) simple patch to illumos-gate to allow building with Perl versions 5.10. So, I don't say that interaction with illumos-gate dev team is a problem. All the times illumos devs were extremely friendly and I think that attempts to blame them are just FUD and provocations. As for real problems... If you mention SPARC - yes, it is slowly becoming second class citizen. But as far as I know, all SPARC-related patches coming from Igor Kozhukhov or Gary Mils were accepted. The reason for this state is that SPARC is some kind of sacred cow for illumos. Noone wants to drop SPARC support (I think most reasons for this are religious), but only several men really do something to keep it alive. I'm personally one of those who don't care about SPARC, so I wouldn't say that it's the main OI problem. The main problem is the lack of developers. The other are coming from this one. I'd say that a lot of outdated software or software which can't be easily rebuilt is a problem. I think that software coming from JDS and XNV consolidations which is still out of oi-userland is a problem. I think that binary blobs (e.g. /usr/bin/make or motif) which can't be easily rebuilt is a problem. I'd say that lack of software usual for FreeBSD or Linux user (e.g., postfix, smartmontools, hhvm on server side, fresh python, perl, ruby versions for developers or audio and video codecs, virtualbox, wine for desktop users) is a problem. --- System Administrator of Southern Federal University Computer Center Peter писал 13.09.2014 11:23: - Original message - On 12 September 2014 17:28, Peter j...@zeus.net.au wrote: That's rich, a project with no stable release baseline to measure binary compatibility against won't accept patches unless ... 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. Things are only integrated when they work, and once they're integrated, documented, and people are able to use them, we intend to keep supporting them compatibly. Building and testing only on the developers computer before integration isn't sufficient to be considered stable and those who would contribute, don't have the resources to test widely enough to satisfy the stable contribution only model. Current policy also denies would be community developers the benefits of an experimental branch; peer review and wider testing. There may be exceptional developers who's code is perfect, but I am not one of them. For the rest of us, a second set of eyes helps to develop well considered api's and better quality code, and this includes a skunk build and wider testing. If this is the Illumos development model, the community needs to find a way of working with it. It sounds like Joyent has an internal experimental branch and it sounds like that's what OI needs in order to enable community based developers to participate similarly to Joyent developers. I think it's also important to have stable snapshots for users to report bugs against. I would be prepared to contribute via OI, if this is possible. The ARM port sounds interesting, ARM64 is a different architecture and doesn't share the 32 bit isa. So SPARC is presently unmaintained. While I couldn't commit to maintaining it, as it is a significant undertaking, I could run tests and help debugging and contributing some improvements. Regards, Peter. Accidents happen; negligence cannot. We may not be perfect, but we _strive_ to be, and to fix bugs (or revert integrated changes) as quickly as is possible so that the software remains unbroken.
Re: [oi-dev] Resignation
On 09/12/14 10:53 AM, Nick Zivkovic wrote: Developers are user too, you know. :) Nobody questioned that :) Thing is, they are not the only one using the things they make or change. If they are the only one, every developer would have it's own distro... Also there is difference between coders and developers as I see it. You don't need to expect from coder to be a developer and vice versa. E.G. developers are usually users, too. Coders are not. Simple example are tons of ex-Sun employees that just lost interest in Opensolaris after their payment for contribution has been cut off. Your argument seems to imply that the developers 1) don't use their own creations and 2) have no good or original ideas of their own, and are eagerly awaiting the input of sales and users to guide their decisions. Developers aren't children in need of adult guidance. Difference between coder and developer as i understand it is that coder have no interest whatsoever beyond he's contract about platform he uses on the project. Developer have interest in platform and he will tend to do what is better for it. In a sense, developer invest he's work and sweat, coder is payed to code. There is no successful distribution without big traffic of opinions and requests from users to developers. And it goes both ways. Why would a developer make something --- in his spare time, for no compensation --- that he himself would never use? Don't know - maybe you have an answer for that question, since you invented it and asked it :) Maybe someone else need what he made and asked from him to make it work and he likes the idea. Illumos is a volunteer effort, and developers have a clear idea of what they want the system to do. The majority of Illumos developers are heavily invested in the technology, and aren't in it just for the paycheck (if they're even getting a paycheck for Illumos work). Many of them use and depend on Illumos every day. Naturally feedback from users is welcome, but you don't need full-blown governance for that, just these mailing lists and the bug trackers. illumos is a project payed by several companies that employed fully payed employees to develop it. It is of course possible to send changes upstream and that is true, but illumos would not exist without those paying companies, so it obviously it reflects their interests and of their use cases, and steer platform where they like. If people outside those companies want to make changes, it is obvious that it is NOT enough just to send some code upstream and hope it gets integrated. People need to form clusters of users, Admins, Hosting and companies using distributions , to , again, employ their people , pay them or inspire existing employees or Members to contribute to make their job easier. More people join such clusters, it is better , not to let just a few companies move illumos to ,say x86-only , killing SPARC or something else. Given the choices between democracy, bureaucracy, autocracy, and adhocracy, I'd say that empirically adhocracy (Illumos) and autocracy (Linux, Node.js, SmartOS) have worked out best in open source projects. Democracy results in community schisms (Gentoo, the BSDs, all of which got forked permanently and never merged back --- even Debian got forked into Ubuntu, IIRC), and bureaucracy is too rule and process-oriented (we're making software, not mass producing pharmaceutical products). While there are some interesting sociological questions here to be answered, it nevertheless holds that we know what has and hasn't worked well so far, and we should do what has worked well. I would say I can not answer easy to such wood of social arrangements and their meanings, all I can say is that regarding OS Distribution organization, people that are in contact with end customers, mostly have idea what they need. Nothing can replace real-life problems and inventions are not made out of nothing, that just does not happen easy. Having said all of that I encourage everyone who is interested in Illumos or in software in general to learn to code. This 1) makes one a better human being, 2) gives one more credibility, 3) give one the ability to solve one's most pressing problems, when the other developers are unavailable due to a crisis in the data center (or in life generally) --- or due their lack of interest in one's specific problem. That is great idea! Only problem is, that it is close to mind, that beginners need to have stable platforms to work on and start developing something they like. It is also said that best way to learn to code or develop is to include yourself in existing projects or software distributions. For that goal I also consider mentoring is a great way of inclusion of new people ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
This is about as useful a conversation as talking about comparative constitutional law as a problem to be solved by exporting good constitutions to somewhere suffering from political problems. Constitutions and licenses are foundational documents that express a way of proceeding in pursuit of shared values and objectives. A great license or constitution can't be transplanted or otherwise adopted if it doesn't in fact meet a development community where it is and move it where it wants to go. It's why there will never be one license to rule them all: because there will always be interesting opportunities in playing the game by different rules that better suit a productive grouping that generally gets along. It's why there will always be forks and schisms, even if you can agree on licenses. You aren't talking at all about OI's challenges, such as technology debt or strategic direction for issues that OI cares about (such as desktop technology) analytically. (For example: technology debt in build systems is very much a reason why developers are a reasonable first-order community consideration at the moment--you can't get to reasonable development cadence when you've got a lot of movement in upstreams and a great deal of time spent fighting the build system.) I don't see reasoning offered for why governance is even the question being posed for the OI community, let alone why you need to follow the Debian model, as well as it works for Debian. Cheers, Bayard On 13 September 2014 01:28, Peter j...@zeus.net.au wrote: That's rich, a project with no stable release baseline to measure binary compatibility against won't accept patches unless ... The logical solution is to maintain a stable kernel release version at OI, then use that as a baseline for patches and submit patches upstream to Illumos from OI rather than from individual developers. That will put your patches on an equal footing as those with commercial interests. I'd ignore the FUD about legacy platforms, projects that support multiple architectures are more stable for it. Debian's constitution is minimal and a similar structure will lend strength to all your interests. Why not base your project on one of the most successful free community projects? Regards, Peter. - Original message - On 12 September 2014 10:24, Nikola M. minik...@gmail.com wrote: illumos is a project payed by several companies that employed fully payed employees to develop it. We have a mixture of commercial interests and unpaid, or at least unaffiliated, contributors. The obvious examples to cite are Rich Lowe in general, or Saso Kiselkov when he was adding LZ4 support to ZFS. If people outside those companies want to make changes, it is obvious that it is NOT enough just to send some code upstream and hope it gets integrated. It is actually the case that, whether or not you work for one of those companies, it is _not_ enough to just send some code. If you are an engineer, regardless of your employer or your motivations, we expect you to provide evidence of several things: - that you have done a full build of the software, and that you have not induced compiler warnings or code style issues - that you have received code review from at least one person who has worked in similar parts of the code base already - that you have tested the software you added or changed, and any software the behaviour of which you may be altering - that you are not breaking public interfaces we expose to users, so that they can expect at least binary compatibility If you work for one of those companies, or not, you are expected to provide the above. If you provide the above, and the advocates are satisfied that you are maintaining the quality of code in the gate, then your changes will be put back. It's as simple as that. What is _not_ simple is that from time to time, people propose and submit changes for review that will break other users of the software. Or, people propose and submit changes that have received insufficient review and testing. Just because it's open source, community-developed software does not mean that we should be lax on quality, or reckless with respect to backwards compatibility. For better or for worse, that's why we accept changes the way we do today. People need to form clusters of users, Admins, Hosting and companies using distributions , to , again, employ their people , pay them or inspire existing employees or Members to contribute to make their job easier. More people join such clusters, it is better , not to let just a few companies move illumos to ,say x86-only , killing SPARC or something else. If (or, frankly, when) we kill SPARC support, it will be because _years_ have passed without any real
Re: [oi-dev] Resignation
Stability issues only appear to exist with one upstream project. Maintain a stable branch for OI and diff and review upstream changes, that'll stabilise OI's build. Report any breakages to the upstream maintainers and don't merge changes that cause breakage. Where does this community want to go? Forget about desktop, server etc, I might have a server that needs DRI to support GPGPU, while you might have a desktop that needs DRI to support 3D graphics. Get back to basics: * Relaibility * Stability * Compatibility * Hardware support Obviously standards and well documented hardware, or well supported by free software is easier to support. I've noticed with sparc there's a lot legacy closed hardware and drivers etc. It's clear the Xorg, IPS and such are the future, but this shouldn't prevent others from bundling OI with legacy binary drivers and other stuff and OI shouldn't deliberately break compatibility unless absolutely necessary. Debian used to have a non-fee section (don't know if this is still the case) but that could work here too. With regard to sparc, there are a number of current chip manufacturers, Aeroflex, Fujitsu, Oracle, FeiTeng. How hard would it be to support sparc v8? What about ARM64? Going forward longer term, if people want 3D graphics on sparc, they'll need to work out how to utilise PC hardware. I've been looking into 8086 real mode emulation and whether it can be compiled into fcode, allowing PC cards to be flashed to support OpenFirmware. Then we can use the free Xorg drivers for sparc also. I'm also investigating whether the crypto acceleration drivers can be rewritten to support T1, T2 and T3, based on hypervisor documentation, header files and some dtrace analysis. I just picked up a 2U T2 sparc with 128 threads, 64GB Ram, 10GigE and room for 16 SAS 2 hard drives, cheap, others will do the same. It's clear that Illumos isn't the right place for me to contribute directly, but the whole community will benefit if I and others like me can contribute via OI. Regards, Peter. - Original message - This is about as useful a conversation as talking about comparative constitutional law as a problem to be solved by exporting good constitutions to somewhere suffering from political problems. Constitutions and licenses are foundational documents that express a way of proceeding in pursuit of shared values and objectives. A great license or constitution can't be transplanted or otherwise adopted if it doesn't in fact meet a development community where it is and move it where it wants to go. It's why there will never be one license to rule them all: because there will always be interesting opportunities in playing the game by different rules that better suit a productive grouping that generally gets along. It's why there will always be forks and schisms, even if you can agree on licenses. You aren't talking at all about OI's challenges, such as technology debt or strategic direction for issues that OI cares about (such as desktop technology) analytically. (For example: technology debt in build systems is very much a reason why developers are a reasonable first-order community consideration at the moment--you can't get to reasonable development cadence when you've got a lot of movement in upstreams and a great deal of time spent fighting the build system.) I don't see reasoning offered for why governance is even the question being posed for the OI community, let alone why you need to follow the Debian model, as well as it works for Debian. Cheers, Bayard On 13 September 2014 01:28, Peter j...@zeus.net.au wrote: That's rich, a project with no stable release baseline to measure binary compatibility against won't accept patches unless ... The logical solution is to maintain a stable kernel release version at OI, then use that as a baseline for patches and submit patches upstream to Illumos from OI rather than from individual developers. That will put your patches on an equal footing as those with commercial interests. I'd ignore the FUD about legacy platforms, projects that support multiple architectures are more stable for it. Debian's constitution is minimal and a similar structure will lend strength to all your interests. Why not base your project on one of the most successful free community projects? Regards, Peter. - Original message - On 12 September 2014 10:24, Nikola M. minik...@gmail.com wrote: illumos is a project payed by several companies that employed fully payed employees to develop it. We have a mixture of commercial interests and unpaid, or at least unaffiliated, contributors. The obvious examples to cite are Rich Lowe in general, or Saso Kiselkov when he was adding LZ4 support to ZFS. If people outside those companies want to make changes, it is obvious that it is NOT enough just to send some code
Re: [oi-dev] Resignation
On 12 September 2014 17:28, Peter j...@zeus.net.au wrote: That's rich, a project with no stable release baseline to measure binary compatibility against won't accept patches unless ... 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. Things are only integrated when they work, and once they're integrated, documented, and people are able to use them, we intend to keep supporting them compatibly. Accidents happen; negligence cannot. We may not be perfect, but we _strive_ to be, and to fix bugs (or revert integrated changes) as quickly as is possible so that the software remains unbroken. The logical solution is to maintain a stable kernel release version at OI, then use that as a baseline for patches and submit patches upstream to Illumos from OI rather than from individual developers. Working on your own distribution-specific fork of illumos-gate is a reasonable idea -- it's the model we use for SmartOS at Joyent. If your intent is to avoid work creeping up on you, I would recommend that you merge changes into your fork early, and often. At Joyent, we merge into the SmartOS fork, illumos-joyent, on most business days. I can't recall a time when we experienced serious difficulty from changes we received through these syncs. We also try to minimise our diff from upstream periodically by submitting chunks of our work for integration into illumos-gate. That will put your patches on an equal footing as those with commercial interests. No, the _only_ thing that will put your patches on equal footing with the commercial interests is to do the software engineering required to produce quality, tested changes. There are not different sets of rules for different contributors -- the same attention to quality, testing, sensible architecture, etc, is expected from all contributors. I'd ignore the FUD about legacy platforms, projects that support multiple architectures are more stable for it. I whole-heartedly agree that operating systems that run on more than one architecture are less likely to see particular classes of bugs that are hidden by some architecture-specific implementation detail; e.g. byte ordering, different core system hardware drivers, etc. Unfortunately, if there are no _active_ OS engineers using and working on a particular architecture, it will absolutely rot over time; eventually becoming an obstruction to important changes where those changes require architecture-specific work. With regard to sparc, there are a number of current chip manufacturers, Aeroflex, Fujitsu, Oracle, FeiTeng. How hard would it be to support sparc v8? What about ARM64? Robert Mustacchi, myself, and a few others, have been investigating (and in Robert's case, working on) an ARM port of the OS. It's a lot of work -- work which is entirely uninteresting to our employer, so it's a spare time project. I would love to see it completed, and hopefully we will get there in time. It's clear that Illumos isn't the right place for me to contribute directly, but the whole community will benefit if I and others like me can contribute via OI. Why is that? If you want to procure and operate SPARC hardware, to fix build issues as they arise, and to write SPARC-specific code for changes that require it, why not do it in illumos? If you (and others like you) do not step up to maintain the SPARC bits, then they truly are dead weight and need to be removed. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
On 09/ 7/14 06:23 PM, Nick Zivkovic wrote: The issue of governance has been talked about before, so I'll just summarize the decisions the Illumos community reached. Governance causes way more problems than it solves. And yet, without governance, you end up having no product. And supported product is what users need. And yet, illumos does not have Any stable release yet, to form stable distros around it. (binary compatibility, anyone?) happened because the founder of Gentoo, left the project and left a governing-board in his place. The Illumos community believes --- and please correct me if I'm wrong --- that those who write the code have the power to decide, to disagree, and so on. Those who are merely consumers of the code don't get much say in development decisions. Hence, there is no need for governance. Code rules. This is really bit shortsighted and not accurate. Users rules. Real consumers of the code are users and sysadmins and if you don't listen what people need, 'coders' could end up coding what no one will actually want to use. (Or coding something stupid that is not designed well) It i true that coders have in reality more power to technologically decide means of achieving goals, bu to let only to coders to decide strategies and setting goals , without involving Sales, user feedback and some strategic planning, would lead to situation like you described. So 'power to the people' could also be described as: If you have maintainers of an distro and some process around it, people involved would have better chance to contribute more, by all means. As opposed to opposing organized effort. Things don't solve for themselves, but with organizing, exactly to avoid personal shortcuts in code for small goals, without bigger picture i mind. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
I think any project that originates from an established code base, instead of growing organically, is going to experience some pain during a transition from one development model to another. If Apache's governance model isn't suitable, have any others been considered, or tried? Regards, Peter. - Original message - On 09/ 7/14 12:24 AM, Peter Firmstone wrote: 1. Document your governance model, I'm a member of an Apache project, we have clear rules that assist in resolving differences Unfortunately, OpenSolaris adopted the Apache governance model and it was a poor fit (Apaches rules for governing a large body of loosely related projects didn't map well to a community trying to generate a single unified OS) and too heavy-weight at the time it was introduced. A big problem was driving things the wrong way around - we built out all this governance structure and then hoped people would show up to use it, and they saw more overhead than benefit and were turned off by it. That's left the OpenSolaris offshoots wary of governance and refusing to admit that some level is necessary for ensuring decisions get made, and thus left them floundering and directionless. -- -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] Resignation
Hi, It appears your developer has reached the point where he must quit to get his point accross. Illumos doesn't have any stable releases and it sounds like developers are having issues with that. Also it sounds like experimental features are being introduced into the Illumos kernel and these components also sound like they belong in a distribution rather than the kernel. If Illumos isn't prepared to listen, maintain a stable kernel version here on OpenIndiana, give it a version, track the changes and make it available to other distributions, treat Illumos like experimental code, contribute fixes back to Illumos. Again: Create kernel stable releases, leave out the experimental stuff (if it's not part of the kernel and can be provided as an optional package, leave it out). Eventually Illumos will come around, if not, only integrate what makes sense and ignore what doesn't and continue to contribute fixes upstream. It's not worth loosing developers over external project issues. Also some other ideas, based on observations: 1. Document your governance model, I'm a member of an Apache project, we have clear rules that assist in resolving differences 1. We have PMC committers and members, we have lazy concensus and voting, if there's disagreement, we vote after debating (yes people are passionate), PMC votes are binding, members votes are non binding (see the apache rules). 2. Also, doers decide. 2. If there are a lot of users, but not many developers, allow users to make donations against issues, then developers can earn these donations by completing work. 3. Actively encourage users to donate (Debian has a donation system, adopt something similar), eg every time someone downloads an ISO, provide the option to donate. Regards, Peter. On 08/11/14 08:22 PM, Milan Jurik wrote: / Hi, // // based on the current situation with OI - lack of old OI non-hipster // branch - and because of bad situation (according my view) of Illumos - // like stupid ideas to include large chunks of 3rd party code to ON gate // which makes it unmaintainable (why did Sun and Oracle invest so much to // remove OpenSSL, SunSSH and ksh from ON gate? See how bad is ksh in // Illumos and how old is Illumos SSH) I have to finalize my decision about // my participation. Illumos and its distros are not for me anymore. /I think idea behind that is to have current SSH for illumos, and later to remove it from illumos. But It is yet to be determined are there SPARC hardware crypto support inside new solution (that is present in SunSSH), because that would be very short-sighted if it is not. GDA even tried to remove UltraSPARC T1/T2 support (?). illumos is tailored by few large companies wishes , that actually pay developers, but it is always possible to contribute. / opensolaris.cz will be up for some time but no more updates to JDS and // SFE. Do not hestitate to contact me in private if you think I still know // something but I will not spend more time on the lists. // If anybody is interested in some older bits then: // // http://www.opensolaris.cz/builds/illumos-wpa-enterprise/webrev/ // http://www.opensolaris.cz/builds/tnf/webrev/ // http://www.opensolaris.cz/builds/ext2-merge/webrev/ /That sounds a bit interesting, since Hipster is much more BSD-style development by few commiters and yet I understand you left for BSD. Hipster broke code consolidations some time ago and without actual numbered versions that are pushed, it is hard to test and debug many new bugs. (And without resurrected 'updatemanager' to update regularly) There is large disproportion between number of people wanting just to install and use OI and illumos distributions and those that want to maintain and work on it. Current situation in OI is tailored for small number of hands active and it is extracting maximum results from current situation, but that would be changing (together with dev process) as more people are involved again. Maybe good way to start further is Install OI from 151a3 (to get Zpool 28 by default for S11 compatibility) and upgrade to 151a8 or install from 151a8 directly. And then upgrade from it to Hipster (/hipster-2014.1) and to see what could be done to upgrading individual packages of interest for. Again, breaking consolidations like JDS is not good but it requires people in TEAMS working together on same project, so more people involved. We will all love to se newer releases in /dev but that needs making releases out of Hipster that goes in line with continuing from latest /dev. Maybe general problem is illumos itself not having numbered releases to have some basis for maintaining patches for some stable version, and that reflect distributions in a bad way. -- Nikola M. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
On Sun, 7 Sep 2014, Peter Firmstone wrote: Hi, It appears your developer has reached the point where he must quit to get his point accross. As best I can tell (based only on mailing list postings), Milan's main concerns were the marginal support for multimedia in the OpenIndiana desktop, and packages dissappearing from Illumos (e.g. OpenSSL) or being significantly altered (e.g. 'man') which then necessitate creating/rebuilding more base OpenIndiana packages, which ripple through the package dependency chain. The lack of a working Adobe Flash player in Firefox on OpenIndiana is surely a major part of the multimedia issue. Illumos doesn't have any stable releases and it sounds like developers are having issues with that. The lack of stable Illumos releases really does not seem like a big deal. In fact, most of the stresses on the OpenIndiana project seem like they are caused by other factors. 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] Resignation
The issue of governance has been talked about before, so I'll just summarize the decisions the Illumos community reached. Governance causes way more problems than it solves. For example, it adds a political aspect to the community, creating clear winners and losers. This leads to rivalry, factions, and the like. This can cause schisms in the community. I used to be a Gentoo user years ago, and I watched the community tear itself apart over petty politics. For example, technological decisions were on the basis of personal egos, feuds, and certain devs' personalismo. As opposed to technical merits and objective measurements. All of this happened because the founder of Gentoo, left the project and left a governing-board in his place. The Illumos community believes --- and please correct me if I'm wrong --- that those who write the code have the power to decide, to disagree, and so on. Those who are merely consumers of the code don't get much say in development decisions. Hence, there is no need for governance. Code rules. On Sun, Sep 7, 2014 at 2:24 AM, Peter Firmstone j...@zeus.net.au wrote: Hi, It appears your developer has reached the point where he must quit to get his point accross. Illumos doesn't have any stable releases and it sounds like developers are having issues with that. Also it sounds like experimental features are being introduced into the Illumos kernel and these components also sound like they belong in a distribution rather than the kernel. If Illumos isn't prepared to listen, maintain a stable kernel version here on OpenIndiana, give it a version, track the changes and make it available to other distributions, treat Illumos like experimental code, contribute fixes back to Illumos. Again: Create kernel stable releases, leave out the experimental stuff (if it's not part of the kernel and can be provided as an optional package, leave it out). Eventually Illumos will come around, if not, only integrate what makes sense and ignore what doesn't and continue to contribute fixes upstream. It's not worth loosing developers over external project issues. Also some other ideas, based on observations: 1. Document your governance model, I'm a member of an Apache project, we have clear rules that assist in resolving differences 1. We have PMC committers and members, we have lazy concensus and voting, if there's disagreement, we vote after debating (yes people are passionate), PMC votes are binding, members votes are non binding (see the apache rules). 2. Also, doers decide. 2. If there are a lot of users, but not many developers, allow users to make donations against issues, then developers can earn these donations by completing work. 3. Actively encourage users to donate (Debian has a donation system, adopt something similar), eg every time someone downloads an ISO, provide the option to donate. Regards, Peter. On 08/11/14 08:22 PM, Milan Jurik wrote: / Hi, // // based on the current situation with OI - lack of old OI non-hipster // branch - and because of bad situation (according my view) of Illumos - // like stupid ideas to include large chunks of 3rd party code to ON gate // which makes it unmaintainable (why did Sun and Oracle invest so much to // remove OpenSSL, SunSSH and ksh from ON gate? See how bad is ksh in // Illumos and how old is Illumos SSH) I have to finalize my decision about // my participation. Illumos and its distros are not for me anymore. /I think idea behind that is to have current SSH for illumos, and later to remove it from illumos. But It is yet to be determined are there SPARC hardware crypto support inside new solution (that is present in SunSSH), because that would be very short-sighted if it is not. GDA even tried to remove UltraSPARC T1/T2 support (?). illumos is tailored by few large companies wishes , that actually pay developers, but it is always possible to contribute. / opensolaris.cz will be up for some time but no more updates to JDS and // SFE. Do not hestitate to contact me in private if you think I still know // something but I will not spend more time on the lists. // If anybody is interested in some older bits then: // // http://www.opensolaris.cz/builds/illumos-wpa-enterprise/webrev/ // http://www.opensolaris.cz/builds/tnf/webrev/ // http://www.opensolaris.cz/builds/ext2-merge/webrev/ /That sounds a bit interesting, since Hipster is much more BSD-style development by few commiters and yet I understand you left for BSD. Hipster broke code consolidations some time ago and without actual numbered versions that are pushed, it is hard to test and debug many new bugs. (And without resurrected 'updatemanager' to update regularly) There is large disproportion between number of people wanting just to install and use OI and illumos distributions and those that want to maintain and work
Re: [oi-dev] Resignation
On 09/ 7/14 12:24 AM, Peter Firmstone wrote: 1. Document your governance model, I'm a member of an Apache project, we have clear rules that assist in resolving differences Unfortunately, OpenSolaris adopted the Apache governance model and it was a poor fit (Apaches rules for governing a large body of loosely related projects didn't map well to a community trying to generate a single unified OS) and too heavy-weight at the time it was introduced. A big problem was driving things the wrong way around - we built out all this governance structure and then hoped people would show up to use it, and they saw more overhead than benefit and were turned off by it. That's left the OpenSolaris offshoots wary of governance and refusing to admit that some level is necessary for ensuring decisions get made, and thus left them floundering and directionless. -- -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] Resignation
On 08/11/14 08:22 PM, Milan Jurik wrote: Hi, based on the current situation with OI - lack of old OI non-hipster branch - and because of bad situation (according my view) of Illumos - like stupid ideas to include large chunks of 3rd party code to ON gate which makes it unmaintainable (why did Sun and Oracle invest so much to remove OpenSSL, SunSSH and ksh from ON gate? See how bad is ksh in Illumos and how old is Illumos SSH) I have to finalize my decision about my participation. Illumos and its distros are not for me anymore. I think idea behind that is to have current SSH for illumos, and later to remove it from illumos. But It is yet to be determined are there SPARC hardware crypto support inside new solution (that is present in SunSSH), because that would be very short-sighted if it is not. GDA even tried to remove UltraSPARC T1/T2 support (?). illumos is tailored by few large companies wishes , that actually pay developers, but it is always possible to contribute. opensolaris.cz will be up for some time but no more updates to JDS and SFE. Do not hestitate to contact me in private if you think I still know something but I will not spend more time on the lists. If anybody is interested in some older bits then: http://www.opensolaris.cz/builds/illumos-wpa-enterprise/webrev/ http://www.opensolaris.cz/builds/tnf/webrev/ http://www.opensolaris.cz/builds/ext2-merge/webrev/ That sounds a bit interesting, since Hipster is much more BSD-style development by few commiters and yet I understand you left for BSD. Hipster broke code consolidations some time ago and without actual numbered versions that are pushed, it is hard to test and debug many new bugs. (And without resurrected 'updatemanager' to update regularly) There is large disproportion between number of people wanting just to install and use OI and illumos distributions and those that want to maintain and work on it. Current situation in OI is tailored for small number of hands active and it is extracting maximum results from current situation, but that would be changing (together with dev process) as more people are involved again. Maybe good way to start further is Install OI from 151a3 (to get Zpool 28 by default for S11 compatibility) and upgrade to 151a8 or install from 151a8 directly. And then upgrade from it to Hipster (/hipster-2014.1) and to see what could be done to upgrading individual packages of interest for. Again, breaking consolidations like JDS is not good but it requires people in TEAMS working together on same project, so more people involved. We will all love to se newer releases in /dev but that needs making releases out of Hipster that goes in line with continuing from latest /dev. Maybe general problem is illumos itself not having numbered releases to have some basis for maintaining patches for some stable version, and that reflect distributions in a bad way. -- Nikola M. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
Milan was one of the great ones... his contributions will be missed by all. There actually was talks of making an oi_151a9 ISO... but I think there was a need to pull in the updated JDS fixes from Milan ~K On Monday, August 11, 2014 3:16 PM, Andrew M. Hettinger ahettin...@prominic.net wrote: Milan Jurik milan.ju...@xylab.cz wrote on 08/11/2014 01:22:07 PM: Hi, based on the current situation with OI - lack of old OI non-hipster branch - and because of bad situation (according my view) of Illumos - like stupid ideas to include large chunks of 3rd party code to ON gate which makes it unmaintainable (why did Sun and Oracle invest so much to remove OpenSSL, SunSSH and ksh from ON gate? See how bad is ksh in Illumos and how old is Illumos SSH) I have to finalize my decision about my participation. Illumos and its distros are not for me anymore. opensolaris.cz will be up for some time but no more updates to JDS and SFE. Do not hestitate to contact me in private if you think I still know something but I will not spend more time on the lists. If anybody is interested in some older bits then: http://www.opensolaris.cz/builds/illumos-wpa-enterprise/webrev/ http://www.opensolaris.cz/builds/tnf/webrev/ http://www.opensolaris.cz/builds/ext2-merge/webrev/ Time to go Milan I have to admit, parts of this are a bit confusing to me. While there are some things coming into illumos, there is more going out. It's looking vary much like OpenSSL is going to be gone (from what I can tell, it's just a matter of making sure nothing depends on it, which is being worked on now), WU-ftpd is looking like it's going to be removed, SUN DHCPd is looking to be going too. Cardbus was just dropped, which is part of removing legacy PM. I definitely understand the lack of stable OI releases (or any apparent desire to make a stable release from hipster) being frustrating. At any rate, best of luck. You'll be missed. Andrew Hettinger http://Prominic.NET | Skype: AndrewProminic Tel: 866.339.3169 (toll free) -or- 1.217.356.2888 x. 110 (int'l) Fax: 866.372.3356 (toll free) -or- 1.217.356.3356 (int'l) ___ 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] Resignation
Hi, based on the current situation with OI - lack of old OI non-hipster branch - and because of bad situation (according my view) of Illumos - like stupid ideas to include large chunks of 3rd party code to ON gate which makes it unmaintainable (why did Sun and Oracle invest so much to remove OpenSSL, SunSSH and ksh from ON gate? See how bad is ksh in Illumos and how old is Illumos SSH) I have to finalize my decision about my participation. Illumos and its distros are not for me anymore. opensolaris.cz will be up for some time but no more updates to JDS and SFE. Do not hestitate to contact me in private if you think I still know something but I will not spend more time on the lists. If anybody is interested in some older bits then: http://www.opensolaris.cz/builds/illumos-wpa-enterprise/webrev/ http://www.opensolaris.cz/builds/tnf/webrev/ http://www.opensolaris.cz/builds/ext2-merge/webrev/ Time to go Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
On 08/31/2012 11:14 AM, Volker A. Brandt wrote: garrett.dam...@dey-sys.com writes: So then, I have just a single question: What is the compelling reason for doing all this effort? Why not just load up Ubuntu on your desktop (or buy a Mac, or even run *cough* Windows) and run illumos bits in a VM? http://tirania.org/blog/archive/2012/Aug-29.html I'm sorry, but I have to contest this claim. The actual fact of the matter is not that OSX killed Linux (or any other *nix for that matter), but rather that the PC market is not growing by such a large margin anymore, and its not the golden poster child of technological progress that the press liked to make it out to be. It however does not mean that PCs aren't an important market. Amid all of the Apple hysteria its also easy to forget that not everybody is willing to fork over 1500 EUR for a laptop with a picture of a fruit on it. Not to mention that academic institutions, governmental agencies and all sorts of other organizations the world over are heavy Linux/open-source users not only on servers, but also on desktops. It's easy to forget that if you're only taking into account the relatively sheltered life of Solaris and Sun. So in all, I think there is a definitive user base for Illumos on the desktop. There *are* places where we can excel (e.g. in deeply integrating ZFS with the UIs). Lots of work? Sure. But may be worth it, if only for tinkering and playing. Cheers, -- Saso ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
Guys, Please, This is a developer mailing list. If you want to help OpenIndiana please go to the issue tracker :) at https://www.illumos.org/projects/openindiana/issues Thanks, -- Piotr Jasiukajtis ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
Milan Jurik wrote: Hi, [...] This crap I heard for years inside Sun. Rumor say half of laptops used by Sun employees (and paid by Sun) were Macs in last year. And the most of core developers were not using Solaris on their laptops. With very same excuse. Now the question - why should new ideas grow on system in VM and not in platform you are using daily? Why should others use my system if even I am using it only to compile code? Just wanting to mention only the happy few can compile code on OpenIndiana. I could not even find the basic headers (stdio.h, etc.) for OpenIndiana downloadable anonymously (whatever the license). Think of why no open developer has ported LibreOffice, whose original design comes AFAIK from Sun. Regards Jean-Pierre ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
Hi Yuri, Yuri Pankov wrote: On Fri, 31 Aug 2012 16:28:46 +0200, Jean-Pierre André wrote: Milan Jurik wrote: Hi, [...] This crap I heard for years inside Sun. Rumor say half of laptops used by Sun employees (and paid by Sun) were Macs in last year. And the most of core developers were not using Solaris on their laptops. With very same excuse. Now the question - why should new ideas grow on system in VM and not in platform you are using daily? Why should others use my system if even I am using it only to compile code? Just wanting to mention only the happy few can compile code on OpenIndiana. I could not even find the basic headers (stdio.h, etc.) for OpenIndiana downloadable anonymously (whatever the license). Think of why no open developer has ported LibreOffice, whose original design comes AFAIK from Sun. $ pkg search stdio.h INDEX ACTION VALUE PACKAGE basename file opt/gcc/4.4.4/include/c++/4.4.4/tr1/stdio.h [...] Great ! it works ! My fault, I am so stupid... Regards Jean-Pierre ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
2012-08-31 19:43, Bob Friesenhahn пишет: On Thu, 30 Aug 2012, garrett.dam...@dey-sys.com wrote: So then, I have just a single question: What is the compelling reason for doing all this effort? Why not just load up Ubuntu on your desktop (or buy a Mac, or even run *cough* Windows) and run illumos bits in a VM? This position you advocate is a very low-performing one and not very reliable either. It is much better to run the inferior OSs in a VM. The so-called desktop is a way to interact with the OS using a graphical interface. It is not necessary for it to directly support idle social applications like Skype. That's what I said, though you phrased it better - thanks ;) I did fire up VirtualBox (recent 4.2.0rc3) in my new oi_151a5 laptop, and a VM can attach to those USB devices that the system can see - such as the video camera. As long as VMs work with the interactive user applications satisfactorily, OI is a way to paint them on the screen, store the VMs safely and efficiently, and limit resource consumption of some over-zealous end-user apps (i.e. a firefox with 200 tabs should better lag in an intentionally constrained VM, than bring the whole physical system down; reloading it with FF session manager vs. save-stating and resuming the whole VM with it upon host reboot also takes somewhat different times to complete). Now, there is a problem with those devices that OI does not see and can't pass through - such as USB3 ports, or use (such as my troubles with Wifi and SATA, and I'm not certain about sound working right)... THAT should be tackled, so that my desktop hypervisor can offer everything I've bought to those VMs which might be the more correct tools for certain jobs - such as skype or heavy tabbed browsing... It has been my long stance that X11 is a way to open many terminals instead of having just one in text mode. VMs on the desktop quite fit into this paradigm; OI does not have to be the all-around GUI desktop solution - it is a portal (or window) to those OSes which arguably have got that edge better. You still won't have, say, MS Visio or Adobe Photoshop on Linux or Solaris (well, maybe with Wine), so if you need those apps - you go get a Windows VM... IMHO it *is* satisfactory if OI is good enough for devs and admins to live in and use the same OS features as they do on their servers for everyday interactive work, provide some of the more baseline apps (current versions) and those which really benefit from physical hardware, and be a shell to VMs with other more complicated features. //Jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
Am 2012-08-31 18:02, schrieb Jim Klimov: That's what I said, though you phrased it better - thanks ;) Now, there is a problem with those devices that OI does not see and can't pass through - such as USB3 ports, or use (such as my troubles with Wifi and SATA, and I'm not certain about sound working right)... THAT should be tackled, so that my desktop hypervisor can offer everything I've bought to those VMs which might be the more correct tools for certain jobs - such as skype or heavy tabbed browsing... //Jim So now an open questions that lurks forever: who and when can port drivers for USB3 and WiFi and all other stuff from CDDL friendly operating systems? :) Regards Damian Wojsław ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
Hi Bob, Bob Friesenhahn píše v pá 31. 08. 2012 v 10:43 -0500: Current OpenIndiana is satisfactory for most things that I need and it only lacks ready-made packages for Firefox, Thunderbird, OpenOffice, and the available Flash plugin. If detractors do not get in the way, forward progress will resume, and these packages will surely appear. personally I use tarballs published on ftp.mozilla.org for Firefox, they work very well. I am using even beta releases, updating through mar files. For OpenOffice, there is version 3.4.0 available: https://adfinis-sygroup.ch/aoo-solaris-x86 I hope http://adfinis-sygroup.ch/ people will prepare 3.4.1 soon. Best regards, Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote on 08/31/2012 10:43:14 AM: On Thu, 30 Aug 2012, garrett.dam...@dey-sys.com wrote: So then, I have just a single question: What is the compelling reason for doing all this effort? Why not just load up Ubuntu on your desktop (or buy a Mac, or even run *cough* Windows) and run illumos bits in a VM? This position you advocate is a very low-performing one and not very reliable either. It is much better to run the inferior OSs in a VM. The so-called desktop is a way to interact with the OS using a graphical interface. It is not necessary for it to directly support idle social applications like Skype. On hardware I have here, I find OpenIndiana's desktop to be quite performant. I also find Solaris 10's aging desktop to be quite performant. I find the desktop to be less performant on Linux systems like Ubtuntu because the focus there seem to be to consume all available resources with new effects and exotic graphics which do not contribute to getting things done. It has not taken me long to learn that Ubtuntu is so frightfully complicated that its developers do not quite understand how it works, and they have not even resolved the long-standing randomly-occuring bug that the system ignores requests to shut down and reboots fail to properly initialize the audio device. I have also had Apple hardware and OS here but it suffers from issues particular to Apple's social culture (which bears some resemblance to Oracle) and it is difficult to recommend that someone depend on it for long term use. Current OpenIndiana is satisfactory for most things that I need and it only lacks ready-made packages for Firefox, Thunderbird, OpenOffice, and the available Flash plugin. If detractors do not get in the way, forward progress will resume, and these packages will surely appear. These 3 things need to be done, but there are no bug/feature-request for them I could find. I'll add them, If there are no missing dependencies, I'll even go ahead and take the FF one. 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___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
The Apache-OpenOffice SPARC build is at 3.4.1: http://adfinis-sygroup.ch/aoo-solaris-sparc https://adfinis-sygroup.ch/file-exchange-public/tag-AOO341/README.html https://adfinis-sygroup.ch/file-exchange-public/tag-AOO341/Apache_OpenOffice_incubating_3.4.1_Solaris_Sparc_install-arc_en-US.tar.gz ~ Ken Mays From: Milan Jurik milan.ju...@xylab.cz To: OpenIndiana Developer mailing list oi-dev@openindiana.org Sent: Friday, August 31, 2012 1:10 PM Subject: Re: [oi-dev] Resignation as OI Lead Hi Bob, Bob Friesenhahn píše v pá 31. 08. 2012 v 10:43 -0500: Current OpenIndiana is satisfactory for most things that I need and it only lacks ready-made packages for Firefox, Thunderbird, OpenOffice, and the available Flash plugin. If detractors do not get in the way, forward progress will resume, and these packages will surely appear. personally I use tarballs published on ftp.mozilla.org for Firefox, they work very well. I am using even beta releases, updating through mar files. For OpenOffice, there is version 3.4.0 available: https://adfinis-sygroup.ch/aoo-solaris-x86 I hope http://adfinis-sygroup.ch/ people will prepare 3.4.1 soon. Best regards, Milan ___ 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] Resignation as OI Lead
Sorry to read about your resignation mate. As a relative newcomer to the project myself, I am not entirely sure of the amount of work that you have done for OI. Although, reading what other fellow developers have said about you, I'm sure it is a lot and your work and efforts put in seem to be appreciated. Leading small projects is timely enough as I am directly aware, as I have done it myself. I can't imagine how timely it must be for a project of the OI scale. These days, I keeper a lower profile in the small projects I'm involved with and just contribute random stuff as I see fit. I am not entirely sure I feel the same way about your comments of Illumos development going nowhere. But I'm not really here to get into that. But rather just wanted to say thanks and good luck for your future projects you might see yourself getting involved with. I'm sure there'll be more just over the horizon. Just keep your involvements small(er)! ;-) Kind regards Chris Jones ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
Mind if I jump in for a bit? On 08/30/2012 09:20 PM, Jose-Marcio Martins da Cruz wrote: Dear Garett, I think I strongly disagree with you. And that you have the ability is the beauty of open-source at work. garrett.dam...@dey-sys.com wrote: Dear Alasdair, The model of OpenSolaris is broken. The model of OpenIndiana following OpenSolaris is broken. The illumos model is following the successful Linux model. This is exemplified by distributions such as the commercially supported, general purpose OmniOS, Joyent’s SmartOS, Delphix OS, and others. In our context, education/research community, we expect an OS coming from some kind of model, a model like Linux Debian or FreeBSD, with a free OS (no strings attached to it), but with people doing business around it with some kind of service (support, installations, solutions, ...). The kind of model we had with Sun was also fine for us : in the 80's and 90's with had a site license for some number of nodes. After that, till the moment Sun was bought by Oracle, the OS was free, but we paid for support. This was also OK. Openindiana is the Ilummos distribution which best fits what we expect. IMHO, it's an error making Illumos follow the Linux model for the simple reason that the user base size isn't comparable. Still IMHO, because of the difference in user base size and the amount of developpers, it should be better to aggregate resources in order to have, for the moment, a solid distribution instead of all these distributions (OmniOS, Joyent's SmartOS, Delphix OS, ...). Maybe this is what is killing Openindiana. You should think about. Just in case you didn't notice, Linux has been using the kernel/distro model from day one when it had next to zero users. I think your issue is not with the distro model, but with the lack of a general purpose totally open-source distro (kind of like Debian GNU/Linux), at least if we assume, for the purpose of argument, that OpenIndiana is dead (which I don't believe one bit). Before the message of Alasdair, I was just preparing some dozen of servers to get into production in our organization, running some infrastructure applications (DNS, mail servers, directory servers, NFS servers, a lot of web servers, ...), based on Openindiana. I'm using OI in production myself and while this change may force me to re-evaluate switching to a different one, I think life will carry on and a new chief maintainer will, sooner or later, step forward. After your message, I looked for the distributions you mentioned above. None of them fits the model I want. Can you be more specific? From where I'm standing, OmniOS looks pretty much like the old OpenSolaris + commercial support, though I haven't really looked into it deeply, so comments would be appreciated. One of them even doesn't have, in their site, a download link, but have a price page. I think you're talking about NexentaStor - that's not a general purpose OS, but rather a storage appliance. So, we're coming back to some kind of closed model, the same Oracle model all of you are critisizing. AFAIK OmniOS is free to use without commercial support with full source available. Am I wrong? At another one, it seems that some features are disabled if you don't have a support contract (zfs send/receive). That's NexentaStor, the storage appliance. So, again, back to the Oracle closed model. If I shall go back to a closed model, maybe I'll prefer remain at Oracle. I think you're mixing up two different product categories: specialized appliances and general purpose OSes. NexentaStor and SmartOS are very specialized and as such are ill suited to applications outside of their respective fields. OmniOS is probably what you're looking for. Now that I know what you really think about the future of Illumos and their distributions, I may definitely consider another OS : Linux of FreeBSD. Linux has exactly the same model you're criticizing (kernel with separate distros) and FreeBSD is just one big monolithic block (with various downstreams existing, but with no clear separation). I short, I think you're framing the issue incorrectly. The fact that there are various distributions of Illumos isn't a bad thing, that's our strength! There's plenty of innovation that can be done in the way you package, manage and handle a distribution, wholly apart from the core technologies (Illumos). In fact, if anything, I feel like there are far too few flavors of Illumos, we should have many more. OpenSolaris (the distribution) was a direct attack on this model, where Sun tried to keep control of everything, rather than relinquishing it and letting the community take it where they'd like to see it. If you don't like what OpenIndiana/OmniOS/whatever is doing, go ahead and create a new distro. Take the Illumos core, build it, install it and build your own software stack on it. That's what Linux has been doing for over 20 years now and has been wildly successful at
Re: [oi-dev] Resignation as OI Lead
On Aug 30, 2012, at 12:20 PM, Jose-Marcio Martins da Cruz jose.marcio...@gmail.com wrote: Dear Garett, I think I strongly disagree with you. I think you misunderstood me. More below. :-) garrett.dam...@dey-sys.com wrote: Dear Alasdair, The model of OpenSolaris is broken. The model of OpenIndiana following OpenSolaris is broken. The illumos model is following the successful Linux model. This is exemplified by distributions such as the commercially supported, general purpose OmniOS, Joyent’s SmartOS, Delphix OS, and others. In our context, education/research community, we expect an OS coming from some kind of model, a model like Linux Debian or FreeBSD, with a free OS (no strings attached to it), but with people doing business around it with some kind of service (support, installations, solutions, ...). The kind of model we had with Sun was also fine for us : in the 80's and 90's with had a site license for some number of nodes. After that, till the moment Sun was bought by Oracle, the OS was free, but we paid for support. This was also OK. Openindiana is the Ilummos distribution which best fits what we expect. IMHO, it's an error making Illumos follow the Linux model for the simple reason that the user base size isn't comparable. Still IMHO, because of the difference in user base size and the amount of developpers, it should be better to aggregate resources in order to have, for the moment, a solid distribution instead of all these distributions (OmniOS, Joyent's SmartOS, Delphix OS, ...). Maybe this is what is killing Openindiana. You should think about. Actually, when I tried this, the result was illumian, which didn't work out so well. All of the distributions you list above are being developed by *commercial* entities that have their own business needs. We collaborate around a common kernel, and there may be areas where there is some collaboration with other upstreams, but the distributions are different because they have different *purposes*. The presence of these competitors is most definitely *not* what is killing OpenIndiana. (Although, I'm told that some parties have switched from OI to SmartOS. But I think that underscores the real problem with OpenIndiana, which I'll get to shortly.) Before the message of Alasdair, I was just preparing some dozen of servers to get into production in our organization, running some infrastructure applications (DNS, mail servers, directory servers, NFS servers, a lot of web servers, ...), based on Openindiana. After your message, I looked for the distributions you mentioned above. None of them fits the model I want. Well, I'm not sure what the model you want is. Of course some of those are commercial (all of 'em really, but then so are most Linux distros). SmartOS, OmniOS, illumian, and OpenIndiana should all be reasonable technology bases for what you are describing above, and they are all basically open source. I think you should look at the alternatives -- but then again if OpenIndiana works for you, great! One of them even doesn't have, in their site, a download link, but have a price page. So, we're coming back to some kind of closed model, the same Oracle model all of you are criticizing. At another one, it seems that some features are disabled if you don't have a support contract (zfs send/receive). So, again, back to the Oracle closed model. If I shall go back to a closed model, maybe I'll prefer remain at Oracle. Again, you misunderstood what I was talking about. I wasn't talking about open vs. closed at all. So let me clarify: What is *broken* was the model of slavishly trying to follow OpenSolaris, or to be an open free alternative to Solaris 11, servicing servers, desktops, laptops, and both SPARC and x86. That was the model that OI started with -- to simply package up the bits that Oracle was providing, try to match it to an illumos kernel, and package the whole thing up. What's broken about this is two fold. First, from a technical level, trying to retain and use packages from an upstream like Oracle, where there are dependencies upon closed bits, and flags days and interface boundaries where we we only get half of the changes, is untenable in the long run. It's been doomed to failure since inception. Second, and probably more significantly, the *vision* is busted. OI had *no* vision except to follow Oracle's lead. Even Oracle abandoned OpenSolaris and the desktop, but OI tries to muddle on with no clear vision about what sets it apart. There is no innovation in OI, really. Too many people want too many things from it (server, desktop, compatibility, SPARC vs. x86), to the point that it can never really take the necessary steps to excel at any one thing because doing so might make it worse at another. OI became jack-of-all-trades, master of none. (In fact, I'd argue that the desktop focus has been a huge drag
Re: [oi-dev] Resignation as OI Lead
Hello Alasdair! It is with much sadness that I hereby resign as project lead. This is sad news indeed. Thank you for all your work. It has not gone unnoticed, and it stands as an example to others. I personally hope that OI continues in one form or another. Best regards -- Volker -- Volker A. Brandt Consulting and Support for Oracle Solaris Brandt Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim Email: v...@bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46 Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
On Wed, Aug 29, 2012 at 10:53 AM, Volker A. Brandt v...@bb-c.de wrote: Hello Alasdair! It is with much sadness that I hereby resign as project lead. This is sad news indeed. Thank you for all your work. It has not gone unnoticed, and it stands as an example to others. I personally hope that OI continues in one form or another. +1 -- Michael Schuster http://recursiveramblings.wordpress.com/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
Hi This is a very sad day in the history of open-source effort, I'd like to give Alasdair my support in these moment and I really appreciate his words. The behavior of those big firms that gain a lot from the openindiana initiative, but do not contribute in the same way, is very annoying and break the trust that OI users have with them. This is lack of support is unacceptable, and only the union of all forces, both from the private sector as well as large companies can make OI the best existing operating system. I hope your decision, although final, can be changed. I think you're the right person to lead this project precisely for the courage that you've had so far. Thank you Paolo Marcheschi On 08/29/12 03:18, Alasdair Lumsden wrote: Dear OI Developers, It is with much sadness that I hereby resign as project lead. I may, if the situation improves under a new project lead, stick around to offer my opinion or occasional assistance, but my resignation is final; I have no wish to return to the project in a leadership capacity. My resignation is primarily driven by a lack of time; I simply cannot commit the hours necessary to maintain a project of this size. I have my life, my health (primarily mental), and my future to think of. But it is also in part due to frustrations with the difficulty of making any progress on the project. OpenSolaris was maintained by a large corporate entity. We however, are volunteers, contributing our personal time to work on a project we believed in. For many of us this was the first open source project we had ever contributed to, myself included. The task at hand was vast, and we were ill equipped to deal with it. But what really, right from the very beginning, upset me, was the lack of interest from the large commercial players benefiting from Illumos, and from those who had been paid to work on Solaris at Sun. Instead, what we got, was grief regarding the name (Project Indiana seemingly being a sore point for Solaris engineers, something I was completely unaware of when we chose OpenIndiana), hostility towards IPS, and a total lack of interest, encouragement or friendship from people many of us looked up to when we were mere end-users of Solaris under Sun. Right from the very beginning, Illumos was on life-support. I have no doubt that Nexenta, Delphix, and Joyent in particular will continue to innovate and that SmartOS will be a success, but support for Solaris from the open-source software community has over the past 2 years gone from bad to worse. Only the other day the MongoDB developers responding to an issue with it segfaulting on OI stated OI isn't supported, use Linux: https://groups.google.com/forum/?fromgroups=#!topic/mongodb-user/45C7M_po1No I lay the blame of this squarely on the lack of a successful general purpose distribution of Solaris/Illumos. OpenIndiana was my attempt at competing with the Linux distros, but our lack of progress has torpedoed it. Nobody in their right mind would use OI - it ships severely out of date insecure software, lacks some of the most common 3rd party apps such as LibreOffice, and so much simple shit that should just work, such as pecl install, gem install, pip install or whatever barfs due to nonsense SunStudio flags, to the point you need a background in computer science and compiler flags to get it to work. Not fit for purpose. So what exactly are 3rd party software developers such as the FFMpeg or MongoDB developers supposed to use to develop and test their software on? Buy a SmartDatacenter? Install a storage product? Run it on a database appliance? All of you, Joyent, Nexenta, Delphix, are complicit in the increasing irrelevance of Illumos. OI, even in it's current current state, is by far the most widely used Illumos distro, so by not supporting it beyond contributing to the Illumos core, you've all shot yourselves in the foot. With a fucking shotgun. What's sad is that you don't even see it. It didn't have to be this way. With some assistance we could have made large strides forward - we had lots of solid ideas of how to get things moving. What we lacked was time, graft, and expertise from those who worked on this professionally - items easily supplied by those with deep pockets and plenty to gain from our success. Instead we got the Illumian farce from Nexenta, along with their senior staff claiming OI is an existential threat to their continued existence. And when I asked for help back in November, we got Bryan Cantrill telling us all when you want to do something, just do it - rich coming from someone paid to work on all this whilst the OI devs volunteer their personal time, often at considerable personal sacrifice, to work on this stuff. With the ZFSOnLinux port becoming increasingly popular (so many of the Linux users I know are using it), and brtfs/dtrace-on-linux/upstart/whatever else slowly brewing away, even some of the
Re: [oi-dev] Resignation as OI Lead
Sad to hear, but I can certainly appreciate the reasons behind it. Regards John G On 08/29/12 18:53, Volker A. Brandt wrote: Hello Alasdair! It is with much sadness that I hereby resign as project lead. This is sad news indeed. Thank you for all your work. It has not gone unnoticed, and it stands as an example to others. I personally hope that OI continues in one form or another. Best regards -- Volker ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
Alasdair Lumsden wrote: Dear OI Developers, It is with much sadness that I hereby resign as project lead. Alasdair, Thanks for your effort! Cheers, Henk ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
Hello Alasdair, Alasdair Lumsden alasdai...@gmail.com írta 2012-08-29 02:18-kor: It is with much sadness that I hereby resign as project lead. I may, if the situation improves under a new project lead, stick around to offer my opinion or occasional assistance, but my resignation is final; I have no wish to return to the project in a leadership capacity. I'm sad about your decesion, but I hope, you think it again or at least show us direction and sy continues your work as great as you did. But it is also in part due to frustrations with the difficulty of making any progress on the project. OpenSolaris was maintained by a large I always say to my collegues that: Don't fix sg. which already works! I lay the blame of this squarely on the lack of a successful general purpose distribution of Solaris/Illumos. OpenIndiana was my attempt at competing with the Linux distros, but our lack of progress has torpedoed it. Nobody in their right mind would use OI - it ships severely out of date insecure software, lacks some of the most common 3rd party apps such as LibreOffice, and so much simple shit that should just work, such I think you see a glass half empty. But that glass is almost full, from another point of view: Every Server thing I ever tried on OI is works, and do it's work more stable than the competing linux varinats. Eg. Storage platform: And I'm not talking about ZFS and the advantages of it, but if you want to implement a storage server on Linux You will suck. Suck with the incompatible implementations of iSCSI targets. (And at least all of them is a piece of shit...) That you cannot resize a lun on the fly. All off them sucks by design. On OI you just install comstar, and it just works. I think there is a difference on quality beetween the two approach: Design first than implement (like in OI) and do sg. which seems sign of work, then hack it... Let's see OS level virtualization: On linux there is vserver, openvz, lxc, and who knows what else, with different feature sets. Except LXC all off them is a separate patch. With huge warnings of it's lack of official / out of box support even in distros like Debian... On OI there are zones. Well designed, and simply just works. Again. I could continue, but I hope You see my point. With the ZFSOnLinux port becoming increasingly popular (so many of the Linux users I know are using it), and brtfs/dtrace-on-linux/upstart/whatever else slowly brewing away, even some of the core features of Illumos are becoming less and less Maybe it's popular. I use (and administer) linux since '96... It's many time. But now, I would never even try a linux (or bsd) zfs implementation, without comstar and the related things I get from OI which is more robust in any beta/alfa/any version of OI, than in a mega-hiper-stable-patched-rmany release of any linux. - what matters is perception and the typical Linux user is happy with good enough. When I encourage my Linux-using friends to try OI they laugh in my face. OI and Illumos to them is a dead platform. Add to that our increasingly out of date and poor hardware support due to the march of never ending new LAN/SATA/SAS/motherboard/GPU chipsets and you start to get the picture. With time and wisdom any linux user bore in the hacks, workarounds and other time wasting things, and wants a system which just works. I don't remember where I see the logo, if it was a late (realy open) OpenSoleris or it was on the OpenIndiana boot screen but that phrase is very true: Love at first boot! Finally, I wish Illumos every success. Ultimately Illumos is what matters, OI was only ever going to be a vessel for delivering it's power to end users. May it go from strength to strength and get the recognition, attention and user-base it so rightly deserves. +1 With many thanks for your work, György Pásztor, end user/sysadmin. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
2012-08-29 5:18, Alasdair Lumsden wrote: It is with much sadness that I hereby resign as project lead. I may, if the situation improves under a new project lead, stick around to offer my opinion or occasional assistance, but my resignation is final; I have no wish to return to the project in a leadership capacity. Well, it is sure with a heavy heart that one hears (or makes) such news. I sure hope that we'll see and hear more of you again, and that the project does not wither in one way or another. You and me did have some different and sometimes opposing views on what OI should be doing and what is intended to look like (i.e. regarding SVR4 support for importing old local zones from SXCE/Sol10, SPARC distro and stuff like that); still, I prefer to stick with OpenIndiana as long as possible - as the most understandable descendant of OpenSolaris. At least, having the common gate infrastructure and building docs in place does leave hope that your personal resignation automatically dooms and closes this wonderful project. Thanks for keeping the servers running ;) And certainly thanks for coping with us for so long and making this distro a reality - however strange it may be after all. I still hope that commercial implementations and sales of support for OI would happen and help maintain the project with paybacks/donations/etc. //Jim Klimov ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
Alisdair, Thank you. I wish you well in wherever you head. You're enthusiasm and energy will be sorely missed. Gary ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
On 08/29/12 03:18 AM, Alasdair Lumsden wrote: Dear OI Developers, It is with much sadness that I hereby resign as project lead. I may, if the situation improves Thank you for Alasdair EverCity support and for making Openindiana. I think we all hope you will continue to be included as extremely valuable leader of Openindiana project who's insights are invaluable. I suppose there is initiative in project leaders to jump into position and to further extend operational structure of Openindiana as best Illumos distribution project. To all reading this: Bare in mind Openindiana is `just` an distribution and any contribution you make, small or big - is bringing back more value to all using it, including you. All your ideas also counts , bug reports, RFEs and support we can give to each other. Also path for commercial support for Openindiana is open, everyone is free to show an initiative. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
[private to you Alasdair - but I could also make some public remarks] Alasdair Lumsden alasdai...@gmail.com wrote: But it is also in part due to frustrations with the difficulty of making any progress on the project. OpenSolaris was maintained by a large corporate entity. We however, are volunteers, contributing our personal time to work on a project we believed in. For many of us this was the first open source project we had ever contributed to, myself included. The task at hand was vast, and we were ill equipped to deal with it. The problem I see is that Illumos only seems to be open to ex Sun employees. But what really, right from the very beginning, upset me, was the lack of interest from the large commercial players benefiting from Illumos, and from those who had been paid to work on Solaris at Sun. Instead, what we got, was grief regarding the name (Project Indiana seemingly being a sore point for Solaris engineers, something I was completely unaware of when we chose OpenIndiana), hostility towards IPS, and a total lack of interest, encouragement or friendship from people many of us looked up to when we were mere end-users of Solaris under Sun. I am not sure who might have send hostile statements. I am definitely very sceptic to IPS as I've seen to many problems that do not apply to the standard packaging system. Given the fact that all Solaris users I personally know, prefer the SVr4 packaging system and /usr/bin in front of PATH, I believe that Indiana was a step into a direction that excluded traditional Solaris users. Well, this has been done by Ian Murdock who took my project proposal I send to Sun and mixed it with some Debian ideas Given the fact that the number of people that are useful for actively maintaining a OpenSolaris based distro is low, the first mistake was to create Belenix on the ideas of SchilliX but without collaboration. I know that was not you but we have several smaller effects into a similar direction that all together create problems. It would be a pity if OpenSolaris would die. OpenSolaris needs more collaboration and some planning on how different flavors can be created without making major components incompatible between distros. I lay the blame of this squarely on the lack of a successful general purpose distribution of Solaris/Illumos. OpenIndiana was my attempt at competing with the Linux distros, but our lack of progress has torpedoed it. Nobody in their right mind would use OI - it ships severely out of date insecure software, lacks some of the most common 3rd party apps such as LibreOffice, and so much simple shit that should just work, such as pecl install, gem install, pip install or whatever barfs due to nonsense SunStudio flags, to the point you need a background in computer science and compiler flags to get it to work. Not fit for purpose. See above, with a source base that is reusable (i.e. it must create SVr4 packages) the total effort for all OpenSolaris distros could be reduced. So what exactly are 3rd party software developers such as the FFMpeg or MongoDB developers supposed to use to develop and test their software on? Buy a SmartDatacenter? Install a storage product? Run it on a database appliance? This is part of OI? All of you, Joyent, Nexenta, Delphix, are complicit in the increasing irrelevance of Illumos. OI, even in it's current current state, is by An important point here is the fact that Illumos repeatedly introduces changes that cannot be aggreed with for a general OpenSolaris continuation upstream. Another point is that Illumos does not like collaboration. Garret D'amore aproached me in June 2010 with his plans for Illumos and asked me wether I would be interested to collaborate. I told him, that for me it would important to have support for creating SVr4 packages and he agred. He even offered to immediately integrate star (planned since 2004 - before Solaris 10) and to give me a seat in the Illumos steering board. After the press release of Illumos, things looked different. Nothing has been turned into reality and it seems that Garret just intended to keep me from starting an own project before Illumos. This is the current base for the problems in the OpenSolaris continuation in the time past Sun. If we do not manage to fix these problems, OpenSolaris will be no more than a fileserver for Nexenta and a web server for Joyent. Instead we got the Illumian farce from Nexenta, along with their senior staff claiming OI is an existential threat to their continued existence. Nice to see that you see this like I do. Garret started to bite against anything that could exist besides Illumos and now Nexenta bites against anything that existst besides their distro. With the ZFSOnLinux port becoming increasingly popular (so many of the Linux users I know are using it), and I see no real threat with that I hope, I really do hope, that Illumos
Re: [oi-dev] Resignation as OI Lead
joerg.schill...@fokus.fraunhofer.de (Joerg Schilling) wrote: [private to you Alasdair - but I could also make some public remarks] Sorry for the wrong recipitent list. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
On Aug 29, 2012, at 2:27 PM, Joerg Schilling wrote: Garret is the base for the recent segregation which may become the base for the future death of OpenSolaris. I was under the impression that OpenSolaris has been dead for quite some time. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation as OI Lead
Hello Alasdair: Thank you for all of your selfless efforts. Warmest regards-- Ken ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
