Any idea how the Chinese integration is?
I've played a few other learning games and tested a bunch of apps, but many have the huge problem of not dealing with the fact that learning Chinese doesn't work like learning a western language, as pronunciation and the symbols/characters are (almost) entirely separate things. Some didn't even have pinyin, making them basically entirely useless.

Most learning games I played are little more than interactive dictionaries.
And learning with those is borderline useless as well, as they don't even apply a spaced repetition system.
Claiming that learning words is the most important part of learning a language is almost within lie territory, too. The most important parts are understanding the grammar and flow of the language, especially if said grammar and flow is very different from your own language. Increasing your vocabulary happens naturally over time as you learn the rest - it doesn't work the other way around, knowing a thousand words won't help you form a correct sentence.

I do not know this specific game, but if it is like others, you'd be better off learning basics with specific apps or books (if you feel truly hardcore) and then dive right into a normal game, set to the language you want to learn and play the game with a dictionary/browser open in the background.

View this comment - View article - View full comments

I write reviews for about half the games I play (would leave more reviews on Steam if it didn't have that awful "only great or terrible" system, as half the games simply don't fall in either category).
And in each review I also positively mention the linux support.

View this comment - View article - View full comments

The cool ones always come late to the party.

View this comment - View article - View full comments

Quoting: drmothThe developer described their Linux experience recently on reddit:

For Linux, I would say one thing that really helped us was the Steam Scout runtime. Valve provides an absolutely brilliant kit of tools for running a standard Linux build server inside a chroot. It is self-updating, helps you link all your libraries correctly and gives you a very clear idea of what your Steam environment will look like.

I know not everyone is a huge fan of Steam, but they have done a lot of heavy lifting to support game developers who are working on Linux. Our cost to carry Linux support would have been a lot higher without Valve's help.

https://github.com/ValveSoftware/steam-runtime [External Link]

We have an advantage in that our games are all built in C++, which is surprisingly portable. We feed the same game code files into XCode, Visual Studio and GCC. For us, supporting Linux and Mac OS X helped us improve performance in Windows and reduce bugs on all platforms. Multiple compilers (warnings:all) helped us find bugs faster. Our games are better on our biggest selling platforms because we support the others.

I will say that adding Linux support for our very first title was intimidating and I was worried about permutations. We made compromises that were difficult (initially the Linux port had lower quality mouse support vs. win32) and we suffered some in reviews for this, but generally Linux players were understanding that it was a process. We stuck with it and our Linux users are among some of the most detailed bug reporters we have on the team.

I won't post a bunch of grumbling about the incredibly high cost of Mac hardware, but if a developer told me they couldn't support OS X because the laptops were too spendy I'd probably nod my head and understand. When one of my Linux test boxes suffered a motherboard failure I just restored a backup into a VM and kept right on going while we waited for a replacement board.

Finally some devs who get it.
This should be redirected at all the devs not supporting linux because they are afraid of the "incredible" workload, which is just a myth.

View this comment - View article - View full comments

That this one is more linear is actually a great thing.
One of the worst parts of PoE2 is that its open world doesn't fit its story at all.
The story requires great urgency, yet you spend months on end exploring the entire world before you return to the actual main story and have by then mostly forgotten about it and the "urgency" of it is completely disenchanted and immersion lost.
The game should have opened up gradually as you follow the story, just like PoE1 did.
They tried telling a typical linear story in an open game. Which just doesn't work. At all.

If they tell a linear story in a more linear way here, that means they at least learned something.

Of course, the additional companion being boring is par for the course. All companions in PoE2 are borefests and want to hump you like some weird fan-fiction.
Chris Avellone is deeply missed.

View this comment - View article - View full comments

Well, that was a blast from the past.
I played the original on the N64 - and I did quite like it.

View this comment - View article - View full comments

MY BODY IS READY!

Seriously, these guys have never disappointed.

View this comment - View article - View full comments

Quoting: demonThis gives you the old interface where you can actually go offline for the friends-thingy.

You can still go invisible in the new chat - and set notifications so they won't annoy you if someone starts playing some game.

View this comment - View article - View full comments

Quoting: marcusHow do I update a library in a SNAP/FLATPAK/docker container manually?

I don't know, but I was under the impression that a library installed by SNAP for my program is just available to my program, not to others. I may be wrong, of course. In which case, I really don't see what makes SNAP different from the the good old apt-get, just installing stuff globally for everyone.

Quoting: marcusHow do i keep track of all the different installed versions of a library in different applications?

If you install a game that has some /lib folder with libraries it uses and puts its dependencies there, nothing will be "installed" on your system to be abused by other programs. Someone would manually have to replace the system version with that game's old version (ignoring for a moment that you usually can't just do that), and if someone has the access rights to do THAT, they'd also have the power to just replace the system version with their own binary entirely, making the whole point irrelevant.

Quoting: marcus

Quoting: TheSHEEEPSo what if ffmpeg, the standalone executable, has a security leak in a very weird circumstance? The only thing I do in my application is using it for a very specific use case that is fully under my control.

What about a multiplayer game that uses avatars? This is not under your control. I can inject an infected jpeg that exploits the library there.

And that infected jpg will not get you anywhere, as neither the server you upload to nor the users that will see it later will ever "execute" the .jpg file on their computers.
There is a reason no game allows its players to just upload any file, and if a file is uploaded, it is at the very least converted or checked. Because if that isn't done, that would indeed be an exploit. But not one that would have been prevented by updating a library.

Quoting: marcusThis is not a myth. A number of recognized publications analyzed exactly this problem of the vulnerabilities introduced by bundled libraries. The this one from the reputable OAKLAND security conference as an example: http://legacydirs.umiacs.umd.edu/~tdumitra/papers/OAKLAND-2015.pdf [External Link]

That paper brings examples that completely defeat the point:

The user is running two versions of Adobe Reader, a default up-todate version and a vulnerable version. The attacker convinces the user to install a Firefox add-on that looks benign. The malicious add-on has filesystem access through the XPCOM API [4]. It locates the vulnerable and patched versions of the Adobe Reader library (nppdf32.dll) and overwrites the patched version with the vulnerable one.

