|
|
Subscribe / Log in / New account

LinuxCon: Some advice from Uncle Dirk

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

By Jonathan Corbet
September 23, 2009
Dirk Hohndel has been a member of our community since the earliest days. In recent years, he has helped direct Intel's (very friendly) strategy toward Linux - a job which has required, one assumes, a great deal of educational work inside the company. Dirk also spends a fair amount of time outside of Intel, advising the community on how it can work better with vendors, with customers, and with itself. His thoughtful talks on the topic are usually well worth hearing. In two separate talks on the first day of the first LinuxCon, Dirk had some fairly general thoughts on how the next steps toward world domination can be taken.

When ASUS created the netbook market, its disruptive new machines all ran Linux. The development community welcomed this news, which seemed like a [Dirk Hohndel] validation of much of what we've been doing all these years. But it did not take very long before Microsoft was announcing that the vast majority of netbook systems were now shipping with Windows instead. How is it, Dirk asks, that Windows is able to displace Linux on systems like netbooks?

Part of the problem, certainly, was the second-rate distribution which was shipped with the early netbooks. It suffered from what Dirk calls the "three click problem." When the system is first turned on, everything looks great. But, by the time the user gets three clicks into the system, it's clear that it is an unfinished product. Obvious problems - configuration dialog boxes for applications which do not fit on the small screen, for example - are everywhere. So it does not take long for users to feel that they have not gotten what they really wanted.

But the bigger problem, says Dirk, is that the systems installed on these devices are trying to be Windows. They are trying to beat Microsoft at its own game, and that is a difficult strategy at best. If the ultimate goal of a development project is to copy somebody else, it is inevitable that the project will always be behind its target. It will never be a perfect copy, and users will know. The user's experience will always be less than it could be with the original.

An example is OpenOffice.org's attempt to copy the "ribbon" interface found in Office 2007. It's already two years later, it is not that great an interface in the first place, and OpenOffice.org will not do it as well as Microsoft did. Suffice to say that Dirk does not appear to be much impressed by this particular initiative. Similarly, attempts to copy the iPhone in mobile devices are doomed to an always-inferior existence. There has to be a better way.

That better way, says Dirk, is to move past the desktop metaphor which was never all that great an idea in the first place. People who are buying computers now are not interested in desktops, and they do not really care about the operating system they are running. What they want is to join communities. So the most important thing we should be doing, in the design of our applications and interfaces, is to better connect users with the communities they are interested in.

Indeed, the processes in many communities seem to have the explicit goal of encouraging people interested in design to go elsewhere. On the issue of design, Dirk made the claim that we have few real designers in our communities. Indeed, the processes in many communities seem to have the explicit goal of encouraging people interested in design to go elsewhere. One partial exception might be KDE; Dirk claims that KDE applications tend to be nicer because Nokia (and Trolltech before it) have put true design resources into the Qt toolkit. In general, though, we are not doing a good job of reaching out to designers, but we need those designers if we are going to create great systems.

The closing note of this talk was simple: listen to the users. And, by "users," he did not mean the people in the room, but the much wider user community that we need to reach.

Dirk's second talk filled a brief keynote slot; it was called "how to shine in a crowded field." The specific crowded field he was talking about was consumer electronics, which is packed with devices in search of customers. In this market, success is not something that just happens. There are, says Dirk, four things which are required.

The first of those is vision. There are, he says, plenty of visionaries out there, even if many of them do not see as far as they might think. We need those visionaries - just following others is, as was described above, not the way to be successful. Our community needs people who are not stuck doing things the way they have always been done.

The second requirement is competence - the ability to actually implement the visions. One of the nice things about the open source world is that competence is very much on display. We can (relatively) easily measure the competence of others, and our own competence as well. We are very free to learn from each other and quickly improve our competence.

Then there's commitment. Without commitment, developers will not see the task through to the end. And, just as importantly, users need to see that commitment. They need to know that the developers will be around, that they are serious, that they will respond to bugs, and that they will continue to carry the code forward. That said, open source makes users less dependent on the commitment of others. When a proprietary software vendor abandons a body of code, there is nothing the users can do about it. Open source software can be picked up and carried forward by others.

Finally, there is the matter of focus. Without focus, we will lose; there are simply too many distractions which can get in the way.

So how does the community do in these areas? We have visionaries, though Dirk would like to see more of them who are willing to go further off the beaten path. For competence, Dirk suggests downloading a random SourceForge project and looking at the code. That, he says, will make one question whether the open source community possesses any competence at all. Commitment, too, is on display at SourceForge - most projects there are inactive and going nowhere.

And focus, he says, is really hard. As a result, open source projects are highly susceptible to the 80/20 problem. The first 80% of the work is fun. But the task of actually finishing the job is less so, so it often doesn't happen. So we have a surfeit of 80%-done programs which have since been abandoned. We have, he says, 55 bad spreadsheets out there when we could have three really good ones. If we could stick to the projects we have, rather than yielding to the temptation to start some new, shiny project, we would be in much better shape.

Another example is the nearly 300 active distribution projects out there; it would be better to have fewer choices which were more complete. Given that, one might ask why Dirk's group went off and created Moblin - yet another new distribution. His answer (to his own question) was that they studied the available distributions and couldn't find one which they thought they could carry forward to a full implementation of the vision they had for Moblin. They needed to start anew, he said, to be able to commit to reaching the end.

In conclusion, Dirk says, the recipe for standing out is relatively straightforward: listen to the users, implement the whole vision, and go someplace where others have not been.


(Log in to post comments)

On Designers

Posted Sep 23, 2009 23:29 UTC (Wed) by zlynx (guest, #2285) [Link]

I know about designers and I know why they tend to get driven away because I would do it if I could. :)

They are a real pain in the neck!

Always creating lots of extra work for the programmers (that would be me) that does not add anything to the functionality of the product.

However, that said...

I have to admit that the finished product that has a designer working on the look, feel and general polish is a lot nicer to use.

You've got to watch them though, or they'll polish the advanced features right out because they are hard to use. Or they'll create too much extra work and the program won't get finished.

On Designers

Posted Sep 23, 2009 23:41 UTC (Wed) by Baylink (guest, #755) [Link]

Yup, that's precisely the project-leader attitude I was talking about. Thanks for demonstrating it. :-)

On Designers

Posted Oct 1, 2009 23:23 UTC (Thu) by jmm82 (guest, #59425) [Link]

Sadly, A new paint job sells a house quicker than fixing the septic tank, but the new owners will smell the backed up S!@@!, eventually. :}

Many Linux projects are in tender need of some love and care, but look at Network Manager. The program is clearly much more user friendly to most *normal* people than ifup/ifdown, still it gets A LOT of resentment for breaking the elegant, simplistic world we can UNIX. Granted it hijacks your routing tables and causes some networking bugs to be so abstracted that only a few people can solve them, but when it works it really is nice.

Simplicity for users comes at the expense of programming complexity. Which leads to the big question. Do all Linux programmers really want the rest of the world to like their masterpiece or will the masterpiece be destroyed in the process leaving a system which resembles the Dredded Micro *cough* *cough* thingie which we left so long ago in search of tranquility.

On Designers

Posted Oct 7, 2009 8:12 UTC (Wed) by alext (guest, #7589) [Link]

But that is thinking of the designer as a decorator rather than the person
who over sees the sum of all the parts and designs a system and by
decomposition the parts.

Design is making components that work together by design rather than hacked
to work by cludge. The daily code base I work on (a commercial IDE) suffers
this exact problem, it was hacked by (average, low experience programmers)
and not design the implemented by people with an understanding of both.

On Designers

Posted Oct 7, 2009 14:55 UTC (Wed) by jmm82 (guest, #59425) [Link]

Yes, true. It is nearly impossible to find a designer which can design _both_ the internal systems workings and the *eye candy*. A strong large project requires a minimum of three good designers.

1. Systems integration designer
2. Low-level designer
3. User Interface designer

Also, the GUI should be easy to replace with out changing the low-level code. Most projects have #2, but few have all three.

Network Manager is not be a good example because a. it is trying to tackle a problem that is close to impossible and that is to cover the needs of all network use cases. When someone comes across a use case that is not supported they say integrate it with NM or too bad. While I support NM as a project necessary to advance Linux, I disagree with this philosophy. b. Most issues I hear about are due to a lack of documentation and issues with drivers.

LinuxCon: Some advice from Uncle Dirk

Posted Sep 23, 2009 23:40 UTC (Wed) by Baylink (guest, #755) [Link]

> On the issue of design, Dirk made the claim that we have few real designers in our communities. Indeed, the processes in many communities seem to have the explicit goal of encouraging people interested in design to go elsewhere.

Indeed we do not.

"Designer" is what I've put on my business cards for most of the last 20 years. It's come up through three tracks; I do software design, graphics design, and the odd TV program here and there; design, like most other discplines, is the application (and thoughtful breaking) of rules.

The reason, I've learned, why designers are chased off in the FOSS environment is largely that design is *not* generally an implementation skill, and designers are not always skilled implementors: to take software as an example, I've worked over the years with half a dozen really excellent coders (which I am not) on various projects.

They were excellent coders, but if you left them to do the design themselves, you wouldn't get anything usable. Systems analysis and software design (two closely related, but slightly different fields) are both critical to a good end-product in the software business... but the only way you get them, generally, in FOSS, is if you *do* find that rare coder who can do both -- it tends to be a "Code or GTFO" sort of environment, except in very rare instances.

And that, I think, is the problem Dirk's alluding to.

He says we need "competence" to implement visions. But that's two pieces: turning the "vision" into a deliverable, and *then* delivering it.

FOSS tends to be weak on the first half -- because that's the half that says "it needs to be usable and workmanlike looking (if not pretty), *in addition* to working properly". And the people who are good at that part are *often* not superstar programmers. Which is all the meritocracy seems to select for, in many cases.

"Programming systems product", Fred Brooks called it. All four quadrants, to paraphrase the movie industry.

That's the part we're missing, and as long as lead coders on projects think that all the smart people *already* "work" for them, the problem will continue.

When you're big enough (or smart enough) to already have a bugzilla or trac, and accept (and triage) RFE tickets, you're either on your way to digging out of this hole, or you've done it. Lots of projects either don't accept RFEs at all, or ignore them.

Figuring out how to make sure that vision isn't tunnel- seems the important bit.

LinuxCon: Some advice from Uncle Dirk

Posted Sep 23, 2009 23:43 UTC (Wed) by Baylink (guest, #755) [Link]

And I missed one important point, on the 80/20 issue:

The *fun* part, generally, is the design work; lots more people seem to find designing fun (whether or not they're actually any *good* at it), than find coding fun... so if you let a designer take the fun 80%, then you're *really* screwed.

Not sure if that part's fixable...

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 18:47 UTC (Thu) by holstein (guest, #6122) [Link]

A variation on the bike-shed-color syndrom probably.

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 1:38 UTC (Thu) by JesseW (subscriber, #41816) [Link]

Interesting and thoughtful response, Baylink. There was one part I didn't follow, though.

But that's two pieces: turning the "vision" into a deliverable, and *then* delivering it. / FOSS tends to be weak on the first half -- because that's the half that says "it needs to be usable and workmanlike looking (if not pretty), *in addition* to working properly".

I don't fully understand what you mean here. You are saying that "turning the "vision" into a deliverable", which I gloss as "specifying it in detail", involves making sure the specification is "usable and workmanlike looking ... [and] working properly". Isn't that what the whole process of making anything is about? What else is there? Could you expand on what aspects of that are particular to the "turning the "vision" into a deliverable" part of the process?

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 1:52 UTC (Thu) by Baylink (guest, #755) [Link]

Sure, though Fred Brooks, as I noted, did it better:

http://my.safaribooksonline.com/0201835959/ch01lev1sec1

Roughly, though, it's "avoiding the three-click problem": it's not always easy for some coders to get up out of the nap of the earth to 5000 feet, much less 30,000 feet, and make sure that they've actually completely specified the problem ... which is what is being complained about there.

FOSS development works, most of the time, we are told, without any direct financial incentive because the developers are scratching their itch.

The problem on point is that *they're not scratching everyone's itch*.

Figuring out how -- and how far -- to generalize, and then making sure that all happens, is the job of systems analysts and project managers. In my personal experience, the number of people who are really good at both is small. I'm a competent coder, but I don't *love* it. What I *love* is figuring out what people really need, and then specifying that so that someone can create it.

FOSS development caters to people who are good to great -- or at least *dedicated* -- coders, whether or not they're good designers (I've seen some really raunchy programs in FOSS; great code, but they're just not up to the task, as demonstrated by the opinions of their audiences)...

but it -- and by "it", I mean "lots of the people who run big FOSS projects" :-) -- doesn't tend to deal well at all with people who are really good analysts/designers, but aren't coding superstars.

Or, perhaps, my entire opinion here is colored by the unsurprising fact that they just don't agree with *my* view of The Way Things Ought To Be; unsurprising because I, clearly, don't agree with theirs. :-)

This is all my perception, of course, going back to when I could read all of Usenet in a day; it's leavened by 25 years in DP/IT, most of it as a designer/analyst, much of it writing my own code, and also by interacting with quite a number of FOSS projects to varying degrees of depth, including big modern things like WebGUI and Zimbra, and old projects like HylaFAX. I could be wrong. :-)

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 1:59 UTC (Thu) by Baylink (guest, #755) [Link]

I find I wasn't quite clear enough before hitting post :-)

"usable and workmanlike looking" is the part I was suggesting is supplied by designer/analyst types, and often missing in FOSS projects, because it's not "essential to the base function".

A current example that's driving me insane is Knetworkmanager, as supplied with SuSE 11.0, which I run on my laptop. The Right Way to handle this stuff has been pretty obvious for some time -- supplied, embarassingly enough, by Windows XP... though it often can't keep the links *running* to save its life.

But KNM makes me jump though some non-obvious hoops to get anything done, having to know that I must choose "New Connection" in order to teach it about a network I've never been on before, and having to suffer through a popup menu that completely fills the screen of already learned networks when *none of them are in range*... and which is *in the way* of the other menu as I scroll up to do the thing I actually need to do.

That's the sort of three-click-problem items he was talking about, IMO.

And the simple fact of the matter is that while I could probably contribute to fixing them, the amount of time I have available to deal with the 30 or 40 such things that make it difficult for me to use SuSE/KDE3 on a daily basis limited to "I might hang a ticket, if I don't have to fight to find and sign up for your tracker". And what I *get*, in a lot of cases is "we look forward to your patch".

I've *read* "Smart Questions".

I submit that while I understand -- and even approve of -- the arguments it makes, *that's the difference we're talking about*. If you want Real People to *want* to use your stuff, then *someone* has to deal with those issues.

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 4:42 UTC (Thu) by JesseW (subscriber, #41816) [Link]

Thank you. I appreciate you taking the time to explain this; I've also noticed similar issues.

Let me expand on my understanding of the alternative to to this problem, i.e. the process followed by projects that do pay attention to RFEs (Requests For Enhancements, for those following along at home). The maintainers of such projects consider their jobs to be designers/systems analysts, although with the job of selecting the good from what they are given, rather than being able to directly demand it of subordinates, as is done in traditional cathedral-style projects. The projects attract a number of coders who are willing and able to recognise itches when they read RFEs, even if they themselves hadn't felt the itch before. And finally, such projects have users who are aware, able and willing to send in their observations of the problems and rough-edges they encounter and receive courteous appreciation for doing so. Is this impossible? Hardly. Are there many, many projects that arn't like this? Certainly.

While I agree that many FOSS projects don't recognise the value of suggestions without code, I'm still uncertain why you consider that having a badly structured interface doesn't screw up "the base function[ality]". I would be surprised to hear of a project that refused a patch fixing a interface wart on the grounds that "interfaces don't matter". There certainly can be really big and long arguments over whether a particular aspect of an interface is a wart or not, but that's quite different than refusing to fix a wart that everyone agrees is there.

As for the examples you mention with Knetworkmanager -- those certainly sound like irritations that most folks using it would like to see gone -- likely including some developers. It is frustrating that the response to filing a description of the problem, or even a specification of how the problem could be resolved, implies that no-one but you is responsible for coding it -- it would be much better (and I've seen this) if the response was, "Thanks for clarifying the solution to this apparent problem; that will make it easier for whoever has the skill and time to implement it." But asking for a patch (from the original submitter or someone else) is a reasonable request -- the code needs to come from somewhere.

Does this match up with what you've been trying to express?

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 13:10 UTC (Thu) by Baylink (guest, #755) [Link]

> I'm still uncertain why you consider that having a badly structured interface doesn't screw up "the base function[ality]".

I consider that having a badly structured interfaces *does* screw up the base functionality; that was most of the point of my post. :-)

> I would be surprised to hear of a project that refused a patch fixing a interface wart on the grounds that "interfaces don't matter".

Most projects would accept *the patch*, it's *the bare report* that they're not interested in... and that was the *rest* of the point of my post.

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 16:37 UTC (Thu) by JesseW (subscriber, #41816) [Link]

Well good, then we agree. Thanks for the discussion! ;-)

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 9:33 UTC (Thu) by Frej (guest, #4165) [Link]

Or just copy the gnome gui. Considerable design resources went in to that.

Although the preferences dialog could use some work - the primary goal (selecting a wireless
network) is hard to assist better than done in nm-applet.

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 17:27 UTC (Thu) by wstephenson (guest, #14795) [Link]

knetworkmanager 0.7 for KDE 3, as shipped in openSUSE 11.0, was written by a kernel hacker, and I jumped in as a KDE developer late in the cycle to do the minimum cleanups needed to get it functional for release. While I am very grateful that Helmut wrote knm3, its UI could do better.

Please have a go of KDE 4 knetworkmanager, currently under development for openSUSE 11.2 and available for 11.1 via the Build Service, and let me know if you think we've improved matters.

LinuxCon: Some advice from Uncle Dirk

Posted Sep 27, 2009 14:19 UTC (Sun) by Baylink (guest, #755) [Link]

Well, I'd love to, but can I *run* that on 11.0? Without installing KDE4 (which I'm still not using)? And if so, does that mean I have to grab the SRPM and build it myself?

(Thanks for this reply, BTW, and my apologies that my own was so delayed.)

LinuxCon: Some advice from Uncle Dirk

Posted Oct 1, 2009 23:41 UTC (Thu) by jmm82 (guest, #59425) [Link]

"But KNM makes me jump though some non-obvious hoops to get anything done, having to know that I must choose "New Connection" in order to teach it about a network I've never been on before, and having to suffer through a popup menu that completely fills the screen of already learned networks when *none of them are in range*... and which is *in the way* of the other menu as I scroll up to do the thing I actually need to do."

Do they have a nm-applet for KDE.

NM in Gnome does not connect to a wireless network automatically unless you have already connected to the network before, but the only time you would have to add a new connection in order to make it appear in the list is for a hidden network. If a network is broadcasting an SSID it will show up in the list and you must click it the first time to connect, but it does not require creating a new connection. Granted it may be a bug in the kde interface.

how does Windows XP do it?

In all fairness it is a Gnome project, just as Amorak(I use Exile now, but it is different) does not run as well on Gnome, Network Manager does not run as well on KDE.

Good points though in your posting.

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 8:12 UTC (Thu) by mjthayer (guest, #39183) [Link]

Something I would like to try coding, when I have time, is a GUI creator which really separates code and design - where the GUI executable created would start a separate, text-only executable to handle everything not related to the UI, would send it all GUI events as lines of text into it's standard input, and receive events as lines of text out of the programme's standard output. Events would be as abstracted as feasible from the UI, somewhat based on Qt's signals.

That way a programmer would be able to write their stuff, doing a very sketchy GUI to support it, and people more interested in design would be able to do their own interfaces without having to get too deep into the code.

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 9:21 UTC (Thu) by hppnq (guest, #14462) [Link]

Something I would like to try coding, when I have time, is a GUI creator which really separates code and design

I can recommend it! Years ago I wrote something that combined a markup language for the graphical stuff and a script language that could handle events, callbacks and other things of a more dynamical nature. It could do more or less what you describe, e.g., read or write text from a file descriptor and have an interpreter do something intelligent with it.

(My problem is to find the time to clean it up and release it. I'm not sure the design was so great. ;-)

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 10:25 UTC (Thu) by spaetz (guest, #32870) [Link]

ever used Glade in which the design could even be a separate .XML file from the binary?

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 11:12 UTC (Thu) by mjthayer (guest, #39183) [Link]

That doesn't quite do what I want, although I would almost certainly use Glade for the actual UI "drawing" in a first version to reduce coding effort and increase the chance of ever getting something working. AFAIK, Glade still requires you to write a lot of binding code yourself in C or python or whatever you are using.

I am thinking of something where all the basic communication between GUI components could be set up in a Qt-like signal-slot way, but without any real coding, and communication between the UI and the (pure console) main programme would also be done via signals from the UI to the programme's standard input, mapped to text strings - e.g.

'MySignal selected "some dropdown entry"',

where "MySignal" is a signal identifier shared between programme and UI - and something similar from the programme's standard output back to the UI (updating graphics would probably be one of the trickiest bits here).

LinuxCon: Some advice from Uncle Dirk

Posted Sep 25, 2009 6:03 UTC (Fri) by magnus (subscriber, #34778) [Link]

Having the communication at that low level would mean that your non-GUI process would need to know lots of detail about the GUI side (which controls exists etc) so you wouldn't achieve any real separation between the two.

To make this separation work well, you would need to make your text-only process like a server that handles the application's state only, and the GUI process is the more active part that sends queries and requests to change the state.

For many applications a bit part of the code is in the GUI handling, and I don't think you can get away from that. What you could possibly do is move the GUI handling code to a scripting language like Javascript which many designers are familiar with.

LinuxCon: Some advice from Uncle Dirk

Posted Sep 25, 2009 9:59 UTC (Fri) by anselm (subscriber, #2796) [Link]

Congratulations. You just re-invented Tcl/Tk -- after ... what? 17 years? :^)

LinuxCon: Some advice from Uncle Dirk

Posted Sep 25, 2009 10:10 UTC (Fri) by mjthayer (guest, #39183) [Link]

Except that Tcl applications had to be written in Tcl, which might put off some developers :) (I do seem to remember that Tk could be coupled to other things, but I don't remember that taking off). But was a Tk GUI really that easy for a non-programmer to rip out and replace without changing the underlying application?

LinuxCon: Some advice from Uncle Dirk

Posted Sep 25, 2009 13:58 UTC (Fri) by anselm (subscriber, #2796) [Link]

The original idea behind Tcl/Tk was that the meat of an application would be written in a language like C, and its functionality be made available as Tcl commands. These Tcl commands could then be used to »script« the application, to allow automated testing, or -- in conjunction with Tk -- to create a GUI for the application. Hence the actual application code (in C, mostly) and the GUI code (in Tcl/Tk) would be neatly separated. This approach was (and presumably still is) used to great effect, for example, in various VLSI design applications.

Tcl got much of its bad reputation because people would try to write big(gish) programs in Tcl itself rather than subscribe to the philosophy outlined above. It took the language some time to acquire the necessary properties to be really useful for larger applications, but by that time much of the damage was already done. Tcl/Tk did earn its inventor, John K. Ousterhout, an ACM Software System Award in 1997 (something that all the other X11 toolkits have yet to achieve), so it is officially a Good Idea.

It is worth noting that when Tcl/Tk came out (early 1990s) it was running rings around its competitors such as OSF/Motif as far as ease of development was concerned. It can also be surmised that if, instead of inventing various other X11 toolkits from scratch, the community had poured the same amount of effort into improving Tcl/Tk (which already existed and worked quite well), we would all be much better off :^) For example, Gtk started out as the »GIMP toolkit«, but if the original developers of the GIMP had decided to come up with a better Tk canvas widget rather than implement a complete new X11 toolkit from the ground up, they could have saved themselves a whole amount of work, and the GIMP would be a better program even today. This is the NIH phenomenon at work.

LinuxCon: Some advice from Uncle Dirk

Posted Sep 25, 2009 16:00 UTC (Fri) by mjthayer (guest, #39183) [Link]

>The original idea behind Tcl/Tk was that the meat of an application would be written in a language like C, and its functionality be made available as Tcl commands.
Indeed, in my first proper job I worked on a scripting language for processing vector data which was based on Tcl.

>This is the NIH phenomenon at work.
I wonder whether how much of the (useful part of the) current FOSS ecosystem would exist without all that NIH though :) Perhaps we would all be using Windows or Macs. Be that as it may, if I ever get round to implementing the thing I discussed above, it is likely to be as a lightweight binding for Glade-3, which looks like it does ninety percent or more of what I am looking for now.

LinuxCon: Some advice from Uncle Dirk

Posted Sep 25, 2009 10:05 UTC (Fri) by mjthayer (guest, #39183) [Link]

My personal suspicion is that the approach I am pushing will work well up to a certain point, but will not scale beyond that. It will depend how much can be achieved by connecting UI components with signals and slots (and how many clever solutions people can find to increase that). As a simplified example: the signal "File menu/open" would be connected to "File chooser dialogue/show", the different components would also be connected to one another ("Directory view/select directory" to "File view/change directory") and "File view/select" would be connected to "File chooser dialogue/hide" and to a text signal into the text process: "OpenFile <filename>". The question is how many uncomfortable details my simplified example simplifies away, but thinking back to Visual Basic 1 (the only one I ever used), I do think that it could work for some applications.

The other point I am hoping may hold is that many more complex applications are built around a single main central widget. For example in MS Word, that would be the editor widget. I hope that at least for some applications, it will be possible for the text controller process to hold some state about that widget (the visible size, the position of the scrollbars), to accept a few events like key pressed, mouse clicked, mouse dragged, scroll down, refresh rectangle and to send a few, like fill rectangle with bitmap, change vertical scroll range, place cursor, while still not knowing implementation details like what the widgets are called, exactly where the scrollbars are and what they look like and so on. (In other words, behave as if it were managing a full screen application like a DOS editor, rather than worrying about the full complexity of a GUI).

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 13:34 UTC (Thu) by Baylink (guest, #755) [Link]

Yes!

This is probably the best design pattern of any for GUI interfaced software; ironically, it's a pretty good description of an AJAX web app: constrain the GUI/app interface to a nice texty 'telnet' channel.

Among other things, this not only makes replacing the interface easier, it *also* makes *scripting* the interface -- say for testing -- easier as well.

It's not as *easy*... but it's worth it.

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 13:45 UTC (Thu) by mjthayer (guest, #39183) [Link]

I will let you know if I ever actually get anything done then! (Although it will definitely not be any time soon, as I have too many other distractions in the real world just now :) )

LinuxCon: Some advice from Uncle Dirk

Posted Sep 25, 2009 6:42 UTC (Fri) by eru (subscriber, #2753) [Link]

This idea reminds me of a description of HUT Windows, an old (1980's) experimental window system from the Helsinki University of Technology (never used it, saw a demo once and read a booklet, which I might still have somewhere on paper). Another similar system might be AntiRight (http://www.nongnu.org/antiright/).

Who is a designer?

Posted Sep 24, 2009 3:55 UTC (Thu) by jameslivingston (guest, #57330) [Link]

I think a big problem is that most developers don't know how to judge the skills of a designer, to find out if they're worth listening to.

When being maintainer of some open-source software, I can usually tell which people are worth listening to on programming topics, because I'm a programmer. However when several people offer advice on design, how can I tell who actually knows about design, and who is just someone telling me what they would personally like?

Who is a designer?

Posted Sep 26, 2009 19:05 UTC (Sat) by man_ls (guest, #15091) [Link]

A designer is still supposed to bring out rational arguments that make sense. See Baylink's comment above for knetworkmanager: it is not as if you need a usability lab to find out that it sucks. You just have to decide to spend your money or efforts on such issues.

Do you have an example where it would not be so easy to tell?

"not interested in desktops"

Posted Sep 24, 2009 4:26 UTC (Thu) by eru (subscriber, #2753) [Link]

People who are buying computers now are not interested in desktops, and they do not really care about the operating system they are running. What they want is to join communities.

That pretty well describes many nontechnical users I know: The browser is practically the only app they use. All the other junk in the computer is there only for supporting the browser.

Given that, it is a bit mysterious why Linux failed to take off on netbooks. Maybe the unpolished bits (like clumsy network manager UIs mentioned in other responses) really mattered. Another is the fact that the "net" is not just HTML and JavaScript, but also proprietary codecs and plugins, and nontechnical users expect all these to Just Work, and have no patience for explanations about closed formats, patents and licenses.

Microsoft threats killed the Linux netbook, not a lack of quality

Posted Sep 24, 2009 4:51 UTC (Thu) by JesseW (subscriber, #41816) [Link]

It's not a big mystery why Linux didn't take off on netbooks. It didn't take off because Microsoft threatened the OEMs with loss of access to Micrsoft's products if they continued to offer alternatives. And the OEMs caved, because no matter how many non-MS machines they sold, they were not in a position to go cold turkey and drop all their sales of Windows. It had little to do with the quality or lack thereof of Linux, and all to do with Microsoft's market power.

I should clarify though -- the "three-click-problem" likely did play a role in the degree of sales the OEMs got, and how people liked their laptops when they got them. But without Microsoft's threats, the OEMs would have been quite willing to sell both Linux and Windows netbooks (with the Linux ones going for a significantly cheaper price, due to the lack of license fees to Microsoft). The disappearance of the Linux netbooks is due to threats, not quality issues.

Microsoft threats killed the Linux netbook, not a lack of quality

Posted Sep 24, 2009 9:20 UTC (Thu) by tajyrink (subscriber, #2750) [Link]

The also dropped Windows' price to one fourth of the original, for netbooks. Which is actually something of an advancement in its own right. Of course, the actual value of their software might be described as less than zero, but still.

Microsoft threats killed the Linux netbook, not a lack of quality

Posted Sep 24, 2009 14:10 UTC (Thu) by Trelane (subscriber, #56877) [Link]

Except now that they've killed Linux on the netbook, they've jacked up the prices for Windows 7 "Starter" (ugh) http://arstechnica.com/microsoft/news/2009/06/microsoft-c...

ARM netbooks and places like System76 continue to be our friends. Maybe we can yet keep this genie out of the bottle.

Microsoft threats killed the Linux netbook, not a lack of quality

Posted Sep 24, 2009 10:39 UTC (Thu) by cortana (subscriber, #24596) [Link]

Is there any hard evidence to back these allegations up? If proven, the allegations sound like the kind of thing that the US and EU antitrust regulators should be interested in.

Microsoft threats killed the Linux netbook, not a lack of quality

Posted Sep 25, 2009 5:44 UTC (Fri) by eru (subscriber, #2753) [Link]

Pretty unlikely there would ever be very much hard evidence. MS probably would want to avoid that, in order not to make things too easy for antitrust officials any more. Anyway, for more allegations I found @ Groklaw: http://www.groklaw.net/article.php?story=20090619161307529

Wondering if contacting a MEP from my country would be any good for alerting EU?

Microsoft threats killed the Linux netbook, not a lack of quality

Posted Oct 2, 2009 3:44 UTC (Fri) by gdt (subscriber, #6284) [Link]

It was a more complicated picture than that. Say you are a importing distributor. Do you import the Windows machine or the Linux machine? You probably don't want to import both, since that doubles the SKUs. What it really needed was a sales person to visit the distributor and make the pitch. Microsoft sent its sales people in, the Linux distribution didn't. And yeah, partly that's Asus's fault for choosing a distribution which lacks that sort of resources.

The real shame is that Ubuntu 9.10 UNR on my EeePc 901 and Aspire One kicks butt. They are the best truly portable computer I've used since the Tandy Model 100, and a illustration that free software *can* do fine design and 100%-complete polish. The experience leaves Windows Xp and 7 in the dust. Canonical should be at Asus now, pitching them a change of distribution. But given the poor history of Linux sales promotion...

on the Ribbon interface

Posted Sep 24, 2009 15:08 UTC (Thu) by kh (subscriber, #19413) [Link]

I'm just really glad I'm not the only one who thinks the Ribbon sucks.
(Especially Microsoft's implementation of it, where it cannot be customized to fit the needs of an individual, and it takes a huge horizontal space just when widescreen and small netbook widescreen monitors are becoming ubiquitous.)


Copyright © 2009, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds