The content of this blog is my personal opinion only. Although I am an employee - currently of MIPS Technologies, in the past of other companies such as Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Thursday, October 08, 2015

OSX HFS+ case insensitive by default - a security bug waiting to happen

I was having problems installing cpanm modules on my MacBook.

Turns out I have had a script ~/bin/CC in my path since circa 1980. cc plus some pleasant defaults. It has worked from UNIX v6 through v7, Eunice, BSD 4.1, 4.2, 4.3, SVr4, Xenix, Gould UTX, Linux, cygwin... and it failed for the first time on MacOS, infinite recursion. 

I wondered if HFS+'s case insensitivity could be exploited for a security hole. Googling reveals that the problem has already been encountered article.gmane.org/gmane.linux.kernel/1853266itworld.com/article/2868393/… January 2015 Although fixed in Git, this is an exploit waiting to happen, for Mac users who have ever installed software from some other UNIX-like case-sensitive system. For that matter, it is probably a potential security hole for code ported from case sensitive iOS to Mac OS X.

Tuesday, September 29, 2015

Merging in bzr: The git approach vs the bzr approach

Nice comparison of the git vs bzr meeging approaches.  

Git: "The changes appear to emerge fully-formed with no evidence of the process which created them."

Bzr: "the project's revision history will show the actual process the developer went through to create the branch."


Since some [D]CVSes support both styles - heck, even git and mercurial support both styles, and I think even bzr does - it may be more accurate to call it "clean history" versus "actual history" approaches.

The availability of a "rebase" tool is the main thing that enables the "clean history" approach.

Myself, I am unambiguously an "actual history" advocate.  "Those who cannot remember the past are condemned to repeat it".

But I can understand why so many Linux developers want a clean history.

Myself, I want both: the actual history, and possibly a clean history that is what you see by default, when the actual history is pretty messy.  (And believe me, I have seen the actual history get very messy.)

E.g. if you haven't rebased a task branch before merging, I want to see it in the style that the page depicts as bzr-style.  But I suppose that it is okay to "fold" it into the trunk, if there has ben no trunk activity in the meantime.   And if every checkin on the task branch is release-worthy.   But if there are any checkins on the task-brach that were half-assed, that you might not want to bisect to, then no, I don't want it folded in.

But if you have rebased a task branch, because the trunk has been modified since the task branch was originally forked, and have tested all of the intermediate points on the rebase, then I want to see BOTH in the actual history.

I want to see the original, pre-rebase, task branch.   Where the work was actually done.

But I am okay on seeing the rebased task branch, and even having it folded into the trunk,

I am okay on only presenting ONLY the rebased task branch and/or folded into the trunk, by default, HIDING the original pre-rebased task branch.  But this is by default only.  I would want to have some sort of indication that says "there's more history here".


Because I don't believe that you can completely test correctness.

Because experience shows that there is always a chance that the rebased task branch, folded into the trunk, will have a bug. A bug that occurred in the rebased task branch, but not in the original pre-rebased task branch. Essentially a bug caused by interference between whatever happened on the trunk and whatever happened on the task branch.

Even if your full test suite has been run on all of the pre- and post- rebase checkins.   Because sometimes the test suite doesn't test for everything.

Sure, oftentimes it will not matter - you bisect on the rebased and folded task checkins, and find what the bug is.   But sometimes  it is good to understand why the bug occurred, not just what it is.

Rebasing, and other history rewriting mechanisms, have two functions IMHO:

1) cleaning up the history

2) as debugging tools

E.g. if you have a task branch, which has passed te test suite at all checkins, and a trunk which has similarly passed the test suite, and you merge - and there is a failure.  But then obviously the failure is due to an interaction.

Creating a rebased clone of the task branch is then a debugging tool - you can see which of the task branch checks, which all passed tests pre-rebasing, causes tests to fail post-rebasing.

This is a damned useful thing to do even if the rebased task branch is not checked in / pushed to some more public repo - even if all you do is a branch merge.

E.g. sometimes I use a rebase just for debugging, and then through out the rebased branch.

What I do object to, however, is rebasing and NOT testing all of the intermediate checkins.

Merging in bzr: The git approach vs the bzr approach: "often"

'via Blog this'

Monday, September 21, 2015

Twitter's Tips for Making Software Engineers More Efficient - IEEE Spectrum

Amen!!!!!!!!  (sez me, who has been dealing with FrameMaker and Parallels crashing many times a day.)

Twitter's Tips for Making Software Engineers More Efficient - IEEE Spectrum: "Reducing the number of times tools break—even if each incident just causes an interruption of a minute or two—can bring about huge productivity improvements. Seibel explains that each interruption takes an engineer out of “flow,” and studies show that it typically takes 15 minutes to enter a flow state. "

'via Blog this'

Thursday, September 17, 2015

Zero - smart and secure email client for your inbox on the App Store

I just installed the "Zero" iPhone app - and I *love* it.  It allowed me to plow through 200+ (I think 300+) emails in my Gmail Inbox in less than half an hour.  Whereas I only had managed to clear out a dozen in an hour using Google "Inbox for Gmail" earlier today.

