|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This view of the diary is limited to these topics: technology. There may be lack of continuity in the text, and some days may be completely missing. In case of doubt, please enable the complete display.
| Thursday, 1 November 2012 | Dereel | Images for 1 November 2012 |
| Top of page | ||
| next day | ||
| last day |
|
More DxO pain
|
Topic: photography, technology | Link here |
My support issues with DxO Optics “Pro” are getting no better. The one problem that remains is the silly duplicate, incorrectly sorted display of images in the “Process” tab. I've asked four times for this to be addressed, without success, and now I just get the message “This ticket is closed”. Hopefully this is just the individual support person and not the company. Put in another ticket, in German in the hope that somebody else will get it. We'll see.
| Friday, 2 November 2012 | Dereel | Images for 2 November 2012 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
DxO problem: worked around
|
Topic: photography, technology | Link here |
A message from another DxO support person today, an English reply (judging by the name Olivier presumably from a Frenchman) to my German problem report stating once again that my Microsoft “Windows” XP system with 3 GB of memory was too wimpy to run DxO Optics “Pro”, independent of the processor. Never mind that the specifications say a minimum of 2 GB, nor that at the time the problem occurred the system had 2 GB of memory free, nor that the problem also occurs with the 64 bit version of “Windows” 8.
In addition, despite many requests for trace output, he couldn't find it. Never mind that this was in relation to the SMB issues: it was in an earlier bug report that had been closed as “solved”.
All in all, I didn't get the warm fuzzy feeling that people were taking the issues seriously. Still, he wanted a trace, so I gave him a trace. In the process, also put the images—all 2.5 GB of them—on a local NTFS file system so that the SMB issues wouldn't muddy the waters. Sent the whole thing off again. I wonder what I'll hear next.
While playing around later, discovered the solution not to this problem, but to the one I wanted solved. In ticket 3490, I asked and heard:
But that's wrong! It is possible to suppress it, both in release 7 and release 8. The real problem is that preferences are strewn around the program: there's a “Edit → Preferences” menu, a “Palettes” menu in the “Customize” tab, and today I discovered various icons for selection of which images to display, looking like an electronic circuit diagram antenna symbol, which they call “Filter”:
|
|
||||||||
This example shows that I have suppressed the display of all images except the one being processed and any in error; I could suppress them too, but currently I'm playing with it.
That's all I wanted. The bug is still there, but I don't have to see it, so I'm happy with the result, if not with DxO support. If the preferences were all kept in one place, this issue would probably never have arisen. As it is, not even the support people knew the answer.
| Saturday, 3 November 2012 | Dereel | Images for 3 November 2012 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
DxO bug: “solved”
|
Topic: photography, technology, opinion | Link here |
Mail from a Pascal at DxO support today. One sentence: “Die Lösung sehe sie hier” (“you see the solution here”). Further investigation shows that there was a video clip attached, showing how to set the sort order in the image browser.
What's wrong with this picture? It's strangely out of focus, for one thing. But more to the point:
It doesn't explain why it should be a solution. I think this may be my fault: DxO seems not to handle German support well. Both the people who responded have typical French names, and this might be an attempt to answer the question without writing more than absolutely essential in German.
It refers to the image browser, not the “process” tab. There's no corresponding icon in the “process” tab, and the settings in the image browser don't have any effect on the “process” tab. Language difficulties or not, they could have checked this.
The nature of the incorrect sorting is unrelated to any of the possible sort orders they offer (by name, size, “extension” and so on).
Surely commercial software support can't all be this bad? Under the circumstances, though, it's clear why so many bugs remain: “support” filters them all out before software development can hear of them. It's a good thing that I can get rid of the display (which, sadly, needs to be reset every time I start the program).
|
Photo processing speed
|
Topic: photography, technology | Link here |
House photo day today. Together with the photos from the open gardens, a total of 168 photos to process. It was also the first day I've done any serious processing with DxO Optics “Pro” version 8, and some of the settings are different from version 7. Processed about 50 of the photos before it occurred to me that the settings I had weren't optimal, and I had to start again. And I'm back to 2 minutes per image processing time.
Or am I? Later in the first, abortive processing it seemed to get faster. So I kept track of the creation timestamps of the output files. Here's a partial list, from the beginning and the end:
At the beginning it took 3:14 to process two images; at the end it took 1:27, hardly more than half the time. Why? If I could get any sense out of DxO support, they might tell me why, but as it is, I'll just have to continue guessing.
|
More network issues
|
Topic: technology, opinion | Link here |
For a change, I didn't have a network connectivity dropout today, though it was hard to tell: in mid-afternoon connectivity dropped to a minimum, with ping times as high as 20 seconds. Looking at my logs, I found:
That's an interesting cell ID. All the ones I've sen so far are 8 digits, but this was only 3. Further investigation showed that it was a GPRS cell. No wonder things were slow! Stopping and restarting the ppp process didn't help, but removing and replacing the (USB) modem did. In the process went through a surprising number of cells:
Roll on theradiation tower!
|
Radiation tower: when?
|
Topic: general, technology, opinion | Link here |
As a result, did a bit of investigation about the state of Wendy's appeal to VCAT. Not good: according to this discussion the date for the hearing has still not been set, after over 6 months. It should have been heard (and dismissed) by now. And there are suggestions that NBN may then postpone the erection until 2015! Under those circumstances, I wonder if we shouldn't be looking to build somewhere else.
| Monday, 5 November 2012 | Dereel → Geelong → Dereel | Images for 5 November 2012 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
Mixing photos
|
Topic: photography, technology | Link here |
Yvonne showed me a funny photo yesterday, a statue with holes in it—clearly a montage of two photos. It was on “here today, gone tomorrow” Facebook, so I can't find it any more. “I can do that too”, I said, thinking of Hugin, so I set to to take some experimental photos.
The first one didn't work at all well: the control points were all detected correctly, but the resultant image looked nothing like what I expected. At a guess took another series with a second image to the right:
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
In principle I only need the first two, but when I try to stitch them, I find (in the fast Panorama preview) the same problem I had yesterday:
|
|
||||||||
This is a small part of the preview, up near the top of the window. There's much more below, and the exposure is all over the place. What went wrong there? My guess was that it's related to only having a single view. That's why I took a new sequence including the third image. I couldn't just add it: the alignment failed after first deleting its log file. Starting again with all three images worked:
|
|
||||||||
Once I had done that, I could exclude the additional image from the photo and start a bit of cutting out bits and pieces with the help of the Fast Panorama preview:
|
|
||||||||
But the resultant image looked completely different:
|
|||||||||||||||||||||||
OK, RTFM time. The masks aren't completely binding, as the tutorial explains: the blender still has a choice of where to get the parts of the image from. OK, how about an include mask? Yes, that works. The specified parts of the image are included. So is the rest: it looks identical to the first component image.
As I understand it, what I need is an include mask on what I want to include and a corresponding exclude mask on all the other images. I've tried doing that manually, but it's painful. There's also the possibility of saving a mask and loading it on another image, then changing the type of mask. That works, but the mask coordinate relate to the individual source image, not the final result, so they don't necessarily land in the same place in the final image. Maybe there's a solution to that (SMOP?), but I don't see it.
| Wednesday, 7 November 2012 | Dereel | Images for 7 November 2012 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
Completing the ls work
|
Topic: technology, opinion | Link here |
I've made a number of modifications to ls over the years: the -X option to display file names in hex, the -y option and also the LS_SAMESORT environment variable to work around the mandated breakage in the standards. Most recently I've added the -, option to break large file sizes with commas (or whatever your locale provides). But I still haven't committed any of them. I described the issues a while back, but it's been nearly a month since then.
So finally I prepared the commit. First thing is clear: I have waited far too long. It's been nearly 4 years since I did the LS_SAMESORT stuff, and of course the sources have changed since then. Just untangling what I did and what others did took a considerable amount of time, several hours. I was finally ready to commit, but I think it makes sense to commit in the mornings to that if anything goes wrong, you can fix it easily. So, once again, mañana.
| Thursday, 8 November 2012 | Dereel | Images for 8 November 2012 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
Finally: the commits
|
Topic: technology | Link here |
Finally I've got round to committing all the patches I have been collecting, and while I was at it also addressed the checklist I made last month. Some of it, anyway. I'm still thinking about the rest, and since the recent change of compiler from gcc to clang, I'm not going to bother about fixing gcc. But clang has the same problem, not to mention the problem of overly verbose and gaudy error messages:
I think that's one for somebody else.
| Friday, 9 November 2012 | Dereel | Images for 9 November 2012 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
Unexpected issues with clang
|
Topic: technology, opinion | Link here |
The FreeBSD project is in the process of changing the C and C++ compiler from gcc to clang, mainly, I think, because of license issues. The transition is going relatively smoothly, and one day I might even get used to the horrible gaudy error messages. And maybe they'll get the compiler to run in less than 2 GB of memory.
But today came a message on the FreeBSD-current mailing list: calendar(1) has “stopped working”. The last serious work on that was done by Chris Yeardley, coincidentally committed a year ago today. So I took a look:
That wasn't in colour, but it clearly comes from clang. Why? From the man page:
The “calendar” file is preprocessed by cpp(1), allowing the inclusion of shared files such as lists of company holidays or meetings. If the shared file is not referenced by a full pathname, cpp(1) searches in the current (or home) directory first, and then in the directory /usr/share/calendar.a Empty lines and lines protected by the C commenting syntax (/* ... */) are ignored.
And looking at the code, it's clear that it was relying on having gcc:
So took a look at how to tell clang to process in “traditional” style, seriously hampered by lack of documentation. Yes, there's a cpp(1) man page, but it's a link to clang(1), and it doesn't document the valid standards beyond this cryptic statement:
So more head-scratching.
|
More source tweaks
|
Topic: technology | Link here |
Yesterday's FreeBSD commits didn't go unchallenged. Somehow my Emacs configuration has reverted to using spaces instead of tabs for indentation, and that's in violation of style(9). So another couple of cosmetic changes.
| Saturday, 10 November 2012 | Dereel | Images for 10 November 2012 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
Pointy hat for grog
|
Topic: technology | Link here |
Into the office this morning: I was less than thorough on my last commit to ls, and Peter Wemm had cleaned up the mess. I had replaced space sequences with corresponding tabs everywhere. That's desired in indentation, largely irrelevant in comments, but it makes a real mess of format strings, and ls -l no longer lined up. Another pointy hat for my collection.
|
Radiation tower affects property values
|
Topic: general, opinion, technology | Link here |
One of the objections raised to the radiation tower in Bannockburn on 13 March 2012 was that the presence of the tower would greatly devalue the property. Elaine J. Stroud-Kaminski of 2895 Colac-Ballarat Road, Dereel, on the corner of Swamp Road, claimed the presence would greatly devalue the property, by between $60,000 to $100,000. That's clearly nonsense, since the online property valuations suggest that the property is only worth about $150,000, but possibly she believes it, since the house is now up for sale.
The truth, of course, looks very different. Got a call today from a bloke who didn't give his name, but who was thinking of moving to Dereel and wanted to know what the current state of play was. When I told him that it could be years, he thanked me and suggested that he'd probably look elsewhere. Another victim of Wendy's objection. It would have been funny if he had been thinking of buying the Kaminski's house.
| Sunday, 11 November 2012 | Dereel | Images for 11 November 2012 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
DxO problem report: success!
|
Topic: photography, technology, opinion | Link here |
It's been well over two months since I reported a problem to DxO: the “Process” tab of DxO Optics “Pro” now displays all images, taking a long time to do so, and they're out of order. After three attempts to get the support person to read the problem report, I got the—incorrect—information that there was no way to suppress the display. When I asked him yet again to address the issue of the incorrect sort order, he closed the ticket without any further answer.
So I entered another ticket, this time in German to get a different support person, and got an inappropriate answer. Asked again, and finally I got a suitable answer:
Das "Problem" ist bekannt und wird zukünftig gelöst. Wir können leider noch nicht sagen wann
The “problem” is known and will be solved in the future. Unfortunately we can't yet say when that will be.
Still, they've finally understood. Given the time it has taken me to get them to look at it, I hope “is known” means “is now known”.
Am I being unfair to DxO? Hard to say. I suspect that the support people are mainly there to help people who are having difficulty with the product, not for handling bug reports. But there should be some way of reporting bugs that doesn't take 2 months, 3 support people and 6 attempts.
| Monday, 12 November 2012 | Dereel | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
Researching Dr. Livingstone
|
Topic: history, technology, opinion | Link here |
A couple of days ago my daily cron job sent me a calendar entry that looked wrong:
“Livingston”? That should be “Livingstone”—shouldn't it? Checked in the source of all knowledge and confirmed it. But also that the date was 27 October 1871. OK, we can fix that, so I did, and committed it.
This morning I had not one but 5 messages awaiting me from Marc Balmer, who had successively discovered that the German Wikipedia had 28 October, and that the entries for Stanley in both languages had 10 November. Clearly something's wrong.
Spent a couple of hours messing around, finally finding an online copy of Stanley's book “How I found Livingstone”. That goes into lots of detail, and it's clear that the date is 10 November. But there's more! Wikipedia also claims:
This famous phrase may be a fabrication, as Stanley tore out of his diary the pages relating to the encounter.
So: the book I have is the book, not his diary. Where's his diary? It's available, but not for free online. But the State Library of Victoria has a copy, so I should take a look next time I'm in Melbourne.
Somehow hacking code is simpler.
|
Another X hang!
|
Topic: technology | Link here |
It's been well over a month since I installed the new nVidia driver for X and solved my X hang problems. I thought. Today it happened again, again under similar circumstances. The symptoms are not quite the same: It's slower now, and it's possible to move the mouse cursor a little from the edge of the monitor before it jumps back. But it's just as fatal.
In fact, it would seem it was more. My ΛΟC monitor came back in 1280×1024 resolution. Investigating the log files showed:
How could that happen? I don't know, and clearly it's unlikely to have anything to do with the crash. Presumably something in the monitor died since I last started X, which would have been a couple of weeks ago. Moving monitors around confirmed that yes, it's a monitor problem and yes, it's here to stay.
OK, I should be able to override the EDID information. That's the way we always did it, and I even had information in the X config file. But how do I get the driver to ignore the (non-existent!) EDID info? The manual tells me: there are a number of options. Put them in the config file and got:
All well and good, but it didn't pay any attention to my HorizSync and VertRefresh specifications either. This suggests that the options are worthless, since there's nothing at all to go on, and it came up in 640×480 mode. But there are other options too: the CustomEDID option allows you to specify a file with the EDID contents, and from this page I discovered that the nvidia-settings program can save the monitors EDID to a file, something I was looking for some weeks ago. Tried it on the other monitors, and it worked fine.
But how do I get the EDID for the ΛΟC monitor? That's the problem in the first place. But Google is your friend, and it came up with this page, which contained:
So: all I need to do is convert this into binary and store it in a file. How do you do that? A number of people on IRC discussed doing it with Perl, but I don't do Perl. Instead wrote a rather crappy C program which did the job, and had the results before they had finished their discussion—the wrong way round: I was using 64 bit quantities for convenience, and endianness comes into the equation. What's the function to turn things the right way round? I recalled htonl and friends, but that's only 32 bit. Nowadays there's a whole lot of new functions, but the man page only refers to byteorder(9), a kernel interface. But that's the one! The function I was looking for was htobe64. Why is this in section 9? It's not a kernel function. It should be in section 3. There is a byteorder(3), but it's just the old htonl and friends. Another thing to fix, I suppose, if I can stand the bikeshed.
So: finally I had my EDID, the right way round. Did it look good?
=== grog@eureka (/dev/pts/6) ~/EDID 6 -> hexdump -C LOS.bin
=== grog@eureka (/dev/pts/6) ~/EDID 7 -> hexdump -C BenQ-G2400W.bin
Look at that bottom line: the model is clearly visible in the BenQ EDID, but the corresponding field in the ΛΟC EDID proves to be the serial number. Is this a valid EDID? Where's the text AOC?
For the fun of it, tried it out, with this configuration entry in the Screen section:
It worked. And it knew the monitor name:
Where did it get that from? Investigation shows that there's a 3 character capital letter only manufacturer abbreviation hidden 5 bits per character somewhere in the binary. BenQ is too long, so it needs to be put in a different field.
So: a couple of hours work and I had it running. From now on I save the EDID of every monitor I use.
| Wednesday, 14 November 2012 | Dereel | Images for 14 November 2012 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
More panorama reprocessing
|
Topic: photography, technology, opinion | Link here |
Continued looking at my photos of 27 November 2011 today. It seems that it's not a good idea to use the old project files for images that have been reprocessed. Here again the comparison between the original, the reprocessed version using the old project files, and the reprocessed version starting from scratch:
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Interestingly, the stitching results were not overly good. The average and maximum error were 1.5 and 11.9 pixels first time round. After deleting all control points over 3 pixels in error, the alignment went down to 1.1 and 3.7 pixels—a little more than the 1.0 and 3.5 of yesterday's bad stitch. So these numbers should be treated with caution.
And it took all day again! Admittedly, that's probably the largest number of photos I have ever taken in one day, and maybe more photos than I ever took with my Pentax Z-1.
|
More USB pain
|
Topic: multimedia, technology, opinion | Link here |
Recently I've been having trouble with the wireless keyboard on teevee, my TV computer. For some reason it can no longer reliably communicate with the USB dongle. It's not the dongle, since the mouse has no difficulty. So yesterday I plugged in a cable USB keyboard.
And then today I could no longer use the remote control! I've been moaning about lirc for years, but lately it's been running well, and I've forgotten how to debug it. Finally found irw and tried it out. No reaction. Ran ktrace against lircd. No input. Took another look at the running lircd process:
That looked straightforward enough. What about the dmesg?
So the keyboard was the culprit! It had taken the device name for the remote control. When I connected it yesterday, the system was already running, so I got the devices the other way round:
That's not the fault of the keyboard, of course. We should have an additional form of device naming; something reflecting vendor and product would seem to make sense, something like /dev/usb/0fe9/9010/0 for the remote control.
But that wasn't the end of it. I dragged out the replacement keyboard that I had bought for exactly this eventuality some time ago and plugged it in. No batteries in it, of course, but that's not an issue. But what did I do with the battery cover? Couldn't find it, and ended up having to tape the batteries in.
And then I came back an hour later and found the keyboard merrily generating the sequence abcdefghijklmnopqrstuvwxyz\n over and over again. What's that? Some kind of test function? Maybe a skillful cat managed to jump on the correct sequence of keys. Removing and replacing the batteries helped.
Isn't having your own multimedia fun?
| Thursday, 15 November 2012 | Dereel | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
Making df legible
|
Topic: technology | Link here |
Surprisingly there was little feedback on my changes to ls, so today I continued with df, adding a -, option:
=== grog@eureka (/dev/pts/14) /src/FreeBSD/svn/head/bin/df 22 -> df /Photos/
=== grog@eureka (/dev/pts/14) /src/FreeBSD/svn/head/bin/df 23 -> df -, /Photos/
It's interesting to note that commas in sizes are standard in Microsoft's COMMAND.EXE.
Of course, there's no pleasing everybody. Callum Gibson wants 1000 byte blocks. That's what the BLOCKSIZE environment variable is for:
=== grog@eureka (/dev/pts/14) /src/FreeBSD/svn/head/bin/df 24 -> BLOCKSIZE=1000 df -, /Photos/
But it's wrong! The values are unchanged. That's due to the simplistic conversion function, which does integer division and discards the remainder. Fixing it isn't as simple as it should be, since the calculation suffers from potential overflows. Mañana.
| Friday, 16 November 2012 | Dereel | Images for 16 November 2012 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
More df work
|
Topic: technology | Link here |
As planned, more thinking about the changes in df today. The block size calculation was:
No description of the parameters, of course. num is the number of blocks (total, used, free) to be converted. fsbs proves to be the file system fragment size, for UFS at any rate (more specifically, statfs->f_bsize), in which the numbers are reported, and bs is the specified “block size” into which we want to convert it. That's straightforward: num * fsbs / bs. So why the messing around? The comments give the lie: avoid overflow. But why? intmax_t proves to be a 64 bit value, and that's big enough for all file systems—even, it seems, ZFS, which uses 128 bit quantities, but really only uses the lower 64 bits of them (which are, after all, 16 Exabytes). So for the time being at any rate 64 bit calculations are reasonable. But why did we end up with this situation in the first place? Looking back, it seems that this function was originally a macro and was introduced in 4.4BSD:
That's all ancient history, though I suppose it's worth it.
But there's another comparison in that calculation:
Why is it checking for a zero fragment size? And why is it not complaining if it finds one? I don't think it can happen, but just to be on the safe side, I've checked for it elsewhere, “fix” it, and print out a warning:
Also went through the man pages, which are also interesting. FreeBSD df has two options, -b and -P, which are not only identical but which don't do very much: they tell df to display the block counts in units of 512 bytes, which just happens to be the default size. About the only effect they have is to override BLOCKSIZE. So why two? Because -b is typical BSD, but POSIX.1 specifies -P, so we need it for compatibility.
| Sunday, 18 November 2012 | Dereel | Images for 18 November 2012 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
gdb: Your friend in need
|
Topic: technology | Link here |
Message in the mail today: I had managed to mess up my change to locale(1). It wasn't immediately obvious why, so I went through with gdb:
That first command was a breakpoint on main. It should have hit there before doing anything. What went wrong? Took a look at the entrance to main and found:
So I had asked for a breakpoint at main, and it placed it 17 bytes further on. Why?
Part of the answer lies in the function linkage. The first two instructions set up the environment so that the stack is pointing to main's stack. A breakpoint at the entry point (0x8048b30) would show the environment of the caller. So normally gdb sets a breakpoint after these instructions, in this case at 0x8048b33. I go into more detail about this in chapter 4 of my kernel debugging tutorial, page 17 and on, particularly page 20.
But why 17 bytes further on? About the only thing I can see there is that the breakpoint has been placed where it can't be executed, since the previous instruction jumps over it. Is this something to do with the change to clang? To be investigated.
| Monday, 19 November 2012 | Dereel | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
FreeBSD compromise fallout
|
Topic: technology | Link here |
A couple of months ago somebody gained access to a couple of machines in the FreeBSD cluster, apparently by stealing an ssh key. There's no evidence that he did any particular harm, but everybody's taking it very seriously.
In my case, I discovered I had private keys on two of the machines, like we all did in the Good Old Days. And it's quite possible they got stolen. So another round of generating new keys, the first in 10 years:
And in the process: which keys do you need? RSA1 is clearly obsolete. But DSA or RSA2? I decided on the later for no better reason than that ssh tries it first. And, of course, ran into problems replacing things, notably on the FreeBSD machines: only the admins can change the keys. So I'll have to wait until they do their thing.
On the positive side, it doesn't look as if anybody has used my private key to compromise other machines:
=== root@www (/dev/ttyp0) /var/log 5 -> bzcat auth.log*2 | grep publickey.*grog | sed 's:.*from :host :; s: port.*::' | sort -u | sh
All of those addresses are the various places I get put after a network disconnect, so things don't look too bad.
|
More gdb investigations
|
Topic: technology | Link here |
So why is gdb setting breakpoints in the wrong place? Why, is gdb setting breakpoints in the wrong place? Did some investigation which proved inconclusive. What I found was:
On FreeBSD-CURRENT on the i386 platform, it sets the breakpoint correctly—if I don't include debug symbols.
On FreeBSD-CURRENT on the i386 platform, it sets the breakpoint 17 bytes from the start if I include debug symbols.
On 9-STABLE amd64 it sets the breakpoint on the entry point. This means that the local variables aren't visible, because they haven't been created yet.
On 9-STABLE i386 without debugging symbols, it sets the breakpoint on the entry point. This means that the local variables aren't visible, because they haven't been created yet.
On 9-STABLE i386 with debugging symbols, it sets the breakpoint 6 bytes later:
But this isn't repeatable. When I came back again, I had the breakpoint on the entry point again.
So: there's clearly some influence here that I don't understand. More head-scratching.
|
Network access for the Friends
|
Topic: technology, opinion | Link here |
Last week I discovered that the Friends of the Ballarat Botanical Gardens are paying an arm and a leg for telephone and Internet access. They've somehow become lumbered with a telephone service with a whopping $44 per month rental—from Telstra, of course—and surprisingly high call costs. The result for last month, for very few calls, was a bill for nearly $60. And the Internet connection is just as bad: $40 for a line that, if I recall correctly, has a 512/128 kB speed and 3 GB cap.
Why am I so vague about speed and traffic? Looking at the ncable.net.au transact.com.au web
site, I can no longer find it. So how about looking at our usage page, something I haven't
done for a while? I had the address saved on a private page: https://accounts.ncable.net.au/index.php/. But now that redirects to https://portal.vic.transact.com.au/, and that times out. Called up technical
support, which for once answered very quickly, and spoke to somebody with a mumbled name,
who didn't disagree when I asked if her name was spelt “Ekta”. She couldn't give me the URL
of the new page, but led me through from the home page to http://transact.com.au/en-VIC/MyTransACT. And then she told me to click on
“Broadband account manager”:
|
|
||||||||
That pointed me to the same URL that had timed out on me. At least I knew why now, and I told her. But she wasn't listening: “Do you have another browser on your computer that you can try?”. I finally got her to connect me to Nick, her supervisor, whose name proved to be Mick. He confirmed that I can only access this information when I'm on one of TransACT's own net connections, and suggested that I go there. I suggested that I go to another ISP, but that didn't seem to worry him.
So went looking and found only two ISPs who seem trustworthy enough to change to: Internode and iiNet (“We're second best”). Internode's web site has gone downhill to the point that I was no longer able to decide what the prices were, so called them up. Yes, the Friends may be a non-profit organization, but they're still a business, because they have more than one computer. And for you, Sir, that'll be $60 for the Internet connection and $35 for the phone! Admittedly it's a lot faster than what we have now, but no cheaper.
iiNet was a different matter. I waited 20 minutes for sales to answer, and heard that we could pay $30 each for the phone and the Internet connection. The salesperson (Esney? Why do these people have such unusual names and mumble them?) told me that I could have opted for callback when the appropriate message came—but it hadn't. I was left with an impression of less than total competence.
So what do we do? I'd like to go to Internode, but that's just too expensive. And it seems that iiNet is the parent company of TransACT, which is a concern. Maybe this silly restriction on account access even comes from them. For the moment more investigation.
| Tuesday, 20 November 2012 | Dereel | Images for 20 November 2012 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
DxO: your fault after all!
|
Topic: photography, technology, opinion | Link here |
Over a week ago I finally got DxO support to understand a problem report I had sent in, to stop claiming that it was all my fault, and admit that they had a bug that would be fixed “sometime”. It was the culmination of over two months of banging my head against a brick wall, including resubmitting the ticket twice, and it felt so good when it stopped.
And then a couple of days ago I got a message asking if I was running DxO Optics “Pro” in a virtual machine. I was quite impressed that they had gone to the trouble to analyse the logs, which were months old. And of course, when I said “yes”, I got the stereotyped reply (translated from German):
Then we have found the reason for the problem. If you run DxO Optics Pro in a proper machine you won't have such problems.
Why, why, why do they say such things? Are they just trying to annoy me? They don't say which problem they're talking about, but there were three components:
Images in the process tab are sorted incorrectly. They've admitted this is a bug.
Can't suppress the display of images in the process tab. I had an answer to that: “No, you can't”. But it was wrong, and I've found out how to do it, so this problem has been solved too.
Settings don't get saved on exit. This problem has been fixed in a later version, presumably while “support” was trying to blame it on me.
So which problem won't I have? It would be nice to say “then support won't be able to blame things on me”, but that's underestimating their ingenuity. After all, they have already blamed things on my real physical machine that meets their requirements.
Why do they do this? It's detrimental both for their product and their reputation.
| Wednesday, 21 November 2012 | Dereel | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
Gizmodo spam?
|
Topic: technology, opinion | Link here |
Strange message in the mail this morning:
Clearly malicious spam. But the interesting part is the email address, gizmodo@lemis.com. It's genuine (or it was at the time, anyway). But I only ever used it for one purpose, to sign up with Gizmodo. So how did the sender get it? I'm continually receiving spam that suggests that well-known sites are involved, such as the continual barrage of “recommendations” from LinkedIn. Wouldn't it be nice if their abuse people would respond? As it is, goodbye Gizmodo.
| Thursday, 22 November 2012 | Dereel | Images for 22 November 2012 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
dirname: not found
|
Topic: technology, opinion | Link here |
Mail from David Noel today, referring to a problem I had 1½ years ago:
He asked how I solved it. I have no idea. I suspected it might be something to do with environment variables, but despite the verbosity of this diary, I managed to leave out the important part. The best I can find is that newvers.sh shouldn't be run at this point, which suggests some discrepancy in timestamps.
| Friday, 23 November 2012 | Dereel | Images for 23 November 2012 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
Computer education for the next generation
|
Topic: technology, opinion | Link here |
Next year Jashank Jeremy will finish school with the the Higher School Certificate or HSC. Today he complained about the quality of his textbooks, unfairly, I thought:
“Today most mobile phones include digital cameras, internet connectivity using both local 802.11 access points and 3G networks, Bluetooth and also GPS receivers. All these connectivity and other hardware features have resulted in an ever increasing number of innovative Apps coming onto the market.”
As he said, “It's so badly structured, the grammar and spelling is typically terrible, all sorts of things are mentioned and never explained...”. OK, you can't see all that from a random quote; I was rather pleased that they used the term 802.11 and not silly buzzwords like WiFi. But it seems that there's worse. The book is “Software Design and Development - The HSC Course” published by the Parramatta Education Centre, and they have sample Chapters online. The content is horrifying! Leaving aside the poor choice of programming languages for the examples (“Visual Basic” and Pascal), much of the content is very misleading or just plain incorrect. I can't cut and paste, but here a couple of examples from chapter 5, “Implementation of software solutions”:
(Page 251) The CPU needs to communicate with outside devices. Communication is accomplished via interrupts. Essentially, an interrupt is a communication channel in and out of the CPU.
The example shows 8086 assembly code using PC BIOS interrupts. It doesn't mention the BIOS in this connection, only later on:
(Page 264) The BIOS provides the interface between the interface between the operating system and the hardware. BIOS settings are stored in CMOS (Complementary Metal Oxide Semiconductor. CMOS is a type of RAM that requires very little power to retain its contents.
And that's all that it says about the BIOS. So an attentive student who relies on this text will believe that an interrupt is part of the processor, and that it somehow performs I/O. By comparison other details (noted by Andy Farkas) are just amusing:
(P 252) The 8086 assembler instruction adc ax,2dh adds the value 2dh to the value contained in the accumulator. The carry flag, cf, is set if the result of the addition overflows the word size of the processor. The hexadecimal machine language equivalent is 15 2D. In binary, this statement becomes 00010101 00101110.
That's not completely correct: adc ax,2dh adds 0x2d and the carry flag to ax. And I wonder how many people really check the correctness of the binary representation.
Apart from that, there are so many assumptions:
.. if an array called ThisArray is declared with a subscript range of 0 to 10, an attempt to assign a value to ThisArray(11) will cause a runtime error.
Wouldn't that be nice? If it's a constant subscript, it could be caught by the compiler, but it's quite possible for this to happen and not be detected at all.
There are dozens of other errors in the book. How can they get away with it? Don't they have technical reviews? And this is what our next generation learn. The publishers should be ashamed of themselves.
| Wednesday, 28 November 2012 | Dereel | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
eBooks: The pain
|
Topic: technology, opinion | Link here |
I've had to deal with eBooks before, and I wasn't very impressed. At the time the issues were more with the device than the medium. But now that Apple has started bringing out high-resolution displays, I don't suppose it'll be long before eBook readers do the same, and that would fix one of my biggest gripes.
Today, however, I got an eBook from the State Library of Victoria. How do I display it? The library gave me three possibilities: view online for 10 minutes, extend for one day (without saying whether this extension would cost anything), or download the eBook and view offline for a week.
So I tried the first possibility. That worked fine, but of course I had to hurry. And after a while it just hung. The information panel on the left told me that I had used all of the 40 pages I was allowed to download, and didn't give me the option to extend. So I tried the “download”, which requires Adobe Digital Editions, presumably to restrict access to 7 days. And that, of course, is only available for Microsoft and Apple. Tried it on my Microsoft “Windows” 8 preview, but it wanted me to authenticate, something that SLV didn't prepare me fora. Tried it without authentication and got unintelligible error message which suggested that the authentication failed, possibly because I can't set the date on this thing.
Round about here I gave up. I had got the information I wanted, and in the process of trying discovered that there was nothing to stop me re-accessing the book for another 10 minutes or 40 pages or whatever the real criterion is. But why do people do this? These silly restrictions make eBooks so much pain that I can't be bothered. If I borrow a book from a lending library, I can use it with less pain for up to 4 weeks, and renew if I want. The time restriction is simply because it's a shared resource, which you can't say about an eBook. And when I hear that companies like Amazon have the capability of revoking access to anything stored on a Kindle, I wonder why people buy them at all.
| Friday, 30 November 2012 | Dereel | Images for 30 November 2012 |
| Top of page | ||
| previous day |
|
Captchamania
|
Topic: technology, opinion | Link here |
I hate Captchas! And they seem to be getting more and more prevalent. A couple of days ago I received a mail message from somebody@inbox.com and replied from an address different from the one he sent the message to. Bang! A reply with subject “My spam filter requires verification of your email address”. Not a problem; I suppose it really does help reduce spam. Follow the link, enter the details—and fill out a particularly emetic Captcha! No, I won't do it. Let him do it if he wants mail from me.
Then today I had the problem again. Yvonne is attending a training session in Rokeby with Robyn Hood next week. And the address was given as “Mayflower Ridge, Rokeby”—just what you need for a GPS navigator or Google Maps. So I went looking, and found the correct address (193 Old Telegraph Road). But that was on an online registration form—with Captcha!
|
|
||||||||
That would be enough to stop me from registering. It's high time that somebody writes a firefox plugin to fill them in for you.
| Top of page | Previous month | Greg's home page | Today's diary entry | Next month | Greg's photos | Copyright information |