Quoting: slaapliedje

Quoting: Philadelphus

Quoting: TheRiddickAnd if you look at Earth via a telescope you would think its blue and the surface is blue also. ;)

Which is over 70% correct. ;) But that's a terrible comparison because Mars doesn't have A) vast bodies of liquid water, B) highly-visible and reflective clouds, or C) plant life, all of which make the Earth a vastly more complicated system to analyze.

Quoting: slaapliedjeBesides, from what I'd read it wasn't the ground really that was reddened, but the sky as well. http://3.bp.blogspot.com/-YXyFj3wFBTY/U9WVMrJT9sI/AAAAAAAAFGU/TIIXmyIQHno/s1600/Slide84.JPG [External Link]

http://blogs.discovermagazine.com/outthere/2013/03/20/what-color-is-the-red-planet-really/ [External Link]

That photo is flat-out wrong, as explained in the very article you linked, which explains it well: color balance is a pretty subjective thing. Does any digital camera actually reproduce colors as we actually see them? No. It just records photon counts on a CCD through different filters, which we process with software to try to get colors that roughly approximate what we see with our eyes. Process the resulting image and you can make it look however you like, which is what those "blue sky" images are: skewed with a white balance to make the scene look like it would on Earth to help geologists better identify geological features. The article itself points out that the first photo in it—of a reddish, ocher-ish Mars—is explicitly processed to be as close to "what a typical cell phone camera" would take from the same location.

Yes, it's true that Mars doesn't look quite as saturated red as those first Viking images did (which is what the left image in the linked photo is from). But that's entirely due to advances in digital photo color processing methods, not some shadowy coverup by NASA.

Yeah, my point in linking that article is that pretty much none of the images we've seen really show what the surface of Mars looks like and are 'best guesses' by the imaging team, because (for some inexplicable reason) they don't just get a lens from Samsung or Nokia to get correct pictures :P

Uh? Curiosity for example has a calibration target for its pictures. I guess your post was ironic, but it's sometimes hard to tell.

https://www.nasa.gov/mission_pages/msl/multimedia/pia16798.html [External Link]

View this comment - View article - View full comments

Barring some purely fantastic elements that are best saved for a future dev diary, the scientific aspect in Surviving Mars is realistic

* Sees wind turbines in the trailer *
* Facepalm *

(Well, this could be plausible if it is a game about terraforming, but the atmosphere there is too thin to have any real use; even VTOL aircraft and storms as seen in the trailer are more fantasy than anything else. But then, I think I also saw some open-sky plantations, and shields, so I guess terraforming is a thing :P)
Looks pretty interesting otherwise :D

View this comment - View article - View full comments

The killer feature of this release is android support, really!

It runs pretty well on my phone, and that could be pretty amazing to throw a phone LAN party with some friends :)
(that is, once network games work)

View this comment - View article - View full comments

I am just curious to know the answer: why didn't they use OpenMW's engine? Is this game really that different?
Is it a total recreation of the game (assets and everything), or just the game engine?

View this comment - View article - View full comments

Quoting: MohandevirI will need a how-to to install that thing. Never been able to make it work on Kubuntu. I see the SC icon in the apps but clicking on it does nothing at all.

Do we still have to stop it before launching Steam?

Edit: Oh! The OpenSuse build service is available again... Had the 404 error last time I checked. Going to give it a shot.

I had an issue with gtk apps at some point when I upgraded from plasma 4 to 5 (or something like it).
It turned out it was due to some old KDE themes (to make gtk look like KDE), and everything worked fine after I deleted them.
To check if it is the same with you, try launching zenity. It didn't work for me.

Now, it was a long time ago, so that's probably unrelated to your issue... But I'll leave that here, you never know.

View this comment - View article - View full comments

Worked pretty well on KDE last time I tried. Except for Payday 2.

I usually drag windows to the correct monitor with alt+click if they show up on the wrong one. Some windows require the Steam overlay to be open for this to work.

Also, I think you have less trouble if your primary monitor is on on the left (which has almost never been the case for me, sadly).

View this comment - View article - View full comments

You had a fair share of valid points (I especially agree with the very last one), but I read your post as being quite aggressive, and it seems that I have been misunderstood multiple times. So there goes the counter-multiquote.

Quoting: devnull

"Bundling" can be interpreted differently form statically linking, though. I usually agree with "bundling"/providing the shared libraries along with the executable (and maybe a LD_LIBRARY_PATH "hack" in a launcher script), but not with static linking.

Shouldn't be required if symbol versions are used.

I don't think I understood this correctly. What shouldn't be required?

