adameasterling
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'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.
> 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...
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.
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.
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...
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
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’s very simple. It’s been a thing since like 2017. This is 100% on 23andme. They are responsible.
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.
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.
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.
> 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]
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!
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. An unconscious man whose pants had slipped off his rear end. 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 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, like 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.
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.
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.
* 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 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.
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!