dingosity

So only right wing commentators who advocate political violence deserve protection?

[Also... Do you have any data supporting this hypothesis?]

Complaining your current version of MacOS X has a worse user experience than it did 10 years ago is like buying a Tesla and then complaining about its resale value.

So here I am at this small company that's running out of runway. I'm meeting with my boss, let's call him Mark (not his real name). We're discussing what features we can add in the next three months before half the company is laid off. At the top of the list is the device-key-regen feature that would allow the user (through an arcane series of difficult-to-accidentally-perform user inputs) to regenerate a key and re-submit it for certification. It required changes to the device code, the security gateway code and to the manual. Mark is adamant we should not do this. It would "distract us from other high-value tasks." I then explain the devices will eventually brick themselves without some way to update, or at least re-certify device keys.

Fast forward a month or two and I get laid off. No one buys the IP, so it's no great loss. Just one more project on the burning pile of money called Silicon Valley.

Seven years later I'm working at a company in Seattle well known for a ebook reader that rhymes with "Bindle." Their first-gen devices have a problem. In three weeks, the certs for the device keys will expire, effectively disallowing them from authenticating themselves to network services. I get called in because I had the words "certificate" and "X.509" on my resume. It turns out the manager of the team who built the device software was my old boss Mark. The one thing he remembered is that allowing devices to update (or at least re-certify) keys requires changes to a lot of different software and there was no down-side to not doing it last time.

It is true... there was no down-side to not adding this functionality last time. The company died before anyone other than a smattering of companies could see our IP, and the few beta-users we recruited stopped using the product before the device key certs expired.

