GNOME Zeitgeist is NOT a file manager
Disclaimer: Due to time constraints, I am not an active Zeitgeist developer right now. Seif Lotfy is the man.
GNOME Zeitgeist is a file manager application for the GNOME desktop environment. Instead of providing direct access to the hierarchical file system like most file managers, GNOME Zeitgeist mainly classifies files according to metadata. This includes time and date of previous accesses, location of use (using GPS positioning), file type, tagging and more. In addition to local files, GNOME Zeitgeist also organizes web browsing history, email and other data sources.
What’s wrong? Zeitgeist is not a file manager. The GNOME Activity Journal can be used to replace a file manager and do file manager-like things, but Zeitgeist is more than that. Check the official Zeitgeist website for details.
If you are a Linux user, how do you use Zeitgeist?
bad interpreter: No such file or directory
Earlier today I was trying to run a Python script that I downloaded from the internet. Bash (or the kernel, to be exact) refused to run the script, insisting that python didn’t exist:
$ mem.py -bash: /home/natan/bin/mem.py: /usr/local/bin/python2.5^M: bad interpreter: No such file or directory
The script agreed to run indirectly with python ~/bin/mem.py
I googled and discovered that the file was encoded in DOS format with improper line endings.
To fix the problem, I copied the contents of the file and pasted them into a new file. Voilà. The shebang became magical again.
Then again, you can also fix the problem permanently. (Don’t.)
ln -s sh "sh$(printf "\r")"
photo credit: Sven & Lirion
Linux and Governments
I left Bolzano back for Munich this morning. Here are a few quick thoughts on the Linux Desktop.
- Every year I read four or five magazine articles claiming that this year will be “The Year of the Linux Desktop.” Every article so far has been wrong, but I’m starting to think that this year and coming years will be “The Year that Millions of Users Switched to Linux and Didn’t Even Realize.” After Dave Richard’s talk last year in Boston, I realized that there are some governments and large offices using Linux, but I just didn’t grasp how many. This past week I spoke to a few people about the topic, including Sebastian Faubel, a few employees of the South Tyrol Free Software Center, and others. All of them spoke about the push to switch to FOSS for financial reasons and how Linux is now being used in places that one would never expect.
- If we want this year to be the year of the Linux then we need to start developing differently. Linux needs to stop being the domain of geeks. We need to start targeting older users who are intimidated by computers. This means that we need to stop making assumptions about what users do and don’t understand. We need to focus on simplicity and usability.
- It’s a critical moment right now. As crazy as it sounds, lets stop focusing on 99% of all computer users. Sure, they’re important- and we definitely shouldn’t do anything to stop them from switching- but they’ve already had their “Year of the Linux Desktop.” Lets focus on the remaining 1% of all computers- some of the computers found, lets say, in government offices. We can get Linux installed on them if we develop with those computers in mind.
Applet Languages
At the GNOME Summit, Owen suggested the following:
When trying to decide on a language for applets/widgets, just about everyone will suggest their own favorite language along with reasons why that language is appropriate. However, one thing that needs to be considered is choosing nobody’s favorite language- Javascript.
Owen, I see your point but have to disagree. One of the key purposes of an applet/widget framework should be to allow new and inexperienced developers to easily write their first GNOME application with the smallest learning curve possible. Because of all the people familiar with it, Javascript is an appropriate language, but so are Python and C#.
Before I focus on the advantages of using multiple languages for applet development, I’d like to review a few of the key philosophies that drive GNOME Development:
- Software should be easy and simple to use for new users.
- Software shouldn’t have a large learning curve.
- Different pieces of software for the same platform should use consistent interface elements and share design decisions. Users shouldn’t need to learn new skills in order to use new applications.
When these same philosophies are applied to development and placed in a GNOME specific context their implications are:
- There should be GNOME frameworks that allow developers to easily write applications, even if they have no prior experience with GNOME.
- Developers shouldn’t have to learn many new skills in order to develop their first GNOME application. When possible, they should be able to use their existing knowledge from other platforms.
- Different pieces of software for the same platform should use the same technologies. A developer working on one GNOME application should be able to quickly jump in and contribute to a fellow GNOME developer’s application without needing to learn anything new.
The implications of 2 and 3 are problematic and contradictory. If we allow developers to jump into GNOME Development using all of their existing skills (including intimate knowledge of languages and toolkits), how can we still create a united platform that uses one set of standard and familiar GNOME technologies? More importantly, how can we create a platform with an interface that’s consistent for users?
The solution that’s been followed for the past 11 years is a simple one- Wherever giving developers extra freedom will not hurt the user experience, freedom should be given. In other words, development in multiple languages is fine, but using multiple toolkits is not fine.
This strategy has worked amazingly well. There are a wealth of applications that have been written in C, C++, Python, Mono, and a few other languages. If GNOME had begun with an ironset rule that applications may only be developed in C, we would still be in the dark ages of desktop development with all development done by a few hardcore C junkies. Heck, even if applications were allowed to be written in one “high level” language like Perl- or even the fledgling Python of 1997, for that matter- we would still never be where we are today. All of the goodness that has come out of Mono- and most likely everything that uses pygtk, as well- would have been lost in the curves and twists of a what-if history of GNOME.
The reason GNOME is so diverse and powerful today is because of it’s flexibility with regard to languages and even technologies. We’ve always embraced the new and hot, most recently with Clutter. We’ve also always allowed developers to use as many of their existing coding skills as possible. We’ve taken in developers from just about everywhere- Windows, Mac OS X, the Web, etc- and they‘re the reason that GNOME rocks so much today.
Owen, I’d love to support simplified Javascript applets/widgets, but I can’t imagine doing so without still supporting other types of widgets. There are no statistics regarding how many developers come to GNOME from other platforms, and whether most of them come from web development or desktop development. The one fact is that we do have developers from both ends of the spectrum, and our job is to get as many of them as possible involved with GNOME development. A framework that will alienate half- or even a quarter- of them is not the right answer.
About Me
20 year old undergrad in CS & Physics, co-founder of Freeversation, faux CEO of Politician Market, and former software developer at Check Point.
I am interested in social startups, information security, and robotics. Read more about me
Contact
Email aantny [at] gmail [dot] com. If it's interesting, I can code it.