Re: [oi-dev] OI project reboot required
I agree with what Peter and Garrett wrote earlier. OI is lacking a clear vision. It should be different than other illumos distros' as well to avoid duplicating work unnecessarily. I think, OI could be illumos hacker distro, and: - carry on providing GUI support, good enough for illumos hackers to use it on their desktops/laptops - it could potentially be based on vanilla illumos-gate; few OI specific changes could be upstreamed or dropped - existing OI users should be able to do pkg update to get the latest bits Not radical or innovative at all. Different enough to what other distros are doing though (no GUI, own illumos-gate forks). I did a quick survey on IRC and looks like there is enough talented and capable people who would be willing to help with the model described above. Existing releng process and contribution process prevent anything from happening though. I would like to help to change that. Radical and innovative ideas are welcome as well. They could be worked on in parallel as sub-projects. What do you think about OI being illumos hacker distro? Andrzej On 10 May 2013 03:12, Nick Zivkovic zivkovic.n...@gmail.com wrote: For what it's worth, I only need Xorg, xpdf and xterm to take care of my graphics needs. Everything that doesn't involve coding happens on linux, mac and winxp. As long as a distro can support Xorg, it is viable for me. So whatever you guys do, please don't remove the basic graphics capability! On May 9, 2013 7:20 PM, Garrett D'Amore garrett.dam...@dey-sys.com wrote: On May 9, 2013, at 4:00 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Thu, 9 May 2013, Garrett D'Amore wrote: Upshot, *today* anyone who thinks there is a commercial future in illumos on the desktop is probably smoking something. There are a few people who would be willing to pay for it, but it needs more than a few dozen people willing to pay a couple hundred dollars (more often substantially less) to make this a viable and interesting (economically) venture. There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. Admittedly true. And yet, most of them *started* on the desktop. Linux's roots are in the desktop. Most of those distros took off because they had a groundswell of support from developer users who wanted it on the desktop -- they didn't have servers, and options like VMware simply didn't exist at the time. I'd argue that this is largely an artifact of history. I would be entirely *unsurprised* if distro vendors like RedHat and Oracle simply *ditched* their desktop support at some point in the future -- its clear to me at least that folks aren't running those distros on the desktop. In fact, I can't think of *anyone* who's paying for a desktop OS that doesn't come from either Apple or Microsoft. Availability of a graphical desktop is seen as a requirement for common acceptance. Historically true, but I seriously doubt it now. SmartOS is the counter example from this community. I think there are others. For example, OpenBSD was highly popular for a long time for its security emphasis, but I don't know *anyone* who ran it on a desktop. The widespread availability of virtualization like VMware, VirtualBox, and Parallels means that there is little need to take over the user's desktop to provide a reasonable environment. Most people these days develop using SSH, etc. The folks I know who use Linux would, apart from a few extremists, not care whether the desktop ran Linux, FreeBSD, or Solaris, as long as it Just Worked and provided a familiar UNIX-like backend. (I contend that these principles have lead strongly to the uptake of MacOS in the developer community…. I use an Apple laptop for my own environment, even though I wouldn't *dream* of using MacOS in a server capacity.) For me, Terminal.app and ssh is along with VMware gives me everything I need for doing cool things with illumos on my desktop. I explicitly *disable* the graphical login on illumos. :-) Much/most of the graphical desktop development taking place for Linux does not seem to be done by the companies which popularly peddle it (e.g. Canonical has been more of a desktop packager except for its useless Unity). Only partly true (Qt is the counter example). But yes, a lot of the desktop development in Gnome and company is done by community members who are passionate about this. And guess what -- almost all those guys are Linux bigots. There's a huge trend in those spaces to adopt technologies that are Linux-specific, to the point of near active hostility towards other FOSS. That creates a huge barrier for leveraging their efforts. Do we have the kind of volunteerism here to take up a duplicate effort? And why just duplicate? If we have *that* kind of interest and volunteerism, I'd recommend actually doing something *cooler* and better. Of course,
Re: [oi-dev] OI project reboot required
On 2013-05-10 02:19, Garrett D'Amore wrote: There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. I would be entirely *unsurprised* if distro vendors like RedHat and Oracle simply *ditched* their desktop support at some point in the future -- its clear to me at least that folks aren't running those distros on the desktop. Well, Oracle does provide and promote SunRays, and while admittedly most of their market targeting is about VDI and access to virtual Windows desktops, there are many requests on the SRSS mailing list about adding support for server-side Ubuntu as the SRSS terminal server, because certain apps only exist for Linux and tunneling of connections makes their graphics lag, and RHEL/OEL/Solaris desktops are argued to be not so user-friendly (I have no opinion on this, to me X11 is a means to display more characters on screen than possible in a text mode). Not that Oracle seems to care to address that demand, at least publicly - just recently they began supporting versions 6 of RHEL and OEL as server-side Linuxes. But there is certain demand for non-MS/Apple desktops, and one linked to commercial interest as well. I am not sure if OI/illumos can ride that tide, though. Maybe with some other terminal client technologies (ThinLinc, Wyse, etc)?.. //Jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Andrzej, Your vision is pretty much the same one I had. The challenge is this: Existing releng process and contribution process prevent anything from happening though. I would like to help to change that. How? On Fri, May 10, 2013 at 12:54 PM, Jim Klimov jimkli...@cos.ru wrote: On 2013-05-10 02:19, Garrett D'Amore wrote: There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. I would be entirely *unsurprised* if distro vendors like RedHat and Oracle simply *ditched* their desktop support at some point in the future -- its clear to me at least that folks aren't running those distros on the desktop. Well, Oracle does provide and promote SunRays, and while admittedly most of their market targeting is about VDI and access to virtual Windows desktops, there are many requests on the SRSS mailing list about adding support for server-side Ubuntu as the SRSS terminal server, because certain apps only exist for Linux and tunneling of connections makes their graphics lag, and RHEL/OEL/Solaris desktops are argued to be not so user-friendly (I have no opinion on this, to me X11 is a means to display more characters on screen than possible in a text mode). Not that Oracle seems to care to address that demand, at least publicly - just recently they began supporting versions 6 of RHEL and OEL as server-side Linuxes. But there is certain demand for non-MS/Apple desktops, and one linked to commercial interest as well. I am not sure if OI/illumos can ride that tide, though. Maybe with some other terminal client technologies (ThinLinc, Wyse, etc)?.. //Jim __**_ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/**mailman/listinfo/oi-devhttp://openindiana.org/mailman/listinfo/oi-dev -- Alasdair Lumsden http://www.everycity.co.uk EveryCity Managed Hosting Studio 18 Bluelion Place 237 Long Lane, London, SE1 4PU general: 020 7183 2800 support: 020 7183 2801 email: a...@everycity.co.uk Every City Limited Registered in England and Wales, No. 5689474 Registered Office: Roper Yard, Roper Road, Canterbury, CT2 7EX ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 10 May 2013 12:54, Jim Klimov jimkli...@cos.ru wrote: Well, Oracle does provide and promote SunRays ... Actually, if you check the SunRay forums people are getting the impression that Oracle does _not_ promote SunRays, and some of their sales guys are actively trying to dissuade people from buying them ... it's got to the point that a large number of the original users are getting scared and are moving away from them to something like a WYSE client instead. Apart from that and the changes in licenses that Oracle decided to levy retroactively on our old models when we bought new ones, I love them, they're great, they do exactly what we need ... but then we only need access to email, internet and openoffice. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 2013-05-10 14:11, Jonathan Adams wrote: On 10 May 2013 12:54, Jim Klimov jimkli...@cos.ru mailto:jimkli...@cos.ru wrote: Well, Oracle does provide and promote SunRays ... Actually, if you check the SunRay forums people are getting the impression that Oracle does _not_ promote SunRays, and some of their sales guys are actively trying to dissuade people from buying them ... it's got to the point that a large number of the original users are getting scared and are moving away from them to something like a WYSE client instead. Yes, that too. At least, they say that they invest more than Sun, release more often, and such blah-blah. As for licensing... maybe that's why I mentioned other terminal technologies ;) I heard about problems with sales of some other ex-Sun products - Oracle has little interest in meddling with small customers; often this means purchases of thousands of licenses. Smaller volume may be discussed, but needs approval procedures and is not guaranteed to happen. Many of largest national companies (in market share terms, excluding giants like banking and oil industry) have 2-3 thousand employees and don't really want to overpay twofold just to qualify for a minimum-sized purchase. It gets much harder with deployments which start as some departmental PoC with potential to scale onto thousands of accounts, but for the starter year would have just several tens or hundreds of users. I can understand how it can be cost-ineffective for a bureaucratic monster to have small customers... but why forbid partners to make it their problem? Then again, it opens the same niches for smaller players, including those which provide same ex-Sun technologies at a smaller price, or just make it possible to buy in small volumes. This monopoly actually promotes competition and innovation among scavengers who can feel happy about leftovers from a tiger's meal ;) my 2c //jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 2013-05-10 13:43, Andrzej Szeszo wrote: I agree with what Peter and Garrett wrote earlier. OI is lacking a clear vision. It should be different than other illumos distros' as well to avoid duplicating work unnecessarily. I think, OI could be illumos hacker distro, and: - carry on providing GUI support, good enough for illumos hackers to use it on their desktops/laptops - it could potentially be based on vanilla illumos-gate; few OI specific changes could be upstreamed or dropped - existing OI users should be able to do pkg update to get the latest bits Not radical or innovative at all. Different enough to what other distros are doing though (no GUI, own illumos-gate forks). Are there many (any?) OI-private deviations from illumos-gate? I thought it was built with the vanilla kernel already. Also, being a hacker desktop distro with access to all other software packages that are available to other distros does not change the fact that OI can be used on servers as well - efficiently, with same kernel capabilities, scaling ability, etc? The difference may be minute, such as compile-time flags for optimizations, default tuning, administrative models and the proper way to do things (i.e. zones in OI and SmartOS are AFAIK quite different logical models). Meaning, that while other distros might be more suitable and optimal for production servers with a clearly pre-defined purpose, such as a VM server or an app server or a storage server - built for that purpose, OI might run a desktop or a undefined-purpose server with possibly smaller efficiency but higher versatility, or admin-friendliness by means of having same administrative interface as on his desk/lap-top or just having the interface at the console of the only server in the small office, etc... maybe :) //Jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 10 May 2013 14:13, Jim Klimov jimkli...@cos.ru wrote: Are there many (any?) OI-private deviations from illumos-gate? I thought it was built with the vanilla kernel already. I don't believe that KVM is in the default Illumos kernel, but is in OI. I don't know whether the planned new Wireless stack is going in Illumos, or in userland, or would have been designated as an Implementer option ... Jon ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Orange Indiana?
What if we created a branch from the kernel that would then allow portability across all platforms. Kinda like the Motorola / Android / Ubuntu project they had a few years back. In the project they had 1 android phone that when placed on a dock was able to use the android kernel and run an Ubuntu desktop natively. Totally agree on the developer / sysadmin perspective that the daily driver just needs to work so I have used Apple in the past. Fed up with the walled garden mentality of the iPhone I started to look at the different brands and marketing approaches that have been used in the past to work on a project that would be affordable, have a commercial branch for support and be up to date. If (any of) the commercial branch(s) create changes within the code, they would be required to release the code after a grace period (thinking about monthly releases if viable so 32 days for the release of the commercial changes to give the open group ~ a month to add it in for the next release and those that wish to pay for the support services would have the improvements, patches and releases 2 months in advance if not added already into the open group) I would be open to discussion about starting a commercial group based on the Open Indiana / illumos platform. James R. M. Winter ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Orange Indiana?
Garrett proposed a Reference Distro around September last year that is pretty much what you suggested: http://gdamore.blogspot.co.uk/2012/09/the-case-for-new-reference-distro-for.html Jon ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Orange Indiana?
The question remains, if it really needs to be IPS based. Or if it can be SVR4 and CSW style pkgutil.net. If you read Garrett's mails he also asked this question from time to time, just the day before yesterday again. But rather than just getting lost in endless discussions, I rather continue with the long promised (delayed) x64 version ... Then you can better feel if it would be acceptebable to you (SPARC users can already test, but as far as I understand it, few of you still have a SPARC). The src and pkgdefs are here and I'm willing to release everything. Doing it properly by committing change after change into hg can take decades. So either I just create diffs or upload tar's or create a history-less hg or what you want. regards %martin bochnig http://svr4.opensxce.org/sparc/5.11/ http://opensxce.org/ http://wiki.openindiana.org/oi/MartUX_OpenIndiana+oi_151a+SPARC+LiveDVD http://www.youtube.com/user/MartUXopensolaris https://twitter.com/MartinBochnig ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Orange Indiana?
For what it is worth: CSW existed before OpenIndiana. I never understood why Sun refused to adopt something like pkgutil (or its predecessor), but insisted on re-inventing the wheel. Instead Sun created IPS from scratch (with a lot of inspiration from conary and Foresight Linux, which they were even meeting before they made IPS). Buy doing so, they also broke the Upgrade patch from all earlier Solaris versions to Indiana aka OpenSolaris aka Solaris 11. And for all this trouble and extra hassle they literally spent MILLIONS of Dollars and millions of hours of man hours.. I (and a few others) had _always_ warned Sun to to go this route, but all I got was laughter. Let me ask: Where is Solaris now, in comparison to 2007? How much market share has remained? I know, for Sun this discussion comes slightly too late: RIP. Well, they were not willing to listen. At least not when it came to things like IPS. But we here can still do what we feel makes most sense. This just as a thought. %martin ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Orange Indiana?
+1 for support another packages then IPS DEB for example. -- Best regards, Igor Kozhukhov On May 10, 2013, at 8:27 PM, Martin Bochnig wrote: The question remains, if it really needs to be IPS based. Or if it can be SVR4 and CSW style pkgutil.net. If you read Garrett's mails he also asked this question from time to time, just the day before yesterday again. But rather than just getting lost in endless discussions, I rather continue with the long promised (delayed) x64 version ... Then you can better feel if it would be acceptebable to you (SPARC users can already test, but as far as I understand it, few of you still have a SPARC). The src and pkgdefs are here and I'm willing to release everything. Doing it properly by committing change after change into hg can take decades. So either I just create diffs or upload tar's or create a history-less hg or what you want. regards %martin bochnig http://svr4.opensxce.org/sparc/5.11/ http://opensxce.org/ http://wiki.openindiana.org/oi/MartUX_OpenIndiana+oi_151a+SPARC+LiveDVD http://www.youtube.com/user/MartUXopensolaris https://twitter.com/MartinBochnig ___ 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] Orange Indiana?
ouch, forgive the types, I'm on the run ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Orange Indiana?
On May 10, 2013, at 9:27 AM, Martin Bochnig mar...@martux.org wrote: The question remains, if it really needs to be IPS based. Or if it can be SVR4 and CSW style pkgutil.net. If you read Garrett's mails he also asked this question from time to time, just the day before yesterday again. *illumos* uses IPS. That's not likely to change anytime soon, if only because the pain of changing packaging systems is too high a cost to bear. That said, its *easy* to make systems that take IPS metadata, and build binary packages in various other formats. Its been done many times -- IPS to tar, IPS to SVR4, and IPS to .deb. I've even written an image builder that parses IPS using shell scripts. Easy peasey. So a distro can choose whatever format they like. I recommend (highly) continuing to use IPS metadata as the source form, if only because it is the only packaging format that actually aims to completely describe the resultant end-system in parseable metadata rather than relying on scripting languages to help out. (SMF boot helpers notwithstanding….) This would mean that others could use the source formats to deliver whatever binaries they like. But rather than just getting lost in endless discussions, I rather continue with the long promised (delayed) x64 version ... Then you can better feel if it would be acceptebable to you (SPARC users can already test, but as far as I understand it, few of you still have a SPARC). Actually I suspect lots of us still have SPARC kit in garages, closets, etc. Just most of us long since turned them off due to poor tradeoffs. (High noise, high heat, power consumption. Low performance -- at least the sparc kit that most of us have laying around.) The src and pkgdefs are here and I'm willing to release everything. Doing it properly by committing change after change into hg can take decades. So either I just create diffs or upload tar's or create a history-less hg or what you want. Nice work Martin. :-) I like your style (delivering the work rather than discussion about the work. :-) - Garrett regards %martin bochnig http://svr4.opensxce.org/sparc/5.11/ http://opensxce.org/ http://wiki.openindiana.org/oi/MartUX_OpenIndiana+oi_151a+SPARC+LiveDVD http://www.youtube.com/user/MartUXopensolaris https://twitter.com/MartinBochnig ___ 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] Orange Indiana?
I would certainly be interested in a OpenSXCE x86_64. From: Martin Bochnig mar...@martux.org To: OpenIndiana Developer mailing list oi-dev@openindiana.org Sent: Friday, May 10, 2013 11:27 AM Subject: Re: [oi-dev] Orange Indiana? The question remains, if it really needs to be IPS based. Or if it can be SVR4 and CSW style pkgutil.net. If you read Garrett's mails he also asked this question from time to time, just the day before yesterday again. But rather than just getting lost in endless discussions, I rather continue with the long promised (delayed) x64 version ... Then you can better feel if it would be acceptebable to you (SPARC users can already test, but as far as I understand it, few of you still have a SPARC). The src and pkgdefs are here and I'm willing to release everything. Doing it properly by committing change after change into hg can take decades. So either I just create diffs or upload tar's or create a history-less hg or what you want. regards %martin bochnig http://svr4.opensxce.org/sparc/5.11/ http://opensxce.org/ http://wiki.openindiana.org/oi/MartUX_OpenIndiana+oi_151a+SPARC+LiveDVD http://www.youtube.com/user/MartUXopensolaris https://twitter.com/MartinBochnig ___ 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] Orange Indiana?
I use pkgsrc on SmartOS. I think it also works on OI, so I have no use really for IPS. Plus there is OpenCSW. From: Garrett D'Amore garrett.dam...@dey-sys.com To: OpenIndiana Developer mailing list oi-dev@openindiana.org Sent: Friday, May 10, 2013 12:00 PM Subject: Re: [oi-dev] Orange Indiana? On May 10, 2013, at 9:27 AM, Martin Bochnig mar...@martux.org wrote: The question remains, if it really needs to be IPS based. Or if it can be SVR4 and CSW style pkgutil.net. If you read Garrett's mails he also asked this question from time to time, just the day before yesterday again. *illumos* uses IPS. That's not likely to change anytime soon, if only because the pain of changing packaging systems is too high a cost to bear. That said, its *easy* to make systems that take IPS metadata, and build binary packages in various other formats. Its been done many times -- IPS to tar, IPS to SVR4, and IPS to .deb. I've even written an image builder that parses IPS using shell scripts. Easy peasey. So a distro can choose whatever format they like. I recommend (highly) continuing to use IPS metadata as the source form, if only because it is the only packaging format that actually aims to completely describe the resultant end-system in parseable metadata rather than relying on scripting languages to help out. (SMF boot helpers notwithstanding….) This would mean that others could use the source formats to deliver whatever binaries they like. But rather than just getting lost in endless discussions, I rather continue with the long promised (delayed) x64 version ... Then you can better feel if it would be acceptebable to you (SPARC users can already test, but as far as I understand it, few of you still have a SPARC). Actually I suspect lots of us still have SPARC kit in garages, closets, etc. Just most of us long since turned them off due to poor tradeoffs. (High noise, high heat, power consumption. Low performance -- at least the sparc kit that most of us have laying around.) The src and pkgdefs are here and I'm willing to release everything. Doing it properly by committing change after change into hg can take decades. So either I just create diffs or upload tar's or create a history-less hg or what you want. Nice work Martin. :-) I like your style (delivering the work rather than discussion about the work. :-) - Garrett regards %martin bochnig http://svr4.opensxce.org/sparc/5.11/ http://opensxce.org/ http://wiki.openindiana.org/oi/MartUX_OpenIndiana+oi_151a+SPARC+LiveDVD http://www.youtube.com/user/MartUXopensolaris https://twitter.com/MartinBochnig ___ 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] Orange Indiana?
Wow, there is some incredibly interesting reads in the mailing list lately. I have been following it with great interest. I have been giving it a lot of thought lately. And especially OpenIndiana. Let's begin with saying Illumos is great. And OpenIndiana has the potential of being great. But at the moment, it's clearly stale and needs some serious action to be revived. I strongly suggest either a re-branding of the name and a complete re-shuffle of management etc. Or the alternative is to fork the project (or someone to fork it) and call it something different. Because at the moment, OpenIndiana is simply dying a slow and painful death. Personally, I am seriously considering setting up a git tree locally, pulling in Illumos and getting to work on something new that could someday continue on where OpenIndiana failed. Because it's not only sad to see such good code wasted, but it's becoming offensive to fans of Illumos. Regards Chris Jones -- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.13 (GNU/Linux) mQENBFF6JoQBCADvrA07ocG4OJBaRfb3RkAQUlfadrW4wyT5jTWv8SY0tDVZsGqa zvsmpIm0pAA4/FtFb70Lo1c7DzITjPFw+iDhzL3sVKpHuvdl141EwtZobI0pYC8q LVDQI/3BQCNapiIaHCSPDtQnqa02hdiaFB2iaFfNU0MHVYqGRxfydn4Dpoocexn7 c4qFs6Fgz25WOcJ4tiRRyj8KZrfc2E8DRj5u4HNy1uBDp4Yl73PIActUySUbVsOx 4ZeO0dx7ODIDqtxxCG9mEmXJZzRUtIDdXlzztsE7ITSmysPVq65MAjeAOIG8Z0lp t0/KlMacKYb6HDEWLhnjNeHYlkZ54Kb1MnfxABEBAAG0JENocmlzIEpvbmVzIDxj aHJpc2pvbmVzQHVuaXhtZW4uY29tPokBPgQTAQIAKAUCUXomhAIbAwUJACdGHAYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQK91yhbSfkL+MaAgAgLWkxQqcc+V0 NkmkLtzb/Bb5XS23tarz08iY7GPimmWIQmWulrORT+JVmBVkg7MRzcvVEOXrlZcE Ttth/+sPDFufHXAE5bC4XDuSIcE7U2J4AOKKFyGfYnC220qXk+MHdBgfphtuagEH Lq8UN/od0t9cNrEnCLjRNm/lpu+R+JHW/6/C+Bd2PAHZ22ib1PfIIT8CM4oPs3lR ItZwzqjSlPZb4RP6i190mcLippJHFzCWdiQG03yI8+UIFj42gsJ8jGMfXOvSEt+J gcgXB2EnZfVFPLM5zkjsehxfjn0gB1SFML5i5ig40GKivKE3UhX5nv4gupGfrGGj xl4XGTaS3A== =sDOZ -END PGP PUBLIC KEY BLOCK- ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] May 18th (this year...): Launch date of OpenSXCE x86_64
Thank you Garrett, all. Ok, I don't like to dictate anything. Just try and C. Q: When will it ship. A: In the past I never held a single date, to make such predictions is usually difficult. This time, though, it is different, because during creation of the SPARC version, I modified all pkgdefs in advance always also for i386 and amd64, in the same source tree. So there is little guessing involved, as I had already compiled almost everything on x86 in October (at the then current state), and afterwards _always_ keept the pkgdefs in sync by definition, until in had to stop on January 30th. For example, before I continued with SPARC in October, I tar'ed everything over after the compile on x86. So the only real task involved: Move my disks containing the devel pool over to my prepared DualCore Celeron 2.4GHz (with Sandy bridge), re-build it, just make install -k'ing the SVR4 packages and also build JDS and its packages, the same accordingly for all gates. The only actual work is to fix a few packaging build errors , where it fails. So on those places where it was difficult to write the pkgdefs for x86 blindly, while I did this on SPARC. The 1rst part of the selfhosting work is also completed on SPARC, this actually had distracted me last week from continuing with x86. Now I identiefied the very files that are missing. However, this is not yet reflected by corrected pkgdefs. I think most of us find it more important to have something to run and test on x86. So let me suspend selfhosting, although only the last mile needs to be gone. All focus shifted to the May 18th release of our first x86_64 version of OpenSXCE. I won't have time to read/answer/write email. So the next thing you will hear from me is the download link, on May18th. p.s. Garrett: I fully understand why you prefer IPS as the basis in Illumos. Only to avoid a misunderstanding, OpenSXCE does not use IPS's manifests in any way. Here again, why: http://openindiana.org/pipermail/openindiana-discuss/2012-December/010921.html There would have been 2 fundamental approaches: Easy and tougher. The first would be to take all IPS manifests and convert them semi-automated to SVR4 prototype/pkginfo/depend files. And simply to keep all the new pkg sets and pkg names and dependencies just intact. This would certainly be nice and interesting. Maybe someone want's to do that, too :) However, this would break dependency resolution backwards compatibility to all legacy SVR4 packages in existance. For this reason, I neglected it. The second one was, to reverse-engineer everything back to the old times. And that's what I did. Not just for Illumos/OSnet, but for ___all___ consolidations. Not just to get old pkgdefs to build without failiure (where they are available), but also to re-assign more than 15 thousand (!) unassigned files to new pkgdefs (this number for Illumos ON alone!!!) Also it was necessary to take older G11N checkouts (just as one example), because we need the good old /usr/openwin internationalization stuff as well, for OpenXsun. Somebody can try it the other (way easier and million times more convenient) way. But then this breaks legacy SUNW* deps. tnx %martin ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
