Hacker News new | past | comments | ask | show | jobs | submit | netheril96's comments login

I don't count that Xi losing, but Xi winning. He's very conservative in China's sense, and he's basically crushed less conservative forces in the Party. A crackdown on clothing "detrimental to the spirit of the Chinese people." doesn't serve any real interests of Xi other than enforcing the ideals of China's conservatives.

Similar to how the Republican party always try to inhibit abortion wherever they can. You won't say that Republican party successfully passing an anti-abortion law indicates they are losing, will you?


> Because Shopify would have waited until Rust came out in 2015, instead of launching in 2006,

> PHP and Ruby apps have generated far more revenues than all the Rust and Golang code combined.

You already stated the obvious: PHP and Ruby apps generated far more revenues simply by existing longer.


I also question the revenue claim.

Google has a lot of revenue. Pinterest, Hashicorp, Uber, Twitch, Dropbox, etc. all have a good amount of golang and collectively have a lot of revenue. It might need a few more years to tip the scale, but it's closer than suggested here.


Twitch was initially built with Ruby on Rails as well.


YouTube was initially built with php, so the revenue argument is true.


Was it? What I was told was that Youtube was built in Python and was gradually migrated to C++ after bought by Google.


and Dropbox with Python


ETH uses 256-bit integers for accounting.


Nullable annotations don’t work with well with generics, or at least those tools I use.


What's the practical difference between system store and user store? Do some apps or system operations only trust the system store and not the user store?

Not rhetorical questions.


The user store is a certificate store that the user can add certificates to. It used to be the case that by default apps would get certificates from both stores if they asked the system for certificate authorities to validate against, with the option to opt out of specific stores, but this changed years ago. Now apps need to opt into loading user configured certificate authorities.

The system store, located in /system/etc/cacerts, is baked into the system image and can't be altered without root. The user store, located under /data, can be updated from the phone's settings.

The system store is now the default store all apps use to validate certificates, unless they pack their own certificate authorities. Many apps doing certificate pinning will do that as well, which prevents them from being MitM'd without injecting code into them.


I don't know the difference between the user and system store, but I do know that apps can choose not to trust certs installed by the user and instead only trust their own that they bring with them. Was frustrated to find this when I was trying to MITM an app to see what it was up to on the wire.


Apps used to trust the user store by default, but that changed back in Android 7. Now they only trust the system store by default and need to opt into also loading the user store. So, it's not that they look at the stores and pick one, it's that the user store has effectively been disabled for most apps (browsers usually work, thankfully). Even Firefox for Android will only use the user store if you go through a five step process to open the hidden settings.

Some apps do certificate pinning, which basically only validates certificates against a specific certificate authority and completely defeats any system certificate store.

You can MitM these apps by injecting code to bypass their restrictions. The eBPF methid linked above works, or you can use Frida in root or rootless mode to inject a variety of existing scripts to defeat certificate validation. This is a lot more involved than installing a certificate authority, but it'll work if you want to reverse an app.


The materials found during discovery are not always relevant. You can discover all of them, but then some of them shouldn't be presented to the court or jury.


Not really. If someone logins as user A on the machine, and caddy runs as user B, then unless A has sudo access, A cannot modify caddy. But with this admin HTTP endpoint, user A now can arbitrarily modify caddy.


This does kind of beg the question, who is sharing their load balancer / reverse proxy?


That's true, but I think if your production web server is running on a system that you expect to have other users log into and do things on while having the Unix permissions prevent them from interfering with the production server, then your whole architecture and process is deeply broken far beyond the ability of any Caddy design decisions to address.


That's another really good point, even if it's less common these days to see this type of shared machine.


> what makes you think India and China can?

They don't have to do anything. The US visa system already excludes most of the Chinese and India people eager to immigrate to the US. The brain drain is bounded above by the US policy.


There are also exchanges where you trade against other people between crypocurrencies and fiat. Chinese people all use this. These workers could use those.


They are like fiat-crypto dexes. How's your experiences with these?


It will be years when most Android users are on Java 21. It’s also not a feature that can be transpiled. So for Android developers virtual threads are probably not a thing we need to understand or use in any near future.


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

Search: