Re: [osol-discuss] Re: priorities for additional Solaris consolidations
Richard L. Hamilton wrote: Common Desktop Environment (CDE) No plans to open source While I realize that's not under your control, has anyone approached TOG and the other contributing companies to at least consider it? The biggest obstacles to CDE are that given the overwhelming desire by both management most users is to migrate to JDS/GNOME, the motivation to spend the required effort to even figure out which parts we can release is small, and that there doesn't seem to much of a community to support it. (Part of the code in the CDE consolidation is wholly owned by Sun, and Sun is a co-owner of much of the rest. I don't know the exact details of the arrangement with the other co-owners, and if I did I probably couldn't comment. What they don't want to do is throw code over the wall and watch it fall flat on it's face with a resounding thud that everyone ignores - if there's no opportunity for community involvement, there's not much incentive to release. I wouldn't be surprised if we tried to work out something to take advantage of the existing OpenMotif community since even if CDE died completely, Motif will live for a very long time still due simply to the huge number of third-party applications that use it. If there was a similar OpenCDE community, we might look into contributing our changes, but it's not really a good idea to try to establish yet another open source desktop community and fragment the existing communities even further.) OpenWindows No plans to open source What do you mean in this case by OpenWindows, given that you already mentioned the X server itself (yet OpenWindows was once used to cover the entire desktop environment, from X server through GUI libs and basic desktop apps)? In Solaris consolidation terms, the OpenWindows consolidation was mostly EOL'ed after Solaris 8. The sole remaining package is SUNWolrte - the OpenLook Runtime Environment - i.e. just enough to maintian binary compatibility for existing Xview/OpenLook applications.See above comments for the obstacles to releasing this. (I wasn't involved, but think the previous throwing over the wall of the Xview source, followed by the complete ignoring of it, is exactly what they don't want to repeat.) Removing the OpenWindows name from the X consolidation components was actually one of my earliest tasks at Sun, as part of the effort to ease confusion over what was going away with the OpenWindows EOL and what was not. SPARC Graphics (OpenGL and device drivers)No plans to open source Ok, OpenGL isn't yours, but (give or take NDAs from hardware component vendors), the graphics device drivers presumably are. Only 5 of the SPARC graphics devices supported in Solaris 10 are Sun's: - SBus: TurboGX/TurboGX+ (cg6) - UPA: Creator/Creator3D (ffb), Elite 3D (afb), XVR-1000 (ffb3/gfb) - Custom (very rare): XVR-4000 (zulu) All of the PCI boards and all the chipsets embedded into Ultra/Sun Blade motherboards are OEM'ed from third party vendors (ATI, TechSource, 3Dlabs). You will probably get full source to cg6, simply because it lives in the ON X consolidations for historical reasons, and because it was mostly already released as the reference driver in the old Solaris Driver Development Kit. (At least some of the kernel driver seems to be released already - see http://cvs.opensolaris.org/source/xref/usr/src/uts/sun/io/cgsix.c ) I don't know what the obstacles are to releasing the X (i.e. 2-D only, non OpenGL) drivers for the Sun cards, but you wouldn't get support for most of the SPARC graphics devices people actually have. We may someday be able to modify Xorg to use it's existing opensource ATI 3Dlabs drivers with some of those devices, but have to be careful in how we do so. (If someone's looking for a project to take on in the community in X development, this might be an interesting area to tackle.) ISTR that getting the wheel-mouse support required both folks from the device driver development area and from the X server development area to work together; as long as those two are separate, community access to anything possible that has components on both sides might increase community understanding of how they work to the point of providing an external bypass to the scheduling and resource chokepoints that slow down efforts requiring components on both sides. (good luck untangling that sentence...) That was actually the mouse drivers, which live in the ON consolidation already released, and was simply because Xsun doesn't talk directly to mice, but gets events from streams modules that translate the specific hardware protocols to a common format - until those were upgraded, there was no way Xsun could see the events from the scroll wheels. (It's also why XFree86 already worked with PS/2 wheel mice, since it skips those and talks raw PS/2 protocol to the PS/2 mice, but uses the same modules
[osol-discuss] Re: priorities for additional Solaris consolidations
I've pulled together my preliminary thoughts on the relative priorities of open sourcing the other Solaris consolidations, and would like you all to comment on the list and priorities below. [...] Administrative Tools LOW Why LOW? I would think having those released would be quite helpful, esp. to those who might want to either enhance them or create variants that to their mind might be more approachable (isn't that the word currently in vogue?). What I'd personally like to see is a library of admin functions, fully accessible by eithe CLI or JDS-consistent GUI, the latter optionally logging its actions (configurably mandatory) and showing equivalent CLI functionality (like AIX's smit, not something I _like_, but something perhaps useful as both a single point of entry to various actions and as something that encourages the user of it to learn more). [...] Install: Rest of the consolidationMED I'd like to see the getbootargs command released (and made not just part of install, but part of ON as well). One can use it in site rc scripts (or presumably service scripts too) to decide whether to take certain actions that might increase reliability at the expense of hanging long enough that one might not want them in a problem situation. For example, in the last few days, I was thinking of probing in rcS.d for SAN online following power failure, in case the system came up before the SAN, and waiting until it did; that would avoid an fsck failure leaving one at single-user prompt. That might be desirable as the normal action, but because it would delay access to the single-user prompt, it might also be desirable to boot with some user-supplied arg (something like boot -s -- nosancheck) which the script would detect and take as an indication _not_ to wait, so one could investigate the problem. Something like that would on the one hand improve the chances of not requiring intervention in most cases, while still allowing it in case of additional problems. I've heard of other interesting uses in rc scripts for getbootargs. It's trivial enough to re-create its functionality, or to copy the binary off of an install CD, but why should people have to do that? It's potentially too useful in some situations _not_ to have readily available, IMO. [...] Common Desktop Environment (CDE) No plans to open source While I realize that's not under your control, has anyone approached TOG and the other contributing companies to at least consider it? If on the one hand, CDE is out of fashion and on its way out, then perhaps its value isn't what it used to be; and that would allow the burden of legacy support to gradually become self-support. On the other, were it opened, there are a number of enhancements that would be fairly easy to add; documented functions to do some of the things that are private between dtstyle and dtwm/dtsession (via libDtSvc, typically), that would allow various useful functionalities. I have a utility I wrote that allows one to issue dtwm f. commands from the command line; most useful is a dtwm reset for those cases that one might want it in a script, such as after editing dtwm-related resources; it doesn't use undocumented functions, but rather does the same X operations as they do; or like a command that fetches and resets the screen saver list from the command line. Another thing that might be possible were it open is to allow full-screen JPG per-workspace backgrounds to be properly integrated (can be achieved now outside of dtstyle by retrieving the windowid of the backdrop window and using something like xloadimage that can be given a windowid). Anyway, there's clearly lots of potential for improvement too. I do notice that Motif-based apps _still_ seem to be 'way smaller and faster than GNOME-based apps at this time. Now perhaps, the corporate types want to invest in improving GNOME, and I certainly don't have a problem with that. But as long as legacy apps exist (and we all know they never _all_ go away), there will be those few that favor the CDE environment. There may not be enough to justify corporate spending for ongoing enhancements, yet still enough to support a community that would be able to get it done themselves if they had the opportunity. [...] OpenWindows No plans to open source What do you mean in this case by OpenWindows, given that you already mentioned the X server itself (yet OpenWindows was once used to cover the entire desktop environment, from X server through GUI libs and basic desktop apps)? Assuming you mean the OpenLook-specific libs and apps, most of the libs other than OLIT (which I understand was an ATT and/or USL or Novell creation, therefore perhaps not yours to release :-( ) have already been released, albeit not necessarily current relative to the latest maintenance on them. Wouldn't hurt to put out current versions of
