“When OSDL announced the first release of its Portland initiative at LinuxWorld Boston in April, heralding it ‘a breakthrough in desktop Linux’, I muttered my skepticism to a co-worker. He expressed surprise at my reaction, noting that the initiative employs extremely smart people. I don’t doubt their intelligence, or their sincerity, but I wouldn’t bet a penny on the project living up to its initial claim, because you can’t conjure a silver bullet out of intelligence and sincerity.” KDE developer Kevin Krammer replies: “There is an article over at linux.com which predicts that the Portland initiative will fail to reach its goal of ‘unifying the Linux desktop’. Unfortunately the author somehow missed that ‘unifying the Linux desktop’ is not the goal of Portland.”
To me the whole situation can be compared to cars: Both projects – KDE as well as Gnome – are like companies whose business it is to create automobiles. Both projects have different ideas about how to create the perfect car. Both projects have “customers” who prefer one brand over the other for natural good reasons and of course there are some people who might simply not care which kind of car they are running as long as they can travel with it from point A to point B. Others spend more time driving and have a strong preference for one brand over the other due to the philosophy as it becomes part of their living environment
There is no problem with having the different car brands KDE, Gnome, XFCE and who knows as long as there will exist some standards:
– people don’t like it if they have to use some cars completely differently from others: Hence there have to be some usability standards about how to drive them to prevent accidents.
– it would be stupid if people would have to visit different gas stations just to refuel their cars. So there have to be standards that tell how putting oil into that thing.
– There should be standards that tell people how spare parts should look like and standards for stuff like putting radios into their car.
Portland is exactly about such standards. Portland won’t make all different car models end up in one single model one day, but it will make those different car brands behave well with each other.
Now you might ask what interests do have people in the open source world have to not produce just one single car model? For real car manufacturers the most important incentive is money. For open source projects that “money” is developer resources. To make sure that enough people prefer their technical framework over the other you’ve got to make sure that from the user’s point of view differences in terms of innovation and look and feel are becoming a part of the brand behind. Because only the look and feel and maybe innovative stuff might be reason enough to prefer your car over the one of the competition.
I predict that the amount of different car models in the open source world will even increase with time. And that’s a good thing as long as it doesn’t cause accidents and as long as ISV’s will be able to provide spare parts that will fit well into any car. And this IMHO is what Portland is about.
Sounds a bit more specific to me…
“Portland intends to generate a common set of Linux Desktop Interfaces and Tools to allow all applications to easily integrate with the free desktop configuration an end user has chosen to work with”
Yes, Portland is more specific. My aim was just to present the big picture and I wanted to show that the idea of a future single unified desktop is flawn. Portland’s motivation is indeed providing ISV’s interfaces and tools to enable them to create applications that work well on all desktops. In my car analogy that would represent the standardization efforts and tools that are necessary for companies who either want to provide spare parts or products which enhance the functionality of the car.
I predict that the amount of different car models in the open source world will even increase with time.
Your analogy is absolutely flawed, and it will become clearer how flawed it is over time.
Things need to be run no desktops environments, in a common way, that are infinitely more complex that anything that needs to be common between cars. Software just isn’t like that.
Things need to be run no desktops environments, in a common way, that are infinitely more complex that anything that needs to be common between cars. Software just isn’t like that.
I don’t understand.
Edited 2006-08-27 14:57
I don’t understand.
The reason why you can drive one brand of car, and then another, is because all the pedals, the steering wheel, gear stick, handbrake etc. are all in the same place – or pretty much the same place. You have enough commonality between cars to drive them.
The problem with desktop environments, and operating systems below them, is that they are complex animals. There are a multitude of tasks to perform, and a multitude of different software packages to run on them with many, many complex APIs that they hook into. They are all vastly different between different desktop environments.
The only reason you’d buy one car over another is for things which are not related in any way your being able to drive it. With desktop environments, those things just don’t exist.
The analogy is silly.
Edited 2006-08-27 15:10
> then another, is because all the pedals, the
> steering wheel, gear stick, handbrake etc. are
> all in the same place – or pretty much the same
> place. You have enough commonality between cars
> to drive them.
One could argue that the same is true for desktop environments: Every one of those has an application menu, application windows, a mouse pointer, a basic set of applications and a small set of common rules that enable you to navigate the whole thing.
> There are a multitude of tasks to perform,
Well, turning left on one road is different from turning left in another. However just like “different” tasks in a desktop environment those two tasks have enough in common to make the user turn left without problems no matter where he is. If there are specific gotchas for some task then maybe it needs some further rethinking in terms of usability.
> and a multitude of different software packages
> to run on them with many, many complex APIs that
I would argue that Portland doesn’t deal with every tiny detail of the API but with the most important basic tasks (which are still in the same kind of magnitude as tasks that might have to be managed in a car).
Concerning the unaffected technical complexity behind: I’m quite sure that people who build cars will disagree with you. A car these days _is_ an extremely complex thing as well under the hood.
> The only reason you’d buy one car over another
> is for things which are not related in any way
> your being able to drive it.
Look and feel is an important thing for anything human beings evaluate to make them feel comfortable: both is important for desktops as well as cars. Then there is regional preference for certain products and several other things.
Yes there are things where cars differ from desktops. but I don’t think that they have any significant impact on the analogy as a whole.
Proof that I’m probably right is the recent increased success of XFCE as well as the countless flavours of KDE as well as Gnome which you will find in different distributions. Those “flavours” sometimes get so much altered from the original, that it’s hard to tell where they are coming from. All of those distributors do have good reasons to make their very own desktops look and feel different (of course “better” from their point of view) and certainly to use different frameworks as their employees have different preferences and different knowledge (insert your favourite C vs. C++ / Gtk vs.Qt flamewar here).
One could argue that the same is true for desktop environments: Every one of those has an application menu, application windows, a mouse pointer, a basic set of applications and a small set of common rules that enable you to navigate the whole thing.
There are different APIs (and APIs are huge) and ways of doing things that different software would have to take into account to run on all of them. In addition, there are still different, or no, ways of doing things like installing a system service on different distributions and desktops and all the tasks people would want to perform.
Have you seen the multitude and wide range of things people program for on Windows? And you think that throwing in different desktop environments still makes that manageable?
A car these days _is_ an extremely complex thing as well under the hood.
Not to drive. When you’re talking about driving a desktop environment you’re talking about things being in the same place everywhere for a user, and also the desktop environment and operating system having exactly the same APIs for everything for software and ISVs.
The LSB is a case in point. Yes, distributors can run the test suites and get themselves a nice sticker to put on their boxes. However, did you know that you can fail those tests just by running on different hardware? The complexity of doing that is vast, and its hard enough maintaining binary compatibility even between the same controlled binaries. Just ask Microsoft.
In short, things like the LSB, and beyond that Portland, look good, but in practice are practically useless. The only way you could even attempt to guarantee any sort of compatiblity would be to give all distributions and desktops the same binaries and the same setup. Diversity, even when various desktops and distributions supposedly adhere to standards is just not something any ISV can feasibly support. Inexplicable differences and incompatibilities are always thrown up.
Proof that I’m probably right is the recent increased success of XFCE as well as the countless flavours of KDE as well as Gnome which you will find in different distributions.
There seems to be this wishy-washy notion from various people, and I saw it with the whole RuDI thing as well, that organisations looking at using free desktops are somehow going to be bothered about running KDE, Gnome and XFCE. They aren’t, and it’s a pretty ludicrous suggestion. I’ve see the situation of desktop an IT support in many organisations, along with the development and distribution of custom and bought software. It’s only barely possible with one desktop, let alone accounting for others.
It’s just confirmation, if any were needed, that many people don’t understand this. I would advise distributors and developers to concentrate on the multitude of functionality that needs to be added, rather than trying to replicate the current inadequate functionality between desktops and distributions.
Edited 2006-08-27 19:00
1. Microsoft keep changing the interface between OSes, as well as between apps/applications suites.
Take WinXP, Win98, MS Office 2K, MS Office 2K7, Windows Vista, Media Player, Winamp, Windows Firefox, and you have a different interface for each of 8 programs. Worse, you can skin many of these in different ways till the cows come home. Worse, because not everyone upgrades to XP or Office 2007 or Firefox when it is released, you have to hold the details of the interface for each of these programs in your head at the same time. You’re probably in the same position re: different versions of Visual Studio. This is an inconvenient fact that MS-loving Linux-bashers choose to ignore, but that doesn’t mean it’s not an issue.
Say it isn’t, and you have an instance of Windows lovers saying that something that is an issue isn’t, as Linux users were recently accused of doing on this site.
2. Cars are NOT the same everywhere.
Some countries drive on the left, some on the right, which means the driver’s seat can change from left to right, too. Some cars are manual transmission, and some automatic (and manual transmission is much more common in Europe). In Europe all stop signs say “STOP” (i.e. in English), whilst in America and Anglophone Canada they say “STOP” and in Quebec “ARRETE”. Signs in America and Mexico might one day say “STOP” and “ALTO” simultaneously. You need different skills/licenses to drive a car/bike/motorbike/tractor/train/bus, but despite the fact they are all road vehicles, they have different uses, and the controls are not the same.
3. The Windows desktop, or desktops, is/are as awkward to get used to if you don’t use it/them every day as any of the Linux desktops or window managers, and so is the Mac. On the Mac you drag a little picture of a disk to a little picture of a Trashcan to eject the disk; in Linux you press a button on the drive or type “eject” to eject it. Gee, I wonder which is more “intuitive”?
I’m afraid you have no clue, fundamentally, what I’m talking about. You’re coming up with stuff that just doesn’t matter to the issues at hand.
Now i understand thanks for explaining.
portland is lots of good ideas but..
Edited 2006-08-27 12:18
GNOME/KDE are already very similar in usage. Differences do exist (much like cars) but they opperate similar enough to me already. I don’t need more standards. I want innovation, creativity, and a willingness to try new methods of doing things. I think loose standards may be a good idea but then again if they are that loose then they are pointless and I think common sense will probably provide enough ‘standardization’ that we don’t need much more.
I actually think linux distros will become more different, how else can you differentiate yourself in such a diluted market?
btw – portland objectives sound just like freedesktop objectives
Differences do exist (much like cars) but they opperate similar enough to me already.
That’s partailly the idea. Since the desktops already provide similar functionality, the only thing needed is a common way to access this functionality.
For example the desktop environments provide the capability to set default handler applications for certain MIME types, e.g. default browser, default image viewer.
Portland allows programs not written for a specific desktop to access these settings, e.g. launch the default browser, independent from the currently active desktop environment.
The result might be different on each desktop, but it will the result expected for the respective desktop.
Well said, Torsten
Browser: Links (2.1pre20; Linux 2.6.15-gentoo-r5 i686; 128×48)
Is this About the Portland Project, or Is this about the Car Analogy now?
In the world of design patterns for software development, the Gang of Four say to “design to the interface”. Is then Portland concerned with building common interfaces whereby an application may uniformly access system resources, including GUI-bound resources?
Is then Portland concerned with building common interfaces whereby an application may uniformly access system resources, including GUI-bound resources?
Yes, although GUI other than common dialogs have not been proposed yet.
As for common dialogs: there is another workgroup, which is handling the printing related things, which is trying to come up with methods to extend printing dialogs for printer specific features without requiring changes to the dialogs code.
Why all the Linux-centricity? I know that OSDL is a Linux-only organization, this is about the desktop, not the kernel. There is nothing in their tools or libraries that requires a specific kernel. Why do they keep saying this is for Linux? Are they not aware that Freedesktop is a crossplatform initiative?
KDE isn’t Linux only. GNOME isn’t Linux only. XFCE isn’t Linux only. So why the heck is the Portland initiative Linux only? Why is their Linux only project being hosted on freedesktop.org?
So why the heck is the Portland initiative Linux only?
It isn’t.
is about make unified API’s for getting various services provided by the desptop and taking advantage of integration into it (file associations, icons, shortcuts…). Such stuff was until now possible mostly by linking to various destop environments libs which is of course problematic to track and therefore not an option in many apps (especially for the commercial vendors which can’t just depend on something which might not be there actually).
KDE and GNOME are platform only for software that directly targets any of them. For others, Portland aims to fill that gap.
Though the huge duplication of work between Gnome and KDE will continue and Portland probably will have certain limits compared to what is possible to do with native API.
Why a news item because one guy out there is confused & is scared that GNOME & KDE will possibly somehow merge into a new monster UI ?
Evil Monster environment – EME – anyone ?
Perfect fit for EvilWM
Look at the Portland-Wiki & its dead ovious what the goals are …
& “Portland” is also useful for other environments BTW
Edited 2006-08-27 22:46
The problem is that ISV’s are not leveraging DEs. Nobody is writing commercial software based on the Gnome libraries, nobody is writing it based on KDE.
What they’re using are generic GTK and Qt applications, and the more zealous members of each desktop camp convince themselves and anyone that will listen that the software is designed for their environments, but the reality is that all of this wonderful work that goes into building our prefered frameworks is essentially wasted and we could essentially be using a bare window manager for running these applications.
Portland gives them an option for a degree of desktop integration without the commitment. Gnome users want to see Gnome filepickers etc., KDE users want KDE filepickers with all their kio-goodness, etc. Portland allows devs to create their GTK or Qt apps and leverage portland to offer a degree of superficial integration for their users regardless of desktop choice.
Portland will not unify frameworks or bridge their differences. It simply gives the ISVs a neutral option.
If an ISV or vendor feels that the kde framework can be leveraged to write an effective application, they will do so because Gnome users can very easily run kde applications. If an ISV or vendor feels that the gnome libraries should be leveraged, they will do so because KDE users can just as easily run Gnome applications.
But if you want to write an application with a degree of desktop integration but don’t need to leverage the full framework because your requirements are minor, then Portland is a third and possibly more appealing option.