Tue, 31 Mar 2009
Is Ekiga Doomed?
I am more-or-less happy user of ekiga. However, with the latest GNOME release (or two), I am not sure about its future. The new GNOME contains a new instant messaging and voice-over-IP application, Empathy.
I have not tested Empathy yet, but the list of supported protocols look impressive. I wonder how complete this support is, however (like GPG in Jabber/XMPP, SIP call redirection, SIP from behind of NAT using STUN or proxy, etc). I am trying hard not to be a skeptic, but maybe ekiga will join the following list of doomed applications:
- GDM 2.1x
- The rewrite of GDM in Fedora 8 (not sure about version numbers now) took away most of the options (such as the X server command line, automatic login for single-user systems, XDMCP(!)), most of the features are not restored even now, year and half later.
- Sawmill/Sawfish
- It has been deprecated in favor of Metacity, which still cannot do such a simple thing like sending a window to the different workspace using
Ctrl+Alt+Rightand return back by releasing bothAltandRight, and pressing theLeftkey while still holding theCtrlkey. Metacity still requires theCtrlkey to be released first. - Galeon
- Has been deprecated in favor of Epiphany, which still plays catch up
with Galeon feature set (even with its
epiphany-extensionspackage, and despite of the fact the development of Galeon has been dormant for several years now).
I could probably name several other projects. May be this is a trend in GNOME: replace the existing full-featured apps with half-retarded new ones, just because you do not agree with architectural decisions of previous developers, or because (in the GDM case) you need one more feature (fast user switching) which is hard to do in the present code base. And then promise to implement all other features users are used to, and fail to fulfill the promise in several years. In the meantime, get your code merged to the GNOME code base, kicking the previous full-featured application out of it, making the life of its developers harder, and thus cause the development of it to slowly die off.
9 replies for this story:
Vasek Stodulka wrote:
I personally like switching from complicated apps to simple alternatives - maybe because I'm getting more dumb with my age. :-) I must agree that GDM is a mistake, but with other apps I don't have problem with. I'm sympatizing with you, but the development of the world goes on. Five years earlier every application doubled the amount of options with every major version, and if not, then everyone said: "They are in troubles, look at their new version - it has no new functions." Now I feel the situation has changed and people want simple apps, and there are two ways of doing this - first is symplifying the apps - but seriously - is there a developer able to cut some features? Nope. And the second is adoption of brand new simple app. Look at Firefox vs Chrome - five years later, noboby will know what Firefox was, maybe some of us will remember it as "the ughly BIG Netscape successor".
Dr wrote: scklss
"Code complexity is the mother of bloated, hard to use, and totally inconsistent software. With complex code, problems are solved in suboptimal ways, valuable resources are endlessly tied up, performance slows to a halt, and vulnerabilities become a commonplace. The only solution is to scrap the entire project and rewrite it from scratch." http://suckless.org/
Milan Zamazal wrote:
I can also observe that GNOME gets worse and worse. I reinstalled my system completely more than a month ago and I can see there is *no* package containing "gnome" in its name on my computer now. What could demonstrate better that GNOME is completely useless to me? This is not that GNOME applications get more simple, they get more stupid. As for VOIP clients, I use hw phones at home/office and I use Twinkle on my laptop (I switched from Ekiga long time ago). GDM got replaced by KDM, Sawfish by Ratpoison and then StumpWM (I've heard Xmonad may be a good alternative to those who prefer Haskell over Lisp), Galeon by Firefox and then Conkeror. Generally, I tend to switch to applications which are simpler in some sense while being more powerful than their alternatives.
thingie wrote:
I wonder how would you replace libvte (Gnome) based terminals like gnome-terminal. xterm is out of the question, urxvt can't handle agressive resizing that xmonad does (well, it can, but badly), konsole is just a crap (KDE 4 version), and what other options are there? While Gnome itself isn't very good DE, I find its applications like evince or gnome-terminal as the most stable and best options currently available, and it doesn't change.
Yenya wrote: Re: thingie
I absolutely agree. There is nothing which can at least remotely match libvte and evince (and possibly some other apps). GNOME is definitely the "lesser evil" :-)
Matěj wrote: Re: ekiga
I think part of the problem is ekiga 3.* which is really unfortunate piece of ... (don't want to use s-word). With ekiga 2.* I used to have at least some level of success, but what's in Fedora since F-10 (inclusive) in unbearable. Hopefully it will get better, but it is not there yet (by far). Oh well. So currently it is hardware SIP-client for me (which sucks, because I don't have headphones for that).
Pathconf wrote:
I'm using FVWM for long time, have several years old configuration which I'm dragging with me from computer to computer and I'm happy. If FVWM isn't in the repositories of the distribution, I just download it and compile it. I've made countless attempts to switch to something else, but always realize the said thing would need to emulate FVWM at least for my configuration and it simply doesn't have those features. I have always big part of GNOME installed as dependencies to those few programs I'm using, so it's just lying around on the disk doing nothing. It's just another battle between setting up the thing one wants and working with what has been set up for him/her.
Pathconf wrote:
I'm using FVWM for long time, have several years old configuration which I'm dragging with me from computer to computer and I'm happy. If FVWM isn't in the repositories of the distribution, I just download it and compile it. I've made countless attempts to switch to something else, but always realize the said thing would need to emulate FVWM at least for my configuration and it simply doesn't have those features. I have always big part of GNOME installed as dependencies to those few programs I'm using, so it's just lying around on the disk doing nothing. It's just another battle between setting up the thing one wants and working with what has been set up for him/her.
Pathconf wrote:
I'm using FVWM for long time, have several years old configuration which I'm dragging with me from computer to computer and I'm happy. If FVWM isn't in the repositories of the distribution, I just download it and compile it. I've made countless attempts to switch to something else, but always realize the said thing would need to emulate FVWM at least for my configuration and it simply doesn't have those features. I have always big part of GNOME installed as dependencies to those few programs I'm using, so it's just lying around on the disk doing nothing. It's just another battle between setting up the thing one wants and working with what has been set up for him/her.
Reply to this story:
Mon, 30 Mar 2009
Firefox File Input
The daily user-interface annoyance award herby goes to the Firefox (or rather XULRunner,
which means this is present also in Galeon). The problem is in forms
in the <input type="file"> fields. It looks like this:
In Firefox and Galeon, it is impossible to write directly to this field. Which means that even if I already know the file name and can type it really fast, I have to click to the input field, wait for the file input dialog to pop up and get focus, and only then I can type the text in.
Is it possible to disable the pop-up (or make it appear only after clicking
on the Browse button)?
5 replies for this story:
Hynek (Pichi) Vychodil wrote: It's obvious
UI guys are weird. I have realized this when asked our UI guys about this "feature". They replies, it's correct, it's obvious. We surprised with my boss also. You are not alone who think that it is stupid but we are not UI guys, obviously ;-)
Miroslav Suchý wrote:
Touble is that in some browser this input line is not displayed at all. See http://swatelier.info/at/formulare/file.htm It can be done using CSS and JavaScript. See: http://www.quirksmode.org/dom/inputfile.html (scroll down)
Edheldil wrote:
There's actually a good reason for this - security. IIRC the input field was deemed as something that could be easily filled by JS with text like "/etc/passwd", its contents sent without user interaction.
Yenya wrote: Re: Edheldil
Well, security can be reason for disallowing Javascript to meddle with the contents of the field, not for disallowing user to type directly into the box.
Erbureth wrote: Re: Edheldil
I actually like Konqueror's solution for this problem: it asks you, whether you really want to upload files, and displays the names.
Reply to this story:
Sun, 29 Mar 2009
The Oldest Real Bug
I occasionally complain about bugs remaining unfixed for a long time in the Open Source Software, and it really hurts when I spend several hours trying to solve a problem, which turns out to be a known problem reported many years ago, still unfixed.
In our archive of graduate theses, we had a problem that some PDF file could not been displayed when being accessed through the
public part of theses.cz. Displaying it from the authenticated
part of this site or downloading it from either part and then displaying
it locally was OK. Later we have found that even displaying the file from
the public part was OK, provided that the HTTPS instead of HTTP has been used.
The problem is caused by caching: Mozilla thinks it cannot cache the
files downloaded over HTTPS, while it can cache the files downloaded
over HTTP. Mozplugger then does a shortcut of running the PDF viewer
with the file name from the Mozilla cache for the HTTP case, but
downloading the file separately into /tmp directory for
the HTTPS case. Now when the PDF file is bigger than the cache size
limit, Mozilla deletes it from the cache just before Mozplugger starts
the PDF viewer.
This has been reported to the Mozilla Bugzilla in March 2003, six years ago. The latest comment was from May 2004, and the bug is still there. The bug has a "QA Contact" field pointing to a non-existent address, so there is even nobody to complain to. We have worked around the bug by adding an HTTP header which causes Mozilla to avoid caching of the PDF file altogether. I have also reported it downstream, to the Fedora bugzilla, hoping they would know better than me how to push it upstream.
2 replies for this story:
Milan Zamazal wrote:
My experience with bugs reported on Firefox is that they either take long to get fixed and the fixes released (> 1 year) or they get forgotten. So you should probably ping on the bug report, I wouldn't expect anybody cares about old bugs with no activity.
Yenya wrote: Re: ping the bug report
This is what I did, but with non-existent QA contact I wonder whether anybody will read the ping at all.
Reply to this story:
Sat, 28 Mar 2009
Git Snapshots
In his excellent article Git from the bottom up (PDF warning)
John Wiegley writes on page 26 about using
git-stash(1)
as a way of snapshotting the work in proggress, e.g. from cron(8).
He suggest to do git-stash && git-stash apply every hour or so.
It is a nice idea, but it has a problem:
It changes the data under your hands, and there is even a short
window of time (between the stash and apply),
when the local changes temporarily disappear from the working tree.
So during this window it is not possible to e.g. open the file with the
text editor and expect it to have the contents which has been written to it
just several seconds ago.
Can snapshotting be done in Git correctly? Something like "save a current working tree as a new unreferenced commit"? How do you make the snapshots of your work, my dear lazyweb?
4 replies for this story:
Tomáš Janoušek wrote:
`git stash create' seems to do the job. It creates a commit object, leaves index and tree intact and prints the commit's SHA1, so you just need to save that somewhere (using a tag, maybe).
Milan Zamazal wrote:
I'm not sure what you want to achieve. I usually commit often, any significant change. It's useful for several reasons. If I need to backup a larger amount of work without making a commit, I simply copy the corresponding files or directories somewhere, preferably to a remote site. BTW, AFAIK git-stash ignores new files unless they are staged.
Yenya wrote: Re: Tomáš Janoušek
"Git stash create" is almost the thing I am looking for. The only feature it does not have is storing the reference to the commit object somewhere (and preferably, keeping the reference for several weeks only, like reflog does).
Karel Zak wrote:
Hmm.. long patches are bad patches. Commit often and use a real (incremental) backup solution rather than "git-stash from cron". ;-)
Reply to this story:
Fri, 27 Mar 2009
Status Update
I am still alive, but busy doing a real-life work rather than writing about it :-) In the meantime, I have received my results from the JLPT 3 exam: I have passed, but with lower points than I had from JLPT 4 last year. So the next step would be JLPT 2, requiring about 1000 more words and 600 more Kanji, definitely not a task for the next year only.
2 replies for this story:
Peter Kruty wrote: JLPT 3
Congratulations! :)
Spes wrote:
> but busy doing a real-life work rather than writing about it Try microblogging (Twitter, Identi.ca etc.), good for short status updates, comments, feelings... Or 'omedeto gozaimas' as well :)