adameasterling

Everyone being surprised at the bridge collapsing needs to reconcile with the amount of force that struck the bridge ... I am also a bit surprised at how many people don't grasp this or grasp engineering, magnitude of forces and design principles.

A spokesman for CalTrans claimed today that Bay Bridge could have taken the same hit without damage, thanks to fenders that protects all pylons for all bridges in the San Francisco Bay Area (1). Cargo ships are heavy, yes, but it appears we have the technology to prevent bridge collapses due to these sorts of collisions today.

1. "The Bay Bridge’s fenders insulated the span during the 2007 incident, so that the Cosco Busan ship struck a bumper, never hitting the bridge itself, Ney said. He noted that fenders on Bay Area bridges should be able to handle a ship traveling at 8 knots, the velocity at which the ship hit the Francis Scott Key span."

https://www.sfchronicle.com/bayarea/article/baltimore-bridge...

I've found very few projects where a bit of poking can't turn up memory safety issues.

I'm working on a Rust project right now, and I'm probably one of those people who are overestimating the correctness of my code! I would love to know about what sorts of memory safety issues you often uncover.

Err, I just enumerated many regulations I have a problem with in the very post you quoted, and evidence is pretty strong that it's the combined effect of all of those regulations that results in higher costs. [1] I realized I left off overuse of exclusively single-family zoning, which is the worst offender. [2]

I'm not sure we need more high-end development - those tenants have plenty of options.

Evidence is strong that market-rate construction causes richer residents to exchange their current unit for a higher-end unit, opening up supply at the lower end. [3]

The problem with BMR requirements is the increased costs borne by developers, who have to offset those increased costs by charging more for the market rate units. There's a limit to that market, so fewer units are constructed than otherwise would be. Middle class families are especially worse off, as they neither qualify for BMR lotteries, nor earn enough for the rapidly accelerating market-rate unit. [4]

Further, rents are lower in states that disallow BMR mandates (like Texas) than those that have BMR mandates (like California).

1. https://www.axios.com/2019/08/28/study-californias-land-use-... 2. https://www.cnn.com/2023/08/05/business/single-family-zoning... 3. https://www.lewis.ucla.edu/research/market-rate-development-... 4. https://escholarship.org/content/qt036599mr/qt036599mr_noSpl...

You are free to choose buildings with multiple stairways if that's a requirement for you! We're talking about easing mandatory regulations, allowing builders to meet demand. We're not saying that all buildings must only have one stairway.

This is a fantastic article.

Burdensome regulations on housing construction have caused costs to skyrocket. Minimum lot sizes, setback requirements, square footage minimums, floor-area ratio restrictions, overzealous height restrictions, parking requirements, abuse of environmental reviews, historic designations, community reviews, overzealous MFH requirements (like double-stair), below-market mandates, all have worked together to constrain supply, leading to skyrocketing costs.

It's the single most important economic issue for me. We need a nationwide effort to ease these restrictions, or we're just going to continue to see rents eat up more and more of young people's earnings.

Oh, I see the issue. The HIBP database is SHA-1 hashed with no salt. It was created from unhashed passwords. You can't download the unhashed version (you could of course compute it, if you really wanted to; but there's no need).

So, the procedure you need to implement is, on login/registration/pw reset, you SHA-1 hash the user's unhashed password and do a indexed lookup on your copy of HIBP's database. Or if you don't want to maintain that copy, you can use HIBP's API to do something similar.

One can only implement a HIBP check when one has access to the user's unhashed password. So, at login, registration, and password reset.

Yes, same scenario, but far fewer logins are successful. 3 orders of magnitude sounds right, but I don't know precise numbers. (Can others shed light?) Three orders of magnitude is a lot!

This is true. The story as written probably didn't happen with HIBP's database. Troy Hunt's database only includes SHA-1 hashes, and passwords in your own database will be hashed with a stronger algorithm (hopefully) and salted (hopefully), so you can't do a simple hash-to-hash comparison. The way to do a HIBP check is, when a user signs in, you hash their password in the way HIBP expects, and check that against either their API or against a local copy of HIBP's database, and if a hit is returned, you give them a nice message and direct them to the password reset flow. There's no easy way to use HIBP's data to identify users with compromised passwords until users actually try to log in.

