News, tips, partners, and perspectives for the Oracle Solaris operating system
-
Perspectives
June 13, 2006
Changing the default login session in dtlogin
At some point over the past few years, I somehow went from just checking in the new login and splash images for CDE in each Solaris release to becoming the unofficial dtlogin “special ops” person - handling the overhauls of the dtlogin appearance for the Solaris 10 beta, 3/05, 1/06, and now 6/06 releases and a few other side tasks that the main CDE sustaining team didn't have the resources to handle. The latest of these is shipping in Solaris Nevada starting in build 39, and I've just gotten the draft of the release note for the upcoming Solaris Express release including it:
Default Desktop Session in dtlogin
Now, when a user logs into the Solaris Desktop for the first time, Java Desktop System (JDS) is the default desktop environment instead of the Common Desktop Environment (CDE). JDS has also become the default environment for users who chose a desktop environment on an older Solaris release that is no longer present in the Solaris release, such as OpenWindows or GNOME 2.0.
System administrators can modify the dtlogin configuration to override the default choices using the defaultDt and fallbackDt resources.
For more information about defaultDt and fallbackDt resources, see the dtlogin(1M)man page.
So users who already chose CDE or JDS will have those choices respected - this only changes the defaults for new users or those whose current session can't be found.
For comparison, the description I wrote for our Architecture Review Committee (ARC) has a lot more technical detail (some of which is now also captured in the above mentioned dtlogin(1M) man page):
This case introduces two new resources in the dtlogin Xresources file
(/{usr,etc}/dt/config/$LANG/Xresources) and establishes initial default
values for those in the Xresources files shipped by Sun.
It requests a patch release binding.
1) Dtlogin*defaultDt:
When a new user logs in for the first time, a dialog box is presented
asking which of the desktop environments installed on the machine they
wish to use. The default list currently consists of CDE & JDS, but
any additional desktops installed using the altDt support in dtlogin
will appear as well.
This resource controls which of those desktops is selected by default
when the dialog appears, so a new user who doesn't know the difference
and just clicks the OK button will get this desktop, but those who know
the difference can still choose as appropriate.
The value of this resource must be the altDtStart value of one of the
desktop environments installed on the system. (This was chosen since
it is the one value required for all desktop environments that must be
most stable, since it is the one recorded in the lastsession file in
the users home directory to store their chosen desktop. The altDtName
is localized, so not appropriate for a global default setting. The
other values for altDt* settings are all optional and may not be present
for certain desktops.)
2) Dtlogin*fallbackDt:
When an existing user logs in, but the lastsession file in their home
directory refers to a program that is not executable on the current
system, dtlogin will execute the program listed here as a fallback session.
This may be any program, including /usr/dt/bin/sdt_firstlogin to offer
the users a choice of the sessions available on the system.
The default X resources files shipped in Solaris will contain these additions:
!! Default desktop choice for new users in initial login dialog
!! This should be the altDtStart key of a session defined here or in
!! an Xresources.d file.
Dtlogin*defaultDt: /usr/dt/config/Xsession.jds
!! Fallback desktop choice for users whose lastsession file refers to
!! a non-existent session choice. Set to /usr/dt/bin/sdt_firstlogin to
!! offer the users a choice of the sessions available on the system.
Dtlogin*fallbackDt: /usr/dt/config/Xsession.jds
------------------------------------------------------------------------------
Imported interfaces:
dtlogin lastsession mechanism Project Private ASARC/1995/390
/usr/dt/bin/sdt_firstlogin Project Private ASARC/1995/390
Exported interfaces:
Dtlogin*defaultDt resource Stable
Dtlogin*fallbackDt resource Stable
Default settings of new resources Volatile
By declaring these Stable, we're promising that these resources will take values as described and do what we say until further notice. It doesn't prevent us from further changing or refining this in the future (though since we're really trying to replace dtlogin with gdm in the future, we're not likely to do much), it just means that if we do, we'll have to either change these in a compatible way or create new resources. By declaring the defaults as Volatile though, we're warning that we could change them at any time, without warning - for now they're the Xsession file currently used by JDS, but we could change to another mechanism of starting JDS or even (though highly unlikely) to another desktop altogether, without having to worry about having made any compatibility guarantee there.
The note about a “Patch release binding” indicates that we think these changes are compatible enough with current systems to allow shipping this change in a patch or update release (and in fact, this change is being backported to a Solaris 10 patch to be included in the third Solaris 10 update release, tentatively scheduled for release near the end of this year). These changes don't break any existing systems, don't change anything for existing users with a valid desktop choice, still give new users a choice of desktops, and can even be easily overridden by sysadmins who still really prefer their new users be suggested CDE instead of the newer, easier-to-use GNOME-based JDS desktop.
A lot of people think that binary compatibility guarantees that Solaris provides stifle innovation because we can never change things - this is an example of why that's not the case. We don't guarantee nothing about the system will ever change - that would be foolish - what we do is specify what things you can count on remaining compatible (not unchanged, just compatible), and what you can't - and how long that compatibility is promised for. We've never made any promises in the past about what choice would be shown as the default in the session choice dialog, and the Volatile stability for this reflects that we still aren't - but because that's not someting that affects the managability of Solaris systems or the ability of ISV's to provide applications, it's not something we need to make those sort of promises about. The new resources are declared Stable because we don't want admins to use them and then find when they upgrade to a future release that we've broken their settings or made it so their users can't login until they find and fix the problem.
Right now these promises are mostly expressed via the man pages in Solaris - especially the Attributes section in many man pages. The ARC team is also working to open up the processes through which these are set and the history of many of the past review cases that set important ones, via the OpenSolaris ARC community, so that developers will have greater insight into these compatibility promises and eventually even have a voice in shaping them.
I do not care about open source Java. But why can't OpenWindows be open sourced?