Seems like the Twitter debate is the new black. The topic appears to be polarizing like hell, and I found that only a few people can reason about the events calmly.
There's "it's a death sentence for a civic conversation" on the one end, and "finally, we'll be able to see what people truly care about" on the other. With not much in between.
Both sides, of course, are right. Free speech absolutism invites all sorts of extremes, which are generally not desirable for most users. The other extreme, which, IMHO, Twitter was quite leaning towards in the past few years, is to be excessively censoring whatever does not fit "the media narrative", which inevitably results in various viewpoints being silenced, despite being proven true soon thereafter.
My view here remains the same: opening up the algorithm is generally a great thing. I wrote about it at length before.
The TL;DR is: if you want to use The Algorithm to help solve some Massive Social Problem, but then you tweak the results of this algorithm because it does not fit your definition of right, it's you, not the algorithm, who is to blame.
Sure, an algorithm would miss on important real-life implications. With crime prevention, for example, The Algorithm gets into Orwellian, Minority Report-style biases, that should absolutely be corrected for.
But my strong belief is that it is important to correct for these biases BEFORE, not AFTER The Algorithm. In other words, these corrections should be the inputs to the algorithm, not post-overrides.
Thus, if, IF, Elon is going to do with he claims to want to do -- the Algorithm-first approach to content selection -- then I do believe it will be a step forward.
Whether he will actually work towards making it so, or whether this can be implemented with our current state of technology, or whether the regulators and/or other big players would allow Twitter to be such a platform -- only time will tell, I guess.
I do keep my fingers crossed though. And am hoping for the best.
There's "it's a death sentence for a civic conversation" on the one end, and "finally, we'll be able to see what people truly care about" on the other. With not much in between.
Both sides, of course, are right. Free speech absolutism invites all sorts of extremes, which are generally not desirable for most users. The other extreme, which, IMHO, Twitter was quite leaning towards in the past few years, is to be excessively censoring whatever does not fit "the media narrative", which inevitably results in various viewpoints being silenced, despite being proven true soon thereafter.
My view here remains the same: opening up the algorithm is generally a great thing. I wrote about it at length before.
The TL;DR is: if you want to use The Algorithm to help solve some Massive Social Problem, but then you tweak the results of this algorithm because it does not fit your definition of right, it's you, not the algorithm, who is to blame.
Sure, an algorithm would miss on important real-life implications. With crime prevention, for example, The Algorithm gets into Orwellian, Minority Report-style biases, that should absolutely be corrected for.
But my strong belief is that it is important to correct for these biases BEFORE, not AFTER The Algorithm. In other words, these corrections should be the inputs to the algorithm, not post-overrides.
Thus, if, IF, Elon is going to do with he claims to want to do -- the Algorithm-first approach to content selection -- then I do believe it will be a step forward.
Whether he will actually work towards making it so, or whether this can be implemented with our current state of technology, or whether the regulators and/or other big players would allow Twitter to be such a platform -- only time will tell, I guess.
I do keep my fingers crossed though. And am hoping for the best.
Another video with Interviewing.io, codename "two experts design the system". Extremely well moderated by both Kevin & Mike, and pleasure working with Bruno & the broader team on this one.
YouTube
Two Ex-Google System Design Experts Compete: Who will design the better system? [Part 1]
🏆 In this video, two Ex-Google system design experts put their skills to the test in a race against time to see who will come out victorious. The task set is to recreate interviewing.io, which, in this scenario, consists of designing Google Docs, a remote…
Folks, what do people mean today when they say "Zero Trust" APIs?
My undestanding -- that might be wrong -- is that each service needs to securely validate the request, as if this request is coming from the outer world. Because security, microservices, etc.
But in this model if a request requires 20+ other requests, the only solution is to make 20+ zero-trust requests which would all be validated as if they are coming from, well, zero trust. Which is both a colossal waste of resources and a huge toll on end-to-end user-perceived latency.
What am I missing?
My undestanding -- that might be wrong -- is that each service needs to securely validate the request, as if this request is coming from the outer world. Because security, microservices, etc.
But in this model if a request requires 20+ other requests, the only solution is to make 20+ zero-trust requests which would all be validated as if they are coming from, well, zero trust. Which is both a colossal waste of resources and a huge toll on end-to-end user-perceived latency.
What am I missing?
Another video about SysDesign, jointly with the Interviewing.io folks. Grace and Kevin rock!
YouTube
Senior Engineer Gets Mentored by System Design Expert 💯
🔥 This video is a system design primer which will show you how to prepare for system design interviews. This content is made for mid-level and senior software engineers who want to learn the fundamentals of system design so they can pass FAANG interviews…
Unpopular / controversial opinion: if Musk doesn't get his act together, I'm quite seriously willing to bet on him being pressured from the top.
Along the lines of "don't mess with our ways to run social ads / experiment with political content distribution / exercise influence here and there, or we'll make sure both SpaceX and Tesla lose most of their value, to begin with".
He's not an idiot, and his ego is not unreasonably huge for the tasks he's tacking. So, my bet would be that the true explanations are elsewhere. The only ones I have, unfortunately, are quite sad.
Along the lines of "don't mess with our ways to run social ads / experiment with political content distribution / exercise influence here and there, or we'll make sure both SpaceX and Tesla lose most of their value, to begin with".
He's not an idiot, and his ego is not unreasonably huge for the tasks he's tacking. So, my bet would be that the true explanations are elsewhere. The only ones I have, unfortunately, are quite sad.
Some thoughts on Quiet Quitting.
From the game theory standpoint, those who consciously decide to "not participate" in the labor market "until the conditions improve" are doing no more and no less than participating in the act of collective bargaining.
The economy today is indistinguishable from a situation where surprisingly many workers across surprisingly many industries have suddenly and successfully unionized. And decided to go on strike until their conditions improve. Are are standing their ground so far.
Quite a few people seriously believe that they deserve better conditions (pay, benefits, WFH, etc.) than the market can offer today. It's hard to argue that, to some extent, these people are right. The market is indeed not treating them well. And they can indeed improve their collective well-being by acting in a "united" way.
The future, however, is uncertain.
First, we are about to continue with recession. So, in absolute terms, many people's situation will be getting worse. Many may well crack under pressure, because money is, well, quite an effective motivator, to put it blunt.
Second, improved job performance, thanks to automation and robotics, is far more mature today compared to what it was ~50 years ago. For many industries, including agriculture, manufacturing, and retail, fewer workers are needed to keep things running.
Third, "bullshit jobs". If a sufficient fraction of people who are involved in non-bullshit jobs decide to quit what they are doing, the world may well change. As of today, however, it is not clear how many of the "quitters" truly qualify for "essential workers".
In a perfect world we might expect to see the state of the art change, towards people willing to pay more for what we are used to having for less. And we might expect to see wages increase.
After all, many of the price breakdowns we are used to are just situational market equilibriums. Who said the car requires a certain number of cents for maintenance per one dollar of gas? Who said keeping one's wardrobe and shoes in certain shape should require a certain percentage of family budget, and how should this percentage compare to what we spend on gadgets or online subscriptions? It is not unreasonable to expect that, in a perfect world, some large-scale rebalance of values happens "thanks to" the current Quite Quitting trend, and we wake up to the state of the economy where the people who participated in this movement are better off compared to before it has stated.
Intuitively, I doubt it though. For two reasons.
One, one can't do anything with supply/demand impedance. The economy needs production. If we produce less than we consume, depression kicks in. It's just too hard to change people's spending habits when everyone begins spending less. If anything, expect federal programs across the globe to boost spending. And these programs would immediately steer the global worker strike experiment" the wrong way; likely to help it "return" to where the economy was before; where the workers are not happy, but keep working, because that's the best option they have.
Two, on the global markets scale. We, Americans, are outsourcing a lot. Most certainly, if Americans buy more American products (and, consecutively, fewer Chinese et. al. products), the American economy improves. Most certainly, if the outcome is that Americans buy more American products, the wages of American workers increase. But the lockdowns situation is lasting for a while now, and it doesn't seem to me that the share of American products on the American market is growing.
I can't think of any big conclusions to definitively draw from the above. Except that we are receiving a yet another confirmation that market downturns inevitably hit the Average Joe and Jane the hardest. And, on top of that, a (somewhat weaker) confirmation that "global unionization" of workers does not necessarily result in better conditions, at least not in the short term.
From the game theory standpoint, those who consciously decide to "not participate" in the labor market "until the conditions improve" are doing no more and no less than participating in the act of collective bargaining.
The economy today is indistinguishable from a situation where surprisingly many workers across surprisingly many industries have suddenly and successfully unionized. And decided to go on strike until their conditions improve. Are are standing their ground so far.
Quite a few people seriously believe that they deserve better conditions (pay, benefits, WFH, etc.) than the market can offer today. It's hard to argue that, to some extent, these people are right. The market is indeed not treating them well. And they can indeed improve their collective well-being by acting in a "united" way.
The future, however, is uncertain.
First, we are about to continue with recession. So, in absolute terms, many people's situation will be getting worse. Many may well crack under pressure, because money is, well, quite an effective motivator, to put it blunt.
Second, improved job performance, thanks to automation and robotics, is far more mature today compared to what it was ~50 years ago. For many industries, including agriculture, manufacturing, and retail, fewer workers are needed to keep things running.
Third, "bullshit jobs". If a sufficient fraction of people who are involved in non-bullshit jobs decide to quit what they are doing, the world may well change. As of today, however, it is not clear how many of the "quitters" truly qualify for "essential workers".
In a perfect world we might expect to see the state of the art change, towards people willing to pay more for what we are used to having for less. And we might expect to see wages increase.
After all, many of the price breakdowns we are used to are just situational market equilibriums. Who said the car requires a certain number of cents for maintenance per one dollar of gas? Who said keeping one's wardrobe and shoes in certain shape should require a certain percentage of family budget, and how should this percentage compare to what we spend on gadgets or online subscriptions? It is not unreasonable to expect that, in a perfect world, some large-scale rebalance of values happens "thanks to" the current Quite Quitting trend, and we wake up to the state of the economy where the people who participated in this movement are better off compared to before it has stated.
Intuitively, I doubt it though. For two reasons.
One, one can't do anything with supply/demand impedance. The economy needs production. If we produce less than we consume, depression kicks in. It's just too hard to change people's spending habits when everyone begins spending less. If anything, expect federal programs across the globe to boost spending. And these programs would immediately steer the global worker strike experiment" the wrong way; likely to help it "return" to where the economy was before; where the workers are not happy, but keep working, because that's the best option they have.
Two, on the global markets scale. We, Americans, are outsourcing a lot. Most certainly, if Americans buy more American products (and, consecutively, fewer Chinese et. al. products), the American economy improves. Most certainly, if the outcome is that Americans buy more American products, the wages of American workers increase. But the lockdowns situation is lasting for a while now, and it doesn't seem to me that the share of American products on the American market is growing.
I can't think of any big conclusions to definitively draw from the above. Except that we are receiving a yet another confirmation that market downturns inevitably hit the Average Joe and Jane the hardest. And, on top of that, a (somewhat weaker) confirmation that "global unionization" of workers does not necessarily result in better conditions, at least not in the short term.
Why doesn’t Ubuntu let me install Android apps natively?
My laptop has a SIM card slot. I do buy local phone numbers in various places. In fact, mobile Internet is so good these days that I often work, take my video calls, and even host my meetup events over the internet that is coming through this in-laptop SIM card.
For many local 4G/LTE providers the best way to manage my account is via their native mobile app.
Why can’t I “install” their native “app” into Ubuntu and let it manage my “mobile internet” on my laptop? Up to and including receiving the confirmation text message, etc.? I expect this app to 100% believe it is running on some non-standard yet popular Android phone.
Why can’t I write a one-liner script to check my balance via a USSD code every hour or so?
Where’s technology when we need it most? =)
My laptop has a SIM card slot. I do buy local phone numbers in various places. In fact, mobile Internet is so good these days that I often work, take my video calls, and even host my meetup events over the internet that is coming through this in-laptop SIM card.
For many local 4G/LTE providers the best way to manage my account is via their native mobile app.
Why can’t I “install” their native “app” into Ubuntu and let it manage my “mobile internet” on my laptop? Up to and including receiving the confirmation text message, etc.? I expect this app to 100% believe it is running on some non-standard yet popular Android phone.
Why can’t I write a one-liner script to check my balance via a USSD code every hour or so?
Where’s technology when we need it most? =)
Folks, how realistic is the following plan?
• Ask people to pay my nonprofit, not me myself or my company, for my extracurricular activities,
• Call out publicly for some open source help, and
• Pay those who are kind enough to help with this open source stuff from this nonprofit?
My rationale is that since whatever I'd be paying for is public domain, and as long as I ask the folks to sign a waiver that they release their code to public domain, this is well in line with what nonprofits are.
Moreover, I would not have to worry about spending all of this non-profit's earnings by the EOY, as I have to with an LLC or with a corp. Because, as far as I understand, non-profits don't pay tax on their annual income.
Obviously, I do not plan to profit directly from those open source contributions. I'll look into making sure this open source work can be leveraged with other, proprietary, code that is not paid for by this non-profit. But everyone is welcome to use the very open source pieces freely, as permitted by the license under which these contributions are released.
Is this a good pattern, or am I walking on shaky grounds if I choose to pursue it?
PS: The extracurricular activities would be my mock interviews / prep sessions / talks I give that people are comfortable paying for / etc.
• Ask people to pay my nonprofit, not me myself or my company, for my extracurricular activities,
• Call out publicly for some open source help, and
• Pay those who are kind enough to help with this open source stuff from this nonprofit?
My rationale is that since whatever I'd be paying for is public domain, and as long as I ask the folks to sign a waiver that they release their code to public domain, this is well in line with what nonprofits are.
Moreover, I would not have to worry about spending all of this non-profit's earnings by the EOY, as I have to with an LLC or with a corp. Because, as far as I understand, non-profits don't pay tax on their annual income.
Obviously, I do not plan to profit directly from those open source contributions. I'll look into making sure this open source work can be leveraged with other, proprietary, code that is not paid for by this non-profit. But everyone is welcome to use the very open source pieces freely, as permitted by the license under which these contributions are released.
Is this a good pattern, or am I walking on shaky grounds if I choose to pursue it?
PS: The extracurricular activities would be my mock interviews / prep sessions / talks I give that people are comfortable paying for / etc.
Late last year I was involuntarily subjected to an interesting psychological experiment.
I misplaced my credit card, my US Passport Card, and some 20 USD.
This made me relatively upset for about two days. Even though 20 USD is nothing to worry about. Even though I have more credit cards on me. Even though I could block this lost card with one message on my phone, which I did. And even though Apple Pay, tied to this card, kept working perfectly fine, so my daily routine was literally unaffected.
Clearly, what made me sad is the loss of the Passport Card.
Sparing the details, here's the thought process that got me back to peace.
This is *exactly* the purpose of the Passport Card!
And it has served its purpose well.
Why did I get a passport card in the first place? To have an alternate ID, in the form & shape of a credit card, an alternate ID that is "safe" to lose, just in case.
What would I carry with me if I did not have this card? My driving license, of course. Which is a far worse document to lose while overseas. Granted, I have another one, from Switzerland, but it's falling apart after 10+ years, so it really really is just a backup one.
Would I "emotionally prefer" to have lost ~100 USD instead of ~20 USD and not lose the Passport Card? Hell yeah, I'd get over losing ~100 USD far quicker than over losing the Passport Card.
Would I have paid that 100 USD to obtain the passport card in the first place, had it been something to order specifically, not something that came with the passport? Likely no; at least, it would have been a close decision.
So, rationally speaking, I concluded that I am worried far too much compared to the true "damage done". I got a passport card to keep it on me mostly as a backup ID so that I don't lose the driving license, I kept it on me mostly for this very purpose, and — whoa! — I did not lose the driving license.
The Universe is working its ways just as it should. Why am I disappointed to begin with?
And I am happy to report this logic & reason did bring me back to peace.
PS: After ~six rounds of human interactions my credit card and my passport cards were found. In the IMAX theater. Although it required two trips there, one to leave the "lost & found request", and one more to manually check on its status, as they did not call back. Karmically weirdly, the cards were found exactly on that one last trip that also had the smallest chance of success, because why would you go somewhere if they would call you on the phone number you left there, right?
PS2: Avatar 2 has amazing visual effects. Distant second would come its effort in autism awareness. Hard to say what would be a distant third. It's still a nice movie, at least for someone like me who frequents movie theaters with a cadence of approximately once in three years.
I misplaced my credit card, my US Passport Card, and some 20 USD.
This made me relatively upset for about two days. Even though 20 USD is nothing to worry about. Even though I have more credit cards on me. Even though I could block this lost card with one message on my phone, which I did. And even though Apple Pay, tied to this card, kept working perfectly fine, so my daily routine was literally unaffected.
Clearly, what made me sad is the loss of the Passport Card.
Sparing the details, here's the thought process that got me back to peace.
This is *exactly* the purpose of the Passport Card!
And it has served its purpose well.
Why did I get a passport card in the first place? To have an alternate ID, in the form & shape of a credit card, an alternate ID that is "safe" to lose, just in case.
What would I carry with me if I did not have this card? My driving license, of course. Which is a far worse document to lose while overseas. Granted, I have another one, from Switzerland, but it's falling apart after 10+ years, so it really really is just a backup one.
Would I "emotionally prefer" to have lost ~100 USD instead of ~20 USD and not lose the Passport Card? Hell yeah, I'd get over losing ~100 USD far quicker than over losing the Passport Card.
Would I have paid that 100 USD to obtain the passport card in the first place, had it been something to order specifically, not something that came with the passport? Likely no; at least, it would have been a close decision.
So, rationally speaking, I concluded that I am worried far too much compared to the true "damage done". I got a passport card to keep it on me mostly as a backup ID so that I don't lose the driving license, I kept it on me mostly for this very purpose, and — whoa! — I did not lose the driving license.
The Universe is working its ways just as it should. Why am I disappointed to begin with?
And I am happy to report this logic & reason did bring me back to peace.
PS: After ~six rounds of human interactions my credit card and my passport cards were found. In the IMAX theater. Although it required two trips there, one to leave the "lost & found request", and one more to manually check on its status, as they did not call back. Karmically weirdly, the cards were found exactly on that one last trip that also had the smallest chance of success, because why would you go somewhere if they would call you on the phone number you left there, right?
PS2: Avatar 2 has amazing visual effects. Distant second would come its effort in autism awareness. Hard to say what would be a distant third. It's still a nice movie, at least for someone like me who frequents movie theaters with a cadence of approximately once in three years.
My understanding of Docker, docker compose, and other higher-level concepts of modern software architecture has just been upgraded to a new level.
I realized I adore them deeply. For a convoluted and controversial reason.
Not only these concepts enable us, engineers, to ship more complex software. That's nice, that's important, but that's not what fascinates me in modern technology.
What makes me love these technologies dearly is their unique property of requiring even more deep thought from whoever uses them.
Let me explain. Some twenty years ago software was "simple". From first principles, any savvy kid could learn enough to qualify for a Jr. engineer by 18yo and for a Sr. engineer by some 25yo. And those "simple" technologies were not very deep in nature.
Today, much as I hate saying this, a modern GPT-* model can handle most of the "complexity" of the technology of the early 2000s.
The technologies the ~18yo-s .. ~25yo-s have to master today, miraculously, are the exact opposite of what GPT-* can be “proficient at”.
Simple things became simpler to build, but the complexity of nontrivial things has grown exponentially. A good engineer today is not someone who understands algorithms and data structures. It's one who is capable of holding in their head the architecture of a system with dozens of moving parts.
From the engineering side, we, modern engineers, are exercising the most powerful part of our brain: managing layers of abstraction. Jr. engineers know how to reason about them. Sr. engineers know how to prefer some to others. Architects know when to break the rules and when to create new abstractions.
Great products emerge throughout engineers navigating these abstractions, and the engineers are paid well in the meantime.
I could not dream of a better world. With all its imperfections, software architecture today is almost intelligently designed to self-select for the people who are good at specifically this: correctly and seamlessly managing multiple layers of abstraction.
So, next time you feel annoyed by a nontrivial counterintuitive behavior of git, or docker-compose, or some hook / trigger / lambda / GitHub action, or whatever tool you use to collect and crunch logs in real time, take a deep breath and relax. That's all how it should be. Had it been "easier", working on software would not require this much intelligence, would not pay well enough, and would not be this much fun.
PS: I played quite a bit with GitHub Actions, docker compose, and wasm/Emscripten in the past several months, and enjoyed how things come together quite a bit.
I realized I adore them deeply. For a convoluted and controversial reason.
Not only these concepts enable us, engineers, to ship more complex software. That's nice, that's important, but that's not what fascinates me in modern technology.
What makes me love these technologies dearly is their unique property of requiring even more deep thought from whoever uses them.
Let me explain. Some twenty years ago software was "simple". From first principles, any savvy kid could learn enough to qualify for a Jr. engineer by 18yo and for a Sr. engineer by some 25yo. And those "simple" technologies were not very deep in nature.
Today, much as I hate saying this, a modern GPT-* model can handle most of the "complexity" of the technology of the early 2000s.
The technologies the ~18yo-s .. ~25yo-s have to master today, miraculously, are the exact opposite of what GPT-* can be “proficient at”.
Simple things became simpler to build, but the complexity of nontrivial things has grown exponentially. A good engineer today is not someone who understands algorithms and data structures. It's one who is capable of holding in their head the architecture of a system with dozens of moving parts.
From the engineering side, we, modern engineers, are exercising the most powerful part of our brain: managing layers of abstraction. Jr. engineers know how to reason about them. Sr. engineers know how to prefer some to others. Architects know when to break the rules and when to create new abstractions.
Great products emerge throughout engineers navigating these abstractions, and the engineers are paid well in the meantime.
I could not dream of a better world. With all its imperfections, software architecture today is almost intelligently designed to self-select for the people who are good at specifically this: correctly and seamlessly managing multiple layers of abstraction.
So, next time you feel annoyed by a nontrivial counterintuitive behavior of git, or docker-compose, or some hook / trigger / lambda / GitHub action, or whatever tool you use to collect and crunch logs in real time, take a deep breath and relax. That's all how it should be. Had it been "easier", working on software would not require this much intelligence, would not pay well enough, and would not be this much fun.
PS: I played quite a bit with GitHub Actions, docker compose, and wasm/Emscripten in the past several months, and enjoyed how things come together quite a bit.
What is the "breakthrough" of Quantum Advantage, formerly known as Quantum Supremacy?
I can build a machine with N nodes and M wires. Each node would have an adjustable electrical resistance, a digital voltmeter, and a pair of connectors, in and out.
With N dynamically adjustable electrical resistances and M mechanical arms or motors or what not, it would be an O(1) operation to get to any topology of how these wires connect to one another.
(A grid, where M = N^2, or where M = N*2, so that only the adjacent nodes can be connected, might be easier to visualize.)
Now, I would let electric current flow between the first node and the last node. And I'll measure the voltages on all nodes.
Voila! I have reproducibly, and relatively accurately, solved a real-life problem in O(1), using O(N+M) "computing elements". Solving such a problem on a modern ("von Neumann") computer would, if I recall correctly, require more "computations" than such a process.
Matter can compute. We all know this. The "traditional" computer is just one way to build a "universal evaluator".
Despite what the Turing-Church thesis tells us about computability, there is no fundamental law which would state that using the ALU (arithmetic logic unit) in the way modern CPUs do is the most effective way to make matter perform computation.
I just outlined an example of a "computer" that would vastly outperform a "traditional" CPU on a real-life problem. How is it not Q.E.D.?
Quantum computers make clever use of far less intuitive laws of physics to arrive at presumably more effective "hardware" to run more effective "algorithms". But quantum effects by no means have a monopoly on "cheating" the modern CPU architecture.
Electricity, optics, heck, even gasoline & metal, in engine tests, can do and arguably do do a better job at solving some computational problems compared to the good old CPUs.
Friendly reminder: an optical array can perform a Fourier transform of an image. Or even apply a ("hard-coded") neural network to it. It's not hard to imagine a zero-watt, emission-free, "solar-powered" "crystal ball" that will show a green light when pointed at a dog and a red light when pointed at a cat. In the same O(1) "computational complexity". So what?
And, at least to me, finding the prime factors of 21 looks far less sophisticated than solving the system of equations to compute electric current.
So, what's the big deal about that Quantum Advantage? After all, we already have Kirghoff's Advantage, Maxwell's Advantage, and Navier-Stokes Advantage, to name a few.
I can build a machine with N nodes and M wires. Each node would have an adjustable electrical resistance, a digital voltmeter, and a pair of connectors, in and out.
With N dynamically adjustable electrical resistances and M mechanical arms or motors or what not, it would be an O(1) operation to get to any topology of how these wires connect to one another.
(A grid, where M = N^2, or where M = N*2, so that only the adjacent nodes can be connected, might be easier to visualize.)
Now, I would let electric current flow between the first node and the last node. And I'll measure the voltages on all nodes.
Voila! I have reproducibly, and relatively accurately, solved a real-life problem in O(1), using O(N+M) "computing elements". Solving such a problem on a modern ("von Neumann") computer would, if I recall correctly, require more "computations" than such a process.
Matter can compute. We all know this. The "traditional" computer is just one way to build a "universal evaluator".
Despite what the Turing-Church thesis tells us about computability, there is no fundamental law which would state that using the ALU (arithmetic logic unit) in the way modern CPUs do is the most effective way to make matter perform computation.
I just outlined an example of a "computer" that would vastly outperform a "traditional" CPU on a real-life problem. How is it not Q.E.D.?
Quantum computers make clever use of far less intuitive laws of physics to arrive at presumably more effective "hardware" to run more effective "algorithms". But quantum effects by no means have a monopoly on "cheating" the modern CPU architecture.
Electricity, optics, heck, even gasoline & metal, in engine tests, can do and arguably do do a better job at solving some computational problems compared to the good old CPUs.
Friendly reminder: an optical array can perform a Fourier transform of an image. Or even apply a ("hard-coded") neural network to it. It's not hard to imagine a zero-watt, emission-free, "solar-powered" "crystal ball" that will show a green light when pointed at a dog and a red light when pointed at a cat. In the same O(1) "computational complexity". So what?
And, at least to me, finding the prime factors of 21 looks far less sophisticated than solving the system of equations to compute electric current.
So, what's the big deal about that Quantum Advantage? After all, we already have Kirghoff's Advantage, Maxwell's Advantage, and Navier-Stokes Advantage, to name a few.
Expectation: Developers are essential and ChatGPT will not affect our lives in meaningful ways, because what we do for living is about as far from mimicking simple tasks as possible, and about as close to Strong AI as possible.
Reality: Attending a training on GitHub Actions, and the format is literally how one would train ChatGPT in a "monkey sees monkey does" way.
Reality: Attending a training on GitHub Actions, and the format is literally how one would train ChatGPT in a "monkey sees monkey does" way.
My new favorite mid-level / senior coding interview question: Write a function that returns a random compact JSON of a given length.
The JSON should be compact in the sense that it has no extra whitespace; whatever
The output of the function should be a string, of length equal to the argument provided to the function.
Acceptance criteria: imagine there will be a forum of developers looking for some
Do you best for ~25..30 minutes, then we'll talk. Now go.
The JSON should be compact in the sense that it has no extra whitespace; whatever
JSON.stringify(object)
returns is compact by definition.The output of the function should be a string, of length equal to the argument provided to the function.
Acceptance criteria: imagine there will be a forum of developers looking for some
random-json
function to use random JSONs in their tests. You should strive to make them want to choose your implementation.Do you best for ~25..30 minutes, then we'll talk. Now go.
We really need some torrent-style worldwide Docker and Ubuntu mesh network of distribution.
Just unthinkable how much traffic is wasted daily by moving the very same bits over and over again.
Just unthinkable how much traffic is wasted daily by moving the very same bits over and over again.
Not intending to start a holy war [probably], but I'm finding myself comparing programming languages to one another again.
To set the tables straight, I'm talking about backend development, where high throughput, low latency, and high reliability are essential.
In addition to the above, I am at the stage of my career where "design for refactoring" is a big theme. So just "we can hack this up quickly" and/or "we can make it work super-quickly in just a week of work" are not strong enough arguments, because what would the company do after you've shipped it and left?
The above immediately disqualifies languages such as JavaScript and Python. Too slow, and pretty much impossible to refactor, or even maintain.
The pros and cons of the "standard" languages are sort of well known. Let me summarize them quickly; again, this is not intending to start a pointless discussion, and I do not claim to be unbiased, just setting the tables to actually ask what I want to ask about.
• C++. Pros: The code would be effective, and, if the team is strong and C++-focused, the code would be maintainable, and relatively error-free. Cons: You pretty much have to be a C++ company, or, at least, you need to have a task that is so niche and so performance-critical, that it's okay for this particular piece to be done in C++.
• Java and other JVM languages, most notably Kotlin. Pros: Easy to find people who speak the language. Cons: I personally am terrified by a) code bloat, b) garbage collection that kills latency at high percentiles, and c) slow warm-ups, so that autoscaling becomes a pain in and of itself.
• C# and the .NET family. Pros: About the same as Java, plus, personally, I'm more comfortable with .NET runtime vs. the JVM one, even on Linux. Cons: Same as with JVM.
Now, the question. In the setup above, how should one gauge Rust and Golang?
My view is rather straightforward so far.
• Rust: Still young. Unclear if it delivers enough to win over C++; i.e., even if support- and refactoring-wise it turns out to be better than C++ for "simple" services in the long run, Rust people are still rather difficult to find.
• Golang. Here, I'm on the fence. There's a large crowd of people who would argue Go is unfit for large projects, mostly due to lack of proper type safety. There's also a large crowd of people who would argue Go is quite efficient for its simple syntax.
Ultimately, my question then is: should Go be taken seriously in 2023?
Is it worth my time to learn it and [help] build a production service in it?
Or would this knowledge be rather useless, given I speak C++ well, and for "simple" low-latency high-throughput gRPC services, it likely is and will remain a better choice?
If the latter is true, I should not really invest much into Golang, and wait for an opportune moment to educate myself on Rust. If the former is true, an opportune moment is now.
Advice welcome -- and many thanks in advance!
To set the tables straight, I'm talking about backend development, where high throughput, low latency, and high reliability are essential.
In addition to the above, I am at the stage of my career where "design for refactoring" is a big theme. So just "we can hack this up quickly" and/or "we can make it work super-quickly in just a week of work" are not strong enough arguments, because what would the company do after you've shipped it and left?
The above immediately disqualifies languages such as JavaScript and Python. Too slow, and pretty much impossible to refactor, or even maintain.
The pros and cons of the "standard" languages are sort of well known. Let me summarize them quickly; again, this is not intending to start a pointless discussion, and I do not claim to be unbiased, just setting the tables to actually ask what I want to ask about.
• C++. Pros: The code would be effective, and, if the team is strong and C++-focused, the code would be maintainable, and relatively error-free. Cons: You pretty much have to be a C++ company, or, at least, you need to have a task that is so niche and so performance-critical, that it's okay for this particular piece to be done in C++.
• Java and other JVM languages, most notably Kotlin. Pros: Easy to find people who speak the language. Cons: I personally am terrified by a) code bloat, b) garbage collection that kills latency at high percentiles, and c) slow warm-ups, so that autoscaling becomes a pain in and of itself.
• C# and the .NET family. Pros: About the same as Java, plus, personally, I'm more comfortable with .NET runtime vs. the JVM one, even on Linux. Cons: Same as with JVM.
Now, the question. In the setup above, how should one gauge Rust and Golang?
My view is rather straightforward so far.
• Rust: Still young. Unclear if it delivers enough to win over C++; i.e., even if support- and refactoring-wise it turns out to be better than C++ for "simple" services in the long run, Rust people are still rather difficult to find.
• Golang. Here, I'm on the fence. There's a large crowd of people who would argue Go is unfit for large projects, mostly due to lack of proper type safety. There's also a large crowd of people who would argue Go is quite efficient for its simple syntax.
Ultimately, my question then is: should Go be taken seriously in 2023?
Is it worth my time to learn it and [help] build a production service in it?
Or would this knowledge be rather useless, given I speak C++ well, and for "simple" low-latency high-throughput gRPC services, it likely is and will remain a better choice?
If the latter is true, I should not really invest much into Golang, and wait for an opportune moment to educate myself on Rust. If the former is true, an opportune moment is now.
Advice welcome -- and many thanks in advance!
In the meantime, we've recorded another educational interview episode, thanks Jos!
YouTube
Eight Queens Problem
Dima and Jos do Mock Interviews Episode 1
Folks, any experience with the "best practice" of different `USER`s in Docker?
Via this link -- https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user -- the recommended way is:
I struggle to understand:
a) Why change the user at all? Isn't Docker secure enough so that "just" using the default, "root", user is good enough for most intents and purposes?
b) If some service would rather not be run as root -- which I admire -- why not build everything from under root from an
c) Why would the Docker team build this feature in such a way that works very differently on Linux and on macOS, so that cross-religion dev teams have to struggle?
d) On a related note, why doesn't the Linux binary of Docker offer the
Edit: To clarify,
Edit 2, via @Komzpa:
Via this link -- https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user -- the recommended way is:
RUN groupadd -r postgres && useradd --no-log-init -r -g postgres postgres
I struggle to understand:
a) Why change the user at all? Isn't Docker secure enough so that "just" using the default, "root", user is good enough for most intents and purposes?
b) If some service would rather not be run as root -- which I admire -- why not build everything from under root from an
AS builder
container, and then only change the user into some app
from within the latest, runner
, container?c) Why would the Docker team build this feature in such a way that works very differently on Linux and on macOS, so that cross-religion dev teams have to struggle?
d) On a related note, why doesn't the Linux binary of Docker offer the
host.network.internal
hostname by default?Edit: To clarify,
postgres
is actually a great example of an application that I believe should be run from under its own user! But when it comes to building & running custom Golang apps, for instance, my original question holds.Edit 2, via @Komzpa:
root
is not safe because root is really something like if (!uid) {} i
n many paths in kernel. if you manage to create a device file in your namespace you can remount it and there's nothing you can do about it as you're root. All the security enclosures only work if you're not root, there's no "root of this namespace".Docker Documentation
Building best practices
Hints, tips and guidelines for writing clean, reliable Dockerfiles
"Dima, I worked in many companies that were at risk of downsizing and/or closing down. The lesson I thus learned early on is to open source more, sooner."