cies' blog

corporate influence in FLOSS projects

2007-12-13T11:34:00.000+01:00

i read some of the many writings on the strange positions some of gnomes prominent members seem to take. to me it boils down to: the relation of corporations and FLOSS projects.

as FLOSS grows (and grows, and grows) it becomes more and more important/interesting/dangerous for corporations. so they will try to influence particular projects. as FLOSS projects are very different from businesses (thank god), the means of influence corporations have are also very different. for instance, they cannot just buy them out.

when i look at how gnome is influenced by corporations the last years, i see a lot of resistance from its community on this influence: simplifying the interface, going mono, and the recent positions of some of its prominent members. all with a lot of resistance from the gnome community. i feel that the way corporations push gnome is not the way its community would like to go.

on the other had there is the kde project and trolltech as kde's the biggest corporate influence. it is in kde's case trolltechs influence is (for all i know) always welcomed... why? i think because trolltech simply pushes kde in the direction that the kde community is already going. it only facilitates.

look at the phonon news from today, isnt that beautiful?

i think that the relationship between kde and trolltech -- that was once regarded as evil and thereby spawned gnome -- is one of the most beautiful examples of a relation between a FLOSS project and a corporation that satisfies both parties. thank you trolltech!

Sun (et al) please help...

2007-07-19T01:47:00.000+02:00

Okay MS is worried of the GPL3... Now we need at least some of the 'heavy weight' projects (thank you SAMBA for being quick) to convert to GPL3 minimum. But many code bases, like KDE, have individual owners.

I think Sun and some other more 'commercial' projects (Qt?) could right now strike MS a hard blow, as their code bases have usually no individual owners. (Sun; you got them to your knees) The GPL3 code base has to be too large and fast moving for MS-deal-ridden-distribution to either fork or ignore.

I don't know how KDE contributers are generally feeling about the GPLv3, but they have my vote on '3 minimum'.

linux race car

2007-05-09T20:35:00.000+02:00

i like funny initiatives, sure, i like FLOSS... but car racing? isn't that a really proprietary business? the 180DEG contrary of our 'open innovation' movement? why would linux need a medium like that, so elite, so money burning, so commercial...

$350000, gosh that is a lot. that is 2000 $175 costing 100-dollar-laptops. that is... forget it.

maybe i just don't get the point of car racing in general.

openSUSE 10.2 to kubuntu 6.10

2007-01-31T00:07:00.000+01:00

i went to suse when they where in their 8.x or 9.x releases. i loved it, i came from gentoo, suse just helped me to get the work done. strangely suse also felt a lot snappier than my tweaked-n-tuned on-the-edge gentoo install.

but since the 10.x releases suse had lost me bit by bit. they sure made everything look more sexy: their latest boot splash it just gorgeous. but they didn't do those two things right that keep my hooked on linux and freesoftware in general:

1) package management
2) transperancy

package management

YAST sucks more with every release. i once loved it so much, but it seems like it is never improved. calculating dependencies, adding sources, retrieving updates -- it all takes way too long, give me bad feedback of what it is doing and is not really untuitive. at some point i was waiting for over 15 minutes to get a simple (<1MB) package installed! i know there is something like SMART and apt4rpm, but i think package management is what a distro is basically all about: if it can't do that right out of the box, i'm not using it.

transperancy

to be honest i did not understand what my openSUSE 10.2 was doing anymore! sometimes my PC was just busy doing something, and when i run 'top' (on the command line), it showed process names i never heard about. maybe i'm getting old. i disabled beagle (seems to slow down everyting), but it seemed to still be running.

i also found another package installer, some updater-thingy. i made my system slow as a brick sometimes. why do i need that thingy?

resolution

so i go for kubuntu, here is what i noticed:

installing:
i like:
- browsing while installing
- installing for a live cd (i can figure somethings out during the install)
- installing a basic system and using the package manager later to finish of my installation
i dislike:
- partitioning; slow and gives bad indication of what it is doing (from an install to a laptop that i did

so kubuntu seems to do the installing process quite to my likings, simplicity rules again. after the system is installed i can go on configuring, i never saw the reason for configuring allmost everything at install time.

using:
i like:
- simple and fast
- adept is nice, aptitude is nice, all so fast compared to YAST! (maybe rpm just sucks?)
- it beeing KDE centric
i dislike:
- the pink color in the default theme looks horrible (tip: go dark blue)
- the bootsplash hides my startup info and i can not unhide it

so basically all i dislike is 'cosmetics' that i can easily change to suit my likings.

conclusion

i don't want to draw a conclusion like "suse is bad". i liked suse a lot. they where clearly a desktop leader for some years -- they pushed the envelope of what a free desktop can do. now i just seem to like kubuntu more.

free energy

2006-12-05T03:21:00.000+01:00

after reading some things, and seeing some movies, i got totally obsessed by the idea of "free energy". for the uninformed: some say that energy is freely available in large quantities all around us -- i'm right now one of them. the same people usually also say that we (the people) are kept under-informed by some powers, and that the current electro magnetics branch of physics is flawed.
to condense it down for you, my main break-throughs where:

fully understanding the principle of a MEG, an overunity device (seemingly outputs more that you put in), by reading this simple explaination and applying my dusty high-school level physics (my dad, an electro techinical engeneer by education, and sceptic by heart, also understood it)
seeing that a German company is actually selling EMM (electro magnetic motor) powered generaters -- devices that use the zero-point energy field to generate power
an last but not least: that this stuff is around for at least more than a decade! more than 10 years of wasted oil!

KDE4; some ideas

2006-11-26T14:25:00.000+01:00

in this post i come up with some "just ideas" that cross my mind for KDE4. i have not thorrowly investigated anything, and i may have not the time to implement at least one of these. yet i do want to share them.

so, here i go:

try to minimize the use of small modeless dialogs. like the find and replace dialogs, like "connection problem X" dialogs, like some password dialogs, like download dialogs. most of the time the interaction they request, or the information they provide, can be done from the main window of the app (like the firefox searchbar), and dont need to steal you attention so bluntly by hanging over your workspace

change the current modules stucture of KDE (again: just an idea)

only groups of apps that share their specific libs should have a module (kde-pim, koffice)
ofcourse we need kde-libs and kde-base
the rest could be in app repositories that show the state and/or level of inclusion into kde (something like: kde-apps, kde-apps-testing, kde-apps-unstable, kde-apps-unmaintained and the same for contibuted-apps-*)

name (at least) the KDE4 release (i like Roberto's "Kaleidos", so it will be "KDE Kaleidos") -- we can always name KDE5 something else... this way KDE becomes the 'brand' name, Kaleidos the central product.

i once (on the 2004 aKademy) saw a CIG (corporate identity guide) about the use of colors and logo's... i really liked the ideas in there, i loved the colour pallet.

KDE4 should do notifications well, all notification must run though a notification manager (maybe a part of plasma) that can decide based on user preferences how a notification should be handled (probably using notification categories)

co-create (probably together with the gnome team, through freedesktop.org) and comply with unified DBUS interfaces for some desktop services like: the notifications handler, the wallet, the system tray, ... (more ideas anyone?) the portland/DAPI looks like strong force in that desktop service infrastructure direction.

do something to unify KIO-slaves and gnome-VFS, probably using "fuse", see my last post.

kwin4: master of eyecandy (maybe rename it to something hip), i have good feelings that KDE can bring the eyecandy we've all seen with beryl/compriz to defacto userland; usable, configurable, sensible, with good defaults and a fall-back mode.

do mimetype-application associations good (using a minimum of popups). i have never liked they way assosiations are handled in KDE, i dont know why but it somehow always annoys me -- maybe it is just my inability to set it up properly.

please note that i have by no means the skills nor the time to implement these proposals. i also didnt discus these ideas with anyone. so basically it is just dumping some ideas. feel free to comment!

is FUSE a solution?

2006-10-28T16:08:00.000+02:00

in the recent kubuntu 6.10 announcement on the dot i found some complaints about the kio-slave system and the 'protocol' wild growth it has started. i read this complaint before, i guess it was on planetkde.

nice all those complaints, but what about a solution? i think a solution discussing is nicer, more positive, than a re-re-re-discussing a problem. so let me give it a shot. ;-)

it is mentioned that KDE should not solve this problem, but that it should be solved at a lower level. i agree since it is a problem that, for instance, GNOME (using VFS) and console apps. i didn't do a full literature research to see what solutions are out there -- i just want to push one: FUSE. yet FUSE needs some kind of wrapping to make it easily accessible by a GUI. maybe DBUS can come in handy here.

my suggestion: what about an 'icon' that you have somewhere -- like the cdrom icon -- that can be mounted/unmounted automatically or manually. this icon, when mounted, can just act as a FUSE folder: this way both KDE, GNOME, , console apps... everyone can use this!

what does it need?

i think the best way to do this is by freedesktop.org, since it uses DBUS. but concole apps need to be able to use it aswell. the file can just be a .desktop (XDG style) file, when mounted a directory by the same name (except for the .desktop ofcourse) is created where the FUSE FS is mounted; the magic-trick is that the file managers just show one icon only which is a 'special file' that is sometimes a directory. in console land we need a command to do this or an extention to mount.

example:

there is a file called "cies@breijs.com.desktop", it shows as an 'FS over SSH' connection icon, internally is is an XDG style text file. right-click -> properties on this icon shows me some additional info, i could also change the name of this 'icon'. double clicking opens the connection (the icon changes), and suddenly the 'icon file' is now a directory. below the surface a directory is created with the same name (minus the .desktop), yet both the directory and the icon show as one, at the new directory the FUSE-FS is mounted.

this is a solution to:
- the VFS KIO-slave incompatibility
- the fact that VFS and KIO-slaves don't work well with console apps.
- the wild growth of 'protocols' (media://, system://, etc.) in KDE
- iirc VFS also has issues

many KIO-slaves already have a similar implementation in FUSE. the whole thing just has to be wraped up by something that i don't yet exactly know what it will look like.

please treat this post as a request for comment on a idea, it is not yet fully materialized and i am deffinitly not the one who should make this kind of descisions. yet i had to come up with something contructive on this issue.

KDE and QtJava

2005-11-13T22:30:00.000+01:00

Recently Trolltech announced that they will releasing Java bindings. We used to have Qt and KDE Java bindings (by Richard Dale) but they never managed to attract much interest. What will Trolltech do to make their Java bindings a succes? I believe they will be.

Times also have changed a little, Java 1.5 copied some usefull C/C++ features (mainly templates and enums). I guess the upcoming QtJava bindings by Trolltech will depend on Java 1.5.
There is also a lot of effort put in a 'free' Java lately. GCC sports a Java front-end for a while called GCJ that compiles java code -> byte code -> executables, there is the GNU Classpath implementation of the 'standard java lib', and there is an ever growing list of free JVMs.

Qt has a long history of running on many platforms, all of Qt will just be platform optimised C++, Java will only be a thin layer. So Qt has the potential to make Java GUIs very responsive.

I wonder what a QtJava app will run like when it is compiled using GCJ and GNU Classpath to a native executable. And I wonder what it will code like since the experiences I had so far with Java in Eclipse where amazing, it felt like Eclipse and I where coding together. Programming in Qt style C++ is nice, but personally I'd prefer a highler level language like Java (with a garbage collector and no worries over pointers, references and build systems).

Qt does not use Exceptions because of portability issues (iirc), will there be some Exceptions added in the Java bindings? I hope so.

My final thought is: What about a Qt-SWT bridge? IBM supposedly worked on such a bridge but cancelled it. Many is said about this. Since SWT is seems to become the usefull standard GUI package in the Java world, it would be nice if SWT apps looked cute in KDE.

KDE4, dialogs, Kopete styles and KTurtle

2005-11-12T16:33:00.000+01:00

i never felt enough need to blog... yet. well... here it is; enjoy.

KDE 4
below you find some of my thought on KDE4, please dont take them too serious, there just some ideas i have in mind.

so: in KDE 4 it might be nice to...

...minimize the use of dialogs; like the find and replace dialogs, they can be put them in search/sidebars (like the firefox searchbar)) -- there is a big anti-dialog rant below

...make the shade the mainwindow (as in less brightness) when it has a modal dialog (like OSX attaches the modal dialog to the mainwindow)

...change the current modules stucture of KDE:

only groups of apps that share their specific libs should have a module (kde-pim, koffice)
keep kdelibs and kdebase
the rest could be in app repositories that show the state and/or level of inclusion into kde (something like: kde-apps, kde-apps-testing, kde-apps-unstable, kde-apps-unmaintained and the same for contibuted-apps-*)

...name (at least) the KDE4 release (i like Roberto's "Kaleidos", so it will be "KDE Kaleidos") -- we can always name KDE5 something else (KDE "Hasta", anyone? :-)

...use the CIG (corporate identity guide -- about the use of colors and logo's), even though it might not be finished yet. i something like a draft of the KDE CIG once on the 2004 aKademy, i liked what was in there, it looked solid.

Some more ranting about dialogs
I just hate them like popups. Ofcourse we need some (settings, file open/save) but many we dont need. Like all the dialogs showing me a 'status' (saying: "loading...", and sometimes a progress bar), didnt we invent the status bar for that? Also all the dialogs telling me about some error, cant i just be noted of the error in the content of the application? (I'm not talking about Dr.Konqi -- i dont want to make him mad)

There are many cases in which we can ditch dialogs. Maybe it is an idea to write a little guideline thing for when, and when-not to use dialogs.
I also hope that in KDE4 the often discussed universial (down)load manager will be there. Then all the "Loading..." dialogs can but put in there.

Kopete styles
after making Efficient, a Kopete style (right now the most popular in kde-look), got into some problems with kopete styles in XML/XSL. there are some serious memory and cpu issues with the current solution, and it is quite difficult to extend the current solution without making it even more resource hogging.
many good looking themes use the notorious "TransformAllMessages" flag and some ugly hacks. this is a pity. to make it work nice a lot of caching within the XSLT has to be done. alltogether it is not easy...
i went dreaming of an alternative.

i thought it might be better to have the sytes as a plugin (c++), instead of an XSLT. This would be fast, but than the styles will not be x-platform anymore, the plugin would likely be able to crash Kopete, and it would be difficult to be made by 'users'.

then i thought of KJS... it is in KDE already and it would fit the bill nicely (IMO). Having the kopete styles in KJS would solve quite a few problems. final question: will KJSEmbed (or QSA) be in a KDE4 base install, so all applications can make use of it?

KTurtle
i have been working hard on a rewrite of KTurtle. it is right now mainly on my harddisk and a backup, but if anyone would like to help i can put it in some repository.

i first rewrote the interpreter. all commands are now meta-programmed by a ruby script (so a new command can be created by adding code in one or two places). the interpreter is statefull and much cleaner in in code. i also ported the whole thing to qt4(.1-snapshots), i plan to keep it depending on qt4 only for a while and intergate it with KDE4 (libs, buildsystem, etc.) later, keeping a build option for a qt-only build.
right now is have to put some more efford in the GUI, the canvas, and the intergration with the interpreter before i have something nice to show.

First blog

2004-10-20T18:15:00.000+02:00

MyFirstBlog(tm) how cool!
Now I hope I can make a habit out of this...