OpenSolaris

Solaris Desktop Gap Analysis

Important Note

The contents of this document are my views and the recommendations are what I would like to be done to close these gaps in OSD on Solaris/OpenSolaris. I hope to keep this as a live document and as such none of these recommendations are set in stone and are prone to change as new information comes to light.

Table of Contents

• Introduction
• Enhanced Core Desktop
  • Volume / Removable Device Management
    • Mass Storage
    • Digital Cameras
    • Digital Media Players
    • Mobile Phones
    • Scanners
    • PDAs
    • Bluetooth
    • Webcams
  • Remote Filesystems
    • CIFS Mounting
  • Performance
    • File Event Monitoring vs. Polling
  • Multimedia
    • CD / DVD Support
      • Authoring
        • Nautilus
        • Other Applications
    • Audio / Video Playing
      • Video DVDs
    • Enhanced Audio Device Support
  • Collaboration
    • IRC / Instant Messaging
    • VoIP / Video / Whiteboard
  • X Server Hardware Acceleration
    • Open GL
    • Cairo
  • Other Applications
    • Security
      • Privileged Operations by User
      • Secure Services
      • ACL Support
      • Encrypted Filesystems
      • Trusted Desktop
      • Firewall Configuration
    • PDF Reader
    • Applets
      • Keyboard switcher
• System Management & Administration
  • Basic Functionality
    • Networking
    • Wired / Wireless Ethernet
      • Modems / Dial-up
    • Power Management
    • Keyboard Configuration
    • Printing
    • Process Management / Monitoring
  • Advanced
    • Virtual Consoles
    • X Configuration
    • Remote Administration
    • Software Installation / Updating
    • ZFS
• Developer Support
  • Compilers and Tools
  • Mutiple Operating System Support

Introduction

Almost a year ago I wrote a document called the Solaris Desktop Gaps - in that period a considerable amount of work has been done both within Sun and in the OpenSolaris.org community. While many things have been completed, there are also areas which are just too complex to solve in just 1 year, but things are well underway to answering some of our biggest needs. This document has now been updated with some of the latest information available to us at the time of writing, with the intention of providing people with an over view of how far we've come, but also how far we still need to go.

As last time, we are comparing ourselves with the current leaders in the desktop arena, namely : MS Windows, MacOS/X and Linux, each with their own individual strengths.

Enhanced Core Desktop

For the average user, the core desktop is all they will ever really experience. In today's world people simply expect things to work, with minimal needs to configure - preferring that nothing at all needs to be configured. This is not an unreasonable request for a desktop user after all the majority of them will have at some time experienced MS Windows and Mac OS/X, both of which do it quite well.

Volume / Removable Device Management

There are very few people using a desktop that don't have at least one device in their possession that could be considered a removable device, which includes any of the following - USB memory sticks (a.k.a. mass-storage devices), Digital Media Players (iPod / MP3 players), digital cameras, PDAs (Palm / Pocket PCs) and even the most common of all, the mobile phone. How many do you have? Be honest.

In the majority of cases, there isn't even the need for additional device drivers for these to work - it is simply built into the operating systems default set of drivers - e.g. USB Mass Storage devices have pretty much totally replaced the need for floppy disks, in most but the most unusual circumstances, mainly due to their almost universal plug & play ability on almost any hardware bought in the last 5 or more years, maybe even longer.

On Solaris, this has been a painful experience in the past. Vold (the only volume manager on Solaris) has only recently (Solaris 10) been fixed to handle USB memory sticks. Vold has historically been so unreliable that many people disable it by default, preferring to handle devices using the command-line commands. But there is good news now....

In the latest OpenSolaris.org sources, and in a soon to be released Solaris Express distribution, you will find that vold is no longer present. It has been totally replaced by the Tamarack project. This project has introduced several new layers, based totally on the Free Desktop Foundation project called HAL (Hardware Abstraction Layer).

HAL provides a framework for the main desktop platforms (GNOME and KDE) that allows application developers to off-load much of the hardware dependencies to a single layer which would enable applications to iterate over devices on the system, but also monitor hardware level events in an OS independent way. HAL is built upon another Free Desktop project, called D-BUS, that provides a light-weight, asynchronous and, again, OS independent, IPC layer which forms the communication layer between the HAL daemon and desktop applications.

In the case of Sun Ray, a HAL backend will be provided that will enable HAL to dispatch events and provide information about any devices plugged into Sun Ray. It it currently thought that this will be provided by the SRSS software, and HAL will be able to pick up the library dynamically.

Building on this framework, GNOME Volume Manager (g-v-m) is able to provide the desktop with the ability to handle many types of removable media in a way that a user wants. For example, a user inserts their removable device, HAL sees this hardware event and translates is into a D-BUS message, this is dispatched and g-v-m sees the event, recognises it as a device being inserted and then based on the type of the device (which HAL attempts to discover) is able to perform a user-defined (or a default) action, such as mounting the filesystem on the device and/or starting the appropriate application to handle the device.

The Tamarack project also provides a desktop independent volume manager that will continue to provide the necessary support (as it has done in the past using rmmount) to handle devices like CD-ROM and mass storage devices so that they can be used on head-less systems or in other desktop environments like CDE.

Recommendation: 

 Now that HAL has been integrated and GNOME Volume Manager is able to work, we should ensure that all the supported hot-pluggable devices are well integrated with suitable default actions available to the user.

Mass Storage

Mass Storage takes many guises. Generally we are referring to USB or Firewire based devices that provide access to storage in either the form of flash memory (including a card-reader for SD, xD, Compact Flash, etc flash cards) or a hard-disk. This can also include devices like MP3 players that expose themselves to the OS as mass storage devices so that the music can be downloaded.

The general behaviour for devices of this type is to mount them as local filesystems and then the user is presented with a file browser window that is showing the top-level directory of the mounted device. Ideally it would be desirable to configure the post-mounting behaviour such that in the case of an MP3 player being mounted, a music organiser application could be launched to handle the files rather than simply nautilus - a similar case exists for digital cameras that are seen as mass storage devices.

As part of the Tamarack project, mentioned above, the filesystem recognition mechanism have also been improved in libfstyp library and the fstyp command. Some of this has been re-used in HAL's probing of newly plugged in devices so that as much information as possible is provided to the consumers of HAL on the desktop.

Recommendation: 

 As things stand, as of the latest OpenSolaris and Solaris Express builds USB Mass-storage should simply work.

Digital Cameras

I think that it is safe to say that Digital Cameras are here to stay - certainly this is the thoughts of many camera manufacturers, many of whom are seriously winding down their film based manufacturing.

User of digital cameras expect to be able to take pictures, and use their desktop to download the pictures so that they can be viewed, edited and even published on the web or simply sent in an e-mail to a friend. This has become such a common task that most operating systems support the minimum functionality of downloading all the images to a specific directory on the user's hard-disk.

The majority of digital camera manufactures have take the move to use the USB Mass Storage device's universal recognition as the main mechanism of providing access to images taken on their cameras. This is mainly because of the fact that it off-loads the need to have to provide device drivers to the various operating systems and as such makes the camera universally usable.

