michaelmcmillan

It is a long-standing policy at Netflix for employees to pay for their own subscriptions. It ensures that employees "live the member experience".

Linux is written in C, my friend.

Which is useless if the domain had HSTS enabled, which they should.

"modicum of research"

Jesus christ. The reason why that comment gets brought up is because it stereotypes the HN community. He wasn't disrespectful. Calm down.

Exactly.

Please, please, please use Terraform workspaces: One workspace per environment.

For environment specific things use conditionals:

  nodes = terraform.workspace == "prod" ? 2 : 1

My bad. You’re right.

Same here. Use n8n. Self hosted and open source.

Good example of why it’s a good idea to browse the web using a VM.

That's not nearly enough.

Real estate: Buy, repair, rent, refinance, repeat.

Exactly, this is ridiculous...

This section was interesting! Somehow I've never realized that row oriented storage is orthogonal to how disks work...

  Jd is a columnar (column oriented) RDBMS.
  
  Most RDBMS systems are row oriented. Ages ago they fell into the trap of thinking of tables as rows (records). You can see how this happened. The end user wants the record that has a first name, last name, license, make, model, color, and date. So a row was the unit of information and rows were stored sequentially on disk. Row orientation works for small amounts of data. But think about what happens when there are lots of rows and the user wants all rows where the license starts with 123 and the color is blue or black. In a naive system the application has to read every single byte of data from the disk. There are lots of bytes and reading from disk is, by orders of magnitude, the slowest part of the performance equation. To answer this simple question all the data had to be read from disk. This is a performance disaster and that is where decades of adding bandages and kludges started.
  
  Jd is columnar so the data is 'fully inverted'. This means all of the license numbers are stored together and sequentially on disk. The same for all the other columns. Think about the earlier query for license and color. Jd gets the license numbers from disk (a tiny fraction of the database) and generates a boolean mask of rows that match. It then gets the color column from disk (another small fraction of the data) and generates a boolean mask of matches and ANDS that with the other mask. It can now directly read just the rows from just the columns that are required in the result. Only a small fraction of the data is read. In J, columns used in queries are likely already in memory and the query runs at ram speed, not the sad and slow disk speed.
  
  Both scenarios above are simplified, but the point is strong and valid. The end user thinks in records, but the work to get those records is best organized by columns.
  
  Row oriented is slavishly tied to the design ideas of filing cabinets and manila folders. Column oriented embraces computers.
  
  A table column is a mapped file.

Cool! Do you login with one account bouncing off 60 IP addresses?

No. Incrementing an integer might be unique for the local database, but not unique for the universe.

Knowing how to do something doesn’t live outside the brain.

You can erase entire categories of knowledge by damaging the brain in particular areas. There is no reason to believe the opposite is not true.

Therefore it is a matter of modifying the state of the brain to learn or know something.

A rotated user agent does not hide anything from Google.

Finally a PR worthy of Hacktoberfest.

You would risk ending up with a maze that can be solved by walking in a straight line directly to from start to exit.

The onus is on you to explain why. Why not: Smaller payloads per packet and missing out on all the TCP algorithms already implemented in hardware en route.

Never attribute to malice that which is adequately explained by incompetence.

And reimplement TCP on top? Would not recommend.

Most sites redirect all http traffic to https to make sure the traffic is encrypted.

Here's an example with HN (notice the protocol in the req/res):

  $ curl -v http://news.ycombinator.com
  [...]
  < HTTP/1.1 301 Moved Permanently
  < Location: https://news.ycombinator.com/

However, the first request is over http, before it gets redirected and encrypted. This is where the malicious relay node would intercept and change the response.

On MacOS you can also drag-and-drop a file from Finder onto your terminal and it will type out the full path for you.

Binding the database to 0.0.0.0 is not a good idea.

Ironically Azure tweeted a guide on how to protect your DNS against unwanted changes only 3 hours before everything blew up: https://twitter.com/AzureSupport/status/1377697274378260489

You can't make this stuff up.

Backups.

I've built a complex CRM that handles 2.1 million USD in transactions every year. It is running sqlite with a simple in-memory lru cache (just a dict) that gets purged when a mutating query (INSERT, UPDATE or DELETE) is executed. It is very simple and more than fast enough.

Friendly reminder that you shouldn't spend time fine tuning your horizontal autoscaler in k8s before making money.

> If you've typed or pasted a long command and decide you need to edit it before running, ctrl-x-e opens it in an editor

Jeez, this is great!

Authentication != Authorisation.

You wouldn't use this to determine if the user really is who he says he is. But in determining what a user has access to, DNS is pretty slick. The DNS server doesn't need to be public either.