Yeah, I have a similar situation with Borderlands 2 not running on my machine with Windows 7 but running just fine in Linux with Proton (which is Steam’s branch of Wine).
It seems to me that Linux with Wine is actually better at backwards compatibility for Windows applications than Windows itself.
PS: Also a handful of old games I have from GoG that wouldn’t run on Windows run just fine with Wine on Linux.
A family of software development processes for teams, which focuses on cycles of quickly building and delivering smaller blocks of program functionally (often just a single program feature - say: “search customers by last name” - or just part of a feature) to end-users so as to get quick feedback from those users of the software, which is then is use to determining what should be done for subsequent cycles.
When done properly it addresses the issues of older software development processes (such as the Waterfall process) in siuations where the users don’t really have a detailed vision of what the software needs to do for them (which are the most usual situations unless the software just helps automates their present way of doing things) or there are frequent changes of what they need the software to do for them (i.e. they already use the software but frequently need new software features or tweaks to existing features).
In my own career of over two decades I only ever seen it done properly maybe once or twice. The problem is that “doing Agile” became fashionable at a certain point maybe a decade ago and pretty much a requirement to have in one’s CV as a programmer, so you end up with lots of teams mindlessly “doing Agile” by doing some of the practices from Agile (say, the stand up meeting or paired programming) without including other practices and elements of the process (and adjusting them for their local situation) thus not achieving what that process is meant to achieve - essentially they don’t really understand it as a software development process which is more adequate for some situations and less for others and what it actually is supposed to achieve and how.
(The most frequent things not being done are those around participation of the end-users of the software in evaluating what has been done in the last cycle, determining new features and feature tweaks for the next cycle and prioritizing them. The funny bit is that these are core parts of making Agile deliver its greatest benefits as a software development process, so basically most teams aren’t doing the part of Agile that actually makes it deliver superior results to most other methods).
It doesn’t help that to really and fully get the purpose of Agile and how it achieves it, you generally need to be at the level of experience at which you’re looking at the actual process of making software (the kind of people with at least a decade of experience and titles like Software Architect) which, given how ageist a lot of the Industry is are pretty rare, so Agile is usually being done by “kids” in a monkey-sees-monkey-does way without understanding it as a process, hence why it, unsurprising, has by now gotten a bit of a bad name (as with everything, the right tool should be used for the right job).
They’re supposed to work as an adaptor/buffer/filter between the technical side and the non-technical stakeholders (customers, middle/upper management) and doing some level of organising.
In my 2 and a half decades of experience (a lot of it as a freelancer, so I worked in a lot of companies of all sizes in a couple of countries), most aren’t at all good at it, and very few are very good at it.
Some are so bad that they actually amplify uncertainty and disorganisation by, every time they talk to a customer or higher up, totally changing the team’s direction and priorities.
Mind you, all positions have good professionals and bad professionals, the problem with project management is that a bad professional can screw a lot of work of a lot of people, whilst the damage done by, for example, a single bad programmer, tends to be much more contained and generally mainly impacts the programer him or herself (so that person is very much incentivised to improve).
Half way into saving the World it turns out you need some data that’s not even being collected, something that nobody had figured out because nobody analysed the problem properly beforehand, and now you have to take a totally different approach because that can’t be done in time.
Also the version of a library being include by some dependency of some library you included to do something stupidly simple is different from the version of the same library being included by some dependency of a totally different library somebody else includeed to do something else that’s just as stupidly simple and neither you nor that somebody else want to be the one to rewrite their part of the code.
The first sign that the company you just joined is amateur hour, every hour of the day, every day of the year is that they don’t have a Staging environment.
It eliminates the dependency of specific distributions problem and, maybe more importantly, it solves the dependency of specific distribution versions problem (i.e. working fine now but might not work at all later in the very same distribution because some libraries are missing or default configuration is different).
For example, one of the games I have in my GOG library is over 10 years old and has a native Linux binary, which won’t work in a modern Debian-based distro by default because some of the libraries it requires aren’t installed (meanwhile, the Windows binary will work just fine with Wine). It would be kinda deluded to expect the devs would keep on updating the Linux native distro (or even the Windows one) for over a decade, whilst if it had been released as a Docker app, that would not be a problem.
So yeah, stuff like Docker does have a reasonable justification when it comes to isolating from some external dependencies which the application devs have no control over, especially when it comes to future-proofing your app: the Docker API itself needs to remain backwards compatible, but there is no requirement that the Linux distros are backwards compatible (something which would be much harder to guarantee).
Mind you, Docker and similar is a bit of a hack to solve a systemic (cultural even) problem in software development which is that devs don’t really do proper dependency management and just throw in everything and the kitchen sink in terms of external libraries (which then depend on external libraries which in turn depend on more external libraries) into the simplest of apps, but that’s a broader software development culture problem and most of present day developers only ever learned the “find some library that does what you need and add it to the list of dependencies of your build tool” way of programming.
I would love it if we solved what’s essentially the core Technical Architecture problem of in present day software development practices, but I have no idea how we can do so, hence the “hack” of things like Docker of pretty much including the whole runtime environment (funnilly enough, a variant of the old way of having your apps build statically with every dependency) to work around it.
Well, mucking about with configuration on a computer is a form of entertainment hence its “use” in a broader sense…
Look for a processor for the same socket that supports more RAM and make sure the Motherboard can handle it - maybe you’re lucky and it’s not a limit of that architecture.
If that won’t work, breakup your self-hosting needs into multiple machines and add another second hand or cheap machine to the pile.
I’ve worked in designing computer systems to handle tons of data and requests and often the only reasonable solution is to break up the load and throw more machines at it (for example, when serving millions of requests on a website, just put a load balancer in front of it that assigns user sessions and associated requests to multiple machines, so the load balancer pretty much just routes request by user session whilst the heavy processing stuff is done by multiple machines in such a way the you can just expand the whole thing by adding more machines).
In a self-hosting scenario I suspect you’ll have a lot of margin for expansion by splitting services into multiple hosts and using stuff like network shared drives in the background for shared data, before you have to fully upgrade a host machine because you hit that architecture’s maximum memory.
Granted, if a single service whose load can’t be broken down so that you can run it as a cluster, needs more memory than you can put in any of your machines, then you’re stuck having to get a new machine, but even then by splitting services you can get a machine with a newer architecture that can handle more memory but is still cheap (such as a cheap mini-PC) and just move that memory-heavy service to it whilst leaving CPU intensive services in the old but more powerful machine.
Worry not: in 20 years’ time people born in 2028 will all pretty much look like kids to you.
Ah, right - I misunderstood that point you were making.
So, as it turns out, we’ve been in agreement all along.
Not living in the US, I’m not up to date with US salaries.
That said, even for administrative personnel paid $25/h, $25 will pay 1h of somebody’s work which is way beyond what is needed to close a retail customer account in any modern administrative system were such thing is a common operation which should take less than a minute to do, because people who design the kind of company administrative computer systems (such as yours truly, at least during part of my career) will make the most common business operations be the fastest to do in that system.
It deceives people whose idea of how things work in large companies hasn’t changed since the days when it was the manager of your bank branch who decided if you you should get a loan or not.
Nowadays, for certain in middle and large size companies, all the administrative main business pathways are heavilly if not totally automated and it’s customer support that ends up eating the most manpower (which is why there has been so much of a push for automated phone and chat support systems, of late using AI).
Those $25 bucks for “account closure” pays at worst for a few minutes of somebody’s seeking the account from user information on a computer, cross checking that the user information matches and then clicking a button that says “Close accout” and then “Ok” on the confirmation box and the remaining 99% or so left after paying for that cost are pure profit.
As somebody who works in designing software systems, including for large companies, lets just say that the amount of human time that goes into a customer account closure is negligible because main business operations such as openning and closing customer accounts are the ones that get automated the soonest and the furthest.
The stuff that uses “lots” (in relative terms) of manpower is supporting customers with really unusual problems involving third parties and even then spending 2.5 h man/hours (assuming the administrative person get paid $10/per hour) is pretty uncommon.
You’ve been lied to, repeatadly, for at least 3 decades.
“Perceived value”
Without that element, there would be no explanation for Marketing other than pure Brand Awareness promotion working (and McDonalds is definitely beyond needing more Brand Awareness, at least in the Developed World)
Even then, it doesn’t explain a lot of how Marketing does its work (namelly the stuff they took from Psychology and use to do things like create associations between brand and specific feelings on people’s subconscious - you know, the way cars are “freedom” and perfumes are “sex”).
And don’t get me started on other techniques that prey of human cognitive weaknesses (for example, FOMO would not work with the fabled Homo Economicus that underpins so much of Free Market Theory)
Anyways, a ton of present day enshittification (and that includes this kind of price inflation) relies on people having a well entrenched positive perception of a brand after years of having a relationship with it (i.e. chosing it as customers) and there being quite a lot of momentum behind it. It also relies a lot on using a “slow boiling” effect to keep people from spotting the full picture of the changes.
By that definition all “Industrial Associations” would not be capitalist.
Personally I would be wary of telling people they should trust the words of the spokespersons of most of them.
There are more than one way in which the elites and near-elites organise to advance their interests and IMHO The Guardian is very much The Voice Of The English Upper Middle Class.
The Guardian absolutely is capitalist (neoliberal, even). Just go check back on their campaign against Corbyn (a leftwinger who won the Labour Party leadership from the New Labpour neoliberals some years ago) which included such memorable pieces of slander like calling a Jewish Holocaust Survivor an anti-semite because of him in a conference about Palestine comparing some of the actions of the government of Israel with those of the Nazis, this done in order to slander Corbyn by association since he was in the same panel in that conference.
Also you can merely go back a few months to see how The Guardian supported Israel well into their Genocide (though they seem to have stop doing it quite as eagerly in the last few months).
Last but not least they very openly support in British elections the Liberal Democrats (who are neoliberals) and the New Labour faction of the Labour Party (also neoliberals) and very often have pro-privatisation articles on UK subjects and are never for bringing things back into public ownership even when privatisation has failed miserable to give better services or lower prices.
I lived in Britain for over a decade and read The Guardian for most of it, so maybe The Guardian’s political slant is clearer for those familiar with British Politics.
I do agree on The Intercept and Democracy Now! though.
Can’t really speak for the others with any knowledge.
I’ve seen, again an again, deploying to Staging and integration testing in that Production-like environment together with the software of other teams, reveal problems that we did not saw in Dev, thus saving us from deploying into Production software that broke or, worse, corrupted the database.
This was certainly very important when I worked in environments such as Investment Banking where Production being down because of integration issues or, worse, sending bad data to other systems or the database having to be rolled back to the overnight backup, might mean the business losing millions of dollars.
It’s not a foolproof mechanism but it certainly catches most integration problems, which are often most of the problems in complex environments where multiple teams are responsible for multiple highly integrated software systems,
Granted, little teams doing small software systems in simple environments were their software has little or no integration with other software, can probably get away with not having a Staging environment if their Dev environments has the same setup as Production (same OS, same database and so on) since they’re going to have very little in the way of Integration problems with other people’s software.