Older blog entries for cdfrey (starting at number 79)

IPv6 and Mozilla

    I did find a solution to the slow DNS lookups in Mozilla, mentioned in my previous rant. Thanks to tw001_tw who posted about it.

    Under about:config, set network.dns.disableIPv6 to true.

Syndicated 2010-09-15 09:28:40 from Chris Frey's Blog - Entries tagged advogato

Rant: Why, Oh Why, Linux??

    This post might be more suitable for the Linux Hater's blog, but I don't have access to that one. This one will have to do.

    I've been experimenting with Debian Squeeze on an older T40 Thinkpad, and I've been noticing some disturbing trends. Trends that I probably haven't noticed since I haven't had hardware that new, and have been fairly happy using xterms and make on Debian Lenny.

    I'm noticing a divergence between the command line and the GUI... a divergence that is horrifying. I installed the base system, got WiFi going using /etc/network/interfaces, and was happy. Then I installed the GUI, and my carefully configured network stopped working. The GUI had its own way to configure things. Yes, the GUI worked, if it was allowed to operate by itself, but that's not the point. Why have two? Why break one to make the other work? I still don't know where the GUI stores its network settings. They sure don't show up in the /etc config files.

    Divergence #2: DNS works snappy from the command line, but somehow Firefox labours to find Google, or Slashdot, even though it was just there a few minutes ago. Really? This is 2010. I poke around the network with tcpdump to see what on God's green earth Firefox is doing. And it's looking up DNS entries for a tab I'm not even on.

    Look, I know IPv6 is the next big thing, but don't turn it on unless it has zero impact on what people need right now. Let me easily choose which network has priority. And give me one place to set it. Not two. Not five. One.

    So I say goodbye to Firefox and load Mozilla.. the ancient browser... it's worked for me in the past. Maybe it will be too old to fail. I load my home page, and watch the network with tcpdump. I see it going through the page, looking up DNS for all the links. Great, I think, at least it will be cached for me. I click on some links. A little better at first, but soon goes downhill. Still more forgetful than an Alzheimer's patient.

    Why is it so hard to get networking working in 2010? My friend went through this with Ubuntu back in 2007, and it didn't work right. At least now it sort of hobbles along, but back then, NetworkManager only managed to dig itself a grave.

    Enough about networks: my laptop is fairly old, and the battery is getting flakey. This is to be expected, I don't mind, the battery is still useful for an hour or two, and I'm happy. So I load up Gnome and work away on the battery. The icon shows me the battery discharge progress. Then it gets to the point where the battery is low. It pops up a gigantic black notification message, over top of other windows, telling me this. Fine. Thanks, I guess. Go away now. Then it gets critically low, and shows me another one. Ok ok, I get it, calm down. Then it alternates back and forth between low and critical. I even saw two notification messages on the screen at once... hiding other windows that I needed! And there is no way to turn these off! Unbelievable. Do I have to hack the code to get rid of these monstrosities? Why not just warn me once and let me deal with the consequences? Why pester me and assume I have no brain? I know the battery is low. I know that means I have 30 minutes of power left. Stop telling me what I already know!

    Does every poor end user need to download some Gnome C code, and hack around in the code to figure out how to tune the system? I've already had to do it once to figure out how to disable automatic Suspend mode, when the GUI helpfully left that option off the menu. Now again for notifications? Good grief on a stick!

    Poor Linux. Everybody running around the system, coding their own little kingdoms in their own little sandboxes, and the distros are including it as if it was something stable for end users. The kernel guys do one thing, the udev guys do another, the hotplugging notification guys do something else, the GUI guys do yet more (in multiple different ways, of course), and the user tries to push a rope uphill, suffering with a very busy but confused system crippled by lack of configuration options in the menus.

    Dear programmers: the first setting you should code in your next fancy new feature is how to turn the bloody thing off.

Syndicated 2010-09-14 08:50:13 from Chris Frey's Blog - Entries tagged advogato

Video: Intro to Git

    I gave my Introduction to Git talk again at the local Drupal User's Group.

    Andrew Berry filmed the talk, and we recorded the laptop screen for the slides and command line activity. He put it all together in a video which you can download at archive.org.

    The lights were off so people could see the screen, so you won't see much of me, but the slides are there.

    If you want to grab the updated slides and scripts for yourself, you can download them via git with the following command:

	git clone http://foursquare.net/intro_to/.git

Thanks to Khalid Baheyeldin, Andrew Berry, and Bob Jonkman for their help and equipment, and thanks to the Drupal group for their welcome.

Syndicated 2010-07-21 21:25:58 from Chris Frey's Blog - Entries tagged advogato

KWLUG: Introduction to Git

    I presented my Introduction to Git talk at KWLUG tonight. I was pleased to hear that folks found it enlightening.

    You can grab my OpenOffice slides, as well as the demo scripts I used during the presentation, by using git:

	git clone http://foursquare.net/intro_to/.git

If you missed tonight's talk, I'm also booked to give it at the next Drupal User Group meeting on Thursday, July 15, 2010, at 7pm. You can find more details here. That meeting is at 58 Queen St. in Kitchener (across the street from the old KWLUG meeting place).

Special thanks to Paul Nijjar for providing the laptop tonight and the setup.

Syndicated 2010-07-05 22:39:10 from Chris Frey's Blog - Entries tagged advogato

