Hi Jim - See below. On Sun, Jun 10, 2012 at 7:36 AM, Jim Klimov <jimkli...@cos.ru> wrote:
> Hello, David et al, > > Renaming the thread and moving to another mailing list, > because it is no longer about printers, and possibly of > small interest and big distraction to actual developers, > and seemingly not about the OpenIndiana distro - as the > discussed matters are between orthogonal and contrary > to objectives and resources of the OI project. > > 2012-06-09 9:31, DavidHalko wrote: > >> On Jun 8, 2012, at 12:19 AM, Darren Reed <darr...@fastmail.net> wrote: >> >> On 8/06/2012 10:10 AM, Jim Klimov wrote: >>> >>>> ... >>>> “There’s a huge installed base of Sun hardware out there in datacenters >>>> around the world, billions of dollars worth of equipment, and Oracle has >>>> basically given it the finger.” – Garrett D’Amore >>>> >>>> “Oracle has removed sun4u from Solaris 11. So there is no sun4u support >>>> in Solaris 11, which means that there is this huge amount of hardware, this >>>> installed base (anything earlier than a year or two ago) that can’t run, >>>> will not run Solaris 11 at all. And that’s a huge Illumos opportunity.” – >>>> Bryan Cantrill and Adam Leventhal >>>> >>> >>> Whilst Garrett is right, I think that Bryan/Adam misunderstand the >>> future. I think that you'll find that the huge Illumos opportunity will >>> turn into a huge Dell/IBM/HP opportunity. At least that is what I hear is >>> happening in the marketplace today. >>> >> >> The SPARC software will not run on Intel. The last revs of Solaris 10 is >> almost here? There are no Solaris 8/9 branded zones on Solaris 11. Legacy >> software meeting business and telco requirements (sometimes worth millions >> of dollars) are stranded. >> > > If millions in software work, performance does not matter. > > As, likely, power drain does not matter there either? ;) > No, human support capital is more. Sun learned that with the release of the T1. > Even 1000$/mo in power is dust in comparison to these systems' > "value" for their owners. And, likely, a negligible speck in > their budget as well. > Different budget. > Adding observability (DTrace) and other numerous goodies of > OpenIndiana to those old systems may be invaluable (i.e. why > not leave things running under Solaris 8/9/10 as long as they > work?)... > OI would make a better hypervisor for Solaris 8/9/10, if it could also be a hypervisor for other legacy OS's in the same datacenter. One OS to run them, with support is a better pitch to a CIO than keeping a bunch of old legacy OS's around, especially if it all becomes more portable. As long as there is no reason to run Illumos in the data center, it will >> never appear there. This makes Illumos an huge embedded OS with no future. >> If Illumos can absorb, with branded zones, all legacy systems - it gets >> into a datacenter as a real platform, because it meets business >> requirements - it runs business critical software. >> With an OS infrastructure similar to legacy systems and features similar >> to Solaris 11 - it could be the best of all worlds in a hard economy. >> Certainly can be justified on a 3 year business plan. >> ISV's looking to hawk software developed on existing systems get another >> half decade of life of software support to charge to their customers, if no >> changes required. >> With a centralized standard SVR4 package repository, commercial vendors >> can have a new marketplace they did not have access to, with existing >> packages, encouraging future support of Illumos by those ISV's. >> > > That is a nice pitch, I think (and hope). > It can be used to keep SVR4 systems from being migrated to Windows & Linux. It can open up an opportunity for OI. But you do talk about two distinct projects of different > difficulty and engineering expertise - SPARC support > (including older CPUs and likely drivers for old Sun > hardware of different scale), and SVR4 distro support > (likely with LU or a similar mechanism). > Yes. There needs to be a distribution interested in commercial support of encapsulating legacy systems under Intel and another for SPARC. Video drivers are not so important, since the scope is primarily server based applications. (If the structure is not too different, perhaps OI could leverage old HBA & Ethernet drivers?) > Things like JumpStart for installation of such new OS > from scratch might not be primary objectives, for example... > or should they be, indeed? > Or perhaps, the marketing jargon should be "Virtual Appliance" - to get them into a data center: [T1-T4] LDom's, [Intel] VMWare instance, not sure what to do about sun4u. Somewhat separately, to my understanding, stands the problem > (and desire) of sparse-root zones. I.e. they are not used in > branded zones (for direct import of s8-s9-s10 systems into > zones, and s10/osol zones into zones). They might have some > use for the described ISVs if we support upgrading such > systems into SVR4 zones with current software, but it is > unlikely that expensive mission-critical legacy software > will be taking this route (upgrade maybe, sparse unlikely). > There are more sparse root zones in the data center I am thinking about than any other kind of zone. If this can be encapsulated, this offers greater opportunity for those Solaris 10 systems, which have little hope of future features. > Regarding SVR4, it is questionable whether new installations > should be allowed, or just a mechanism for import/upgrade of > existing ones (Sol 8/9/10 and OSol SXCE) would suffice? > It would really be nice to be able to perform an fresh install, add a zone, convert a zone into a specific "branded zone" using all existing Illumos binaries plus run a special loader to scan floppy, cd, tape, nfs, etc. to install only SVR4 packages required to complete the environment: i.e. install_unixware_#.#, install_mpras_#.#, install_sco_#.#, install_solaris_#.#, install_redhat_#.#, install_attunix_#.#, etc. A P2V for legacy systems seems reasonable. Capture everything, from MAC, IP, NIC, etc. - move it over: P2V_unixware_#.#, P2V_mpras_#.#, P2V_sco_#.#, P2V_solaris_#.#, P2V_redhat_#.#, P2V_attunix_#.#, etc. The above two items are something that pretty much any systems administrator can do. > Even so, a new distro could be made like today as a LiveCD > which installs an SVR4 package-based pre-made image, and > that can then be upgraded like any other supported image... > The method of laying down of SVR4 packages in the initial install may be irrelevant. SVR4 moving forward is more of the issue. Flash archive, LDom image, http boot from OpenBoot, tape, cdrom, etc. may all be fine. This does not preclude use of beadm for subsequent systems > lifecycle maintenance, and LiveUpgrade in SXCE also had > support of ZFS-based BEs. > Agreed. ZFS with boot environment administration is needed. > It does sound like an interesting project, especially if, in keeping > the best of all worlds, you can keep compatibility with OI. > I would think so. > I mean it would be beneficial to have the new project > just a differently-packaged set of the same binaries, as > well as have the new project support ipkg-based zones. > SVR4 packaging is pretty much in stone... it is a standard and no one else is driving updates. A consortium of distributions (including OI) and software package providers can drive it. The ipkg format is in flux and Illumos might not get future updates from Oracle. Will Illumos developers really invest engineering effort to support a moving target defined by Oracle, when they have no control over it? I doubt it, ipkg might remain as a pre-Solaris 11 release, making it a 100% proprietary solution. Seems dangerous to even suggest, from a sustaining engineering point of view. ISV's will never buy into it ipkg until is more mature. The decision for ipkg limits penetration into future markets, on the short term, while extending SVR4 (with full backwards compatibility) merely keeps markets open. > Ideally, all needed code changes would be pushed up into > illumos and OI as appropriate, and making of the new distro > would be just a use of another make target to get a LiveCD. > We really don't need another distro. We need existing distro's using what we have, commercial support, a larger market base (drawing legacy systems into orbit), and a vision for the future. SVR4 already has HTTP proxy for network distribution - we have to use it. That would generate SVR4 packages equivalent-to-OI based > on the same source repo; and in terms of going forward - it is > likely better to adopt the transformation of pre/post-scripts > into SMF methods (as long as old SVR4 packages seemingly > went this way already to become IPS packages - that should > not be undone). > Existing third-party SVR4 packages need to be accommodated, possibly discourage use of pre/post install/remove scripts, for new packages. Possibly add SMF intelligence into SVR4 packaging format with new tokens. Some good examples on auto-configuration of packages via SMF > (replacing postinstall scripts) can be found in Tim Foster's > blog posts about "IPS self-assembly": > https://timsfoster.wordpress.com/category/opensolaris/ > This is a good resource. Finally, I hope that you'd find interested ISVs and ISPs > and other parties who would support this project so as to > make it more interesting to illumos/OI developers to work > on such changes. > There are more than a few groups who seem interested so far. Do you have a plan? Perhaps, a draft page on the illumos Wiki? > http://svr4.blogspot.com/ > What are you trying to achieve and what are you not > trying to achieve, and what would you prefer to avoid in > this project? I want fast results. I need a Proof of Concept. Tthe writing is clearly on the wall, yet it is taking longer than what I expected. I would like to see a viable [OpenSolaris based] distribution, which offers security patches for [paid] commercial consumption, which uses a standard [existing SVR4] packaging system, which can offer third-party [freeware and commercial] packages, and offers security patches for [paid] commercial consumption. Distributions would offer [legacy initially with future] SPARC and Intel support, possibly act more as a hypervisor, leveraging branded zones for legacy SVR4 system encapsulation. Final product could be used by data centers to better leverage existing systems, migrate legacy OS-App systems to new hardware, migrate legacy OS-App systems to cloud providers. I would like to solicit several commercial Network Management vendors to port their software, if we had a viable distribution (with support) and packaging vendor who would provide a distribution channel for SVR4 packages. Not trying to achieve? Not looking for an large, long, or expensive - the world has Solaris, AIX, Windows, and Linux. SVR4 needs more than an embedded ZFS server and more than an embedded OS for Oracle database server. Sun & Oracle needed Solaris. SGI dumped Irix, needed Nexenta (which is now pigeonholed as storage.) HP needs a NG-UX. Illumos based distributions can clearly be more, but not on this track. Perhaps, in phases or milestones? > Phase 1: determine: sympathetic distributions; sympathetic package and source code repositories; determine initial feature list; release interval Phase 2: agree upon SVR4 conventions, possibly extensions Phase 3: agree upon updates, make changes, push changes to source code repository Phase 4: build SPARC and Intel distribution; build package repository Phase 5: automated diff patches from previous revision Phase 6: gather features requests, repeat phase 3 at regular interval We need a destination, a train, and passenger cars. Without all 3, no one will pay fares. Thanks, and good luck, > //Jim Klimov > Thanks - Dave H http://netmgt.blogspot.com/ ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