The FBI feeds data into Troy Hunt's database and FBI Director Christopher Wray gave Troy Hunt a medal for his work [1].

The Open Web Application Security Project's Application Security Verification Standard recommends that you do a hashed password check [2].

For bigger companies, sure, go talk to legal, but for young startups, my feeling is it's not worth the $200 or whatever your counsel will charge to say it's ok. I personally did not ask anyone (am cto), I just added the check.

1. https://twitter.com/troyhunt/status/1674132801837477888

2. See OWASP ASVS 4.0 2.1.7 https://github.com/OWASP/ASVS/blob/master/4.0/en/0x11-V2-Aut...

Troy Hunt is such a treasure. And for us web application developers, there is no excuse for not having protection against credential stuffing! While the best defense is likely two-factor [1], checking against Hunt's hashed password database is also very good and requires no extra work for users!

I don't have anything to back this up, but my guess is that the vast majority of compromised user accounts comes from credential stuffing/password re-use. It's really surprising to me when I hear that huge companies don't do this check.[2] It's simple, easy, takes about a day to set up.

If you're a young CTO or early-stage engineer working on a web app and have never been targeted with a credential stuffing attack, let me tell you: It's coming! It's just a matter of time before it's 1AM and your phone blows up; your site is getting hammered; you think it's DDOS, but then realize most of the hits are on your login page, then realize that and then realize with a horrible feeling that some % of those hits are getting through the login page. You'll be up all night dealing with it, and then you have to make breach notifications, and that really sucks.

Troy Hunt's free database will save you that heartache (probably). Just do it.

1. https://cheatsheetseries.owasp.org/cheatsheets/Credential_St...

2. Like 23andMe. https://news.ycombinator.com/item?id=37794379

It's not on 23andMe, or anyone (other than the user) for that matter, to ensure the passwords used by the user are not copied passwords from other credentials.

In my opinion, it is, actually, on 23andMe. At my tiny startup, I implemented a simple check against Troy Hunt’s compromised password database.[1] If I can do it, 23andMe can.

If anyone reading this is in the business of making web apps and there’s literally anything of value behind your login, prioritize this mitigation. OWASP recommends it too. [2]

1. https://haveibeenpwned.com/Passwords

2. https://cheatsheetseries.owasp.org/cheatsheets/Credential_St...

It is not hard and every web service really should implement this sort of check. I’m actually pretty surprised to see so many comments here that aren’t aware of it!

See: https://haveibeenpwned.com/Passwords

I don’t know about criminal liability, but they’re certainly at fault for not implementing a check against known compromised passwords[1]. I believe it’s been an accepted best practice since something like 2017.

1. https://haveibeenpwned.com/Passwords

Websites should mitigate credential stuffing by checking against known cracked passwords. All you have to do is download Troy Hunt’s hashed password database, check it when someone logs in and if it’s cracked do your email password reset flow. Or you can use their API.

It’s very simple, and I believe has been an accepted best practice since like 2017. This is 100% on 23andme. They are responsible.

1. https://haveibeenpwned.com/Passwords

I had to deal with this problem in our product, which has a visual programming language. I opted to throw an exception if, for whatever reason, "all()" receives an empty list! I had forgotten I'd done that. There's no explanation for it in the code.

As I sit here justifying my own reasoning, though, it sort of makes sense. For ordinary people (for whom this product is supposed to be for), I figure if they put in nothing, that was probably just a mistake.

A few months ago, I did some analysis on JSON data in our platform, and discovered that more than two-thirds of bytes were field names. Two thirds! That’s a lot of potentially unnecessary extra bytes.

In my case, I was thinking about storage costs for JSON data; but thinking about this use case: Isn’t it true that the CPU would have to spend basically three times as much time making FFI calls? Assuming that practically speaking, field names make up 2/3rds of the bytes in their real-world JSON data.

