Depends on the season. Until a few years ago Bengaluru had a different problem – when it thundered or rained, they would cut power to protect transformers from shorting out due to falling trees on power lines.
2,041 karma · joined March 28, 2013
Whatever creativity/thinking/effort bandwidth that's available will now get shifted to a different place in the problem-solving effort bottleneck.
That's the hallmark of any delegation being effective. Do we see that happening with AI tools? Personally, I do see that working for me. Is it as good as the hype makes it to be or I wish it to be? maybe not, yet, for me. But that's the case with most things in life.
Money serves its purpose while it's in motion. Increasing the velocity of money is good for economy. All the payment rails above do that 24/7/365 with lowest friction – by making all modes of payment possible and for free.
Digital payment rails is an order of magnitude cheaper (all inclusive) compared to cash rails. Accepting notes, counting, and depositing them, doing book-keeping and reconciling it against sales receipts, paying workers and vendors, avoiding leakage and theft etc – all cost time and money. For small merchants, it costs them time away from their business to handle cash.
UPI person-to-merchant (p2m) payments puts money instantly in their bank account. Their bank statements showing P2M deposits help them borrow for working capital at better interest rates.
Risk of theft with cash is much higher than digital theft from their bank accounts. RBI mandated 2FA, velocity checks, cooling-off periods, and awareness campaigns etc help people avoid scams.
W.r.t taxes, GST surveillance does catch merchants who accept high volume of P2M payments but aren't filing GST returns. Conversely, filing GST returns again helps with credit ratings and borrowing on better terms for working capital.
They put out a lot of useful stats here https://www.rbi.org.in/Scripts/Statistics.aspx
Daily payment settlement stats here: https://rbidocs.rbi.org.in/rdocs/content/docs/PSDDP04062020....
I worked on scaling UPI a few years ago. Real-time Payments is vastly more complex as it is much more distributed - each transaction involves the two banks holding funds, two end-user apps (and their banks), and the network (npci) – for the payment to complete end to end, multiple message exchanges need to happen between these parties while the user at both ends are waiting. So, if you measure the scale in messages/sec it would 10-25x higher.
Real-time payment rails that works 24/7 365 days a year from any bank to any bank (domestic, no exceptions) for free is truly a game-changer. Compare that to US payment rails which is slow and expensive. Apart from UPI, India has 3 more payment rails – NEFT (similar to ACH – batch settlement), IMPS (similar to UPI, instantaneous - but different user experience), RTGS (real-time, intermediated by the central bank RBI, but only for high-value transactions) – all are 24/7/365 and free. Then, there's credit card rails – apart from Visa and Mastercard, India also has RuPay which has much lower interchange rate.
So it is less about whether people will be “allowed” to own AI, and more about whether there will be anything useful to own in the first place.
The incentive for local models is mostly to make them good orchestrators or user agents. They may give you some privacy and control, but they will still depend on much larger models running in datacenters for anything difficult.
I remember all the excitement around OpenMoko and other open-source “BlackBerry killer” projects. BlackBerry did get killed, but not by any of those individual-first projects.
For AI regulation, I think we should focus on normal commercial rules: consumer protection, privacy, antitrust, liability, and so on. In other words, focus on where money changes hands and where companies have power over users.
Military and offensive use is different. There, regulation is not much of a defense. The real defense is having enough capability and strength of your own.
Restricting AI because it can give dangerous knowledge to ordinary people is like restricting the printing press because it can be used to spread radical ideas.
The way mobile radio/phone networks have evolved (trusted walled garden with backward compatibility) vs Internet has evolved (untrusted with end to end security) is in stark contrast to each other.
Irritating thing is how Apple hides bluetooth headphones pairing 2-3 clicks deeper than AirPods pairing – on iPhones and Apple TV.
If you let your legal team use such broad CYA language, it is usually because you are not sure what's going on and want CYA, or you actually want to keep the door open for broader use with those broader permissive legal terms. On the other hand, if you are sure that you will preserve user's privacy as you are stating in marketing materials, then you should put it in legal writing explicitly.
Then start your materialistic business end of your day. Learn to breathe and keep your mind calm and present throughout the day. Watch/catch yourself if your mind runs wild with background threads – try and disable background jobs in your mind for a few weeks.
If you have a spouse/partner, discuss these goals with them and ask for their cooperation while you are trying to change your habits. Have realistic expectations, and be generous towards others.
Coming to materialistic business hours of your day, focus on problem-solving and living in reality.
Work through your own personal Maslov's hierarchy of needs. Be strategic, be realistic, and try to build a reasonable position of confidence. Then, launch yourself further from there. Don't overextend yourself.
All the best!
1. You have a lock, you have a corresponding physical key. You can have more identical physical keys. All of them will unlock the lock. If you lose the physical key, you can call the locksmith to change the lock. Physical key is anonymous. Only you know which key unlocks which lock. If a random person finds your physical key on the street, they shouldn't be able to find their way to your lock to try and unlock it.
2. That's all well and good. Now, comes a magic key. That's your personal magic key. Any lock you are permitted to unlock, your magic key can unlock it. Any key you are not permitted to unlock, your magic key cannot unlock. Now, you can more than one magic key – where only some of the locks you are allowed to unlock can be unlocked by one magic key vs another. And if you happen to lose your magic key, you can call your locksmith to cancel your magic key – actually, that's a keysmith than a locksmith!
3. Your magic key is still anonymous. Only you know which magic key can open which locks. A random person who finds your magic key shouldn't be able to find their way to all the locks it can unlock.
4. When you see a lock, you are prompted to insert a key. The prompt doesn't say which key. You try one of the magic keys have that you think should unlock it. If it happens to the wrong key, not a big deal. You just try another magic key you have, and if that's the correct key it will unlock it.
5. When you buy a new lock (sign-up), you decide which magic key you have that should be the one to unlock it. This pairing of the key to the lock is done simply by asking pair a key to the lock. You are not being told to use a specific vendor of magic keys. You are not being peddled only magic key vendor over another!
6. If you want to change the magic key paired to a lock, you can do so at anytime on your own as long as you are in possession of the current magic key.
7. And of course, you can have multiple magic keys paired to the lock, so that you can unlock with any of the keys.
8. When you use a key to unlock a lock, the lock can tell which paired key was used – you can give nicknames to the paired keys that the lock remembers. The lock will tell you which nicknamed keys were used to unlock it previously and when.
-----
Here's where I think passkeys went awry. They became yet another platform war. The OSes and browsers are supposed to be neutral and provide an unobtrusive prompt for user to pair a key or use a key, that's it. And the user should invoke a keyring against that prompt. If the keyring provider has features – like portability or non-portability of keys etc that's unique to each key ring provider and as long as the user is comfortable with it, everyone should be good with it. The prompt needs to be unassuming. Today it is very assuming and that's the problem!
Apart from free users, even the contributors have very similar considerations for their participation.
But the starting point is the license – it has to be a clear and unambiguous open-source license that is widely well-understood – especially w.r.t the blast-radius or infection radius of the license. Does it infect the library code that is linked/loaded into it? Does it infect the independent binary/processes that scaffold around it (say, control-plane, orchestrator, proxy etc)? What are the obligations if it does? If we have to get lawyers involved to answer these questions because it is a custom license that is vaguely written or it has never been challenged in a court or the license holder is of unknown reputation, these are huge red flags.
Another equally important consideration is the motivations of the stewards of the project. While this isn't explicitly stated, one cannot be naive about it. Contributors and users will have to consider a gamut of scenarios – best/base/worst scenarios and make their judgement. With smaller steward organizations, there are one kind of risks while with larger organizations open-sourcing there are other kinds of risks. If they are competitors in some way that's another challenge. If there is no natural alignment of use-cases functionally or non-functionally, that's another issue etc.
With recent changes in Redis, all these things have become less clear and straightforward.
1. Make the software scalable w.r.t machines.
2. Make the software scalable w.r.t humans.
3. Make the software maintainable over time.
4. Make the software reusable to reduce startup costs.
Motivated by these, we make a lot of choices:
1. decompose a large complex problem into smaller, isolated, modular problems that can be worked on by different small teams, and run on different servers with inter-server communication.
2. organize code along with its documentation for easy understanding, readability and modifiability over time by same developers and different developers.
3. organize reusable and independently upgradable parts of the code for ease of upgrade with stable interfaces and stable test suites.
4. maintain the build/package/deploy toolchains for ease of underlying hardware and operating systems upgrades without affecting all of the code.
5. reuse is the only way to reduce costs – both time and effort – for anything. thinking carefully and setting up for reuse of services, systems, libraries, toolchains, processes, practices etc are critical to any large successful software project.
These are general rules for normal times. But there are inflection points when it is profitable to violate these rules.
Things that distort the cost/benefit tradeoffs and make it profitable to violate these rules:
1. When tech ecosystem is rapidly evolving and toolchains and libraries ecosystem isn't mature.
2. When time to market is super critical and if successful we will have more than enough money to deal with these problems later, and if we are late even with good software we would have failed and shut shop.
3. When we can't hire talented skilled engineers and still it is worthwhile to win in the short-term.
With these rules and violations, you can get stuck in an early local optima. A culture of continuous safe refactors is a super-power that can make you immune to it. Ossification of any kind is bad.
Until we invent some sort of non-obtrusive brain observability system (like a no-op continuous observability implant) that can take precise and accurate measurements with timestamps that can be correlated with other measurements taken across the boday of a person living their normal life, it is going to be difficult to form an effective study for this.
1. Learn how to learn well, continuously, and sustainably. Tech changes rapidly. And you will want to hop from one domain to another, just for keeping things interesting and to move with markets. This is both a blessing and a curse. It is a blessing because you can start late and still be in the top percentile if you have the brains and work hard for it. It is a curse because you will be doing this no matter how many years of experience you have.
2. Hone your non-technical skills– caution: these are compounding over time (both good and bad habits) – being disciplined, thinking clearly, articulating clearly, being professional, being trustworthy, managing your physical and mental health, being dependable/reliable, having a growth mindset, thriving in ambiguity and uncertainty etc. then, honing your communication skills – effectively collaborating with people, give/receive effective feedback, do/get mentoring/coaching, working with cross-functional people, working with very seniors, very juniors, peers etc. read a lot, develop mental models, deeply craft your personal approach to first principles problem solving, to making tradeoffs/bets etc.
You can do the above all by yourself, through reading, and observing people from afar, and engaging with people (even strangers on forum like this one) in dialog.