Really need to try PyInfra, the concept sounds nice.
You don't have to do crazy things with Ansible for that yaml DSL becoming the opposite of helpful. Things which would be quite straightforward to express in code become quite cumbersome, hard to understand and hard to debug. Also Jinja is often a horrible choice (you don't have in Ansible). Also Ansible excessively requires it in places where you want proper types and not just a string.
I think in general not being able to replace the battery toolless is quite an acceptable compromise nowadays. The needed mechanism and the protective shell the replaceable battery needs definitely takes up space which can be used for more capacity instead. You have (sometimes quite insane) fast charging and also powerbanks which support it. Also quality batteries can be quite durable.
The real problem I think is the hostility towards repair, glue everywhere, no spare parts, etc.
Good points, but from a chemistry perspective, fast charging is detrimental to the battery. It would be more efficient to have two or three batteries standard charged to 70% that you can swap in as you go than have one that you need to repeatedly fast charge.
I argue that easier they make for user to swap batteries themselves, higher the demand for the batteries will be, thus lower their price.
> The needed mechanism and the protective shell the replaceable battery needs definitely takes up space
This is true
> The real problem I think is the hostility towards repair, glue everywhere, no spare parts, etc.
I think when a manufacturer isn't designing to allow a regular customer (the owner) to be able to replace the battery themselves, using glue and restricting spare parts is a natural consequence of financial realities: Most people are not going to take a $500 phone that has been used a few years to a shop that will need to charge $100+ in just labor to swap out a battery. So there's no incentive to have a bunch of spare batteries.
I'm a huge fan of user replaceable batteries because in addition of obvious benefits, you can also just remove the battery and power it simply off USB-C when running something heavy on the phone for extended periods of time. A battery used in that scenario wouldn't just overheat itself but stop the phone from cooling off too.
Nonsense. It just mandates easier repairability and spare parts availability, not ad-hoc replacement. Also this does not apply if the battery is able to retain 80% of its original capacity after 1,000 charge cycles so "innovative" manufacturers just need to use high quality batteries.
You can even use the chip on the card together with some cheap HW device to authorize the transactions made with the app.
This actually exists [1] for quite some time but seems to be mostly limited to Germany. But this and the use of other HW tokens systems is on decline. Banks increasingly use apps now, increasingly without any meaningful second factor, not even offering better options. They want this and are fully to blame.
> But the job had better take fewer people, or the automation is not justified.
Not necessarily. Automation may also just result in higher quality output because it eliminates mistakes (less the case with "AI" automation though) and frees up time for the humans to actually quality control. This might require the people on average to be more skilled though.
Even if it only results in higher output volume you often have the effect that demand grows also because the price goes down.
There's a classic book on this, "Chapters on Machinery and Labor" (1926). [1]
They show three cases of what happened when a process was mechanized.
The "good case" was the Linotype. Typesetting became cheaper and the number of works printed went up, so printers did better.
The "medium case" was glassblowing of bottles. Bottle making was a skilled trade, with about five people working as a practiced team to make bottles. Once bottle-making was mechanized, there was no longer a need for such teams. But bottles became cheaper, so there were still a lot of bottlemakers. But they were lower paid, because tending a bottle-making machine is not a high skill job.
The "bad case" was the stone planer. The big application for planed stone was door and window lintels for brick buildings. This had been done by lots of big guys with hammers and chisels. Steam powered stone planers replaced them. Because lintels are a minor part of buildings, this didn't cause more buildings to be built, so employment in stone planing went way down.
Those are still the three basic cases. If the market size is limited by a non-price factor, higher productivity makes wages go down.
I think this is probably the trajectory for software development because while people claim there is a potentially unlimited demand that really only occurs at rock bottom prices.
In many cases you can saturate the market. The stone planer examples is an early case. Cheaper lintels don't mean more windows, because they are a minor part of the cost. Cheaper doorknobs do not generate demand for more doorknobs, because the market size is the number of doors. Cheap potatoes, soy, corn, and cheese have saturated their markets - people can only eat so much.
This might also be true of web analytics. At some point, more data will not improve profitability.
The thing is, there is next to no software that "doesn't need further changes" at all. There is always something, sure it might be infrequent and/or most of the time nothing really big or difficult (except sometimes) but the point is: someone needs to step up and do it.
If a see a project with recent activity, best from multiple people it is a strong signal that this will happen, if the last commit is a year ago I must assume it's completely abandoned because most of the time it just is. Sometimes it's clearly communicated that it is the way because the authors see it as essentially feature complete, there are some examples of this but not that many honestly.
An LLM is an impressive, yet still imperfect and unpredictable translation machine. The code it outputs can only be as good as your prompt is precise, minus the often blatant mistakes it makes.
You don't have to do crazy things with Ansible for that yaml DSL becoming the opposite of helpful. Things which would be quite straightforward to express in code become quite cumbersome, hard to understand and hard to debug. Also Jinja is often a horrible choice (you don't have in Ansible). Also Ansible excessively requires it in places where you want proper types and not just a string.
reply