Note the bold part.
As soon as the user willingly says "yes" to something, aka gives access rights, everything can happen.
Instead of switching a vulnerable and patched version of some library, the add-on might have as well just put its own version into the system (which would have been a way better idea from the hacker's perspective). That there was a non-patched version somewhere on the user's PC is completely irrelevant as there would be countless other ways.
That the paper tries to put the blame on a fully irrelevant fact just shows that an example has been picked to "prove" the point they wanted to prove to begin with. Just another example of biased "research".
There is no protection for users screwing up their own security.

Quoting: marcusHere some examples from some of the games shipped by steam that I have installed:
ShadowOfMordor, Alien Isolation, Life is Strange, Borderlands 2 --- OpenSSL 1.0.1 14 Mar 2012
Expeditions: Conquistador, Element4L, TIS-100,Oxenfree --- OpenSSL 0.9.8o (32 bit) and 1.0.0g (64 bit)
Pillars Of Eternity --- OpenSSL 1.0.0g
Talos Principle --- OpenSSL 1.0.1i (Last patch release of 1.0.1 was 'u')
Millie The Centipede --- OpenSSL 0.9.8o

These games use the network (at least Borderlands 2 does). Same goes for the steam API here btw. They should really provide security updates for it ... No sane distribution still ships OpenSSL 1.0.1. They all moved on to 1.0.2. Steam itself uses 1.0.2j btw. We are at 'o' as the current patch release --- which is also installed by my distro.

This proves exactly my point.
Nobody, ever, has been or will be hacked or in any way influenced by a game not using the most recent version of OpenSSL. Otherwise, these games would have updated their dependencies, been removed from Steam, made it to the news, etc..
This isn't true for every kind of program or application, obviously. Especially programs that are themselves important parts of operating systems are better served by automatically using the latest version.
But a game and many other kinds of "non-system" software certainly doesn't belong to that category.

Quoting: marcusLets agree to disagree here: You value "It just works" more than "it is secure" and I do the other way around. It's just a matter of different priorities.

I do value my security.
I just also realize that my security isn't in the least reduced by my games coming packaged with their own dependencies. Because there is no realistic way to abuse those dynamic libs lying in some /lib folder of my installed game if I don't go ahead and install shady software from untrusted sources.
What I don't do is put on a tinfoil hat, fearing and preparing for theoretically possible attacks that never did and never will happen to me.

View this comment - View article - View full comments

Quoting: marcus

Quoting: TheSHEEEPBut what is the argument?

It saves space? In a time when space is disk virtually free (except for SSDs, disks are basically giveaways), this is a non-issue.
It obviously works for Windows, and binaries on Windows can be strangely large.

It does obviously not work under Windows. On Windows every application ships its special funny version of ffmpeg or libjpeg for example. Do you think this ever gets updated to fix bugs? I think adapting the Windows approach (and in the end all these snaps, flatpacks, docker images (lets subsume them under "containers") and whatnots are nothing else + a bit more isolation) is a bad thing. It encourages packaging libraries and then abandoning them because "the application works".

"The application works" is the one and only important criterium.
So what if some dependent library gets an update? If the update is important for your application, you can just update it to the recent version.
If the update isn't important to your application (which is the vast majority of cases), you don't need to do anything.

Quoting: marcusIn a distro, a library that has a vulnerability gets either updated or (lacking updates) removed. Sure this breaks you application if ABI breaks or if there is no fixed version, but for good reason! It removes a vulnerability from your system.

But we're not talking about distros here, we're talking about distributing applications. For the OS itself I actually think this variant of relying on external packages makes sense. But not for single applications that do not even want to become part of the system (like games).
So what if ffmpeg, the standalone executable, has a security leak in a very weird circumstance? The only thing I do in my application is using it for a very specific use case that is fully under my control. I don't put my version of it into some system folder, only my application uses it. My application's way of using it isn't insecure at all. Or even better, I use the dynamic library, not the executable, so there's no way anyone can use it directly - if you don't start copying my application's dependencies into your system folder, in which case it is clearly the user's fault and not my problem any more.
A very clear case of my application not needing the update.

Quoting: marcusThey suggest that breaking APIs and ABIs is fine. You can just package the right version and the library dev can then go on developing without having to backport fixes to the old code.

Breaking APIs and ABIs IS FINE. You can take a look at Windows API programming prior to Windows 8 to see the absurd legacy shit Windows devs had to deal with because Microsoft was afraid to break APIs.
And the second sentence is exactly the point - it is less work for everyone involved without any downside. Plus the library dev still has to backport if too many users of the library for some reason cannot switch to a newer version.

Quoting: marcusThis is a huge problem and going that route will invite many of the security holes we find in the Windows world into the Linux world.

This is mostly hearsay without any basis. The reasons linux has less breaches than Windows is first and foremost that it is a smaller target - if it ever becomes big, that will change in an instant - and the second part is that no application can just go and change system files, run cronjobs, etc. without the user's approval.
The "annoying" thing of having to type your password each time is actually way more secure than Windows' popup where you have to click a button.
And lastly, Linux distros are developed differently, with a lot more different eyes on the code. Leaks are more easily found and fixed this way. Open source development is, in the end, more secure.

Quoting: marcusIf you want to do this, be at least honest: statically link the libraries in. Because in the end, all those funny container formats are doing the same.... just not using static linking. Containers are already there. They are called static binaries. No dependency hell required.

This is terrible advice and shows that you have zero experience developing software for end users.
First of all, some software you cannot even link statically without breaching license (FFmpeg, for example, forces you to give away object files of your project, or go open source yourself - check this [External Link]).
Also, software (usually) needs updating. That usually means your own code has changed, and sometimes it means a dependency has updated and you wanted that change.
If you link all your dependencies statically, each and every update will be - depending on the size of your dependencies - gigantic. While space is virtually unlimited, bandwidth unfortunately still isn't. And this propagates - from your repo (if you got binaries there, maybe in a git LFS) to the build server, to the install build server (if separate) to the CDN to every user. Trust me, that is a big no-no.

The only benefit of static linking is that people won't know what libraries you use (if for some reason you want to hide that???) - so it is actually less honest than dynamic linking.

View this comment - View article - View full comments