The runtime is the most interesting part to me. They are effectively replacing the LSB with a "binary LSB" that you can distribute with your game.
By ensuring any application compiled against the Steam Runtime will work on SteamOS, they are providing a solid baseline for developers. From now on, developers will know they can relay on Steam Runtime.
Next thing may be we start to see other applications (not games) to use the Steam Runtime and provide it on non-SteamOS distributions.
How is this news? In Europe obstetricians advise women to start taking folic acid (AKA vitamin B9) at least two months before trying to get pregnant. Isn't the same advice given in America?
Local webapps are easy to port only because they are simple apps. Start adding the kind of complexity and features you have in native app developed in C++, C# or Delphi and we'll talk about porting complexity.
Also, C++, C#, Delphi apps are expected to integrate PERFECTLY in the platform: colors, behavior, etc. Local webapps do nothing of that. No wonder there are no "porting complexities". Ugh.
First we tried to replace desktop apps with webapps and that's why we stood the awkwardness and immaturity of JavaScript, CSS and HTML. At least, we could justify it by saying "you'll be able to access the application from everywhere" (not true: new versions of browsers broke apps everytime)
Now, we are using those same immature and awkward technologies (JS, CSS, HTML) to develop local apps, which could be developed in C#, C++ or even Delphi in a fraction of time, integrate better with the platform and have more direct access to local APIs. I'm sorry but I don't understand this.
And yes, JavaScript, CSS, etc are way immature if you compare with what you can do in C# (WinForms, WPF), C++ (Qt, Boost) or even Delphi. The debugging process in itself is a nightmare.
Na, you are wrong. You can of course package a private copy of Qt for Android/iOS/etc with your application but you can also use the shared copy provided by Ministro:
Fortunately, Hello World apps are rarely distributed. Adding Qt to your application, any real world application, is usually perfectly acceptable. You can even statically-compile the appliation to get a single executable.
I really wonder why people complain about 10 MB when we are using operating systems that take gigabytes of hard disk space and RAM.
In 2013, cross-platform does not mean Win32 and Linux. And the developers of QT broadcast this archaic viewpoint with an exclamation point.
Qt supports these platforms: Linux, Windows, Mac, BSD, OS/2, BeOS/Haiku, Amiga, Android, iOS, Blackberry 10, Symbian, MeeGo/Mer, Tizen, Windows CE/Mobile/Embedded, Embedded Linux, VxWorks, QNX, bare metal (Boot to Qt). In the past, it also supported Solaris, AIX, HP-UX, webOS and there was an experimental port to Amazon Kindle.
The only way to write a more portable application than with Qt is to use HTML, which is unfit for many applications.
I like C++, therefore I use Wt for webapps. Great performance and scalability, great for embedded systems, great for huge systems, great when using third-party libraries (you can use any C or C++ library), etc.
In my experience, Zoho Docs is years ahead of Google Docs. Very few columnists talk about it but it's the only serious "office for web" I would consider for my business. It does everything Google Docs, Hangouts, Drive, etc do, plus a few more things.
Depending on how they implement the "no used games" feature, it may be contrary to European law. There was a ruling against Oracle last year saying it is perfectly fine to resell second-hand software:
The only advantage to actually porting an app using Winelib is to move to another architecture
No, that's not the only advantage.
By using winelib, you can mix the source code of the Windows version with Linux libraries, which means you can incrementally port your application. I. e: 1. Start with a 100% winelib port 2. All winelib port but the database library, which you start using the Linux version 3. All winelib port but the database library and the DRM library...
I'd say Wine on Android is not intended for the end user but for developers. It's not about running Windows x86 applications on Android but about porting Windows applications to Andoroid:
1. As the developer of a Windows application in C/C++, I'll take the source code of my application 2. I'll take the Wine SDK for Android (which does not really exist yet, but wait and see, wait and see!) 3. I'll compile the source code of my application using the Wine SDK for Android. Briefly explained, what this does is use winelib + bionic instead of bionic only. 4. Result is I get a native Android application with a reduced effort
I will of course need to take care about the UI, especially if my application uses Metro-styled custom widgets: those do not fit in Android, but it's a matter of porting the UI of that speficic widget.
So in summary Wine on Android looks more like a cross-platform library (such as Qt or Mono) that implements the Win32 API instead of some other API.
Windows RT apps on Android? I doubt it. Both of them are supposed to be ARM but "ARM" does not really mean anything: there are far too many variations of ARM, even amongst same-generation processors.
That's the right title: "only people with mutations survived".
It's not like humans mutated into something so that they could survive in Siberia but rather that humans who happened to have some mutations could survive and all the others died.
That small difference in wording is what defines natural selection (Darwinism, right) vs traits inheritance (Lamarckism, wrong).
Nokia must be really desperate to try this in order to grow a community for the Lumias. Accessories such as cases are one of the most profitable businesses.
Try GT.M for something different. It's a key-value database, dating back to the 60's, but still hitting hard in healthcare, vets and financial. Great performance. The underlying technology is called MUMPS. Other MUMPS databases (such as Intersystems Caché, closed source) use MUMPS internally, then offer SQL, XML, object, etc layers.
I seriously doubt I've missed the point, given that I was the one who proposed this "port the desktop environment to Android" idea.
KDE is ported to X11 (Linux/BSD/Solaris/etc), Windows (GDI+), Mac (Cocoa), OS/2 (PM), BeOS, etc. Porting to one more graphics layer (Android.View) is not a problem, especially since Qt provides the Qt Platform Abstraction (QPA, formerly known as LightHouse) and we have Qt for Android (AKA Necessitas).
Gnome, XFCE, etc should become more graphics-layer agnostic and do the same as KDE if they want to achieve good performance on Android.
Slashdot Mirror
The air gap is not the solution. Proper isolation, firewalling and virus/malware is.
The runtime is the most interesting part to me. They are effectively replacing the LSB with a "binary LSB" that you can distribute with your game.
By ensuring any application compiled against the Steam Runtime will work on SteamOS, they are providing a solid baseline for developers. From now on, developers will know they can relay on Steam Runtime.
Next thing may be we start to see other applications (not games) to use the Steam Runtime and provide it on non-SteamOS distributions.
Replying to myself: obstetricians here ALSO recommend folic acid for fathers-to-be.
How is this news? In Europe obstetricians advise women to start taking folic acid (AKA vitamin B9) at least two months before trying to get pregnant. Isn't the same advice given in America?
MUMPS is used by the Veteran's Administration, and probably others too. In fact, it became an ISO/IEC standard in 2005.
Intersystems Caché and FIS GT.M are the most popular implementations. GT.M is open source and available under the GPLv2.
http://en.wikipedia.org/wiki/MUMPS
Local webapps are easy to port only because they are simple apps. Start adding the kind of complexity and features you have in native app developed in C++, C# or Delphi and we'll talk about porting complexity.
Also, C++, C#, Delphi apps are expected to integrate PERFECTLY in the platform: colors, behavior, etc. Local webapps do nothing of that. No wonder there are no "porting complexities". Ugh.
Mono. Yes, portable: with Mono, I can develop for Windows, Linux, Mac, iOS, Android and even PS4. Probably more.
First we tried to replace desktop apps with webapps and that's why we stood the awkwardness and immaturity of JavaScript, CSS and HTML. At least, we could justify it by saying "you'll be able to access the application from everywhere" (not true: new versions of browsers broke apps everytime)
Now, we are using those same immature and awkward technologies (JS, CSS, HTML) to develop local apps, which could be developed in C#, C++ or even Delphi in a fraction of time, integrate better with the platform and have more direct access to local APIs. I'm sorry but I don't understand this.
And yes, JavaScript, CSS, etc are way immature if you compare with what you can do in C# (WinForms, WPF), C++ (Qt, Boost) or even Delphi. The debugging process in itself is a nightmare.
Except for that BSD-licensed Qt release would be X11-only, no Windows, Mac, VxWorks, QNX, etc
It's called "dependency" and "dependency management". It's been working for decades on Linux.
Na, you are wrong. You can of course package a private copy of Qt for Android/iOS/etc with your application but you can also use the shared copy provided by Ministro:
https://play.google.com/store/apps/details?id=org.kde.necessitas.ministro&hl=es
Digia is already working on a "Ministro for iOS" to provide a shared Qt copy for all the apps.
Fortunately, Hello World apps are rarely distributed. Adding Qt to your application, any real world application, is usually perfectly acceptable. You can even statically-compile the appliation to get a single executable.
I really wonder why people complain about 10 MB when we are using operating systems that take gigabytes of hard disk space and RAM.
In 2013, cross-platform does not mean Win32 and Linux. And the developers of QT broadcast this archaic viewpoint with an exclamation point.
Qt supports these platforms: Linux, Windows, Mac, BSD, OS/2, BeOS/Haiku, Amiga, Android, iOS, Blackberry 10, Symbian, MeeGo/Mer, Tizen, Windows CE/Mobile/Embedded, Embedded Linux, VxWorks, QNX, bare metal (Boot to Qt). In the past, it also supported Solaris, AIX, HP-UX, webOS and there was an experimental port to Amazon Kindle.
The only way to write a more portable application than with Qt is to use HTML, which is unfit for many applications.
I like C++, therefore I use Wt for webapps. Great performance and scalability, great for embedded systems, great for huge systems, great when using third-party libraries (you can use any C or C++ library), etc.
In my experience, Zoho Docs is years ahead of Google Docs. Very few columnists talk about it but it's the only serious "office for web" I would consider for my business. It does everything Google Docs, Hangouts, Drive, etc do, plus a few more things.
Depending on how they implement the "no used games" feature, it may be contrary to European law. There was a ruling against Oracle last year saying it is perfectly fine to resell second-hand software:
http://www.businessweek.com/news/2012-09-16/second-hand-software-sales-set-to-soar-on-oracle-ruling
The only advantage to actually porting an app using Winelib is to move to another architecture
No, that's not the only advantage.
By using winelib, you can mix the source code of the Windows version with Linux libraries, which means you can incrementally port your application. I. e: ...
1. Start with a 100% winelib port
2. All winelib port but the database library, which you start using the Linux version
3. All winelib port but the database library and the DRM library
I'd say Wine on Android is not intended for the end user but for developers. It's not about running Windows x86 applications on Android but about porting Windows applications to Andoroid:
1. As the developer of a Windows application in C/C++, I'll take the source code of my application
2. I'll take the Wine SDK for Android (which does not really exist yet, but wait and see, wait and see!)
3. I'll compile the source code of my application using the Wine SDK for Android. Briefly explained, what this does is use winelib + bionic instead of bionic only.
4. Result is I get a native Android application with a reduced effort
I will of course need to take care about the UI, especially if my application uses Metro-styled custom widgets: those do not fit in Android, but it's a matter of porting the UI of that speficic widget.
So in summary Wine on Android looks more like a cross-platform library (such as Qt or Mono) that implements the Win32 API instead of some other API.
Windows RT apps on Android? I doubt it. Both of them are supposed to be ARM but "ARM" does not really mean anything: there are far too many variations of ARM, even amongst same-generation processors.
The performance hit is small enough for Chrome, Qt and other projects to use ANGLE to translate Direct3D to OpenGL:
https://code.google.com/p/angleproject/
That's the right title: "only people with mutations survived".
It's not like humans mutated into something so that they could survive in Siberia but rather that humans who happened to have some mutations could survive and all the others died.
That small difference in wording is what defines natural selection (Darwinism, right) vs traits inheritance (Lamarckism, wrong).
Nokia must be really desperate to try this in order to grow a community for the Lumias. Accessories such as cases are one of the most profitable businesses.
There's Mac-on-Linux for that, last updated in 2007:
http://en.wikipedia.org/wiki/Mac-on-Linux
Try GT.M for something different. It's a key-value database, dating back to the 60's, but still hitting hard in healthcare, vets and financial. Great performance. The underlying technology is called MUMPS. Other MUMPS databases (such as Intersystems Caché, closed source) use MUMPS internally, then offer SQL, XML, object, etc layers.
I seriously doubt I've missed the point, given that I was the one who proposed this "port the desktop environment to Android" idea.
KDE is ported to X11 (Linux/BSD/Solaris/etc), Windows (GDI+), Mac (Cocoa), OS/2 (PM), BeOS, etc. Porting to one more graphics layer (Android.View) is not a problem, especially since Qt provides the Qt Platform Abstraction (QPA, formerly known as LightHouse) and we have Qt for Android (AKA Necessitas).
Gnome, XFCE, etc should become more graphics-layer agnostic and do the same as KDE if they want to achieve good performance on Android.
Any desktop environment (KDE, Gnome, LXDE, etc) ported to Android should not use X but whatever Android uses to replace X (android.view)