Hacker Newsnew | past | comments | ask | show | jobs | submit | FooBarBizBazz's commentslogin

When I have been in NYC recently, it's seemed remarkably quiet to me. In particular, I don't see many cars.

(Only the subway is loud. But that doesn't stress me out, because I don't have to do anything. You get on, you let your mind wander, you get off, you take a little walk.)

When I was a child, I saw movies set in New York, and the streets were always choked with traffic. The sound of a car horn was almost a shorthand for the city. You'd hear it in music. They'd use it in establishing shots in films. Always yellow cabs.

Even a decade or two ago, you'd stand, as a pedestrian, at the crosswalk, waiting for the light to change.

Now, often you look both ways and the street is clear for a whole block. You don't wait, you just cross.

Sure, there's a rhythm to it. Even decades ago, the Financial District, choked during rush hour, was spookily-empty on the weekends. So maybe I have more recently walked around in the places and times that are at the troughs of that rhythm.

But I suspect there is also a longer-term trend, or perhaps a step change, caused by COVID: Cities just seem quieter now.

To an extent it is good. I'm happy to see a city by for and of people, rather than ditto for cars, their manufacturers, and their buyers (who lack alternatives). By all means, let restaurants build decks on the street; decorate them with flower boxes; let people meet there for brunch or after work.

There is also a negative aspect. There is still, I think, a suburban hangover. I see this in friends who it is now difficult to drag out of their apartments and away from their video games; in other people who one might frustratedly describe as "suburban women voters" who, in rare acts of personal courage, mask up and use the subway (they stand out from the people who actually live and work in the city. ... I shouldn't mock them; at least by seeing the reality they will overcome their fears); and in the rhetoric of the political Right, which seems more grounded in Escape from New York than in reality.

So I suppose several forces have made the city quieter. Some positive, some negative. And popular perception lags (as it must; this is the nature of information transmission).


Apparently the surge tolls they implemented recently contributed to less traffic, in Manhattan at least

The loudness of cities is generally a product of cars.

Very busy areas of cities without many cars are fairly quiet.

Tire noise, exhaust noise, horns, etc all make a ton of noise. Living near a highway in the suburbs is probably inherently more noisy than many cities.


I like to think about the time around 1900 when the population was far far higher than today, but there were no cars. Horses don’t make the same noise.

Of course there was heavy industry in that day so that would be loud and filthy.

How quiet was dense NYC in 1830 though?


Pales in comparison to Soviet science ;-):

> the power comes from pistons that are filled with a fuel-air mixture, and fired by compression when the user puts his or her full body weight down into the boot

https://en.wikipedia.org/wiki/Rocket_boots

https://www.cnet.com/tech/tech-industry/these-gas-powered-bo...


Seems to be these ones, and bunch of more videos in the description too: https://www.youtube.com/watch?v=xJvmAXCh6Ak

1. Yes re. first paragraph. There are many examples from the nuclear program.

2. No re. second paragraph(?). How many of the recent high profile "leaks" have been driven by money? Most seemed ideological.

That said, when you read stories of people who did perform espionage for money, the dollar amounts are usually embarrassing. "Just do leetcode, bro."


Leaks aren’t espionage.

I doubt we hear about the real damage.


Wait til you hear about Phi Beta Kappa. Sometimes they even have pizza parties. Probably.

Isn't this solved with salt?

This is how I did it. You generate a salt per logging context and combine with the base into a sha2 hash. The idea is that you ruin the ability to correlate PII across multiple instances in different isolated activities. For example, if John Doe opened a new account and then added a co-owner after the fact, it wouldn't be possible for my team to determine that it was the same person from the perspective of our logs.

This isn't perfect, but there hasn't been a single customer (bank) that pushed back against it yet.

Salting does mostly solve the problem from an information theory standpoint. Correlation analysis is a borderline paranoia thing if you are practicing reasonable hygiene elsewhere.


