Re: ARTICLE: Portland Project

[Sriram Ramkrishna <sri aracnet com>]

Waldo,

Thanks for the edits!  I was hoping you might fill in some details
that some of my notes have missed.  I'll incorporate your edits in and 
spin out a new version.

sri

On Sat, Apr 08, 2006 at 05:45:01PM -0800, Waldo Bastian wrote:
> On Saturday 08 April 2006 14:33, Sri Ramkrishna wrote:
> > As promised here is my article regarding the Portland Project.  Waldo
> > and I discussed this over a cup of coffee on Friday.  Waldo, please let
> > me know if I've been accurate in my description of the portland
> > project.
> >
> > If the rest of you can edit this (John?)  that would be great!  I would
> > have finished it on Friday but it took some amount of time to come up
> > with a decent style and content.
> 
> I have made a few changes that will hopefully clearify things here and there. 
> 
> My changes are indicated by WB:
> 
> Cheers,
> Waldo
> -- 
> Linux Client Architect - Channel Platform Solutions Group - Intel Corporation

>                     The Portland Project 
> 
> I had the opportunity to spend a little time with Waldo Bastian, over a cup of coffee on the project he's leading the effort on called Portland Project.  The Portland Project has recently been in the news thanks to an OSDL press release and coverage at major Internet sites.  Waldo in addition to being one of KDE's chief architects works for OSDL (Open Source Development Labs) to bring Linux to the mainstream. 
> 
> WB: I'm not really much involved any more with KDE's day to day development at this
> WB: point. Technically I don't "work for OSDL" but I am the chair man of the OSDL
> WB: Desktop Linux (DTL) Technical board.
> 
> Waldo's introduction to the project actually starts with 10x10, Jeff Waugh's rallying promise at GUADEC 2005 (GNOME User and Developer European Conference) a vision that Waldo agrees with and wants to see accomplished.  The fundamental question Waldo asks is "How do we get there?"  To do that Waldo believes that one of the things we need to look at identifiable usage models.
> 
> The usage models today can be broken down to categories. 
> 
> WB: *begin* 
> Within OSDL DTL we recognize 5 different categories:
> 1. Fixed function. This means that people use the system for only one task. Typical examples are Point of Sale (POS) terminals, ATM machines and an airline boarding pass kiosk. An increasing number of these systems is running Linux... but it isn't very visible, typcially you only see the one application that is running on it. These
> systems don't tend to use the "desktop" concept.
>  
> 2. Transactional workstation. Here people typically use one business application and there maybe some additional tasks that requires sending e-mail or use of a web browser. This is the kind of system that you find in call centers for example.
> 
> 3. Technical workstation. This is an interesting one because this is an area where traditionally Unix based work stations have been used. There has been a lot of migration from Unix based systems to Linux systems in this category over the last years. Quite some microprocessors are being designed on Linux based workstations these days and if you were at last years GUADEC you would have heared how Dreamworks is using Linux workstations
> for its work on animated movies. 
> 
> 4. Basic office. People in this category use office applications, e-mail, web browsers to access an intranet or to access web-based applications. However the amount of functionality used is rather limited and doesn't change much over time.
> 
> 5. General purpose/advanced office. In this category people are using a wide variety of
> different applications and there is much more variety in the tasks over time. There is a lot of interaction with people in other organisations. 
> WB: *end*
> 
> Two types have been office and advanced office models.  Office models is your typical corporate user who needs calendaring, email, word processing and so forth.  There is then this notion of the advanced office user, who in addition to the office users need at least one other application that is unique to the job they are doing.  For instance, a dental office may require specialized software to track patient records.  
> 
> The other side of coin is the idea of application availability which plays a role in corporate and enterprise as well as home users.
> 
> WB: The issue of application availability is not going to be solved with free software
> WB: alone. There are classes of applications that ust don't lmend themselves well
> WB: to the open source approach.
> 
> It's not good enough to have a TurboTax like software if you can't keep it updated to
> 
> WB: "if you can't keep it updated" -> "if it isn't updated in time"
> 
> keep up with existing tax laws in the country and locality you live in.  Free and Open Source software have historically been poor in positioning themselves to meet those deadlines due to the fact that they have only finite resources.  Unless, there is a
> 
> WB: it's not so much "finite" as well as "volunteer"
> 
> company behind the project that is willing to keep tax software updated it's unlikely it'll be accomplished successfully year after year.
> 
> WB: +"and well ahead of the filing deadline."
> 
> Waldo makes the argument that Linux needs to be able to address application availability and to support usage models like advanced office in order to make Linux a viable desktop alternative.  Lack of such applications is a deterrent to acceptance.
> 
> WB: That, and hardware support, in particular support for peripherals.
> 
> We have  interesting situations where when you meet with hardware and software vendors they acknowledge that Linux is a great platform and they would love to support it but there are not enough sales to justify investing a lot of money on it.  A classic chicken and egg problem!
> 
> In order to break out of this situation we need to think about Market Segment Share (MSS).  We need to present Linux as a single unified platform not as a diverse eco-system forcing ISV's to look at the various parts.  Vendors should not look at KDE or GNOME, but at the "Linux Desktop".  When we present Linux as a single platform we are creating a Market Segment Share that is measurable.  When we show a large percentage of MSS we have something to drive both hardware and software vendors to support Linux.  We should fight segmentation in Linux distributions and the desktop environments.  Creating strong standards is a key strategy to encourage third party software investment.  
> 
> I mentioned the fact that ISV's seem to have the most trouble with packaging since we don't have a package format that transcends all distributions.  Waldo acknowledges that standards in packaging is lacking and mentions that the Desktop Architects conference 
> 
> WB: *begin*
> I don't think "lacking" is the right description. LSB proscribes a packaging format in the form of a subset of the RPM format. So even though Debian for example uses a
> different packaging format natively, Debian supports installing these LSB-compliant RPM-based packages as well. There does seem to be quite a bit of room for improvment in tbhis area though. So far packaging on Linux has been mostly approached from a Linux distribution point of view, and less so from the point of view of an software
> vendor who wants to distribute his software independent from a distribution and for all kind of different distributions.
> WB: *end*
> 
> meeting in Frankfurt, Germany will be talking about issues like these.  The idea is to make recommendations to distributions to improve their products including packaging.
> 
> Waldo shifts his focus to a problem all of us are familiar with.  Which desktop should we develop for?  ISVs have the perception that if they have to write an application that they need to choose between one desktop environment over the other.  While there is a bit of truth to that, the reality is that 90% of the functionality an application requires comes from the X server.   5% of the desktop environment is window manager specific and we have to deal with the 5% that is the difference between the desktops. 
> 
> WB: The window manager specific bits are already covered by the ICCWM and NETWM specs
> so we don't have to worry too much about that part. 
> 
> Good examples are email programs, web browsers, or writing an application that runs as
> 
> WB: starting of an e-mail composer, opening a URL in a web browser or running an application as root.
> 
>  the root user.  Both GNOME and KDE provide the same functionality; the only difference is presentation and functionality.
> 
> WB: The only difference is that you have to access that functionality in slightly different ways.
> 
>   Waldo asks "Can we define an interface that glosses over the difference and provide one interface and let you access those differences at one entry point?"
> 
> WB: "those differences" -> "that functionality"
> 
> This is the basis of the Portland Project.  To provide a stable set of interface that ISVs can develop against that will work under any desktop environment.  
> 
> Waldo points out that Project Portland is not a widget set.  There are plenty of widget sets out there and we have the ability to use theme engines to be able to make them all look the  same visually.  Differences, like button ordering and dialog boxes can and willbe addressed by being able to apply policy across all applications regardless of toolkit used.
> 
> WB: The point here is that the desktop environment can set a policy for that and the
> WB: widget toolkit can follow that policy. Gtk for example already has a
> WB: gtk-alternative-button-order setting. Same for colors and fonts. It should be
> WB: noted that fonts aren't handled very well currently.
> 
> Project Portland will provide the interface and also reference materials for developers.  Application developers can use these interfaces to develop for both KDE and GNOME.
> 
> WB: "develop for" -> "integrate well with both the KDE and GNOME runtime environment."
> 
>   Linux developers will have the freedom to change how the interfaces are implemented in
>  order to add more value to those interfaces.  For instance, if your application needs to use root access but the current implementation does not provide for a root dialog box, you're free to implement one for your platform.  The Portland Project wants to give as much flexibility in how Linux developers implement the interfaces.
> 
>   At the same time, the interfaces need to be stable so that it can be relied upon.  Additionally, these interface can take advantage of other parts of Linux like SELinux allowing greater integration.
> 
> WB: *begin* Let me try to make that a little bit more clear:
>   Linux desktop or distribution developers will have the freedom to change how the interfaces are implemented in order to add more value to those interfaces.  For instance, if your application needs to use root access the current implementation will prompt for password and uses su, but you're free to implement one for your platform based on sudo for example, or one that requires a fingerprint instead of a password.  The Portland Project wants to give as much flexibility in how Linux developers implement the interfaces. The important part though is that the interfaces themselve remain stable, between different distributions as well as over time, so that application developers
> can rely on them.
> WB: *end*
> 
> Some issues that Portland Project have been working on are default applications.  ISV's would like to have a way to register their applications to handle file types they
> WB: "register their application" --> "register their application as the default application"
> 
>  support.  This feature can be open to abuse as we've seen with Windows.  But by directing applications to a single interface we can explicitly control that interface.  We also need to be aware that we should handle future problems like root kits and
> 
> WB: "root kits" -> "spyware", doesn't need to involve root, see below.
> 
>  viruses.  If you're data is compromised or deleted it doesn't matter whether your OS is protected as you've lost your data. 
> WB: "If you're data" -> "A lot of people still seem to think that as long as there is no
> root compromise there is no problem, but if your data"
> 
>   We still need to be able to deal with these issues now before they become widespread.  With existing security systems in place like SELinux we can integrate them at a single point and be able to assert control over it.  When an application violates a security policy it will not have permission to do so.
> 
> WB: *begin* Let me clearify:
>   We need to think about these issues now before they become widespread. If we introduce
> well defined interfaces for applications to go through, we can put policies in place behind these interfaces, for example we can prompt the user and ask whether he really
> wants to use application FooBar to open all his *.doc files or maybe we want to let
> the system administrator put rules in place for that. The great thing is that with
> emerging new security systems such as SELinux and AppArmor we can actually enforce that
> applications go through such an interface and we can be sure that any policy is enforced:
> An arbitrary application would simply not be allowed by such security system to make changes to the Gnome or KDE configuation files that determine which applications are used by default.
> WB: *end*
> 
> Autostart is another vulnerability that needs to be addressed.  Malware can abuse this feature by inserting itself into the login process.  We need to be able to contain these problems through these interfaces.
> 
> WB: "We need to be able to contain these problems through these interfaces." -> "We need to start thinking about addressing these kind of problems. By defining interfaces
> that applications have to go through we introduce control points that we can use to
> contain these kinds of threats. There is of course a lot of work to do, in current systems
> there are many different ways malware can insert itself into the login process and autostart is just one of many."
> 
> The end state is that we move all kinds of functionality out of the individual tool-kits
> WB: "all kinds" -> "certain kinds"
> and instead move it towards the Linux platform by encouraging ISVs to using a standard set of interfaces.  By doing so we make room for all kinds of innovation across the Linux platform space instead of GNOME, KDE or other parts of the desktop.
> 
> WB: "By doing so we make room for all kinds of innovation across the Linux platform space, e.g. by GNOME or KDE or by Linux distributors." 
> 
> As we finished our cups of coffee, and our conversation.  I had some time to reflect on what Waldo was trying to tell the desktop community.  We need to stop looking at our individual areas and see the Linux desktop as a whole.  The idea of MSS is a strategic way of getting ourselves out of the catch-22 we find ourselves with vendors and make real progress towards the Linux desktop as a dominant platform for ISVs.
> 
> Project Portland is only one of several projects that work towards building the Linux platform.  The other significant effort is the Desktop Architect meetings that seek to form standards in packaging, distributions and desktop technology.  Project Portland will work with popular desktop environments like GNOME and KDE to enhance it's interfaces in order to support the needs of ISVs around the world.
> 
> I'd like to thank Waldo Bastian for taking the time to talk to the GNOME community about Project Portland and his vision for the Linux platform.




> _______________________________________________
> Gnome-journal-list mailing list
> Gnome-journal-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-journal-list


--