What happened to the idea of small, non-intrusive banner ads
You answered your own question:
they bring much less revenue compared to in-your-face video interstitials per impression
And shortsighted profit driven thinking - can make a load more money now even if some users are pissed off, don’t worry about long term user retention. Oh what!?! The usersbase is pissed and leaving/blocking things, better double down to keep them profits high in the mean time…
I don’t see how? This is targeting people already using ad blockers. People not already using them should not see any difference in service so why would they change their behaviour? At most a mild rise of awareness, though I bet most people following these news stories are also already running ad blockers. It is all the other aggressive shit they are doing with ads that will turn people towards ad blockers/premium.
People that were running ad blockers were not seeing ads and business owners were not paying for those blocked ads. So I don’t see why they would care at all.
Those are call applications. Use any language you like. If go/rust is what you know use them. I use rust all the time for things beyond run a bunch of commands and tends to be my go to when I need to process data in any way.
The package format is almost irrelevant TBH. Most packages are not interoperable between distros due to the versions and names of dependencies. That is not something that gets fixed by a standard package format. Packages don’t even work well between different versions of the same distro. largely due to libc - anything that depends on that is built against a specific version and when you upgrade it you need to rebuild and install everything that depends on it. Similar problems exist for all compiled dependencies on a distro.
And while some packages of the same format can be installed on multiple distros (mostly those based of the same foundation) most cannot. This is what the newer package formats (like flatpack) are trying to solve - by including all dependencies inside the package.
So a standard format does not really solve those issues, so there is little advantage for one. At least not one of the old school formats. And the wars are not really over the format, they are over the tooling required for that format. At the end of the day RPMs, DEBs, and arch packages are just tarballs of files and some meta data (and there is even a tool that can convert between them - though anything with dependencies quickly becomes a complete mess). It is the build and install tooling that makes all the difference.
Linux has standards where interoperability is important. The more things needs to talk to each other the more they need a common standard to talk over. Things like X11/Wayland don’t have many alternatives as so many things need to talk over them. The only reason there are two standards here is because X11 has massive limitations that cannot easily be worked around.
For package managers applications don’t care about them. Interoperability only matters within a single distro. So people are more free to create what ever standards they want for their own distros. And when people can choose people have opinions and these opinions evolve over time. Which results in multiple competing products that effectively do the same thing.
And here is my hipotesis if the GNU project came up with a good and easy to work package manager in the early days of Linux
Probably, but creating a good, easy to work, fast and reliable package manager that meets everyones needs when you are discovering how you want it to work for the first time is extremely hard. And even if you created a perfect one at the start, requirements can change. This happened with X11, and even with package managers seeing the rise of things like flatpack, snap and appimage that all work fundamentally different from the traditional ones.
check “Enable Steam Play for all titles” and restart Steam. Otherwise, you get ONLY games with a native Linux version (which are…hit or miss at times).
I don’t think this is fully true. You get all native games plus all verified games. Which is only a small subset of games overall, but quite a bit more than just the native games. Though most others do work and only really require toggling that switch.
The Linux OS symbol only tells you if the game is Linux native or not. Since valve released proton it is not very useful. The deck Verified/Deck Playable symbols are a far better indication of if a game will work. But even then, quite a few of the unsupported games still work on Linux overall, just less well on the deck. ProtonDB is the more definitive source of if a game will work as well as any tweaks you can do to make it run better.
I think it is a simpler case of legacy. They had the Linux/Windows/Mac symbols before proton was a thing and back then you needed it to be a native Linux game for it to work on Linux. Or you had to install all of steam inside wine and had pot luck as to if anything would work. Since they released proton they have kept the OS symbols the same. And since they released the steam deck they have added new deck verified/deck playable symbols which are a much better indication of playability on Linux.
Maybe not the best marketing. But I don’t think it is really due to legality issues, more so legacy ones.
Although AAA games also tend to work these days within days of release
And TBF, Far too many AAA games tend to not work well on Windows within the first few days of release either. Even a few like elden ring that worked better on Linux before Windows. Though I still avoid getting games on their release date. You are generally going to have a far better experience on either system by waiting a bit and seeing what others say about it.
IMO that is a disingenuous way to state that. It makes it sound like they had to work to find games that worked on Linux at all and suggests that most games do not. Which is far from the truth. Most games just work these days and it is only a handful that don’t, so only a handful work 100% better. Then it all really depends if you care about those few games or not.
Because of that prototypes should be small - no more than a week or so worth of effort. Anything larger means it will take even longer to rewrite it from scratch which management will never like and is overall just a waste of time. Most of the time you don’t actually want a prototype - you want a MVP written in the language of the final project as it will become the final product.
Really the only time I would write a prototype in a different language then the final product is when you don’t yet know the language you want to (or more likely, need to) use or you know another language vastly more than the target language. The time saved by the language is often just not worth it overall when you are reasonably competent in both languages.