Posts about kde (old posts, page 8)

2005-07-29 11:11

The ethics of advertising

Just finished reading an article at Timothy Butler's site (see here) and it was a weird feeling.

On one hand, I find the idea of the immorality of avoiding ads strange. I mean, I am watching TV, ads come, I flip. Instantly. That's why I like that my TV has a way to program it to cycle through selected stations. That way I can keep coming back easily, until the ads end.

On magazines and newspapers... well, if someone came and told me that flipping through the ad pages is morally wrong, I would really not give a damn.

But the weird thing is not that (or rather, the other weird thing is something else).

His argument goes like this:

  1. TT has to make money
  2. The way to make money is selling their intellectual property in some cases (in others, it's given for free)
  3. Timothy says that's not ok.

The other hand says:

  1. People who write on websites has to make money.
  2. The way to make money is to put ads on the site.
  3. People are avoiding the ads.
  4. That's not ok.

Those two ideas don't seem to have much in common, but lets rethink the issue, in terms of providing intellectual preperty, be it a website or software.

Suppose TT would make Qt adware. What do you think Timothy's position on Qt would be if he could use it for anything, but the app would always show an animated ad using 30% of the screen. With sound.

That is what websites are providing. Intelectual property as adware. TT is providing intellectual preperty in two ways:

  • As free software
  • As proprietary commercial software.

Of course we know that both properties are the same code, but it is provided in two ways.

I find both delivery mechanisms vastly superior to adware, or nagware. Timothy doesn't.

So, in the same way he suggested KDE and TT to part ways, I suggest how he can avoid all his trouble with adblockers.

Timothy Butler should turn ofb.biz into a paysite. He should charge you if you want to read it.

Or, he should be upfront about it like salon.com is: see this ad, then you can read. Of course now I check salon maybe once a week.

So, the main problem would be, for that solution, that probably noone would pay to read it. Well, welcome to capitalism, Timothy.

2005-07-26 11:04

The evil of sliding

I am not too active in the public speaking business anymore (not that I ever charged for speaking, either ;-).

A few years ago, I would do it about once a month, now it's about twice a year. But I have done it some 50 times, with crowds of up to 1000, and I think I am pretty good at it (but getting worse by the minute). And I have been to a million or two.

And for some reason, I have decided I want to talk about it. Many of the KDE guys & gals have to do it every once in a while, and a bunch will do it in aKademy so, maybe this can help someone :-)

Of course, this is surely the wrong way to do things for 90% of the people, so read without any care ;-)

Entertaining is better than boring

Obvious, right? Well, then why are 99% of these things so dull?

The main reason is, of course, that the one speaking is scared (not nervous. Scared.) , or that he really is a dull person on first contact.

Most of the free software people I know are not dull at all. But when you first talk to them, they are about as interesting as a brick.

That's probably shyness. Most extroverts don't make a living by staying immovile in small places and looking at the same three objects for hours at a time.

So, how can a shy person be interesting quickly? By not trying. For Christ's sake, don't make a joke (unless it's really unavoidable [1]). Just try to chill out, and speak about what you want to say, in a natural tone. Stammer if you have to. Think before answering questions.

Specially, allow the audience to ask questions during your exposition, if you can do it. Who knows, it may not let you say what you wanted to say, but it will let the audience learn about what they want to learn, which is just as good.

It helps a lot if you talk about something you really know. Don't try to overreach. I couldn't speak about C++ development because I am not good enough. Sure, I could give a crappy lecture. Just not a good one.

So, if you have to, stay on a simple topic. The audience will lead you from there, but if they lead you somewhere you don't know... well, say you don't, and then you both can try to figure it out or ask someone else.

Avoid slides unless absolutely necessary

One problem is that they will believe the slides are the lecture. They aren't.

If what you have to say can be said in 30 pages with 6 lines each, then why the hell are you taking 45 minutes to say it? If it can't, then what are they for?

They lock you in a path. Unless it's absolutely necessary that you get a specific message out, I say don't bother.

Use graphics? Sure. Use a live app showing how to do something cool? Sure. A blue background with a picture of app A saying "app A can do something cool"? Yeech.

To connect it with the other one, some people think slides will make things more interesting. Guys slides are incredibly boring. They are more boring than the speaker making funny shadows on the screen.

What the heck, put some nice screensaver hacks and leave it at that.


[1] I was once showing how to rip MP3s in konqi and asked anyone for a audio CD. I got one from a 16 year old. Written in huge letters on top of the CD was "crappy music". I won't say what I said, but you can say your own in the comments ;-)

2005-07-18 10:41

Some more about the docs

Answer to comments on my previous docs item. First of all, chillout people. This is just the blog of a retired guy. It's not exactly Infoworld, ok?

Sorry if I ruined your day, that was not my goal. I had an idea. Nowadays, being a retired guy, when I have an idea, I either code it for myself or put it in my blog so others can read it. Sometimes it works, sometimes it doesn't.

It was not my goal to say that the writers or editor's job is bad. I meant to say that it can get better, and I had a small idea that may help there.

Rainer: hmmm... well, I translated all of KDE 1.0 (or maybe earlier?) to spanish once, before there was a translations team ;-) but I am sure that doesn't count.

I mentioned in the article that there is no need to write docbook, and that you can send plain text to the docs team. I really really did, so don't ride me about it.

BTW: the docs don't say where to send that plain text email. For example, the kcalc manual says the documentation is copyrighted by Bernd Wuebben and Pamela Roberts (in an obfuscated manner, but that's ok).

I am damn sure that if you send Bernd an email with corrections for kcalc's manual, he won't apply them, because he has been out of KDE development for 5 years. Pamela Roberts I don't know.

So, who exactly is one supposed to send a 20 line explanation of the M-buttons to?

Oh, I get it, you are supposed to figure out that docs.kde.org (which is not mentioned in the manual) has a "Contact us" link... which sends you to http://www.kde.org/documentation/ which then suggests you learn docbook (which is not necessary) and go to http://i18n.kde.org/doc/index-script.php where you are told to contact the app author and [email protected].

For a 20-line writeup? Does that sound reasonable?

Maybe the template used to generate the docs could be modified to add something in the last page, like "For contributions or corrections to this manual, please send email to [email protected]".

I mean, if that doesn't ruin your day.

But hey, I can see the attitude of Lauri is more open, at least. And yeah, Lauri, thanks for your job, I'm sorry I dropped the app later :-(

Sorting through the really bad garbage is not all that difficult. Would I offer to triage? Sure, if it's made convenient. Make it come as clearly tagged mail with, say, two hyperlinks in it, one for sending to docs team for further review, one for declaring it crap, I can do a hundred of those a day.

Canllaith: I share the feeling about wiki markup. RestructuredText is nice, if you find a wiki that supports it.

2005-07-17 14:10

Making docs more useful

There are some problems with some of the KDE apps docs. The biggest are:

Superficial:

They explain too broadly, not covering any specific details.

Uneven:

They explain some things in great detail and others not at all. For example, the kcalc docs explain what the lsh operator is. They don't explain what the M+/M-/C/CE buttons do.

Unfocused:

Being uneven is right, as long as what you don't exmplain is obvious (for example, not explaining the button 9 is good).

These problems are common to almost any technical document, and they are not easily fixed. In fact, the only known fix is having a very good technical writer, and a very good technical editor.

Sadly, those are very hard to find. And usually they won't do it for free.

So, here's a proposal for a solution that may make things easier for KDE4.

Open source the docs

Oh, sure, they are open source now. Anyone can hack them. As long as he knows how to get to their source code, which is in docbook.

I understand the docs team is willing to take plain text submissions and format them accordingly, but you can't quite figure that out from the docs themselves.

Even then, the barrier to entry is high, you have to write your explanation, send it through channels, and noone can see it until next release.

My proposal is to integrate in the KDE help viewer a limited wiki-like capability.

The user would have a "annotate this page" prominently displayed somewhere. And he could use that to attach annotations that should be clearly visible on the docs.

And, most importantly, he should be offered a chance to share those annotations, which would be uploaded to a wiki-like system. Said system would be moderated by the current docs team people, who could approve of them.

Then, the doc viewer should also have a feature to update the docs for a version, downloading new pages and annotations from that same system, completing the feedback loop.

Said annotations would then be shown along the docs, and could even be marked as "tips" which would be added to the tip-of-the-day system.

Should be a bit of work, but the KDE hackers are more than up to it, I'm sure :-)

2005-06-05 12:02

Innovative apps and features in KDE

I will be speaking about this subject in 48 hours.

Here's the challenge: post as a comment (if you see this in planetkde, you will have to click somewhere to get to my page) describing your favourite innovative unusual and/or little known feature in KDE!

In a few days, I will post the whole thing as a .swf file somewhere so everyone can see it.

My goal is to make it dazzling, feature-packed, and very fast. If I can get to 100 features in 1 hour, that's about right.

So, what is it?

2005-05-14 16:22

Data aware widgets in KDE

Well, reading in planetkde about how nice data aware widgets would be, I have to say this:

  • Data aware widgets are great
  • Data aware widgets in C++ are not the best possible solution

Using a higher level language, and specifically a more dynamic language makes lots of things much simpler.

As a tiny, lame example, please check the little thing I wrote about data aware widgets in python here.

I am sure that some of our better programmers (or more creative thinkers) can come up with awesome stuff if they divorce from C++ in this subject :-)

2005-05-13 18:13

Pissed off at SSH

Ok, not really, since SSH has made my life much simpler than it would be otherwise, but really, it has some usability issues.

And I mean real usability issues, not the usual crap.

  • It can't be integrated into kdewallet

While there is a mechanism to have a GUI asking the password, this helper app (askpass) doesn't get any session info, so it's meaningless, unles you are trying to directly start a X app over ssh.

