Why podcasts don't work for me

Why podcasts don't work for me:

I don't have a driving commute, so when it is the case that I am driving, it's either a short trip, or I have passengers, or I'm going to an unfamiliar place so I have to pay attention to navigation. Plus my car time is irregularly scheduled. And to top it off, my car's audio doesn't have an aux input of any sort.

When I'm not driving a car, I'm usually reading, writing, doing work with my hands, exercising, meditating, thinking deeply about something, sleeping, or talking with someone. None of these activities are compatible with listening to a podcast.

And finally, podcasts are too slow and too linear. I can read well formatted text an order of magnitude faster than someone can speak clearly.

Plus my reading style is to constantly jump backwards while reading ahead, constructing lists and building up the "idea structures" that the text is presenting, and then if the text was interesting and useful enough, jump back an entire section or chapter or the whole work and reread it again, filling in the structure that I built the first time. There are probably people out there that can do the same thing in one pass, memorizing the text in one flat read or as it's dictated to them, but I am not that smart.

In other words, if a podcast is that awesome, please also translate it into an essay, or even just a cleaned transcript, and I will read that instead.

How Microsoft could save their mobile business

I feel bad for the winphone product team at Microsoft. On a purely technical basis, in many ways, the current MSFT phone OS is superior to both iOS and Android. However, none of the ISV's trust MSFT not to pull the rug out from under them, again. How many times has Microsoft abandoned their mobile OS ISVs this way, developing, marketing, pushing, and then suddenly EOLing a mobile OS with no sane forward path? At least seven. Sometimes very abruptly. Microsoft could still possibly get a win in this space, but they will have to keep their mobile phones and mobile phone OS in the market for at least 2 more years, before any ISVs start trusting them again.

If it was me tasked to save the winphone, I would do the following things, all at once:

1. make the developer experience for developing for their phone seamless
2. give the all the developer tooling and training away for free
3. hire several parallel teams of app developers, and put them to work grinding out useful apps.
4. Focus the security model and app priority list on the actual needs of business and users and IT departments. (Which means a lot more than just "port Office to it".)
5. And then, the big one: open source all those apps, and the dev tools, and the mobile OS itself.

In fact, Microsoft could do something both amazing and good for themselves, and GPL the winphone OS, and GPL the HALs for all their Nokia hardware. Since they would be the copyright holder, the GPLs stickiness works *for* them, instead of something they would be terrified of and fight against.

They are not going to do any of this, of course. Instead they are going to do something stupid, like try to "converge" their cloud server OS, cloud guest OS, data center server OS, desktop OSs, tablet OS, and phone OS all to the same code base. Which is one of those things that seems like a great idea at first, until thinking through it more deeply.

Rant: account setup and reset flows for banks are all terrible

Why is the account setup and password recovery flows for the sites of financial companies so utterly terrible?  And so insecure?   "Please fill in the following badly structured form with your personally identifying information that is easy to research from public records" and then emailing a new password in the clear, instead of a reset link, seems to be standard practice.

Account setup for financial, insurance, employment, medical, legal, regulated utilities, and government services should go through registered postal mail, and/or in person.   And if I were king, that would be black letter law, with no wiggle room, and draconian penalties, plus private rights of action with statutory damages.

On telco admin access to your DSL or DOCSIS modem (rejected by the Cryptography mailing list)

(The following post was rejected by the moderation of the Cryptography mailing list as "inappropriate", so I am posting it here, instead.)

Bill Stewart writes:
probably the telco has their own [administration interface] for the DSL [modem].

I respond:

Having had jobs where I had access to the management and configuration UIs for various brands of head end units for DOCSIS [cable modem] and for DSL systems, and for various brands of remote management tools for customer side equipment control for DOCSIS and for DSL, all in lab settings: I flat guarantee that the telco has their own management access to your DSL modem, and that that management control can see both the CSE and CPE sides of your modem.

When we were lucky, the modem lets the telco change the credentials to the telco admin interface. All too often, it was fixed to a hard default by the modem manufacturer.

