Frostbite is its own sub-company within the E.A umbrella. While Frostbite is used by the titles from DICE and we share parts of our offices, the two companies are rrally distinct for a couple of years now.
Frostbite had roughly 300 employees when I joined 2 years ago.
That's not really giving the full picture of ROSE online!
- The official server (arcturus) is awful to work with code-wise. But all the decently big private servers uses it because at one point we only had the binaries of it and it worked out of the box. When the source started to leak too, it was easier to continue forward with that thing.
- The "simple version" which I am assuming you refer to is os(i)rose. This was the only thing you would get BEFORE the official server got leaked. It had some momentum simply for being there since roughly 2006. It was based on Brett19's code which at the time was a 14-something teenager. The same brett that now works on a fully modern C++ codebase that is decafemu.
- The Modern C++ version which if I remember is worked by few folks from osrose came out something like 2 years ago. Passing 2015, the momentum for the game is close to none. So yes, no one will even spin that codebase.
The official server was stolen due to horrible code-practice (C++-wise and software engineering in general), like having plain SQL-injections when creating characters. Worst! This was one of the reason that made the company (TriggerSoft) behind the game go bankrupt. The game was full of security holes back in 2005. This made the game's economy being broken due to few cheaters, created few horrible roll-backs and such. This drained the player's base from the game.
The "simple C++ server" osrose was also plagued by security issues and technical issues. Up to a point that people preferred to patch the official server with dll-injections + assembly rather than trying to make this "simple C++ server" work.
Not the reason. Especially when the author includes headers like:
#include <stdlib.h>
#include <unistd.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <linux/ip.h>
#include <linux/udp.h>
#include <errno.h>
#include <fcntl.h>
BROWSERS are really dangerous; if you need to keep your machine secure, you shouldn't use any IMHO. By definition, browsers need to be able to access things such as page content. What would stop someone from writing a browser that captures your bank credentials? Nothing.
Obviously no security-conscious user is going to install a bank credential stealing browser. But what about bugs in browsers? If a buggy browser can be made to execute arbitrary code, it is as dangerous as a malicious browser...
At the end, it's a matter of trust in your browser or your extensions.
I see where you're getting at, but with only a handful of browsers* maintained by large organisations eager to protect their reputations vs a plathora of extensions out there, your argument doesn't hold so well.
* I'm assuming usage of Chrome/IE/Firefox/Safari here.
The quoted paragraph is buildup to the fact that AngularJS evals content on purpose, and does not really even try to be secure against maliciously-crafted DOM. Browsers, on the other hand, are designed to resist attacks.
But yes, certainly you need to trust the browser more than an extension.
I dream of the inverse of the react native or electron trend. In this world one would write his application using Qt Quick for all the platforms including the web! Using Emscriptem you would be able to compile your C++ code to asm.js or webassembly and make your application run flawlessly in your browser with WebGL, canvas or HTML5 as a backend. Some people already started working on that: https://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-...
Even using React, Redux, flexbox layout and all these fancy frameworks, I still find the web stack a huge hack that tries to bend HTML and CSS to recreate the feeling of an app (like SPAs). QML is simply more expressive for layouts and bindings.
Here is a demo of a QML sandbox in the browser using Qt+Emscripten if you are interested[1]. And the blog post in which I wrote about it[2]. It's quite big and not very well performing, but Qt might be useful for larger web apps one day.
Funny, I recently looked into using QML & Qt Quick as a lightweight alternative to electron, and although there are some promising factors with the approach, it became apparent that things would take a lot more work and experimentation than simply using electron.
A nimble, feature-complete starter client that is fully scriptable with javascript, i.e. qmlscene without the rough edges, would be ideal.
Is this due to unfamiliarity / learning curve with the technology or limitations found using Qt Quick? Because what you're describing sounds an awful lot like the base example when starting a new Qt Quick application project.
Not if you don't explicitly link against the relevant modules. That is usually done by adding a few entries in the Qt project file (qmake) and then including the headers.
Frostbite had roughly 300 employees when I joined 2 years ago.