If it's salted, you can't share it with a third-party and determine who your customers in common are. (That's the point of the salt; to mean that my_hash(X) != your_hash(X)).

You actually can join it when the salt provider is a dedication shared entity. The entity rehashes the data of both organizations to use a shared salt. That is how different organizations join hashed data.

> A 2020 MacBook Air can hash every North American phone number in four hours

If you added a salt, this would still allow you to reverse some particular hashed phone number in about 4 hours, it just wouldn't allow you to do all of them at the same time.


I do not agree. How will you reverse a salt with sufficient entropy? Imagine the salt is a 512 bit hex, the data is a ten decimal digit phone number, the generated hash is 512 bits of which the first 160 bits are used as the value. Now exactly how will you get the phone number back? Do you really think you can iterate over half of the possibilities of 512 bits in four hours?

You know the salt because it's stored alongside the hash. You're only iterating over the space of phone numbers.

If it's not stored alongside the hash it's not a salt, it's something else.

https://en.wikipedia.org/wiki/Salt_(cryptography)


> If it's not stored alongside the hash it's not a salt, it's something else.

That is not even true. The definition in the article does not substantiate it. There is no requirement for the salt to be stored alongside the hash.

The definition in the article is sufficiently clear. This is all that a salt is:

> a salt is random data fed as an additional input to a one-way function that hashes data

With regard to effective anonymization, the salt is stored by the generator, but not in the exported dataset.


If the "salt" is kept secret then I agree you can't brute force all the phone numbers so easily. But I don't agree that "salt" is the correct term for that technique.

A salt is very good if the input varies. If the input stays within a pre-defined range (e.g. phone numbers), salt does not work very well.

I do not agree that it doesn't work very well. How will you reverse a salt with sufficient entropy? Imagine the salt is a 512 bit hex, the data is a nine decimal digit SSN, the generated hash is 512 bits of which the first 160 bits are used as the value. Now exactly how is the salt not good enough?

I don't get it. This guy had bugs in his Pascal code, and he thinks moving to C is going to make his life easier?

I mean, that's one way to see fewer errors: If a tree writes off the end of an array in the forest, is there actually a bug?

(Yes. Yes there's still a bug.)


This isn't new. It goes back thousands of years.


Chinese civil engineers, and engineering orgs, are good because they get a lot of practice.

In the West, and especially in the US, individuals and orgs don't get practice, so when they finally do get a new contract they have to stumble around for 5-10 years figuring out all the institutional knowledge that was lost.

By the time they figure it out, the project is over budget, so it gets canceled, and then it's 20 years until the next half-hearted attempt. Lather rinse repeat.

At root, a lot of this stems from a "managerial" mindset in which people and skills can simply be "reallocated" on a dime. They can't. You can't uproot trees all the time. You plant one and then it grows over multiple human lifetimes.


To say nothing of the NIMBYism. To acquire the land for use, you have to fight some armies of lawyers retained by a population with a lot of disposable income. (Yes, the US for all her problems has the biggest pool of disposable income in the world)


There's no NIMBYism in China, so that's a huge barrier that they don't have to worry about.


I know it would be attacked politically, but I wish in the US we would be more open to hiring foreign firms for these kinds of projects. Could we have high-speed rail if we just asked some French or Japanese company to build it for us? And we should structure contracts with them in a way that keeps the plans from being changed for political reasons. "Sorry state senator, we can't alter the route to pass through that town without re-opening negotiations which might cost billions."


> Could we have high-speed rail if we just asked some French or Japanese company to build it for us?

No. Please see SNCF (French rail company)'s involvement in California's high speed rail project.

https://www.nytimes.com/2022/10/09/us/california-high-speed-...

October 9, 2022

"How California's Bullet Train Went Off the Rails"

The (foreign) company's recommendations [...] were cast aside, said Dan McNamara, a career project manager for SNCF


So I guess we have to not only hire the foreign companies, but also listen to them.


I think the lesson here might be to solve your problems on a more local scale, as the fit of the solution is as important as checking the boxes.

What works in Japan works in Japan because it was a solution built for the problems, politics, and people of Japan. Sometimes there are lessons we can take from projects in other countries, other times it turns out like Cali HSR where the proposed 'foreign' solution might be logical but not politically tenable.


The problem isn't physically building the rail, the problem is the legal framework in which governments operate in. Multiple rounds of environmental impact statements, eminent domain lawsuits, preferred contractor RFP's, zoning, permitting, endless red tape...


I used to do stuff like this (ok, not half as smart), but stopped around 2013 or so, as the distinction between "implementation defined" behavior (ok) and "undefined" behavior (not ok) started to matter and bite.

After thinking through this carefully, though, I do not see UB (except for signed overflow in a corner case):

Step 1, bit shift.

I understand that, until C++20, left shift of a signed int was UB. But this right shift appears to be implementation defined, which is ok if documented in the code.

Step 2: Add.

Then, (x + mask) is defined behavior (a) for positive x, since then mask=0, and (b) for most negative x, since then mask=-1. However, if x is numeric_limits::lowest, then you get signed integer overflow, which is UB.

Step 3, XOR.

Then the final XOR doesn't have UB AFAICT. It wouldn't be UB as of C++20, when signed integers became two's complement officially. It might have been implementation defined before then, which would be almost as good for something that ubiquitous, but I'm not sure.

Ok, so I think this does not involve UB except for an input of numeric_limits_lowest.

Sound about right?

To fix this, perhaps you would need to make that + an unsigned one?

It bothers me how hard you need to think to do this language lawyering. C++ is a system of rules. Computers interpret rules. The language lawyer should be a piece of software. I get it, not everything can be done statically, so, fine, do it dynamically? UBSan comes closest in practice, but doesn't detect everything. I understand formally modeled versions of C and C++ have been developed commercially, but these are not open source so they effectively do not exist. It's a strange situation.

Just the other day I considered writing something branchless and said, "nah", because of uncertainty around UB. How much performance is being left on the table around the world because of similar thinking, driven by the existence of UB?

Maybe I was supposed to write OCaml or Pascal or Rust.


Well, I would say that implementation defined is ok only if you have full control on the full compilation process. If your code aims at universality you should find better tricks.

The UB on the add happens in cases where all incarnations of abs() would fail as well, because there simply isn't a correct return value.


Rust in particular with miri is quite impressive at catching them. You just run your testcases via

    cargo miri run
And if your code actually touches UB, mirei will most likely point out exactly where and why.


Amtrak would benefit from a coach-class sleeper, like they have in India or in Eastern Europe. They just need coach benches that convert to beds. If, for a reasonable price, you could lie flat at night behind a little curtain, like you can in e.g. Indian Railways 2nd Class, it would change the game completely. Without that, you can only travel comfortably during the day, and trips are limited to about eight hours for the non-masochist. With it, cross country would be fine. It doesn't seem that hard. Lots of other railways do it.


Amtrak coach seats don't lay flat, but they are not far off. Most people find them plenty comfortable.


Oh, don't get me wrong, during the day it's the most comfortable way to travel. But the ability to lie flat, even in fare classes that aren't too fancy, like they have in India, counts for a lot when you're traveling overnight.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: