HN user

nicknow

67 karma
Posts0
Comments23
View on HN
No posts found.

Why do we treat boy-girl and girl-boy as different outcomes since they are, per the question, equal outcomes thus representing one possible outcome.

We don't care about which came first or second, only what gender each child is.

Thus the answer, to the question given the information you have, is 50%. The only possible outcomes are girl-girl or girl-boy (where order is irrelevant.)

And this is absolutely NOT the Monty Hall Problem. I don't know why some people are making that reference. The Monty Hall Problem contains three possible choices and one is eliminated by the host, this is what makes the statistical math interesting in that problem. None of that is happening here.

Lets look a the exact wording of the question:

a family has two children. You're told that at least one of them is a girl. What's the probability both are girls?

We have a family with two children. Assume we don't know their gender. We'll represent them as XX.

We are told one of them is a female. So now they are represented as GX (remember GX = XG, since order doesn't matter.)

You are left with the question what is the probability that X is female? Well there are only two choices, F and M, and we are told elsewhere that the probability of having a girl is 50/50.

Assume that the probability of having a girl or boy is 50% and that the birth order has no effect on the probability.

So the chance of X being female is 50%. Thus the answer is 50%.

You can't say birth order doesn't matter and then use birth order to say the FM and MF are different results. The only possible results are FM and FF (since birth order is irrelevant.)

Completely agree.

What will happen is over time this will become the new baseline for developing software.

It will mean we can deliver software faster. Maybe more so than other advances, but it won't fundamentally change the fact that software takes real effort and that effort will not go away, since that effort is much more than just coding this or that function.

I could create a huge list of things that have made developing and deploying quality software easier: linters, static type checkers, code formatters, hot reload, intelligent code completion, distributed version control (i.e., Git), unit testing frameworks, inference schema tools, code from schema, etc. I'm sure others can add dozens of items to that list. And yet there seems to be an unending amount of software to be built, limited only by the people available to build it and an organizations funding to hire those people.

In my personal work, I've found AI-assisted development to make me faster (not sure I have a good estimate for how much faster.) What I've also found is that it makes it much easier to tackle novel problems within an existing solution base. And I believe this is likely to be a big part of the dev productivity gain.

Just an example, lets say we want to use the strangler pattern as part of our modernization approach for a legacy enterprise app that has seen better days. Unless you have some senior devs who are both experienced with that pattern AND experienced with your code base, it can take a lot of trial and error to figure out how to make it work. (As you said, most of our work isn't actually typing code.)

This is where an AI/LLM tool can go to work on understanding the code base and understanding the pattern to create a reference implementation approach and tests. That can save a team of devs many weeks of trial & error (and stress) not to mention guidance on where they will run into roadblocks deep into the code base.

And, in my opinion, this is where a huge portion of the AI-assisted dev savings will come from - not so much writing the code (although that's helpful) but helping devs get to the details of a solution much faster.

It's that googling has always gotten us to generic references and AI gets us those references fit for our solution.

Isn't this what Anker has largely done. In a world of might be good/might be crap cables, chargers, batteries, etc. You can always select the Anker variety on Amazon. It'll cost you a bit more than whatever random product, but you know they are reliable. It's priced much cheaper than an OEM (Apple, Google, Samsung, etc.) accessory but is more reliable (quality wise) than no-name accessories.

We need to be careful here. Because we still want people to sell off potentially productive land. Lets say I buy two lots along a highway with growing traffic because I believe in the next 5-10 years it will be a good spot for a gas station/convenience store.

So now 5 years later the highway is developing and I build out my location. I decide I want to sell the other lot since I'm not going to build on it.

Now, I don't need to sell it. I could hold on to it, it's not that expensive to own. It would be a great spot for a fast food joint or what not. But I don't want to sell it to someone who immediately develops it as a gas station.

The public would benefit from developing the land - new services and more tax revenue. So it's in the public's interest for the owner to sell.

So you want to allow some amount of anti-competitive restrictions. I get not wanting permanent non-removable restriction.

Care Doesn't Scale 2 years ago

Essentially most consumers just didn't care about quality and preferred the lower price over the higher quality product. That seems like normal consumer choice. The people didn't get poorer all of a sudden when the corporate breadmakers came along - the people simply decided they would prefer to get an inferior product at a lower price.

The reality is most people don't want to spend more money for higher quality goods. Or, if they do, it's on a limited set of goods based on personal preference.

Care Doesn't Scale 2 years ago

Yes. And child psychologists will tell you that babies and children crave consistency, variety is not their thing. In fact, one of the reasons we as parents (adults) expose them to variety is so they develop an understanding of how to cope with inconsistencies. And it's always a careful balance, small amount of variety but mostly consistency.

And I can tell you most little kids love hard boiled eggs which I suspect is because they are incredibly consistent in texture and taste, unspoiled by some cook seasoning them or cooking them differently.

There are entire systems engineering courses focused on failure resulting from a series of small problems that eventually in the right succession result in catastrophic failure. And I think we can say this was a catastrophic failure.

Think about it, first you need a race condition, and that race condition has to result in the unexpected result. That right there, assuming this code has been tested and is frequently used, is probably a less than 10% chance (if it was frequently happening someone would have noticed.) Then you need an engineer to decide they need this particular crash dump. Then you need your credential scanning software (which again, presumably usually catches stuff) to not be able to detect this particular credential. Now you need an account compromised to get network access and that user has access to this crash dump and the hacker happens to get to it and grabs it.

But even then, you should be safe because the key is old and is only good to get into consumer email accounts...except you have a bug that accepts the old key AND a bug that didn't reject this signing key for a token accessing corporate email accounts.

This is a really good system engineering lesson. Try all you want eventually enough small things will add up to cause a catastrophic result. The lesson is, to the extent you can, engineer things so when they blow-up the blast radius is limited.

- Not enough log retention in the corp environment to track a 2 year old infiltration.

It didn't say that Microsoft couldn't identify that infiltration had occurred just that they didn't retain the logs to prove to exfiltration. That makes a lot of sense, maintaining access logs is one thing but to retain the detailed logging of every file action by every user on a 100k+ user corporate network long-term would be a massive amount of storage, of fairly limited value.

Even in this case, it might be nice to have but it wouldn't change any of the major findings you care about if you are Microsoft: that a bug allowed a key to be written to a dump file, that the scanning tools didn't detect the key in the dump file, and that the authentication process didn't properly check the keys.

Or they knew/discovered that there was a repository of crash dumps - likely a widely known piece of information - and just grabbed as much as they could. Nothing in the write-up indicates any connection between the compromised engineer and this particular crash dump, other than they had access.

Can you provide some additional details on the VoIP service? When you say "parking it on a VoIP service" do you mean that you ported from T-Mobile to the VoIP service or do you mean you forwarded your calls to a VoIP line and continued to pay for T-Mobile?

Who botched the port request? You would have initiated the port request via US Mobile when you signed up for service. They wouldn't depend on T-Mobile "having the number", they would have looked up who had the number and initiated the porting process.

You can see which carrier "owns" your number by going to https://freecarrierlookup.com/.

Now, if you cancelled your service BEFORE you ported the number, then you may be SOL as the number would have been released. Even if not reassigned you may not be able to get the provider/carrier to release it since it is no longer in your name.

What you would hope is that there is a small monthly fee (say a few bucks) to have the service and then a "usage fee" for the random unlikely time you use the service. So imagine paying $2 a month to have the service on and then $75 each time you use it. Use it once every 3 years (which seems like a lot for the intended user base) and it's only ~$4 a month.

And that seems about right compared to SPOT monthly pricing, considering it's intended for much greater usage than one time every 3 years.

Easy to memorize does not equal weak (i.e., easy to brute force.) You can use natural language to create very difficult to guess or brute force but incredibly easy to remember passwords.

It's SUPPOSED to be a shitty/frustrating/annoying process, not easy. This is your "break glass in case of emergency" solution - you don't want to ever use it and you want it to be super hard for someone else to compromise it.

We have plenty of ways to make this easy but if all those avenues are blocked because of some black swan event, you need a backup - and that backup can't be too easy because then it invites attack.

When I was doing IT ops for a company, we had a little program that generated 4 random common words and put a symbol between them (!.@#$%). Super easy to type and fairly easy to memorize, but according to every password checker also really hard to crack.

"Broth.Dogs.Run.Blue" is 10x easier to remember than "$#kdSk$SWE223" but 1000x times more secure. Probably more so, because you are less likely to have to write it down to remember it.

I would need to recover access to my password manager and my 2FA authentication tool (which is cloud backed up.) My password manager has recovery codes and my 2FA has a recovery process. Those - and, actually my email service's recovery codes (although technically not needed, since I can use the password manager and 2FA but this would speed up my time to access) - are in hard copy and stored in my safe and at a safe at a relative's home several hundred miles away. For additional security, there is a word written on the envelope at the relative's house that the relative knows to require I provide if we are not in-person (to prevent someone faking a call and asks for the information.) The document is also sealed and included with my Will, which is held by my trusted executor.

With that document I can recover access to my complete digital life.

The advantage is nothing changes. New accounts are added to my password manager and 2FA, but nothing needs to change on the recovery process side.

There are some other ideas I have, if I didn't have a trusted relative/friend, who I could give the document to but I haven't felt the need to implement them.

For example, I think they’d still be able to do the pay once model if they abstracted they storage to work with Dropbox/icloud/OneDrive/whatever.

I get why they don't but I often wish more SaaS companies had a bring your own computer & storage model. It doesn't make sense for 95% of customers and the 5% of us who might like it and have the tech chops to use it would just complain about having to pay more because we are outliers. But I wish it was offered!

Very different population sizes and land mass. The US is way more spread out than in the UK (730 per sq mile in the UK vs. 93 per sq mile in the US.)

In the US the Top 100 cities (each will have at least one police department) have just 20% of the population.

You have a police department for almost every state, county, city, and town in America. And, the US has about 3000 counties and 19,000 towns (with about 14,000 being 5,000 or fewer people.)

Yes, because learning Latin - as a written language - will put your vocabulary far ahead of those who don't. My high school had a general elective focused just on learning to use Greek and Latin to enhance your vocabulary, it was essentially a free SAT prep course for the language section.

So many terms can be quickly understood if you understand Latin prefixes and suffixes, and the better you understand Latin the better you'll understand its use in any of the modern Western languages.