Quoting: devnull

The only "valid" reason I can think of for statically linking executables is to distribute your program as only one binary. But even then, there are better options (sfxs, flatpack-like files with an embedded filesystem image or archive), and it only concerns a very nice portion of all applications (usually, portable ones).

Security. How secure depends entirely on the attack surface of course but in general preload is easier then binary editing.

I am not sure statically linking actually reduces risks at all (it doesn't prevent code injection at all, but just raises the difficulty a bit). It can also be a security risk, because you then statically linked libs with CVEs in them, and no mean to upgrade them (especially if the developer doesn't care anymore, which is unfortunately often the case).

Quoting: devnull

But yes, carefully pick the libs you bundle. To me, the general rules are:

• Libs everyone have (double check everyone *is* everyone). Don't bundle them, dynamically link.


• Libraries provided by a third party as part of a special contract with your studio/company: provide them as .so

Redistribution rights may prohibit it.

I didn't mean it that way. What I meant is that you had to provide them (but preferably as shared objects, so that they can be upgraded later by the consumer, if you care about your consumer, that is ;) )

Quoting: devnull

Internal libraries developed by your studio/company: statically link them, perform a monolithic compilation with them or provide them as .so depending on your needs or update/modding/debug policy

Don't quite see the difference between this and above. If it's not public IP, there's no reason not to protect it.

The difference here is that if that's *your* IP, *you* are the one who is going to update it. Contrast this to the case where ex. Valve releases a steamaudio fix. If they do, the customer can upgrade the .so (that's done transparently trough Steam, usually). If that's your lib, you will probably release an update to the game when you update the lib (if you are a good guy). Of course, this is only useful when the company producing the game goes downhill, and that's not the use case most companies care most about.

Quoting: devnull

"wild" libraries that are not very well maintained, or can break the API (early development version, for instance): avoid them, you will probably run into problems a few years down. If you must use them, provide them, don't statically link them but prefer them to the host libraries. That way, you make it possible to tinker with them if it stops working, but they should work the same way regardless of the system.

Invitation to disaster. There are MANY libraries that aren't backward compatible. Pulse for example. Simply including or not including doesn't negate other dependencies elsewhere.

Avoiding poorly maintained libraries is an invitation to disaster? Come on, tell me you didn't say this just to contradict me. Breaking the ABI/API is ok when the library is well versioned. That way, the system can provide the different versions, or compatibility shims.

Quoting: devnull

Prefer open source libraries whenever possible (still avoid the previous case): generally well maintained, people can fix them easily if they are broken a few years down the line, or write wrappers for them in the worst case.

Bit irrelevant. There are quite open source libraries that are not backward compatible and outright refuse to run otherwise. Pulse, dbus, etc.

I must confess that I didn't really get your sentence.

Quoting: devnull

Whenever possible (and that's usually a more general software rule), avoid complex dependencies. Both for the libs you choose (they should depend on a minimum of other libraries) and for your application. Bonus points if you can enable/disable some dependencies via a config file (though you may have to manually load your libraries. It's not *that* complicated, and as a bonus, you can gracefully fallback and disable features)

Also a bit irrelevant. The linker has no problems resolving dependencies. There is a bit of overhead at runtime though.

As far as I know, the linker has to link every dependency at runtime, before even starting to execute the program. You have to dlopen() if you want to handle complex feature toggling.

View this comment - View article - View full comments

"TheSHEEP Likes this article" -- :P

This game looks entertaining, I like the fact that they have to carry the sheep out.

Is there a way to bring the sheep back? (Like dispatching a vehicle to do so, which might get harmed by the incoming troops).

View this comment - View article - View full comments

Quoting: Lakorta

Quoting: MayeulCLooks like some people went all the way to reverse engineer the steam platform: https://github.com/SteamRE/SteamKit [External Link]

They also have a "Depot Downloader [External Link]". Which makes it a fully open-source (afaik) way to download steam games. Now, if only we could get a shim to make wine games work with the Linux client, that would be great :)

Someone tried to do something like that once (https://github.com/sirnuke/steambridge [External Link]). Unfortunately that project is dead (also I never tried it out so I don't know how well it worked).

Ah, thanks, I've been trying to find again the name of that project for quite some time. Starred it. It's a shame the project has been discontinued, though.

View this comment - View article - View full comments

Glad to see some progress on this.

To VP: How can we apologize to CD Projekt Red for our initial reaction regarding The Witcher 2 port? I am longing for TW3, and you have proven that eon has come a long way in terms of performance/playability :)

View this comment - View article - View full comments