vinay_ys

It takes a lot of effort to build a system that is both user-friendly and does implement sophisticated mechanisms to prevent bypassing permissions controls. Apple has taken the pains to do that well and then to maintain it against an unending barrage of attacks. So they deserve to make money.

A lot of people who eat this produce and don't take any supplements are healthy and doing fine. If the nutrient levels have really fallen so much, then, how come malnutrition isn't an epidemic?

> For example, if you love football, and you're good enough at it, you can get paid a lot to play it.

good enough doesn't get you paid enough to cover your injuries.

Hook up different kinds of alerts/notifications to office intercom and announce outages and pages! Gives the feeling of a real sense of urgency and danger! :-) Sev1 alerts, DDOS attacks etc. You can do this for positive things too – like a e-commerce product launch going out of stock in record time, or hitting a sales target etc.

This is beautiful. Maybe useless, but still a lot of fun to learn.

Surprised to find a bunch of anesthesiologists hanging around here. How come?

> That's not low risk, that's higher risk. Letting the founders continue in Founder Mode can be both lower risk, and higher expected value, at the same time.

It depends on how the founder and their investors perceive risk. If they have the risk appetite to stay in founder mode at scale, even when they have a lot to lose, then they do. But most don't. That's my point. And so, they take the advise to derisk for themselves – they take some money off the table, they hire professional managers and delegate, they take their new found time and money and put it elsewhere.

There's a fundamental point missing in this analysis. That is the difference in skin in the game and upside/downside game theory dynamics for people involved. An early "founder" by definition has a lot of upside and very little downside and have a lot of ownership. And hence they behave in a particular way. They are actually taking very little risk.

A late stage founder or a professional manager ceo has amassed stuff that they can lose more easily than stuff they potentially can gain. To continue to behave in the same way, they must be willing to take a lot of risk. And a lot of normal people don't want to take such risks.

Only really crazy people – be it a founder or a professional manager – will disregard game theory dynamics and work against their own apparent self-interest and take huge risks. And they tend to expect people around them to take similar huge risks along with them. We call them unreasonable people. And only really unreasonable people can make huge changes in society. This is by definition true because only such people will behave in an outlier manner, and if they do so with a huge amount of capital and power in their control, they can change societies in big ways. If we think that is working well, we celebrate them; and if we think it is horrible, we write cautionary tales about them. It is possible to have both perceptions to be held by different groups of people at the same time.

All the rest about hiring good people and letting them do etc is all just details of dynamics emanating from this unreasonable risk taking ability a person can manifest. I don't believe this can be turned into a playbook that can be taught in a management school. Management schools already teach how to take risks such that downside doesn't befall on the person who went to management school and instead falls on others. Everyone can subconsciously sense this about MBAs and hence the reaction they get. As companies become big and have a lot of external players with skin in the game (aka stakeholders) who are at a distance, they want these MBA types to manage that risk in such a way that it doesn't befall them. That's fundamentally very different from a founder who is not at a distance, but within. Still, founders also do the same when it is them vs their employees. In this aspect, it is all relative.

Since you asked for warnings about what not to do, here's one – don't share passwords! With shared accounts, you won't be able to tell who did what. If it is an important thing to which you are sharing passwords and bad thing happens, due to user action that is either accidentally or maliciously, you won't be able to find out who exactly did it and take corrective action.

This made me wonder about postgres. Is Postgres at risk of being taken over by some corporate? What can we learn from all these free open-source databases that has gone enterprise commercial.

And, that's a dis, why?

Also, food in general wasn't poisonous. And if those royals actually lived even a modestly healthy life (not drinking too much, not using lead based makeup, or their doctors poisoning them with mercury etc), then they could easily live a lot longer.

If you are IT team for a large impactful organization, you have to control updates to your organization's fleet. You cannot let vendors push updates directly. You have to stage those updates and test them and then do a gradual rollout to your whole organization.

Plus, for your critical communication systems, you must have a disaster recovery plan that actually helps you recover quickly in minutes, not hours or days. And you have to exercise this plan regularly.

If you are crowd strike, shame on you for not testing your product better. You failed to meet a very low bar. You just shipped a 100% reproducible widely impactful bug. Your customers must leave you for a more diligent vendor.

And I really hope the leadership teams in every software engineering organization learn a valuable lesson from this – listen to that lone senior engineer in your leadership team who pushes for better craft and operational rigor in your engineering culture; take it seriously - it has real business impact.

Google gives most privacy controls than any other major Internet company and actually works really hard to honor it.

Still, you can do two things to maximize your privacy:

