Zero breaks "swiping up"

BRIEF:

The original Zero app, with its triage mode that allowed you to swipe up to archive email was great.

But updates to the Zero app broke thus triage mode. At the moment the Zero app is just yet another yawn inducing email app. It will not be worth using, installing, or purchasing until they fix triage mode so that you can swipe up to archive.

Swiping up/down is significantly more efficient than swiping left/right because humans have opposable thumbs.


DETAIL

My original review of Zero is below. When Zero first came out I gave it 5 stars. I would have paid 50$ or more if Zero had ActiveSync support to allow me to use it with my company's Exchange servers (IT disallows IMAP).

But every few months they update Zero, and every time they update Zero my rating goes down. I haven't used Zero in months. I really should give" it the lowest possible rating, 1 star (zero stars if possible), but I give it 2 for now because I hope it may go back to being worth using. I try every update, but give up disappointed.

Here is what I like about the original Zero app: triage mode. A mode where you see one email, and can swipe up to archive it, or do something else (back then, hit star) to keep it in your Inbox marked as read. Swipe left to look at in more detail, etc.

Indeed, before using Zero on iPhone I used a similar app called Triage on Android. Similar "swipe up to archive" interface.

This "swipe [up] to archive interface" allowed me to empty my Inbox quickly. One quick swipe, rather than tap to read, hunt for a button to archive or otherwise handle. One easy swipe, rather than a lot of finicky small movements. Speed is proportional to ease of UI action.

Sure, the original Zero had shortcomings: My main complaint was lack of Exchange ActiveSync support. Also, I want to use this triage "swipe to process" on other mail folders: e.g. I have rules to sort mail into high and low priority bins, and for different projects and clients. It simplifies time tracking when I am not mixing mail from different projects. Plus, better standard mail tools, like move or copy to folder.

But, even without those, the original Zero was useful. Unfortunately, the updated have removed the feature that made Zero special.

Zero's updates have, for the most part made Zero more of an ordinary email app. Better rendering, different buttons, swipes in the message list. Not bad, but I can't see any reason to use Zero rather than another mail app. Originally, I used Zero's triage mode, and then switched to another app like Outlook to do non-triage email processing (also to read email in the rule based folders that Zero's triage mode cannot access).

Unfortunately, from my point of view Zero's updates broke triage mode. :-(

Sure, the updated Zero still has triage mode. Plus, it has more swipe actions: swipe left to archive, right to keep. (As opposed to swipe up to archive in the old Zero. Also, the new Zero has no swipe up or down)

In some ways the new Zero is more symmetric: swipe left to archive, right to keep, as opposed to the old swipe up to archive, tap a star icon to keep.

Unfortunately, it turns out that swiping UP or DOWN is important for the most frequent actions. At least for me - and I suspect for many other users. Something similar arises in apps like FlipBoard - a rather successful app, whose initial success was largely due to swiping up or down vs left to right.

On an iPhone held in your hands, one or two handed, swiping up or down with your thumb is faster, easier, less muscle strain than swiping left or right.

Swiping up or down uses the big joint at the base of the thumb, and the big muscle that "swings" the thumb. Eg imagine holding your hand out, fingers splayed, and swing the thumb to the other fingers, or across the palm. I.e. the muscle that gives us the opposable thumbs that are so important to our success as the human species.

Whereas swiping left or right requires bending the thumb at the joint closest to its tip. Finicky small muscles. Muscle strain inducing movements.

Like many people, I suffer from thumb strain, and from other RMS problems. Swiping up or down reduces such strain. Swiping sideways increases it.

Swiping up or down also allowed me to change which thumb was doing the swiping. Swiping left or right means that swiping away gets stressed on the right thumb, swiping in gets stressed on the left thumb.

Swiping up turns out the be slightly easier than swiping down - the hand grip strength, versus the jam that rock climbers use to stay in a crack. But up or down is 2-4x less stressful than left or right. So swiping up should be used for the most common action, down for the next most, side to side for less common.

If you are able to hold your phone so that the big joint of the thumb is directly beneath the home button, you can swipe side to side easily. Most people cannot do that. Similarly, if you lock the phone on portrait mode but hold it in landscape mode, your thumbs can actually swipe up and down although the app thinks they are left/right. But you have to be able to read text sideways to do this.

This may seem like a small thing, but it is not. Reducing stress, and allowing email processing to be done quickly is important. I doubt that Zero will be useful to me until they restore the ability to swipe up to archive.

Until then, I actively recommend most people do NOT use Zero. I regret purchasing it. At the moment Zero is just yet another yawn inducing email app.

Triage mode is the thing that made the Zero app worthwhile. But they broke it. I hope that they fix it someday.

--- my original review
--- unfortunately no longer applies

