How do you develop for it though? Do you install it locally as well? Or do you only do interpreted languages and/or Java? I suppose Go would work across distros also (because it doesn't use libc), but that's all I can think of.
You should just develop your apps in/with/for containers. The container contains all the dependencies for your app. This way you never have to think about the host OS ever again; your app "just works" (once you hook up the networking, environment, secrets, storage, logging, etc for whatever is running your container). That sounds like a lot of extra work, but actually it's just standardizing the things you should already be dealing with even if you didn't use containers. The end result is your app works more reliably and you can run it anywhere.
Some of us are systems/infrastructure engineers who have to build the intermediate layer. You can't just lay a dockerfile on top of a kernel and hope the system learns how to run it by osmosis.
Yes there are services like Fargate but they're not cost efficient for many cases.
The person was asking how they should develop their app to run on a particular host. If they need to run/deploy it, they can use the EC2 Instance Launch Wizard to set everything up in the console, log in and install Docker, use Docker.com to pull their container, and then run it.
Or, like you suggest, they could use an AWS service to manage their container, like App Runner, or Lightsail, or EKS, EKS Fargate, EKS Anywhere, ECS, ECS Fargate, ECS Anywhere, ROSA, Greengrass, App2Container, Elastic Beanstalk, or Lambda. There are plenty of guides on AWS's website on how to use them.
Cost is mostly irrelevant to the conversation, as you can run containers anywhere (other than, say, a CloudFlare worker); pay for any infrastructure you want and then run the container there.
This is true, but people focusing on only these benefits often miss the fact that they still have to update the image contents and re-deploy as soon as security patches are available.
This is like updating the direct dependencies of your service itself (e.g. cargo audit -> cargo update) but anecdotally I'm seeing many people neglect the image and sometimes even pin specific versions and miss potential updates even when they do later rebuild it.
We take unattended upgrades for granted on Debian-based servers, and that will likely help the Docker host system, but I'm not aware of anything nearly as automated for rebuilding and redeploying the images themselves.
It could be part of your CI/CD pipeline but that in itself is a lot of extra setup and must not be neglected, and it must make sense, e.g. pin in a way that will still pick up security patches and have a dependency audit as part of CI/CD to report when the patching hasn't been enough (e.g. due to semver constraints).
Docker's website has pretty sweet automation that you can use to re-build your containers automatically when the base image changes.
What you describe isn't hard to achieve. Write a one-line cron job that gets the latest packages for your container's base, writes them to a file, commits it to Git, and pushes it. Then set up a Git webhook that runs a script you have to build your container with a new version and push that to a dev instance. Add some tests, and you have an entire CI/CD process with just one cron job and one Git webhook.
Why? I develop C++ servers for Linux. I have script that can build production server from nothing with all the dependencies needed, deploy database and then pull down source build executable run tests and install it as a daemon. I test if from scratch every once in a while just in case and did not have any troubles for years.
> you never have to think about the host OS ever again
This is literally one of the only things that is not included in a container image. The Linux kernel is the Operating System and you are subject to differences in its configuration depending on where the container is running. You are referring to the distribution.
> You should just develop your apps in/with/for containers. The container contains all the dependencies for your app. This way you never have to think about the host OS ever again; your app "just works" (once you hook up the networking, environment, secrets, storage, logging, etc for whatever is running your container). That sounds like a lot of extra work, but actually it's just standardizing the things you should already be dealing with even if you didn't use containers. The end result is your app works more reliably and you can run it anywhere.
This is a false sense of reproducibility. I encountered cases where container worked well on one machine and crashed or had weird bugs on another one.
This happens, but is pretty rare. Using containers generally leads to much more reliable portability than trying to manage all the dependencies by hand.
If I remember correctly Go does use libc by default if you link with net package (you can set CGO_ENABLED=0 to disable it but then you won’t get NSS). On openbsd it also switched back to using libc
He can be "exceptionally clear" and still biased in favor of TMSC.
> It is impossible with respect to current cost structure
Well, we'll have to pay a few cents (or dollars) more per chip then. It is infeasible for us to continue to depend on TMSC in the long term - it will be taken over by our largest geopolitical adversary by 2030 at the latest. We do not have a choice but to either on-shore, or shift production to countries with far less geopolitical risk.
On the other hand, from the perspective of TSMC, if production does not get transferred to USA mainland, then it secures the future of TSMC because in that case USA will ensure that they do not get taken over by a geopolitical adversary in the coming decade. Geopolitical risk is not something external that exists in isolation; the location of semiconductor manufacturing is a big factor that shapes the geopolitical risk by shaping the interests of key players. If USA can afford to walk away, Taiwan is at large geopolitical risk; but as long as their interests are tied together, then the risk to Taiwan is greatly limited.
If the push comes to shove, a US carrier group parked in Taiwan's territorial waters makes any sea invasion impossible if it's willing to shoot at Chinese ships; you can't ship and land a million soldiers across a hostile sea, and China can't (at the moment) win the sea battle.
It's debatable to what extent USA is willing to fight for that, but if it chooses to do so, then now and at least until 2030 USA has enough military might to enforce a stalemate/status quo across the Taiwan strait, no matter how much it gets escalated. China can force Kinmen and Matsu islands, but invading Taiwan proper requires either USA not joining the war or a stronger China.
So IMHO the fate of Taiwan in this century depends on how much USA will be willing to intervene to protect it; and the physical location of semiconductor factories is a big factor influencing that willingness.
If a carrier is willing to shoot at Chinese ships and close enough to reliably do so, then the Chinese are willing to shoot at it and are close enough to reliably do so.
Chinese antiship weapons are significantly better than the US. Without immediately inducing Kessler syndrome and still being very lucky, I don't see how a US carrier is going to survive two dozen DF-21 missiles simultaneously, a couple hundred supersonic cruise missiles, and whatever submarines or UUVs the Chinese have got lurking there.
The US fleets most advanced weapon, SM-6, still can't reliably intercept MRBMs or SRBMs(https://www.defensedaily.com/mda-conducts-sm-6-missile-raid-..., https://www.reuters.com/business/aerospace-defense/us-fails-...) and has never intercepted a single IRBM. I struggle to see how it can possibly defend against dozens of IRBMs with advanced countermeasures that aren't on a predefined trajectory if it can't even hit a single one with no countermeasures. And by the way, they're building over 100 missiles a year. They could realistically have 1000 antiship IRBMs in a few year - more antiship IRBMs alone than the combined amount of interceptors of all carriers the US could hope to deploy within 8000km of Taiwan.
Right now the best the US can do is try to jam the missiles and deploy smoke, and hope they miss, which they probably won't.
A US carrier group in Taiwan's territorial waters is 100% getting absolutely wiped. The US will never risk getting their carriers that close to Chinese weapons, they'll stay thousands of kilometers away and hope for the best.
The US's best hope is to keep its assets far away from the theater and cooperate with Taiwan to try to whittle away the Chinese fleet and prevent them from setting up a beachhead, and hope the Chinese air defences, low-frequency radars, and signals intelligence platforms can't stop the counterattack.
The Chinese also won't need a million soldiers. They just need to get a few dozen thousand on the shores with air superiority and disable the Taiwanese military then take as much time as they want pacifying the island.
In a full scale conflict, carrier group would be sunk by subs in the first 15 minutes. Those carrier groups are a relic of the past that only works against unsophisticated adversaries who do not have the largest submarine fleet in the world [1] or nukes. US military planners know this so any such things will be withdrawn shortly before shit is about to go down, or (more likely) never brought in in the first place. And it doubly does not work against adversaries without whom we can't even build anything because we outsourced all of our production there. In 2 years we couldn't even scale the production of N95 face masks on US soil, let alone anything more complicated. The colossus has legs of clay and US government (and its owner - the US business establishment) is to blame.
Prediction: Taiwan will be retaken by China by 2030 and the US will do bupkis about it other than saber rattling. It can't even do sanctions, since that'd be sort of like US imposing sanctions on its own manufacturing base. Xi knows this. He will use our weakness to his advantage. It would seem that business establishments are already acknowledging this, hence this massive investment in the US. On the other hand, this is also forcing China's hand - they can't afford to wait until it becomes feasible for the US to impose effective sanctions. Their colossus too has legs of clay. Except the legs are not as weak.
The US has no hope to even possibly defend surface naval assets in the Taiwan strait or its periphery. A carrier strike group literally doesn't have as many interceptors as the Chinese could fire missiles at them from that distance.
The US will have to leave the Taiwan strait waters to China and attempt to strike as many Chinese boats there as they can from a distance in the air.
Because the US has been ruled by incompetent and corrupt imbeciles since the 70s. And there's now a second generation of incompetent imbeciles in the government who were students back then. If you think they can avert, let alone win this, you're out of your mind. Our best play here is to not intervene on another country's behalf seeing how we couldn't win against a bunch of semi-literate cave dwellers with Kalashnikovs after 20 years and 2 trillion dollars. War against today's China would be unwinnable in _any_ shape or form whatsoever under any circumstances even if we had competent leadership, which is something we do not have, and haven't seen in 50 years.
Watch the YT video linked in the article. China is in the position of strength now. They're on an upward trajectory. We're on a steep downward one. And that won't change until we at least acknowledge the realities of our present predicament, and begin the serious, careful work to rectify it. I see no signs of that even being possible the way things are right now, let alone likely.
I suppose "ensure" is too definite of a claim. But it's clear that the US can apply all types of pressure to try to hinder a takeover of TSMC/Taiwan. Methods range from open negotiations, to trade/economics sanctions, etc.
>He can be "exceptionally clear" and still biased in favor of TMSC.
Probably. But It wasn't that TSMC doesn't want to move, he made it clear the maths doesn't work out. Giga Fabs operate at scale and efficiency is precisely why you could make a $30 M1 Die.
>Well, we'll have to pay a few cents (or dollars) more per chip then.
That is easier for mature node. But most of the time we are not talking about mature node but leading edge.
If the maths were a few cents or even a few dollar things would have been done already. In US, for TSMC having the same margin would probably put M1 close to $50, while having higher initial R&D cost, meaning more volume to amortise the cost, or higher final retail price depending on sector.
So Morris's question to TSMC's client, are you willing to pay 50% to double for US made silicon. As far as all major US players, that is Qualcomm, Nvidia, AMD and Apple. The answer has been a simple no. They want it cheaper! ( Looking at Nvidia's constantly moaning )
Of course there is another path, forcing TSMC to operate in US while lowering their Net Profit margin. Which is likely what is happening here. The only good thing is that US is finally understanding the risk of its supply chain. For some people like me who has been crying about it for nearly a decade.
OK, then we'll pay $20 more for a $3K laptop. Hardly a tragedy. Same with labor by the way. If Apple made phones here and charged $20-30 more per unit, their user base wouldn't even blink.
For a $3K Laptop you are looking at M1 Pro or M1 Max, those would cost at least $50 to $100 more BOM cost. Excluding other factor. That translate to roughly $125 to $250 retail price increase at the same margin.
For a labour of $20 to $30 increase per iPhone unit, would equate retail price increase of $50 to $75. Excluding other factors. Not to mention I seriously doubt labour would be an increase of only $20-30 per unit. The different in cost / productivity is likely higher than 3x.
There's not a whole hour of labor in each iPhone. Not even close. Humans just put together robot-assembled boards, screens, and so on. If this is re-shored, it wouldn't be that difficult for Apple to reduce manual labor even further than that, possibly to near zero. I've tried to repair an iPhone PCB once where an SMD resistor fell off. I couldn't do it, even though I have a hot air workstation and a bench microscope. Humans can't work on SMD components you can't even see without magnification.
And I'd like to understand how it is that an M1 Pro die, which is manufactured _solely_ by robots, and can't even use human labor would cost $100 per unit more here than anywhere else in the world. Heck the chip itself likely costs less than that to manufacture (do remember that we're excluding the design cost, which is the same).
This is quite literally the case of big businesses selling their (for some tenuous definition of "their" - they don't much care where they are situated as long as they have access to US market) country out for a buck.
> an M1 Pro die, which is manufactured _solely_ by robots, and can't even use human labor
I was not aware that there were no employees in modern chip fabs. They must require some sort of maintenance cycle, how often do humans come to modern chip fabs?
"Maintenance" won't add $100 per die like GP is suggesting. There are hundreds of dies per wafer, and thousands of wafers within maintenance interval. We're talking a very small incremental cost. And it too could be reduced to account for more expensive labor.
I'd like to pose a better question: why do you voluntarily carry water for Apple? If you are in the US (or in one of its allied countries), on-shoring advanced semiconductors, and other types of advanced manufacturing is 100% beneficial to you no matter from which perspective you consider it.
MBA programs do not produce "business leaders", except by accident. They produce business _administrators_, which is a different thing entirely, and often the opposite that of a leader. People often confuse management with leadership, and while a manager can be a leader, the two are rarely the same.
People often react with incredulity about FAANG comp, while forgetting that the company makes several times as much per employee as mean comp package (2/3rds of which isn't even cash). All of that value is generated by employees. Is this a fair split? I suppose we'll find out soon. Someone has to blink, and then everyone will blink. Google did blink circa 2011, and raised its (until then) fairly modest comp something like 30%.
I think a cool and "googly" thing for Google to try would be to do what one of the companies in the article did: reduce the work week to 4 days while keeping the same pay. All tech companies should do that. Working the same hours as factory workers did 100 years ago is absurd given the productivity improvements in the interim.
That's exactly how the market works, in the absence of collusion. Which has been demonstrated several times among big tech behemoths [1]. That is also how it'll work this time, assuming there is no collusion, which there may still be.
No it isn't. Without collusion the market rate is determined by the supply and demand of and for employees. This has nothing to do with the value created.
I agree with your second sentence, but disagree with your third. The demand for SWE (or any other kind of labor) is itself some (often complex) function of value created.
If you employ N software engineers and an infallible oracle told you that you’d create more value if you hired 2 more, you’d try to hire 2 more. If the oracle told you you’d create more value with 2 fewer, you’d try to get to N-2, making your demand for SWE labor a function of value created.
The market is nothing but the sum of all the actors in the market. If the value created by SWEs doubled (even if only for 10% of participants), the market equilibrium would be higher because of the increased demand for SWEs. If it was instead cut in half (even for only 10% of participants), the market equilibrium would be lower due to decreased demand.
I can’t see any reasonable way that the market for SWEs “has nothing to do” with the value created by them.
Fauci is the highest-paid US government employee. That's even ignoring the fact that he will make tens of millions of dollars after he ceases to be a government employee. The previous head of the FDA, Gottlieb is with Pfizer already. The guy who replaced him, Stephen Hahn, is with Moderna now. I find it bizzarre how people instantly forgot how profoundly evil US Big Pharma was considered even a couple of years ago. These people will let diabetics die for a buck, and yet I'm now supposed to treat them as the second coming of Jesus, and pretend they can do no wrong.
And I can guarantee you Daszak and a bunch of other hangers on make a lot more than "20K". In fact 20K might not be enough to get him out of bed in the morning.
> Fauci is the highest-paid US government employee.
...And? What's your point?
As a Chief Medical Officer at a pharma company, which he more than qualifies for, he's be making 10+ million/year. E.g., darryl sleep, the CMO of Amgen, made $20 million last year. You make this point yourself.
So Fauci is greedy because he.... didn't sell out? This take is so astoundingly ignorant that it's hard to believe it's made in good faith.
My point is, until we ban the immediate popping up of these figureheads on Big Pharma boards (something Trump tried and failed to do, and Biden won't even try), there's a massive conflict of interest, and everything they say and do should be regarded with a lot of suspicion. Pay them twice as much,
but then say "you can't take money from the companies you're charged with regulating, directly or otherwise, for 5 years or you go to jail". The situation we have right now is just dumb and corrupt AF across the board. Fauci generated somewhere near half a trillion dollars of revenue for Pfizer just on COVID alone, and there's nothing whatsoever in US law preventing him from collecting a de-facto deferred bribe after he leaves NIAID. Happens to every single one of these figureheads, without any exceptions. I strongly suspect that's why they take these relatively unexciting jobs in the first place - for the potential to earn something more "exciting" that they wouldn't be able to get otherwise.
If you think they have your interests in mind, I suggest you reconsider. At best, your interests might sometimes align with those of their true masters. But if they don't, who gives a shit - Pfizer has legal immunity now.
I largely agree that moving between gov't and private sector should be illegal or at least highly constrained, particularly in leadership or decision-making positions. But I also think you're unserious and insincere.
> Pay them twice as much, but then say "you can't take money from the companies you're charged with regulating, directly or otherwise, for 5 years or you go to jail"... Happens to every single one of these figureheads, without any exceptions.
You know how I can tell you're an unserious? You're criticizing Fauci for doing exactly what you want -- staying a well-but-not-unfairly-paid civil servant for his entire career. If Fauci was going to cash out, he could have done so decades ago. He's been at the top for a long time.
Which, BTW, is FAR more common than not. The people you're describing are not the median or normal outcome.
I don't think you have thought seriously about your criticism here, and I don't think you're commenting on this issue in good faith.
> customers affected by the outage _may have_ encountered 404 errors
> for the inconvenience this service outage _may have_ caused
Not a fan of this language guys/gals. You've done a doo-doo, and you know exactly what percentage (if not how many exactly) of the requests were 404s and for which customers. Why the weasel language? Own it.
Someone in a tech role wrote something like "because of the limitations of XYZ system we can't get a crisp measurement of the number of 404 errors customers experienced", failed to add a ballpark estimate because they thought everyone was on the same page about severity, and someone polishing the language saw and interpreted as "I mean, who can really say whether there were 404s?"
And the latter one would have been originally written as something more normal, then someone else read it and objected, "Most customers were outside of the blast impact!" (or somesuch) so then because the purpose of the post was informational to all customers, instead of scoping the apology to the customers who were impacted they came up with that language.
Committee communications are a painful mess, and the more important everyone thinks an issue is the more likely they are to mangle it.
Linus was also nearly driven out by "activists". Best I can tell he never actually said or did anything egregious - his European directness and sense of humor just upset some particularly fragile folks on the mailing list, and so did his refusal to grovel before them.
That said burntsushi at least doesn't seem like an activist to me, so the grievances are probably legitimate. Coming from someone less prominent they'd not have anywhere near the same weight in my eyes. We just don't know what they are.
I remember a person from current Rust's core team cheering when that person thought Linus is getting ousted from the project.
I take Linux organizational model over Rust's every day. A group of super competent people with no bullshit policy. It is proven. The problem is how to form the successor to the dictator.