1. In https://myactivity.google.com/activitycontrols, disable all activity history – everything should show "off".

2. In iOS, turn off background permission to all Google apps. (You can do this for most apps without loss in functionality). Then, turn off location permission all apps. For maps, give it location permission to "allow while using" only.

This is the least intrusive you can get to. Beyond this, you can also use different google account for different google apps to minimize data mingling. Further beyond that, you can just stop using google apps.

Isn't there challenges with slippage and managing the volumes while exiting? And isn't speed also about processing the data feed as fast as possible to time the exit decisions accurately?

Here's a pcisig article talking about symbol rate in terms of GT/s:

https://pcisig.com/blog/pci-express®-50-architecture-channel...

PCIe 1.0 to 5.0 used NRZ (non return to zero) electrical signaling for transmission. In NRZ signaling at high rate and over long distances, there are challenges w.r.t clock recovery, DC balance and error correction. To deal with this, encoding is used.

Encoding is basically a block of data (a sequence of zeros and ones) is represented as a sequence of electrical voltage changes (a block of symbols).

GT/s does stand for Giga Transfers per second. Here, the transfers are referring to number of symbols transferred per second, and not actual usable data bits per second.

We say GT/s instead of Gbps, because the actual usable bits/sec is determined by the encoding scheme used.

PCIe 1.0 and 2.0 encoded 8 data bits in 10 symbols (NRZ electrical signals). That's 20% overhead.

PCIe 3.0 to 5.0 encoded 128 bits of data in 130 symbols. That's a much lower overhead of 1.54%.

PCIe 6.0 (& yet to be standardized PCIe 7.0) use PAM4 for signaling and doesn't required any encoding on top –hence it is written as 1b/1b. (btw, in PAM4, each symbol is 2 bits).

You can see similar NRZ signaling with encoding in SATA, Ethernet, Fiber Channel etc. Btw, PAM4 with NRZ is used as well!

Coming to latency, latency is the time it takes for a single bit of usable data to transfer from A to B. Many factors affect this latency. Signaling medium's speed of transmission (a fraction of speed of light), signaling medium's length, signaling frequency (Mhz, Ghz etc of voltage switching), encoding scheme (encoding overhead, clock recovery or its failure and hence retransmissions, error detection/correction quality or its failure and hence retransmissions) - each of these things affect the latency of usable data.

GT/s = Signal Frequency x Bits per cycle.

Remember, PAM4 encoding in PCIe6.0 has 2 bits per cycle (2 bits per symbol).

There are many such local laws limitations that big techs have to bow to (that smaller obscure companies choose not to). For example, Google won't offer its VPN service as part of Google One in India. Whereas, proton/mullvad works just fine.

It is supposed to be simple for its users so that users own systems don't become complex. It is not supposed to be simple underneath its hood.

ncurses!

> With a web-of-trust, friends or family could vouch for your name, age or location; landlords could vouch for your address; employers could vouch for your skills; customers could vouch for businesses; and so on. As it doesn’t rely on government databases, but rather the people you know, it is truly decentralized and accessible.

This is literally how it works in majority of the real world; except for things where government has a role to play; most common case is taxes. If you are a landlord and collect rent from tenant and if either of you want to make tax related claims to the government, then you will have to provide/quote each other's government recognized identity in your tax returns.

For large parts of the population in the lower socio-economic strata, even this won't be relevant. And that reliance on that web-of-trust is the problem for them due to class discrimination etc. Hence, having a government issued identity (as a universal right) which acts as an anchor to which trusted attestations can be attached to is critical to make a difference in the life of the last person in that socio-economic line.

This is in essence the basis for India's identity system Aadhaar[1] – which is super minimal identity system – just biometrics (fingerprint, iris scan, head/shoulder photo, gender) – mapped to a a 12 digit number (basically a unique key in its database); plus 3 additional demographic fields – name, age (date of birth), address – which require external anchor proofs (which are very weak proofs). Here's the full list of accepted proofs - https://uidai.gov.in/images/commdoc/valid_documents_list.pdf

1. https://uidai.gov.in

> However, I am uncertain about how to plan the product. Can you assist me with this?

List your fav features of IMDB that you want to emulate in your project. Then, scope your project to something you can do in 3 months and do it and show off to users and get feedback. Then, after that figure out what to do next.

> What do you think about this idea?

There are common fallacies and pitfalls when someone says they want to do "like X for Y". (Like Uber for shopping etc). Learn about them and make sure your idea isn't suffering from those same issues.

I've been a decision maker on $100M+ of engineering hardware/software/services spend per quarter and here's my perspective on this problem:

1. If you are making developer tools, make sure current/existing developers find it super useful and are strong advocates for your tool.

2. Make sure you don't tick any of the 'veto' boxes – there are a few – opaque contracts, lockins, data security/privacy challenges, sso/auth integration challenges etc.

3. Make sure your pricing makes sense – if it scales linearly with some variable it is likely not going to make sense in some finance spreadsheet. A simple per developer per month fee makes a ton of sense. A site-wide floating seat license makes even more sense. For some, a lumpsum fee for site wide unlimited license makes even more sense. On the last option, you can still charge for your consumables – cloud compute/storage charges you incur – just pass it on as-is. Even better if you can deploy to customer's cloud account directly (that solves for all data privacy/security issues as well).

4. Provide sufficient cost controls – put an upper limit on billing, put an upper limit on usage. don't let anyone turn on any knob that can result in expensive usage charges etc. Also provide sufficient usage reporting facilities.

5. If you do a good job, you can sign multiyear contracts with committed spend. Make sure your service is reliable and you do a quarterly check-in with your large account customers to understand if they are happy or have specific unmet needs.

6. Remember, you can provide and charge for whiteglove professional services (dedicated butts in seat engineers, support etc). This is highly lucrative and also sometimes critical to win and keep certain types of customers. Sometimes your product is controversial inside the customer's company and there maybe detractors who will make your product fail. By having professional services do the initial integration/implementation job you can ensure your product reaches its intended users without much meddling from the IT gatekeepers.

7. Don't bother trying to sell something that a customer strongly believes they can build in-house (even if they are wrong). Even if you win initially, you will lose eventually.

A nice framework that's constructed retrospectively. Will it hold true in the future, maybe, maybe not. The thing that makes the most difference are not these broad ontological things, but short time horizon tradeoff equations around talent/skills available in the market, access to early customers and who/what they want, your personal network, your innate temperament/mindset in making day to day decisions.

No, it was routed directly to the jet engine's bleed-air system. Interestingly, jet engine was said to be a tad bit more efficient because of it.

It would have made more sense if you have context on the local politics in India or followed the supreme court case on this matter.

> That’s not an unsubstantiated claim, that’s literally how you deal with sensitive contacts and information in journalism.

The way it works is if the writing has a byline of a credible investigative journalist. It doesn't work for an anonymous wire service article.

> You understand that nobody is going to speak on the record about this, right? What, exactly, do you expect in terms of substantiation?

Journalism used to have standards. If you didn't have multiple confirmations you wouldn't publish it. These days they publish anything. They have more better credibility than anonymous opinion posts on random internet forums.

I'm clearly refuting this – "because Modi complained" in the GPs post. And your linked article is making an unsubstantiated claim based on "source with direct knowledge". That's just not credible enough.

Well, supreme court ordered panel investigation into this spyware scandal didn't find any evidence of actual spyware. So there's that. Also, if government wants to investigate someone, they have so many powerful ways to do that (and they actually do that). So, it's not clear to me what need they have to go spy on people via NSO tools. And surely, if they were building large datacenters to do massive spying like some TLAs do in 5eyes countries, we would know about it. So, no, this isn't the local government but a foreign government (which doesn't have detention powers in another country) that's likely to use remote hacking methods to coerce people in another country. We saw this with leaked data dumps from recent hacks by the not so friendly neighbors on India's many citizen databases (like retirement provident fund systems etc).

If you were the hacker operating a remote command and control for such a targeted attack, you would immediately know if Apple or some other mechanism silently blocked your exploit kill chain. This notification to users tells you nothing new. If something doesn't work, you move on to the next exploit available to you. It's not likely that they would shut shop and go away just because apple notified users. Only thing this does is Apple gets more users to turn on their protection mechanisms like lockdown mode which makes it more valuable to find vulnerabilities in that (as that is the new baseline now). And so goes the tale. It's a never ending escalatory game.

iMessage has been one of the most successful delivery vector for these spyware attacks.

So, if you think you are a likely target of a state sponsored attack, best thing you can do on an Apple device is to turn on lockdown mode, turn off iCloud and iMessage, stop using keychain, use only a yubikey for all authentication, and restrict yourself to a limited number of essential apps on your primary device and use a dedicated burner device for all your throwaway browsing and communications, and erase/reset that device after every session. And still, assume everything you say and do online is fully compromised, because there are always system vulnerabilities that haven't been made known yet ('zero-day' attacks) and are being used to compromise highly targeted individuals. In the end, it is a very convoluted cat and mouse game.