I love Zero. Helps me keep on top of my email, approaching elusive "Inbox Zero". Only problem is that Zero does not use ActiveSync, so I cannot use it for work. I emailed the developers a few minutes ago saying I would pay 50$ if Zero supported SctiveSync. 50$ in a world of 5$ apps - that is how much I like Zero!!!!

FitBit: Goal Day Challenge Not Calculating - Infinity ... - Fitbit Community

Solved: Re: Goal Day Challenge Not Calculating - Infinity ... - Fitbit Community:



I just had the same problem: 12k steps on my FitBit, and in app, and in webpage, but infinity as reported in one of the challenges I was participating in. (But not in a different challenge.)
 



"Fixed" by quitting, and then having a friend invite me back in.
 



Nevertheless this is a bug.  It may be a SW bug in FitBit, an uncorrected DRAM error - or, worse, evidence of iPhone malware breaking in. Possibly through a bug in FitBit, possibly through some other iPhone vulnerability such as the recent https://www.theguardian.com/technology/2016/jul/22/stagefright-flaw-ios-iphone-imessage-apple
 



I am doing a factory reset now, but it may be too late - the malware may have already stolen all of my passwords and emptied all of my bank accounts.
 



This sort of +infinity bug is more scary than a "the FitBit iPhone app won't let me do...", because the +infinity indicates data corruption.
 
FitBit should fix this bug, if it is their bug.



'via Blog this'

Triple-Parity RAID and Beyond - ACM Queue

Triple-Parity RAID and Beyond - ACM Queue: "A Classification
for Triple-parity RAID

None of the existing RAID classifications apply for triple-parity RAID.  ... The next obvious choice is RAID-7, but rather than applying the designation merely to RAID with triple-parity protection, RAID-7 should be a catch-all for any RAID technique that can be extended to an arbitrary number of parity disks. Specific techniques or deployments that fix the number of parity disks at N should use the RAID-7.N nomenclature with RAID-7.3 referring to triple-parity RAID, and RAID-5 and RAID-6 effectively as the degenerate forms RAID-7.1 and RAID-7.2, respectively."
'via Blog this'

I reject this RAID-7 terminology.  Or, rather, I find this terminology not useful - not useful for thinking about, explaining, extrapolating.  If Marketing needs to use RAID-7, fine, let them - I will translate to what



The original RAID terminology was never coherent, arbitrary numbers, mixing considerations like bit, byte, and block level, dedicated parity disk versus rotating the parity, etc.



More and more, I am starting to use meaningful notations like

• Rd+p = redundancy, with d data disks and p parity (or other) disks.
• e.g. assuming striping at fixed size block level, and that all rotate parity 
• Rd+1 = classic RAID-4, with d data disks and 1 parity disk, 
• R4+1 = 4 data disks + 1 parity disk
• R2+1 = 2 data disks + 1 parity disk
• R3+1 = three data disks + 1 parity disk
• R1+1  = ??  arguably, a mirror, see below
• Rd+2 = d data disks + 2 parity = classic RAID-6
• Rd+3 = RAID-7 as proposed above, with triple parity

By default we may assume that there are stripes that contain all of the data disks and parity disks.

However, there is value in thinking about different nesting or grouping for higher levels of parity or reconstruction codes.  e.g. L1-parity may be within a stripe, L2-parity may be across a stripe of stripes, i.e. recursively nested, or across a different stripe that intersects the current stripe in only one disk. The write overhead grows in either case, especially for partial stripe writes, but less with intersection than inclusion.

I.e. you may have Rd+p, but you may have D > d+p disks.  No, I don't have a good notation.

An extension to the notation describes not the amount of redundancy, but also how many disks can be lost.

E.g. Rd-f, with d data disks, able to tolerate the failure of f disks.

Typically   Rd-f => Rd+f,  but not necessarily logical/physical  storage proportional to d/(d+f).  As mentioned above, the reconstruction codes may be calculated on nested or intersecting groups, e.g. R4+1 groups nested in an R12+1 group 4/5*12/13 = 48/65.  (Assuming that this is truly R*-2.)  (I am not advocating this, or even asserting that this is possible -m I just want a notation that can describe it.)

Perl prototypes quite useless

I already knew this - but to emphasize the point.



perlsub - perldoc.perl.org: "prototypes have no influence on subroutine references like \&foo or on indirect subroutine calls like &{$subref} or $subref->()"



Method calls are not influenced by prototypes either, because the function to be called is indeterminate at compile time



the intent of this feature is primarily to let you define subroutines that work like built-in functions



'via Blog this'

Apple Reminders - at place, on day, but not before time (NOT)