Alpine is a trap! For a Python product, we tried to make it work for about a year before throwing our hands up and switching to a plain Ubuntu image. We’ve had no regrets.

Perspective from a CTO at a small b2b saas startup:

Pricing is incredibly tough, and at my startup, we’ve had tons of hours-long conversations on pricing internally, with consultants, etc.

We also have a mix of customers, both very large companies with thousands of employees and very small ones as well. My answer is a little complicated because we have two products right now, with very different approaches to pricing.

For our first product, it worked really well to charge by the number of physical locations at the business. (We tried usage-based pricing, but it was too confusing for what that product was; and also incentivized less engagement.) The price per location is fairly high, but we do tend to discount down for larger deals.

For our second product, pricing has been very tough. For very large customers, we’ve carved out special deals, where they get billed a flat monthly negotiated amount for unlimited service. These have been a little annoying to set up, but pretty profitable for us. For all other customers, we charge by usage.

Also, I see some people saying bringing on an enterprise client is a way to kill your startup. I’m skeptical of this. Large businesses, in my experience, are very pleasant to work with, have a lot of money to spend, and, yes, are demanding, but in ways that make your product better, not worse. It’s true that you’re going to have more fire drills for your engineering staff (last-minute demands to add an important feature), but this isn’t a bad thing. Security questionnaires are probably the most annoying thing to deal with, but it’s solvable (talk to Vanta).

Feel free to hit me on Discord or send me an email; happy to say more.

I had trouble finding the link to the full report; here it is!

https://survey.stackoverflow.co/2023/

I haven't heard of the idea of the "hard problem of consciousness" before, but after reading this Wikipedia article, it sounds like nonsense. Like, take this passage:

For example, it is logically possible for a perfect replica of [David] Chalmers to have no experience at all, or for it to have a different set of experiences (such as an inverted visible spectrum, so that the blue-yellow red-green axes of its visual field are flipped).

A perfect replica? So you somehow make an exact copy of a person and his environment, down the last gluon, and play time forward, and you'd think that the two people might have different experiences?

No way. In every other situation, if you set up a system in the exact same way, you'll get the same outcome. (Yes, randomness can come into play, but the distribution of outcomes will be the same.)

I agree with this:

The philosopher Thomas Metzinger likens the hard problem of consciousness to vitalism, a formerly widespread view in biology which was not so much solved as abandoned. Brian Jonathan Garrett has also argued that the hard problem suffers from flaws analogous to those of vitalism.[1]

1. https://en.wikipedia.org/wiki/Vitalism

I had a really fascinating conversation with the lead architect at Frost Giant the other day. They're making the next StarCraft, basically.

They don't use floating points.

He didn't mention (IIRC) the possibility of rounding bugs; the reason he cited was something a bit more interesting: Floating points are not deterministic, which makes multiplayer challenging, as they simulate game state on each client's computers and only send commands across the wire.

One wonders if the "out of sync" errors that plagued Age of Empires in my youth were partially explained by FP determinism issues!

"At one point in the harrowing footage, he appears to be stumbling toward a car, and then falling to the ground as the car drives away."

This was so sad to read. I bet the driver thought Lee was a dangerous or disturbed person, and he ran away.

I see a lot of other comments saying that our fear just comes from the media, but I don't think that's the case. I say that as a San Franciscan for two years now. I think it comes from personal experience. These are mine, in the last two years:

1. I witnessed the end of an extremely violent street mugging. The victim was left sobbing in a pool of blood from a head wound.

2. I was shoved by a disturbed person while I was recovering from knee surgery and learning to walk outside again with a knee brace. I was not hurt, thankfully, but easily could have been.

3. My building was broken into by a street person. He defecated in the hallway. Police had to convince him to leave. He was not charged. (Also, I drew the short straw for the cleanup. Not fun!)

4. I've also seen many disturbed individuals in states of extreme distress. Some of these people have left lasting images in my mind. A lady in a wheelchair who sleeps outside, screaming at the top of her lungs at some attacker. An extremely young female wandering dazed, out her mind, who apparently hadn’t noticed the feces that collected in her pant leg. Lots of unconscious people (likely due to fentanyl) in what should be super painful positions. There’s so much pain, just, on the streets outside my apartment...

5. There are also large encampments nearby with what appear to be dozens of possibly stolen bicycles. Once, a person in this encampment shouted at me angrily. (I ran away.) Just a couple blocks away, a tent caught fire, and it spread to the nearby apartment. No one was hurt, thankfully.

When you encounter these situations on a regular basis (and when your friends report similar personal experiences--again, not news media!), your reaction to someone strange approaching you is to run away. You become conditioned to anticipate negative interactions, or violence, and as an act of self-preservation, you avoid/run.

I've often wondered what would happen to me if I had a heart attack, on the streets nearby. Would someone think I've just had a nap from the drugs I’ve just used?

Don't get me wrong, these are just the bad parts of living in the city; and there's SO MUCH good. Outdoor and indoor activities, club sports, transit and walkability, shops and restaurants, and I've made so many friends. For me, the good very much outweighs the bad. I just wish there was less bad. :)

I recently discovered Bevy, and it's so much fun to play with.

I wouldn't be surprised if in 2-4 years, we see some fantastic, revolutionary indie game coded in Bevy that totally breaks the mold in some way. The next Minecraft, basically.

I say that because Unreal sucks for developers who like to code in text, want a fresh blank canvas, and don't want someone else making all the decisions about how gameplay should be created: Basically, the exact same type of person who's likely to make something really cool.

And Bevy's coded in Rust! Bevy gains all of Rust's safety, ergonomics, speed; yet it avoids pitfalls with some OSS Rust products: it doesn't overuse lifetimes or macros and is relatively easy to follow.

Plus, my understanding is that Bevy is way better at multithreading than Unreal and Unity; and consumer core counts just keep going up.

IMO, there's a big opportunity for someone(s) with resources to invest in Bevy's development somehow.

"Housing prices only keep pace with inflation. America realizes it totally forgot about a few million homes it built, greatly expanding supply. Housing prices rise only 2%. Alice is much, much worse off for buying. In total, buying costs ~$1.75M, where renting would have cost her ~$1.3M."

Err.

What?

In this scenario, Alice lives in a world where a homeowner is allowed to subdivide their lot and sell homes worth about the same to N more people. Sure, one "home" costs the same, but she'll be allowed to fit a lot more homes onto her lot. She comes out way ahead in this world.

I've been slowly reading this book on cognition and neuroscience, "A Thousand Brains: A New Theory of Intelligence" by Jeff Hawkins.

The answer is: Yes, yes we are basically fancy auto-complete machines.

Basically, our brains are composed of lots and lots of columns of neurons that are very good at predicting the next thing based on certain inputs.