Which you probably aren't.

  • Fingerprint management sucks.

Suppose you have a firewall. You keep port 22 as a way to log into it, and forward port 23 to a mail server in the DMZ. Well, it will complain and print huge, scary warnings each time you login into one or the other, depending on which one you used first.

Or, it can simply refuse to connect.

And that's just the easy two.

What can be done?

  • Take the dropbear client (not openssh, dropbear code seems simpler), and put a putty-like UI into it. Use the konsole kpart for display.
  • Take the GTK version of Putty and hack it into KDE shape, put kdewallet in it. I don't quite like the idea of having a seaparate, different terminal app for remote sessions.

I would probably go the dropbear route if:

  1. I had a working PyKDE (maybe someday)
  2. The idea of delving into someone else's C code didn't make me nauseous. (probably after I surgically remove my sense of taste).

2005-05-13 10:34

KDE at Software Libre2005

I will be speaking at the Software Libre 2005 event, June 7 at 2PM, at the Sheraton Retiro, Buenos Aires.

I'd invite everyone, but it costs some money, so I will just say that I promise to buy a beer for everyone mentioning this blog. (Limit 10 beers, only national ones allowed)

For more info, click on "read more"


Voy a dar una charla en Software Libre 2005, el 7 de Junio a las 14 horas, en el Sheraton Retiro, Buenos Aires.

Invitaria a todo el mundo, pero cuesta dinero, asi que solamente los invito con una cerveza si mencionan esta pagina. (Limite 10 cervezas, solo nacionales)

Para mas datos, click en "Read more"

2005-03-17 23:59

Linux: a not-unix-like OS.

Well, I am still experimenting with my concept-distro.

I am now up to a running PyQt using uClibc, which I thought unlikely ;-)

I completely removed all the sysv init stuff, and replaced it with runit, which has an interesting effect:

It boots to a graphical login in about 15 seconds. Inside qemu. In a 900Mhz duron. Including kernel loading.

Of course the trick is that you have the login while stuff is still loading, but I am working on that, too.

Since using runit it's pretty simple to get a overview of where the booting process is (services have dependencies, they simply get started in order, and in parallel), I will hack a system-wide ksplash-like thing on a side of the xdm (probably will end up writing my own whateverdm).

Think of it as Fedora's rhgb, only you can login instead of getting bored.

I also switched to a root-free system Ubuntu style. Not decided yet on it, but it's not hard to do (or use).

Next step: hack Knoppix HW-detection script (or rather rewrite them in a real language).

I understand why there are 743 Linux distros. It's quite a lot of fun to hack one together.

Oh, and it needs a name. It's not going to be useful for anyone, it's just a personal toy, but it needs one.

Come on, Planetkde guys, throw me names for a non-unix like linux, if you dare ;-)

2005-03-15 23:59

Source-based distributions, the good side.

I am no fan of source-based distributions. I think that for most practical purposes, a distribution where installing KDE takes over a day (I own a lowly Duron as my fast computer) is useless.

However, they are good for one particular niche.

Custom distributions. Weird distributions. Personal distributions.

I have several computers. Most of them too slow and small.

As I was considering reinstalling Linux on my Libretto for fun, I looked at what was installed in it, and decided that really, 90% of it was of no use whatsoever.

The problem was, since it had Debian installed, it has a rather wide network of dependencies that simply could not be done without.

On a regular computer, that's not an issue, but in this tiny workhorse, with 16MB of RAM and a 800MB HD, it makes a lot of difference. The smallest I could get Debian to be, and still have network, PCMCIA and X11, was about 250MB.

And the performance was not awesome, either (but not terrible).

So, what would happen if instead of a regular distribution it had something like this:

  • uClibc instead of glibc
  • runit instead of SYSVinit
  • dropbear instead of OpenSSH
  • X built as kdrive (formerly tinyX)
  • python/qt (or maybe python/fltk) for basic admin tools

And so on. Basically rejigger the whole software selection slanting it towards the small side, and dropping a bazillion non-fundamental dependencies along the way.

Well, it can be done. It's just that it's a heck of a lot of work. But here, a source-based distribution gives you a headstart.

For example, I decided to start from ucrux, a uClibc-based port of Crux. Since the native toolchain in ucrux is uClibc, I don't have to worry much about a whole class of mess that happens when you build uClibc-based binaries on a glibc-based system (it's practically cross-compiling).

Qemu lets me install ucrux and work on it somewhat faster than on the target P75 (if I could make KQEmu work I'd be happiest).

Since crux's software packaging mechanism is simplicity itself (a shell script that installs to a fake root), although it's severely underpowered (no dependencies), I can start from ucrux, hack the build of one package at a time, then put everything on a CD very quickly.

So, if you want to hack your own distribution, Crux (or some other similar kit) is quite a nice thing.

For general use... well, my requirements start at apt-get or equivalent ;-)

Now, if only TinyCC worked for more programs, that P75 would be a pocket development powerhouse!

Contents © 2000-2018 Roberto Alsina