While this covers the majority of modern digital cameras, there is another protocol - Picture Transfer Protocol (PTP), ISO#15740 - that is also in common use. This PTP protocol is mainly used for inter-device transfers, such as between a camera and an inkjet printer (when combined with USB this is commonly known as PictBridge support), so that no computer is required.

From a desktop point of view, PTP is defined as being a universal protocol for transferring pictures between devices, where a computer is also known as a device. OSD provides support for the library libgphoto2 (which includes code from libptp2) is which provides basic PTP support on Solaris. Building on this Gtkam provides a GTK+ based application.

Previously in the original document, I mentioned F-Spot, a C# based application, written using the Mono .NET platform. Sun is still undecided about the inclusion of Mono as a supported platform on Solaris. There are many reasons for this due to the nature of Mono, but rest assured we are not forgetting about it.

Recommendation: 

 We need work on making the plugging in of a camera more seamless, at a minimum providing the automatic downloading of pictures to a user-specified location, but serious thought needs to be put in to a non-Mono alternative to F-Spot.

Digital Media Players

With the onslaught of iPod and other such devices, there is a lot of desire by people to be able to manage their music devices using their desktop. While it is possible to support these devices a purely USB Mass Storage devices, enabling people to simply copy the files to/from the device using nautilus, some people also want to be able to manage the music on the device - where by manage I mean to set up their play-lists, synchronise pod-casts, download new music, etc.

Sun is embracing the use of portable media devices - making podcasts of announcements, useful information and so on, available for RSS subscrption - e.g. Sun RSS Feeds/Podcasts. So we need to be able to handle all of this on Solaris.

Thankfully, there are open-source applications that could facilitate these devices - e.g.

• Organisers
  • Rhythmbox (Now Included in Solaris Express)
  • Cnomad2
  • Gtk Pod (iPod manager)
• Podcast Synchronisers
  • Rhytmbox also provides this, as well as being an organiser
  • jPodder (Java based podcast downloader)
  • gPodder
• Device Synchronisers
  • Cnomad2 - supports only the Creative Zen/Nomad devices
  • Gtk Pod (iPod manager) - supports only the Apple iPod devices
  • Nautilus (GNOME File Manager) - fortunately some manufacturers have seen that there is a benefit to using the almost standard USB Mass Storage mechanism for presenting their devices to the operating system, as such Nautilus can provide the necessary copying mechanisms.

While all of these represent some of the many options, none come near matching the seamlessness of the way that iTunes integrates both the on-line experience and the off-line (using iPod) experience. There is a relatively new project, called Song Bird, which is attempting to provide a cross-platform (currently supporting Windows, MacOS/X and Linux) using the Mozilla application framework. The aim, as they say, is to become the Firefox of media players... It has support for extensions, and one such extension is for synchronising with the iPod.

Recommendation: 

 We are now supporting, and including Rhythmbox in the latest OSD builds in Nevada, mainly due to its ability to both synchronise podcasts as well as organise things.

 In the latest sources for Rhytmbox, support has been added to for synchonising to the iPod using libgpod. We should provide this as a default feature of the Solaris/OpenSolaris desktop.

 We should also keep an eye on the SongBird project since it's has a lot of potential given it's cross-platform nature.

Mobile Phones

At present there isn't any suitable applications available that would enable Mobile Phones to be synchronised on Solaris, but should we manage to make the Bluetooth story work, then things might change here.

Scanners

Scanning images is quite a common task in many offices - this generally accompanies the use of an office suite to write up memos, publish newsletters, etc. In OSD at present, we ship Star Office as an Office Suite, and GIMP as an image editor, enabling scanners to work is still a missing link in the chain.

Scanners on Unix are best supported using the libsane library. This provides access to various scanners that are connected to a machine either via USB or SCSI.

The main UI for this is XSane, but it is also possible to get an Open Office.org component (http://www.openoffice.org) and a GIMP plug-in (from xsane) that would enable these applications to also communicate with the scanner, albeit in a more limited fashion than XSane.

The GNOME team are also seriously looking at this area, with some interesting work being done in the GNOME Scan project which was started as a project of the Google SoC 2006. There are some nice screenshots of this also.

Recommendation: 

 "libsane" should be available in OSD. This then provides the basic framework to enable other applications to make use of any attached scanners. XSane will give us an immediate result if delivered, but we should certainly also look at the GNOME Scan project and think about integrating it as well as integrating with StarOffice/OpenOffice.

PDAs

PDAs are everywhere, and people want to be able to synchronise their PDA with e-mail and calendaring applications on Solaris.

Palm support is quite good already, has been improved via the addition of USB support, and the ability to synchronise with Evolution.

Pocket PC, and SymbianOS devices are more difficult to support on Solaris, mainly due to the integration of the devices applications with their name-sake equivalent on the desktop (i.e. Pocket Outlook and MS Outlook, etc).

SyncML is another mechanism for synchronising devices. Originating on the Symbios OS, on the Nokia 9000 devices, it has now become more widely available on a number of other mobile phones, such as Sony Ericsson phones.

There is a considerable body of work under way to provide synchronisation for SyncML and Pocket PC based devices. The main UI for this would be called Multi Sync, which is a GNOME based application, that is build upon the Open Sync framework, which was developed originally as part of the Free Desktop group.

Using OpenSync we could getin support for devices like:

• SyncML and IrMC capable devices
• Nokia cellphones
• PalmOS based devices
• Windows CE and PocketPC based devices
• Handhelds using GPE and opie.

The complete device compatibility listing is at : http://www.opensync.org/wiki/DeviceCompatibilityList)

Synchronisation with several applications is also already supported, namely:

• Evolution's calendar addressbook todo
• Google-Calendar
• SunBird.

Recommendation: 

 Solaris/OpenSolaris is still in need of a suitable solution, but OpenSync appears to be the correct direction to go for synchronising with desktop applications, so we need to look at making this work well on Solaris/OpenSolaris.

Bluetooth

Many personal devices (PDAs, Phones, etc.) support Bluetooth as a communication protocol. This has replaces wires during the synchronisation of these devices with laptops (many of which have bluetooth built-in as well).

Solaris currently lacks the necessary hardware drivers (kernel modules), but if they were to become available, then the Linux based BlueZ project would be capable of providing the necessary Bluetooth stack at the protocol level and above.

The good news, is that Sun are seriously considering how to provide Bluetooth support on solaris. The initial plan would be to provide the low-end of the stack, such at: HCI support (Mice/Keyboards), L2CAP protocol stack. The next step would be to expand this to provide RFCOMM, the SDP protocol stack and provide profiles for various device types.

It's going to take time to get Bluetooth into Solaris, but we in the desktop arena should be ready for this, in as far as we can be. On the desktop, there are several areas that need to be looked at:

• GNOME Bluetooth Tools
   These provide much of the basic functionality for browsing a device, and interacting with it, such as transferring files over to a device (e.g. pictures in a Picture Phone).
• Nautiilus Send-To...
   This adds a new entry into the context menu in Nautilus - which allows you to send a file somewhere. While it is not specific to bluetooth (it can also send to e-mail or IM tools) - it is useful to downloading files to a device.
• GNOME Bluetooth Control Remoto
   This allows you to control your desktop using your phone - the most useful tool here is to be able to control a presentation in OpenOffice...

Recommendation: 

 I would think we should definitely provide Nautilus Send-To now, why wait, it is certainly a very useful mechanism. As things come together then at the base OS level, we can start the then look into extending support using the GNOME Bluetooth Tools - while the GNOME Bluetooth Control Remoto tool is probably a stretch.

Webcams

Webcams are needed for video collaboration (covered elsewhere). To enable people to be able to see each other, then Solaris needs to be able to provide for the ability to download video from a webcam.

Previously I mentioned that a student at "University catholique de Louvain, Belgium" had worked on a USB based webcam driver that supports the Phillips Webcams. The drivers group in Sun have picked this up and productised it, so that it can be integrated into Solaris.

Once we have Webcams working, we can then proceed to enable Ekiga to use them, providing us with a more complete story with respect to collaboration on Solaris.

Recommendation: 

 Once the Webcam support has been integrated into Solaris, Ekiga should be enhance to use these when present on the system.

Remote Filesystems

A core element of Solaris is its ability to enable filesystems to be centralized, and hence remove from the users regular desktop. The ability to access remote filesystems becomes even more important for the roaming user.

CIFS Mounting

For a Unix only environment, NFS is very capable of dealing with the needs of the desktop user, but in a heterogeneous environment this breaks down, especially if MS Windows Servers are involved. MS's support for NFS is quite poor, and quite unusable for a large volume of Solaris desktop users. So if Sun are to be able to successfully replace MS on the desktop in such organisations, it needs to be able to inter-operate well with the MS windows file sharing protocol - CIFS.

CIFS is the underlying protocol used when a MS Windows server shares a filesystem.

While we have Samba, and its underlying technologies for browsing the network and sharing files in a FTP-like way - to r�eally be able to inter-operate successfully, we need to be able to mount a CIFS on the user's desktop system - this requires a kernel driver and modifications to the CLI mount/umount, etc to be able to work.

There is an OpenSolaris.org project for this that is targeting the integration of a CIFS client into Solaris. This will allow for the mounting of CIFS network shares on Solaris. Considerable effort is being put into synchronising identity with Active Directory, as well as allowing for a single mountpoint to multiplex the users of the mount correctly to preserve security.

Recommendation: 

 When the CIFS driver is available, we in OSD should ensure that we are able to work with it seamlessly - browsing such file shares, and allowing users to mount them and use them.

Performance

File Event Monitoring vs. Polling

The current implementation of File Alteration Monitor on Solaris makes use of polling (a configurable frequency is possible). But generally this means that if you, for example, are browsing a directory in nautilus, and a file in that directory is removed, or a file is added, your view of that directory in nautilus won't be updated until the next poll timeout. This generally means that there is an inconsistent view. This can also apply to the viewing of a files properties - if you are monitoring a file's size, you won't see the size updates until after the poll-timeout period. Polling also wastes system resources stat-ing directories and the files there-in to see if there has been any update - this could be potentially very expensive in a directory with a lot of files.

Since the introduction of NFSv4 in Solaris 10, a new kernel level module was provided in Solaris, called the File Event Monitoring API (FEM). This kernel API enables other kernel modules to monitor file activity by intercepting file system modifications at the v-node level. Because of demands from OSD, and others, a userland API is being developed to enable applications and their libraries to make use of this functionality.

There are several user level APIs that many people use, two of the most common in the GNOME desktop are:

• File Alteration Monitor (FAM) - developed by SGI originally it was one of the first such libraries, and it went on to be one of the most common implementations in use.
• Gamin - Gamin attempts to provide an API that is compatible with FAM, but also provide some reduction in memory consumption and security needs to make it more compatible with SE/Linux.

Work is currently under way to expose the kernel FEM API in to userland using the event ports mechanism in Solaris. This will allow for the monitoring of files and hence enable the porting of FAM or Gamin to Solaris.

Java is also working on integrating JSR#203 - the ability to do this is important to being able to provide a complete implementat of this Java API on Solaris.

Recommendation: 

 When FEM has been exported to userland, Gamin should be ported to using this API instead of the polling mechanism currently being used.

Multimedia

Playing of multimedia (audio and/or video) is an often discussed topic. Everyone wants to be able to support all the possible formats, but due to licensing issues on common codecs, it is a nightmare on any platform but MS Windows or MacOS. Quite a few of the mostly used codecs (the piece of the application that decodes the media file) are MS Windows or MacOS only - e.g Quicktime, Windows Media formats, etc. While there are other file formats which are "open" they aren't as widely adopted. If nothing else, Solaris should support as many of these as are reasonable.

CD / DVD Support

Authoring

Many recent machines come equipped with a combination CD/DVD writer. And with larger and larger volumes of data being stored on hard-disks, then it is important that people be able to at least backup their data.

Currently Solaris has much of what people need to be able to achieve this at the command-line level with tools like:

• cdrw - usable for CD and DVD burning.
• DVD+RW Tools - for creating DVDs
• cdrtools (incl. cdrecordPro) - usable for CD and DVD burning.

Unfortunately the GUI side of this is not quite as rich, with the only GUI available in OSD being Nautilus CD Burner, which is extremely basic.

While authoring a CD is generally quite simple, authoring a DVD can be a little more difficult when you want to create more than a simple Data disc, it is possible for DVDs to have a more complex structure - especially if you take into account the ability to create a Video disc for playing on home DVD players.

While nautilus will provide some of the functionality that people want, others like more control, especially if you want to even slightly vary the way an ISO image is created - is it HSFS, Joilet, Rockridge, or some hybrid, etc. From this perspective, there are a couple of options available. Again, most of them are layered upon the cdrtools and/or dvd+rw tools packages.

• GNOME Baker - Is in active development, not at version 0.6.0, with constant updates occurring - its plans for the future include the ability to write video and stills to CD/DVDs.
• Brasero - also known as Bonfire, is a CD/DVD mastering tool, now being hosted at GNOME.org, it is at version 0.5.0 now.
• K3B - This is probably one of the most used CD burning applications on Linux, but it is written using KDE's Qt library rather than GNOME's GTK+.

Recommendation: 

 We should do some detailed analysis of GNOME Baker and Brasero, comparing the two and pick one of them for inclusion in to Solaris/OpenSolaris.

Audio / Video Playing

In the latest Solaris builds, the multimedia solution was supplied by a mix of GStreamer-0.10 (with GUIs Totem and Rhythmbox), Real Player and Java Media Player (JMP). Each of these supports a different set of file formats.

Real Player, based on the Helix community, was introduced into Solaris within the last year or so. This covers several file formats - for playing only, but it also doesn't allow for conversion between file formats, to do that you should use GStreamer or JMP.

Originally, because of licensing issues, it was not possible to include MP3 support in GStreamer 0.8, but with GStreamer 0.10 Fluendo wrote a new MP3 decoder which was free from the previous licensing issues and is now included in Solaris/OpenSolaris.

JMP is capable of playing some proprietary formats, mainly because of agreements Sun made with the owners of the patents (e.g Quicktime) to enable this, but the versions of some of these formats is getting quite dated and as such we are tendint toward focusing on GStreamer 0.10 and Real Player for supplying the bulk of the multimedia player needs.

Fluendo have taken the initiative on the licensing of some restricted codecs for GStreamer. There are several plugins currently in beta testing, which should be released soon, and these are: MPEG4. Windows Media (audio and video) and MPEG2 plugins. There are also others planned in the future. Solaris is seen as a supported platform for Fluendo, and as such any plugins will be available on Solaris as well as Linux. This enables customers that desire support for codecs that have a restrictive license to be able to purchase a module that would simply plug-in to the existing GStreamer framework that OSD provides.

As mentioned above, there is a relatively new project, called Song Bird, which is attempting to provide a cross-platform (currently supporting Windows, MacOS/X and Linux) using the Mozilla application framework. The aim, as they say, is to become the Firefox of media players... It has support for extensions, and one such extension is for synchronising with the iPod. It uses the GStreamer framework for decoding media files, and as such is worth looking at going forward.

Recommendation: 

 With constant improvements in GStreamer 0.10 we are moving towards a good extensible framework where it will be possible or 3rd party vendors (like Fluendo) to provide codecs for media formats. It would certainly be good to start approaching companies like Apple, who owns Quicktime, to get them to start producing plugins for GStreamer 0.10.

 Totem, Rhythmbox and RealPlayer make up the bulk of the media playing on Solaris/OpenSolaris right now, but SongBird could replace both Totem and Rhythmbox given time, so we should keep an close eye on its progress.

Video DVDs

There still is no possible solution for a legal DVD player on Solaris/OpenSolaris. As many people may or may not know, commercial DVDs tend to be restricted in use by two things: the region code (1 = USA, 2=Europe, etc) and encryption of the video stream. The main purpose of the region code is to provide control over the media distribution, while the main purpose of the encryption is to enforce the copyright.

While it is possible to play DVDs, it is only possible to play then once they have been decrypted. On Linux this is normally done using the DeCSS library - this library has problems due to the way it was written - essentially it was reverse engineering of the encryption mechanism - there is some dispute about the legality of this, and it varies from country to country. As such many companies don't ship this support for DeCSS by default.

While it possible to obtain legal permission to ship a DVD player - the biggest problem is that a company has to pay for each machine that the decoder is installed on - this is why when you buy your average home machine, it has additional software specifically for playing DVDs installed. But because Solaris is given away for free, and you only pay for support, it is not possible to provide such a codec by default.

Of course there are also DVD videos that are not encrypted, but these tend to be mainly your average home-made DVD Video, but that doesn't mean we shouldn't at least support this.

Fluendo are also working on a suitable GStreamer 0.10 plugin to provide DVD playing support - this should enable people that really want to be able to play DVDs, legally, to be able obtain a suitable codec so that Totem will be able to play DVDs.

Recommendation: 

 While Fluendo is a possible source of the DVD player for Solaris/OpenSolaris, should a suitable software repository become available, which customers would pay for, then it may be worth considering including this plugin in the repository for paying customers to download.

Enhanced Audio Device Support

There are limitations to the Solaris Audio Device Architecture (SADA) that only allows for up to two channels for output, and because the API exists only on Solaris (thus generally not supported in many audio applications), any drivers for hardware are only ever written by Sun (and only for h/w we deem that we need support for).

This presents problems in the long term - there is quite a lot of varied hardware in existence for audio, more than ever on the x86 platform, with cards often able to support multiple channels, equalizers, etc. The SADA api is much too simplified to support such hardware, and as such, then support is provided it is only using a fraction of the capabilities of the hardware. There is also the inability to keep up with the market by developing drivers for every type of audio hardware.

Last time I mentioned that Sun was looking into possible alternatives to SADA, but from my understanding this has been abandoned we are sticking with SADA for the foreseeable future.

Recommendation: 

 I still think that we should be looking to improve the audio architecture on Solaris. Maybe with OpenSolaris.org it will be possible for the wider community to create drivers, which hopefully could be then integrated into Solaris, if stable enough.

 Maybe it would be a good project for the community to look into improving the audio architecture - any takers?

Collaboration

With the global distribution of many employees in companies (Sun is a prime example), even more so now that we have the OpenSolaris.org community presenting quite widely dispersed virtual teams, there is a constant need for people to be able to communicate effectively.

With this in mind, many people are already using tools such as E-mail, IRC or Instant Messaging, but even these have limitations. With the addition of high bandwidth networks tools that provide Voice over IP (VoIP) video and white-board applications are in higher demand, and provide a very cost-effective way to run a business.

IRC / Instant Messaging

We already have GAIM as part of the OSD desktop which provides much of the functionality that people currently require, and we are shipping the 2.0 version (currently beta, but soon to be released) in Solaris Express/OpenSolaris

From a protocol standpoint Jabber (also known as XMPP) is fast becoming the defacto standard for IM protocols, but is also being quickly expanded, due to its XML roots, to contain various messaging types, including data for starting Audio chats - this is what Google Talk is using now. We should try to ensure that Gaim supports as much of the Jabber protocol as is viable - including the possible use of Ekiga once such a VoIP conversation is initiated.

Recommendation: 

 We should continue to provide Gaim as it covers a multitude of instant messaging protocols quite well, for internationalisation, we should try to keep up to the latest version, which has many improvements.

 We should also look into improving Gaim's integration with Jabber, and possibly Ekiga.

VoIP / Video / Whiteboard

VoIP is fast becoming the way people's phones are operating - many telecoms are actually realising this and offering packages using it. But this is only part of what should be possible when using the network as the carrier.

The biggest player in the GNOME open source VoIP market is Ekiga, previously known as GNOME Meeting. It supports much of what people expect from a VoIP product, but there is still more that could be done in terms of collaboration tools such as white-boarding, integration with Gaim (for text chat), etc. There have been many prototyped whiteboarding mechanisms started, but none seem to have been taken beyond that point, why not?

The latest version of Ekiga integrated into Solaris Express / Open Solaris will soon be 2.0.3.

At present there is no video support on Solaris/OpenSolaris, but this is due to change in the near future, with the integration of the USB Webcams support we will be working to integrated this into Ekiga.

Recommendation: 

 We have Ekiga, but there is still features that could be added to it, so we should try to do this as soon as possible.

X Server Hardware Acceleration

On Solaris, we currently have two X servers (Xsun and Xorg). Currently Xorg is x86 only and Xsun runs on both SPARC and x86. Xorg supports many more X Extensions than Xsun does, and work is well underway to replace Xsun totally with Xorg on SPARC and x86.

Open GL

Open GL has been around since 1992, and is heavily used in the high-performance graphics industry for the rendering of 2D and 3D graphics.

On Solaris, Open GL has traditionally been an unbundled product for SPARC systems only. In Solaris Express/OpenSolaris, the Mesa Open GL implementation is being delivered by default on the OS. Unfortunately, it currently is mostly software based rendering, which essentially makes it unusable for most real-time uses.

Fortunately there is some good news in this arena - with the introduction of the Direct Rendering Interface (DRI) kernel support into recent Solaris/OpenSolaris builds, we will have the ability to make use of the 3D Hardware acceleration provided my most modern graphics cards. This combined with the provision of new X Extensions to make use of this (GLX being one) will enable use to greatly improve the responsiveness of the desktop.

At the moment the DRI implementation only supports specific hardware made by Intel, but this will soon be expanded to include hardware by ATI, nVidia and others.

Once this is available it is possible to run Xgl on top of the Xorg server to provide the ability to render windows off screen and then control how they are presented to the user on-screen. Xgl is an X server that uses Open GL to talk directly to the underlying hardware making use of the hardware acceleration.

Using all of this we can then add some really neat features such as :

• Window Tiling - on the click of a key, specific mouse location, etc. show all the windows in miniature and real-time...
• Wobbly Windows / Animation Effects - moving windows can be opaque, showing real content rather than a snapshot, and also it is possible to introduce effects like perspective, etc.
• 3D Cube rotation effect when switching workspaces.
• Desktop widgets - e.g. gDesklets
• And so on...

While some people will not want these - others will - so lets at least give people the option ;-)

