Q. Will you open source your crawler? Will you post your guidelines? A. We can post the guidelines, they're just a page.
IBM workplace client based on Eclipse framework (!) Notes 7 plugin in Java.
For each service (printing, wireless, etc.) stop thinking "How do I provide printing on Windows", and start thinking "How do I provide this service for all our supported platforms".
Q. Who asks for Linux now? A. User segmentation's critical. I'll get to that.
Can't deploy a desktop without answering all those questions. Central wizard to handle installation of a desktop. Central wizard to handle initial configuration and personalization.
Q. What about accessibility? A. I'm investing in a screen reader for Linux. Working with Gnome team. Need some things in X for screen magnifiers and high contrast. Big focus for next year. I can only get exceptions for the policy for so long.
Q. What desktop-specific system management do you do? A. Do you give the user root? Do you provide remote admin? Remote takeover? Do you allow users to install? Do you lock down the machine? Do you give the user the ability to defer low-security patches? For how long? Do you let them pick when patches get applied? Depends on the business unit; some want really secure systems; some want really stable systems and don't care about security.
User segmentation and user profiling within IBM. Five different types of workstation. We're targeting the lowest four categories, not the power users.
Q. Will these slides be online? A. No. Munich did it backwards. They talked about it too early. I don't want to talk this up in the press until most of the work is done. No desire to be a poster child.
Q. Can you post a summary at least? A. Sure.
Enterprise enabling the linux client. Want to lower TCO, but the transition state energy is too high. His effort for last couple years was to lower the pain of migration. Needs to be easy for users, easy for system admins, easy for CIO's.
What do CIOs really need? Want to be able to take a laptop from your desktop dock to a meeting for an hour, then bring it back. Network, mouse, projector all that have to switch transparantly without e.g. restarting X. Users want to be able to suspend, hibernate, then unsuspend and have everything working. Need to expose power management to users. Need a "low power" button for people on long flights. (KDE folks say "we have that in our toolbar since three years ago".) Need wireless drivers and location profile support. Need the appearance of instant statup. Need desktop search. Need input methods and fonts for chinese, japanese, hebrew.
Q. How often do you want to refresh your base kernels? A. Twice a year.
Q. I don't see "applications" on your list. A. I didn't put this on the list because it's my problem to work with the vendors, not yours as linux platform developers. e.g. Brio Insight Plugin -- we're getting them to support firefox. Q. But Wine is trying to help solve that problem. A. I don't want to go that route. Q. Several years ago you wanted to be at 50000 user by now. Why aren't you there yet? A. I wanted Workplace Client. That's how I get the installation easy.
We need things like TPM so we can distribute signed apps and lock out/sandbox all nonapproved apps.
Document interchange. ODF. If everyone's using Powerpoint, it's hard to get them to use OpenOffice. We're on a path to get everyone to ODF on similar time scale as Massachusetts.
Other big gaps I struggle with? When the CEO does his webcasts, the codecs he uses aren't available for Linux. We need to start using mpeg4 codecs for our webcasts.
Q. Would you be willing to buy commercial codecs for linux? A. Yes, as an enterprise. Our network team says bandwidth is critical, so need to use best available compression.
ThinkPad Linux Configurator (Linux version of Access Thinkpad program) Makes it easy to configure all the hardware-specific options, want a picture of your very model showing every option it has. Gave it to Lenovo. Email grant_shenk at Lenovo if you want this :-)
We need a desktop linux conference. We also need to go have a sit-in at the linux kernel summit to get them to
Our hardware database tool lets us go to hardware vendors and say "We have 50000 users who want a driver for your device." It also lets us recommend devices that work. e.g. open source drivers are available for centrino, which lets us go to other vendors and say "centrino's well supported; how are you going to respond?"
Q. I've been having much better luck with Nvidia and ATI lately. They're even assigning a person to just make things work. They respond very well when you come to them with cool applications that challenge them. They don't respond well to just general desktop needs. A. Let's have a separate ATI/NVidia session
Need to get kernel community involved in desktop. They often say "just solve it in userspace".
Q. Got a specific example? A. Wireless drivers all wildly inconsistant, need unified API (but see link to Jeff Garzik's work in driver breakout) Need realtime for multimedia. Q. Why don't we have any kernel guys here today? A. Good question. Q. We need more people like Robert Love working on things like inotify!
Need to get IHVs to care about the Linux desktop!
Openoffice needs to work hard on usability rather than trying to clone MS Office.
Keeping drivers working's a challenge - they may work at one point, but the next firmware rev might break them
Standard formats and protocols crucial Users want to be able to share data between apps (e.g. common address book), want to be able to run apps without worrying about compatibility, etc.
NLD was a quick test. Turned out to be wildly successful. Next version will be more serious. Gap-filling needed to hit basic office user. We do usability testing during development (betterdesktop.org). We even send usability testers out to different countries to avoid country bias. Test ten tasks per week. Actually have developers for those bits on hand. Evening after the tests, developers try to address the issues. Sometimes this lets us improve rapidly during the week. Other times it's too hard, hopefully the videos on the web site will let others do the improvements later.
90% of people, when asked to tell if they were online, recognized the firefox logo and clicked on it!
Was root password for things like changing the clock a problem? Turns out, no. (Really?)
We figured out how to set up a usability lab for $1000 and we'd love to show anybody else how to do it. It's important to make people comfortable.
We hired Robert Love two years ago, had him do inotify. Took a year.
We went to call centers and looked at how hard it would be to convert them to Linux. Turns out they have specialized hardware for voice handling. Email call center workers wanted good music software, too. So we worked on that; see Banshee.
Been working on VBA -> OO macro translator.
Challenges: OpenOffice is the key! We have 6000 internal users. It's viewed as a cheap clone of MS Office by users. UI is klunky and bad. Looks worse than MS Office. MS Office users have trouble using it. It would be nice if it were faster, good UI, and had some compelling original functionality. We're really dependent on Sun's efforts here. It'd be nice if there was more multilateral development on ooo.
Q. What's stopping Novell from putting more engineers on OOo? A. We have a few already. It's money, really. If we could have a revenue strea from it that'd help.
Need a widely accepted way to move apps from Windows. Wine would be that, but there's this cloud over it in people's heads.
WMV/WMA/MMS support needed! Real's been great, maybe they can help. If Linux can't play these, people will think it's a cheap piece of crap.
Q. What's the total amount of money needed to get WMA? A. Publicly quoted price is $420K/year annually to license WMV from MS. (Linspire pays less.)
Q. These usability videos are great, thanks! A. They're the only chance some Linux developers have to see women. (audience laughter)
Mime types and menus are fragmented despite freedesktop.org's efforts. Maybe we need conformance testing?
Would it help to organize connectathon-style hardware day events? Or usability sprints?
We're all about data compatibility. You can see all the filetypes we support at linspire.com/filetypes.
Our focus is on the basic user, not the power user. We do lots of business in latin america. Our customers have no idea how to install software; we make this a pleasant experience by offering a catalog of software with user reviews and one-click install.
Our customers demanded virus protection -- it's now our #1 selling product.
Q. Has it detected any viruses yet? A. Yes, windows viruses. A. (IBM guy:) Business care about this - they don't want linux systems to act even as passive conduits for windows viruses. Q. Rathole (this is how the audience vetoes threads that might go on too long).
We have companies sending us hardware every day for validation. One of our biggest challenges is regression testing when things like the kernel or KDE change; we want to make sure the new linspire still works on the old hardware. Also, lifetime of a motherboard is 6 months -- keeping up with that is really hard. Modems are huge for us. Average consumer still using AOL. Softmodems are a huge mess. Consolidation going on in the industry isn't helping. We're trying to put pressure on the vendors.
Software is an issue. Everybody wants a financial package. In India, every PC has Office and the local equivalent of Quicken.
Q. Would Quicken on Wine do? A. If it works, sure.
Multimedia's a huge issue. All new computers are multimedia machines. Video playback is especially an issue. We need games, too. Even when Linux games are available, they're on the same disk as the Windows game, can't get 'em separately. (They don't want to split the SKUs because it would hurt their standings in the industry sales figures.)
Q. What do games have to do with the desktop? A. The consumer market is the largest single market for PCs, so games are really a big issue for linux.
Our customers don't think of us as a Linux desktop, they think of us as a tool to get things done.
Hardware vendors in Taiwan do little changes to the hardware all the time. Validating drivers is a huge issue. And the hardware vendors don't care about Linux unless it means lots of volume for them.
Printing is a big issue, especially color management and inkjet drivers.
Q. Which apps are having trouble printing? In KDE we did lots of work to make CJK printing work well. A. Non-Qt apps. But we're based on Gnome, so Qt having good printing doesn't help us much.
It'd be cool to have a central compatibility test for web sites so web developers could go to one place to find out if their site was Linux-friendly.
Q. Siemens did a medium-term usability test. If you try to make your UI look like Windows, they get annoyed if it doesn't actually work like Windows. A. It's not a question of copying the menus; it's a question of "let's not destroy what the users have been doing for the last five years".
1000 developer accounts
We get lots of inquiries about running KOffice or Konqueror on Windows, or about using KHTML on Windows. So we're porting KDE to Windows and Mac. This will make transitions from those OS's to Linux much easier for both users and ISVs.
Q. KDE is too complex and hard to debug. Lots of strange DCOP messages. A. Hey, we're just a toolkit. We're not a product. If we were to simplify it too much, it would make the distros do more work to add stuff back. A. Xandros says: KDE is all about modularity. We have no problem stripping things out. Q. DCOP messages are annoying. A. Rathole!
The X server is a real bottleneck. The graphics subsystem is too slow even on good hardware. This needs to be solved fast. We've even worked with Keith Packard a bit. Keith says: often it's a bad use of the X protocol. There's a lot of application-side rendering going on that should be happening on the server.
Poor colaboration. Forks all over the place (e.g. WebCore).
Toolset gaps. Linking to the many KDE libraries is a problem. e.g. to use KDE OpenFile dialog, you have to link to the KDE libraries; can't do that from C programs. Running KDE programs on a Gnome desktop looks funny and doesn't work well. People have tried using a common main loop, but we think using a fixed ABI won't work. The GCC C++ ABI breaks every month. [That's an exaggeration; see below. --dank] RUDI (, ) tries to solve that. [We ran out of time to discuss it here, but RUDI's basic idea is "let's use web services instead of C++ calls for a small subset of high level services". The speaker says that while he agrees that C++ is a bad language for providing an ABI, a bigger problem is early binding. Late binding supposedly lets you stop worrying so much about a stable ABI. --dank]
Too much crap going on in the open source desktop world. Self-inflicted FUD. Projects fighting for a piece of that 2% of market share. (KDE evidently takes a lot of crap from Gnome proponents, but he didn't give any examples.) This looks really bad to ISVs. (An elephant entered the room about now.)
Q. I have a different view of this. The developers for Gnome and KDE work well together otherwise freedesktop.org wouldn't be where it is. The problem is the opinionated fan bases. A. it's also corporations who are pushing their own agendas. (he didn't mention any names, but maybe he's referring to things like novell almost dropping kde?)
Q. Supporting both desktops takes a lot of time. We don't have that time! Unless we can figure out how to make it easier to develop for both platforms at the same time, we're in trouble. Q. We need a single platform story!
We want e.g. Adobe Acrobat to work very well in both Gnome and KDE. It doesn't right now.
1500 developer accounts
Focussing on universal access. The important people are the people who don't care about computers. Really being quite stringent about our user interface design. We have the Human Interface Guidelines, but we also have ideas about lifestyle and experience design.
Since gnome 2.0 we have a big focus on third-party developers. We really want to involve projects like Firefox, VMWare. We've maintained ABI and API compatibility since 2.0; it's horrendously boring but vital for ISVs. Proof is in the pudding; the latest VMWare is very nicely integrated into the desktop.
Gnome release strategy: release every six months reliably; nice updates without the world changing under your feet. Release process is phased: four months of development followed by two months of bugfixing. Fedora and Ubuntu are scheduling their release schedules around ours because they can rely on us!
The desktop is mostly done, but we need much better system integration, so we've been working on Project Utopia (HAL, DBUS, etc) and pushing things like freedesktop.org. Next step is to move from the WIMP paradigm (windows, icons, menus, pointing devices) and on to the important issues (documents, getting laid).
If Mozilla can't give us a stable ABI/API for a rendering engine,
we may have to look elsewhere.
(Mike Shaver, the Mozilla guy: we have two problems: our APIs are based on C++, and our stable APIs aren't sufficient to write real apps. Everyone wants to ship a different mozilla. We'd love to have everybody use the same Mozilla libraries! I'm very willing to discuss this issue. I need more details. Also, we don't have the resources to freeze ABIs all by ourselves. We need help.
KDE/RUDI guy: we really need a uniform way to invoke the user's preferred mail program and web browser etc.
Mozilla guy: This is rocket science, and not immediately important to most of our users, so we need help.)
We need more people like Robert Love taking desktop issues to the kernel, e.g. things like inotify! And of course, we need better audio, printing, multimedia.
We need to encourage all the KDE and Gnome developers to go to the Desktop Developer Conference associated with OLS.
(See his slides and the web page that brought him here)
[highly compressed - I was eating lunch]
We need to reduce the cognitive load of switching to Linux
Is diversity really a good thing? Unification is good for both user experience and for developers (especially the VB sort of developer).
How do I build better apps? Start with data on users. Make your own work easy to use by other apps - everything should be a plugin.
Let's set up the right incentive structure for IHVs to write their own Linux drivers. Give driver developers a common API and a clear set of guidelines that will let them target *every* linux distribution. Certification? Logo program?
Q. I've heard some kernel developers say that most hardware vendors aren't qualified to be driver developers A. Microsoft requires hardware vendors to get certified before they can write drivers. Maybe we can also certify driver writers?
A second meeting was held on Day 2, see below.
They sell thin client software based on Linux. The presentation described a migration of 20000 desktops for a retail chain. The desktops did not store any user data, so it was practical to simply force a remote network boot of a script to wipe the disk and install Linux.
One sticking point was that some Windows apps were needed; for that they used Citrix remote access. They have also used Windows Terminal Services for this. (They also had a customer or two that wanted to use wine, so they helped them get Crossover Office installed.)
Centralized management is key. They use VNC (and say it's implemented directly in the X server?) to let the helpdesk shadow users.
End user GUI concerns: absolutely need to avoid unneccessary user changes, since you can't afford to retrain 20000 users if you can avoid it. For this project, they used a customized fvwm to achieve a pseudo-windows look, and XUL customizations to Firefox.
Overall solution cost was about 1/4 the cost of a standard PC/Windows solution; the savings was about the same as what the customer would have spent to open a new retail location. Starting last year, security has been a major selling point; customers are really tired of windows viruses. Pricing is flat per user, plus a small maintenance fee.
They have a services and customization orientation; each customer needs specialized attention. This makes updates difficult. They try to put the customizations into a separate install module to make updates easier, but they still have to avoid promising free updates to their customers.
Q. What are your font issues? A. Web pages don't look the same in Firefox as on IE due to fonts. Also asian fonts are a real problem. We just did some acquisitions in China, are hoping that will help us there.
Q. What about printers? A. This is our #1 support issue. Customers which have a single uniform printer used everywhere aren't a problem, but customers which have lots of different printers are so hard to support that we end up giving them windows on the desktop instead of linux.
An interesting way to approach the driver problem is to pick one or two laptops and ask what it would take to get them really working well; he said it turns out to require lots of work across many different areas.
sometimes there is no documentation, even internal, for devices beyond the source for the Windows driver.
The IHVs often do a one-time special purpose ASIC that is half broken, will never be fixed, and they use software workarounds in the Windows driver.
The PC Company tried writing "open source drivers" into its contracts a couple years ago, but the vendors weren't ready back then
They only thing IHVs respond to is a real revenue stream. Give them two big orders, and they'll come around.
Each Linux distro has a list of supported laptops and an idea of which users are running which laptops. They need to work together to create the market data and busness case for better linux support to take to the vendors A unified hardware compatibility list for all distros would help users find good hardware.
The Gelato people are working on allowing userspace drivers even for things like IDE drives or 10ge network cards; maybe that would make writing drivers easier. See the lwn article and the Gelato wiki.
Centrino driver support is pretty good. Business laptops tend to be easier; the consumer desktops tend to use the cheapest chipset this month, most of which have no good linux driver support. We need big customers to start writing "you must use a linux-certified chipset" into their RFQs.
Wireless driver interface is wildly different from driver to driver. This needs unification. (Note: Jeff Garzik started working on this in 2004, and is still making progress. There's a home page and a mailing list for the project, even.)
On printer drivers: HP is supporting us pretty well. Other vendors not so well.
We do something fundamentally different than Windows. They make you download a driver that exposes GUI choices; we encode everything in the PPD file, then generate our dialog boxes from info in the PPD file -- and the ppd format isn't quite up to the task. Our architecture is the right one, but we need to enhance the PPD spec, perhaps with help from Adobe (the author of the PPD format). Till from Linuxprinting.org is point person on this; he says it'll be discussed on the foomatic mailing list.
Modem drivers: it's all softmodems now. Often the hardware vendor licenses the codec from a third party which places restrictions on where and how the ihv can distribute the driver.
X needs to handle hotplugged new input and output devices; you may think this works now since you can plug in a new usb mouse or keyboard, but that's a kernel bandaid. There is interesting and difficult work to do to get X up to speed here.
Rumor has it that ATI and NVidia are in a patent deadly embrace; the first one to really open up to linux driver developers will get sued by the other. No idea if this is true.
Short term: binary drivers will continue to be needed. The ATI and NVidia binary driver writers say they are resource limited, so trying to force them to restructure their drivers wouldn't go over well.
Intel is currently doing things right; their graphics hardware isn't the highest performance, but their drivers are open. We should focus on a positive message praising companies that do have open source drivers.
Right now, X is reconfiguring your PCI busses from userspace, and doing busywaiting instead of relying on the kernel for those things. The X.org community has plans for dealing with this, but it's a lot of work.
Monitor probing is a dark art. The SiS driver is an example of this done well. Nevertheless, the time lag to support new devices is high.
There are suspend/resume issues. ACPI defines a way to reinitialize a video card, but hardly any vendors implement it. FreeBSD does this right. There's been one meeting a year at OLS about this stuff, which isn't enough. We need more people working on this, and meeting more often. Somebody at Intel's trying to put a summit together; if you're interested, contact patrick.mochel at intel.com.
Finer-grained power management is needed both by desktops and by large server farms. Mostly a kernel issue.
Audio. We should ensure we have one well-designed, useful, and recommended way for game developers and embedded developers to do sound. We have a network-transparant windowing server, but not a network-transparant audio system; is there's a disconnect there?
MAS was developed by the old X consortium, is under the old X license, would support Jack across the network, and the LTSP people say it works.
gstreamer was said to be good.
See also :
We like the agile way freedesktop.org specs come together. We would like a lightweight way to formalize these specs, e.g. feed them into LSB. This is exposing some processes at freedesktop.org that may need some updating. For instance, freedesktop.org doesn't speak with one voice to the outside world. How many people in this room have actually read through the specs there? (only 20% raise hands) If the folks in this room haven't, how can we expect the general community to? We need to work on this.
The old X meetings had a large education component. Our desktop conferences so far have been aimed at insiders; we need to add more outreach and education to these events, and get ISVs to come. OSDW was a test of this idea, and it seemed successful. Somebody said that, just like we need an "MSDN for Linux", we also need an "PDC for Linux".
So, how do we keep freedesktop.org stakeholder-based, yet provide some oversight? Maybe an nontechnical advisory board made up of representatives from key stakeholders (gnome, kde, etc.) to facilitate communication, and when neccessary, resolve conflicts. The breakout group looked at actual situations that happened, and found that most issues had been sorted out by (1) reducing the noise level and (2) getting the right people together.
OSDL might help by encouraging projects (e.g. Gnome, KDE, Mozilla, Adobe Acrobat) to improve their support for some of the freedesktop.org specs.
One of the strengths of freedesktop.org is that it's run by the technical people, and they worked towards solving technical problems without worrying too much about marketing issues.
Freedesktop.org has done well at making it easier to develop useful desktop specifications to solve individual problems. It's a bit like sourceforge.net, though; there are freedesktop.org specifications that aren't really getting any traction. We could improve the freedesktop.org site to reflect which specs are widely adopted.
Waldo would like to see more involvement from projects like OpenOffice and Mozilla.
Some of the specs are really speculative. Should we require projects to gain some experience with an initial implementation before encouraging people to follow a spec, to cut down on the number of specs that turn out to be bad? The IETF requires two interoperating implementations before you can create a draft standard.
A spec is not a spec without use cases. A spec is not a standard (until it it meets some criteria). Maybe we should encourage people to call these things proposals until they meet some requirements.
Maybe freedesktop.org needs a neutral person to help guide authors of proposals.
Such a site should have an advisory board from the community.
Here are some existing documentation resources:
The world is dynamic. X barely handles any change at all without requiring a restart.
X.org has been maintaining imake for twenty years, and wants to get out of the build system business. Hence the switch to autoconf/automake.
X.org has no way currently to tell when they break their ABI. This makes it really hard for third parties.
Right now, when a security problem is found in a tiny library like libxpm, X.org's response is -- release the entire X system. This is one reason they're moving to a modular server. They're shelving the monolithic code base as of x.org 6.9.
90% of graphics chips are dedicated to 3D now. X needs to support 3D graphics to take advantage of the 90% of transistors currently laying fallow. Hence the EXA acceleration work. Much of the work is in memory management; doing the drawing is the easy part! This is the short term approach. EXA is part of X.org 7.0, will be ready for wide use in 7.1. We expect a fairly rapid transition from XAA to EXA.
X should be recast as a GL application. This lets you do all sorts of interesting things for accessibility (color correction, magnification) and lets you avoid having multiple 3D drivers (one for X, one for GL). This is the long term approach -- GL on Linux isn't quite up to this yet. This depends on the kernel/X interface.
Cleaning up messes - there are turds from long ago we'd like to get rid of.
Migrating from xlib to xcb - xlib is broken, doesn't expose all of X protocol, has too much other stuff in it. xcb is tiny, provably correct, provides all of the X protocol, lets you use asynchronous X calls to make your app less sensitive to network latency.
Utopian dream -- we need a kernel driver for hardware management instead of letting X, fbdev, and DRM all fight over the hardware. (See the lwn.net article about the 2004 OLS meeting on this subject.)
A few post-meeting links:
Preventing ABI breakage, and making it possible for ISVs to "write once and run everywhere", is exactly the goal of the LSB. The ISVs are still skeptical about the LSB because of its limited scope. Presumably the skepticism will abate once the LSB Desktop effort bears some fruit.
The LSB verifies that Linux distributions are free of ABI breakage by running an LSB compliance test before each release of each distribution. This is fairly late in the game; projects like Gnome, KDE, and freedesktop.org can and should do their own ABI stability testing before their own releases. (They should also take library versioning seriously; see the recent problems with fontconfig.)
One ISV said that he needs a way to target older distributions. Autopackage was brought up as a possible solution. The ISV said he wanted something lighter weight that did not address packaging -- he wants to continue using his existing packaging techniques, and only wants something to make e.g. LD_LIBRARY_PATH and LD_PRELOAD tricks easier. The meeting adjourned without reaching a conclusion on this issue.
A few post-meeting notes on ABI stability:
As an ISV, our GUI toolkit requirements include:
[ None of KDE/Qt, GNOME/GTK+, nor wxWidgets mets all these requirements. ] Right now we use, develop, and host FLTK, which offers all of these things (#5 is part of 2.0...) so that we can write our UI code once and distribute on multiple platforms.
- Stable API
- Native (or similar) look-n-feel
- Basic UI widgets - buttons, lists, tabs, menus
- Ability to develop custom widgets
- Unicode support
- Static linking or stable, vendor-supplied shared libraries
- Cross platform (UNIX/Linux, MacOS X, Windows)
- Smaller is better
- License should allow for binary-only distribution.