Back at the company in Seattle whose logo is half of a smiley face: after MANY failed updates, they eventually pushed out an update that re-certified the existing keys (i.e. - it submitted the public key to a third-party registration authority, authenticating the message with the device's private key.) Not a perfect solution, but given that they waited until about three days before devices started failing, not the worst in the world.

But there was a three-day window in which the devices needed to be on, notice there was a software update and convinced their users to press the "install update" button. Some large number of first-gen devices were not even turned on during this period. When they were later turned on, there was no way to get them the update that allowed them to connect to online services.

The solution was just to tell customers they would be given a new ebook reader. Given the engineering time invested and the number of new ebook readers shipped out, our team estimated it cost the company between $40M and $60M.

My old boss Mark was promoted.

I think my point is... with the possible exception of a company whose devices prominently feature a fruit-based logo, no large company understands what a key-pair or certificate is and how it relates to operational processes which enhance their products' security or trust. And I like to kvetch.

Also, he's not an aspy. I worked with him. He's an Asshat.

Think about what happens if you're on a site that loads hundreds of images and has keep-alive explicitly turned off. Or if you're doing a TLS handshake across a high latency network (TLS, for all it's benefits, requires at least one back-and-forth to setup the secure transport before sending "content.") Or you have a weird / inefficient dynamic loading process. Each of these will cause perceived latency, but have different solutions.

I tend to agree with the OP, it certainly seems like sites I use on a regular basis are laggy, but we may need a more objective evaluation framework than "ugh. the web is slow." And who knows, maybe most of the problem could be solved by getting the OP a better ISP and a faster machine.

   Them: What's your LinkedIn Account?
   Me: Don't have one.
   Them: Twitter?
   Me: Nope.
   Them: InstaGram or TicToc?
   Me: Nope.
   Them: Do you use the web at all?
   Me: Only through Lynx.  I see a lot fewer ads.
   Them: No JavaScript!  How do you use YouTube?
   Me: I don't, really.
   Them: You have no social media?
   Me: Well... I *did* order a pizza from Dominos online once...

   Yeah... I don't use the web much as you would expect for someone
   who's livelihood depends on it.  I just wish USENET was still
   USEFUL.  I have a rant in me about ad-tech and crap-ware on the
   web.  I'm just enjoying my life without the web too much  to 
   write it.  And clearly, HN is my web-tech achilles heel.

a. Lisp isn't a single language, but a family of languages. There's Common Lisp, Scheme, Clojure and even Lisp Flavoured Erlang. They're all similar, but different enough that you can really shoot yourself in the foot if you assume code for one will do the same thing (or even work) in the other. C/C++ have a long history of reverse compatibility and a strong spec that insures interoperability between different implementations (mostly.) Java and C#, for all their perceived faults, have language definitions which are well defined.

b. Functional programming is different. Sure, you can do OOP w/ Lisp (google CLOS if you're unfamiliar with this.) But maybe it's not really a syntax thing and more of a "I have to bend my brainstem around a bit to do 'true' functional programming." (for some definition of the word "true".) And then there's the Haskell guys running around saying you can't do functional programming unless you've written a dissertation on category theory.

c. Other languages have stolen Lisp's functional thunder. When I was a young coder, Lisp was pretty much the only functional language out there. Sure... ML and OCaml existed, but this was before the intarwebs so we had never heard of them. Java and C++ have lambdas these days. And sure, they're not REALLY lisp-like lambdas, but they're close enough. And JavaScript lets you do reduce, forEach and filter, so you can get your monoid in a category of endofunctors on. And if all you're trying to do is irritate your co-workers, FORTH is better for doing that.

I use Scheme and a home-grown lisp-like language every day. I've taught a few co-workers how to cope with it. There are great benefits. But management doesn't pay to send me to conferences like the Java and C# guys get to go to. We also use SPITBOL for a few tasks just because it's A LOT easier for certain parsing tasks than Lisp and more powerful than awk.

We have a lot of engineers who's brains grok Java/Spring. They're reliable. We know what they can do in a given month. None of us Lisp guys want to do the same things. Larry Wall once said something like: "Languages do not differ in what they make possible, but in what they make easy." Lisp makes a subset of tasks an enterprise must perform easy. But it requires time to teach gigging coders how to use it effectively. Some enterprises just don't want to invest that time.

I came the other way.

I started with AWS a couple decades ago. I was lucky 'cause I worked at Amazon and there was always a friend-of-a-friend inside the organization which could put me in touch with someone who understood what the system was doing. Documentation in the early days was bad. We learned to reverse-engineer what was happening underneath the interface abstractions. Kind of a sh***y experience, but if you banged your head against the wall enough times, you were able to figure it out.

Then a whole bunch of AWS people left to go work on Azure. It's not that Azure was made exclusively of AWS people, but you can definitely see some AWS fingerprints all over Azure. The abstractions and interfaces are similar.

GCP seemed to be a different creation, exporting different abstractions. Starting with account creation. How do you create an account? AWS is pretty straight-forward. GCP has several different (undocumented) account types you have to understand before you can complete account creation. Or, you can just guess and pick one at random. AWS Lambdas (for instance) are pretty straight-forward to create. You create the lambda via a command line interface, a {java|javascript|python|c#} program or via the console. It is an entity you identify with a ARN/URI and do things to it. GCP seems to have different ways to identify GCPs (is it an index? is it a name? is it a URL? is it a URI?) and the answer to how to do things was always "you write a python program to do that." (Not so much because there was only a Python SDK, but because there were only Python code examples.)

AWS docs weren't the best in the world, but they were easy to find. And they documented the underlying objects that exported methods / abstractions to modify those objects' state. It was often mildly confusing what you were looking at (abstract, HTTP API or JavaScript SDK) but it was pretty straight-forward to work it out. Over time the AWS docs improved slowly.

Azure interfaces and docs seemed to follow AWS pretty closely.

Getting back to the GCF example. It's well known Lambdas are bits of code you write smushed into a container with the lambda runtime and deployed on a lightweight container. If you REALLY want to know, you can find out if two of the containers are running in the same VM, but you're sort of warned against it. GCF on the other hand... is it running in the same container? maybe. is it running in the same context? answer unclear. ask again later.

It seemed to me the GCF guys wanted to make things a bit more abstract and herd programmers away from assumptions that are easy to make on AWS Lambdas or Azure Functions. And I think that mentality pervades GCP; It's a bit more abstract while AWS and Azure expose more concrete interfaces (until it doesn't in which case you have to ask your TAM to find an engineer who can send you copies of the documentation about an interface they haven't documented publicly.)

It may sound like I'm down on GCP. I'm not really. But it *did* seem to "feel" very different from what I was used to over on AWS and Azure. Smart developers shouldn't have a problem moving from one to another, but when I moved from AWS to GCP, there was a month or two where I wasn't especially productive because I assumed it (GCP) behaved the same way as AWS and when I learned it didn't I had to spend time researching and recoding.

Seems like getting a no or low cost account on AWS, Azure and GCP is pretty straight-forward. Maybe doing a project on AWS and Azure to demo your mad skillz (and to learn how they're different) would be a good idea. That way you could put an AWS project on the resume and it won't be a lie.

Maybe what I'm saying is... yeah... under the hood it's all pretty similar, but the interfaces are different enough that you can take a productivity hit until you learn how they're different. As for me... if someone could demonstrate competence in one, I'm confident they could pick up the others without too much of a delay. I would eat the cost of an engineer having to read manuals and write test code to figure out a new environment if they were reasonably smart and worked well with others.

Things I like:

1. It's obvious where sections begin and end.

2. PLENTY or margin and padding. I know some people try to cram as much info on a single line as possible. My old eyes prefer spacing; it helps them track the text.

3. With one exception (mentioned below) the font sizes seem to "look good."

Things I might suggest are improvable:

1. It's not obvious what the show/hide button at the top of the page does at first glance. The button is at the top of the page and its effects are seen at the bottom of the page. Maybe put another copy of the button immediately above the answer section?

2. Continuing the show/hide theme, the per-answer-section show/hide button hides the content, but maintains the blank space in the document. That seems "wrong" to me since I have to scroll past complete blank areas when looking at it on my phone. And I think we could have no end of discussion whether those buttons should be at the top or bottom of the section that gets hidden. I'd just suggest trying putting them at the top and see if they look better to you.

3. The "Objective", "Question", "Result", "Answer" sub-section headers seem like they should be a little bigger.

I don't know if you tested some of these options, and completely defer to you if you tested them and they look even weirder. Just my $0.02. Mostly looks great.

It's as simple as you might expect from the title. If you're going to criticize someone (even politely, even constructively) give their idea five minutes to ruminate. Fried points out he's discovered some ideas take a few minutes to truly understand.

This is at odds with our move-fast / break-things culture (which I'm told Facebook has pulled away from), so maybe he should have originally said "give it an hour" and then backed off and said "oh. okay. you can't wait an hour. just give it five minutes," and then we would think we're getting the speedy version.

Anyway. I think this might help with posts on comments forums as well. I certainly have posted snarky responses I was later not especially happy with.

I would also add, "if it sounds absurd, read it one more time." But that's just me.

The other day I was thinking... "We should do every thing we can to ensure SoundTransit Light Rail (in the Seattle area) should fail. That way we could replace it with something that actually worked."

This kind of thinking may be accurate, but it introduces near-intolerable levels of uncertainty for the future. Or maybe I should just give up on using mass transit to get to work in the Seattle area. Similarly, maybe I should give up thinking there's anything that will prevent the rentier class from extracting value from the commons by way of broken technology.

Or maybe I'm just having a bad day.