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.

Wednesday, November 11, 2015

I hate Outlook!: the continuing whining, bitching, and moaning

I very carefully recovered circa 251 emails that were misclassified as spam.

Bug reports that I wanted to ensure were not lost, etc.

And then I accidentally deleted them. Wrong folder.

No undo.

I hate Outlook!

Friday, November 06, 2015

Stupid Blogger does not understand difference between symbolic link and data deduplication

See the quote from a UNIX bigot's blog at bottom.

Now, I am a UNIX bigot.  But I also try to be an unbiased UNIX bigot.

In particular, I understand the difference between data deduplication - a filesystem where two completely separate files that happen to have the same contents will be transparently linked, behind the user's back, to share physical storage.

Linked in such a way that, if one file is modified and the other is not, then the change is NOT propagated to the other.

I.e. linked transparently to the user.  Invisibly, except for occupying less disk space.

Symlinks are sometimes used as a "poor man's" approximation to this.  But symlinks are definitely not transparent.  E.g. if the target file is removed, the symlink dangles.  That should not happen in a proper "single instance store".

For this matter, UNIX hardlinks can be used as a "poor man's" approximation to this.   But, again, not transparent.

Now, I do not know if Microsoft's single instance store is fully transparent.  But I suspect it is - or at least more so than symlinks or hardlinks.

The Civilized Explorer Travel Bizarre Link Page: "Microsoft Innovations. This is an actual press release dated February 28, 2000, on the actual Microsoft Web site wherein Bill Bolosky and two Microsoft colleagues claim to have invented symbolic links three years ago!
... an idea occurred to them -- why not save operating system disk space by storing duplicate files as links that point to a single file housed in a central location?
Are these guys brilliant ...
During the next 1-1/2 years, Bolosky, a researcher in Microsoft Research's Systems and Networking Group, and three of his researchers worked full time with the Windows 2000 team to build the technology, now known as the Single Instance Store.
Or what?
And you thought Microsoft's only innovations came from other companies that they either bought or crushed."

Stupid UNIX bloggers unite!  You have nothing to reveal to the Internet except your ignorance, and inability to absorb new concepts!

'via Blog this'

Thursday, October 15, 2015

Google Chrome browser shows corrupted content on Mac OS X – DisplayLink Support

Google Chrome browser shows corrupted content on Mac OS X – DisplayLink Support: "This issue is due to the browser attempting to use hardware acceleration functions not currently available on virtual screens."

I got bit by this bug - disabling hardware graphics acceleration in Chrome, but not elsewhere, fixed the problem, as recommended by DisplayLink.

I wonder why the DisplayLink cannot hook the acceleration calls, and report ion error when applied to their display?

But I also wonder why Chrome does not check the capabilities of the display.  Here, the problem is probably confusion, since some of my displays have acceleration, and some do not.   Heterogeneity - gotta love it!  

Q: why does MacOS expose use of accelerators to apps?

'via Blog this'

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