> 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 consolidation MED 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 AT&T 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 what has already been released IMO, nor perhaps to release the deskset apps for those who wanted to self-maintain. I'd go along with LOW, but to the extent no new rights have to be obtained, don't see the point in "No". > 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. You guys have mostly gotten out of the business of creating your own graphics chipsets, so presumably you don't have the dubious excuse of closed source to protect trade secrets. Some of these might be useful either as models or to provide some insight into how to access hardware capabilities (3D acceleration, for instance) from open alternatives (like Mesa). IIRC, some skeletal bits&pieces may have already been released on the developer site; if they were fleshed out a bit (and other dribbles here&there such as on the developer site were brought under the same license as the rest of OpenSolaris on a general basis wherever possible!), it might enable some suprising benefits. 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...) This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
