Re: [oi-dev] oi_151a9 roadmap & planning
On 19 Feb 2014, at 16:45, Peter Tribble wrote: > > > > On Wed, Feb 19, 2014 at 2:35 PM, Andy Stormont > wrote: > > I’d love to see an SVR4 distro that was actually supported by upstream > illumos but I won’t be the one to make it happen. > > Define supported. Tribblix is a pure SVR4 distro from a vanilla illumos-gate, > really just a handful of scripts to build the distro. I didn't need anything > on > the illumos side to make it all work. > I want to be able to checkout, build and install illumos-gate without having to jump through any hoops. In my mind supported means I can do that using the same or a similar process to the process documented for OI on illumos.org. It shouldn’t feel like a second class citizen. When I get a chance I’ll check Tribblix out. Andy. > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > ___ > oi-dev mailing list > oi-dev@openindiana.org > http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Bayard Bell wrote: > illumos never made any promises to you, I am sorry to see that you are uninformed. 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] oi_151a9 roadmap & planning
On 19 Feb 2014, at 15:19, Joerg Schilling wrote: > Bayard Bell wrote: > >>> From my experiences Illumos is non-collaborative and non-trustworthy. >>> >>> This however is something that could be easily changed. Illumos would just >>> need to give a sign that there is a will for collaboration. >> >> This is tiresome and unreasonable, Joerg. > > I am not sure what you call unreasonable…. The rest of my e-mail was quite explicit on this point. If you're nevertheless "not sure", I take this as a sign that you will continue to complain about the lack of reasonable interlocutors whom you ignore when they address you and ask you what you'll do today to collaborate rather than what are your preferred conclusions and consequences of a personal dispute from four years ago. > A promise is a promise and as Illumos broke that, this is a problem initiated > by Illumos. I am not unforgiving, so it would be simple to just implement the > promise to come out of the current situation. illumos never made any promises to you, so when this "promise" further implicitly exempts you from the current contribution process, it's a non-starter. In fact, Garrett does not have the authority to say that a contribution can bypass the contribution process, and such an exemption would violate the fundamental integrity of the process. If it's "simple", it's as simple as that, and this isn't the first time this has been said directly--I could post the mail thread we had some time ago with the advocates list that went precisely to these points. Further, I checked the archives a year ago, and I don't recall finding any contribution you submitted to the community under the current process, only complaints about not being able to have work accepted by telephone call to Garrett immediately after the fork, while the process was still largely undefined. If you don't take the option to break the circle where it's available, that's the definition of what can be done and entirely up to you. The further hypothesis this suggests is that you have settled on fixating on this previous incident because the contradiction which has been brought to your attention in fact relieves you of dealing with or accepting any criticism of your work or forms of participation. I don't think you've attempted to address this fundamental contradiction when it's been brought to your attention: you continue to define equal treatment as preferential treatment in explicit violation of standards that apply to everyone else. You use the word collaboration a great deal--in the concrete practice of it for the illumos community, I think you either don't know what it means or are yourself averse to it. I do not know whether you aware of this evasion, but when you cast its lack of acceptance as a character deficit of others, I feel compelled to raise this publicly. Anyway, that you've replied to the first line of what I said and professed that you don't understand what's been said before that you very evidently don't want to hear, is a sign that this won't be a dialogue, which is an expected disappointment and already more than needs to be said. I appreciate that this is a difficult position for you, but as long as your basic premise for talking about this is that there's no problem on your end, this is going nowhere. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On Wed, Feb 19, 2014 at 2:35 PM, Andy Stormont wrote: > > > I'd love to see an SVR4 distro that was actually supported by upstream > illumos but I won't be the one to make it happen. > Define supported. Tribblix is a pure SVR4 distro from a vanilla illumos-gate, really just a handful of scripts to build the distro. I didn't need anything on the illumos side to make it all work. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Andy Stormont wrote: > > This is what I did in late 2010 and early 2011. > > > > Svr4 package meta data is present and maintained on SchilliX-ON. > > Feel free to take it. > > I?d love to see an SVR4 distro that was actually supported by upstream > illumos but I won?t be the one to make it happen. > > Do you not have any desire to move to an illumos-gate base? The problem is that there now are more differences between illumos and SchilliX-ON that just the package meta data. But I am open to discussions and proposals as long as they permit enough room for the goals I have for SchilliX. 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] oi_151a9 roadmap & planning
Bayard Bell wrote: > > From my experiences Illumos is non-collaborative and non-trustworthy. > > > > This however is something that could be easily changed. Illumos would just > > need to give a sign that there is a will for collaboration. > > This is tiresome and unreasonable, Joerg. I am not sure what you call unreasonable A promise is a promise and as Illumos broke that, this is a problem initiated by Illumos. I am not unforgiving, so it would be simple to just implement the promise to come out of the current situation. 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] oi_151a9 roadmap & planning
On 19 Feb 2014, at 14:27, Igor Kozhukhov wrote: > Hi All, > > it is thread about OI , but let me provide additional info. > > We are talking about illumos, but I think, we have to understand, that > illumos based on sponsors who are using it for business and depend on it. > > Take a look list of advocates: all advocates from companies who are using > illumos for business and invest to devs/env. Not true. Please review the advocates list, which shows that Rich Lowe remains without commercial affiliation: http://wiki.illumos.org/display/illumos/RTI+Advocacy___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On 19 Feb 2014, at 13:30, Joerg Schilling wrote: > Andy Stormont wrote: > >> The IPS metadeta isn?t really that useful to non-IPS distributions but I?m >> not sure removing it is a good idea. Instead I?d rather see the SVR4 data >> reintegrated if it?s going to see some use and somebody cares enough to >> maintain it. > > This is what I did in late 2010 and early 2011. > > Svr4 package meta data is present and maintained on SchilliX-ON. > Feel free to take it. I’d love to see an SVR4 distro that was actually supported by upstream illumos but I won’t be the one to make it happen. Do you not have any desire to move to an illumos-gate base? > > Even though I have no use for the IPS meta data, I did maintain it so far... > > 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 ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Hi All, it is thread about OI , but let me provide additional info. We are talking about illumos, but I think, we have to understand, that illumos based on sponsors who are using it for business and depend on it. Take a look list of advocates: all advocates from companies who are using illumos for business and invest to devs/env. we try to talk about some integrations/changes in illumos for other projects, but we have no advocates who can integrate our changes if they are not interest for companies with business based on illumos. also - as you can see - all companies/distrs are not using illumos as is - all have forks with additional changes. but - all depend on maintenance of additional changes and wants minimize it by integrate changes to illumos. for my opinion: packaging it is not critical area for illumos and can be using outside based on current IPS manifests. yes - will be better to have integrated DEB packages generation (just for example), but who will maintain it ? yes - i can maintain it, but who will integrate it ? update tools and some other changes ? As i said - we have no additional advocates/integrators who can do it with out of scope of business needs. good example: Xen community and work with tree. source tree has parts with persons who can review it and integrate. Example: if you want commit your changes to 'tools' - you have to add persons in MAINTAINERS list who are familiar with tools and responsible for approval/integration. We have no it with illumos. we have list of advocates. if changes are no interest for companies with illumos business - changes will not integrate to illumos tree and we can only maintain it on personal forks. but with good result: we can update personal tree by illumos changes for personal distr. -- Best regards, Igor Kozhukhov On Feb 19, 2014, at 5:30 PM, Joerg Schilling wrote: > Andy Stormont wrote: > >> The IPS metadeta isn?t really that useful to non-IPS distributions but I?m >> not sure removing it is a good idea. Instead I?d rather see the SVR4 data >> reintegrated if it?s going to see some use and somebody cares enough to >> maintain it. > > This is what I did in late 2010 and early 2011. > > Svr4 package meta data is present and maintained on SchilliX-ON. > Feel free to take it. > > Even though I have no use for the IPS meta data, I did maintain it so far... > > 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 ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On 19 Feb 2014, at 12:26, Joerg Schilling wrote: > Alasdair Lumsden wrote: > >>> Date: Wed, 19 Feb 2014 12:42:53 +0100 >>> From: joerg.schill...@fokus.fraunhofer.de >> >>> >>> Well it would be great if some people at Illumos would not try to dictate >>> things but signal that there is an interest for a collaboration. >> >> illumos is collaborative. In the past year there has been around 50 >> contributors all working on the code: > > It may be that this is your personal impression, but this is not usable for a > general statement. > > From my experiences Illumos is non-collaborative and non-trustworthy. > > This however is something that could be easily changed. Illumos would just > need to give a sign that there is a will for collaboration. This is tiresome and unreasonable, Joerg. It's been pointed out that your definition of collaboration is that your contribution not be evaluated by the same process that applies to anyone else attempting to contribute, and your complaint is that, before this process was established, you felt work you offered for contribution wasn't accepted. When this point is raised, you don't address it head-on, your responses are stuck on an impasse you hit with Garrett in 2010 rather than dealing with the community and contribution process as it's actually functioned for the last three years. Garrett isn't the illumos community, and I, like everyone else in the community, have no reason to take a position on what happened between the two of you four years ago or see that as relevant to what's happened since Garrett shepherded illumos to a collaborative community with collective technical direction. You may not like hearing this, but what you consider dispositive is generally not taken as relevant. If that's something you can't get past, that's a matter of your choice rather than ongoing problems with the illumos community. On top of that, over the course of several years numerous people in the community have given you feedback about shortcomings in your own responses to offered contributions to help you offer feedback that is constructive for those contributors and the community, and you've shown no interest in taking or addressing that feedback. The observed pattern is that you object to contributions without offering a clear problem definition that can process a better solution either immediately or as a later change. Call it open source liberalism as a community value: people don't want to be told simply that what they've got isn't sufficient as a contribution, they want to be given a clear definition of what needs to be resolved so that they receive criticism they can address, and your feedback is often disregarded because you articulate criticism that is simply negative. I don't see that you fundamentally appreciate that otherwise valid criticism that has only negative expression is not satisfactory in community collaboration and may therefore be set aside. You haven't taken any of this feedback, which I take to be offered in the hope and expectation that collaboration is possible, on board. I'm not trying to say that the illumos community is perfect, but you've been repeatedly unwilling to demonstrate that you're willing to self-scrutinise and compromise on the question of collaboration, even as you loudly complain about others, which itself becomes a further obstacle. If you're surprised that the result is that you therefore lack credibility, that's ultimately your problem and deficit. When you add to that claims that "the community" isn't trustworthy, that's offensive, and that's the point at which I feel compelled to write a public response like this one. It's not that anyone doubts your fundamental ability as an engineer, but anyone who wants to be part of a community has to expect to participate by the standing conventions of that community. I've taken you seriously enough to read back through mail archives to look at the interactions you've had with the community over the years, and what I see is that there are serious problems on your end that you do not acknowledge. There are certainly communities whose product I like and use but whose process I don't care to engage, and I'm able to reconcile myself to that. If you don't want to work by other people's rules, the result may be unfortunate, but it's not fundamentally a question of other's willingness or integrity. I'd certainly be happier if you'd begin to deal with this. I should add that, as long as your responses continue the pattern I describe, I have no intention of or interest in responding. Kind regards, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Andy Stormont wrote: > The IPS metadeta isn?t really that useful to non-IPS distributions but I?m > not sure removing it is a good idea. Instead I?d rather see the SVR4 data > reintegrated if it?s going to see some use and somebody cares enough to > maintain it. This is what I did in late 2010 and early 2011. Svr4 package meta data is present and maintained on SchilliX-ON. Feel free to take it. Even though I have no use for the IPS meta data, I did maintain it so far... 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] oi_151a9 roadmap & planning
On 19 Feb 2014, at 12:17, Alasdair Lumsden wrote: > illumos is not a distribution. It carries packaging metadata in IPS format as > a convenience for downstream distributions, but downstream distributions are > not obliged to use IPS. Perhaps in the future illumos will stop shipping > package metadata completely. > > Many other illumos based distributions use other package formats, such as > rpm, deb and SVR4. Ultimately, packaging is a distribution specific > implementation detail. > > If you wish to use SVR4 in SchilliX, you are free to do so. Nobody is > stopping you. > The IPS metadeta isn’t really that useful to non-IPS distributions but I’m not sure removing it is a good idea. Instead I’d rather see the SVR4 data reintegrated if it’s going to see some use and somebody cares enough to maintain it. I also think the “nobody is stopping you” attitude is anti-collaborative and (I hate to resort to name calling here) childish too. illumos needs to learn to be more accommodating if it wants to have the collaboration of distributors. And that’s my 2c. Andy. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Alasdair Lumsden wrote: > > Date: Wed, 19 Feb 2014 12:42:53 +0100 > > From: joerg.schill...@fokus.fraunhofer.de > > > > > Well it would be great if some people at Illumos would not try to dictate > > things but signal that there is an interest for a collaboration. > > illumos is collaborative. In the past year there has been around 50 > contributors all working on the code: It may be that this is your personal impression, but this is not usable for a general statement. >From my experiences Illumos is non-collaborative and non-trustworthy. This however is something that could be easily changed. Illumos would just need to give a sign that there is a will for collaboration. 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] oi_151a9 roadmap & planning
> Date: Wed, 19 Feb 2014 12:42:53 +0100 > From: joerg.schill...@fokus.fraunhofer.de > > Well it would be great if some people at Illumos would not try to dictate > things but signal that there is an interest for a collaboration. illumos is collaborative. In the past year there has been around 50 contributors all working on the code: http://github.com/illumos/illumos-gate/graphs/contributors?from=2013-02-17&to=2014-02-16&type=c Given that SchillixON has 1 collaborator, is it not possible that the barrier to collaboration between yourself and illumos is not illumos, but you? >> It isn't. There are distros using SVR4, dpkg, rpm, IPS, pkgsrc, >> and/or no packaging at all. > > Well, where is the SVr4 package meta data in Illumos? > Note that IPS meta data is limited compared to Svr4 package meta data and for > this reason, there is no way to convert meta data correctly. illumos is not a distribution. It carries packaging metadata in IPS format as a convenience for downstream distributions, but downstream distributions are not obliged to use IPS. Perhaps in the future illumos will stop shipping package metadata completely. Many other illumos based distributions use other package formats, such as rpm, deb and SVR4. Ultimately, packaging is a distribution specific implementation detail. If you wish to use SVR4 in SchilliX, you are free to do so. Nobody is stopping you. > Illumos would need to verify first that Illumos is collaborative. > Currently we have the unfortunate state that Illumos did not include some > software even though this was promised and a code review has been presented. > Colaboration of course also means that partners are trustworthy and implement > promises. > > Once Illumos turned into a trustworthy and collaborative entity, it makes of > curse sense to file bugs against Illumos. Illumos is very collaborative. A diverse array of individuals and organisations successfully collaborate on illumos every day: https://github.com/illumos/illumos-gate/graphs/commit-activity Illumos has a clearly defined contribution process: http://wiki.illumos.org/display/illumos/How+To+Contribute If you want to collaborate, you have to follow the procedure. Everyone does. If you're not prepared to follow the procedure, then that's your problem, and nobody else's. If you correctly follow the procedure, and the community decides it doesn't want that specific feature, the mature adult thing to do is to accept this and move on and continue to attempt to collaborate on other items. Forking illumos as SchilliX-ON because you can't follow procedures or because people don't want a specific feature integrated is petty and childish. Then complaining about it for years afterwards on mailing lists is further evidence of stunted emotional development. If you want to collaborate, collaborate and follow the god damned procedure. Otherwise, stop bothering everyone on these mailing lists. Regards, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Peter Tribble wrote: > First, you need to stop saying "must" and attempting to > dictate design and implementation decisions. Well it would be great if some people at Illumos would not try to dictate things but signal that there is an interest for a collaboration. > > > Well > > > > - IPS must not be the only packaging > > > > It isn't. There are distros using SVR4, dpkg, rpm, IPS, pkgsrc, > and/or no packaging at all. Well, where is the SVr4 package meta data in Illumos? Note that IPS meta data is limited compared to Svr4 package meta data and for this reason, there is no way to convert meta data correctly. > > - /sbin/sh may be a link to the Bourne Shell > > > > Why is this relevant to collaboration? Because for being able to collaborate, we need to have a common understanding of what is preventing collaboration. This results in avoiding changes that prevent collaboration. > This is a good example of where collaboration matters. If this is > important to you, and you want the system to behave correctly > with an alternate /sbin/sh, then log bugs against illumos, > preferably with fixes. However, as with all projects, if having > it fixed matters to you, you have to do the work. Illumos would need to verify first that Illumos is collaborative. Currently we have the unfortunate state that Illumos did not include some software even though this was promised and a code review has been presented. Colaboration of course also means that partners are trustworthy and implement promises. Once Illumos turned into a trustworthy and collaborative entity, it makes of curse sense to file bugs against Illumos. > - scripts need to be open for being able to mount /usr using > > the Bourne Shell. > > > > We're off into the realms of distro-specific implementation artefacts. > This sort of statement doesn't even make sense for some distros, > and the concept it refers to isn't part of illumos at all. I am sure whether you understand what collaboration is... if we like to share important scripts, we need to have a common understanding of what others are interested in. Specific changes at one side may prevent collaboration at certain points and this is such a point. Being able to have native (SVr4 package based) zones on all distros would be another thing to look at. In any case, collaboration means that one distro does not dictate constraints that affect other distros. > > > - We need to find a way for versioned libraries to support > > as much binary compatibility as possible. > > > > That's how shared libraries, versions, mapfiles, and filters > work. But again, this is largely irrelevant - binary compatibility > has often been out of fashion in many open source projects, so > it's not a problem we can solve. And it's a much smaller part of > the overall compatibility question - what versions of interpreters > are present, what build options were chosen, where are applications > installed? If we like to collaborate, we need to decide whether there should be binary compatibility. I remember that in the late 1990s, Linux was so fragmented, that it was impossible to run a binary on distro a if it was compiled for distro b. OpenSolaris has a much smaller community and I am not sure whether OpenSolaris will survive too much fragmentation. 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] oi_151a9 roadmap & planning
On Wed, Feb 12, 2014 at 1:42 PM, Joerg Schilling < joerg.schill...@fokus.fraunhofer.de> wrote: > > What do we need for collaboration? > First, you need to stop saying "must" and attempting to dictate design and implementation decisions. > Well > > - IPS must not be the only packaging > It isn't. There are distros using SVR4, dpkg, rpm, IPS, pkgsrc, and/or no packaging at all. > - /usr/gnu must not be the default first entry in PATH > Irrelevant. How distros want to define a default user environment is their own business. > - /sbin/sh may be a link to the Bourne Shell > Why is this relevant to collaboration? This is a good example of where collaboration matters. If this is important to you, and you want the system to behave correctly with an alternate /sbin/sh, then log bugs against illumos, preferably with fixes. However, as with all projects, if having it fixed matters to you, you have to do the work. - scripts need to be open for being able to mount /usr using > the Bourne Shell. > We're off into the realms of distro-specific implementation artefacts. This sort of statement doesn't even make sense for some distros, and the concept it refers to isn't part of illumos at all. > - We need to find a way for versioned libraries to support > as much binary compatibility as possible. > That's how shared libraries, versions, mapfiles, and filters work. But again, this is largely irrelevant - binary compatibility has often been out of fashion in many open source projects, so it's not a problem we can solve. And it's a much smaller part of the overall compatibility question - what versions of interpreters are present, what build options were chosen, where are applications installed? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Jean-Pierre, 1. Set -Bacpi-user-options=0x0 (or 0x2) during Grub boot. 2. Use a known good Wi-fi USB stick or daughtercard for WEP. 3. Use VESA for most display things. For the most part, most oi-devs should have working hardware with OI (or speak up, if not). ~ Ken Mays On Thursday, February 13, 2014 10:21 AM, Laurent Blume wrote: Le 2014/02/13 16:00 +0100, Alan Coopersmith a écrit: > Nearly all package systems have repositories, what makes IPS more > intolerable than the rest? I wrote a list, but then thought again, there's no point arguing that anymore. If people using it are happy with it, good for them, > (Or had you just not noticed that support for package > archives, > basically tarball versions of IPS packages, was added to IPS in years past? > It wasn't there in the 0.1 version used in the initial OpenSolaris > releases, > but that was what the kids today call "Minimum Viable Product" not the > intended final state of features.) That touches a nerve. Back then, it was not called 0.1. It was called 1.0, and requests for a file format were met with derision, who would ever need that? It was certainly not part of the plan. It took years just to make the devs admit it was needed, and then some more to actually deliver it. I guess now it's good enough. Wonderful, *finally* a round wheel! Having been burnt there, I'd rather not see that history being rewritten to make those disliking it with their good reasons look like fools. Distrusting people who took half a decade to find that round was the right shape makes sense. Laurent ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On 02/12/14 11:42 PM, Jean-Pierre André wrote: Hi, Alan Coopersmith wrote: On 02/12/14 12:41 PM, Peter Tribble wrote: (Ideally, you want other communities to build and distribute software for you. That's one area where IPS is a huge obstacle - all this repository stuff is an intolerable burden on third parties, Nearly all package systems have repositories, what makes IPS more intolerable than the rest? (Or had you just not noticed that support for package archives, basically tarball versions of IPS packages, was added to IPS in years past? Oh, great, I did not know. I have three computers, but the hardware for two of them is not supported by OI. I can only install OI on third one, but the WiFi network access is not supported. So, basically I have to download through Windows or Linux, but I do not known how to "ftp" or "wget" an update, or anything which is not available in an ISO, from an IPS ? I am the maintainer of ntfs-3g. How should I deposit an "IPS package" on a plain web server I do not control ? (see http://jp-andre.pagesperso-orange.fr/openindiana-ntfs-3g.html) Follow the instructions in the link I provided to use pkgrecv to generate a .p5p archive on the machine you're using to create the package: http://docs.oracle.com/cd/E26502_01/html/E21383/pkgcreate.html#gluem Figuring out how you post a file on a web site you do not control is your problem to solve - I can't help you there. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Le 2014/02/13 16:00 +0100, Alan Coopersmith a écrit: Nearly all package systems have repositories, what makes IPS more intolerable than the rest? I wrote a list, but then thought again, there's no point arguing that anymore. If people using it are happy with it, good for them, (Or had you just not noticed that support for package archives, basically tarball versions of IPS packages, was added to IPS in years past? It wasn't there in the 0.1 version used in the initial OpenSolaris releases, but that was what the kids today call "Minimum Viable Product" not the intended final state of features.) That touches a nerve. Back then, it was not called 0.1. It was called 1.0, and requests for a file format were met with derision, who would ever need that? It was certainly not part of the plan. It took years just to make the devs admit it was needed, and then some more to actually deliver it. I guess now it's good enough. Wonderful, *finally* a round wheel! Having been burnt there, I'd rather not see that history being rewritten to make those disliking it with their good reasons look like fools. Distrusting people who took half a decade to find that round was the right shape makes sense. Laurent ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Hi, maybird1...@yahoo.com wrote: Hi Jean-Pierre, 1. Submit hardware issues here (dev only) so we know or file a feature/bug request. I would like at least https://www.illumos.org/issues/4097 to be addressed. Another computer just displays "APIC Error interrupt on CPU 0. Status 0 = 0, Status 1 = 80" when trying to boot OpenIndiana, but I take this as not fixable. On the the only compute I can use, I have spent a lot of time solving https://www.illumos.org/issues/3367 and Jim Klimov has helped me, but I have never been able to provide support for WPA encryption. I will try again if somebody helps me (I will provide more efforts if the issue 4097 is addressed). 2. Ask oi-userland team for IPS integration of your software. FUSE was in sfe repository. I got them integrated by Milan two years ago, but he is so busy... Also wait a few days, a new version is coming. ~ Ken Mays Sent from Yahoo Mail on Android <https://overview.mail.yahoo.com/mobile/?.src=Android> *From: * Jean-Pierre André ; *To: * ; *Subject: * Re: [oi-dev] oi_151a9 roadmap & planning *Sent: * Thu, Feb 13, 2014 7:42:54 AM Hi, Alan Coopersmith wrote: > On 02/12/14 12:41 PM, Peter Tribble wrote: >> (Ideally, you want other communities to build and distribute software >> for you. That's one area where IPS is a huge obstacle - all this >> repository stuff is an intolerable burden on third parties, > > Nearly all package systems have repositories, what makes IPS more > intolerable > than the rest? (Or had you just not noticed that support for package > archives, > basically tarball versions of IPS packages, was added to IPS in years past? Oh, great, I did not know. I have three computers, but the hardware for two of them is not supported by OI. I can only install OI on third one, but the WiFi network access is not supported. So, basically I have to download through Windows or Linux, but I do not known how to "ftp" or "wget" an update, or anything which is not available in an ISO, from an IPS ? I am the maintainer of ntfs-3g. How should I deposit an "IPS package" on a plain web server I do not control ? (see http://jp-andre.pagesperso-orange.fr/openindiana-ntfs-3g.html) > It wasn't there in the 0.1 version used in the initial OpenSolaris > releases, > but that was what the kids today call "Minimum Viable Product" not the > intended > final state of features.) > > http://docs.oracle.com/cd/E26502_01/html/E21383/pkgcreate.html#gluem > ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Hi Jean-Pierre, 1. Submit hardware issues here (dev only) so we know or file a feature/bug request. 2. Ask oi-userland team for IPS integration of your software. FUSE was in sfe repository. ~ Ken Mays Sent from Yahoo Mail on Android ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Peter Tribble wrote: > On Wed, Feb 12, 2014 at 10:34 AM, Alasdair Lumsden > wrote: > > > > > TribbliX was a for fun desktop-oriented distro (correct me if I'm wrong) > > by someone that hates IPS and loves SVR4 packaging. I got the impression > > Peter never seemed to want to help OI out directly because of the IPS issue. > > > > That's partially true, but not entirely. It's true that I hate IPS, > part of that is emotional and psychological scars that will > probably never heal, and they run deep. So it seems that your impression is the same as mine. There is a will for collaboration but it seems that OI causes the impression that OI is not interested in collaboration. If you like to collaborate between different projects, this will need both sides to make compromises and to give enough room so the other side is able to have a benefit. I am willing to give other people enough room and I guess that you would do the same. So let us see whether OI is willing to colaborate. As I mentioned since a long time: OpenSolaris has not enough people to make each job twice, so we need to collaborate if we like OpenSolaris to survive. 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] oi_151a9 roadmap & planning
Hi, Alan Coopersmith wrote: On 02/12/14 12:41 PM, Peter Tribble wrote: (Ideally, you want other communities to build and distribute software for you. That's one area where IPS is a huge obstacle - all this repository stuff is an intolerable burden on third parties, Nearly all package systems have repositories, what makes IPS more intolerable than the rest? (Or had you just not noticed that support for package archives, basically tarball versions of IPS packages, was added to IPS in years past? Oh, great, I did not know. I have three computers, but the hardware for two of them is not supported by OI. I can only install OI on third one, but the WiFi network access is not supported. So, basically I have to download through Windows or Linux, but I do not known how to "ftp" or "wget" an update, or anything which is not available in an ISO, from an IPS ? I am the maintainer of ntfs-3g. How should I deposit an "IPS package" on a plain web server I do not control ? (see http://jp-andre.pagesperso-orange.fr/openindiana-ntfs-3g.html) It wasn't there in the 0.1 version used in the initial OpenSolaris releases, but that was what the kids today call "Minimum Viable Product" not the intended final state of features.) http://docs.oracle.com/cd/E26502_01/html/E21383/pkgcreate.html#gluem ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
I think the general idea is to get to a minimum criteria as basis for wider collaboration. We have to start small and manageable and agreeable. Then others will follow if they see the benefits of that working together for a healthier code and healthier community guidelines, then there will be lower barriers for participation, more consensus-building and pooling together the best solutions out there. I am inviting Alasdair, Peter Tribble, Jörg Schilling and Martin Bochnig to discuss this and find the best way forward in creating this smaller circle to create greater trust and more support from within the OpenSolaris-derived communities and the wider ecosystem. The perks would be participation of more stakeholders and better performance from healthy code maintenance and less work for we know who does what where, this further invites more hobbyist and professionals to devote their time if we have a better framework. In a sense we need to build confidence in the core technologies. Thank you all for your response. I am driving you to re-think. It is my personal dream to see our community finally take off and overcome this "heritage of missing collaboration" from Sun in illumos and OpenIndiana. I am very positive about future collaboration with UNIX lovers so we can evolve the best UNIX ever. Sincerely yours, Seth Nimbosa, your Brother and Comrade-in-Arms http://twitter.com/nimbosa FB.com/nimbosa -- ** * ** -- * Normal is getting dressed in clothes that you buy for work* *and driving through traffic in a car that you are still paying for -* *in order to get to the job you need to pay for the clothes and the car,and the house you leave vacant all day so you can afford to live in it. * - Ellen Goodman On Thu, Feb 13, 2014 at 4:41 AM, Peter Tribble wrote: > On Wed, Feb 12, 2014 at 10:34 AM, Alasdair Lumsden > wrote: > >> >> TribbliX was a for fun desktop-oriented distro (correct me if I'm wrong) >> by someone that hates IPS and loves SVR4 packaging. I got the impression >> Peter never seemed to want to help OI out directly because of the IPS issue. >> > > That's partially true, but not entirely. It's true that I hate IPS, > part of that is emotional and psychological scars that will > probably never heal, and they run deep. > > I have no particular love for SVR4 - it's there, it's compatible with > every other Solaris system I run, it's good enough (unlike IPS), it > doesn't suffer from the crippling technical limitations of IPS, and > I'm sufficiently familiar with it that I can use it with zero effort. For a > hobby distro, minimizing effort is paramount. Had I come from > a different background, I might have chosen rpm or dpkg. > > Tribblix is definitely for fun, and has the advantage that I completely > understand the needs of its target audience. (Currently, just me.) > Desktop orientation is a reflection of current state rather than future > intentions, though. > > People naturally work on different things in different ways. If there's > > a net benefit to working together (and there are always costs to doing > > so - whether that be making a commitment, surrendering control, fitting > > in to alien processes, or having to support something you're opposed to) > > then people will do so; it gets much harder if there isn't a net benefit. > > I decided that the amount of effort I would have to expend to make > > another distro do what I want was far higher than the effort > > needed to directly build it from scratch, and I was right on that. > > And, just as importantly, I learnt far more from doing so than I > > would have otherwise. > > I suspect that there will always be multiple distros - we have multiple > packaging systems, variant desktop philosophies, appliance vs > server vs desktop vs general-purpose. The real focus ought to be > illumos, and any distro adds to the overall ecosystem. > > Strengthening that ecosystem ought to be the goal, not picking > a winning distro or forcing people with different aims and objectives > to toe some common party line. In many ways, much of that work > needs to be done outside our own community - by working with > other communities to strengthen their support of illumos/Solaris > based systems. > > (Ideally, you want other communities to build and distribute software > for you. That's one area where IPS is a huge obstacle - all this > repository stuff is an intolerable burden on third parties, pushes you > in the direction of central control and bottlenecks, and discourages > the long tail of drive-by contributors that is key to successful > projects. [See what Linus was talking about recently, although > that was about the problems with CLAs. Same issue of reducing > barriers to participation, though.]) > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > __ _ On Wed, Feb 12, 2014 at 9:42 PM, Joerg Schilling < jo
Re: [oi-dev] oi_151a9 roadmap & planning
Vincent, The manufacturers provide the drivers and chose whether to support their newer products on S11 or illumos-based OSes. You can use /hipster for modern server installs: http://dlc.openindiana.org/isos/hipster/OI-hipster-text-20140124.iso oi_151a8: http://dlc.openindiana.org/isos/151a8/oi-dev-151a8-text-x86.iso With a8, you can use the proper procedures for pkg updating to the a9 release which is a bug fix snapshot release of packages in IPS. The next ISO release of this branch may be planned for a10. People contribute as they have interests. Just look at the efforts of the oi-userland team. ~ Ken Mays On Wednesday, February 12, 2014 1:39 PM, Vincent Torri wrote: On Wed, Feb 12, 2014 at 7:33 PM, Udo Grabowski (IMK) wrote: > On 12/02/2014 14:25, Andri L. Vicko wrote: >> >> Hi, >> >> I Hope on Next OpenIndiana oi_151a9 will be support Emulex 16 Gbps and >> Qlogic 16 Gbps for comstar target. >> > ?? A9 is already released. really ? http://openindiana.org/ <-- 151a8 http://openindiana.org/download/ <-- 151a8 Vincent Torri ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On 02/12/14 12:41 PM, Peter Tribble wrote: (Ideally, you want other communities to build and distribute software for you. That's one area where IPS is a huge obstacle - all this repository stuff is an intolerable burden on third parties, Nearly all package systems have repositories, what makes IPS more intolerable than the rest? (Or had you just not noticed that support for package archives, basically tarball versions of IPS packages, was added to IPS in years past? It wasn't there in the 0.1 version used in the initial OpenSolaris releases, but that was what the kids today call "Minimum Viable Product" not the intended final state of features.) http://docs.oracle.com/cd/E26502_01/html/E21383/pkgcreate.html#gluem -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On Wed, Feb 12, 2014 at 10:34 AM, Alasdair Lumsden wrote: > > TribbliX was a for fun desktop-oriented distro (correct me if I'm wrong) > by someone that hates IPS and loves SVR4 packaging. I got the impression > Peter never seemed to want to help OI out directly because of the IPS issue. > That's partially true, but not entirely. It's true that I hate IPS, part of that is emotional and psychological scars that will probably never heal, and they run deep. I have no particular love for SVR4 - it's there, it's compatible with every other Solaris system I run, it's good enough (unlike IPS), it doesn't suffer from the crippling technical limitations of IPS, and I'm sufficiently familiar with it that I can use it with zero effort. For a hobby distro, minimizing effort is paramount. Had I come from a different background, I might have chosen rpm or dpkg. Tribblix is definitely for fun, and has the advantage that I completely understand the needs of its target audience. (Currently, just me.) Desktop orientation is a reflection of current state rather than future intentions, though. People naturally work on different things in different ways. If there's a net benefit to working together (and there are always costs to doing so - whether that be making a commitment, surrendering control, fitting in to alien processes, or having to support something you're opposed to) then people will do so; it gets much harder if there isn't a net benefit. I decided that the amount of effort I would have to expend to make another distro do what I want was far higher than the effort needed to directly build it from scratch, and I was right on that. And, just as importantly, I learnt far more from doing so than I would have otherwise. I suspect that there will always be multiple distros - we have multiple packaging systems, variant desktop philosophies, appliance vs server vs desktop vs general-purpose. The real focus ought to be illumos, and any distro adds to the overall ecosystem. Strengthening that ecosystem ought to be the goal, not picking a winning distro or forcing people with different aims and objectives to toe some common party line. In many ways, much of that work needs to be done outside our own community - by working with other communities to strengthen their support of illumos/Solaris based systems. (Ideally, you want other communities to build and distribute software for you. That's one area where IPS is a huge obstacle - all this repository stuff is an intolerable burden on third parties, pushes you in the direction of central control and bottlenecks, and discourages the long tail of drive-by contributors that is key to successful projects. [See what Linus was talking about recently, although that was about the problems with CLAs. Same issue of reducing barriers to participation, though.]) -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Besides, isn't a9 a bugfix only release that hasn't been spun as an ISO? If so, that's why it's not directly listed on the download page. The pkg.openindiana.org/dev address is the default publisher for OI, so just installing from the latest iso and running pkg update should get you to 151a9. Do note that most of the people here are knowledgeable and will try to be helpful if possible, but do not tolerate aggressive or downright abusive questions (and shouldn't have to). Bryan --- Bryan N Iotti ironsides.med...@runbox.com +39 366 3708436 Original Message From: Milan Jurik Sent: Wednesday, February 12, 2014 20:00 To: OpenIndiana Developer mailing list Reply To: OpenIndiana Developer mailing list Subject: Re: [oi-dev] oi_151a9 roadmap & planning Hi, On st, 2014-02-12 at 19:48 +0100, Vincent Torri wrote: > On Wed, Feb 12, 2014 at 7:43 PM, Milan Jurik wrote: > > Hi, > > > > On st, 2014-02-12 at 19:38 +0100, Vincent Torri wrote: > >> On Wed, Feb 12, 2014 at 7:33 PM, Udo Grabowski (IMK) > >> wrote: > >> > On 12/02/2014 14:25, Andri L. Vicko wrote: > >> >> > >> >> Hi, > >> >> > >> >> I Hope on Next OpenIndiana oi_151a9 will be support Emulex 16 Gbps and > >> >> Qlogic 16 Gbps for comstar target. > >> >> > >> > ?? A9 is already released. > >> > >> really ? > >> > >> http://openindiana.org/ <-- 151a8 > >> http://openindiana.org/download/ <-- 151a8 > >> > > > > really - http://pkg.openindiana.org/dev/ > > it's a joke ? you guys don't mention nor provide the new release on > your **own** website... so the users have to look at some obscure > adress (i don't even know if it's mentioned on openindiana.org) to get > it ? > It is not joke. It is about that people working on it have no time to do more. And the rest of people is just filling the mailing lists of ... It is not obscure address for power-users. > i understand now why openindiana don't attract people... > Well, it is not easy toy. > Vincent Torri > 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] oi_151a9 roadmap & planning
Hi, On st, 2014-02-12 at 19:48 +0100, Vincent Torri wrote: > On Wed, Feb 12, 2014 at 7:43 PM, Milan Jurik wrote: > > Hi, > > > > On st, 2014-02-12 at 19:38 +0100, Vincent Torri wrote: > >> On Wed, Feb 12, 2014 at 7:33 PM, Udo Grabowski (IMK) > >> wrote: > >> > On 12/02/2014 14:25, Andri L. Vicko wrote: > >> >> > >> >> Hi, > >> >> > >> >> I Hope on Next OpenIndiana oi_151a9 will be support Emulex 16 Gbps and > >> >> Qlogic 16 Gbps for comstar target. > >> >> > >> > ?? A9 is already released. > >> > >> really ? > >> > >> http://openindiana.org/ <-- 151a8 > >> http://openindiana.org/download/ <-- 151a8 > >> > > > > really - http://pkg.openindiana.org/dev/ > > it's a joke ? you guys don't mention nor provide the new release on > your **own** website... so the users have to look at some obscure > adress (i don't even know if it's mentioned on openindiana.org) to get > it ? > It is not joke. It is about that people working on it have no time to do more. And the rest of people is just filling the mailing lists of ... It is not obscure address for power-users. > i understand now why openindiana don't attract people... > Well, it is not easy toy. > Vincent Torri > Best regards, Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On Wed, Feb 12, 2014 at 7:43 PM, Milan Jurik wrote: > Hi, > > On st, 2014-02-12 at 19:38 +0100, Vincent Torri wrote: >> On Wed, Feb 12, 2014 at 7:33 PM, Udo Grabowski (IMK) >> wrote: >> > On 12/02/2014 14:25, Andri L. Vicko wrote: >> >> >> >> Hi, >> >> >> >> I Hope on Next OpenIndiana oi_151a9 will be support Emulex 16 Gbps and >> >> Qlogic 16 Gbps for comstar target. >> >> >> > ?? A9 is already released. >> >> really ? >> >> http://openindiana.org/ <-- 151a8 >> http://openindiana.org/download/ <-- 151a8 >> > > really - http://pkg.openindiana.org/dev/ it's a joke ? you guys don't mention nor provide the new release on your **own** website... so the users have to look at some obscure adress (i don't even know if it's mentioned on openindiana.org) to get it ? i understand now why openindiana don't attract people... Vincent Torri ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Hi, On st, 2014-02-12 at 19:38 +0100, Vincent Torri wrote: > On Wed, Feb 12, 2014 at 7:33 PM, Udo Grabowski (IMK) > wrote: > > On 12/02/2014 14:25, Andri L. Vicko wrote: > >> > >> Hi, > >> > >> I Hope on Next OpenIndiana oi_151a9 will be support Emulex 16 Gbps and > >> Qlogic 16 Gbps for comstar target. > >> > > ?? A9 is already released. > > really ? > > http://openindiana.org/ <-- 151a8 > http://openindiana.org/download/ <-- 151a8 > really - http://pkg.openindiana.org/dev/ > Vincent Torri > Best regards, Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On Wed, Feb 12, 2014 at 7:33 PM, Udo Grabowski (IMK) wrote: > On 12/02/2014 14:25, Andri L. Vicko wrote: >> >> Hi, >> >> I Hope on Next OpenIndiana oi_151a9 will be support Emulex 16 Gbps and >> Qlogic 16 Gbps for comstar target. >> > ?? A9 is already released. really ? http://openindiana.org/ <-- 151a8 http://openindiana.org/download/ <-- 151a8 Vincent Torri ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On 12/02/2014 14:25, Andri L. Vicko wrote: Hi, I Hope on Next OpenIndiana oi_151a9 will be support Emulex 16 Gbps and Qlogic 16 Gbps for comstar target. ?? A9 is already released. -- Dr.Udo GrabowskiInst.f.Meteorology a.Climate Research IMK-ASF-SAT www.imk-asf.kit.edu/english/sat.php KIT - Karlsruhe Institute of Technologyhttp://www.kit.edu Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026 smime.p7s Description: S/MIME Cryptographic Signature ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On Wed, 12 Feb 2014, Alasdair Lumsden wrote: There is no community. Only self centered individuals who think their way is best. Fragmentation was inevitable. I stated very clearly that I thought fragmentation would kill illumos. I still feel that today - fragmentation is killing illumos. Instead of one strong OS, we have a dozen fringe ones. I think that you must be biased due to your background. I am on almost all the mailing lists (including Illumos) and I do see plenty of collaboration and contributions to Illumos. In fact, there is considerable recent activity and contributions from many parties. Illumos contributions seem to be rather well managed and tracked. Some fragmentation is a good thing because it proves that multiple parties can deal with the code base and allows people to explore their own ideas. TribbliX is an excellent example of that. There is a rather similar situation with Linux. There is (mostly) one Linux kernel and baseline environment but many different Linux distributions which construct different application frameworks on top. OpenIndiana is like a Linux distribution. Regardless, I don't see this discussion has anything to do with 16 Gbit FC support (a driver/enumeration issue) and I don't see how an opinion from someone who starts off like "I haven't kept track how build 134 metamorphosed into build 151a9 today" can have much merit when he then produces a long opinion on the very topic he claims he has not paid any attention to. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Alasdair Lumsden wrote: > Hi Seth, > > When I started OpenIndiana, I wanted to avoid the "Linux Distribution > Fragmentation" issue, so I created a community distro and tried to solicit > input from everyone and try to keep everyone happy. > > I failed miserably. Nobody wants to collaborate, everyone wants to do their > own thing. Hence the huge number of distros you see before you. The problem with OpenIndiana is that it is a continuation project for "Sun Indiana". Sun Indiana however (if ignoring the IPS issue) has been created using my project proposal for a community based distro I send to Sun in 2005. Sun did take the ideas from the proposal but did not collaborate... OpenIndiana for this reason has a heritage of missing collaboration. It needs to be restructured in order to prevent contradictions with other distros in order to allow collaboration. > XStreamOS, DilOS, Schillix etc all have their own goals and agendas, and > again, have no interest in collaborating. I cannot speak for the other distros, but SchilliX definitely is interested in collaboration once possible partners do not act in a way that prevents collaboration. Note that I am trying to support collaboration since September 2004 and definitely since June 17 2005 when SchilliX was published as the first OpenSolaris based distro. What do we need for collaboration? Well - IPS must not be the only packaging - /usr/gnu must not be the default first entry in PATH - /sbin/sh may be a link to the Bourne Shell - scripts need to be open for being able to mount /usr using the Bourne Shell. - We need to find a way for versioned libraries to support as much binary compatibility as possible. 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] oi_151a9 roadmap & planning
Jonathan Adams wrote: > *Joerg Schilling* wrote: > > "I am not sure whether you are aware about the fact that OpenSoaris has few > contributors and that Illumos is trying to frighten developers by not being > a sure partner you may trust" Wow, a reply after more than 5 months > Please take that with a pinch of salt. Joerg is an experienced and prolific > programmer, who has done great things and is very supportive of Solaris ... > but he doesn't like Garrett, and because he sees the Illumos fork as a > project implemented by Garrett, doesn't play well with Illumos. You may either missinterpret things or you are incorrectly informed. Claiming that I don't like Garret is not correct. It is however most probable that Garret does not like me. What happened is that Garret promised me, before Illumos was created, that Illumos will definitely integrate e.g. star (star integration was planned and approved by Sun for Solaris-10 on initiative by Sun - not me). After Garret publically announced Illumos, he was no longer interested in his promise. This caused Illumos to become implausible as a project. > He has been asked to contribute on many occasions, and his response isn't > to create diff/patches it is to say "you should just use my version of the > program" ... not even explaining the differences or why you should use his > program. This is wrong - sorry. There was a webrev for star integration but Garret just ignored it. If you are interested in the credibility of the Illumos project and you have influence on the project, you could make the promise happen. To do this, you may take the current code from the SchilliX-ON code repository and integrate it into Illumos. > Schillix has 2 contributors, neither of which is paid to work on the > project so cannot devote much time to it. SchilliX currently has three contributors. You are correct, nobody is payed for this purpose. > OpenSXCE has 1 contributor, and because of the way that that project is set > up, it can only have 1 contributor, and as much love and respect as we can > give from this community to Martin, he needs to go and get a job and start > eating. If I am informed correctly, TribbliX also is a 1 contributor project. > PS. if you go to Schillix you will find that your ZFS is no longer > compatible with either Illumos/*BSD/Linux or even with Oracle Solaris for > that matter, both have major enhancements, although both differ slightly. The problem with OpenZFS is that is does not have an own code repository. In addition, I have not yet been able to find the documentation of the general method used for implementing enhancements. Once I could review this method and it turns out that the current OpenZFS code still fits into OpenSolaris, I am willing to upgrade. Collaboration is a result of promises and credibility by implementing said promises. Collaboration is also a result of compromises. If you are not willing to make compromises, you try to dictace what other people may do and this is not compatibile with collaboration. I am open for a collaboration for OpenSolaris as long as there is room for different goals in the different distros. 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
[oi-dev] oi_151a9 roadmap & planning
Hi, I Hope on Next OpenIndiana oi_151a9 will be support Emulex 16 Gbps and Qlogic 16 Gbps for comstar target. Currently if we used 16 Gbps, comstar speed still 8 Gbps. Thanks, Andri L. Vicko ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
entally > > Sincerely yours, > > Seth Nimbosa, your Brother and Comrade-in-Arms > > http://twitter.com/nimbosa > FB.com/nimbosa > > > > -- ** * ** -- > > * Normal is getting dressed in clothes that you buy for work* > *and driving through traffic in a car that you are still paying for -* > > *in order to get to the job you need to pay for the clothes and the car, > and the house you leave vacant all day so you can afford to live in it. * > > - Ellen Goodman > > > ________ > > > *Joerg Schilling* > > Joerg.Schilling at fokus.fraunhofer.de > > *Tue Sep 3 09:11:10 UTC 2013* > >- Previous message: [oi-dev] oi_151a9 roadmap & > planning<http://openindiana.org/pipermail/oi-dev/2013-September/002660.html> >- Next message: [oi-dev] oi_151a9 roadmap & > planning<http://openindiana.org/pipermail/oi-dev/2013-September/002661.html> >- *Messages sorted by:* [ date > ]<http://openindiana.org/pipermail/oi-dev/2013-September/date.html#2659> > [ thread > ]<http://openindiana.org/pipermail/oi-dev/2013-September/thread.html#2659> > [ subject > ]<http://openindiana.org/pipermail/oi-dev/2013-September/subject.html#2659> > [ author > ]<http://openindiana.org/pipermail/oi-dev/2013-September/author.html#2659> > > -- > > Ray Arachelian < > > > > > > ray at arachelian.com <http://openindiana.org/mailman/listinfo/oi-dev>> wrote: > > >* > Since oi_151a9 was scheduled for release this month, some initial > * > Could someone explain why you udr 151a9? > > > - It is not based on onnv_151 > > - It is most likely not the 151th release for OI > > - It is based like others on onnv_147+ > > >* > thoughts: > *>* > > *>* > 1. bump illumos to b02c4a353739 > *>* > 2. bump oi-jds to ee8cf112eec2 (hg.opensolaris.cz/oi-jds > <http://hg.opensolaris.cz/oi-jds>) > *>* > 3. Nvidia 304.108 video driver > *>* > 4. Xnv_161 integration (Alasdair ?) > *>* > > *>* Can we add USB 3.0 support, and SATA 6GB support? Please? > * > I am not sure whether you are aware about the fact that OpenSoaris has few > contributors and that Illumos is trying to frighten developers by not being a > sure partner you may trust. > > Promising to include software causes people to spend time in creating a > webrev, > but later not doing a code review causes at least this time to be wasted. This > finally ends up in not fulfilling a commitment and is toxic for Illumos > credibility. > > Adding code with known bugs to Illumos even though it did not pass a > codereview, just because the code is from an animal that is more equal > than others destroys credibility. > > Illumos also drives in a direction that is not what I understand by going the > Solaris (UNIX) way. Code is removed just because it is not of interest for > Nexenta or Joyent, continuing this way will at some time lower attractivity. > Ripping off troff from man(1) because "col -x" (as a result from a buggy > localization software in Illumos) does not pass japanese characters is a > strange response to a problem. > > > > While points 1..4 are decisions that can be made by OI, your proposal is not > leading to a decision that could be made by OI. > > You may hope that this at some time is handled by Illumos, but Illumos does > not > cover all the skills that are needed. So my question to other OI members is: > are you 100% bound to Illumos? > > I am currently underway with finishing the package collection for SchilliX > based on network loadable Svr4 packages that I made basically working in > February 2011. Now that SchilliX collects helpers, we expect to be in a state > to deliver a full desktop in a few weeks. After that, I will start to work > again on the OpenSolaris code base. As mentioned, a toxic person prevents > Illumos from being interested in collaboration, so we either end up in a > tattered OpenSolaris landscape or we find a way to pool changesets and let > distros decide how to compose their OpenSolaris base. > > Are you interested in collaboration? > If yes, do you have an idea how this could be done? > > Jörg > > -- > EMail: > > joerg at schily.isdn.cs.tu-berlin.de > <http://openindiana.org/mailman/listinfo/oi-dev> (home) Jörg Schilling > D-13353 Berlin > > > js at cs.tu-berlin.de <http://openindiana.org/mailman/listinfo/oi-dev> > (uni) >joerg.schilling at fokus.fraunhofer.de > <http://openindiana.org/mailman/listi
Re: [oi-dev] oi_151a9 roadmap & planning
*Joerg Schilling* wrote: "I am not sure whether you are aware about the fact that OpenSoaris has few contributors and that Illumos is trying to frighten developers by not being a sure partner you may trust" Please take that with a pinch of salt. Joerg is an experienced and prolific programmer, who has done great things and is very supportive of Solaris ... but he doesn't like Garrett, and because he sees the Illumos fork as a project implemented by Garrett, doesn't play well with Illumos. He has been asked to contribute on many occasions, and his response isn't to create diff/patches it is to say "you should just use my version of the program" ... not even explaining the differences or why you should use his program. because we fail to use his program, he asserts that we don't accept contributions and therefore are not a trustable community. Schillix has 2 contributors, neither of which is paid to work on the project so cannot devote much time to it. OpenSXCE has 1 contributor, and because of the way that that project is set up, it can only have 1 contributor, and as much love and respect as we can give from this community to Martin, he needs to go and get a job and start eating. PS. if you go to Schillix you will find that your ZFS is no longer compatible with either Illumos/*BSD/Linux or even with Oracle Solaris for that matter, both have major enhancements, although both differ slightly. Just my 2cents. Jon ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On Wed, Feb 12, 2014 at 10:30 AM, seth Nimbosa wrote: > Basically, we need to take one step back so we can move forward. > > the OpenSolaris community as it is has always been small from the start > after Sun was swallowed by Oracle and all official development ceased > > we had to start over with illumos and OpenIndiana, > however, there has not been much collaboration outside of Nexenta and Joyent > internal developement, and there is a general feeling of a hack and slash > attitude within illumos and OpenIndiana circles, not very inviting to > contributors as significant UNIX code-base inherited from Sun's Solaris core > is shrinking while the bloat and half-baked code is growing > imho, if you want to attract people, the OI (and other distributions) should do some advertising. That is, when a release is done, posting news on * phoronix * osnews * slashdot * reddit * lwn.net * linuxfr.org (french website) * others i don't know etc... I know that some of those site are first dedicated to linux but there have been several posts there for other OS too. I know that it is boring (i myself was doing that for a library), but it's a very good way to attract users or developpers. best regards Vincent Torri ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Basically, we need to take one step back so we can move forward. the OpenSolaris community as it is has always been small from the start after Sun was swallowed by Oracle and all official development ceased we had to start over with illumos and OpenIndiana, however, there has not been much collaboration outside of Nexenta and Joyent internal developement, and there is a general feeling of a hack and slash attitude within illumos and OpenIndiana circles, not very inviting to contributors as significant UNIX code-base inherited from Sun's Solaris core is shrinking while the bloat and half-baked code is growing I think people behind TribbliX, XStreamOS, DilOS, napp-it and OmniOS should get together with Schillix and OpenSXCE (previously MartUX) in re-creating the original code-base with significant code improvement plugged in, if any.. another concern is the 3-Gigabyte download for live media!!! i remember there was a time when there was a light OpenSolaris LiveCD based on build 134 (700++ MB), which was easy to try and actually instantly install, from which additional packages can be added to build the system that's right for you.. even with fast internet connection a 3-GB media is too hard to swallow and a high barrier for would-be developers and casual slackers trying a modern UNIX-based system I haven't kept track how build 134 metamorphosed into build 151a9 today, since 2011 I was busy in developing Network Technologies and integrated solutions through Unified Communications and virtualization working with Cisco.com after my failed attempt at volunteering at Sun just when Oracle bought it, but i think it is never too late to take one step back and pick the pieces of our OpenSolaris community, as the only open source UNIX community a large-scale community collaboration of all OpenSolaris-based distribution is needed, and I am willing to do my part in bringing this together, hopefully people from the illumos Foundation can help, but the community must move forward with or without their stewardship, what we need is a massive de-duplication of efforts in our community focused on code-based development not dictated by corporate pragmatic decisions alone.. we can start with a BitBucket or a GitHub repository to rehabilitate the OpenSolaris code and compile all significant improvements and replacements with minimal code-slashing and considerable code-review, this can be done incrementally Sincerely yours, Seth Nimbosa, your Brother and Comrade-in-Arms http://twitter.com/nimbosa FB.com/nimbosa -- ** * ** -- * Normal is getting dressed in clothes that you buy for work* *and driving through traffic in a car that you are still paying for -* *in order to get to the job you need to pay for the clothes and the car, and the house you leave vacant all day so you can afford to live in it. * - Ellen Goodman *Joerg Schilling* Joerg.Schilling at fokus.fraunhofer.de *Tue Sep 3 09:11:10 UTC 2013* - Previous message: [oi-dev] oi_151a9 roadmap & planning<http://openindiana.org/pipermail/oi-dev/2013-September/002660.html> - Next message: [oi-dev] oi_151a9 roadmap & planning<http://openindiana.org/pipermail/oi-dev/2013-September/002661.html> - *Messages sorted by:* [ date ]<http://openindiana.org/pipermail/oi-dev/2013-September/date.html#2659> [ thread ]<http://openindiana.org/pipermail/oi-dev/2013-September/thread.html#2659> [ subject ]<http://openindiana.org/pipermail/oi-dev/2013-September/subject.html#2659> [ author ]<http://openindiana.org/pipermail/oi-dev/2013-September/author.html#2659> -- Ray Arachelian < ray at arachelian.com <http://openindiana.org/mailman/listinfo/oi-dev>> wrote: >* > Since oi_151a9 was scheduled for release this month, some initial * Could someone explain why you udr 151a9? - It is not based on onnv_151 - It is most likely not the 151th release for OI - It is based like others on onnv_147+ >* > thoughts: *>* > *>* > 1. bump illumos to b02c4a353739 *>* > 2. bump oi-jds to ee8cf112eec2 (hg.opensolaris.cz/oi-jds <http://hg.opensolaris.cz/oi-jds>) *>* > 3. Nvidia 304.108 video driver *>* > 4. Xnv_161 integration (Alasdair ?) *>* > *>* Can we add USB 3.0 support, and SATA 6GB support? Please? * I am not sure whether you are aware about the fact that OpenSoaris has few contributors and that Illumos is trying to frighten developers by not being a sure partner you may trust. Promising to include software causes people to spend time in creating a webrev, but later not doing a code review causes at least this time to be wasted. This finally ends up in not fulfilling a commitment and is toxic for Illumos credibility. Adding code with known bugs to Illumos even though it did not pass a co
Re: [oi-dev] oi_151a9 roadmap & planning
Well played Garrett. On a more positive note I wish to thank everyone who has contributed directly or indirectly to OI and I'm sure there are many others like me who are adamant users but generally voiceless.Regards From: Garrett D'AmoreSent: Tuesday, 3 September 2013 14:44To: OpenIndiana Developer mailing listReply To: OpenIndiana Developer mailing listSubject: Re: [oi-dev] oi_151a9 roadmap & planningOn Sep 3, 2013, at 2:11 AM, Joerg Schilling wrote:> > I am not sure whether you are aware about the fact that OpenSoaris has few > contributors and that Illumos is trying to frighten developers by not being a > sure partner you may trust. Aargh. I hate responding to Joerg posts, and I know I probably shouldn't, but its not in me to ignore someone who goes around throwing rocks at my house… and there may be folks who are not yet familiar with Joerg's antics, so I feel that some response is unfortunately necessary.> > Promising to include software causes people to spend time in creating a webrev, > but later not doing a code review causes at least this time to be wasted. This > finally ends up in not fulfilling a commitment and is toxic for Illumos > credibility.This all comes back to star(1). And you're continuing with your antics that really result from the fact that you're angry because I refused to personally review your software after I had such negative interaction with you. I told you then, and I repeat now, all you needed to do was find another sponsor willing to review your work, and you *were* required to have your code properly reviewed if you wanted it to be integrated in illumos. You've never undertaken that, and your refusal to follow the rules that we have established for *all* contributions is why your software isn't integrated. Further, going around doing what you can to disrupt illumos operations has turned off almost anyone else who might be wiling to work with you. You urinate on everyone who might have been wiling to give you some help, and wonder why nobody wants to?> > Adding code with known bugs to Illumos even though it did not pass a > codereview, just because the code is from an animal that is more equal > than others destroys credibility.No. This has not happened. I believe you are referring to a hexdump / od incident, again, where your sum total of code review was "its broken" with nothing actionable, except that you were again upset because we were not going to integrate hexdump which you had hastily put together an od-workalike mode for (instead of simply providing actionable feedback to my already complete program.) Other reviewers passed the review and to this date I know of no actual defects in od(1) -- feel free to file bugs if you find otherwise. (I also *did* give you review feedback on your version of od(1), if you recall, and that was actionable.)> > Illumos also drives in a direction that is not what I understand by going the > Solaris (UNIX) way. Code is removed just because it is not of interest for > Nexenta or Joyent, continuing this way will at some time lower attractivity.> Ripping off troff from man(1) because "col -x" (as a result from a buggy > localization software in Illumos) does not pass japanese characters is a > strange response to a problem. > man continues to support roff functions, but we also support mandoc now, which is a much more elegant formatting packaging. It also makes it vastly easier for us to collaborate with *BSD on man page content. The fact that col -x was used for formatting was just one more level of brokenness in the existing package, and we made a decision to switch directions. There is no collaboration from the *Solaris* ecosystem anymore, and so we don't consider that important.> > > While points 1..4 are decisions that can be made by OI, your proposal is not > leading to a decision that could be made by OI.> > You may hope that this at some time is handled by Illumos, but Illumos does not > cover all the skills that are needed. So my question to other OI members is: > are you 100% bound to Illumos?> > I am currently underway with finishing the package collection for SchilliX > based on network loadable Svr4 packages that I made basically working in > February 2011. Now that SchilliX collects helpers, we expect to be in a state > to deliver a full desktop in a few weeks. After that, I will start to work > again on the OpenSolaris code base. As mentioned, a toxic person prevents > Illumos from being interested in collaboration, so we either end up in a > tattered OpenSolaris landscape or we find a way to pool changesets and let > distros decide how to compose the
Re: [oi-dev] oi_151a9 roadmap & planning
On Sep 3, 2013, at 2:11 AM, Joerg Schilling wrote: > > I am not sure whether you are aware about the fact that OpenSoaris has few > contributors and that Illumos is trying to frighten developers by not being a > sure partner you may trust. Aargh. I hate responding to Joerg posts, and I know I probably shouldn't, but its not in me to ignore someone who goes around throwing rocks at my house… and there may be folks who are not yet familiar with Joerg's antics, so I feel that some response is unfortunately necessary. > > Promising to include software causes people to spend time in creating a > webrev, > but later not doing a code review causes at least this time to be wasted. > This > finally ends up in not fulfilling a commitment and is toxic for Illumos > credibility. This all comes back to star(1). And you're continuing with your antics that really result from the fact that you're angry because I refused to personally review your software after I had such negative interaction with you. I told you then, and I repeat now, all you needed to do was find another sponsor willing to review your work, and you *were* required to have your code properly reviewed if you wanted it to be integrated in illumos. You've never undertaken that, and your refusal to follow the rules that we have established for *all* contributions is why your software isn't integrated. Further, going around doing what you can to disrupt illumos operations has turned off almost anyone else who might be wiling to work with you. You urinate on everyone who might have been wiling to give you some help, and wonder why nobody wants to? > > Adding code with known bugs to Illumos even though it did not pass a > codereview, just because the code is from an animal that is more equal > than others destroys credibility. No. This has not happened. I believe you are referring to a hexdump / od incident, again, where your sum total of code review was "its broken" with nothing actionable, except that you were again upset because we were not going to integrate hexdump which you had hastily put together an od-workalike mode for (instead of simply providing actionable feedback to my already complete program.) Other reviewers passed the review and to this date I know of no actual defects in od(1) -- feel free to file bugs if you find otherwise. (I also *did* give you review feedback on your version of od(1), if you recall, and that was actionable.) > > Illumos also drives in a direction that is not what I understand by going the > Solaris (UNIX) way. Code is removed just because it is not of interest for > Nexenta or Joyent, continuing this way will at some time lower attractivity. > Ripping off troff from man(1) because "col -x" (as a result from a buggy > localization software in Illumos) does not pass japanese characters is a > strange response to a problem. > man continues to support roff functions, but we also support mandoc now, which is a much more elegant formatting packaging. It also makes it vastly easier for us to collaborate with *BSD on man page content. The fact that col -x was used for formatting was just one more level of brokenness in the existing package, and we made a decision to switch directions. There is no collaboration from the *Solaris* ecosystem anymore, and so we don't consider that important. > > > While points 1..4 are decisions that can be made by OI, your proposal is not > leading to a decision that could be made by OI. > > You may hope that this at some time is handled by Illumos, but Illumos does > not > cover all the skills that are needed. So my question to other OI members is: > are you 100% bound to Illumos? > > I am currently underway with finishing the package collection for SchilliX > based on network loadable Svr4 packages that I made basically working in > February 2011. Now that SchilliX collects helpers, we expect to be in a state > to deliver a full desktop in a few weeks. After that, I will start to work > again on the OpenSolaris code base. As mentioned, a toxic person prevents > Illumos from being interested in collaboration, so we either end up in a > tattered OpenSolaris landscape or we find a way to pool changesets and let > distros decide how to compose their OpenSolaris base. > > Are you interested in collaboration? > If yes, do you have an idea how this could be done? I strongly caution the OI team to consider carefully… Joerg has a very different idea of collaboration than the illumos team. Once you go down the road of SchilliX, you'll be departing further afield from the OS that the main contributors to the kernel (Joyent, Nexenta, Delphix, DEY, OmniT all employ people to do this for a living) use and maintain. And unlike illumos, where the rules for integration are clearly spelled out, and the leadership is indeed distributed, you'll be entering what is a one- or two-man show, where Joerg's word is law, and
Re: [oi-dev] oi_151a9 roadmap & planning
Joerg, Just because I originated this thread... oi_151a was based on a snapshot of the original 'snv_151' consolidation branches - excluding the 'fully closed' changesets for ON_151 (and other closed 'snv_151' binaries and IP) - predating the 'Solaris 11 Express' release. You now have a hybrid or moreso - a spork based on specific collaborative efforts and backports. The Illumos effort is only a 'kernel-based' code drop based on the ON_147 snapshot. What a distro provider implements for their distro is not a consideration of Illumos as a whole. A provider can maintain the original kernel source and cherrypick changesets from the Illumos project - or any other project - to enhance the kernel or distro in its entirety. Are we still of a mindset that a little leaven leaveneth the whole lump? Some would say to 'pluck out' that which offends you and utilize the good parts. For others, toss out the whole thing into the abyss... and use something else... The people/businesses that use Illumos use this model to accept changesets into their own distros. I can only grasp that you may want to do the same. ~ Ken Mays P.S. (off topic) - Alcohol is a multipurpose poisonous drug consumed and accepted by BILLIONS of people. Therefore, some poisons are both good and bad - it just depends on the 'when and how' upon application... From: Joerg Schilling To: oi-dev@openindiana.org Sent: Tuesday, September 3, 2013 5:11 AM Subject: Re: [oi-dev] oi_151a9 roadmap & planning Ray Arachelian wrote: > > Since oi_151a9 was scheduled for release this month, some initial Could someone explain why you udr 151a9? - It is not based on onnv_151 - It is most likely not the 151th release for OI - It is based like others on onnv_147+ > > thoughts: > > > > 1. bump illumos to b02c4a353739 > > 2. bump oi-jds to ee8cf112eec2 (hg.opensolaris.cz/oi-jds) > > 3. Nvidia 304.108 video driver > > 4. Xnv_161 integration (Alasdair ?) > > > Can we add USB 3.0 support, and SATA 6GB support? Please? I am not sure whether you are aware about the fact that OpenSoaris has few contributors and that Illumos is trying to frighten developers by not being a sure partner you may trust. Promising to include software causes people to spend time in creating a webrev, but later not doing a code review causes at least this time to be wasted. This finally ends up in not fulfilling a commitment and is toxic for Illumos credibility. Adding code with known bugs to Illumos even though it did not pass a codereview, just because the code is from an animal that is more equal than others destroys credibility. Illumos also drives in a direction that is not what I understand by going the Solaris (UNIX) way. Code is removed just because it is not of interest for Nexenta or Joyent, continuing this way will at some time lower attractivity. Ripping off troff from man(1) because "col -x" (as a result from a buggy localization software in Illumos) does not pass japanese characters is a strange response to a problem. While points 1..4 are decisions that can be made by OI, your proposal is not leading to a decision that could be made by OI. You may hope that this at some time is handled by Illumos, but Illumos does not cover all the skills that are needed. So my question to other OI members is: are you 100% bound to Illumos? I am currently underway with finishing the package collection for SchilliX based on network loadable Svr4 packages that I made basically working in February 2011. Now that SchilliX collects helpers, we expect to be in a state to deliver a full desktop in a few weeks. After that, I will start to work again on the OpenSolaris code base. As mentioned, a toxic person prevents Illumos from being interested in collaboration, so we either end up in a tattered OpenSolaris landscape or we find a way to pool changesets and let distros decide how to compose their OpenSolaris base. Are you interested in collaboration? If yes, do you have an idea how this could be done? 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___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On 09/02/2013 09:00 PM, Andrew M. Hettinger wrote: > > USB-3 is most likely going to have to come from Illumos-ON. > Sadly so, but this is my biggest need for OI so far. I don't care that much about video drivers, though I'm sure plenty do. > > Does SATA 6G not work properly? Personally, all my gear is SAS (and I > can attest, that SAS 6G does work just fine) > It does not, if I enable the built in SATA 6GB devices in the BIOS, it won't boot. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Ray Arachelian wrote: > > Since oi_151a9 was scheduled for release this month, some initial Could someone explain why you udr 151a9? - It is not based on onnv_151 - It is most likely not the 151th release for OI - It is based like others on onnv_147+ > > thoughts: > > > > 1. bump illumos to b02c4a353739 > > 2. bump oi-jds to ee8cf112eec2 (hg.opensolaris.cz/oi-jds) > > 3. Nvidia 304.108 video driver > > 4. Xnv_161 integration (Alasdair ?) > > > Can we add USB 3.0 support, and SATA 6GB support? Please? I am not sure whether you are aware about the fact that OpenSoaris has few contributors and that Illumos is trying to frighten developers by not being a sure partner you may trust. Promising to include software causes people to spend time in creating a webrev, but later not doing a code review causes at least this time to be wasted. This finally ends up in not fulfilling a commitment and is toxic for Illumos credibility. Adding code with known bugs to Illumos even though it did not pass a codereview, just because the code is from an animal that is more equal than others destroys credibility. Illumos also drives in a direction that is not what I understand by going the Solaris (UNIX) way. Code is removed just because it is not of interest for Nexenta or Joyent, continuing this way will at some time lower attractivity. Ripping off troff from man(1) because "col -x" (as a result from a buggy localization software in Illumos) does not pass japanese characters is a strange response to a problem. While points 1..4 are decisions that can be made by OI, your proposal is not leading to a decision that could be made by OI. You may hope that this at some time is handled by Illumos, but Illumos does not cover all the skills that are needed. So my question to other OI members is: are you 100% bound to Illumos? I am currently underway with finishing the package collection for SchilliX based on network loadable Svr4 packages that I made basically working in February 2011. Now that SchilliX collects helpers, we expect to be in a state to deliver a full desktop in a few weeks. After that, I will start to work again on the OpenSolaris code base. As mentioned, a toxic person prevents Illumos from being interested in collaboration, so we either end up in a tattered OpenSolaris landscape or we find a way to pool changesets and let distros decide how to compose their OpenSolaris base. Are you interested in collaboration? If yes, do you have an idea how this could be done? 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] oi_151a9 roadmap & planning
USB-3 is most likely going to have to come from Illumos-ON. Does SATA 6G not work properly? Personally, all my gear is SAS (and I can attest, that SAS 6G does work just fine) 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) Ray Arachelian wrote on 09/02/2013 03:57:09 PM: > On 09/01/2013 10:00 AM, ken mays wrote: > > Hello, > > Since oi_151a9 was scheduled for release this month, some initial thoughts: > > 1. bump illumos to b02c4a353739 > 2. bump oi-jds to ee8cf112eec2 (hg.opensolaris.cz/oi-jds) > 3. Nvidia 304.108 video driver > 4. Xnv_161 integration (Alasdair ?) > > Can we add USB 3.0 support, and SATA 6GB support? Please?___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On 09/01/2013 10:00 AM, ken mays wrote: > > Hello, > > Since oi_151a9 was scheduled for release this month, some initial > thoughts: > > 1. bump illumos to b02c4a353739 > 2. bump oi-jds to ee8cf112eec2 (hg.opensolaris.cz/oi-jds) > 3. Nvidia 304.108 video driver > 4. Xnv_161 integration (Alasdair ?) > Can we add USB 3.0 support, and SATA 6GB support? Please? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On 2 September 2013 19:42, Milan Jurik wrote: > Hi, > > On ne, 2013-09-01 at 15:38 -0500, Bob Friesenhahn wrote: >> On Sun, 1 Sep 2013, ken mays wrote: >> > >> > Add more...or less... >> >> Was ksh93 ever updated to fix known bugs (e.g. 'rm -f' with no >> argument produes error) which were fixed in upstream? >> > > find some "mad" man to do that at first :-( I think I found some mad people to do it first :) But first he base code must become ready Ced -- Cedric Blancher Institute Pasteur ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Hi, On ne, 2013-09-01 at 15:38 -0500, Bob Friesenhahn wrote: > On Sun, 1 Sep 2013, ken mays wrote: > > > > Add more...or less... > > Was ksh93 ever updated to fix known bugs (e.g. 'rm -f' with no > argument produes error) which were fixed in upstream? > find some "mad" man to do that at first :-( > Bob Best regards, Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Bob Friesenhahn wrote: > On Sun, 1 Sep 2013, ken mays wrote: > > > > Add more...or less... > > Was ksh93 ever updated to fix known bugs (e.g. 'rm -f' with no > argument produes error) which were fixed in upstream? If it is possible to just fix bugs and to avoid to extend the number of builtins that overlay Solaris commands, I would be interested to upgrade ksh93 in SchilliX-ON. This will however not happen before we are ready with the next SchilliX distr release that is expected to be fully svr4 package based. Anyway, before I update ksh93, I will re-enable the Bourne Shell as /sbin/sh using my enhanced version of the Bourne Shell and by making the 6 shell scripts Bourne Shell compatible again that Sun did "break" in Spring 2010. 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] oi_151a9 roadmap & planning
On 1 September 2013 22:38, Bob Friesenhahn wrote: > On Sun, 1 Sep 2013, ken mays wrote: >> >> >> Add more...or less... > > > Was ksh93 ever updated to fix known bugs For Oracle Solaris yes. The same patch cluster was submitted to illumos-dev but never made it into their sources. > (e.g. 'rm -f' with no argument > produes error) which were fixed in upstream? Short version: Olga Kryzhanovska and Roland Mainz appear to be working on that; if you follow the ast-develop...@research.att.com list you see a flurry of ongoing patches and testing on Solaris being done (current focus appears to be on O_XATTR, /proc, China locale, new allocator, namespaces and stability work). Olga's last comment on the subject was "... we wait for ksh93 version v- to stabilise...". That was in mid August. The last I tried (ast-ksh.2013-08-14) was not quite ready yet since some of the Solaris test modules failed for that version. Glenn Fowlers comments indicate that ksh93 version v- may soon enter the beta phase, maybe we can ask Olga/Roland for patches then. Ced -- Cedric Blancher Institute Pasteur ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
On Sun, 1 Sep 2013, ken mays wrote: Add more...or less... Was ksh93 ever updated to fix known bugs (e.g. 'rm -f' with no argument produes error) which were fixed in upstream? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Hello, The mentioned change is the latest including your changeset as well as the 'ncsd' spurious condition for Illumos. Whatever it translates to in git or elsewhere. Sent from Yahoo! Mail on Android ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
What is this b02c4a353739 illumos version? Is there a typo? I would go with at least: commit 5253393b09789ec67bec153b866d7285a1cf1645 Author: Matthew Ahrens Date: Fri Aug 30 01:19:35 2013 -0800 4082 zfs receive gets EFBIG from dmu_tx_hold_free() Reviewed by: Eric Schrock Reviewed by: Christopher Siden Reviewed by: George Wilson Approved by: Richard Lowe -- Piotr Jasiukajtis On Sep 1, 2013, at 4:00 PM, ken mays wrote: > > Hello, > > Since oi_151a9 was scheduled for release this month, some initial thoughts: > > 1. bump illumos to b02c4a353739 > 2. bump oi-jds to ee8cf112eec2 (hg.opensolaris.cz/oi-jds) > 3. Nvidia 304.108 video driver > 4. Xnv_161 integration (Alasdair ?) > > Add more...or less... > > ~ Ken Mays > > > > > > > > > > ___ > oi-dev mailing list > oi-dev@openindiana.org > http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap & planning
Hi, ken mays wrote: Hello, Since oi_151a9 was scheduled for release this month, some initial thoughts: 1. bump illumos to b02c4a353739 2. bump oi-jds to ee8cf112eec2 (hg.opensolaris.cz/oi-jds) 3. Nvidia 304.108 video driver 4. Xnv_161 integration (Alasdair ?) Add more...or less... Is there some hope to get this internal disk supported : pci bus 0x cardnum 0x1f function 0x02: vendor 0x8086 device 0x282a Intel Corporation 82801 Mobile SATA Controller [RAID mode] CardVendor 0x103c card 0x1894 (Hewlett-Packard Company, Card unknown) This is a rather new controller, but it must have some compatibility with traditional SATA ones, as a Linux live-CD dating back from 2007 is able to use it, but OpenIndiana sees no disk at all. Jean-Pierre ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] oi_151a9 roadmap & planning
Hello, Since oi_151a9 was scheduled for release this month, some initial thoughts: 1. bump illumos to b02c4a353739 2. bump oi-jds to ee8cf112eec2 (hg.opensolaris.cz/oi-jds) 3. Nvidia 304.108 video driver 4. Xnv_161 integration (Alasdair ?) Add more...or less... ~ Ken Mays___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
