> to look like geniuses when they solve ahead of schedule
No, it is because estimating software tasks is difficult, the penalty for underestimating is that people think you are dishonest/flakey, and there isn't anywhere to get an education in how to do it well. The default advice given to junior engineers is therefore: "take your intuition and triple it." I hate that this is the state of the industry. My interactions around estimation over the past 5 years since uni have literally made me feel nauseated and near fainting on multiple occasions. I would love for Joel or Klamezius or Uncle Bob or someone else to fix it and produce a good course on how to create estimates.
Agreed, agile seems the only way, but does indeed require experienced managers. A lecturer once pointed out that business/normal people would always expect some kind of point estimate, they are never satisfied with some kind of distribution or interval. Personally, I would say that this is even more sad than that: the point estimates are always taken at the extreme values, which ever suits the person wanting the estimate more, never the average value.
Of course, all this leads to bad blood between techies and business side: how long will it take? -> probably about 3 weeks, but this requires using a library we haven't used before, so in the worst case even 2 months -> what? so long? get it done in 4 days, this is required the next week -> no, that's not really possible -> make it happen -> it happens and it either sucks when it's delivered at all, so the deadline gets extended anyway to iron out all the bugs or it causes lots of problems in the future.
"And before you downvote, ask yourself: Senseless violence to stop outsiders who are just trying to survive: is it really any less bad when the outsiders are animals?"
I use the equivalent thing on Firefox. Partly so I can use or not use different groups of addons quickly and easily, but also so I can be logged into the same websites multiple times on different accounts.
Or you can import the two images into graphics software like gimp. Invert the colours in the top image, then knock transparency for that layer down to 50%. If the images are identical, you'll just see grey. Any differences will instantly become visible.
It would help if Linux games actually worked on Linux, instead of only on single version of Ubuntu that's usually a few years out of date, and you have to have libraries X, Y and Z installed, only it won't tell you this, so have to trawl through various support forums. And god help you if you're running something truly bizarre, like Debian.
I usually have more success running the Windows version through Wine than I do running the Linux version. I wish I was joking.
That's interesting, I run one of the more esoteric mainstream distros, Arch, and I almost never have problems with Linux games on Steam. I ran into one issue with Hyper Light Drifter and libxcb incompatibility. Otherwise, everything has just worked to my memory. I remember things were a little rougher years ago, have you tried it again recently?
> I usually have more success running the Windows version through Wine than I do running the Linux version. I wish I was joking.
Glad you find it useful! If you are able and want to support the project financially, buying a copy of CrossOver from my employer is the best way to continue funding Wine's development. Our salaries don't come out of thin air ;)
That's one of the benefits of Steam as a gaming platform on Linux. It provides a standard set of libraries that games run against, which match those used on Steam OS and Ubuntu.
Occasionally a developer might use a library outside of the runtime and you could run into an issue, but as you say, 99% of the time games will work under any distro. My situation is the same as yours - I run Arch, and almost every game I've run has worked, besides a couple of small issues.
The downside of this is that you might lose out on some performance gains that you could get from newer libraries, but it's an acceptable compromise for compatibility. A lot of the times devs say they don't want to develop for Linux because it's difficult to test against every distro, but I don't think that's an issue. It's fine to test for Steam OS and the last few versions of Ubuntu, and release it for that. With Steam, it'll almost always work anyway, and if there's a few incompatibilities on more complex distros like Arch or Gentoo, users will usually be able to fix them themselves anyway.
Strange. I run Steam games just dandy on Debian Sid with little to no hassle. The Steam runtime provides a base platform with libraries to build against, which cuts down on the library rot and version mismatches that plagued proprietary gaming on pre-Steam Linux, and I find that gaming on Linux using steam now fits roughly in the 'just works' ballpark.
Sure, I'm technically on my own support-wise, but game devs haven't yet rebuffed me for not having the right OS (I submitted a bug report yesterday for Life is Strange - a GPU issue, not an OS one, and pointing out my OS - and got an encouraging reply from Feral today).
Steam Runtime solves that issue. What you describe however happens with GOG games, since they don't have a Steam Runtime-like system to take care of dependencies.
IIUC it was a bit of both. A unit of work was meant to be short lived, but if a higher priority unit of work came along it would be pre-empted and its state pushed out to a temporary store.
There's a full description in the article, though it's buried a bit far down. Here's a snippet for grep-ability:
if a low-priority job was executing and a high-priority job was scheduled, the low-priority job was suspended while the higher-priority job executed.