Apple's iPhone / MacOS reminders with time and place sound like a good idea - but they have  been so damned annoying, occurring at the wrong time, that I have been disabling them.

It's the usual "AND/OR" confusion.  The usual UI/UX designer hubris "Users want to keep it simple, so we won't give them the feature that I, the omniscient UIX/UX designer, can't imagine needing in my limited imagination".  Self-fulfilling prophecy.

Use Reminders on your iPhone, iPad, or iPod touch - Apple Support: "With Reminders, you can set notifications that alert you when reminders are due, or when you arrive or leave a location."
'via Blog this'

Investigating the annoying notifications that occur when I do not want them:



E.g. I want to be reminded  to pay bills on the weekend, typically any time after 6pm on an evening, or whenever I arrive home on the weekend.



But Apple keeps reminding me at the wrong time- like, I get reminded to pay bills when I am working during the day on Friday.



I would insert a screen clipping, but Blogger does not make it easy to upload images.  (In fact, I think that Blogger only uploads URLs or images, i.e. by reference, not by value.)



The MacOS reminder dialog says

remind me
[x] on a day (with day and time, which I have set to 6pm)
[x] at a location
  [ ] Leaving [x] Arriving
On DATE you will be reminded when you arrive at this location, or by 6pm that day at the latest.
repeat  Every Week

So I can't complain too much.

• The web page documentation correctly says "OR", both in the MacOS dialog and in the web page clipped above.
• But in the iPhone screen, there is no "OR".

The iPhone Reminder app screen looks like

Pay bills

Remind me on a day YES
Alarm Fri, date, time
Repeat WEEKLY 

Remind me at a location YES
Location  Arriving: Home

I think that I assumed that these separate controls, on a day and at a location, were AND'ed together --- because such ANDing  is, I think, more common in user interfaces.  E.g. most email rule systems AND the conditions, at least in the first generation.



Of course, what I really want is dependency, and event based.  (Hmm, look at some temporal and event based notations.)

• AT or AFTER date-time
• create new reminder one week later
• DO: remind me at that date-time
• THEREAFTER
• WHEN arriving home DO: remind me

Of course, I might have wanted the slightly different structure

• AT or AFTER date-time
• create new reminder one week later
• DO: remind me at that date-time IF I am at home
• THEREAFTER
• WHEN arriving home DO: remind me

We really need standard languages and notations for such compound constraints.



Even at the level of code.



But also at the level of UI.



Possibly graphical - e.g. nested boxes.

ZFS - Wikipedia, the free encyclopedia

ZFS - Wikipedia, the free encyclopedia: "With Oracle Solaris, the encryption capability in ZFS[32] is embedded into the I/O pipeline. During writes, a block may be compressed, encrypted, checksummed and then deduplicated, in that order." 

'via Blog this'

Everything should be encrypted by default.  For individuals, on a per-user basis, perhaps at finer granularity for particular roles and sensitive data.  For companies, perhaps team- or organization-wide.



But per-user encryption loses the ability to deduplicate across users.  Cross-user deduplication is certainly desirable to save storage when there is replication of data, and possibly also to just plain observe such replication, as in spam. Consider an email server like Gmail.



I am going to make the simplifying assumption that deduplication only applies to data encrypted with the same key.  It is possible that different plaintext may encrypt to the same ciphertext, and therefore share storage via deduplication.  But I will mostly ignore this possibility, and certainly not optimize for it. (Although - I am one of those belts and suspenders guys who prefers to actually verify that deduplicated data matches at both the hash and the raw level, rather than just hoping that the hash does not collide.  In my deduplication work (as part of DVCS, merge-rcs-files) I have deliberately weakened the hash to increase collisions to test this.  I would do the same thing for encrypted deduplcated data.)



I am also going to ignore systems where the deduplication service has access to all keys.  Single point of failure.



Obviously: we want cross-user deduplication for less-sensitive stuff, but not for sensitive stuff.  It is tempting to say no-encryption for non-sensitive stuff.



But this nests: we may want cross-team encryption and deduplication, but not global.



OK for a-priori identification ---  "any email from a .COM domain should not be encrypted and should be deduplicated".   But I want these things to be as transparent as possible.



I.e. I want to just plain store data, a message, a block, a file, and have the opportunity for deduplication with shared encryption observed.  With rules, but with as much without rules as possible.



One basic approach  to compute the deduplication hashes, and then compare to whatever hashes are stored, detect conflicts, and then decide to use the keys already stored.



Computing such storage hashes from plaintext, however, might allow an observer, the storage service, to break user privacy.  If the storage service knows the plaintext and the storage service observes a user request for a hash, then the storage can infer the user's plaintext.  Even if the storage service doesn't know the plaintext, it could infer that groups of users are sharing a message - e.g. exposing a samizdat network, or a TOR file sharing service.



