Yeah, no disagreement here. I don't get any real benefit from static linking, either. It's just more cumbersome to update anything.

But in the Atom case, I don't think it is a problem of static linking. I'm pretty sure the folders would be just as big if Atom was dynamically linked - which it maybe is, I don't know. Either way, the problem is developers being messy, not the linking type.

View this comment - View article - View full comments

I might have worded that poorly.

I know WHY all the data is there, what I find generally unpleasant is how much of that is redundant data and just general developer carelessness. Take Atom, for example. That editors seems to store all its previous versions since original installation (and all of them are about 400MB).
After deleting all those folders, Atom worked just as well, so all of those folders were completely useless, just hogging up GBs of space.
You cannot blame the OS for that, it really is on the developers. That's what I meant.

View this comment - View article - View full comments

Quoting: ShabbyXLast year I bought an SSD. It was expensive and I got a 256GB one. On windows, I consistently see about 100GB~200GB of OS+programs storage while on Linux all my OS+programs (that is everything excluding /home) takes about 20GB. So yes, that _is_ an issue still. I'm not talking just about games.

Do you honestly think all those data is multiple versions of the same library?
That's utterly ridiculous.

I have about the same amount of SSD usage and regularly use WinDirStat to check what is taking that space.
By far the largest chunk is the user data directory, as every single program (unfortunately usually not configurable) stores its data there. And usually redundant data, too. Browsers, email clients, Windows installer caching nonsense, those are the evildoers.
I don't really have an explanation of why on Windows every programs just spams that folder (while on linux it doesn't?), but it has very little to do with duplicate libs.

You also forget that applications might share the same library, but certainly not the same version. So if 20 apps used the same library, it is pretty likely that they have been built against, let's say, 10 different versions. So even on linux, you will have 10 different library versions lying around. Not that much of a difference any more.
Again, storage is cheap. Except SSDs (for now). If you install all your programs on your SSD instead of just vital data (save games, coding profiles, etc. just usage data) - well, that is your fault.
I install everything on my non-SSD drive (given a choice), and it works just fine, since I'm not running a toaster and if you can afford a rather large SSD, chances are you aren't running one either.

Quoting: ShabbyX- Security: If the library fixes some bug, 20 applications (on windows with 20 different updaters) have to update that dll. We all know (on windows) that not all of them will do it, and the buggy library will end up remaining on your pc.

Not wrong, but you are talking about bugs so important that applications HAVE to update. When does that actually ever happen? Once per year?
Usually, dependencies aren't updated simply because they don't need to be. Because most software doesn't actually deal with security issues.

Quoting: ShabbyX- File System Cache: If the library was shared between the 20 applications, then loading one application after the other would be much faster given that the same .so files are either already in RAM or likely at least in the file system cache. Each application shipping a separate copy of its .so files mean slower application start.

Not wrong, but I think the last time I was actually bothered by an application starting up taking more than a few seconds must have been Win XP. Or one of my first smartphones.
I am a VERY impatient man, and if I'm not bothered, it really isn't bad. Another non-issue.

Quoting: ShabbyX- Memory: Unless the OS does a byte-to-byte comparison of the whole .so files, it cannot know that the applications are using the same .so file, which means running multiple of those applications results in the same .so files loaded multiple times in RAM, resulting in higher RAM usage, as well as worse CPU cache usage.

I'm not really convinced the CPU cache argument is correct. Won't it actually be faster if each program runs its own version of a library as the data will be closer together? At least as a general rule, redundancy improves speed at the cost of space.
The RAM usage... my main PC has 12 GB. I have never seen that filled, and I do work some heavy applications regularly. My laptop even has 16GB. So, yeah... another non-issue.

View this comment - View article - View full comments

This looks like Blood Bowl!
But only with the human team... and a severe lack of blood. Meh.

View this comment - View article - View full comments

[quote=ShabbyX]

Quoting: TheSHEEEPThat aside, the real problem is in fact that they try to force a windowsish distribution on an operating system that has a proper package manager. The libraries on linux actually have pretty decent abi versioning, which means multiple libraries can co-exist and each application would choose to higjest compatible version. Dependency-hell may be an issue for packagers, but the end results are damn nice for users.

Imagine for a moment if Linux games were also packaged like the rest of the system... No more 100 duplicates of .so files like on windows!

First of all, those duplicates were an issue many years ago when disk space was a problem. It simply isn't any more. This is a non-issue. Games nowadays can take any amount of space from 100MB to 60+GB. A few MB more in dependencies simply will not matter.

Also, yes that package managing stuff is nice. But only in theory, where it actually works.
In practice, games (and other software) are not constantly developed and updated with latest versions of libraries. And they shouldn't! Don't change a running system.
So at some point, version X of a dependency WILL rotate out. And then users have to find custom solutions, which is annoying as hell and will cause more people to switch to Windows for the product than it will cause them to fiddle around with their system. Fiddling around is nice for us proggers, but not for average users. This has happened SO MANY TIMES with open source libs that actually are maintained by someone - and so many times more by closed source software.
So either package maintainers have to carry ancient versions of their libs around (possibly even fixing critical bugs in them still if they appear) - and with that outlook, who still wants to maintain packages "properly"? Nobody.
Or developers are forced for a life long update-my-dependencies-game, including possible API changes and whatnot. Hooray.

No, I'm sorry. This package managing stuff may have noble goals, but in practice it is a terrible crux for developers that are actually paid for their work. And it throws more than just a few stones in the way of spreading linux.

View this comment - View article - View full comments

Yeah, the worst part about linux is that app/lib version mess.
Honestly, it should just be like on Windows - look in the executable folder first, done. Would solve all problems, at least for closed source distributions.

Instead you gotta do some tricks like this script or my preferred method - changing rpath of the executable (and recursively the other dependencies).
Both is hacky, though.

But at least there are solutions to this, hacky or not.

The main problem here is Game Maker... really, I'm surprised anyone uses this for actual games and more than just fooling around. There are so many better alternatives.

View this comment - View article - View full comments

Steamworld Dig was great, indeed. But a bit short (I think it took me 7 hours to finish it?).
Hope this one will be a little longer.

View this comment - View article - View full comments

The game has both badgers and mushrooms, so this is a sure purchase.

View this comment - View article - View full comments

Quoting: MayeulCA bit sad to hear this. Would love to hear the complete technical analysis of what happens here. The function names, actual differences, etc.

Is it floating point related, RNG related, other? Wine doesn't seem to have a problem with this. Wouldn't using some parts of winelib help? (It is LGPL, so definitely linkable against).

My guess is that they went for a full deterministic approach (each player is running the full simulation). You can make sure that all players actually have the same results (yes, even with floats and rng) - but only within the same platform.
So far, so good.
What I don't get is why they don't just add an occasional sync to it all to offset the rare case where there would be differences between the platforms. It's not like the game has a great deal of data to sync. It's not a Supreme Commander or something like that.
Afaik, that's how all others do it that go for determinism.

If this is not what actually happens, then I have no idea. There is no logical reason not have a turn-based game work cross-platform.

View this comment - View article - View full comments

Quoting: ExpalphalogI've never understood Civ being a multiplayer game. A single game typically runs me 20+ hours and that's without having to wait for anybody else to take their turn. Is multiplayer faster somehow or do people really sit there without sleep for days on end to play?

We have a weekly online gaming round with some friends going. For a while, we played Civ5 there and actually managed to finish two games.

Obviously not going to work for any "quick session".

View this comment - View article - View full comments