Tuesday, April 12, 2005

Hotel Rwanda; fish://; FD.o

summaries time!

FD.o



in short, here's what i think would help FD.o:


  1. create a clear, concise "what the heck we're doing" mission statement that has no wishy-washyness to it. then publicize that. public perception is not in line with what FreeDesktop.org is doing, and that causes problems for those of us promoting it

  2. be honest about what we're doing on FreeDesktop.org. it's not another SourceForge; it's a place where software and specifications are created in the hopes of becoming de facto standards. there is more responsibility here than simply being a place to slap software around.

  3. be less cavalier in the software design process and include more of the community that is actually involved in the specific areas. in other words, make the software projects side of it less of a self-selected group and more of a cooperative invitational affair. reach out to those it will affect, reach out to those already working on the technologies in question, get rid of the "my pet project" mentality.



this is part political and part practical, but both are important. i want to see FD.o succeed, but it's becoming harder to support that aim when the perception of it erodes amongst the audiences it tries to address.

to date the software projects on FD.o have been less than successful. Cairo is being used by Gtk+, but pretty much everyone else i've talked to is unhappy with it (though the consensus is that things are moving in a positive direction and eventually maybe one day it'll "get there"). DBUS is not the best technical solution for KDE right now (i won't speak for anyone else), and the recent API breakage really screwed things up for KDE's media ioslave. (thank the goddess we don't use it in more places yet). pkg-config has been an interesting experience... i could go on.

and it's not because the people working on these things are poor hackers. they are some of the more intelligent people i've run into in my life with some serious skills. it's the process that is being used that is helping the projects coming out of FD.o consistently underperform. as FD.o moves on to ever more serious and critical issues like configuration systems and file system abstractions we can't have this and have a sustainable FD.o.

if you're wondering where i get these viewpoints, it's from talking to and, then more importantly, listening to a rather large number of people in a number of venues who work with, or at least try to work with, these technologies. this is not a set of phantoms of my own making, but the collected impressions of those who quietly succeed, struggle or suffer with the processes of FD.o.

on the joys of questioning the status quo



btw, in case anyone wonders: no, i do not enjoy questioning the status quo, because it usually results in a very non-fun personal experience. there is twice the burdon of proof put on the one questioning the way things are than there is on the person supporting the way things are (this is natural). there are also a lot of people out there who do not react well to the concept that things may not all be fine.

i think we coasted for a good while with more cheerleaders than critical thinkers being heard. we're rounding a corner, though. i'm seeing more people stepping up and saying, "Ok, let's change things." that includes the people in leadership roles at FD.o, it includes people i've met in the more traditional side of the industry of late, it includes people who are coordinating things in KDE.

i tip my hat to these individuals, because i do realize that it is not an easy ride all the time. it's rewarding, but that's something different.

fish://



i've received a lot of feedback from my last blog entry about fish:// ... so many of our users were unaware of its existence or still don't know how to make it work.

here's the skinny on it:

if you have an ssh account on a machine, you can access your files on it via fish. let's say you have an account foo@bar.com and wanted to get at /var/www/html. the url would be fish://foo@bar.com/var/www/html. it's just that simple. there's no need to set up anything on the server, just a plain ol'd ssh account.

btw, if the username you are logging into on the remote machine is the same as the one you are currently logged into, you can just do fish://bar.com/var/www/html. wicked!

Hotel Rwanda



tonight i watched Hotel Rwanda. if you haven't, i would recommend it. something in the horror of those days in Rwanda that the film documents tugs at me saying, "this is part of the thing that we are striving to fill in, to heal and to become aware of."

while it is impossible to truly know a horror that one has never experienced, it is perhaps possible to help prevent such things from needing to happen. our small daily efforts in life are not limited in impact to propelling our economy, or to allowing us to afford another vacation or to producing wonderful solutions to technological puzzles.

we are all capable of conscious compassion, as well as its opposite nature. as a collective of humans spread across the planet but increasingly connected we each have an impact on the totality.

i've pondered the why of life since i can remember; the first time i remember discussing God and his potential existence was when i was 4 .. i don't remember a time when i was not compelled to consider the broader existence. but i still don't have explanations or answers, not even close =) i still do not know how to explain the mechanisms i perceive at work all about me, the great whirring of humanity: a beautiful thing, but unconscious even yet.

experiences like Hotel Rwanda, however, seem to offer a glimpse into the greater depths.

6 comments:

segedunum said...

Well, you'll know much more about what is going on internally at Freedesktop than I would, but I think if people can be honest about the whole thing then that will be a good starting point. It isn't Doomsday by a longshot.

The open source community desperately needs to collaborate better to share more of the workload to accomplish more, and that means through more channels like Freedesktop. I've been a sceptic, but it really is needed. Stuff like DConf really goes beyond any desktop, so people working on it and wanting it to be something more should just go and ask people doing things with Apache, Samba and other major projects "Do you think this is a good idea, and what should it do for you if you wanted it?". The way people talk they obviously want DConf to be much more than a replacement for GConf and KConfig. Whether a unified config system really would solve a lot of interoperability issues is up in the air, but it could certainly help. Wait for all of those 'Windows Registry' comparisons to be thrown at you!

I know many people have pushed DBus hard enough that people think they have alterior motives, or maybe they just like standard bits of software. However, that's all part of that smoke and mirrors thing. There's too much uncertainty to the point where you see things that possibly aren't there. DBus is a good idea, and when it matures it will be an excellent messaging and IPC system going beyond what way DCOP can provide now to the point where people are confident with it. However, replacing a messaging system in a desktop is such a huge undertaking it cannot be overstated. For KDE it is more of a huge issue than most, as DCOP interfaces are KDE's lifeblood. Even if you get something new to work there are many, many quirks to iron out. It's exactly the same for Gnome. You've got to look at immediate practical issues, no matter how good the technology is unfortunately. The issue of GStreamer as a default and the maintainability of interfaces with KDE is probably another, but I'm even less familiar with the multimedia side of things. At least arts doesn't change much so people know where they are with it!

The flip-side is that the longer things are left, the more difficult it is in the future to move to things like DBus in a wholesale fashion. You end up having to make bridges in a way that is transparent to the vast majority of developers. You're also left with a situation where as desktop market share increases, and more people depend on KDE (and especially if ISVs develop with it) you simply can't have a hard and fast break with ABI compatibility as is often proposed widely in the open source community, or as Microsoft has done with .Net in many ways, which is out of character. That isn't just a case of providing previous versions of libraries, but providing transparent access to them through any new libraries.

Anyway, interesting times ahead, especially when Qt4 becomes final.

segedunum said...

Oh yer, forgot.......fish://. That wasn't intended, I promise :).

Oh yer, that's saved me quite a bit of time and effort more than once along with smb, nfs...... and all the other ioslaves I can't remember. The only problem is with smb shares etc. over a network and large files having to be copied when you use them. The only reason why people don't know about it is they don't see it as an option when browsing the network.

If you want to make yourself feel really, really weird, do this: Ponder consciousness and what it is. Sit quietly, look in the mirror and ask "What it is it in me that makes me alive? Why aren't I just a collection of parts?". It's then that you realise that there's something more to life and everything, whether you're religious or not.

You end up feeling rather comforted by it, and not completely devoid of all hope.

leo said...

fish:// rocks. It saves me so much time, along with all the other ioslaves.. The only question I have, why "fish", why not ssh://? It seems like the logical choice...

Diego Calleja said...

I agree with you on FD.o. Recently someone started to discuss about DVFS - a replazament for gnome and kde userspace vfs approachs. I argued for a while that we don't need to do things like kde and gnome did - FUSE is about to be merged in the kernel, and that will allow us to have userspace filesystems The Right Way. With a small difference: There is a single VFS and we don't need to modify 100% of apps to get advantages of them.

(I know people will argue with me that fuse is linux-only, but I say that VFS is something that belongs to the _operative_system_, not to desktop apps, and you can't do a lot if they don't have one. dragonfly will have userspace filesystems at least and hey, you can keep current kioslave/gnome-vfs for compatibility. Pasting a URL from konqueror to your terminal and the terminal failing because it doesn't supports kioslave/gnome-vfs/dvfs is a HUGE inconsistency, one that FUSE can solve without needing to rewrite every damned app to get support)

Aaron Krill said...

Am I the only one that realizes sftp:// accomplishes the same feat?

Aaron J. Seigo said...

> Am I the only one that realizes
> sftp:// accomplishes the same
> feat?

actually, it doesn't. sftp:// requires sftp support to be turned on in the sshd on the server. fish:// simply requires an ssh log in, which is generally always available.

of course, if you only have sftp but no shell logins (i have such things set up on certain boxes for people i don't want logging in but who do need to transfer files), then sftp is your man.