Steganography...   False traffic...  Requesting large blocks of hashes (and keys).



Note: while it might seem that the storage service is going to always be able to detect such sharing, if it stores all data, we can imagine systems where A storage service is only storing some of the data.  E.g. a user might want to store a file; the user may ask a storage service if it can cheaply deduplicate with that service; but if there is no cost reduction for storing with that service, the user may store the data elsewhere.   Hence, the user might ask "How much to store data of size SZ with hash key for deduplication H", and the service may respond with a price quote, and, eventually, possibly, keys (if not already implied). (The storage service may not have the private key.)   Therefore, the user may want to hide the needle of its single request in a haystack of other requests. And similarly cache the server hashes, possibly via Bloom filters and various precisions.



Let's make progress by assuming that everything is local - either that we trust the storage service, or that we are caching large parts of its hash and key index.



The user has access to a large number of storage pools, each with an encrypt-key.



The user computes deduplication hashes for each of these pools.  Detects matches.



This can detect unanticipated replication.  At this point an interactive program might say "Your supposedly top-secret private email is available in the encrypted but widely shared storage pool of Scientology.com, and also on skeptics.net.  Do you still want to encrypt it privately so that no deduplication is possible, or do you want to save money and encrypt-deduplicate-store it in one of these shared pools?"



Such interaction is not always possible in synchronous real time.  Hence rules, ranging from "share always" to "initially private, but ask me later to deduplicate".



We still want to preserve as much privacy as possible when we ask storage services for deduplication hashes.



IDEA:  perhaps we might start by asking for hashes that are deliberately weak and collision-full.   These are, after all, a Bloom filter - if there is no match with a weak hash, there will not be a match with a stronger hash, so we would only progress to more exact hashes when there is a chance of a match (and a savings).



Bit-vector Bloom filters with multiple bits set for a match are a nice example.  It might not be unreasonable for a user to locally cache megabyte-scale bitvectors of a storage server's hash index.   (Although if it becomes really sparse, then this approaches multiple hash functions.)



A storage server could game this, reporting false positives at the lower resolutions, just to get the user to request the higher resolution hashes.



We might also filter deduplication requests.  E.g. only investigate the possibility of deduplication for longer messages.   For messages that resemble human uttered text, or x86 machine language, or Java byte codes, or for messages that are or are not compressible, that have certain measiures of entropy, etc...  Yes, I am back to talking about rules - but I am brainstorming as to what rules may be useful.



Since computing strong hashes for deduplication and other purposes can be expensive, suggesting computing mutiple such hashes to decide which encrypted-deduplicated-storage-pool to use may be very expensive.  Back to rules, and possible cheaper low-resolution hashes to start with.



Good crypto usually doesn't parallelize well.   There is usually a serial depedency - although that may not be needed so much for deduplication as it is for encryption and attestation.



But it may be possible to use SIMD-style parallelization when computing multiple such hashes at the same time.



---



In any case: I like crypto and dedup.   I suspect that they will be more and more important in future computer systems.



I wonder what quantum computing does to deduplication hashing, beyond Google's supposedly quantum-proof lattice base PK.



(All the more reason why



---



These latent and long held thoughts were prompted for blogging by the ZFS article saying "compressed, encrypted, checksummed and then deduplicated, in that order".



Since what I am talking about here amounts to speculatively investigating the possibility of deduplication before encryption.



Ah, there's the rub - may use the coarse-grain hashes before encryotion, but ultimately must encrypt and then deduplicate.

FitBit Charge Notifications (Calls)

---+ BRIEF:



The FitBit Charge notification features are almost useless.  At least compared to those on my Pebble watch.



---+ DETAIL:



I was given the FitBit Charge by my company, so had not done a full feature comparison.



I knew that the FitBit Charge was supposed to be able to receive call notifications from my phone, and I had noticed them from time to time --- but I was wondering why I did not notice them reliably.



Here's why: the FitBit vibrates briefly, so briefly that it is easy to miss. The FitBit Charge family only displays the message while the phone is ringing, + 10 seconds. It does not retain any history, so you can't go and see the notification after more than 10 seconds.  If you reflexively hit the FitBit button, the mesage erases.

Help article: How do I get notifications from my mobile device?: "When you receive a notification, your tracker vibrates and the notification scrolls for 10 seconds or, for a phone call, until the call is answered. Notifications are not stored on your tracker.

Press the button on your tracker to dismiss the notification at any time."
'via Blog this'

The FitBit Surge notifies on calls and texts.



The FitBit Alta and Blaze notify on calls, texts, and calendar items.  (No info on selectivity.)



Essentially, the FitBit notification features are almost useless.  At least compared to those on my Pebble watch.