I love Zero enough that I paid 5.99$ for an upgrade to unlimited accounts within an hour or starting to use it.  But, see below.

And I cleared out my Gmail Inbox using Zero while walking on my treadmill desk!!!   OK, I admit that I do everything except detailed drawing and coding while walking on my treadmill desk.  But Zero was easier to use than most other apps.

Zero is a lot like Triage (http://www.triage.cc/) - an email app that I used to use on Android, although the web page only mentions IOS at the moment.  I gave up Triage a while back, because back then (1) it required VPN to run on my phone in order to connect to my mailserver - which I am guessing meant that it did not use ActiveSync to connect to Microsoft Exchange) - which was suboptimal because it meant more hassle, and a long password, to type in when I wanted to quickly triage my email, and (2) back then Triage crashed a lot - sometimes seeming to delete email.

      But when Triage was connected and was not crashing, it was sweet!

Both Zero and Triage do one job really well.  They aren't full mail readers.  What they do is allow you to quickly go through your Inbox, quickly archiving or discarding low priority email, allowing you to manually filter out low priority stuff so that only important stuff is left for you to handle, using a more powerful mailreader. Both Zero and Triage have some ability to respond to forward, email, or create new email - short messages, after which you archive or delete.  But longer replies you would want to handle somewhere else.   (Back when I was using Triage, most of the crashes and lossages were related to replying to or composing new email.

The key reason why Zero and Triage are more efficient for this particular email task is their user interface: they both use a "card" interface.  One email per card.

The card shows a lot of a message - often the whole thing.  Imagine the "preview" lines you get in a typical mailreader, but expanded to a screenful per message. You can tap on an email to truly see the whole thing, with HTML formatting, etc.  But the "large preview" you see on the card allows me to process emails more quickly, much more often than the "short previews" you see with regular mailreaders like Outlook or Inbox or Mail or ...

And then the actual processing is easy: in Zero's case, swipe upwards to archive a message, so that it no longer appears in your Inbox. Swipe left exposes a screen to the right where you can see the full email.  Tap a star to leave the mail in the Inbox.

Yes, this is not that different from the swipe actions of your favorite mailreader. Swipe right to archive, swipe left to schedule. (AFAICT neither Zero nor Triage have a "Defer" feature.)

But the cards, allowing a large amount, often all, of the email to be seen, and the simple swipe, allows me to go much faster.

Also, I have noticed: I seem to be able to swipe up or down much more easily than left or right.  In part because I often switch the hand I am using the phone with: thumb swiping up works easily with either hand, but swiping left or right is more difficult no matter what, and often much more difficult in a non-preferred direction.

(I believe that swiping up was one of the big reasons that I found Flipboard https://flipboard.com/ so pleasant to use when it first came out.  And Flipboard isn still pleasant to use in terms of swiping - it is just horribly full of ads and crashes my iPhone.)

I think this "card" interface is becoming a BKM (Best Known Method).  I wish that it were integrated with standard email apps, like Inbox or Outlook for iPhone.  Cards are just an alternate interface or "view".  Most email apps have several views: (1) the message list, w/wo previews, possibly sorted.  For Inbox, some other folder, or a search. (2) a full message view. (3) Now "cards".

     (I really think that a "folder tree view" should be included, although most email readers have really, really, sucky tree viewers.)

I love Zero enough that I paid 5.99$ for an upgrade to unlimited accounts within an hour or starting to use it.  But...

Zero is free for the first account, 1.99$ for the second, and 5.99$ for unlimited.

I hoped that I could be able to use Zero for my work email - I seem to remember that Triage could access our work server, using Imap (hence requiring VPN).  But this seems not to fly.

So, I can only really use Zero for my personal email, not at work.  I won't begrudge them the 6$ - I like supporting software that is useful.  I wish them luck.

This situation is becoming more and more common:  email is something people spend a lot of time on.  There are many good ideas bubbling up - cards, swiping, AI-like autoprioritization.   But no single app has all of the good ideas.  

So we end up using multiple apps. Email widget apps, that do one thing well, but where you have to use other apps for other things. And just cross our fingers that the apps play together well.

Zero seems to use Gmail's standard Archive feature. And Zero's "mailfeed" seems to be just "Inbox and Unread" - i.e. Zero's concepts seem to map to standard Gmail concepts.   I hope it will not interfere.

As far as I know,  there is no standard feature for "Defer email to process later at a scheduled time".  Different mailreaders handle this in different ways: labels, special folders.  

And this is a common situation wrt security: typically, not being able to access corporate mailservers using your favorite mobile app.  Being restricted to a much smaller number of limited, less innovative, email apps, like Microsft's Outlook app or Apple's standard Mail.app.

I understand corporate IT's unwillingness to allow random apps access to the corporate mailservers.  Especially when those apps often process the email on the app company's servers - even if they put it back on your employer's mailservers.

I just wish that there was a better way: a way to get innovative features, like Zero and Triage's cards, on my work email.

I suppose monetization is part of the problem.

More and more, I find that the technology I use to handle email at work sucks compared to what I use outside work. Not only is it slow, but it is so much less pleasant that I am averse to reading work email using the primitive apps.

Zero - smart and secure email client for your inbox on the App Store

'via Blog this

Tuesday, September 08, 2015

Version Control of Crash Recovery Cruft

I have developed a system whereby I archive the "cruft" created by a crash into a tar file


so that I can recover autosave files if necessary, but so that they do not clutter my directory.

I just added a quickie to count the number of crashes saved, or at least an approximation thereof.

This is one of those "duh, why didn't I do this years ago" sorts of things.

EVERYTHING needs version control.

Even crash recovery files.

It sure is nice to have multiple versions of the same crash recovery file(name) , rather than having to rename them autosave.1 autosave.2, ...  (Most important thing is to be able to name things. Second most important thing is to not have to name things.)

    CRUFT_FILES= $(FM_CRUFT_FILES) $(PPT_CRUFT_FILES)    FM_CRUFT_FILES= *.auto.fm *.backup.fm *.auto.book *.backup.book *.recover.fm *.recover.book    PPT_CRUFT_FILES= *Autosaved*.pptx    .PHONY: save-cruft    save-cruft: archive-all-autosave-files    .PHONY: archive-all-autosave-files    archive-all-autosave-files:    -echo $(PPT_CRUFT_FILES) | gtar -uf TAR.archived framemaker-cruft.tar    -rm $(PPT_CRUFT_FILES)    -echo $(FM_CRUFT_FILES) | gtar -uf TAR.archived-framemaker-cruft.tar    -rm $(FM_CRUFT_FILES)    make unlock-all-framemaker-files
    .PHONY: ls-cruft    ls-cruft:    ls $(CRUFT_FILES)
    .PHONY: count-crashes    count-crashes:    .PHONY: count-saved-crash-cruft    count-saved-crash-cruft:    gtar tvf TA*tar | perl -p -e 's/^([^ \t]+[ \t]+){3}([^ \t]+ [^ \t]+).*/\2/' | sort -u | tee >(echo "Unique timestamps (crash points in archive):" `gwc --lines`)

Sunday, September 06, 2015

Who says Mac OS X does not need uninstallers

I have heard people say that Windows needs uninstallers for DSW because of design flaws, whereas Mac OS X does not need uninstallers because of its perfect UNIX-ish design.


Evidence: uninstalling the "Basis Sync.app", now that I am no longer using my Basis B1 watch (R.I.P.).

The web page link says, paraphrasing: "To uninstall move the 'Basis Sync.app' from the /Applications folder to Trash.  Also, go and remove support files from ~/Library/Application Support/Basis Sync."

The two separate steps would be encapsulated by an uninstaller.

But furthermore:  trying to move the 'Basis Sync.app' fails, because the app is running - I was starting it by default.  (I guess Apple has put in a Windows like interlock; normal UNIX would blindly unlink a running program.)  Option-Command-Escape does not show 'Basis Sync.app' as running.  However, standard UNIX ps does, and I can kill it, and then remove the app.

I know how to do this.  But how many non-UNIX users would?   My wife?  My mother?

Automating - creating an uninstaller - forces the software vendor to really know how to uninstall.

Wednesday, September 02, 2015

Watch and fitness band

After the Withings Activite' Pop failed to satisfy, I have reverted to a slightly updated version of what I have been wearing for the past year: a semi-smart watch on one wrist, and a fitness tracker wristband on the other.

Before their watery demise, I was wearing the Basis B1 watch, and a Jawbone UP.   I bought the Basis watch first. I later bought the Jawbone UP, at first just to get vibrating alarms - but I liked the UP iPhone app so much more that it became my main fitness tracker.   I mainly used the Basis as a watch, to tell the time, and because it had a display so that I could see how many steps I had done without opening my phone.

Now I am wearing a Pebble Smartwatch, and a Jawbone UP2.

The UP2 because I continue to prefer its app, and for sleep monitoring.  The Jawbone UP was able to tell whether I was awake or asleep automatically, but only the Misfit watchapp can do that on the Pebble - and it interferes with other watchapps, like the Jawbone UP watchapp, which actually counts steps. 

Interference between watchapps is the bugbear of the Pebble.

I was therefore a bit disappointed to learn that the UP2 has separate modes for sleep and awake.   Automatically detecting is the entire reason I got the UP2.

The Pebble SmartWatch  (a) because running the Jawbone UP watchapp displays steps taken in almost real time - i.e. because it has a display.   (b)_Swimming.  (c)_Other smartwatch goodness: (c.1) calendar (via SmartWatch Pro), (c.2)_notifications about email and text (mixed blessing, needs better filtering), (c.3)_bus and train schedule. (d) Because I can write my own watchapps, in my own copious free time. 

I can already feel the gravitational pull:  I am frustrated when something that could fit in the smartwatch's limited form factor is not available as a watchapp. Just as I prefer to use my cellphone for most things that fit on it, I think the same will apply to the watch.   The cellphone just has a bigger display, and the MacBook an even bigger display, and a big keyboard.

If we had goggles...