It is always amazing at how crap some code can be and yet still function, usually to the total bemusement of the coder. "It shouldn't work but it does?!"
When I used to contract code for some game engine stuff back in the 2000's early 2010's, that was essentially my working standard. Essentially gave a boiler plate terms of my work. I will make it work, I will get it done quickly, it will run fast BUT you will incur a lot of technical debt in doing so. In a games engine it isn't a big deal, you are essentially just pushing pixels around a screen in a sand-boxed system. "Yeah, the decompression system does some odd things with memory addresses but it is quick and plays nice with your streaming system. Just don't change the overall mapping too much and it should ship ok.". "In this level of your game, I have this explicit exception code that prevents that streaming system from booting out too much necessary data. Don't change this unless you want a headache"
I shudder to think of what that style of code would do in a work environment with serious consequences.
I suspect we will find out a lot more of this in the decades to come.
That last point is the 'argument from popularity' logical fallacy but I guess we are talking opinion not facts here. ;) Personally, when it comes to tech, people are generally ok with their decisions. Not great but not bad either.
You do bring up a good point in term of wanting new additions if possible. The real question is, who is adding the capabilities? And do you have any control over these additions?
More I have new things forced onto me and it is very clear they came from the management teams to drive engagement rather than a genuinely useful new feature. If you could just outright disable or uninstall said feature then there is no problem, but that is rarely the case any more.
Trump could become an accidental environmental ally in the same way the 2008 credit crisis and Covid did. Just blunders in and in the wreckage might be something ok.
Even if it wasn't for corrections, one has to look at the longer trends and not just single months.
Loads of people switch to Linux but I do wonder how many are still there a year later? I say this as someone that been a Linux daily runner since about 2010.
> Even if it wasn't for corrections
> Loads of people
This is all fine (and might even be true) but not having to fill in the gaps with anecdotal data and wishful thinking is precisely what good statistics are for. Bad statistics, on the other hand, make for a bad conversation starter because everyone is confused and it gets worse from there.
We also have a lot of easily accessible resources via agriculture and mining, things Mars does not have. And even if it did having mining potential, the cost of returning the goods to Earth would be wild.
I have long suspected that the next major move will be to roll Tesla into Space X, thus completing the Musk consolidation. After that is when it gets interesting as the whole staggeringly massive business has to be profitable long term.
It could be a good thing as it is very diversified but it can also open the whole thing up to a lot of risk factors.
That is true but they are also some of the most vocal advocates of certain systems. It is a king of trust errotion that doesnt show up for a very long time but by the time it does it is too late to reverse.
Tge flipside of that is that Google and Apple have no viable alternatives. It would take years to build what they have.
It took Huawei about 5 years with Harmony OS to do it but odds if that making it far out side of China is limited.
For many years I had been advocating for Linux distros to optimize for lower spec machines as their life times got extended. Best case, you head off potential hardware end of life, worst case you allow newer hardware to run more effciebtly. The latest shortage I didnt see coming, but it would have helped out regardless. Keeping old hardware going is vital nowadays, need to end the mind set of disposable goods.
When I used to contract code for some game engine stuff back in the 2000's early 2010's, that was essentially my working standard. Essentially gave a boiler plate terms of my work. I will make it work, I will get it done quickly, it will run fast BUT you will incur a lot of technical debt in doing so. In a games engine it isn't a big deal, you are essentially just pushing pixels around a screen in a sand-boxed system. "Yeah, the decompression system does some odd things with memory addresses but it is quick and plays nice with your streaming system. Just don't change the overall mapping too much and it should ship ok.". "In this level of your game, I have this explicit exception code that prevents that streaming system from booting out too much necessary data. Don't change this unless you want a headache"
I shudder to think of what that style of code would do in a work environment with serious consequences.
I suspect we will find out a lot more of this in the decades to come.
reply