Recommendation: 

 There's definitely a want for things like this, and why not, since most modern machines have the necessary hardware. While Sizzle isn't necessarily practical, it is something that attracts people and removes the old presumption that Solaris is somehow slow, but most importantly with the right persuasion (like this ability) it can attract developers...

 We should start with getting the basic framework in place - DRI, GLX Extension, OpenGL, Xgl, and so on, and then we should add a window manager that is capable of using these - metacity can do it, but Beryl / compiz could do it better... But one step at a time.

Other Applications

Security

Secure Services

Until recently Solaris/OpenSolaris had lots of services running on it by default, all of which provided potential security holes onto a machine. Recently several changes were integrated to change how services ran - either by disabling them by default, or modifying them to only respond to requests from the local machine by default. Generally this project was called the "Secure By Default" (SBD) project, and is a requirement for any software delivered on Solaris where the service is active by default.

Recommendation: 

 There's no specific recommendation other than that people should be aware of this change, and it is useful for everyone since it means that as a desktop, or server, it is very secure and not prone to abuse from the network. (e.g. Denial of Service attacks).

Privileged Operations by User

A common problem with the desktop on Unix is that the user is that any configuration to the system generally require root/super-user privileges.

With the introduction of Role Based Access Control (RBAC) on Solaris the need for the root user is considerably reduced, since the ability to perform specific tasks is not limited to root, but to a user (any user) that happens to be allocated a specific privilege or role. In this a user can be assigned sufficient privileges to change the network - but nothing else. So they don't have the root password, and hence don't have full control of the system. Even root is now just a regular user, but happens to be allocated all possible privileges / roles, by default.

