Open Source, Free Software, and similar
I won’t be joining the attempted world record of Firefox downloads on the release day June 17th 2008 since I dist-upgraded my Debian unstable just a few days ago and I got my Firef… eh Iceweasel version 3 then.
Of course, others have also noted that Firefox will miss a few Linux users downloading that version as Linux users all over will prefer to get it using their distros’ ordinary means of getting packages and updates…
My 19″ (Acer) LCD screen at work died the other day. It started flickering a lot and when I tried to switch it off/on to see if the flickering would go away, it wouldn’t go back on again.
I got a lowly 1280×1024 screen to borrow until my new screen would arrive and I got to experience that using the panning screen thing of Kubuntu (my desktop would remain 1600×1200 since I preferred not to reboot or even shutdown my X) could easily get the mouse coordinates confused and then I had to hurry up to the upper left corner to “reset” the coordinates and then I could again click on the correct items on the screen…
Very well, I got a 24″ 240BW Philips. This being a widescreen thing (they’re really taking over the world, those widescreen versions) it prefers 1920×1200 resolution. My computer had one of them intel graphics chips (82Q963/Q965) on the board and dang, I got no good resolution no matter how I poked the xorg.conf file. After trying out 915resolution, I learned that the graphics card couldn’t in fact show the necessary resolution so I had to insert a card that can. I got a dreaded Nvidia and now I’m using the evil proprietary drivers to get DVI at this resolution…
But I must say that with my 19″ at 1600×1200 and my 20″ at home at the same resolution, bumping up the screen size yet another notch to 24″ makes me think 1920×1200 is kind of on the low side for such a huge screen. I did a quick check on my favourite tech stuff compare site (prisjakt.nu) but it seems there’s no screens with higher resolutions at this size?
I like user feedback and comments from people in projects I participate in – even those that I run or maintain myself. I value bug reports and I think no project can evolve without a fair amount of external input.
But they can also be annoying since when done in public places they tend to stick around. If they’re negative I can respond to them if posted in forums where that is possible and where I care about it, but sometimes they’re just “blurted” out in a way that I cannot respond to and that I cannot do anything about. And the review/comment/complaint will sit there to be watched by the world. Uncommented by me or anyone else thinking otherwise.
Let me point out the recent example that made me write this particular rant: user review on curl at ohloh.
I realize there’s nobody to blame and that this is the way of life and how things work and that everybody is entitled to publish their opinions and all that. It still doesn’t feel really good when you just don’t agree with them and they’re “against” one of your own babies.
I noticed the new site publicsuffix.org that has been setup by the mozilla organization in an attempt to list public suffixes for all TLDs in the world, to basically know how to prevent sites from setting cookies that would span over just about all sites under that “public suffix”.
While I can see what drives this effort and since we have the same underlying problem in curl as well, I have sympathy for the effort. Still, I dread “having to” import and support this entire list in curl only to be able to better work like the browsers in the cookie department. Also, it feels like a cat and mouse race where the list may never be complete anyway. It is doomed to lack entries, or in the worst case list “public suffixes” that aren’t any such public suffixes anymore and thus it’ll prevent sites using that suffix to properly use cookies…
There’s no word on the site if IE or Opera etc are going to join this effort.
Update: there are several people expressing doubts about the virtues of this idea. Like Patrik Fältström on DNSOP.
In the most recent Lugradio podcast Episode 19 Season 5 at roughly 1h30 into the show, we got to hear a user’s write-in explain to the hosts about the benefits of using Rockbox on your ipods. Although the hosts aren’t very impressed… They also later on mention that they did get “a lot of mail about Rockbox” so obviously it is getting quite known out there.
Just minutes ago I uploaded the curl and libcurl 7.18.2 package to the curl site. There are a few new changes that people might just like, but most importantly there are many bug fixes.
And by a happy coincidence, a bunch of #curl visitors (the irc channel on freenode) are going to meet up for lunch on tuesday next week (June 10th) in Stockholm, Sweden. If you’re a curl hacker or curl fan and in the proximity that day, feel free to get in touch and join us!
I just posted about this on the curl-users mailing list and I’ll just echo it here to reach a slightly larger audience:
One of the not so good behaviors of curl is how many of the command line options work when being repeated: toggling on/off.
We’ve got bug reports about this in the past and I know for a fact that this behavior has burnt more than one guy who’s tried to set default options for curl in their .curlrc etc. When they then re-use the same option on the command line or in a script, it effectively disables the option again…
I’d like this corrected. I want people to be able to explicitly enable and disable features with the command line options. I think the toggling is very rarely useful and something we can just abandon – unless we can figure out a way to keep it for backwards compatibility when we introduce the new behavior.
I’m willing to sacrifice some backwards compatibility to get this done, but I would of course like to hurt as few users as possible.
I’m very interested to get ideas and feedback from you guys on how we can accomplish this!
My first thoughts on how to do this, is simply to convert all the current options to enable options and then introduce a new concept that negates the option. Like -v or –verbose to enable verbose, and –no-verbose to disable verbose.
Any bright ideas?
Update: my suggestion above is what has now been committed targeted for the upcoming 7.19.0 release…
With over six months since the previous c-ares release, I’m happy to announce that I’ve just uploaded the 1.5.2 tarball to the usual c-ares project place.
The changes aren’t major in any way, but they’re improvements and they’re pushing c-ares forwards. You can browse the RELEASE-NOTES off the cvsweb.
Back at FSCONS ’07, I asked the guy doing the Openmoko presentation about whether they are going GTK or Qt, as his talk mentioned both and he didn’t really spell it out on what horse they were putting their money on. He then thought it was a really funny question and went on to explain how the Openmoko is like a small computer that can run anything you want. A bit like he was educating us that embedded devices do have CPUs that can run actual software. As if they wouldn’t have a main branch and a main development selecting one of these particular toolkits…
Many moon laps later, I discussed Openmoko with a friend over a few stouts at Snaxx 18, and he explained how he’d got one of the dev boards a long time ago and had kept up and tried a lot of versions of it and that it basically never worked to even make simple phone calls. He gave me the impression that perhaps the project wasn’t really that well run if it after this long still don’t have even the most basic functionality present and running stable.
Therefor I was happy to listen to TWIT 143 about the Dash Express and them telling me about it being based on the Openmoko platform. It felt like solid proof they are moving in the right direction then, so at least parts of the project must be functioning!
Then, to round it up it was with a big grin I read about the recent news that they are abandoning GTK and are now going to use E17 and Qt instead. Not a trace of any “this is like a small computer it can run anything” talk now (although I do understand that the statement was just something from this person and not any public endorsement from the project or so). This very same Ars Technica article says the first Openmoko based phone called Freerunner is going into “mass production stage next month” (that would be June 2008).
Personally, I can still see how making Rockbox run as an application on an Openmoko device would be a very cool thing.
As one of the last living dinosaurs on the planet still using text-based email clients, I realized that pine has been replaced by alpine and I upgraded to that. When doing some reading up on the subject, I noticed that there’s another old grumpy guy still using this client. I’m not sure exactly what that says…
Anyway, the upside of this switch is that this client is now distributed under a proper open source license (Apache license 2.0), as that’s what I’ve been getting in my face from mutt users for years when I’ve explained what I use! (I mean the complaint that pine wasn’t proper open source)