manv1

Years ago I updated authenticator and it wiped out all my entries, which led to an incredibly aggravating week of account recovery.

What happens to your data when google decides to lock your google account? Does your device keep a local copy or will it just shut down?

But yes, Windows NT was basically a DEC product. Cutler probably left because he knew DEC was dead. DEC: the brain was dead, but the body lived on.

DEC showed how long a company could survive on inertia alone.

For a criminal enterprise, FTF authentication is probably fine. You might use PGP keys hidden behind a QR code or something that's user-friendly.

But then you have the other operational issues with the cells, like what do you do when your cell is compromised, or how does a cell reattach to the network if an upper level point-of-contact is compromised.

And there are administrative issues...like a shared calendar. Payroll. Inventory. Logistics alone makes a cell structure difficult, because logistics means coordination among many people.

It would be an interesting project to make for sure.

Any network of users that is large will leak, whether encrypted or not.

People are social, and when push comes to shove they're more than willing to throw someone else under the bus.

The question is, why hasn't anyone designed a standard cell-like structure for an encrypted communication app? Cell-based structures have been known for a long time.

How do you verify + vouch for a new user in a way that's secure yet anonymous?

How do you handle anonymous + secure + directed communication?

The only real interview question that should matter:

The customer wants to increase their sales. They want something that auto-generate sales responses to incoming emails. Discuss.

The problem with technology workers is that they believe technology is important. The above question allows you, the interviewer, to see if they have actual critical thinking skills.

Every relevancy-based search I've used pretty much sucks, so Kendra sounds about par for the course.

"we wanted to share 5 concrete learnings"

Please just say it the normal way: "We wanted to share 5 things we learned..."

And it is not concrete if the learnings are ideas...by definition.

Tokamaks have been asymptotically approaching viability for a very, very long time.

At some point they just have to give up on the design, because it just isn't working. But I suppose as long as there's funding there'll be people trying to get it to work.

This is why you need good people when you start: because good architecture is the difference between fast iteration and slow iteration.

A good architecture will allow you to make changes easily. A bad one doesn't. It's actually pretty simple, conceptually speaking.

If you believe that "late stage" companies make correct architecture choices you're probably incorrect. It's not about late stage or early stage, it's about knowing how to build software from scratch in a way that you don't hamstring yourself (and others) down the road.

There was a post a few months ago about a developer who's job it was to rework ML stuff into actual efficient code. This reminds me of that post because it seems that lots of ML stuff is just plain inefficient...in that they use way too many resources given the problem.

And they're arguing about mmap, something that's been around forever.

It reminds me of that speedup in a package manager because they were reading uncached byte-at-a-time off of disk. You need to explicitly turn buffered reads off...but why would you do that in the first place? Unbuffered reads are almost never a good idea, ever.

It makes me wonder what other weird sub-optimal stuff is lying underneath the resource behemoth that is ML.

That's interesting, I didn't know QEMU could emulate PPC well enough to run that.

Thanks!

Isn't the problem that both CONFIG_IBMVIO and CONFIG_PCI are defined?

I had to see what IBMVIO was, it looks like the IBM Virtual I/O Server. Although you actually fixed the bug, the other bug might be that IBMVIO is defined when it's "The VIOS is part of the PowerVM® Editions hardware feature"

Were you on an IBM power box?

https://www.ibm.com/docs/en/power8?topic=server-virtual-io-o...

I'm just curious, because the IFDEFs assume one-or-the-other as written. Is having both busses a valid configuration?

Look at all that spectrum that can be repurposed if AM radio went away!

https://ntia.gov/sites/default/files/publications/january_20...

Finishing things is surprisingly hard. You have to practice to get good at it.

I'd suggest learning how to paint. Why? Because a painting is literally never done. Just like software, there's always more you can do to a painting. But at some point you need to finish and hang it up.

Even pollock-style splatter painting will work for this exercise.

I've been shipping software and finishing projects for a long time, and it does get easier. There's this weird feeling of anxiety when you're near completion...it's a lot like stage fright. And getting that last 1% done is really, really hard. It takes a ton of effort...more effort that it takes to start.

At some point you have to decide "it's as good as it's going to get" and be done with it.

That's not to say I don't have plenty of projects that I haven't finished; I do. But I also have a lot of stuff that I finished off and am relatively happy about.

Again, read books about art, not about programming. Finishing stuff is hard. It's one of those things they don't really talk about in CS class...or in engineering. It's the reason Jobs used to say "artists ship." They do, or at least commercially successful ones do.

Let's take a step back to the real question: is the developer upset because

1. they don't know how to estimate, 2. because their estimate is always wrong, 3. they are being held accountable for an estimate that was incorrect, or 4. they feel that it's not their job to estimate the duration of their work?

Most people here assume that the issue is #4.

However, it's not like they teach estimating skills in school. And the abilities of people vary so much that you'd think estimating would be impossible.

But let's go back to the old apprentice/master model for a minute. How much time would it take a master builder to build, say, a classic roll-top desk with a bunch of little drawers out of oak? I think if you surveyed 10 furniture makers their estimates would be within a few days of each other. Then you'd ask them how long would it take for an apprentice to do the same? And I'm sure their answer would balloon tremendously.

What's the point of that exercise? Experience matters. When you've done lots of things, and you've paid attention, it's easier to estimate how long it takes to complete things - even if you've never done those things in your life. How long does it take to build an OS? With the right team, it should take about 4 years to build version .9. How long does it take to build a telemetry back-end that scales to a few million clients? Maybe 3 weeks to a month. For someone new who's never touched any of the technologies before? Maybe 4-6 months at a minimum, and that's assuming they're good at integrating things together.

So let's get to #1. If you don't know how to estimate, well, you estimate by first trying to figure out the amount of work it takes, then looking at how long it took you to do something of the same complexity/work, then adding some extra time because it's new. You can use your bug tracking system to figure out how long it takes you to fix a bug.

What about #2? Well, if your estimate is always wrong you need to find that delta and exploit it. If it took 2 weeks and you said it would take a week, well, try and figure out why. Were you waiting on other teams? Ran into some problem? Couldn't get resources? Or it was harder than you thought? You ran into some unexpected weirdness? Next time, double your estimate.

There's a PM rule of thumb that says take your developer estimate, double it, then move it to the next time unit. It actually sort of works when you move it up to the next level ie: include testing/QA, documentation, training, deployment.

#3. Are you really going to get fired because you gave a bad time estimate? Then you either need to get better at it or leave. The fact is, anything of any complexity is going to require more people to do, and more people = more time = worse estimates. But it's really up to you to keep people up to date. If you estimate 3 months and you're not even close after a month, well, maybe it's time to tell people and reset expectations. But what the heck are you doing that requires 3 months of work?

1. Redis can handle a lot more connections, more quickly, than a database can. 2. It's still faster than a database, especially a database that's busy.

#2 is an interesting point. When you benchmark, the normal process is to just set up a database then run a shitload of queries against it. I don't think a lot of people put actual production load on the database then run the same set of queries against it...usually because you don't have a production load in the prototyping phase.

However, load does make a difference. It made more of a difference in the HDD era, but it still makes a difference today.

I mean, redis is a cache, and you do need to ensure that stuff works if your purge redis (ie: be sure the rebuild process works), etc, etc.

But just because it's old doesn't mean it's bad. OS/390 and AS/400 boxes are still out there doing their jobs.

Well before nobody actually dealt with PDFs directly; they exported it out of FrameMaker or whatever tool they used to compose stuff (ie: print-to-pdf).

Acrobat has always been a really bad PDF editor. I'm not sure why that is, exactly, since their other editing tools were basically industry standard for a long time. All the interactive stuff like fillable forms, etc are probably incredibly hard to build.

Back in the day there were at least two programs competing for the role that PDF fills today that I remember: diskpaper and PDF. Apple also had one for its developer docs, but it was never released commercially, I believe.

