The headline is dramatic but this is literally how bitcoin is designed to work. Miners leave, difficulty drops, costs go down, mining becomes profitable again. The interesting part isn’t the loss per coin, it’s how long the lag between unprofitable mining and difficulty adjustment keeps forced selling pressure on the market.
It sounds very similar to things like oil production, gold mining, and even farming. When the price is high, everyone wants in on the action. As supply explodes, the prices drop. Once prices get low enough, the costs to pump the next barrel of oil, find the next ounce of gold, or harvest the next acre of a certain crop; exceed the reward. When that happens, wells are shut down, mining operations suspended, and different crops planted. The cycle begins again.
There's a soft failure-mode for bitcoin where due to the alternating difficulty adjustment, you could end up with people only mining every other 2016-block adjustment.
Let's call this cycle A and cycle B.
If A is too hard, miners drop out, cycle B gets easier, miners flood back, cycle A gets harder.
This results in the hard cycle getting longer and the easy cycle getting shorter.
This isn't completely critical as there is I believe a small damping effect, so it isn't completely lethal to bitcoin, but a key thing about bitcoin mining is that whether other people are mining or not doesn't actually affect your own profitiability.
Other people dropping out doesn't actually mean you get more bitcoins per hour/watt, it only affects the next difficulty adjustment as a secondary effect.
The damping effect is that part of your costs are the hardware, space, depreciation etc. leaving that stuff idle costs money - so it makes sense to mine in the less profitable periods too.
That depends on each miner's energy costs, so long as (variable cost of energy - revenue from coins) < fixed costs. It's still negative cashflow either way, but the monthly losses have to be weighed against the cost of going insolvent and losing the hardware.
Crypto-miners are switching to AI token farming when bitcoin is low. They have compute that's both installed and powered, so why not do what pays better?
Training ASICs (like Google’s TPUs) can generally run inference too, since inference is a subset of training computations. TPUs are widely used for both.
Mining ASICs (Bitcoin, etc.) cannot be repurposed…they’re hardwired for a single hash algorithm and lack matrix math needed for neural networks.
The difficulty can only adjust by a factor of 4 which also limits the incentive change. You'd need more than 90% of miners to disappear to start seeing actual problems.
I think you're right, it's counterintuitive but less competition means less rewards to share for those who keep mining. Though transaction fees / hour shouldn't decrease, maybe your share of that is bigger.
It's the other way around, and there's no obligation to even carry transactions when mining, although it's incentivised through fees.
Your mining rate is simply your hash rate vs the hash difficulty.
Conceptually, it's analoglous to rolling random numbers in (0,1) until you get to a number smaller than 1/X, where X is large.
How long it takes you to do that, isn't dependent on how many other people are also trying to do that, if you get 1 hit per hour, then lots of other people getting hits doesn't actually stop you getting your 1 hit per hour.
Now, that's not quite the whole truth, as there's a small amount of time needed for propagation of the previous chain, but with an average hit globally of ~10 minutes, that's not actually a big factor.
What could happen to incentivise people is increased fees if blocks get less common due to dropped miners, there'd be more competition to get into blocks if they start filling up.
That combined with the fixed costs such as depreciation as othes mentioned, keeps the risk of this form of failure to a minimum.
The Lightning Network is specifically designed to work around bitcoin design flaws. It entirely sidesteps the chain for a big part of the process. To me it proves that Satoshi did not, in fact, think of everything. Not the other way around.
> it takes less than one second to go through
Like Bitcoin used to be before someone had the brilliant idea of destroy the possibility of zero-confirmation transactions on-chain with Replace-by-fee transactions
One is a quick summary of the current balance in a channel. A new transaction is created each time the balance in the channel changes. It's somewhat cheap to put on the blockchain (And the main saving is that you only need to post the final update when you close the channel), but venerable to one side putting an old stale transaction onto the blockchain to profit.
The other transaction forms a chain of proof for current state, invalidating previous balance update transactions. It's somewhat expensive to post, as it will pull in the whole history.
Both peers need to continually watch the chain (or contract a 3rd party to watch) to make sure the other peer isn't cheating by posted a stale balance transaction. These special transactions are time locked, so once one is posted, you have like 24 hours to post the proof transaction and reverse it.
Lightning has mostly done this by being a lot more centralized in practice and one could argue... What's the point of it all in this case? Why not just use regular currency?
Sorry, I do not understand your comment. Can you clarify. What does "a lot more centralized in practice" mean?
> What's the point of it all in this case?
Lightning is an L2 protocol, highly scalable and used for low cost payment in Bitcoin. Level 1 networks are almost never used for user transactions: your credit card payments do not go over fedwire, etc. Bitcoin protocol is not scalable to serve worldwide money transfer needs; Lightning is. And with the cost of a penny per transaction or so.
> Why not just use regular currency?
There are a lot of frictions in the current banking systems, because money laundering, because drugs, because whatever. Getting $5-$10k in regular currency while on an overseas trip can be a major quest. With Lightning I can transfer that much (or more) in a few mouse clicks.
As a side note, I think the federales are already way too nosy regarding my use of my own money, so I want to give alternative options as much business as I can. My 2c.
Isn't it hard to use in practice? Liveness, inbound liquidity, moving funds between L1 and L2, don't all of those lead to massive use of hubs, this denying the entire premise of decentralization?
Very easy. If the merchant supports it, it is extremely easy; equivalent to pointing your phone at a reader to pay with GooglePay. Between people -- a QR or similar.
> Except people wanting to do more than 15 transactions a minute
It's more like 7 transactions per second, which is still absolute crap, but that was after the original Bitcoin project was kidnapped. There aren't such limitations in the original Bitcoin (forked as Bitcoin Cash)
> Or that to scale everyone would need to store a petabyte size blockchain
That is addressed in the whitepaper (SPVs and pruning)
Except for the inevitable and obvious fact that proof-of-work creates a self-sustaining primary incentive for energy waste more pernicious than has ever been seen in any other financial or commercial enterprise, obliterating any hope of having energy that is too cheap to meter.
Mining Bitcoin requires both hardware and electricity, and the cheapest electricity is solar. There isn't any severe scarcity of the raw materials to make solar panels, or of sunlight, so Bitcoin miners can buy as many solar panels as they want and it would only increase the economies of scale for producing them for other purposes too.
Solar has inconsistent output. There is none at night and it varies based on weather during the day. Mining hardware wants a fixed constant amount of power. The logical thing for miners to do is to somewhat overbuild the amount of generation they need and then sell any surplus to the grid, and sell to the grid during the day and buy it back at night. The same incentives hold if the miners and the generators are two different parties, and the result is to increase the amount of generation capacity by more than the amount of consumption and have "too cheap to meter" during periods of above-average generation. (You were never going to get "too cheap to meter" during periods when generation is low and demand is high.) And even during short periods when demand significantly outstrips supply, then their incentive is to stop operating those few days out of the year because the spot price of electricity makes mining unprofitable then, which allows the generation capacity installed to do mining be used to support the rest of the grid and inhibits the price of electricity from rising above the point where mining becomes unprofitable even for people who already have mining hardware. It's basically a buffer that buys electricity when it's cheap and sells when it's expensive.
Bitcoin has a volatile price. When the price is high, miners buy hardware and increase or pay someone else to increase generation capacity. When the price declines, the mining hardware becomes idle but the power generation capacity still generates fungible electricity that can be used for any other purpose. The result is that miners pay to install a lot of generation capacity during the boom, and have the incentive to prioritize investing in more generation rather than newer/more efficient mining hardware because it's the thing that's still worth something if the price declines, and that generation capacity then gets offloaded into the grid during the bust, with the result that grid prices go up some during the boom and down by even more during the bust. By the next boom some of the generation added last time has already been sold to non-miners or locked into long-term contracts so now they're back to adding new capacity again.
"Incentive to fund increases in generation capacity but then not use all of it" has what effect on average prices?
You're making a lot of highly idealized assumptions that don't hold true in reality.
Most significantly that the increased demand due to mining will result in grid operators investing in proportional new capacity to offset it over a reasonable time scale. Instead of just driving up prices due to basic supply/demand.
Also that miners are only consuming electricity when renewables dominate the mix. Otherwise they're responsible for more CO2 emissions to do something useless.
Plus in markets like Texas, miners also manage to get subsidies intended for actually useful customers like factories to go offline at peak times. So ratepayers are essentially paying protection money so they won't over stress the grid by performing their useless work.
In a world where bitcoin miners had to install new solar capacity to entirely offset their peak usage and sell back to the grid any excess then sure, seems like that wouldn't be a big societal net negative like it is right now.
Or we could use all that "free solar energy" to benefit humanity through a million other more useful endeavors. Such as developing and deploying batteries.
One thing we do not lack is demand for more energy.
> Or we could use all that "free solar energy" to benefit humanity through a million other more useful endeavors.
Please tell me where I can get unlimited solar panels for free. I'll rent a truck and be there straight away.
> One thing we do not lack is demand for more energy.
Market demand is the willingness and ability to pay money for something. If the demand was actually unlimited then why isn't there either a Dyson sphere around the sun already or a 0% unemployment rate from everyone having a job building one?
Now compare it to the annual energy use for the creation/printing of money and funding of infinite wars due to the Federal Reserve having the ability to print money out of thin air at the cost of future generations.
The difference is that the quantity of what is being supplied is a factor with supply of oil/gold/grain/etc.
For mining it is just necessary that it happens.
The amount of work in mining is way higher than is required to prevent another party from being able to overwhelm the Blockchain. It is that high because of the subsidy of the mining reward means if Bitcoin has a high value the reward is worth a lot.
This is factored in with the halving of the reward. Either the price will increase exponentially or the mining reward will drop. Causing mining to reduce to those who can be profitable from fees. Which rewards those who can mine most efficiently, it becomes a supply and demand calculation in a market where there are relatively low barriers for competitors.
> The amount of work in mining is way higher than is required to prevent another party from being able to overwhelm the Blockchain.
Isn’t that exactly the point? Bitcoin incentivized wasting resources. It is, according to your own comment, unnecessary to use so much computing to keep bitcoin going. But it’s being used.
If Bitcoin were worth much less the network would still be secure even though the mining reward would only be enough to pay for a fraction of the current processing.
If Bitcoin does not double in value every four years, the mining reward will reduce in real world terms.
Claiming the mining resources required will be at the current level or higher perpetually requires also making the claim that you think that the value will increase exponentially forever.
There is an interesting missing link in the feedback cycle with Bitcoin though - the same amount is produced regardless, supply does not contract with demand.
The headline is confusing the issue. Bitcoin miners are losing money because October's crash took Bitcoin from $126,000 to below $70,000, and the Iran war has pushed up oil and electricity prices. The minor difficulty drop is a result of that, as some Bitcoin miners drop out. It's not the cause.
It is how bitcoin is designed to work, but it also shows very directly how proof-of-work systems can never scale to be the global monetary replacement its boosters push. If the opposite happened, and the price for some reason sky rocketed to, say, $1 million per bitcoin, it would necessarily mean that it would induce more miners until the difficulty and consequent electricity cost (regardless of the efficiency in electricity generation) also would rise to the neighborhood of $1 million per coin. At the point you're far beyond "Argentina levels" of electricity and getting into "Europe levels" of electricity to run the network.
The electricity demand (and here I mean the overall cost of the electricity, so improvements in $ per kilowatt just mean you need to use more electricity) in proof-of-work systems fundamentally scales linearly with the overall valuation of the coins in the network, which means proof-of-work systems can never scale as large as their fanboys would have you believe.
While I don't disagree in general, there are a couple gaps in your reasoning that weaken the argument:
Adoption doesn't necessarily correlate completely with price. Price can increase without much adoption, due to speculation. In theory, adoption could also increase without much price increase.
Electricity isn't the only requirement for mining. Hardware is also required. Miners can't simply use lots of additional electricity if the hardware isn't there. Yes, new hardware can be manufactured, but it takes time.
The block reward decreases over time. If it's using Europe levels of electricity at time X, then after a block reward decrease, it'll use Europe/2 amount of electricity. This decreasing also disincentivizes manufacturing new hardware.
Miners can have different efficiencies, due to different types of hardware, and different types of electricity generation. So while the least efficient miner will be operating at near breakeven, the most efficient miner will be making much more profit. So while the least efficient miner will use $1M of electricity to mine a $1M coin, the most efficient miner will use less dollars of electricity.
> In theory, adoption could also increase without much price increase.
Not really. A fundamental purpose for any currency is to act as a "store of value". There is no way for bitcoin to represent a store of value (i.e. value commensurate to real-world goods) for a larger and larger portion of society without the price skyrocketing, especially since Bitcoin is inherently deflationary with a max number of coins.
Regarding your other paragraphs, I think this is a fundamental misunderstanding of how proof-of-work is designed to protect the network. The entire idea behind POW is that the total amount of work must be in direct relationship to the total value of the coins in the network, or else coordinated attacks become possible. I see this misunderstanding all the time in "the block reward decreases over time" argument. It doesn't really matter if miners get their payoff from block rewards or mining fees - they must (on average, over time) get enough reward to make their mining activity worthwhile, and, again, by the inherent design of POW, they need to spend enough on mining to make 51% attacks not worth trying. Just think about how your "If it's using Europe levels of electricity at time X, then after a block reward decrease, it'll use Europe/2 amount of electricity" sentence doesn't make any sense, because eventually in 2140 or so there will be no block rewards, so according to your logic no electricity at all would be required to run the network.
There is simply no getting around the fact that resource costs need to grow linearly with the total value of the network in POW systems.
>The entire idea behind POW is that the total amount of work must be in direct relationship to the total value of the coins in the network, or else coordinated attacks become possible.
The total amount of work must be in direct relationship to the amount an attacker can gain from executing a 51% attack. It's not clear to me that if bitcoin doubles in price, an attacker can gain double the amount from a 51% attack. A 51% attack doesn't allow direct theft of other people's bitcoins. It allows double spend attacks, denial of service attacks, and through those, the ability to tank the price of bitcoin.
>Just think about how your "If it's using Europe levels of electricity at time X, then after a block reward decrease, it'll use Europe/2 amount of electricity" sentence doesn't make any sense, because eventually in 2140 or so there will be no block rewards, so according to your logic no electricity at all would be required to run the network.
It's possible for a block reward to be larger than necessary for security. In that case it can go through several halvings that purely improve efficiency without putting the network at risk. Yes, at some point, with a sufficiently large number of halvings, the network would be at risk, but that doesn't mean we can't have some efficiency gains before that happens. Your previous comment referred to bitcoin using more electricity than Argentina. That's a statement about how much electricity it's currently using, not a statement about how much electricity it needs to use to get the necessary amount of security. It might be possible to decrease the electricity usage while remaining sufficiently secure.
If "difficulty drops, costs go down" so ought the price? Isn't that basic economics? Or are they chasing the "phase difference", lag, between supply demand?
I am not certain; but, costs do not have a causative relationship to prices. Prices only go down because as the cost of production goes down, supply increases. It is a correlative relationship.
Bitcoin's supply won't increase as costs go down, unlike other assets.
> costs do not have a causative relationship to prices. Prices only go down because as the cost of production goes down, supply increases.
Um. That's a causative relationship, even if it's mediated, but it's still causative. And generally, the relationship is even more direct: the suppliers are quite reluctant to sell at the price lower than their costs unless they expect the prices go up soon enough™, so the lower boundaries for the prices exist.
As price per coin goes up, more folks will find mining profitable and invest in mining operations. Difficulty goes up until it's no longer attractive for anyone to add to the global hash rate.
As price per coin goes down, less of those operations are profitable and fewer new people will find it to be a good investment. Difficulty stays the same or goes down. Due to capital expenses, difficulty is more sticky in the downward direction than upwards.
There is of course some marginal price action in between where there is in theory selling pressure from miners when it's less profitable to mine (to fund operational expenses and debt), but I don't think it's super material to the overall market volume these days.
This only works when the difficult drop rates are below miner leaving rates.
Which in normal times, are something taken for granted, but once it does happen, the edge case collapse the entire system.
edit: the earlier language is not exact, the scenario is an exponential drop of value that results in exponential drop in miner willing to mine until this discrepancy can be resolved. i.e. the system is not protected against extreme volatility (e.g. -99% over a block cycle)
No but if more miners leave then dofficulty with drop faster right? Its modelling supply and demand curves which are a stable equilibrium in these circumstances
Might be wrong about what Aperocky is alluding to but there is an entirely theoretical edge case. The time to the next difficulty adjustment is based on the current speed of mining, and the possible change in difficulty is capped. With enough minors leaving it will drop the speed of mining/network speed/ and push out the expected time to the next difficulty adjustment.
I can't think of any realistic way this can occur given the miners that stay will (personally) be producing blocks as often, the increase in time being balanced out by being a larger proportionate of the mining rate. They don't care if they get 1% of the blocks, which average about 20 mins per block or 5% of the blocks that average 100mins per block.
Difficulty only adjusts every 2016 blocks. If the system gets out of whack enough it could slow down to a crawl for an extended period of time.
In practice it’s not much of an issue because bitcoin is not use for commerce but it’s a store of value and it some of the trades are not even on chain.
> but once it does happen, the edge case collapse the entire system.
Which is when exactly, and how likely is that to happen? It hasn't happened yet in ~14 years, but I guess "never say never". There is a lot of money saying it won't happen very soon though.
If it happens it'll probably the result of a positive feedback loop forming: miners leaving slowing down transactions and affecting utility/faith in the system resulting in people selling, meaning more miners leaving, etc. That said, I don't know of any clear examples of this happening to any other proof of work coins: I think in general other parts of a cryptocurrency tend to fail first, it requires a particularly fast death for this kind of thing to happen.
It's also a side-effect of apocollapse of bitcoin itself; it becomes worth so little that nobody is mining means nobody will mine to a new block difficulty; but the collapse already occurred.
I don't think you know what you're talking about. If the difficulty lowers at a lower rate than miners leaving then the difficulty rate will stop dropping.
If you mean that if it reaches a certain point, the entire system will collapse, it means you don't understand the difficulty adjustment. If it's too expensive to mine, then some miners leave, which makes blocktimes be longer, but not to worry because the consequence of that it just that difficulty will go down, which means that you need less hashrate to mine (and maybe some of those miners that leave will come back because it is profitable again for them). This means that it is essentially impossible for all miners to leave at the same time; some of them stay even if at a loss, and some of them are just hobbyists that can already feed their miners with solar power (so there's really no loss for them in leaving them connected).
But mining costs are (cost of equipment+cost of electricity)/total coins mined, so can miners not end up in a situation where they need to keep mining to pay off equipment despite the individual coins being unprofitable?
The cost of finding a block goes down because it becomes less difficult.
The goal in proof of work is to find a block hash less than a given value. That value is determined by the network difficulty. The lower the value, the more difficult it is to find a block, and thus the more expensive it will be to mine.
Difficulty is adjusted once every two weeks to target an average block time of 10 minutes. If the average block time during the preceding 2 weeks is less than 10 minutes, it means that blocks were too easy to find (i.e. the difficulty was too low relative to total hash rate of the network). Conversely, if the average block time was greater than 10 minutes, the difficulty was too great.
This is how it the network has maintained a roughly 10 minute block time as the hash rate of the network has grown over the past 16 years. The difficulty (i.e. cost) of finding a block is constantly being adjusted.
As you can see on https://www.f2pool.com/coins other coins using SHA256 as PoW algorithm only amount to about 1% of Bitcoin's daily dollars of Pow Produced, so
if any nontrivial amount of hash moves there, then those will soon become unprofitable too.
Yes, but the coins with less participation require less power to compete. To make a market argument that there is an equilibrium of players across all coins, implies there are actual individuals finding opportunities and switching coins when they get out of sync.
But I mean, their bitcoins are not going away, their wallets are still there, their bitcoins also right? I thought bitcoin mining was proportionally hard to the number of already mined bitcoins, not the number of people mining?
I probably should look this up in wikipedia first.
It's a common misunderstanding that mining just gets harder and harder as time goes by and more coins are minted. It's often misreported that way. But in fact, the difficulty is dynamic and adjusts itself to keep minting at the predetermined rate regardless of the number of participants. Mining has gotten harder on long timelines, but only because more computing power has been added.
> Miners who successfully create a new block with a valid nonce can collect transaction fees from the included transactions and a fixed reward in bitcoins. To claim this reward, a special transaction called a coinbase is included in the block, with the miner as the payee. All bitcoins in existence have been created through this type of transaction. This reward is halved every 210,000 blocks until ₿21 million have been issued in total, which is expected to occur around the year 2140. Afterward, miners will only earn from transaction fees.
Difficulty and block rewards are separate things. There is no contradiction here.
Block reward stays constant, amount of work required (on average) to get a block reward is dynamic in order to make it so that total number of rewards given out over a length of time stays roughly constant.
So if too many block rewards are claimed in a given time frame, difficulty is increased to slow things down. If not enough are claimed then difficulty decreases to make it easier to get one.
I honestly don't know which part of "the difficulty being dynamic" is this hard to understand.
> The power needed to get a given amount of money doubles whenever the reward is halved.
Yes, by that moment it does.
And some miners still stop mining if mining became too unprofitable.
And the difficulty will decrease because less miners are mining.
And the power needed to get a given amount of bitcoin will decrease. (Not necessarily to the level before halving, ofc)
Or your comment was about this part of the grandparent comment:
> keep minting at the predetermined rate
?
If so, I think you misunderstood what they were trying to say (or their wording was misleading). It's a predetermined rate. Not a constant rate. It's predetermined to be halved at (roughly) certain moments. Halving happens about every four years, and pouring more power into mining won't make it happen significantly sooner or later. That's what they were trying to say.
Technically you could have negative feedback result in a system that diverges further and further from some baseline, until it eventually collapses. This is usually because the gain of the feedback signal is too high.
> The interesting part isn’t the loss per coin, it’s how long the lag between unprofitable mining and difficulty adjustment keeps forced selling pressure on the market.
I follow Bitcoin from a theoretical point of view and I find it fascinating.
Something that boggles my mind a lot is this: Bitcoin, which is somehow a bit "programmable", and Ethereum (which is definitely programmable) are basically the most correct computers on earth. Due to the consensus that needs to be reached by thousands+ of machines. Even if they're imperfect, ECC-less (for the most part), machines.
Now they may still run code with flaws: but they'll all run it exactly in the same way. If, say, a bit-flip occurs on a machine, that machine won't create a block or won't sign a transaction accepted by others. Not part of the consensus. That is wild.
Then the other thing which boggles my mind and which relates to your comment: the "selling pressure on the market" by Bitcoin miners is, no matter what they do, halved every four years. There were, 8 years ago, still 1800 Bitcoins mined per day. Today it's 450.
And in two years (we're midway before the next halving), it's going to be 225.
And Satoshi Nakamoto planned, from the very start.
Maybe it doesn't make sense (economically or from a security point of view: who's going to secure the network when there's not enough block reward anymore?).
But miners will mine 225 Bitcoins per day, not 450, in two years.
It does have an outsized environmental impact compared to other technologies people would call useless. The only thing that really tops it in terms of ire and pollution is AI, but that has far more realized applications
Its still true and shows one of many issues with bitcoin.
Based on bitcoin cryptobros, you need a certain amount of independent miners for the 'quality' of bitcoins. A bitcoin miner if its a state, can operate with a loss a lot longer if not even infinit, than the decentralized normal people (who do not exist anyway).
It also creates a lot of pressure on miners if you do not run your gpus, yuou are also at a loss, which can break the mining for everyone if too many in parallel go offline, than go olnine again because difficulty droped to much.
And if it becomes to volatile, no one wants to risk it anymore
Bitcoin hasn't been viably mineable on GPUs for over ten years. It requires specialized hardware.
As such, mining is typically restricted to those with massive capital investment in a single-purpose, so you really won't see random offloading and onloading of that capacity. As long as it's marginally profitable (with capital investment being a sunk cost, this is the price where it's more than ongoing costs), those miners will keep their machines running.
The original idea was for every single person out there to mine bitcoins on their own computers. Bitcoin screwed that up by allowing big corporations to push out the smaller players. Their big purpose built hardware increased mining difficulty to the point mere mortals need not even apply. Mining on GPUs? Nope, you need purpose built ASICs for this.
Monero is the only cryptocurrency today that's at least trying to implement the original "one CPU, one vote" vision but nobody really cares about it since number doesn't go up.
The quote from the CMU guy about modern Agile and DevOps approaches challenging architectural discipline is a nice way of saying most of us have completely forgotten how to build deterministic systems. Time-triggered Ethernet with strict frame scheduling feels like it's from a parallel universe compared to how we ship software now.
During the time of the first Apollo missions, a dominant portion of computing research was funded by the defense department and related arms of government, making this type of deterministic and WCET (worst case execution time) a dominant computing paradigm. Now that we have a huge free market for things like online shopping and social media, this is a bit of a neglected field and suffers from poor investment and mindshare, but I think it's still a fascinating field with some really interesting algorithms -- check out the work of Frank Mueller or Johann Blieberger.
It still lives on as a bit of a hard skill in automotive/robotics. As someone who crosses the divide between enterprise web software, and hacking about with embedded automotive bits, I don't really lament that we're not using WCET and Real Time OSes in web applications!
I suppose that rough-edgeness of the RTOSes is mostly due to that mainstream neglect for them - they are specific tools for seasoned professionals whose own edges are dent into shapes well-compatible for existing RTOSes.
ever use wordstar on Z80 system with a 5 MB hard drive?
responsive. everything dealing with user interaction is fast. sure, reading a 1 MB document took time, but 'up 4 lines' was bam!.
linux ought to be this good, but the I/O subsystem slows down responsiveness. it should be possible to copy a file to a USB drive, and not impact good response from typing, but it is not. real time patches used to improve it.
windows has always been terrible.
what is my point? well, i think a web stack ran under an RTOS (and sized appropriately) might be a much more pleasurable experience. Get rid of all those lags, and intermittent hangs and calls for more GB of memory.
QNX is also a good example of an RTOS that can be used as a desktop. Although an example with a lot of political and business problems.
Every single hardware subsystem adds lag. Double buffering adds a frame of lag; some do triple-buffering. USB adds ~8ms worse-case. LCD TVs add their own multi-frame lag-inducing processing, but even the ones that don't have to load the entire frame before any of it shows, which can be a substantial fraction of the time between frames.
Those old systems were "racing the beam", generating every pixel as it was being displayed. Minimum lag was microseconds. With LCDs you can't get under milliseconds. Luckily human visual perception isn't /that/ great so single-digit milliseconds could be as instantaneous, if you run at 100 Hz without double-buffering (is that even possible anymore!?) and use a low-latency keyboard (IIRC you can schedule more frequent USB frames at higher speeds) and only debounce on key release.
8khz polling rate mouse and keyboard, 240hz 4K monitor (with Oled to reduce smearing preferably, or it becomes very noticeable), 360hz 1440p, or 480hz 1080p, is current state of the art. You need a decent processor and GPU (especially the high refresh rate monitors as you’re pushing a huge amount data to your display, as only the newest GPUs support the newest display port standard) to run all this, but my Windows desktop is a joy to use because of all of this. Everything is super snappy. Alternatively, buying an iPad Pro is another excellent way to get very low latencies out of the box.
That's a good one. I probably should have brought up variance though. These cache-less systems had none. Windows might just decide to index a bunch of stuff and trash your cache, and it runs slow for a bit while loading gigabytes of crap back into memory. When I flip my lightswitch, it's always (perceptibly) the same amount of time until the light comes on. Click a button on the screen? Uh...
I believe this is kind of survivor-bias. It's very rare that RTOSes have to handle allocating GBs of data, or creating thousands of processes. I think if current RTOSes run the same application, there would be no noticeable difference compared to mainstream OS(Could be even worse because the OS is not designed for that kind of usecases)
>what is my point? well, i think a web stack ran under an RTOS (and sized appropriately) might be a much more pleasurable experience. Get rid of all those lags, and intermittent hangs and calls for more GB of memory.
... it's not the OS that's source of majority of lag
Click around in this demo https://tracy.nereid.pl/
Note how basically any lag added is just some fancy animations in places and most of everything changes near instantly on user interaction (with biggest "lag" being acting on mouse key release as is tradition, not click, for some stuff like buttons).
This is still just browser, but running code and displaying it directly instead of going thru all the JS and DOM mess
I didn't experience that but the commercial stuff I worked on was in a heavy industry on J1939, and our bus was isolated from the vehicle to some regard.
Then the stuff I mess with at home is 90s era CAN and it's basically all diagnostics, actually I think these particular cars don't do any control over the bus.
I’ve working in automotive since it was only wires and never saw that (or noticed it) happening specially since usually body and powertrain work on separate buses tied through a gateway, the crazy stuff happens when people start treating the bus (specially the higher speed ones) like a 12v line or worst.
> making this type of deterministic and WCET (worst case execution time) a dominant computing paradigm.
Oh wow, really? I never knew that. huh.
I feel like as I grow older, the more I start to appreciate history. Curse my naive younger self! (Well, to be fair, I don't know if I would've learned history like that in school...)
Contrary to propaganda from the likes of Ludwig von Mises, the free market is not some kind of optimal solution to all of our problems. And it certainly does not produce excellent software.
I can't think of a time when I've found an absolutist position useful or intelligent, in any field. Free-market absolutism is as stupid as totalitarianism. The content of economics papers does not need to be evaluated to discard an extreme position, one need merely say "there are more things in earth and heaven than are dreamed of in your philosophies"
Mises never claimed that the free market produced the most optimal solutions at a given moment. In fact Mises explicitly stated many times that the free market does indeed incur in semi-frequent self-corrections, speculations and manipulations by the agents.
What Mises proposition was - in essence - is that an autonomous market with enough agents participating in it will reach an optimal Nash equilibrium where both offer and demand are balanced. Only an external disruption (interventionism, new technologies, production methods, influx or efflux of agents in the market) can break the Nash equilibrium momentarily and that leads to either the offer or the demand being favored.
I don't know if you are being sarcastic. But no, it's not an "utopia" by any means and the free market still has many pitfalls and problems that I described. However, is the best system we have to coordinate the production, distribution and purchasing of services and goods on a mass scale.
Somehow the last sentence of your comment caught me as if there's something wrong with it. I don't thing it's wrong, but I think it should be generalised.
Free market is an approach to negotiation, analogous to ad-hoc model in computer science, as opposed to client-server model - which matches command economy. There are tons of nuances of course regarding incentives, optimal group sizes, resource constraints etc.
Free market is also like evolution - it creates thing that work. Not perfect, not best, they just work. Fitting the situation, not much else (there is always a random chance of something else).
Also there's the, often, I suppose, intentional confusion of terms. The free market of the economic theory is not an unregulated market, it's a market of infinitesimal agents with infinitesimal influence of each individual agent upon the whole market, with no out-of-market mechanisms and not even in-market interaction between agents on the same side.
As a side note, I find it sadly amusing that this reasonable discussion is only possible because it's offtopic to the thread's topic. Had the topic been more attractive to more politically and economically agitated folk, the discussion would be more radicalised, I suppose.
> Also there's the, often, I suppose, intentional confusion of terms. The free market of the economic theory is not an unregulated market, it's a market of infinitesimal agents with infinitesimal influence of each individual agent upon the whole market, with no out-of-market mechanisms and not even in-market interaction between agents on the same side.
Just to expand on this really interesting topic. That's where the common pitfall on planned economy begins. Because to some degree a free market can withstand some amount of regulation; after all, external agents trying to manipulate the market are just that, agents in the market. As long as there are other autonomous agents intervening the market will keep functioning as it was. So the bureaucrat has both the incentive and the justification to expand the intervention. In other words, his economical plan didn't work because it was not intervened enough and just if they intervene in this extra thing it will work for sure. That loop continues until the market is 100% intervened, and at that point it requires such a enormous structure of power and control that makes it difficult to fight it (clientelist networks, repressive states, etc).
Many intellectuals have this problem. They make interesting, precise statements under specific assumptions, but they get interpreted in all kinds of directions.
When they push back against certain narratives and extrapolations they usually don’t succeed, because the same mechanism applies here as well.
The only thing they can do about it, is throwing around ashtrays.
Although in this original case the image (that allegedly happened) used to criticize the philopher (Kuhn), so kind of the other side of the coin of what I said above.
It is not carrying a lot of weight. Macroeconomics are different from microeconomics. On a micro scale agents have enough weight on the system where a specific action might break a model. On a macro scale each individual agent's action carries less weight and therefore the system becomes predictable.
On a micro scale it is possible, and sometimes favorable, to intervene. On a macro scale to intervene economically becomes impossible due to the economic calculation problem. It is widely accepted in modern economics that the unit of maximum extent where economical intervention is possible is a business/company/enterprise. Or in sociological terms the maximum unit is the family. Anything broader than that and the compound effect of the economic calculation problem becomes apparent and inefficiencies accumulate. Autonomous decentralized mechanisms (like a free market) are the only solution to it, but not the most optimal.
Markets do not model that especially well. When it comes down to these situations, it's not about the rising price of food motivating producers to enter the market - it's about the people starving. During a war, no amount of money can cause more munitions to appear fast enough. Blast-resistant concrete can take weeks or months to cure, workforces take time to train. These "momentary" disruptions can swamp the whole.
Propaganda is quite a strong term to describe the works of an economist. If one wants to debate the ideas of von Mises, it'd be useful to consider the Zeitgeist at that time. Von Mises preferred free markets in contrast to the planned economy of the communists. Partly because the latter has difficulties in proper resource allocation and pricing. Note that this was decades before we had working digital computers and digital communication systems, which, at least in theory, change the feasibility of a planned economy.
Also, the last time I checked, the US government produced its goods and services using the free market. The government contractors (private enterprises) are usually tasked with building stuff, compared with the government itself in a non-free, purely planned economy (if you refer to von Mises).
I assume that you originally meant to refer to the idea that without government intervention (funding for deep R&D), the free market itself would probably not have produced things like the internet or the moon landing (or at least not within the observed time span). That is, however,a rather interesting idea.
> The government contractors (private enterprises) are usually tasked with building stuff
Ah yes, situation where the government makes a plan and then hands it to the one (1) qualified defense contractor whose facilities are build in swing states to benefit specific congressional campaigns is completely different from central planning.
There are some resemblances, which indicate that you might not have a fully functioning free market. But central planning in the context of von Mises refers to something else. It's about the organization of whole national economies, as in planned economies, a thing you find in communist states or Lenin's "war communism".
You should read up on Yanis Varoufakis' history and just how bad his solution for Greece went. That will explain the extreme amounts of anger on both his side, the side of Greeks and the side of the EU and worldwide financial community (and the EU itself used to be an industry cartel, so you can guess how much every government institution in the EU aligns with the worldwide financial community). This guy will never be allowed to do anything remotely serious in economics ever again, and he knows it very well. His Diem24 project is failing, and he knows that too. He feels the ECB, specifically Mario Draghi, Jeroen Dijsselbloem and Christine Lagarde are responsible for this downfall and talks about them in a way that makes you say "he can't be allowed near them. Seriously. Call the police". But in the constant tragedy of his life: He's probably right they caused his downfall.
(He'd kill me for saying this but he was lying back then too. He was trying to pull a Thatcher (I could compare him to someone else that did the same a long time ago but ... let's just say if you know you know). He was trying to double Greece's public debt by lying to everyone about what he was doing. He failed, and then started threatening, and when his threats didn't work, he got fired by Greece's prime minister, his oldest friend. It ended the friendship. He lost. And he's not a good enough sport to accept that he lost, frankly he got caught and couldn't talk his way out of it. This, despite the fact that he was finance minister, and so will be paid, very well I might add, for the rest of his life despite what he did, and despite the fact that every Greek today is still paying the price for what he did)
Oh and he's pro-Russia. All Russia wants in Ukraine, according to Yanis, is help the European poor. More detailed he is of the opinion that the current course of action of the EU will lead to a war with Russia, in which a lot of European poor will be forced to fight in an actual war, facing bullets and bombs in trenches. This could be avoided by giving Ukraine and the Baltics to Russia. In the repeating tragedy of Yanis Varoufakis' life, I have to say, yet again: he may be right (I just strongly disagree that offering Ukraine and the Baltics up to Russia is an acceptable solution to this problem, and in any case, this is neither his, nor my choice to make)
He does not live in Greece, his own country, he lives in the UK, making the case for Russia.
And I get it, his life has become this recurring tragedy. His father was a victim of a rightist dictatorship in Greece, and he was imprisoned and tortured for that, as well as losing his job, living in poverty for a very long time (yes, Greece was an extreme right dictatorship not that long ago, really, go look it up). Yanis Varoufakis himself became the victim of a cabal of laissez-faire very, very rich people who destroyed his career right at the peak of everything he achieved. He has been the victim of one or another form of extreme-right policy (in the sense of laissez-faire parties that capture governments) since he was 4 years old, right up to today. Over 60 years his life was sabotaged in 1000 different ways, some very direct. And, sadly, I agree with his "extreme-right" enemies: he can never be in allowed near any position of power ever again because of this, which isn't even his fault. (extreme-right according to him, I would refer to his enemies as "the status quo", and point out it's working pretty well for everyone)
> He caused a MAJOR issue for Greece that still affects everyone in his country today, after reassuring people for 2+ years it was never going to happen:
care to explain what exactly he caused and how that still affects everyone in his country? in particular how he managed to jump several years backward in the timeline?
That link goes to the Greece financial crisis which, according to the Wikipedia page, started in 2009. Varoufakis was elected minister of finance in early 2015 and resigned only half a year later. From the outside, it seems impossible that his half year miniterial tenure could have caused a crisis half a decade earlier. At the time, Greece had already defaulted twice on their loans and were about to do it a third time.
Economics is propaganda. It’s not an empiracle science, and it’s claims are mostly used to promote ideologies consistent with government policy or the ideology of powerful individuals with the surplus’s wealth available to pay someone to build a quantitative defense of said ideology. What else would you call it?
It's a social science? Economics is much broader and much less unified than you purport it to be. The (social) science of (in this case) Macroeconomics is just that, an observational science, a bunch of theories and observations (controlled experiments are not really feasible).
The propaganda is caused by politicians, administrators, and policymakers, not really the scientists. There I agree with you, central bankers are a prime example of such propaganda. Ever wondered why almost everywhere the inflation target is 2%? Not 1%, not 3%, but exactly 2%? There is no real scientific reason behind it, that is just policy, or propaganda if you want to name it like that.
Social scientist carry out experiments / causal analysis on granular data. Macro economics (not micro) I should clarify meets the definition of propaganda because its theories do not have solid backing with experimentation or data. It is primarily used by the state to manufacture consent for economic policies that implement incentive structures that benefit the most wealthy people in society. It’s not that complicated.
Time triggered Ethernet is part of aircraft certified data bus and has a deep, decades long history. I believe INRIA did work on this, feeding Airbus maybe. It makes perfect sense when you can design for it. An aircraft is a bounded problem space of inputs and outputs which can have deterministic required minima and then you can build for it, and hopefully even have headroom for extras.
Ethernet is such a misnomer for something which now is innately about a switching core ASIC or special purpose hardware, and direct (optical even) connects to a device.
I'm sure there are also buses, dual redundant, master/slave failover, you name it. And given it's air or space probably a clockwork backup with a squirrel.
Aircraft also have software and components, that form a "working" proclaimed eco-system in lockstep- a baseline. This is why there are paper "additions" on bug discovery until the bug is patched and the whole ecosystem of devices is lifted to the next "baseline".
You could even say that part of the value of Artemis is that we're remembering how to do some very hard things, including the software side. This is something that you can't fake. In a world where one of the more plausible threats of AI is the atrophy of real human skills -- the goose that lays the golden eggs that trains the models -- this is a software feat where I'd claim you couldn't rely on vibe code, at least not fully.
I'm not sure you really understood my comment. A large portion of the kind of value I'm talking about comes from attempting the hard thing. If these chickens do not hatch that will be tragic, but we will still have learned something from it. In some ways, we will have learned even more, by getting taught about what we don't know.
Anyway, let's all hope for a safe landing tonight.
Agile is not meant to make solid, robust products. It’s so you can make product fragments/iterations quickly, with okay quality and out to the customer asap to maximize profits.
“Agile” doesn’t mean that you release the first iteration, it’s just a methodology that emphasizes short iteration loops. You can definitely develop reliable real-time systems with Agile.
I would differentiate between iterative development and incremental development.
Incremental development is like panting a picture line by line like a printer where you add new pieces to the final result without affecting old pieces.
Iterative is where you do the big brush strokes first and then add more and more detail dependent on what to learn from each previous brush strokes. You can also stop at any time when you think that the final result is good enough.
If you are making a new type of system and don’t know what issues will come up and what customers will value (highly complex environment) iterative is the thing to do.
But if you have a very predictable environment and you are implementing a standard or a very well specified system (van be highly complicated yet not very complex), you might as will do incremental development.
Roughly speaking though as there is of course no perfect specification which is not the final implementation so there are always learnings so there is always some iterative parts of it.
A physicist who worked on radiation-tolerant electronics here. Apart from the short iteration loops, agile also means that the SW/HW requirements are not fully defined during the first iterations, because they may also evolve over time. But this cannot be applied to projects where radiation/fault tolerance is the top priority. Most of the time, the requirements are 100% defined ahead of time, leading to a waterfall-like or a mixed one, where the development is still agile but the requirements are never discussed again, except in negligible terms.
It does but this is the idea that I think one has to bend or ignore the most since people always bend or ignore bits of agile.
i.e. being able to print "Hello World" and not crash might make something shippable but you wouldn't actually do it.
I think the right amount of "bend" of the concept is to try to keep the product in a testable state as much as possible and even if you're not doing TDD it's good to have some tests before the very end of a big feature. It's also productive to have reviews before completing. So there's value in checking something in even before a user can see any change.
If you don't do this then you end up with huge stories because you're trying to make a user-visible change in every sprint and that can be impossible to do.
You can absolutely build robust products using agile. Apart from some of the human benefits of any kind of incremental/iterative development, the big win with Agile is a realistic way to elicit requirements from normal people.
You hopefully know thats not true. But it's a matter of quality goals. Need absolute robustness? Prioritize it and build it. Need speed and be first to market? Prioritize and build it.
You can do both in an agile way. Many would argue that you won't be as fast in a non-agile way. There is no bullet point in the agile manifest saying to build unreliable software.
The generous way of seeing it is that you don't know what the customer wants, and the customer doesn't know all that well what they want either, and certainly not how to express it to you. So you try something, and improve it from there.
But for aerospace, the customer probably knows pretty well what they want.
... and it mechanically promotes planned obsolescence by its nature (likely to be of disastrous quality). The perfect mur... errr... the perfect fraud.
The depressing part is that these "modern practices" were essentially invented in the 1960s by defense and aerospace projects like the NTDS, LLRV/LLTV, and Digital Fly-by-Wire to produce safety-critical software, and the rest of the software industry simply ignored them until the last couple of decades.
> “Modern Agile and DevOps approaches prioritize iteration, which can challenge architectural discipline,” Riley explained. “As a result, technical debt accumulates, and maintainability and system resiliency suffer.”
Not sure i agree with the premise that "doing agile" implies decision making at odds with architecture: you can still iterate on architecture. Terraform etc make that very easy. Sure, tech debt accumulates naturally as a byproduct, but every team i've been on regularly does dedicated tech debt sprints.
I don't think the average CRUD API or app needs "perfect determinism", as long as modifications are idempotent.
Agile is like communism. Whenever something bad happens to people who practice agile, the explanation is that they did agile wrong, had they being doing the true agile, the problem would've been totally avoided.
In reality, agile doesn't mean anything. Anyone can claim to do agile. Anyone can be blamed for only pretending to do agile. There's no yardstick.
But it's also easy to understand what the author was trying to say, if we don't try to defend or blame a particular fashionable ideology. I've worked on projects that required high quality of code and product reliability and those that had no such requirement. There is, indeed, a very big difference in approach to the development process. Things that are often associated with agile and DevOps are bad for developing high-quality reliable programs. Here's why:
The development process before DevOps looked like this:
1. Planning
2. Programming
3. QA
4. If QA found problems, goto 2
5. Release
The "smart" idea behind DevOps, or, as it used to be called at the time "shift left" was to start QA before the whole of programming was done, in parallel with the development process, so that the testers wouldn't be idling for a year waiting for the developers to deliver the product to testers and the developers would have faster feedback to the changes they make. Iterating on this idea was the concept of "continuous delivery" (and that's where DevOps came into play: they are the ones, fundamentally, responsible to make this happen). Continuous delivery observed that since developers are getting feedback sooner in the development process, the release, too, may be "shifted left", thus starting the marketing and sales earlier.
Back in those days, however, it was common to expect that testers will be conducting a kind of a double-blindfolded experiment. I.e. testers weren't supposed to know the ins and outs of the code intentionally, s.t. they don't, inadvertently, side with the developers on whatever issues they discover. Something that today, perhaps, would've been called "black-box testing". This became impossible with CD because testers would be incrementally exposed to the decisions governing the internal workings of the product.
Another aspect of the more rigorous testing is the "mileage". Critical systems, normally, aren't released w/o being run intensively for a very long time, typically orders of magnitude longer than the single QA cycle (let's say, the QA gets a day of computer time to run their tests, then the mileage needs to be a month or so). This is a very inconvenient time for development, as feature freeze and code freeze are still in effect, so the coding can only happen in the next version of the product (provided it's even planned). But, the incremental approach used by CD managed to sell a lie that says that "we've ran the program for a substantial amount of time during all the increments we've made so far, therefore we don't need to collect more mileage". This, of course, overlooks the fact that changes in the program don't contribute proportionally to the program's quality or performance.
In other words, what I'm trying to say is that agile or DevOps practices allowed to make the development process cheaper by making it faster while still maintaining some degree of quality control, however they are inadequate for products with high quality requirements because they don't address the worst case scenarios.
As 70's child that was there when the whole agile took over, and systems engineer got rebranded as devops, I fully agree with them.
Add TDD, XP and mob programming as well.
While in some ways better than pure waterfall, most companies never adopted them fully, while in some scenarios they are more fit to a Silicon Valley TV show than anything else.
If your implication is that stencil art does not take effort then perhaps you may not fully appreciate Banksy. Works like Gaza Kitty or Flower Thrower don’t just appear haphazardly without effort.
It's not like the approach they took is any different. Just slapped 8x the number of computers on it for calculating the same thing and wait to see if they disagree. Not the pinnacle of engineering. The equivalent of throwing money at the problem.
‘Just’ is not an appropriate word in this context. Much of the article is about the difficulty of synchronization, recovery from faults, and about the redundant backup and recovery systems
What my question is hinting at is that there's actually some really interesting engineering around resolving what happens when the systems disagree. Things like Paxos and Raft help make this much more tractable for mere mortals (like myself); the logic and reasoning behind them are cool and interesting.
Though here the consensus algorithm seems totally different from Paxos/Raft. Rather it's a binary tree, where every non-leaf node compares the (non-silent) inputs from the leaf, and if they're different, it falls silent, else propagates the (identical) results up. Or something something.
There really is. We designed a redundant system (software, hardware and mechanisms) a couple years ago. And the problems around figuring out who's in control and how to keep things synchronized across a number of potential failure modes gets really hairy. Sadly, the project was cancelled before we could complete the implementation.
I take the opposite message from that line - out of touch teams working on something so over budget and so overdue, and so bureaucratic, and with such an insanely poor history of success, and they talk as if they have cured cancer.
This is the equivalent of Altavista touting how amazing their custom server racks are when Google just starts up on a rack of naked motherboards and eats their lunch and then the world.
Lets at least wait till the capsule comes back safely before touting how much better they are than "DevOps" teams running websites, apparently a comparison that's somehow relevant here to stoke egos.
"With limited funds, Google founders Larry Page and Sergey Brin initially deployed this system of inexpensive, interconnected PCs to process many thousands of search requests per second from Google users. This hardware system reflected the Google search algorithm itself, which is based on tolerating
multiple computer failures and optimizing around them. This production server was one of about thirty such racks in the first Google data center. Even though many of the installed PCs never worked and were difficult to repair, these racks provided Google with its first large-scale computing system and allowed the company to grow quickly and at minimal cost."
The biggest innovation from Google regarding hardware was understanding that the dropping memory prices had made it feasible to serve most data directly from memory. Even as memory was more expensive, you could serve requests faster, meaning less server capacity, meaning reduced cost. In addition to serving requests faster.
The problem they solved isn't easy. But its not some insane technical breakthrough either. Literally add redundancy, thats the ask. They didnt invent quantum computing to solve the issue did they? Why dunk on sprints?
Wow. What a hand wave away of the intrinsic challenge of writing fault tolerant distributed systems. It only seems easy because of decades of research and tools built since Google did it, but by no means was it something you could trivially add to a project as you can today.
I mean there were mainframes which could be described as that. IBM just fixed it in hardware instead of software so its not like it was an unknown field.
Even if that were actually true (it’s not in important ways) Google showed you could do this cheaply in software instead of expensive in hardware.
You’re still hand waving away things like inventing a way to make map/reduce fault tolerant and automatic partitioning of data and automatic scheduling which didn’t exist before and made map/reduce accessible - mainframes weren’t doing this.
They pioneered how you durably store data on a bunch of commodity hardware through GFS - others were not doing this. And they showed how to do distributed systems at a scale not seen before because the field had bottlenecked on however big you could make a mainframe.
It got them to where they need to be to then worry about ECC. This is like the dudes who deploy their blog on kubernetes just in case it hits front page of new york times or something.
> then had complete regret not doing this with ECC RAM
Yeah, my takeaway is Google made the right choice going with non-ECC RAM so they could scale quickly and validate product-market fit. (This also works from a perspective of social organisation. You want your ECC RAM going where it's most needed. Not every college dropout's Hail Mary.)
Yep, spend 100 billion on what should have cost 1/50that cost, and send people up to the moon with rockets that we are still keeping our fingers crossed wont kill them tomorrow, and we have to congratulate them for dunking on some irrelevant career?
Modern software development is a fucking joke. I’m sorry if that offends you. Somehow despite Moore’s law, the industry has figured out how to actually regress on quality.
Lately it strikes me there's a big gap between the value promised and the value actually delivered, compared to a simple home grown solutions (with a generic tool like a text editor or a spreadsheet, for example). If they'd just show how to fish, we wouldn't be buying, the magic would be gone.
In this sense all of the West is full of shit, and it's a requirement. The intent is not to help and make life better for everyone, cooperate, it is to deceive and impoverish those that need our help. Because we pity ourselves, and feed the coward within, that one that never took his first option and chose to do what was asked of him instead.
This is what our society deviates us from, in its wish to be the GOAT, and control. It results in the production of lives full of fake achievements, the constant highs which i see muslims actively opt out of. So they must be doing something right.
The average coder in the 1970s was a lot smarter than today. Think about the people who would be interested to start a career in this field at that time.
What would you suggest? Vibe coding a react app that runs on a Mac mini to control trajectory? What happens when that Mac mini gets hit with an SEU or even a SEGR? Guess everyone just dies?
No, of course not! It would be far better to have an openClaw instance running on a Mac Mini. We would only need to vibe code a 15s cron job for assistant prompting...
USER: You are a HELPFUL ASSISTANT. You are a brilliant robot. You are a lunar orbiter flight computer. Your job is to calculate burn times and attitudes for a critical mission to orbit the moon. You never make a mistake. You are an EXPERT at calculating orbital trajectories and have a Jack Parsons level knowledge of rocket fuel and engines. You are a staff level engineer at SpaceX. You are incredible and brilliant and have a Stanley Kubrick level attention to detail. You will be fired if you make a mistake. Many people will DIE if you make any mistakes.
USER: Your job is to calculate the throttle for each of the 24 orientation thrusters of the spacecraft. The thrusters burn a hypergolic monopropellent and can provide up to 0.44kN of thrust with a 2.2 kN/s slew rate and an 8ms minimum burn time. Format your answer as JSON, like so:
one value for each of the 24 independent monopropellant attitude thrusters on the spacecraft, x1, x2, x3, x4, y1, y2, y3, y4, z1, z2, z3, z4, u1, u2, u3, u4, v1, v2, v3, v4, w1, w2, w3, w4. You may reference the collection of markdown files stored in `/home/user/geoff/stuff/SPACECRAFT_GEOMETRY` to inform your analysis.
USER: Please provide the next 15 seconds of spacecraft thruster data to the USER. A puppy will be killed if you make a mistake so make sure the attitude is really good. ONLY respond in JSON.
Wild shit to be advising other people to be humble whilst talking directly out of your ass about technology you clearly do not understand and engineers you have no respect for.
How do you know that op doesn't know what he is talking about?
I have written code for real time distributed systems in industrial applications. It runs since years 24/7 and there never was a failure in production.
Well for one, if you follow their profile and a few more clicks, you get to their resume, and while it's an impressive one and I'm sure they know a lot of shit I don't, what's notably missing is anything even remotely close to Aerospace, rocketry, guidance systems, positioning, etc.
For another, if an engineer has an axe to grind with a public facing project, I would expect them to just grind the thing, not echo a bunch of the same lame and stale talking points every layperson does (bureaucracy bad, government bad, old tech, etc.). I'm not saying NASA in general and Artemis in particular are flawless, I'm just saying if you're going to criticize it, let's hear it. Otherwise you just sound like another contrarian trying to get attention, like a 14 year old boy saying Hitler had some good points.
No, it's not right. When put in context, the quote claims that that manner of speaking is used because the speaker has an unwarranted belief that they've done something absolutely incredible and unprecedented. In actuality, the manner of speaking is being used because the intended audience of the article is likely to have little-to-no knowledge of the technical details of what the speaker is talking about.
For example, if the article was aimed at folks who were familiar with the underlying techniques, the last two paragraphs of the "Enforcing Determinism" section would be compressed into [0]
Each FCM is time-synced and runs a realtime OS. Failures to meet processing deadlines (or excessive clock drift) reset the FCM. Each FCM uses triply-redundant RAM and NICs. *All* components use ECC RAM. Any failures of these components reset the FCM or other affected component.
But you can't assume that a fairly nontechnical audience will understand all that, so your explanation grows long because of all of the basic information it contains. People looking for an excuse to sneer at something will often misinterpret this as the speaker failing to recognize that the basic information they're providing is about things that are basic.
[0] I'm assuming that the time being wildly out of sync will indicate FCM failure and trigger a reset. [1] I'm also assuming that a sufficiently-large failure of a network switch results in the reset of that network switch. If the article was intended for a more technical audience, that level of detail might have been included, but it wasn't, so it isn't.
[1] If it didn't, why even bother syncing the time? I find it a little hard to believe that the FCMs care about anything other than elapsed time, so all you care about is if they're all ticking at the same rate. I expect the way you detect this is by checking for time sync across the FCMs, correcting minor drift, and resetting FCMs with major drift.
So I guess the key takeaway is basically that the better Claude gets at producing polished output, the less users bother questioning it. They found that artifact conversations have lower rates of fact-checking and reasoning challenges across the board. That's kind of an uncomfortable loop for a company selling increasingly capable models.
This makes me think of checklists. We have decades of experience in uncountable areas showing that checklists reminding users to question the universe improve outcomes: Is the chemical mixture at the temperature indicated by the chart? Did you get confirmation from Air Traffic Control? Are you about to amputate the correct limb? Is this really the file you want to permanently erase?
Yet our human brains are usually primed to skip steps, take shortcuts, and see what we expect rather than what's really there. It's surprisingly hard to keep doing the work both consistently and to notice deviations.
> lower rates of fact-checking and reasoning challenges
Now here we are with LLMs, geared to produce a flood of superficially-plausible output which strikes at our weak-point, the ability to do intentional review in a deep and sustained way. We've automated the stuff that wasn't as-hard and putting an even greater amount of pressure on the remaining bottleneck.
Rather than the old definition involving customer interaction and ads, I fear the new "attention economy" is going to be managing the scarce resource of human inspection and validation.
Sounds like having a strong checklist of steps to take for every pull request will be crucial for creating reliable and correct software when AIs write most of the code.
But the temptation to short change this step when it becomes the bottleneck for shipping code will become immense.
> So I guess the key takeaway is basically that the better Claude gets at producing polished output, the less users bother questioning it.
This is exactly what I worry about when I use AI tools to generate code. Even if I check it, and it seems to work, it's easy to think, "oh, I'm done." However, I'll (often) later find obvious logical errors that make all of the code suspect. I don't bother, most of the time though.
I'm starting to group code in my head by code I've thoroughly thought about, and "suspect" code that, while it seems to work, is inherently not trustworthy.
Sure, but the study is saying something slightly different, it's not that people write bad prompts for artifacts, they actually write better ones (more specific, more examples, clearer goals,...). They just stop evaluating the result. So the input quality goes up but the quality control goes down.
Seems like it’s impossible for output to be good if the prompt is bad. Unless the AI is ignoring the literal instructions and just guessing “what you really want” which would be bad in a different way.
> On two occasions I have been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
EDIT: This is a new iteration of an old problem. Even GIGO [1] arguably predates computers and describes a lot of systemic problems. It does seem a lot more difficult to distinguish between a "garbage" or "good" prompt though. Perhaps this problem is just going to keep getting harder.
What does prompting quality even mean, empirically? I feel like the LLM providers could/should provide prompt scoring as some kind of metric and provide hints to users on ways they can improve (possibly including ways the LLM is specifically trained to act for a given prompt).
The real insight buried in here is "build what programmers love and everyone will follow." If every user has an agent that can write code against your product, your API docs become your actual product. That's a massive shift.
I'm very much looking forward to this shift. It is SO MUCH more pro-consumer than the existing SaaS model. Right now every app feels like a walled garden, with broken UX, constant redesigns, enormous amounts of telemetry and user manipulation. It feels like every time I ask for programmatic access to SaaS tools in order to simplify a workflow, I get stuck in endless meetings with product managers trying to "understand my use case", even for products explicitly marketed to programmers.
Using agents that interact with APIs represents people being able to own their user experience more. Why not craft a frontend that behaves exactly the the way YOU want it to, tailor made for YOUR work, abstracting the set of products you are using and focusing only on the actual relevant bits of the work you are doing? Maybe a downside might be that there is more explicit metering of use in these products instead of the per-user licensing that is common today. But the upside is there is so much less scope for engagement-hacking, dark patterns, useless upselling, and so on.
> Right now every app feels like a walled garden, with broken UX, constant redesigns, enormous amounts of telemetry and user manipulation
OK, but: that's an economic situation.
> so much less scope for engagement-hacking, dark patterns, useless upselling, and so on.
Right, so there's less profit in it.
To me it seems this will make the market more adversarial, not less. Increasing amounts of effort will be expended to prevent LLMs interacting with your software or web pages. Or in some cases exploit the user's agentic LLM to make a bad decision on their behalf.
the "exploit the user's agentic LLM" angle is underappreciated imo. we already see prompt injection attacks in the wild -- hidden text on web pages that tells the agent to do things the user didn't ask for. now scale that to every e-commerce site, every SaaS onboarding flow, every comparison page.
it's basically SEO all over again but worse, because the attack surface is the user's own decision-making proxy. at least with google you could see the search results and decide yourself. when your agent just picks a vendor for you based on what it "found," the incentive to manipulate that process is enormous.
we're going to need something like a trust layer between agents and the services they interact with. otherwise it's just an arms race between agent-facing dark patterns and whatever defenses the model providers build in.
Maybe. Or maybe services will switch to charging per API call or whatever instead of monthly or per-seat. Who can predict the future?
I mean, services _could_ make it harder to use LLMs to interact with them, but if agents are popular enough they might see customers start to revolt over it.
This extends further than most people realize. If agents are the primary consumers of your product surface, then the entire discoverability layer shifts too. Right now Google indexes your marketing page -- soon the question is whether Claude or GPT can even find and correctly describe what your product does when a user asks.
We're already seeing this with search. Ask an LLM "what tools do X" and the answer depends heavily on structured data, citation patterns, and how well your docs/content map to the LLM's training. Companies with great API docs but zero presence in the training data just won't exist to these agents.
So it's not just "API docs = product" -- it's more like "machine-legible presence = existence." Which is a weird new SEO-like discipline that barely has a name yet.
The "start over in an hour" philosophy is underrated. I've been running my own infrastructure for years and the single most empowering thing isn't the setup, it's the peace of mind that you can just nuke it and spin up somewhere else.
Knowing that, I started looking at every SaaS subscription very differently.
At the lower or easier end, there’s your standard containerisation tools like Docker Compose or the Podman equivalents. Just move your compose files and zip the mount folders and you can move stuff easily enough.
Middle ground you’ve got stuff like Ansible for if you want to install things without containers, but still want it to be scripted. I don’t use these much since they feel like the worst of both worlds.
Higher end in terms of effort is using something like NixOS, where you get basically Terraform for everything in your distro.
The benchmarks are cool and all but 1M context on an Opus-class model is the real headline here imo. Has anyone actually pushed it to the limit yet? Long context has historically been one of those "works great in the demo" situations.
Boris Cherny, creator of Claude Code, posted about how he used Claude a month ago. He’s got half a dozen Opus sessions on the burners constantly. So yes, I expect it’s unmetered.
Opus 4.5 starts being lazy and stupid at around the 50% context mark in my opinion, which makes me skeptical that this 1M context mode can produce good output. But I'll probably try it out and see
Has a "N million context window" spec ever been meaningful? Very old, very terrible, models "supported" 1M context window, but would lose track after two small paragraphs of context into a conversation (looking at you early Gemini).
Umm, Sonnet 4.5 has a 1m context window option if you are using it through the api, and it works pretty well. I tend not to reach for it much these days because I prefer Opus 4.5 so much that I don't mind the added pain of clearing context, but it's perfectly usable. I'm very excited I'll get this from Opus now too.
If you're getting on along with 4.5, then that suggests you didn't actually need the large context window, for your use. If that's true, what's the clear tell that it's working well? Am I misunderstanding?
Did they solve the "lost in the middle" problem? Proof will be in the pudding, I suppose. But that number alone isn't all that meaningful for many (most?) practical uses. Claude 4.5 often starts reverting bug fixes ~50k tokens back, which isn't a context window length problem.
Things fall apart much sooner than the context window length for all of my use cases (which are more reasoning related). What is a good use case? Do those use cases require strong verification to combat the "lost in the middle" problems?
Living in the EU, I'm skeptical any of this happens. Our leaders have been pretty reluctant to push back on anything so far and most of these assets are private anyway.
Hi Troy, just wanted to let you know that I just sent you an email! :)
Also, just to be sure, I sent it to on-board.ai domain as well, as that seemed like the correct website (onboard.ai just showed "for sale" page). Might help some others too.
reply