Jeff Waugh: “I raised concerns about overselling Portland during the first [OSDL Desktop Architects] meeting, as it could harm long-term credibility with ISVs. Such unclear language has resulted in serious miscommunication, and was not rectified in the 1.0.” (Via Stephen O’Grady.)
I agree completely and have raised similar concerns—Portland helps solve an important problem, but it’s being dangerously oversold, and it’s certainly not a complete solution for ISVs by itself. The LSB has been around for a long time, and we’re just now reaching the breadth of features and distribution support that we’re comfortable positioning it as a practical solution for ISVs. Even now, we’re being extremely careful not to oversell (i.e., we consider our ISV certification program to be in the pilot phase). We (the Linux community) are only going to get one chance at this, namely the opportunity to present Linux as a unified ISV platform rather than a fragmented mess, and we can’t afford to blow our one chance with premature proclamations that the problem is finally solved.
There is a wide range of applications that could benefit from more user feedback if only they would run on other platforms. Both GTK and QT are eminently linux-only, and developing applications in them leads to linux-only applications. Think of GNU Cash, for example. It only runs on gnome. If you want to run it under KDE, you need to load the GTK libraries. If you want to run it under OSX, you need to load X11 and the GTK libraries. If you want to run it in windows, you need cygwin, x11, and the GTK libraries. The problem is, that native compilation is not possible. PORTLAND may be a step forward on the GTK/QT front, but is Yet-Another-Local-Toolkit. To my judgement, the very best approach is to focus on a cross platform toolkit and GUI library that allows the same source project to be compiled natively on linux, but also on osx, and windows.
Very good point. I often speak about the desire to have more cross platform support in the LSB interfaces, which sometimes leaves people a bit perplexed. The LSB is a Linux thing, right, so who cares about cross platform? Well, the reason we should care is because Linux is usually the second port for an ISV, so the less Linux specific interfaces we provide, the less incremental work the Linux port will be, and the more likely the ISV will be to do the Linux port. So, it’s a very important consideration indeed. -ian
The core problem, in my experience, is the ROI (Return Of Investment). Let me describe it with a concrete case. I spent ten (10) years, part time, in the development of a useful application. The application has been running all along. In those years, due to various updates of the operating system, I had to re-write the application four (4) times. The structure is sound and up to date, but the GUI has been and is still causing me great pains. The application currently runs on linux only. It has a server side, and a clients side. I need them all to run on linux, but also on osx and windows. The step is steep. The problem occurs in other software endevours of mine. I want my software to be free from the mess deriving from non-cross-platform-gui-toolkits-and-related-libraries. When I write a program, I demand it to run natively on linux, osx and windows. So far, I did not manage to fulfill this vivid need. I am also tired of languages that keep getting in the way between my thoughts and their implementation. Object-oriented-Java, with all its calls to libraries, it is an instrument for sad-maso-programming. I appreciate the write-once-run-everywhere philosophy, but why is that it has to be so unnatural, and run fucking slow, excuse my French?. I love Perl. I say it, and I repeat it. I love Perl. The problem is, that it is an interpreted language. So, running a complex perl application in different platforms truly means that each platform must run the whole Perl gamut: the interpreter, and various libraries. By the time you have managed to install, configure, and tune all the elements, you realise you have been working for long hours on a machine just to run one program.
My ideal is
– Perl as main programming language, because it allows all sorts of other languages to occur in the code (SQL, etc.);
– a platform-independent-gui, which I am still in search for;
– a Perl compiler.
Am I asking for too much? It is unrealistic, in the third millennium, to ask for a proper high-level language with a cross-platform-gui and the ability to compile natively in different operating systems?
–bob
Ian,
I also raised these concerns with Mr. Cherry at OSDN repeatedly.
It’s quite frustrating that they continued overselling Portland for 1.0.
I have encountered confusion about Portland from the developer
community as a result.
On the bright side, a few web sites that covered the 1.0 release
actually got it, and explained what Portland 1.0 was good for.
I think the problem in large part is caused by DAPI being included
in Portland. It really should have been a separate project.