IMO, one of the deeply fundamental problems with both DOCSIS and with DSL is that the telco has to trust the equipment installed at the customer's site, and thus cannot allow the customer to randomly play with what it can be configured to do. (For example, at least in 2004, DOCSIS 1.1 and DOCSIS 2.0 did bandwidth caps in part on the terminal side, instead of at the head end.) This is the kind of deeply stupid design error that only someone breathing the telco / bellhead koolaid can make.

Regarding systemd

After reading this rant by Christopher Barry about systemd, I feel the need to weigh in myself about systemd

After learning more about systemd at the LinuxConUS last year in New Orleans, I took half a day to audit the source code. It's a nasty complex hairball, full of internal boundary violations, leaky abstractions, undocumented implied state, no DRY (don't repeat yourself), and poor code style.

It is, in short, a pile of shit, worse than most, and is not to be trusted, especially NOT as process id #1.

How to disable SELinux of just Apache on CentOS6

yum install policycoreutils-python
semanage permissive -a httpd_t

A wishlist of features for conference call providers. The internet exists, let's use it.

At HP, we are heavy users of conference calls. Most of those calls are provided by InterCall, and we are moving over to using Lync running on the corporate network. And when I was at RedHat, we used a lot of InterCall there as well. And of course, there are all the various external partner calls on Cisco WebEx and on Join.ME.

I have developed a wishlist of features for conference call service providers.

My first simplest wish is that bridge id's / meeting id's should be forbidden from having a repeating digit. This is big pain point that expresses itself when dialing quickly or when using an automated dialing string. I would say that at least half the time, when there is a repeated digit dialed quickly, it gets mis-interpreted.

Next, I wish there was a simple modern web app (with an underlying REST API) that lists all the lines connected into the bridge, showing for each line the caller id, registered user, connection time, is-muted, and instantaneous momentary current sound input level. By "registered user", I would like people to be able to say "when you see this CID/ANI, that's ones of my phones, and display my name". And for the sound level, it would be "who's line has the barking dog"?

And my big "I wish for a pony" wish: I wish for standards compliant SIP VoIP interfaces. Often I connect to a concall by running a SIP client on a machine or device, connecting that SIP client to a SIP/PSTN gateway service provider, and then dialing into one of the PSTN numbers of the concall service provider. It seems that it would be better to bypass some of that complexity, and just be able to point my SIP client directly to sip:123-456-7890@hp.intercall.com

Intercall actually does provide a HA QoS MPLS SIP interface designed to be plugged into large corporate soft PBX systems, but it's not available over the public internet. It is understandable that Intercall can't guarantee call quality for internet VoIP, but a supported best-effort interface would still be useful.

Microsoft Lync is, of course, VoIP, but it's not at all interoperable with any other VoIP client. It has "embraced and extended" SIP with a lot of semi-documented MSFT-only extensions. It does use well known codecs, but it runs media transport over TCP in a way that is in no standard and like nobody else does. (The term "realtime media transport over TCP" makes me facepalm).

Facebook is poisoning itself

My FB feed is getting more and more polluted with "shared" links to "news media" "articles" that already have lots of eyeball juice, and the communicate almost nothing beyond the sharer's own confirmation bias.

Original content textual posts, and links to pictures and other personal media, about what my friends and contacts are actually doing in their own personal life, are now almost entirely crowded out. Also crowded out are posts by businesses and organizations that I've followed (now called "Liked").

The payoff of the personal time investment into Facebook is declining severely.

My own workflow for FB now is to individually select the feeds of half a dozen people I'm most interested in and read them. Which, hilariously, is the *original* FB workflow, back when it was .edu only, before they came up with the "unified feed wall".

Iterative cost reduction causes collapse of UX quality

One can always keep shaving cost by 5% each iteration, each time yielding with a 10% drop in quality of user experience.
That's not impressive at all, and continuing in that course will eventually kill your company.
What is instead impressive and profitable is spending 10x the money, and using those resources to get 100x the UX quality.
That is one of the lessons of the iPhone.