Hello, Just my notes:
See: http://www.guug.de/veranstaltungen/osdevcon2007/slides/marTux___OSDevCon2007.pdf http://wiki.openindiana.org/oi/MartUX_OpenIndiana+oi_151a+SPARC+LiveDVD http://www.oracle.com/technetwork/systems/opensparc/index.html http://www.oracle.com/technetwork/systems/opensparc/opensparc-operating-systems-1544128.html 1. SPARC Servers (a) - Sun SunFire V480 Server or higher requested. UltraSPARC T1 or higher are highly preferred. 2. Hosting (b,c) - There are a few organizations, ISVs, and academia that already host 'hundreds' of SPARC servers. 3. Shipping - Not an issue for most real SPARC host providers and sponsors. They already have legacy and some modern hardware. 4. Support - Tongue in cheek, it is much easier to support existing SPARC hardware than 'off-the-shelf' PC hardware. 5. LiveCD/DVD SPARC distro - Existed through the Martux project for over EIGHT years. I have the older 0.1 Live DVDs >=Y2006. 6. SPARC emulators - See OpenSPARC project 7. Resources (human) - Illumos/OpenCSW/GSoC/etc? Host provider maintainer(s) can take care of most things. Note on shipping: Mostly I see this as donating hardware to organizations and ISVs wanting to help and willing to contribute on a serious level to provide software on SPARC-based platforms. If I get some funding, I can install/rebuild/ship servers 'anywhere' in the world. Note on professional hosting solution providers/human resources: Most hosters provide automated Solaris administration tools and staff expertise allowing them to provide a comprehensive approach to managing business-critical Solaris environments. Is the Illumos-based SPARC port healthy? Define your benchmarks of health. Now, modernization. The OpenSXCE SPARC distro can provide a more recent Illumos_gate b13e6c26bd03 kernel userland snapshot. A recent monthly snapshot is already included and can be updated through the project's repository. This can also become a weekly or nightly build of the distro (or on demand through web request) for personal development or bug testing purposes. A 'no fluff' snapshot version with just GRUB/GRUB2 bootloader and the Illumos kernel userland can be reviewed, tested, and discussed - keeping it simple. With such talents from the key distro providers and key partners, SPARC 'may' be on the brink - but this is not the Titanic... Also, keep in mind most ordinary developers/advocates don't have (1-8)x(4-16)-core x64-based workstations/servers either. Those eight physical x64-based CPU motherboards are still quite expensive for most people.... Hope that helps... ~ Ken Mays ________________________________ From: Garrett D'Amore <[email protected]> To: "[email protected]" <[email protected]>; "[email protected]" <[email protected]> Sent: Monday, January 28, 2013 11:06 AM Subject: [developer] Status of SPARC I'm sorry to open a thread that I'm sure will cause a lot of discussion most of which will probably be fruitless and pointless. And yet, I feel compelled to do this. Please think before you respond, and only reply if you have some thing useful to add to this conversation. Recently, I advocated (as in RTI advocacy), a change to a program - kstat. After I integrated this change, another advocate pointed out that the SPARC port was broken by this otherwise worthwhile change. In that particular instance, the advocate took it upon himself to fix the problem. However, its clear to me that this particular advocate (Richard Lowe) may be the only advocate with regular access to SPARC. Its also clear to me that the vast majority of ordinary developers lack such access to SPARC. SPARC is on the brink. There in the past have been numerous offers of SPARC hardware. However, as far as I can see, these offers have come without any hosting, or even shipping to get the hardware to somewhere where it can be useful. Historically, if a SPARC problem arose that broke the build, the change would be backed out. Sun engineers were expected to build and test their changes on both architectures before integration. illumos has never had this requirement, because we have always understood that most developers don't have SPARC access; but we have still tried hard to keep the SPARC port working. Now the choice is not mine to make alone, but I'm going to strongly advocate that we simply stop making that effort unless sufficient SPARC resources are made available to keep the port "healthy". The resources that we need: a) Hardware - we need at least three fairly decent configurations (4 CPUs or better ideally) -- a build system for advocates, a build system open to all illumos developers, and a reservable "test" system. (A sufficiently beefy system - e.g. a 12 way system, could be used to serve both of the build system needs, but I'd still prefer two separate boxes if possible.) In the past there have been many people who have offered to donate -- in some cases pretty high end -- SPARC hardware to illumos. We've failed to find a location for it though. b) Rack space for the systems, with sufficient power, cooling, and network bandwidth for 24x7 operation. We also need remote console access to all three systems, and ideally some kind of remote power control for at least the test system. I think we should like to see a 12-month commitment to keep these things running; we don't want to go to the expense and trouble of setting them up only to find we have to vacate a few weeks later. Recognize that two of these systems are going need very wide access to allow any illumos developer to have access. (We'll do some basic validation of email addresses, and use public key SSH authentication, and we an even arrange for a "click to agree" legal agreement process before granting access.) c) If "a" and "b" are not co-located, then funds to ship the servers to the hosting location. d) Human resources (administrative) to perform basic system administration and setup of the above resources, including a calendaring system for managing the test reservations. I *suspect* that this is the one resource we will find in plenty once the others are answered. So please wait to reply to this until we see if a - c are forthcoming. So, if we don't have these resources, and nobody is able to provide them, then I believe we don't have the resources to keep the SPARC port healthy, and I don't think we should continue to try. In such a case, I'll recommend that we consider SPARC a secondary port, and not consider its functionality in deciding whether to integrate new changes or not. (That said, I think we'll always be happy to accept fixes for SPARC from volunteers who submit them with documentation demonstrating that they have tested such fixes, but I imagine that SPARC support will quickly degenerate if we stop requiring SPARC functionality to work during the RTI process.) I do know that some people have been working hard to get a viable SPARC distribution going. My hat is off to those people. I don't know if we yet have such a distribution. I know no small level of effort has been invested there, and it is not my intention to denigrate that effort. But even if everything worked perfectly for SPARC today, without the above resources I don't think we can truly consider the SPARC port healthy. We need to be able to point developers at resources that they can use to fix and test their code for this platform. Without that, its not fair or reasonable to insist that all changes be correct on SPARC. Nor is it fair or reasonable to ask the single RTI advocate (who by the way is also the only RTI advocate who doesn't get a paycheck for illumos related work!) to maintain this port all on his own. In the past I tried be a middleman for this conversation -- it didn't work out so well. Lots of offers for hardware came, but nobody with resources to host them, or an ability to ship hardware to the destination. So instead I'm going invite folks to discuss and solve the problem here. I think its more likely that a solution will come in an open forum. And if a solution can't be found here, then it will be obvious to everyone, and hopefully nobody will think worse of us if we then decide to reduce our commitment to what will at that point be obviously an unsupportable platform. (A brief note about simulators: there are some SPARC simulators. I'm not aware that any of them are capable of running illumos. If they were, it would be a huge boon to illumos and SPARC platform support. However, because hardware frequently differs from emulation, I don't believe the existence of such a simulation eliminates the requirements I've stated here for a healthy port. It *would* mean that there would be a reduced demand for the build systems, I think, and less frequent use of a remote test system, but I think we would still need these things to be available to the community to keep the port healthy.) Thanks. - Garrett ------------------------------------------- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21175186-163ec15a Modify Your Subscription: https://www.listbox.com/member/?&; Powered by Listbox: http://www.listbox.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