What's really interesting is what happens when the next thing is NOT what you expect. I'm putting this in a very simplistic way (because I don't understand it myself), but, basically: Your brain goes crazy when you...

- Think you're drinking coffee but suddenly taste orange juice

- Move your hand across a coffee cup and suddenly feel fur

- Anticipate your partner's smile but see a frown

These differences between what we predict will happen and what actually happens cause a ton of activity in our brains. We'll notice it, and act on it, and try to get our brain back on the path of smooth sailing, where our predictions match reality again.

The last part of the book talks about implications for AI which I haven't got to yet.

I don't know! I think you might be right, but my intuition tells me it's a little more than that. Other ideas:

* Is it a mind-body connection thing? Writing seems to involve a lot more fine motor control and muscle engagement than typing.

* Like other people my age, I didn't grow up typing; I started learning when I was around 10 years old. I learned to write much earlier than that. Could it be that neural connections tied to writing are somehow more effectively hooked up to learning new things?

* Is it a hand dominance thing? I write with one hand, but type with both.

* Is it that writing engages a different kind of language processing than typing? To me, the "voice" I use typing feels very similar to how I speak. Whereas when I'm physically writing, the "voice" I use feels very different. It's as if there's a different language center being worked.

I 100% agree with this. If I want to fully commit to learning something, physically writing it down with my hand makes it stick better, for reasons that I don't really understand.

I actually started to think about it as a kind of cheat code. Like, how, in a video game you can type in a cheat code and you get special powers. That's how big of a difference it made for me.

My strategy looks like this:

* If there's a good book, buy the book. Like when I wanted to learn C, I picked up K&R's C. A physical copy isn't required and can even get in the way, but can be useful if the Kindle version looks bad. If there isn't a good book, open up the official documentation on a web browser. Third-party tutorials tend to suck, IMO; official documentation is much better.

* Sit down at a desk with my laptop, book, and my notebook. Start at the beginning of the book/documentation. Read every line. If there's a word that doesn't make sense, look up the word. Talk to myself, out loud: Summarize and re-phrase what I'm reading.

* Write down a summary of the large important details of what I'm reading, in snippets of prose, on paper with a pen. It's important to not use the same words that the author(s) used. And of course, be much pithier than the author. As Kevin from the office taught us, why use lot word when small word do trick?

* The act of summarizing and re-phrasing, first verbally and then manually, seems to really do the trick in terms of making my brain remember things.

* If there's anything that can be tested with code, test it. If you're learning C or Lua or whatever, you obviously want to set up a little environment and test everything you're reading. This is harder for something like system design, though.

* Repeat every day until the book or documentation is consumed, or I feel I've had enough to accomplish whatever goals I had. Repetition every day seems to be important.

* Talk to other people about what I'm learning. One time I even reached out to the author of the book: I thought I found a mistake in his book; I was wrong! But talking with co-workers, or even salespeople if learning something like Snowflake can be helpful, or my partner. Anyone who will listen.

I will admit to not using the notebook strategy in recent years. I'll use a Google doc or sheet instead. But I think the notebook strategy is better! Especially when I was starting out, and the concepts of programming were new and strange.

This copy is confusing. What's the actual product that I could potentially buy? From the description here, this could be "just" AWS Lambda. I'm sure it's better in some way, but, like, how exactly?

Huh. I had this long call with our AWS Account Reps (+ Support Engineers) the other day and no one mentioned App Runner! This is the first I've heard of it. Looking at it now.

Ah I see, launched originally in May 2021. That's probably why they weren't aware of it. Yes, this looks cool. Very much what I was looking for.

The differences that I can see are...

* AWS App Runner lacks an advertised free tier. Not a big deal for all but the smallest projects though.

* AWS App Runner bills rounded up to the next second, whereas GCP Cloud Run rounds up to the next 100 millisecond.

* AWS App Runner doesn't charge per request (?!), whereas GCP Cloud Run charges $0.40/1M requests.

* AWS App Runner has fewer CPU/RAM configuration options. The lack of low end options may be a blocker for us.

* It's cheaper than GCP Cloud Run - $51.83 @ vCPU/1GiB, but 2GiB minimum, in Runner vs $69.642 @ 1 vCPU/1GiB (v1) $97.50 @ 1 vCPU/1GiB (v2) in Cloud Run.

* I'm confused by the networking model. In App Runner, you have to make an ENI for your App Runner service to access your VPC? Weird. There's some extra cost there I think.

Things that I can't determine based on the documentation...

* Does App Runner support committed use discounts?

* Does App Runner throw a SIGTERM before shutting the container down? I hope yes but I can't find docs on it.

* Is there a file system accessible on App Runner and is it just in memory or is there actually a disk to write to?

* The quotas & limits page on App Runner feels incomplete and I'm left with a lot of questions about it.

* Is there an SLA?

* In fact the documentation for App Runner just feels a little incomplete.

It looks like AWS definitely wants App Runner to be the answer to Cloud Run, but to me, it feels like it's not quite there yet.

It's also weird, that ECS Fargate lets you run a container without thinking about the server that it runs on, and App Runner does too, just with a few extra things. Why is it a whole separate service? Why didn't they just add it onto Fargate?

Re: Other services. I've only heard of API Gateway, DynamoDB and Lambda@Edge; I'll have to spend time investigating the other ones. Thank you for mentioning them!