bwooce's comments

I've dropped Twitter. Their iOS client regularly pushed so many ads down my throat (in stream) that (a) I noticed and (b) I noticed it every day.

When I got to the point of blocking every advertiser (confirmed views +1!) but they popped back up under different special handles I resigned myself to defeat.

I will miss the serendipitous discovery of tidbits of information that it enabled, but the signal/noise (or rather, content/ads) ratio was overpowering. It needs to make money, but I think it's killing itself or at least transforming itself into the equivalent of TV -- content producers broadcasting to a largely passive audience.

What magic directory names? The special case for "pkg" is the only one I saw.

The main proposal is one of scoping by directory hierarchy - /a/b/c can import a/b/d but a/g/x can't.

Can you remove/align the localizations on the phone number in loopd? I'm in Australia and can't put in a phone number.

Looks good otherwise, I'll try it around Sydney tomorrow.

It's cute that you're both naming your products after New Zealand's national bird.

Both of your products sound like dating sites dedicated to meeting New Zealanders. That's....a niche market.

Kiwi != kiwifruit, if you talk if eating a nice juicy kiwi in the rest of the world you're either salacious, a cannibal, or undertaking some kind of illegal feast (main course: roast bald eagle perhaps)

the only bit I'd prefer clarification on is:

Timestamp with Timezone

There’s seldom a case you shouldn’t be using these.

For recording most event times that's true but:

Birthdates (which can include times) shouldn't use them.

Calendaring should think very carefully too, should the 9am meeting move to 10am due to DST? or should it "stay put" but potentially move for other timezones?

If you want to know if the connection went down in a reasonable timeframe e.g tens of seconds, then you need to implement heartbeating over TCP. This is the first thing any new protocol on TCP usually does.

Go impl: https://github.com/dchest/blake2b

New words for my vocabulary:

congaed - past tense&participle of conga scrod - young cod/haddock/white fish split and boned. (also schrod, also available).

"Strip out the baseband" of a dongle and you won't have a device that can connect to the network, authenticate, shift cells or anything else. It's like stripping the firmware off your disk drive.

Fully support the initiative for an open baseband. One reason it's not open is the (fairly legit) fear that intentional and unintentional DoS attacks would occur, affecting everyone in the area. It's really really simple to be an obnoxious cellular network citizen and it's pretty damn hard to police.

Baseband bugs that impact networks are common too due to the complexity. I saw a function point analysis of GSM vs 3G once, seem to remember 1-2 orders of magnitudes difference. Ahh Function Points, you flawed devil of a management metric.

Is this not what you want? http://www.leonardodigitale.com/index.php?lang=ENG

Dome houses are initially appealing but ultimately and practically have too many flaws to be useful. Single room houses may be an exception.

Read this http://www.shelterpub.com/_shelter/domebuilder's_blues.html and see how many of the concerns are addressed in this design.

Lloyd was passionate about domes, but came to realize their flaws. Most of these are applicable today despite the materials improvements over the last 30+ years.

US Citizens have some (reasonable) expectation they won't be spied on without some cause. They may even get back to that situation eventually through legal challenges against the supra-legal shit going on.

The rest of us, well, we were always subject to this oversight and it won't change. We just didn't have our noses rubbed in it very often and US media don't give a damn. I expect Chinese companies are just as paranoid about data flowing through the US as the US are about their data being in China.

It's a timely reminder for us all. Remember that putting your data elsewhere doesn't mean anything if (a) it transits the US unencrypted or (b) the parent company is US owned.

Agreed. This is why the scientists playing with creating influenza variants freak me out. I suspect they have the 1918 variant on hand, combine that with something a bit slower to present and we'd have a winner.

As David from 27b/6 is wont to say: (In Australia) "... practically every living creature can kill you in under three minutes. Our primary spoken language is screaming".

Not when you could have sold the TV for $10K. This is the shoplifting issue; the shop loses both the product and the potential profit on the product.

It gets a bit existential e.g. can you lose what you never really had? But even if you fall on the NO side of that, the cost of re-obtaining a product is not zero.

There appear to be some philosophical differences that mean this won't occur.

Specifically the "let it fail" aspect of OTP, which begets supervisor hierarchies and the consequent lack of exception handling required.

This has been brought up before and dismissed (not the unix way perhaps? I forget), and supervisors have been implemented in go by others from Erlang backgrounds. It's just not quite the same as being built in.

The way goroutines are not linked to their parents or children is related to this. It's a conscious design decision, but I am still adjusting my style to it.

It appears so, that red stamp appears to be different every time it appears.

The clueless idiot that got their stamp pad out that day is probably long retired or dead.

That big black stamp on page 2 doesn't look original either though, to be fair."ex dono" = as gift.

Ok, it's sensible to make these logs easier to parse.

I don't understand why an entirely new Tag-Value scheme was invented though, and this article doesn't attempt to justify it. Maybe it's not new and I just haven't heard of it?

Why not use: JSON ASN.1 BER Or any other scheme with existing, mature, encoders and parsers.

The irony is that they're excellent for preventing aerosol droplets filled with virus from the wearer. Wearing one when infected is therefore responsible.

Well, no there are several good cases where storing a time in UTC as seconds since an epoch is wrong.

It's a common mistake.

The first usecase is Birthdays. For most purposes people do not want to store the extract time and date of their birthday in the original time zone. Apple do this, much to my annoyance - it means people's birthdays change as you move around our planet, and that doesn't align with how they work in the real world. If I'm born in Utah on 1/1/1980 it does not mean I celebrate my birthday on 31/12 when I'm in Australia.

The second usecase is recurring meetings, particularly with global participants. The mind bending case is where you have DST in some or all of the TZs. The only remotely correct thing you can do is keep the meeting at the same wall-clock time in the TZ of the meeting owner (9am meeting stays at 9am). Most apps don't, and there is no perfect answer (consider a participant in a different TZ - the meeting changes to a possibly conflicting time).

Sometimes storing the absolute time/date is correct. Other times storing the original UTC offset, as well as the time in UTC is. But most of the time, yes, store it in UTC in whatever form you prefer.