Weekly Edition
Return to the Front page
| |||||||||||||
UserLinux Moves Forward
A lot has been happening on the UserLinux front since Bruce Perens first
publicly announced the project in
October. The project has moved
through the early discussion and design phases and is now moving into early
install testing with its own package repository. There is also a fairly
comprehensive Wiki
for UserLinux with everything from project policies and package
framework to the marketing
concept and mission
statement:
Provide businesses with freely available, high quality Debian based
GNU/Linux operating systems accompanied by certifications, service, and
support options designed to encourage productivity and security while
reducing overall costs.
Users and developers who are eager to try out UserLinux will find instructions
on creating a UserLinux system by converting a Debian unstable
system using the UserLinux package repository. At the moment, the UserLinux
package repository only has three meta-packages, one for each UserLinux
configuration: Desktop, server and server-gui. By adding the UserLinux
repository to a system's KDE, however, is not in the package lists. A recent email from Bruce Perens to the UserLinux discussion list provoked Slashdot and a few other news sites to declare that UserLinux would support KDE after all. We touched base with Perens on Tuesday, and he said that this comment has been misinterpreted:
The project policy remains the same -- the official GUI will remain
GNOME. The option was always there for commercial service providers to
support KDE, or any other add-on software that they would like. That little
one line and they got excited. The fact is that a customer asked me to
support KDE, and I said 'sure, I'll take your money to support any open
source software.'
In the past, Perens has mentioned that some companies have approached him about the UserLinux concept. We asked Perens if he was now able to name any of the companies that had expressed interest in backing UserLinux. Perens declined to give the name of any companies he'd spoken with, saying that he was in contract negotiations and he could not give any names at this time. He also said that he asks people not to speculate on the companies he may be in talks with, as it might give potential backers cold feet. We also asked if there was a lot of work needed to make Debian "enterprise-ready." Perens said that Debian is a "solid base" and that there are only a few areas where Debian really needs improvement.
It's important to concentrate on Debian's strengths... I can't beat the
quality of Debian. A lot of what I'm doing on the UserLinux project is
making sure that Debian's good points are not compromised and that we take
advantage of all the good decisions that they've made...I want to be able
to take Debian into the enterprise without doing anything to dissuade the
Debian developers.
He did acknowledge that there are some areas which need improvement. For example, Perens noted that some Debian packages are installed in a non-functional state by default. Perens said that all packages should be installed in a "working state" even if it's just a demo configuration for testing. He also noted that UserLinux will need to support batch or cluster installs, and that the new Debian installer will make Debian much more business-friendly. For developers who want to contribute to the project, Perens says that he'd like to see them go through the Debian Developer process and check any packages into the Debian repository first. "I would not like to see a large repository of free software that does not live in Debian for some reason." He said that he expects that UserLinux will begin to draw new people into the project now that the project has entered the testing and development phase. When can we expect to see an official release of UserLinux? Perens said that there is no firm date, but that the rough date for a release of UserLinux will correspond with the Debian Sarge release. He also noted that UserLinux will be providing pre-releases and CD releases before then. (Log in to post comments)
UserLinux Moves Forward Posted Feb 5, 2004 6:58 UTC (Thu) by aleXXX (subscriber, #2742) [Link] I don't understand the reasoning of Bruce with regard to KDE.First there were some rumors spread on the mailing list that gtk is more free than Qt. When they were corrected (yes, Qt *is* GPL), it was said that Qt would be to expensive for commercial developers (one Qt license on one platform costs much less than one month salary of one developer, while enabling him to produce the same software for three platforms at once). When these arguments were brought, backed by a long list of commercial software based on Qt, the next argument against Qt was that UserLinux is not able to support two desktop environments, too much work. Now.... Bruce himself, i.e. his company, the company of the founder of UserLinux will support KDE for UserLinux, commercially. What was the reason for going against (yes, against, not without) Qt/KDE ? To me it seems not a single one is left. Bye Alex
UserLinux Moves Forward Posted Feb 5, 2004 9:04 UTC (Thu) by MathFox (guest, #6104) [Link] UserLinux wanted to chose ONE desktop as a default. With two very good desktops available one has to make a (hard!) choice. There are no deciding technological arguments, so it is just the licensing issue (LGPL vs. GPL) that was decisive, sorry for the KDE people.Anyone is free to create a KDE4UserLinux.deb. You are free to run KDE on your desktop. But we shouldn't force our preferences on others.
UserLinux Moves Forward Posted Feb 5, 2004 14:59 UTC (Thu) by aleXXX (subscriber, #2742) [Link] > UserLinux wanted to chose ONE desktop as a default.It's not about the default desktop, it's about excluding any Qt/KDE *applications* from UserLinux (k3b, kdevelop, quanta, scribus, ...). > But we shouldn't force our preferences on others. Yes, exactly. They chose (ok, Bruce decided) not to support Qt/KDE (although now he does), so they try to force their preferences on others. Hmm, kinda weird to me... Bye Alex
UserLinux Moves Forward Posted Feb 5, 2004 19:39 UTC (Thu) by frazier (guest, #3060) [Link] > It's not about the default desktop, it's about excluding any Qt/KDE*applications* from UserLinux (k3b, kdevelop, quanta, scribus, ...). It's about keeping the number of packages down, period. Less to support. > Yes, exactly. They chose (ok, Bruce decided) not to support Qt/KDE For clarification, this comment is referring to UserLinux. > (although now he does), For clarification, this comment is referring to Perens, LLC. > so they try to force their preferences on others. No. People are free to add to their systems whatever they wish. It's generally easier to add things than remove them, or so has been my experience with Linux distros in general, anyway.
the rumours are true! GTK is LGPL, QT is GPL big difference Posted Feb 5, 2004 18:08 UTC (Thu) by fergal (subscriber, #602) [Link] GTK does have a less restrictive license than QT. GTK uses the LGPL. This means that I can link it in to a non-free app. If I make any changes to the GTK library then I must make them available but I can keep my app's cource code secret. QT is GPL, so if I link an app to QT, I must distribute it under the GPL or pay TrollTech for a non-GPL license. This makes GTK much more commercial developer friendly. It's not a rumour it's a fact. By the way, I prefer KDE to Gnome so I'm quite happy to see that KDE is going to be supported.
UserLinux Moves Forward Posted Feb 5, 2004 19:19 UTC (Thu) by frazier (guest, #3060) [Link] When they were corrected (yes, Qt *is* GPL), it was said that Qt would be to expensive for commercial developers (one Qt license on one platform costs much less than one month salary of one developer, while enabling him to produce the same software for three platforms at once).Maybe in Europe... (I understand your primary interest is in KDE and not the goals of UserLinux, you've made this very clear through your actions on the UserLinux mailing list.) -Brock (no KDE or GNOME affiliation)
Commercial support for KDE vs. Integration in UserLinux Posted Feb 5, 2004 19:41 UTC (Thu) by ptr (guest, #5885) [Link] Well, these are two very different things:1) supporting one customer with specific needs in direct exchange for money Usually, it is much easier to provide the first than the second. The UserLinux principle to rather select the (arguably) best solution for every common problem enables it to integrate far better and with less work (in theory). For me this is a convinving argument. Now I hope that they live up to the expectations. If you prefer choice over integration, you can still use Debian itself.
UserLinux Moves Forward Posted Feb 5, 2004 10:53 UTC (Thu) by alonso (guest, #2828) [Link] I think not including KDE and QT is simply a big mistake that will bring this project nowhere. Every firm that develop commercial software on linux use QT: MainActor, TheKompany..... And now pixar cite QT as a competitive advantage!!!!A lot of things of KDE is unbeaten: kpart, kdevelop, and why Apple chose khtml? Wherw is gtk commercial apps? If you cite OOo we all know that this was a political decision.....
UserLinux Moves Forward Posted Feb 5, 2004 14:19 UTC (Thu) by gallir (guest, #5735) [Link] OOo in GTK? Which one?
UserLinux Moves Forward Posted Feb 5, 2004 15:49 UTC (Thu) by alonso (guest, #2828) [Link] I was meaning GTK in StarOffice/OpenOffice. But I'm no more sure of the use of GTK in OOo, my mistake :(
UserLinux Moves Forward Posted Feb 5, 2004 19:30 UTC (Thu) by gallir (guest, #5735) [Link] Yes, I understood, AFAIK there is no a line of GTK code in the officialOOo.
UserLinux Moves Forward Posted Feb 5, 2004 15:26 UTC (Thu) by hazelsct (guest, #3659) [Link] It is indeed ironic, as you point out, that although the LGPL licensing of the GTK+/GNOME libraries would seem to encourage proprietary software development, it seems that there is quite a bit more such software for Qt/KDE. I'd add to your list the Corel/Xandros file manager, Lindows' Click-and-Run, and SUSE's YaST2 and package manager as significant pieces of proprietary software for Qt/KDE.On the other hand, there seems to be quite a bit more commercial development of free software for GNOME. From RedHat, to AbiSource, to the ill-fated Eazel, to Ximian before and after its purchase by Novell, to Sun with its "Java desktop", it's interesting to note that all of these companies have invested and continue to pour significant resources into GNOME infrastructure and applications -- and then given them all away under free licenses like the GPL and LGPL. I know of zero proprietary file/package/configuration managers, office programs, or for that matter any proprietary software at all for GNOME (with the possible exception of GNOME support added to Kylix as an afterthought). I would therefore agree with you that despite the licensing differences, there is empirical evidence for Qt/KDE being a more hospitabile environment for proprietary software development. Which makes UnitedLinux' "licensing" rationalization for choosing GNOME all the more baffling. Not to mention the inherent contradiction between "We want to encourage a free desktop" and "We want to encourage proprietary applications". OTOH, IMHO such evidence makes GNOME the better desktop to contribute to, as those contributions will more likely be followed up by commercial investments in free software, resulting in less incentive to deal with the myriad problems associated with proprietary apps. Which is a very different thing from what UnitedLinux is saying.
Encouraging a free desktop, but proprietaryware apps Posted Feb 11, 2004 9:30 UTC (Wed) by Duncan (guest, #6647) [Link] > the inherent contradiction between "We want> to encourage a free desktop" and "We want to > encourage proprietary applications". This baffles me too. It would seem to me that the KDE/QT solution is the best choice possible. 1) It is available GPL, for those wishing to support free software. 2) The QT portion, at least, can be licensed for proprietary-ware use, at a reasonable cost. This is a good thing because it provides both nominal incentive to develop free, which we SHOULD be encouraging, and an alternative if folks are going proprietary-ware anyway, at a quite reasonable but non-zero cost. 3) For those with the budgets, as mentioned elsewhere in the discussion, QT is a product in its own right, with full documentation and support available, for those commercial entities that prefer that sort of thing over the vagaries of typical open source support, as some commercial enterprises seem to, whether our practical experience demonstrates those same vagaries result in better, speedier, and more substancial "on the ground" support, or not. Of course, QT != KDE, and the QT commercial licensing possibilities != KDE commercial licensing possibilities either. KDE as a platform is *NOT* available for proprietary use, AFAIK , which means if KDE is chosen as a platform, those wishing to build on top of it for proprietary use must either be content with the limited integration of the QT base libraries (or choose non-integration at that level all together), or switch to GPL compatable licensing for use of the full KDE platform. Again, I have absolutely NO problem with that. I didn't switch to Linux and software libre after spending a decade on MSWormOS and proprietary-ware just so I could go back to using proprietary-ware in a different form. NO WAY!! I haven't the faintest sympathy with those wanting to use open code but prevented from legally doing so because they refuse to open their OWN code. However, it seems Perens, who is after all the big mover behind UserLinux, has other ideals. Indeed, as the quote above states, it seems very much like he's caught by the double-talk of saying a free desktop is better, while all the while encouraging proprietary-ware apps. (Note that I'm not entirely anti-proprietary-ware. Folks can choose to keep their stuff proprietary if they so desire, and I realize some will. I just have no sympathy whatsoever with their moans and groans if the choose to do so, that they can't borrow code that isn't theirs to begin with, without having to share their own code on the same terms. Neither do I want ANY of my personal support, in any way, shape, or form, whether code, volunteer work, or money even to the penny, going to support those who would keep their own work proprietary. They choose to do it on their own, let them do just that, STAY on their own.) As for the desktop wars themselves, I've stated b4 and will state here again, my view is pretty simple. When Gnome/GTK gets the ability to do something as simple as choosing individual interface colors, instead of changing the entire theme, from a GUI based applet, as KDE can do with kcmshell colors, THEN I might consider taking it seriously as a desktop. Even the proprietary-ware MSWormOS has that! Unfortunately, it seems that while KDE has chosen a route of empowering the users with MORE choice, Gnome/GTK has decided to simplify even basic choices such as that out of the user's ability to make, altogether. I've seen some say that to much choice confuses the user and that they consider that one of the weaknesses of GNU/Linux as a platform. I simply can't agree, as again, if I was OK with some big corporate or developer entity making all my choices for me, I'd have never dumped a decade of MSWormOS and other proprietary-ware experience to switch to Linux and libre-ware. Duncan
UserLinux Moves Forward Posted Feb 7, 2004 12:57 UTC (Sat) by oak (guest, #2786) [Link] QT:The reason why those companies use Qt for their products instead of Gtk is that Qt itself is a *product*, unlike Gtk. Gtk is a project. What I mean by product is that you can buy / get one single package which includes the libraries, integrated documentation, integrated development environment, support etc.
Those companies are using Qt, not KDE. KDE is not a product for which one can buy an exclusive licence, it's only available under GPL license. KPart is a proprietary method whereas Gnome uses the CORBA standard.
KHTML and Mozilla (Gecko) are the only alternatives as full Open Source browser HTML engines and neither is a part of Qt nor Gtk. As to the reason why Apple chose KHTML over Mozilla, I don't know. :-)
UserLinux Moves Forward Posted Feb 7, 2004 14:57 UTC (Sat) by primorec (guest, #2740) [Link] As to the reason why Apple chose KHTML over Mozilla, I don't know. :-)speed and size
UserLinux Moves Forward Posted Feb 9, 2004 0:00 UTC (Mon) by lacostej (guest, #2760) [Link] >> As to the reason why Apple chose KHTML over Mozilla, I don't know. :-)> speed and size code size of the KHTML engine was 10% of Gecko's. Idel for maintenance. Easier to start with.
'Demo configuration' is more insecure than 'non-workable state' Posted Feb 8, 2004 10:40 UTC (Sun) by eludias (subscriber, #4058) [Link] 'Perens said that all packages should be installed in a "working state" even if it's just a demo configuration for testing'.I prefer the 'disable all packages by default' far more from a security point of view. The demo configuration which are not even used might open sites to security holes. Yes, it's true that non-demo use would also be vulnerable, but I prefer the doctrine 'disable what you do not use'.
'Demo configuration' is more insecure than 'non-workable state' Posted Feb 9, 2004 10:42 UTC (Mon) by ekj (subscriber, #1524) [Link] That is still the wrong answer. Noone should have "installed but nonworking" software on their computer.The correct way to secure against bugs in un-used software is not to configure it so it doesn't work. The correct way to secure against bugs in non-used software is not to install it in the first place. Seriously. If a user says "install postgres", he should be able to expect a working installation of postgres. Second-guessing and saying "most people who have postgres installed are probably not using it, thus it's more secure if we configure it so it won't start by default" is stupid in the extreme. Mandrake, for example, gives you a list of services you have selected you have choosen after the select packages step and say something along the lines of: "You have choosen to install the following services [list here]. There are no known security-holes in these services. Nevertheless more services running increase the risk that security-holes are present. You should only install services you intend to use. [Install selected services] [Return to packet-selection]" If the user, after reading that says "Yes, I wan't those services", then he should get it. If Debian is typically giving lots of services they never asked for, nor where aware of running, then that is a bug. And it should be fixed, but not by crippling the service-install procedures to the point where "apt-get install postgres" does not, infact, give me a working and functional version of postgres. (postgres is choosen as a random example here)
|
|||||||||||||