In the latest Solaris Express / Open Solaris releases, you will find that Gksu and libgksu has been integrated. It has also been enhanced to support the use of RBAC should it be possible for a user to execute the command requested using elevated privileges.

Recommendation: 

 In all cases we should try to be as secure as possible, and only seek super-user privileges if REALLY needed. This is the "secure by default mantra". Applications that currently need to run as root, should first call gksu to launch itself, this will first check if the user has RBAC profiles/roles that they could use to run the application, if so will run it using these, if not, it will ask for the root password to continue its execution.

ACL Support

Until recently Nautilus (OSD's file manager) didn't support ACL modification. This was a regression in the desktop, but now, in the latest Solaris Express / OpenSolaris releases, and also in Solaris 10 Update 3 (to be released soon), you will find that Nautilus now has support for the modifying of file and directory POSIX ACLs.

ZFS and NFSv4 then provide enhanced ACL support, much more flexible, and hence complex, than what POSIX ACLs are capable of, so this is still a gap in Nautilus' support for Solaris/OpenSolaris.

Recommendation: 

 Now that we have POSIX ACL support, we should look at providing support for the more diverse NFSv4/ZFS ACL mechanism.

Encrypted Filesystems

Work has already been done in this area, but at the moment it is not part of Solaris, but an OpenSolaris.org project has just been started to deal with this called : lofi compression & cryptography support..

Using loopback mounts (lofi) it is possible to mount a filesystem (or even sub-dirs) as being encrypted. "lofi" has been extended to include a prototype encryption layer and the intention is to further enhance this with a compression layer. This, combined with PAM, would enable easy access to encrypted files.

Subsequent to that the necessary work will be done to bring it in to the core of Solaris.

Recommendation: 

 It is vital that this encryption is well integrated into the desktop - encryption on removable media devices and portable machines is becoming more of an necessity with the risk of identity theft possible all the time with such items.

Trusted Desktop

For many years now, the only secure desktop for Solaris was CDE. Recently in S10U3 and Nevada, along with the Trusted Extensions project, Trusted Desktop was added. This addresses many of the needs of users that run in a Trusted environment, allowing them to now move to a more modern desktop.

We are now the first secure desktop platform using GNOME. This has taken a lot of work, and we hope to be able to contribute this back to the GNOME community too so that users will still have the option of a secure desktop on Linux.

We are also not finished yet, there are more features of Solaris with /ed Extensions that could be used to enhance the user experience even more. Right now we are only matching what CDE provided, but we now have the scope to take this further with the better framework provided by GNOME.

Recommendation: 

 Let's share the code, making GNOME a secure desktop on both Linux and Solaris.

Firewall Configuration

While Solaris/OpenSolaris has firewall capabilities installed by default, they are not configured as active. This means that people need to configure before they activate it. But unfortunately there is no suitable GUI available in the desktop to configure this. While it may fall into the remit of the Visual Panels project - or the Network Auto-Magic project, it is definitely something we need to provide.

Recommendation: 

 We should provide a suitable firewall configuration utility for the desktop, and it should try to be as integrated into the desktop as those you find on MS Windows, where it is possible for the user to notify the user of an attempt to use the network in a way that's currently not enabled and allow the user to make an on-the-spot decision as to whether this should be allowed or not.

PDF Reader

The Portable Document Format (PDF) is quite widely used as a format that is widely distributable for electronic documents. This is helped by the way the format provides all the necessary information to produce a well printed book, if so desired.

The best reader application for PDFs is of course Adobes own Acrobat Reader - it fully supports all of the features of the file format. The problem here is that Adobe have to see the value in porting the reader to a given platform before they will even consider it.

This is still a point of contention for Solaris - Adobe will only provide binaries for Adobe Acrobat Reader on SPARC, despite the fact that most users of the latest distributions, Solaris 10 and Solaris Express/OpenSolaris are mainly x86 based since this is the platform that most people have to be able to multi-boot with.

Evince aims to bring together all the various document viewers in to the GNOME environment. It doesn't only support PDF files, it also supports Postscript, Djvu, TIFF and dvi.

On top of this, it also provides searching and indexing of documents that can be, as well as a thumbnail view of all the pages in a document too.

Recommendation: 

Evince serves well for its purposes, but there are still users out there that need some of the more advanced that PDF provides, such as forms, as such there is a need to either implement this for Evince or get Adobe to do the simple re-compile that's needed to support Solaris x86.

Applets

Keyboard switcher

Solaris has a problem with the fact that there are two X servers available - Xsun and Xorg - both of these are very different in the way that they manage the keyboard. This makes it very difficult to be able to support an applet that enables the user to switch keyboard layouts on the fly.

The current plans are to move towards Xorg being the standard server - and this is due to happen fairly soon - but there is still the issue with what to do if someone is forced to use Xsun (e.g can't manage to get Xorg to run with their hardware).

Previously OSD shipped the gkb_applet, which did work with Xsun. But the gkb applet used direct mapping of keycodes - which are not guaranteed to be consistent between releases (or even in patches), and so caused a lot of problems.

Since gkb_applet has been removed, we no longer have the ability to switch keyboard layouts on Solaris using the Xsun xserver. This is something that people do still desire, and it is particularly important in the case of Sun Ray where each DTU could potentially have a different keyboard layout.

Recommendation: 

 Xsun should be always run with the xkb extension enabled - this is necessary for not just this applet, but also for Accessibility.

 We need to look at what will work best for Solaris, but at the moment it looks like the gswitchit applet, using libxklavier, is the best way to go since it is totally based on XKB and is in active development still.

System Management & Administration

This is a hot-topic at the moment. The Approachability team are very interested in a solution for the single-user system. There already exists a large project, called Lockhart, that is concentrating on the enterprise solution - configuring multiple systems from one admin interface.

Linux has similar problems in that each distribution has its own set of admin tools, e.g: SuSE / Novell have Yast2 and GNOME Control Center, Redhat has the redhat-* admin tools, etc. But even these are miles ahead of what we have on Solaris.

We have taken a serious look at this area, and there are several projects underway to solve this problem once and for all, these are:

• GNOME System Tools
   This is a set of generic tools that provides some basic administration tools, presenting a common UI to the users of the GNOME desktop. We will soon be integrating these into Solaris Express/OpenSolaris with respect to solving part of the needs of the user. Visual Panels

Recommendation: 

 With the integration of the GNOME System Tools we will have some basic administration, which will satisfy many peoples needs, but people interested in improving this area even more should get involved with the Visual Panels project.

Basic Functionality

Basic functionality refers to the areas that a desktop user simply expects to be able to do, with minimal fuss.

Networking

Wired / Wireless Ethernet

With the continued growth in the laptop market, the use of multiple network interfaces on a single-user system has grown because of the availability of wired and wireless networks - both in the office and at home, the latter becoming more and more popular due to the ever increasing availability of broadband solutions. This presents the desktop user, especially the mobile user, with the need to have the ability to change the network configuration depending on location or availability of the network.

With this in mind, there is a team, the Network Auto-Magic (NWAM) team, that is examining this area and enabling the configuration of network profiles. This has been under active development for the last year, and has already released a first prototype, which users can download, and is working closely with the community to ensure that it meets the needs of all the users.

Solaris / Open Solaris has also now got several wireless drivers included by default, and it working on providing more. It is also possible to create additional drivers using an NDIS wrapper, which provides the possiblity to use the MS Windows driver on Solaris x86.

The GNOME community are working on a utility called Network Manager - this is concentrated on the wired and wireless networking and making it as seamless as possible to switch between them. It is currently at version 0.4, so there's plenty of scope for enhancements. It is being regularly used on Linux distributions that are using the latest GNOME releases.

Network Manager has a root user-daemon, that is connected via D-BUS to the user - this is used to change the system's networking settings. It also has a user daemon / applet that runs in the user's panel to display status and enable the user to configure the network.

While Network Manager is quite a leap forward for Linux, Solaris/OpenSolaris doesn't have anything yet to match it. Unfortunately the daemon element directly conflicts with the NWAM project's daemon, which means it is unlikely to be ported to Solaris / OpenSolaris - but Network Manager also as a GNOME Panel Applet, which it may make sense to port and provide a suitable bridge between NWAM and D-Bus.

GNOME System Tools has a Network Admin element, which does also allow for the configuration of network profiles and wired / wireless networks using DHCP or a Static IP, and DNS as the name service. This provides some basic relief for the user of the desktop and it will continue to work when NWAM is integrated into Solaris / OpenSolaris.

Recommendation: 

 We are finally starting to solve one of the main complaints of users of Solaris/OpenSolaris on the desktop - NWAM, when integrated will finish this off. NWAM's integration will also include a Visual Panels element, and should also provide a GNOME Panel Applet akin to Network Managers to make it easy to do simple network changes and monitor changes in the network status.

 the network status.

Modems / Dial-up

While Solaris has long had support for modems, it only supports modems attached to the serial port. Though wireless is becomming quite common place in many areas, there are still people that rely upon dial-up to access the office.

Unfortunately on laptops, almost all the modems that you find built-in to the machine are what has become know as "Win Modems". What actually happens with these is that only the very basis DAC and phone is hardware, while the rest of the modem is implemented in software in the modem driver. This means that most of these winmodems are pretty much unusable on anything other than MS Windows, hence the name.

On Linux, some work has been done to try make these modems work, but it has been difficult because of the lack of support from the hardware vendor. At the moment no such work has been done on Solaris, but maybe this is a project that could be of interest to people working on Open Solaris.

Other modem types that exist are GSM based, either through a mobile phone via IrDA or Bluetooth, or using a GSM PCMCIA card. At the moment none of these are being supported.

Recommendation: 

 A GUI for configuring a modem would be very useful, but seems to be of limited value without the appropriate drivers being present on the system. The GNOME System Tools Network Admin tool is capable of handling modems to a limited degree, but this support will not be present on Solaris/OpenSolaris on integration - but that doesn't exclude an interested party getting involved and providing a suitable patch to the project's community maintainer.

Keyboard Configuration

At the moment there is limited support in the GUI for configuring the type of keyboard connected to the system post-installation time. The only GUI available at present, for users of the Xorg server, is to use /usr/X11R6/bin/xorgcfg, but this does't present a simple interface to the user, and it is possible that in changing the keyboard that the user is likely to break their X configuration.

In a previous section, I mentioned that use of a GNOME Panel Applet that would provide a mechanim for the user to change their desktop's view on what keyboard is attached, but this doesn't solve the need of the user that wants for this change to also take effect at the console level. There is a CLI that is available, called kbd, but a user shouldn't have to use the CLI for such a change.

Recommendation: 

 We should look into providing a GUI for this, but it may also make sense that this be part of the Visual Panels project.

Power Management

Power Management is a big issue on Solaris still - SPARC does have some power management, that works, but it is mainly Solaris x86 that power management is most important, since this covers the main arena for laptops. So what is to be done about this?

A new ACPI driver is going to be soon integrated into Solaris / OpenSolaris, and will provide a lot of the basic power management people expect to be able to use on a laptop such as CPU stepping and monitoring the battery levels.

Suspending x86 machines (to RAM or Disk) is also an important point feature that people desire. While it is actively being worked on, it has taken a lot of time due to the diversity of hardware out there, and they all behave differently when the machine resumes. But it should be available in the near future.

With all these new features being available in the base OS, we need a desktop utility, with a UI that can make the best use of it.

GNOME have a utility called GNOME Power Manager. This works in conjunction with HAL and D-BUS to enable the power management of the machine and monitoring of changes in the state of the machine, such as battery or power status, etc. and to be able to react to these changes - e.g shutdown machine if battery is low, suspend if idle, dim screen, etc.

Recommendation: 

 We should support GNOME Power Manager on Solaris. The necessary ACPI work will soon be integrated into Solaris / Open Solaris's HAL implementation, and with this in place it will be possible to port GNOME Power Manager. We will also need to examine the power management interface on Solaris SPARC to see if it is possible to implement a suitable HAL backend for this too.

Printing

Printing in GNOME and on Solaris, is changing. Printing is now a core function of GTK+ and Solaris is moving to a more complete PAPI and IPP based implementation.

GNOME has moved the printing API from libgnomeprint into GTK+ itself, as of GTK+ 2.10 and GNOME applications are moving towards using this new API - but there isn't a PAPI implementation for this new API, so we will need to provide one for Solaris.

The printing story is still not complete though given the disconnect between the user experience and basic configuration of the printers, so there are areas that need to be done soon:

• Provide a PAPI backend for the new GTK+ Printing API.
• Change the CDE / Motif look on Java apps to be consistent with GNOME.
• Provide a user and PAPI based application of configuring user's printers.
• Finally, but a larger task than the rest, and so will probably break down into phases - work on the user experience when setting up printers, with the aim to providing one application for the user to configure printers.

Recommendation: 

 Work is already under way to implement the PAPI backend for the new GTK+ api, and there is the Presto project that is starting on the user-experience level to make the plugging in of a local printer work so that the user can configure and use the printer relatively quickly and easily. You can track the working going on there at the Desktop Printing project page.

Process Management / Monitoring

OSD on Solaris we now include libgtop and GNOME System Monitor. /p>

Recommendation: 

 While these now work on Solaris, the performance of libgtop and GNOME System Monitor needs some fine tuning to minimise the impact on the system.

Advanced

Virtual Consoles

Linux has had the concept of Virtual Consoles for quite some time now - and Solaris is due to get it (again) on SPARC and x86 in the near future. This is thanks to the Virtual Consoles team at opensolaris.org. There is a prototype available, but it is based on Solaris Express build 44 - it would be good to see a more recent version since the version of the Xorg server contained in it is considerably out of date now.

Recommendation: 

 While we are getting VC soon, it would be good to have something available for people to play with sooner - in the form of a BFU for a later version of Solaris.

X Configuration

The main aim here is to have Zero config of the X server necessary. For this to happen we need to improve the probing mechanisms, but that will always be cases where this simply isn't possible to resolve and user interaction is necessary. In this case it should be possible for the user to be able to get a usable default configuration (e.g. using SVGA or similar) so that they are not left with nothing to use - or alternatively, they should automatically be presented with the necessary configuration tool such as kdmconfig or xorgcfg

Xorg should soon be available on SPARC (currently it is only x86) which will enable people to finally switch resolutions on SPARC too...

While there is progress, there is still a demand for the ability to switch from a laptop LCD to the video out, etc. We need to look at how we can achieve this - some of it will be limited to the device driver, but AFAIK X doesn't have a toggle output ports mechanism.

A configuration utility for enabling (or disabling) Xgl/Compositing by the user would be a very useful tool - the configuration is not for the feint hearted, even on Linux, so if we want people to see this it should be easy achieve.

The xorgcfg utility should have at least a Launcher - right now it is difficult for people to find since it is not even on the default path.

Recommendation: 

 It would be good to see the provision of several elements to enable simply X configuration:

• Add Xorg Configuration Launcher (should probably check Xorg is being run initially)
• Work with dtlogin/GDM to provide a "would you like to configure" mechanism should the starting of the X server fail, or alternatively start X with a suitable fallback configuration.
• Work with Xorg community on a suitable standardised (not varying depending on driver) mechanism to enable projector usage.
• On integration of Xgl, make it easy for user to switch on or off as desired - simplify configuration of this.

Remote Administration

Remote administration is a common demand of central IT operations groups in large enterprises. Many MS Windows based offices tend to at some point end up purchasing this type of utility.

In the latest OpenSolaris.org and soon to be Solaris Express builds, OSD is delivering Vino. It has been enhanced to use the GNU TLS and JSSE encryption mechanisms for security when communicating over the network. The ability to use gnome-keyring to store the password (previously it was a plaintext sting in GConf), and the provision of a logfile for auditng were also added. There is also better support for IPv6.

Longer term, there are plans to add access control lists (based on IP) and some forrm of PAM authentication.

Recommendation: 

 We have done the basics now, so our next target should be to enhance it to be even more secure so it can be deployed in high security environments.

 It would probably be a good idea to also provide a VNC client supporting the same encryption mechanisms.

Software Installation / Updating

This is still an area in need of improvement - while we support Jumpstart (install over the network) really well, the interactive experience for install is really poor. The ability to simply install or upgrade software is also an area that we have to work on.

The good news is that this is under active development right now, and the OpenSolaris.org Install project is where you will find out more detail. The planned work is focused around the following two areas:

• Caiman Installer
   This is targeted at creating an inviting / interactive installation experience and also updating Solaris' installation capabilitys to be the best in the industry. It will provide repositories as well as a CLI and GUI for automatcially finding, installing and updating s/w from such repositories. It will also make use of ZFS snapshots for reverting to prior states.
• Aduva
   Sun acquired Aduva in 2006. Aduva is an enterprise level tool for managing software installed on Solaris and Linux machnines from a central point. It allow for the enforcement of patching (for securtiy for example) and remotely deploying new software.

When both of these are available things will be much better, but it is going to take time, so it is likely that things will be delivered in phases.

Recommendation: 

Things are happening, and now is the time for people to get involved in the Install project - if you want to ensure that the new installer will match your needs please get involved in discussions now.

ZFS

With the introduction of ZFS into Solaris/OpenSolaris we now have a very powerful file system available. Right now it is very under-used and there are several reasons or this, such as the inability to boot from it (although a solution to this is close) and also the fact that it is simply too new for some people to trust.

But in not using ZFS prople are missing out on some fantastic features - such as the ability to export a filesystem for sharing even between big and little endian machines, cheap snaphots (and hence rollback, but also can be used for backups), fast cloning of filesystems, better file security (enhanced ACLs), Zetta-byte filesystem sizes, compression and easy file system management. [Probably more, but do you really need more reasons to use it?]

One major gap here is that there is no UI available to users to allow them to make the best use of this from their desktops. Certainly the installation projects are looking at using this for a rollback mechanism, but also for quick cloning for upgrades and so on. But what about everyday use - e.g. a user developing S/W wants to take a quick snapshot of things before they install a possibly risky version - providing a reliable fallback should things go wrong.

One example of a project that is being prototyped is to be able to manage ZFS snapshots from within Nautilus - this will allow users to be able to take snapshots, and rollback to a specific one. Tim Foster mentioned this in his blog (and there are even more recent comments about auto snapshots), and it looks like Apple might be looking into similar technologies.

Recommendation: 

We need to do more investigation into possible solutions for the desktop here. The project to integrated ZFS snapshots into Nautilus is a fine example. This is definitely an area we can beat other platforms.

Developer Support

This area refers to the specific needs of a developer to be able to develop software. These needs can vary quite considerably given the type of software being worked on - C/C++, Java Application, Java Web Application, etc. What we aim to do is to try provide as much as possible by default, but in the cases where we don't supply something, it should be easy to get and use.

Compilers and Tools

Until relatively recently the Sun Studio compilers and tools were not free to use, and required licensing. This has changed, and now it is possible to download then for free. But, why should a developer need to download then - they should simply be there and usable from /usr/bin - at least if, when the machine was installed, the Development package cluster was selected.

These days though, simply including the compiler isn't enough for many people - there are sets of tools that many people need just to be able to build opensource software on Solaris - e.g. auto configuration tools (autoconf, automake, etc.), source control (SVN/CVS/Mercurial), GNU Make, etc. Why can't we make these available by default - if a developer needs to go get something and build it before they can use it, then it is less likely they will bother.

A well integrated IDE is a must-have for many modern developers - MS Visual Studio is a prime example of a well-integrated IDE, especially when it comes to the ease by which information can be sought about APIs, etc. and also with respect to the visual debugger. How does Solaris compare - we have a real mis-mash of things - the Sun Studio IDE is still based off of NetBeans 3.x (when NetBeans itself is at 5.5!) and the main debugger is still command-line - dbx, or even mdb/adb - with few people making use of the IDE to debug, because it is too clunky - in fact many people I know use ddd to wrap dbx - but it is still not ideal.

An update to NetBeans 5.5 or later with much of the existing Sun Studio infrastructure installed using NetBeans Modules makes a much better long-term solution - and work is happening to enable much of this to happen.

While NetBeans is an excellent Java IDE - its C/C++ support has to improve - even with support added based on Sun Studios C/C++ editing module, there is still much more integration that could occur. If you've ever developed in Java in an IDE like NetBeans, or Eclipse, you will know that you tend to have lots of information at your finger tips, such as dot-completion (where typing in a "." after an object will list all the possible methods or attributes you can use) or in-line documentation (where the method parameters are listed in a tooltip, or even the java-doc entry is in the tooltip). Also, there are much more advanced build mechanisms other than make. We should be able to auto complete a function name or variable name based on scope or the included headers, etc. This also applies to the access of help information.

We also should take into account the Open Solaris, and wider Java and GNOME communities, or others, when looking to encourage developers to develop software on Solaris/OpenSolaris - there is a lot of interest by people outside of Sun in working with Open Solaris and making it a viable alternative for everyday use - so we in Sun need to work with these people and make it happen. This requires time and effort - answering questions, communicating via IRC / e-mail, blogging, providing documentation, etc. Every little bit helps - but it also needs to be easy for people to use. OpenSolaris.org can be improved upon to provide a better collaboration infrastructure - such as Wikis (see Genunix), planet.opensolaris.org (GMan's POS prototype), Sun Developer Network, and so on. These should be part of opensolaris.org domain, not else where to ensure the community doesn't get fragmented. We should also ensure that whenever useful information is being put up here, it is easily accessible - specifically I'm referring to the IDE again - if some one is in the IDE it should be possible to look for examples/tutorials/articles, etc. on a given API - to achieve this there should be a programmable way to access the relevant locations to correlate this information and present it to the user.

DTrace is probably one of the most useful development tools to be invented in the last couple of years - so much that other platforms want to duplicate it (MacOS/X, FreeBSD, Linux, etc.). Yet we don't have a decent interface to it - again documentation integration would be a huge advantage - especially with the way DTrace can be used to trace Kernel AND applications. Of course we could all help if we included useful DTrace probes in out applications and libraries (this is why the X server and eventually Mozilla will be getting some, and hopefully GNOME and others too). Template code is a huge use-case for D scripts - if you look at the Java IDEs again, many will allow for insertion of template code - most people take existing D scripts and cut/paste them then modify to their needs - templates would simplify this a lot (and I'm not referring to C++'s STL here). There is a tool called ">Chime (and a MacOS/X equivalent called Shark) - this provides some nice visualisation of DTrace aggregations, but it could do so much more, especially if it was integrated into an IDE with debugger, etc.

Even once people have finally created an application worth sharing, we don't provide tools that make it easy to deploy them. Debian has the Debian Package (dpkg) tools, RedHat has the RPM build tools. We in OSD have the pkgbuild/pkgtool tool which uses a spec file mechanism similar to RPM and generates Solaris SVR4 packages. This is type type of tool we should have people moving to using for all of Solaris / OpenSolaris, and it makes it easy for people to generate new build files and this packages - obvious proof of this is in the way so many people are creating new solaris spec files at : https://svn.sourceforge.net/svnroot/pkgbuild/spec-files-extra/trunk. Ideally, what ever the solution of a package repository, which we badly need, it should be possible to easily generate a suitable package for deployment to this repository from a set of files.

Recommendation: 

There are a lot of developers that like Solaris as a platform, but there is a lot of work needed by people to get an installation ready for development - we need to make this easy, either through providing the tools out of the box, or making it very easy for people to get them (maybe this is where the Caiman installer should help).

 But even once people have the tools, they don't always work as people want - so we need to improve the user experience here and again make it easy to build and deploy both Java and non-Java applications.

 The provision of documentation shouldn't be the domain of tech writers (although they could, and probably should, be editors after the fact) - it is something we all need to do, but without the right infrastructure and mechanisms to write and publish it, it is very likely to be very dispersed and as a result hard to find what you need when you need it, so this area needs to be seriously addressed.

 NetBeans is an opensource IDE - and with so many developers out there, it should be possible for us to make our own lives easier, so lets start using the IDE, and generating new and useful modules.

 Using NetBeans 5.5, there is a new C/C++ Pack (currently in Beta) that greatly improves the C+/C++ development.

Mutiple Operating System Support

With the advent of multi-core and multi-processor machines coming to the desktop, it is likely that many of use won't be making the best use of it - but also there are lots of reasons that a developer would like to be able to run multiple operating systems on their desktop - building and testing on other platforms being the main one. But multi-boot systems mean you can only use one operating system at a time - Virtualisation provides a solution to this - where you can run multiple operating systems simultaneously.

For a long time this has been the domain of VMWare with its Workstation and Servers editions. But in all cases there is a Host OS and some level of interpretation going on - meaning the OS that is running in the "virtual" machine isn't really performing at its best.

Xen provides an answer to this. While current hardware tends to be limited to a certain amount of restrictions - especially on x86 where there are certain instructions that need to be trapped to ensure multiple OSes will work correctly and not break others, many CPU manufacturers are working towards providing support of Xen virtualisation at the hardware level. The main catch with Xen over VMWare is that the operating systems running need to be aware of Xen, while in VMWare it emulates certain types of hardware that most OSes will recognise (e.g. network cards, etc). Xen allows the OS to be fully aware of the machines hardware, but to allow for allocation of the hardware to other virtual machines.

At this point many of the main operating systems have Xen support in their latest version - Solaris/OpenSolaris is soon to have this out of the box, but at present it is limited to an extra installation step as detailed at the Xen OpenSolaris.org project.

While it is possible to have many OSes running on a single machine, resource allocation, etc. is still a major issue to be able to maintain a running machine. For this to be easy to do, you need a GUI that can be run from the main controlling OS - to this end the Virt Manager project was started. This is based on libvirt which provides an abstraction to the underlying OS. Once libvirt is ported to Solaris Virt Manager will enable people to control the virtual machines from Solaris.

Recommendation: 

We need to deliver Xen on Solaris, and provide libvirt and Virt Manager. With these it will be possible to use Solaris as a main development platform, while being still able to use other OSes simultaneously. This will be a major advantage in heterogeneous development environments where a given application needs to be able to build / run / deploy on several OSes. To take this further, we could also integrate the ability to control Zones into this tool.