Programmer Ethics

    apenwarr,

    That is a pretty comprehensive list. I'm probably in the same camp as you claim to be, having broken every one.

    The rules are pretty strong as well. I'm still mulling them over in my mind, but there is one that sticks out as unwise, or poorly written. It is #3, which says: "I will not write a program that fails to do tomorrow what it was able to do yesterday."

    Taken purely literally, this prevents all change, all experimentation, all feature-level refactoring. I'm sure this is not what the rule was intended to say. I'm assuming it is more of an encouragement for better testing, so that a bugfix in one area doesn't break a feature in another.

    Even taking this rule as a Testing Rule, I think it overreaches. There are steps that programmers can take to prevent regressions, but to assume that it is possible, or even common, to prevent them all is wishful thinking.

    I think a better rule would be something like: "I will not refuse or hinder the fixing of a bug that I have caused."

Syndicated 2010-05-23 18:27:14 from Chris Frey's Blog - Entries tagged advogato

Bike Safety

    It's almost that time of year again, when people get out on their bikes and enjoy the fresh air blowing in their faces, and the benefits of exercise.

    Instead of merely slapping on a helmet and thinking you're bulletproof, though, take a look at this excellent site on bike safety: How To Not Get Hit By Cars.

    Whether you wear a helmet or not, the primary goal for safety should be to avoid an accident in the first place. And this site explains the dangers logically and clearly.

    I remember being very impressed by the site the first time I found it a few years ago. It changed the way I ride on the streets. I hope it will help improve your safety as well.

Syndicated 2010-05-11 18:50:21 from Chris Frey's Blog - Entries tagged advogato

Time Conversion: timegm()

    redi, thanks for the pointer to timegm(). Both GNU and BSD, you say? Nice. I did not know that function existed.

    It would still be nice if timegm() was in a library of its own instead of libc. But that's probably asking too much.

    Good to know. Thanks!

Syndicated 2010-05-05 13:39:29 from Chris Frey's Blog - Entries tagged advogato

Time Conversion: ISO timestamps, mktime(), and UTC

    In the C library, there is a very handy function called mktime() which takes a struct tm pointer, pointing to time data in the local timezone, and converts it to a unix time_t.

    There is also a very handy set of functions that goes in the other direction. The function gmtime() takes a time_t and converts it to a struct tm in the UTC timezone. And localtime() does the reverse of mktime(), converting a time_t to a struct tm in the local timezone.

    The one function missing is the reverse of gmtime().

    One way to do it, via standard library function calls, is to adjust the TZ environment variable to "UTC" and then call mktime(), which will then use it as the current timezone. But that gets messy. Not only do you have to save the old TZ setting to restore it afterward, if your program uses threads, messing about with the global TZ variable is hardly safe.

    Another way to do it is to use gmtime() as a reference point, and loop while adjusting the original struct tm until mktime() + gmtime() gives you the result you started with. This is brute force and inelegant, but it manages to do the job without fiddling with the global environment.

    When parsing ISO timestamp strings, this problem is hit pretty quick. An ISO timestamp can contain a time in either the local timezone or UTC, depending on the trailing 'Z' flag. In my research, it does not appear that more specific timezones can be specified in the timestamp format, so at least we only have two states to worry about.

    After much searching, I've ended up with something that I find suitable enough to release. I tackled this problem back in 2007 for the OpenSync project (you can see similar code in the opensync_time.c file), but looking back on it now, the code is not clean enough for me to reuse very easily. And even though there's a vtime2unix converter function, it leaves the burden of timezones to the user.

    I took a look at Boost's date_time library as well, and while huge and comprehensive, and though it breaks the problem of time, dates, and durations into nice manageable chunks, it seemed to reverse the status of the C library: it made UTC conversions easy, and local timezone conversions hard. And it reads timezone information out of CSV files... I don't want to have to maintain my own timezone database when the OS does it for me.

    So, if I don't want to write my own conversion routines, and if I don't want to maintain my own timezone database, I'm stuck with the C library method, and the first two solutions. Might as well make it easy to use.

    The source files for TzWrapper contain the following utilities:

    • iso_to_tm() - simple ISO timestamp converter
    • utc_mktime() - the brute force UTC to time_t converter
    • TzWrapper - C++ wrapper class for setting and restoring TZ

    Using TzWrapper, it's now possible to do things like:

	struct tm pacific_tm = { ... };
	time_t t = TzWrapper("Canada/Pacific").mktime(&pacific_tm);
	cout 

If you have any further tips to make this code better, or pointers to better libraries that make this code obsolete, please let me know!

Syndicated 2010-05-01 22:37:19 from Chris Frey's Blog - Entries tagged advogato

Predictions Beyond 2012?

	for those people who may not be aware: 2012 is the time which
	all the prophecies in all the religions point as being a "key
	pivotal moment" in human spiritual development. there are _no_
	predictions beyond that point, because the decision of where we
	go, and what we do next, is to be made *globally*, as an entire
	planet and a species.

With respect, I believe you may have overlooked at least one religion. :-)

There is no starting date that I am aware of in the book of Revelations. But there is a time period predicted, commonly thought to be 7 years, in which things happen that have not happened yet. So even if those 7 years started right now, the predictions would take us beyond 2012.

If so, then how can your claim be true for "all the religions"?

Syndicated 2010-04-24 02:29:46 from Chris Frey's Blog - Entries tagged advogato

Blog now syndicated

My main blog has, for many years, been right here on Advogato. But due to its focus on free software, I always hesitated writing about topics that strayed too far afield.

I've now moved my main blog to http://foursquare.net/cdfrey/blog/, and syndicated all entries with the "advogato" tag to show up here.

I plan to check the recentlog regularly, so feel free to reply to my blog posts on advogato as usual.

Enjoy.

Syndicated 2010-03-13 22:13:29 from Chris Frey's Blog - Entries tagged advogato

70 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!