PDF provided more fidelity for printing, had better tooling (it was by Adobe after all), it was cross-platform, could be displayed on the desktop, so it won. The reader was cross-platform so end-users didn't have to mess with installing plugins for various image types. And because everyone in the document creation division(1) used Postscript to print, printing to PDF was super-easy. And at some point everyone had a postscript printer driver on their machine, so printing to PDF because super-easy as well.

It's not an archiving tool, but people use it for archiving...just like the way a spreadsheet isn't a project management tool, but millions of people use it for project management.

At this point the network effects for the PDF file format would make it difficult to replace. With PDF you can practically guarantee(2) that the file will look the same on any device.

(1) This was more true back then than today, probably (2) assuming that you embedded the fonts, and that the reader doesn't suck.

What's funny is I don't think Adobe really makes any money off of PDF; it's an accidental de-facto standard.

PosgreSQL has its share of annoyances, like case preserving case insensitivity and inconsistent naming of its tools/config files.

Nothing like trying to do a select on a table/column that you know is there and getting an error...becuase the table/column was created with quotes by your ORM so it doesn't automagically get case in-sensitized.

It's maddening.

You mean postgres | postgreSQL | pg | pgsql?

"I realized that the trouble with bong makers is that they’re also bong users." - classic!

If you're a cloud denier it's better to have tried and failed ("it didn't work because it costs too much") than to have never tried at all ("The cloud...it sucks.")

Maybe the problem is that staff wants to learn cloud because they don't want to be left behind in the job market. So everyone pushes for cloud, even though it really won't be a benefit to the business itself.

I mean, what kind of CTO would you be if you didn't have a cloud project going on? Who would hire you if you got booted?

Well, HIPAA can be self-certified, but that probably won't stand up in court so most organizations will pay a third-party provider to perform the certification for them. That also lets you see the gaps, because HIPAA is big.

Here's AWS's list of HIPAA-eligible services. HIPAA-eligible is technology provider specific:

https://aws.amazon.com/compliance/hipaa-eligible-services-re...

Here's google's:

https://cloud.google.com/security/compliance/hipaa-complianc...

In general it means that the service may not be HIPAA compliant by default, but can be configured to be HIPAA compliant.

HITRUST is something else and it outside the scope of this discussion IMO. Not sure why you brought that up.

"I trust a scribe because they are a person with years of specialised training and experience who can be held accountable."

They can be held accountable, but it's unclear how much specialized training or experience they actually have. They could have had a 6-month course, an online course, etc.

And of course you're assuming their EMR is actually secure. In a small office you can usually find the passwords you need stuck to the monitor or under the keyboard.

Oh, one smaller but useful book:

Design is a job, by Mike Monteiro

Even though it's targeted towards designers, it's actually about businesses that happen to be small design shops. The same principles apply: value your work, don't do work for free, dealing with clients, contacts, etc.

Traction, by Weinberg.

It goes over the various sales channels. How you get customers should really be the #1 priority for your startup.

Building stuff is easy. Getting customers is hard. And "if you build it they will come" doesn't really work most of the time IRL.

Most people at this level don't really care about specs like higher refresh rates. They care about cost and functionality.

Hundreds of millions change their phones every year, which is why there's supply for the used market.

Billions of people don't change their phones every year, because they can't afford to or don't care to.

If you think this is scary you should see how it's done today without AI.

Doctor's handwriting is notoriously bad. Now try putting that into an EMR. Good luck with that! You think you're going to get someone who gets paid $2000/hr to type shit up? Yeah, guess again.

What that really means is:

* they may be HIPAA-compliant (ie: they fulfill the requirements), * they haven't gone through a HIPAA-certification (no third-party cert), * they aren't using services that aren't HIPAA-certifiable

The latter point is important, because there are some services (ie: firebase) that apparently won't be HIPAA compliant. Some services are HIPAA-compliant if configured correctly. AWS has a list. I believe google does too.

There are a bunch of HIPAA guides out there.

So as a demo, it's not a big deal. But if they start selling this they need at least to be HIPAA-compliant with certification on the roadmap.