• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

PS3 Web Browser Discussion - big upgrade rumoured for long time, but no concrete news

Kysen

Member
As long as PS3 is stuck with its ram setup there is no way it can run a modern mobile browser. Even low end Androids have more memory than the PS3.
 
TBH I have no idea what "being technically Gnome" means. If I use library A in my project does that project become "technically" "library A"?

Mono is simply something that allows you to run Microsoft .NET stuff on other platforms, including Linux, which is much cheaper - and better in many cases - to maintain than Windows (and we can still use the MS development tools which are actually pretty good). It uses Glib for low level functions and it also has C# wrappers for higher level Gnome stuff like GTK (which we never used). It is not a "Gnome engine", it is not technically a part of Gnome, and the Glib functionality could technically be replaced with other libraries. As far as I know.

It is a set of tools (most importantly a CLR runtime + standard libraries) that allows you to run .NET code on any platform. Who developed it does not make it "Gnome". No idea what "engine" would mean in this case

Mono has nothing whatsoever to do with that. It uses low level functions from Glib because I guess it was convenient and the implementation was already there and the developer who was in both projects knew this library well. Happens all the time. It also provides a c# "wrapper" for other Gnome functions but that doesn't make it "technically Gnome" either.
Please understand that I don't disagree with your last post.

For a browser on a phone or to support applications you want the smallest memory footprint. The Gnome project not only optimized and chose the best libraries they implemented Zero copy techniques to conserve battery and increase performance. This is seen in Glib and the main event loop for Mono is in Glib which is what makes it technically a Gnome application and the Gnome project is built using cross platform libraries.
 
As long as PS3 is stuck with its ram setup there is no way it can run a modern mobile browser. Even low end Androids have more memory than the PS3.
Android platforms keep a number of applications in memory at the same time and that uses most of the memory.

The PS4 only has 256MB of memory for the system UI memory and some apps. It's going to be crazy as with two GPUs and two memory pools in can shift out of IPTV mode if it's running a WebGL game or webAR for instance and use the larger GPU and memory.
 
Please understand that I don't disagree with your last post.

Disagree? I'm either right or wrong, I don't see much room for subjective opinion here tbh. Or maybe I'm just not getting something.

For a browser on a phone or to support applications you want the smallest memory footprint. The Gnome project not only optimized and chose the best libraries they implemented Zero copy techniques to conserve battery and increase performance. This is seen in Glib and the main event loop for Mono is in Glib which is what makes it technically a Gnome application and the Gnome project is built using cross platform libraries.

Sorry, what is the "main event loop for Mono"? I've never heard of it and I don't know what it being "in Glib" could even mean? (To be clear: afaik, it doesn't have one. GTK apps have one and if Mono was a GTK app, *which it absolutely isn't*, your sentence would make sense.)
 
Sorry, what is the "main event loop for Mono"? I've never heard of it and I don't know what it being "in Glib" could even mean? (To be clear: afaik, it doesn't have one. GTK apps have one and if Mono was a GTK app, *which it absolutely isn't*, your sentence would make sense.)
Note:
libc = POSIX basic IO and basis for all operating systems which follow the same standards and try for the same APIs.
glibc = GNU linux version of libc
Glib = Gnome and designed to support cross platform portability. It contains some of the glibc calls but adds more routines not in libc/glibc.

Edit from the Mono web site:

Mono and GNOME
How is Mono related to GNOME?
In a number of ways. This project was born out of the need of providing improved tools for the GNOME community, and will use existing components that have been developed for GNOME when they are available. Mono team members work actively on the Gtk# project: a binding of the GNOME class libraries for .NET and Mono.

Has the GNOME Foundation or the GNOME team adopted Mono?
We hope that the tools that we will provide will be adopted by free software programmers including the GNOME Foundation members and the GNOME project generally.

Should GNOME programmers use Mono?
Yes, we believe that Mono is a great development platform for building applications for the GNOME desktop. Mono includes Gtk# a .NET binding for GTK+ and various GNOME libraries which together with C# and the System libraries provide developers with great productivity for building graphical applications especially when compared to GTK+ or Java Swing.

Will Mono include compatibility with Bonobo components? What is the relationship between Mono and Bonobo?#
Although we had plan to support Bonobo, we have not yet done any work on this area and it is no longer a high priority.

Does Mono depend on GNOME?
No, Mono does not depend on GNOME. We use a few packages produced by the GNOME team like the ‘glib’ library, we also use other third-party open source libraries like Cairo and ICU.
 
My Stuff Everywhere™ – Your Content On Any Screen

Listed in the Cable Labs website with an Android implementation.

Essentially it's a set of protocols and token generation that makes it easier to setup media streaming. The PDF I linked above gives an easy to understand explanation and we might see something like this supporting Playstation platforms. I.E. The user implements it and it discovers the platforms in the home able to display media and with what resolutions or restrictions and asks if the user wants to stream them. After the first sign-on tokens are accessed and as far as the consumer is concerned it's automatic. It supports user owned media and cloud services...all your media anywhere.

My Stuff Everywhere offers several novel features:
1. An integrated and convenient way for users to access all of their content, wherever they are.
2. One time authorization of access to content sources and management of resulting access tokens for later use.
3. Support for multiple, standard authorization protocols.
4. TLS security for all user and content access credentials.
5. Support for multiple discovery and launch protocols.
6. SharedDOM for multi-screen user interfaces between the personal and shared devices.
7. 100% use of HTML5, JavaScript and CSS for all personal and shared device application user interface and functions for write once, run anywhere development efficiency.

Expanded Set of User Content Sources
Many cloud user content sources offer an authentication API and are candidates for MSE services, e.g. Instagram, Flickr, Google Drive, Google Play, Tumblr and Twitter. An MSE app can make all of these available and offers the ability to integrate content access across sources in novel ways that appeal to users.

Add Pay TV Web Services
A pay TV service provider can use MSE both to deliver its services to discovered screens and to integrate user content sources. The service providers has fine-grain control over the exact set of discovered screens eligible for reception of its paid service, for example only in the subscriber’s home, only in certain geographic areas, limited to a certain number of uses per time period,
 
There, you yourself quoted it:

"Does Mono depend on GNOME?
No, Mono does not depend on GNOME. We use a few packages produced by the GNOME team like the ‘glib’ library, we also use other third-party open source libraries like Cairo and ICU."

Again, this is sadly enough my job, and I can recognise when someone just throws words around and appears knowledgeable but doesn't actually really understand what they're saying. I'm actually pretty OK at that too myself.

To make it clear: Mono has *no* such thing as a "main event loop" and so it is not "in glib". Mono is neither "technically" nor in any other way a "GNOME application". It is a free and open source implementation of parts of .NET. We've been using it since 1.0 to run our server side stuff. I also know what POSIX, libc and glibc are quite well thank you :-D
 
There, you yourself quoted it:

"Does Mono depend on GNOME?
No, Mono does not depend on GNOME. We use a few packages produced by the GNOME team like the ‘glib’ library, we also use other third-party open source libraries like Cairo and ICU."

Again, this is sadly enough my job, and I can recognise when someone just throws words around and appears knowledgeable but doesn't actually really understand what they're saying. I'm actually pretty OK at that too myself.

To make it clear: Mono has *no* such thing as a "main event loop" and so it is not "in glib". Mono is neither "technically" nor in any other way a "GNOME application". It is a free and open source implementation of parts of .NET. We've been using it since 1.0 to run our server side stuff. I also know what POSIX, libc and glibc are quite well thank you :-D
I have a question? The PS4 has Glib and in the webkit disclosure uses GTK APIs but rewrites the Cairo script for the GTK chrome and calls it POSIX. Does this make the Playstation Gnome or POSIX? They did replace many of the libraries GTKwebkit uses with a different License version but kept the same APIs as the Linux Vidipath reference standard used by Comcast and Cable Labs is Gnome/GTKwebkit using Gstreamer with Cairo bindings and the DLNA server is Rygel using again Gstreamer.

I don't want to incorrectly say the Playstation desktop and browser is Gnome. What makes it Gnome, using Glib? If that is the case then technically mono is Gnome. If not Gnome then QT isn't gnome ( I realize it isn't technically considered Gnome) even though it also uses Glib. The PS3 uses the same APIs but doesn't have at this time Glib and it can't support apps that can talk to each other using dbus like a contact/Friends app that can be used with a Chat program. It's all custom Sony but using the GTK webkit APIs for the browser..is this Gnome? The primary difference between QT and GTK or POSIX are in the scripts that use Cairo for the look and feel of the desktop. Is this how you want to define Gnome....See how picky this is..... The Gnome project was more than a desktop look and feel as evidenced by other Desktops using the same Glib created for Gnome.

And I realize that I'd call a Delorean a GM car as the motor was from GM, the thing that makes it a car not the Delorean Stainless steel and chrome skin.
 
I have no idea about the PS4 or user interface stuff *at all* which is exactly why I'm sure that Mono is not a "GNOME application" :) I'm just working on "business" crap in .NET (hey, at least it's pretty simple and the tools look ok) - and Mono enables us to use the code I develop on Windows on Linux servers. What I do *only* communicates with other programs, and *even that* it does through mechanisms I don't even care about (I only have to care about the "abstract" API, not the underlying implementation or what other code uses it...well, theoretically at least, as in practice there do exist restrictions depending on what kind of application calls these APIs). With that said, here's my explanation.

Glib is a set of *very* general and *very* low level functionalities, most importantly data structures, threads, messaging and queues etc. These are implementations of very standard and common functionalities that are used by all kinds of software. You can find a lot of these problems and algorithms in textbooks and afaik, you study most of them in engineering school and should be able to understand and implement many of them (how well and efficiently is another question entirely, of course).

Gnome is closer to the other end of the complexity spectrum: afaik (and again, this is not my area) it is about how high level end user applications look and work and about making them easier to develop. It is made up of toolkits and libraries (like Glib and GTK+), higher level applications and even design guidelines. They're at opposite ends (except not really "ends") of the spectrum of "complexity" or however you call this. Gnome uses Glib for some stuff, along with I guess quite a few other libraries. I think what makes something a "Gnome application" is at the very least being able to integrate into the Gnome desktop, which is probably more or less automatic if you use particular libraries.

POSIX is another set of standards that encompasses low level unixy stuff (only including low level user interface stuff). As far as I know, you can conform to POSIX standards and provide a Gnome desktop environment at the same time. Like a food product can conform to food safety guidelines *and* organic certification guidelines at the same time.

Again: I do not know what makes an application a "Gnome application" but I think at the very least it has to integrate into the Gnome desktop environment - and Mono is completely independent from that, or any other such environment.
 
I have no idea about the PS4 or user interface stuff *at all* which is exactly why I'm sure that Mono is not a "GNOME application" :) I'm just working on "business" crap in .NET (hey, at least it's pretty simple and the tools look ok) - and Mono enables us to use the code I develop on Windows on Linux servers. What I do *only* communicates with other programs, and *even that* it does through mechanisms I don't even care about (I only have to care about the "abstract" API, not the underlying implementation or what other code uses it...well, theoretically at least, as in practice there do exist restrictions depending on what kind of application calls these APIs). With that said, here's my explanation.

Glib is a set of *very* general and *very* low level functionalities, most importantly data structures, threads, messaging and queues etc. These are implementations of very standard and common functionalities that are used by all kinds of software. You can find a lot of these problems and algorithms in textbooks and afaik, you study most of them in engineering school and should be able to understand and implement many of them (how well and efficiently is another question entirely, of course).

Gnome is closer to the other end of the complexity spectrum: afaik (and again, this is not my area) it is about how high level end user applications look and work and about making them easier to develop. It is made up of toolkits and libraries (like Glib and GTK+), higher level applications and even design guidelines. They're at opposite ends (except not really "ends") of the spectrum of "complexity" or however you call this. Gnome uses Glib for some stuff, along with I guess quite a few other libraries. I think what makes something a "Gnome application" is at the very least being able to integrate into the Gnome desktop, which is probably more or less automatic if you use particular libraries.

POSIX is another set of standards that encompasses low level unixy stuff (only including low level user interface stuff). As far as I know, you can conform to POSIX standards and provide a Gnome desktop environment at the same time. Like a food product can conform to food safety guidelines *and* organic certification guidelines at the same time.

Again: I do not know what makes an application a "Gnome application" but I think at the very least it has to integrate into the Gnome desktop environment - and Mono is completely independent from that, or any other such environment.
Glib contains some of the glibc low level routines but it also contains dbus, ICE and Telepathy. Three very important lower level libraries for sharing data between desktop applications (dbus) and setting up a video and audio chat (telepathy) past firewalls (ICE) without needing a Sony server. Your application may not need those libraries. Telepathy is generally used with Gstreamer another common Gnome library.

640px-GStreamer_overview.svg.png


If you look at the Peripheral HW accelerators in pink at the bottom right, AMD UVD, VCE and Trueaudio are listed. AMD's UVD and Trueaudio use Xtensa DPUs as does the XB1 and PS4 (confirmed for audio and if you want to use Cadence libraries for audio you will use Cadence Xtensa IVP for video). A Linux or Unix platform that uses Gnome APIs should use Gstreamer APIs. About the middle of the slide it says: HW accelerated plugins shunt execution to accelerated DSPs and the result back.

Again, Gstreamer is not listed in the PS4 about or Open Source software lists but it's very likely that the PS4 follows the same APIs and handles using the Xtensa accelerators the same way that AMD does for the Linux kernel example they provide. Because it's a game console, going any lower and it could be custom routines to access the accelerators and of course the accelerators themselves will use codec libraries likely provided by Cadence-Tensilica.

Every codec, compression and DRM stream will likely use the Xtensa DPUs as HW accelerators.
 

KyleCross

Member
...which is really a shame because the OS is slower than ever and the store is one of the most frustrating experiences I have on anything. It's poorly optimized. It didn't have to be that way.

Yes, it's terrible. It didn't use to be, it use to be perfectly usable but a couple years ago something went horribly wrong... It is pretty much impossible to use it, it takes forever to load anything and it often freezes the entire PS3 for me.

I now exclusively use the webstore, and it seems that is the way Sony wants it as even the PS4 store is difficult to find things. It's awesome to go to the webstore and literally any device I want and then tell it to download a product to the actual system. There is literally not reason to go into the PS3's store.

Speaking of the PS3's web browser, it is crap but I do owe it a thanks. I had an old crappy rent-to-own computer from 2001 to 2011 until I got a laptop in 2011, but for the last couple years the old computer was pretty much unusable. It was so slow doing anything, it'd take minutes for a web page to load and it'd take over 15 minutes to even boot up. I eventually gave up and used the PS3's web browser for all my internet needs... which is basically all I did. I lost count of how many hard freezes my PS3 had and how many tricks I learned in order to access certain sites (like twitch streams) but it worked and I thank it.
 

LordOfChaos

Member
A big update to it now near the end of its life would be funny in a way.

Is it true it was using a single SPU? Why? Only one was locked for OS use, why could it not use the rest of the processor?

Main system memory was probably a bigger issue though I guess. And was it GPU accelerated?

I can imagine rendering the web would be no fun for a core without branch prediction and in-order, since you can't force the web to unroll loops or anything like that.
 

Diablos

Member
Yes, it's terrible. It didn't use to be, it use to be perfectly usable but a couple years ago something went horribly wrong... It is pretty much impossible to use it, it takes forever to load anything and it often freezes the entire PS3 for me.
They are no doubt leaving it gimped to give people even more incentive to buy a PS4. It's so incredibly stupid. They should just strip everything down and do a minimalist store, or at least give you the option.
 

KyleCross

Member
They are no doubt leaving it gimped to give people even more incentive to buy a PS4. It's so incredibly stupid. They should just strip everything down and do a minimalist store, or at least give you the option.

I doubt that. The PS3 store started going down hill before the PS4 was even announced. They redesigned it and made it more fancy a few years ago and that just made it the mess it is now. It use to be very minimalist.
 

Bold One

Member
kind of pointless, the ps4 and the vita are in dire of need of web updates. I dont care what anyone says, I need my flash player
 

Luigiv

Member
kind of pointless, the ps4 and the vita are in dire of need of web updates. I dont care what anyone says, I need my flash player

Won't happen, regardless of how much you beg. Even if Sony wanted to, Adobe refuses to port the code to any new devices. It's only a matter of time before Adobe cuts the cord of the PC version too (give it a couple more years).
 
Keep cable but lose the box with VidiPath, a new wireless way to watch

DLNA-Vidipath

Moore told us the first approved VidiPath devices will begin hitting the market as early as the second quarter of this year.

“there are (game) consoles that I know of that will be VidiPath certified as well.” With Sony in the mix, it’s not a stretch to assume the PS4 could incorporate the technology. And DLNA Marketing Manager Katie Gengler also hinted that TV manufacturers are looking into firmware updates that could potentially make some existing smart TVs compatible with VidiPath. While we’re still waiting for the VidiPath veil to be lifted, it appears the protocol will hit the ground running once it premieres in the next few months.
And the PS3 is getting Playready DRM which I think means it will also be a certified Vidipath platform.

Consumers might soon be able to view all of their subscription-TV content on multiple TVs in the home without renting additional set-top boxes, thanks to smart TVs and set-top boxes equipped with wireless VidiPath technology, the Digital Living Network Alliance (DLNA) said. The standards organization expects the first VidiPath-certified CE products to become available to consumers late in the first quarter.
 
Glib contains some of the glibc low level routines but it also contains dbus, ICE and Telepathy. Three very important lower level libraries for sharing data between desktop applications (dbus) and setting up a video and audio chat (telepathy) past firewalls (ICE) without needing a Sony server. Your application may not need those libraries. Telepathy is generally used with Gstreamer another common Gnome library.

You are right that ICE, Glib, Telepathy and GStreamer are used in GNOME Desktop, but that doesn't imply that they are GNOME on their own.

Playstation using GTK+ or Glib doesn't make it "GNOME", just like using WebKit (or a variant of it) doesn't make it Mac.

Also GNOME, GTK+ and Glib aren't interchangable terms. GNOME depends on and GTK+ depends on Glib.
 

Diablos

Member
I doubt that. The PS3 store started going down hill before the PS4 was even announced. They redesigned it and made it more fancy a few years ago and that just made it the mess it is now. It use to be very minimalist.
But even when it first launched it wasn't as bad as it is today (the "fancy" store that is). I'm not saying it's a conspiracy or anything, just that they are not going to spend time or money optimizing it on an old console. It's PS4 marketing in disguise, intentional or not.
 
But even when it first launched it wasn't as bad as it is today (the "fancy" store that is). I'm not saying it's a conspiracy or anything, just that they are not going to spend time or money optimizing it on an old console. It's PS4 marketing in disguise, intentional or not.
The issues with the PS3 Store started when they moved to the WebGL version, the PS3 supports some of the webGL calls with a game engine not OpenGL. They don't use openGL because an overflow or something...creates a security vulnerability and the PS3 Fat hidden keys were hacked. There is a rumor that Sony discovered this vulnerability before the Slim was released and the hidden encryption keys in Cell were added to with a second set in Slim and later versions.

Using the second set of Keys would create a fragmentation of the OS between the Fat and the Slim versions and the Apps would all have to be rewritten. There is also no revocation ability used with Marlin, no detection of tampering provided to third party apps like Netflix.

Sony announced they were going to use Playready in 2011 as the FCC mandate for DLNA CVP2 was announced late 2010 and Playready chosen by the industry soon after. Playready reached 1.0 status Oct 2014 so Sony would not have used Playready in the PS3 until that point in any case. All Apps like Netflix on all platforms that the manufacturer hasn't embedded Playready have Netflix including their own DRM.

The PS3 has Marlin DRM native to the PS3 OS. It supports something similar to WMDRM10 and can be used for the DLNA DTCP-IP streaming DRM but is not strong enough for IPTV DRM. Moving to Playready has a DRM subset called WMDRM10 used for DTCP-IP and a superset called Playready for IPTV DRM. With Playready DRM when anyone uses the PS3 for IPTV it connects to a Playready server that can revoke both the WMDRM10 and Playready superset if tampering is detected or the current firmware is compromised.

I believe Sony has not updated the PS3 XMB waiting on the Playready update. If this is the case and Sony porting Playready to the PS3 at this late date seems to indicate this, we should see a faster Playstation store, faster apps and XMB with functionality similar to what's coming for the PS4>>>> HTML5 Apps replacing Chat, Friends list...everything. IF this is the case then Glib needs to be in the PS3 too.

Imagine the PS4 using ooVoo unable to video chat with PS3s yet is able to Playstation Now (Game Stream PS3 games). There is even more coming for the PS4 that makes the PS3 DEAD if it's not updated after Playready.

Sony is counting on the large number of PS3 and PS4 Game consoles to support Vidipath (DLNA CVP2) and provide a startup market for their Playstation Vue, Playstation Now, Playstation games and APP store. A totally refreshed PS3 with low power modes for IPTV would also come with the total rewrite to the PS3 OS not before. Playstation Now and markets like China opening up to game consoles creates a market for Vidipath STBs and a cheaper PS3.

Sony not incrementally updating features like DLNA to the three box model doesn't make sense unless they were waiting for WMDRM10. The PS3 having a seperate DVD, Blu-ray, DLNA and IPTV player does not make sense except that the PS3 evolved over years with each being patched in as blocks not integrated into a player that contained support for all media that needed DRM. That has to change and requires a total rewrite to the PS3 XMB....everything. If the PS3 firmware is compromised pre-Playready then DVD, blu-ray and IPTV are compromised, post-Playready all would be better protected in the event the PS3 firmware is compromised.
 
You are right that ICE, Glib, Telepathy and GStreamer are used in GNOME Desktop, but that doesn't imply that they are GNOME on their own.

Playstation using GTK+ or Glib doesn't make it "GNOME", just like using WebKit (or a variant of it) doesn't make it Mac.

Also GNOME, GTK+ and Glib aren't interchangable terms. GNOME depends on and GTK+ depends on Glib.
Gnome is this from 2011, read the entire post and think about PS4 features. Since then dbus and Telepathy were moved into Glib, Xwindows depreciated with Wayland taking its' place and everything optimized with code taken from Android libraries with the same function. Pango which incorporated Harfbuzz is now Harfbuzz.

gep.png


Using APIs similar to Gstreamer allows third party Playready middleware.

http://www.discretix.com/microsoft-playready/ said:
Discretix Playready DRM Client is designed to address the security vulnerabilities of open operating systems. The client supports all versions of Android as well as multiple Linux flavors[/B]. For native Linux devices, the Discretix API allows quick integration into HTML5 based browsers using the EME interface and integration with a customer-specific media framework such as GStreamer and others.
With a blu-ray player and required for DLNA CVP2 platforms is Java support. Both Javascript (with Extended Media Support = supports APIs that Playready can use) and Java require native libraries with APIs that follow industry standards. Sony chose to follow what amounts to Gnome APIs using libraries, like Android, that have an open source licence that doesn't require disclosing source code changes. These are the same APIs in the 100% vanillia Gnome reference RDK that Comcast and Cable Labs follow for DLNA CVP2.

I keep mentioning this because it supports Sony had plans for the PS3 and the entire Playstation platform when they first sent a PS3 developer package to Collabora in 2007. Collabora had just ported Gstreamer with Cairo binding to GTKwebkit. The Javascript disclosure Sept 2010 was for a GTKwebkit with the GTK chrome rewritten and named POSIX.

To this point the PS3 hasn't been an open to third party apps platform. The PS4 is designed to be a open to third party HTML5 apps and likely Java too.

Everyone is making assumptions about the PS4 based on how the PS3 got updates which might only be because of a DRM security flaw.
 

MRORANGE

Member
Sony is counting on the large number of PS3 and PS4 Game consoles to support Vidipath (DLNA CVP2) and provide a startup market for their Playstation Vue, Playstation Now, Playstation games and APP store. A totally refreshed PS3 with low power modes for IPTV would also come with the total rewrite to the PS3 OS not before. Playstation Now and markets like China opening up to game consoles creates a market for Vidipath STBs and a cheaper PS3.

Realistically what are the chances of seeing a new PS3 model? The latest revision is down to 22nm? If I recall?
 
Realistically what are the chances of seeing a new PS3 model? The latest revision is down to 22nm? If I recall?
Nope, latest Known to the public Cell version is 45nm. The 2010 Xbox 720 leaked powerpoint had a 22nm Xenon (Xbox cpu) for BC but that projection for 28nm X-86 APU, HBM, 2.5D assembly and 22nm Xenon was too optimistic. There is supposed to be work on a 22nm Cell (IBM Linkedin post) but we haven't even heard any rumors for a refreshed PS3 with any kind of reduction in node size. Early 2011 a news article quoted Sony skipping 32nm and the author speculated that they would support 22nm.

There are several credible rumors for a Xbox 360 mini from 2013 that state that it requires Windows 10 and will game stream to the XB1 and PCs. We find as of last month that this is a feature of Windows 10. Windows 10 also supports ARM and X-86 in the same platform with AMD APUs and supports common apps that work on both ARM and X-86 platforms.

China opening up to game consoles as Vidipath STBs can create a massive demand for a refreshed cheaper PS3 but it needs Playready DRM (which Sony is porting to the PS3), IPTV power modes and to compete with the rumored Xbox 360 mini, game streaming. Both game streaming and IPTV power modes would be supported by a ARM block which can support TEE level DRM/security. The PS3 OS should be similar to the PS4 OS and the Xbox 360 mini is likely also going to use Windows 10 just like the XB1.

So if there is to be a Xbox 360 (diskless) Mini and a refreshed PS3 with 22nm Cell the prerequisites are in place as of this year.

Prerequisites:

Playready 1.0 ----- Oct 2014
Playready DLNA certification starts ----- September 2014 with platforms released end of Q1 2015 at the earliest
Windows 10 ----- June-Nov 2015 (Xbox)
HTML 5.0 with W3C extensions for Vidipath ----- March 2015 (GTKwebkit used by Playstation) guess based on other platform releases end of Q1 and rumors
FCC mandate for DLNA CVP2 = Vidipath ----- June 2015
China opening up to Game Consoles ----- End of 2014 with DRM (servers) and Region Locking creating delays
22nm PD-SOI and FD-SOI or Global Foundries 28nm SHP Silicon ----- mostly ready at the end of 2013
2.5D assembly and Interposers as well as HBM ----- ready at the end of 2014
Xtensa IVP processors ----- Ready end of 2012
Xtensa HiFi processors ----- ready
h.265 codec ----- support in Windows 10, Android L and if in Windows 10 supports AMD's kaveri for h.265 which uses a Xtensa processor then Cadence has the libraries to support the same on the PS4.
 

Diablos

Member
The issues with the PS3 Store started when they moved to the WebGL version, the PS3 supports some of the webGL calls with a game engine not OpenGL. They don't use openGL because an overflow or something...creates a security vulnerability and the PS3 Fat hidden keys were hacked. There is a rumor that Sony discovered this vulnerability before the Slim was released and the hidden encryption keys in Cell were added to with a second set in Slim and later versions.

Using the second set of Keys would create a fragmentation of the OS between the Fat and the Slim versions and the Apps would all have to be rewritten. There is also no revocation ability used with Marlin, no detection of tampering provided to third party apps like Netflix.

Sony announced they were going to use Playready in 2011 as the FCC mandate for DLNA CVP2 was announced late 2010 and Playready chosen by the industry soon after. Playready reached 1.0 status Oct 2014 so Sony would not have used Playready in the PS3 until that point in any case. All Apps like Netflix on all platforms that the manufacturer hasn't embedded Playready have Netflix including their own DRM.

The PS3 has Marlin DRM native to the PS3 OS. It supports something similar to WMDRM10 and can be used for the DLNA DTCP-IP streaming DRM but is not strong enough for IPTV DRM. Moving to Playready has a DRM subset called WMDRM10 used for DTCP-IP and a superset called Playready for IPTV DRM. With Playready DRM when anyone uses the PS3 for IPTV it connects to a Playready server that can revoke both the WMDRM10 and Playready superset if tampering is detected or the current firmware is compromised.

I believe Sony has not updated the PS3 XMB waiting on the Playready update. If this is the case and Sony porting Playready to the PS3 at this late date seems to indicate this, we should see a faster Playstation store, faster apps and XMB with functionality similar to what's coming for the PS4>>>> HTML5 Apps replacing Chat, Friends list...everything. IF this is the case then Glib needs to be in the PS3 too.

Imagine the PS4 using ooVoo unable to video chat with PS3s yet is able to Playstation Now (Game Stream PS3 games). There is even more coming for the PS4 that makes the PS3 DEAD if it's not updated after Playready.

Sony is counting on the large number of PS3 and PS4 Game consoles to support Vidipath (DLNA CVP2) and provide a startup market for their Playstation Vue, Playstation Now, Playstation games and APP store. A totally refreshed PS3 with low power modes for IPTV would also come with the total rewrite to the PS3 OS not before. Playstation Now and markets like China opening up to game consoles creates a market for Vidipath STBs and a cheaper PS3.

Sony not incrementally updating features like DLNA to the three box model doesn't make sense unless they were waiting for WMDRM10. The PS3 having a seperate DVD, Blu-ray, DLNA and IPTV player does not make sense except that the PS3 evolved over years with each being patched in as blocks not integrated into a player that contained support for all media that needed DRM. That has to change and requires a total rewrite to the PS3 XMB....everything. If the PS3 firmware is compromised pre-Playready then DVD, blu-ray and IPTV are compromised, post-Playready all would be better protected in the event the PS3 firmware is compromised.
Wow, thanks for all the information. Sounds like a genuine mess. No wonder it's stuck in limbo.
 
To make it clear: Mono has *no* such thing as a "main event loop" and so it is not "in glib". Mono is neither "technically" nor in any other way a "GNOME application". It is a free and open source implementation of parts of .NET. We've been using it since 1.0 to run our server side stuff.

When a Linux or even a Unix Operating system performs it's init, dbus becomes part of the main event loop or run loop. dbus can then spawn additional event loops. On a iOS or windows system dbus start must also be placed in it's init scripts.

From a 2011 post I made in this thread: The PS3 has had two snapshot kernels to this point with an abreviated one for the game side. To use webkit & GTK/Gnome applicaitons in the game side is going to need a different "dynamic" kernel model like Systemd (Linux) or launchd (Apple). Full Linux or FreeBSD functionality is not needed, Sony can have a custom method similar to systemd.

"systemd is a system and session manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux cgroups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit."
If your Linux system OS is fairly new then it uses SystemD and dbus is in the init and part of the main event loop. This is what Mono likely uses to access services and create it's own event loops.

Now think about the PS4 supporting "resume" for gaming and having multiple saved resume game states on the hard disk. One can reside in the GDDR5 memory with zero clock and the others on the hard disk. Moving a resume image from the Hard Disk to GDDR5 memory should take about 15 seconds vs 2 minutes for some games to initialize.
 
When a Linux or even a Unix Operating system performs it's init, dbus becomes part of the main event loop or run loop.

As far as I know, they do not become "part of the main event loop" because such a thing *does not exist* in a *nix system as they are not "event driven" in their fundamental architecture. Dbus is started as a traditional Unix daemon and it provides (event based) communication services to other processes and as far as I know, it is mostly for high level desktop applications. I have the impression that you're just mixing up high level event-driven application frameworks with much lower (OS) level stuff. Unix has had multiple different IPC services from the beginning (starting from pipes), as far as I can see, this is just another one, explicitly aimed at high level desktop applications.

dbus can then spawn additional event loops. On a iOS or windows system dbus start must also be placed in it's init scripts.

This doesn't have anything to do with whether Mono is a Gnome application or not. It uses some of the same libraries that Gnome uses but this does not in any way makes it a Gnome application, much less a "Gnome engine", whatever that may mean. I have the impression that you have a lot of high level information on products and high level features (certainly much more than me) but don't really have an in-depth programming experience, although maybe I'm wrong.

Basically: mono does NOT require Gnome (it uses only Glib) or vice versa, it does NOT have a "main event loop", you can run it on many operating systems (including Windows hehe) regardless of architecture. It has NO user interface to speak of. Is is not a part of Gnome and Gnome is not a part of it, and it is not a Gnome application. It simply uses one of the libraries (Glib) that Gnome does. From our perspective, its existence is pretty awesome actually, the amount of money it saves (by being able to use Linux servers while developing on Windows) is huge.
 
As far as I know, they do not become "part of the main event loop" because such a thing *does not exist* in a *nix system as they are not "event driven" in their fundamental architecture. Dbus is started as a traditional Unix daemon and it provides (event based) communication services to other processes and as far as I know, it is mostly for high level desktop applications. I have the impression that you're just mixing up high level event-driven application frameworks with much lower (OS) level stuff. Unix has had multiple different IPC services from the beginning (starting from pipes), as far as I can see, this is just another one, explicitly aimed at high level desktop applications.

This doesn't have anything to do with whether Mono is a Gnome application or not. It uses some of the same libraries that Gnome uses but this does not in any way makes it a Gnome application, much less a "Gnome engine", whatever that may mean. I have the impression that you have a lot of high level information on products and high level features (certainly much more than me) but don't really have an in-depth programming experience, although maybe I'm wrong.

Basically: mono does NOT require Gnome (it uses only Glib) or vice versa, it does NOT have a "main event loop", you can run it on many operating systems (including Windows hehe) regardless of architecture. It has NO user interface to speak of. Is is not a part of Gnome and Gnome is not a part of it, and it is not a Gnome application. It simply uses one of the libraries (Glib) that Gnome does. From our perspective, its existence is pretty awesome actually, the amount of money it saves (by being able to use Linux servers while developing on Windows) is huge.
I have a EE background, was part of a group that programmed on 68000 machines, some Linux/Unix experience in the 90's but since then only upper level user but with my background I find it easier to memorize instructions if I understand how things work at the hardware level. So as you post I'm ignorant of some of the middle and current (last 10 years) except for the hobby in learning/predicting how the game consoles work and using that to make money in the stock market. Game consoles are now leading the PC industry in hardware features that will show up in 2016+ PCs.

Visual Studio (Microsoft) C++ AMP will become the high level language with multiple underlying implementations including DirectCompute, Khronos SPIR 1.2 for OpenCL and HSAIL. Notice all the support for languages used with Virtual engines and native language interpreters with Sony supporting Mono on the PS4 and PS mobile on iOS and Android. It's not just for cross platform as it can also support cross architecture (multiple architectures in the same platform). To understand this you have to understand HSAIL and the near future need for HSAIL. It's also part of the reason the XB1 has three virtual engines to support the Windows 10 OS.

The PS4 will support Javascript, Java and Mono with a Intermediate Language similar to HSAIL = HSA Intermediate Language. The XB1 does the same with three virtual engines that while running on different ISA hardware support the same Intermediate Language.
 
This still has absolutely nothing to do with the original point and you are again just listing a bunch of acronyms and tbh all I can see is a somewhat, errr, manipulative attempt to overwhelm me with completely irrelevant details, which have nothing to do with the previous (minor) issues of Mono, Glib or Gnome or "main event loops" that Unixes simply don't have. Since you never actually respond to technical points with anything but a list of technology acronyms and since I'm not sure you even read my posts (e.g.:

It's not just for cross platform as it can also support cross architecture (multiple architectures in the same platform).

My previous post:

Basically: mono does NOT require Gnome (it uses only Glib) or vice versa, it does NOT have a "main event loop", you can run it on many operating systems (including Windows hehe) regardless of architecture.

)

I don't think continuing this discussion makes too much sense.
 
This still has absolutely nothing to do with the original point and you are again just listing a bunch of acronyms and tbh all I can see is a somewhat, errr, manipulative attempt to overwhelm me with completely irrelevant details, which have nothing to do with the previous (minor) issues of Mono, Glib or Gnome or "main event loops" that Unixes simply don't have. Since you never actually respond to technical points with anything but a list of technology acronyms and since I'm not sure you even read my posts (e.g.: My previous post: )

I don't think continuing this discussion makes too much sense.
The Main Loop: The Engine of a GUI Library While the article is about GTK GUI and the main loop, examples are given in how to interface with the OSX main loop. ALL operating systems have a main loop or they can't poll multiple incoming processes like window updates finished, key presses, incoming data from the USB or Ethernet port....multiple anythings. Mono has to interface with a main loop and it likely does that through dbus and dbus is patched into the system main loop. You may not see this as a Mono C# programmer as that has to be supported by a native library compiled for the system that comes with the Mono package for that system.

I guess you don't understand I'm past that. I could care less if you consider Mono an interpreter for C#, which in your case is all you use it for, or if you and others don't consider it Gnome.

Mono is not just a cross platform C# virtual engine as it can also support cross architecture (multiple architectures in the same platform). which both the XB1 and PS4 have for multiple power modes.

I brought up Mono's use in the PS4 and in a PS4 with GNOME/GTK APIs it can use the same native libraries, the entire set of APIs that Gnome uses which Javascript, Java and Mono use on Gnome platforms. I brought up C++ AMP as it's Microsoft and Microsoft is preparing to support platforms with multiple ISA architectures. Sony must do the same on the PS4 and will have Gnome native libraries in each ISA architecture and some QOS mechanism Mono, Javascript and Java will use to scale APPs from low power mode (ARM) to high power mode (X-86 APU). This is something that likely only happens on future consumer PCs..I.E. , you won't see it in a Linux server and it will be transparent to the C# programmer.

I'm not trying to overwhelm or deflect....but explain the issues with APUs with a large number of GPU CUs not able to support low power IPTV and XTV without a second ISA (ARM GPU and more) which creates issues for APPs that have to scale between low power and high power modes.
 
You are talking out of your ass about things you have no clue about.

The Main Loop: The Engine of a GUI Library While the article is about GTK GUI and the main loop, examples are given in how to interface with the OSX main loop.

No idea about OSX, it may actually be a fully event driven architecture, but Unixes in general are not.

ALL operating systems have a main loop or they can't poll multiple incoming processes like window updates finished, key presses, incoming data from the USB or Ethernet port....multiple anythings.

Not necessarily, and actually that's not the same kind of "main event loop" that GTK has ffs. A main event loop is specific to an event driven system, where a single central component processes and dispatches all events. This is not how unixes work.

Mono has to interface with a main loop and it likely does that through dbus and dbus is patched into the system main loop. You may not see this as a Mono C# programmer as that has to be supported by a native library compiled for the system that comes with the Mono package for that system.

Mono doesn't have to "interface with the main loop" and this doesn't actually mean anything. Unixes are *not* event based and they do *not* have "main event loops" like GTK. And I'm not a "Mono C# programmer". Seriously, you just put different technical terms next to each other and hope they mean something.

I guess you don't understand I'm past that. I could care less if you consider Mono an interpreter for C#, which in your case is all you use it for, or if you and others don't consider it Gnome.

I do not consider Mono an "interpreter for C#", mostly because it isn't, I have no idea where you pulled this idiocy from. It is absolutely *not* Gnome though. It does (afaik) contain an interpreter based runtime too.

Mono is not just a cross platform C# virtual engine as it can also support cross architecture (multiple architectures in the same platform). which both the XB1 and PS4 have for multiple power modes.

I never said it was a "C# virtual engine" ffs and I don't even think this even means anything. It is not an "engine". (In fact, I don't think that the expression "engine" in software actually has any concrete technical meaning outside a few specialised areas ("game engines" eg.) where it has a much more concrete meaning.) Mono is a free implementation of the .NET framework, most importantly the CLR.

http://programmers.stackexchange.com/questions/108613/what-makes-a-piece-of-software-an-engine

Look at the top rated comment (not the top rated answer). "Engine" is mostly a marketing term outside of a number of specialised areas.

I brought up Mono's use in the PS4 and in a PS4 with GNOME/GTK APIs it can use the same native libraries, the entire set of APIs that Gnome uses which Javascript, Java and Mono use on Gnome platforms. I brought up C++ AMP as it's Microsoft and Microsoft is preparing to support platforms with multiple ISA architectures. Sony must do the same on the PS4 and will have Gnome native libraries in each ISA architecture and some QOS mechanism Mono, Javascript and Java will use to scale APPs from low power mode (ARM) to high power mode (X-86 APU). This is something that likely only happens on future consumer PCs..I.E. , you won't see it in a Linux server and it will be transparent to the C# programmer.

And still, this has nothing to do with whether Mono is a "GNOME engine", which it isn't.

I'm not trying to overwhelm or deflect....but explain the issues with APUs with a large number of GPU CUs not able to support low power IPTV and XTV without a second ISA (ARM GPU and more) which creates issues for APPs that have to scale between low power and high power modes.

Listing a bunch of completely irrelevant acronyms and bullshitting about stuff you only superficially understand, that's exactly a tactic of overwhelming and deflection. Maybe it works with other people who don't understand this stuff, but for anyone with some experience, it's obvious that you're just bullshitting.

I'm out.
 
Generally in event-driven programming there's a main loop running, unlike in embedded systems for example where events might be controlled via interrupts. The blog post talks about how the main loop is implemented in GTK. How that has anything to do with PS3 web browser I am not sure yet.

And sure there is JS running on on the browser, PS3 and PS4 have BD-J support which are Java ME xlets so there's that but I am still (again) figuring out where Mono and Gnome come in.
 
Generally in event-driven programming there's a main loop running, unlike in embedded systems for example where events might be controlled via interrupts. The blog post talks about how the main loop is implemented in GTK. How that has anything to do with PS3 web browser I am not sure yet.

And sure there is JS running on on the browser, PS3 and PS4 have BD-J support which are Java ME xlets so there's that but I am still (again) figuring out where Mono and Gnome come in.
Mono VM and Class libraries are in the PS4 Open source List.. For Gnome, the PS3 Webkit disclosure is using GTKwebkit APIs and that is based on a Gnome GUI toolkit.

The PS4 has two memory pools and two OS, one a low power ARM with 256MB DDR3 and one a High power APU with GDDR5 memory. How do you support apps on such a system? With Virtual machines! Javascript, Java and Mono are designed to be cross platform and run on multiple ISAs. The difference here is there are multiple ISAs in the PS4.

AAA games will only use the high power mode with OS support from the low power Second custom chip as Southbridge. This is a reason for Sony to concentrate on Games at release. Current PS4 APPs run only in high power mode. The XB1 is getting APPs this November with DEV support sometime mid-year.

IPTV apps will run only in low power mode
Games only in High power
XTV and Browser have to scale from low to high power.
IoT apps must have a ultra low power AOAC network standby Mode
DLNA Server must be a combination of Network standby and IPTV mode
Voice and Gesture control can be used for IPTV and as OS system support for games so LOW POWER

DLNA Client/DLNA CVP2 is a combination of IPTV and HTML5 and must scale. XTV is part of this.




.
 

Bio

Member
As if I could have any confidence in a new web browser when they can't even get their PSN Store app to work properly.
 
This is interesting, From 2011 also:

http://www.mono-project.com/FAQ:_Licensing Parts of Mono have Microsoft patents

When do I need to obtain a license from Xamarin to the Mono Runtime?

We only require licensing for uses of Mono and Moonlight on embedded systems, or systems where you are unable to fulfill the obligations of the GNU LGPL.

For example, if you manufacture a device where the end user is not able to do an upgrade of the Mono virtual machine or the Moonlight runtime from the source code, you will need a commercial license of Mono and Moonlight.

Or if you ship an application that requires to statically link the Mono runtime and you are not able to provide the object code to relink Mono, you must obtain a commercial license from Xamarin.
PS3, Xbox, game consoles mentioned as requiring a license in other links.
So if the Mono license hasn't changed then Mono in the PS4 Open Source list means the PS4 is an open system and would seem to confirm rumors of Sony allowing something like Other OS Linux.
 

Atedos

Member
WTF guys, are you serious?
I've just been reading through several first pages thinking some new great stuff coming to PS3 browser, until I realized it's 5 years old thread.
RLY?
 
He's been doing this for four years now.
If you look at the PS4 open source list, Mono is listed as a Virtual Machine which was denied by Flachmatuch. All OS have a main loop but IO for efficiency is not part of the main loop on many Servers. Mono can be used as a CLI interpreter and doesn't need Dbus or to be patched into the main loop.

This is a case of a stubborn Testosterone driven mule headed discussion where everyone was accurate but not fully accurate. The first Mono implementation was as a Gnome application. The first use of Mono on Gnome was as a C# to Objective C interpreter. The first Android version of Mono used Mono as a C# to Dvorak interpreter inside the web browser sandbox . The second use of Mono on Android was after Google allowed native libraries and that version of Mono could but didn't usually translate C# to Dvorak, it called native libraries. Before that version Mono had to write to the screen using the Android browser which used Skia. After native libraries were allowed with Android, Mono could write to the screen using Cairo and could use Gstreamer or Unity. Anyway native libraries for PS Mobile had to be installed by the platform owner which supports patching into Android native libraries or the Linux OS.

The Mono project has gone beyond both of those components and has developed and integrated third party class libraries, the most important being: Debugging APIs, integration with the Gnome platform (Accessibility, Pango rendering, Gdk/Gtk, Glade, GnomeUI), Mozilla, OpenGL, extensive database support (Microsoft only supports a couple of providers out of the box, while Mono has support for 11 different providers), our POSIX integration libraries and finally the embedded API (used to add scripting to applications and host the CLI,
 

SgtCobra

Member
Keep dem haters comin'. Can't wait for the next Jeff_Rigby redeemed thread.
It's actuallt pretty fascinating to read his posts.
 
WTF guys, are you serious?
I've just been reading through several first pages thinking some new great stuff coming to PS3 browser, until I realized it's 5 years old thread.
RLY?
HTML5/WebGL is used as the system UI on the PS4. It will be used for the DLNA CVP2 RUI on ALL certified platforms. All certified platforms will support WebGL supported by OpenGL.

1) The PS3 doesn't have OpenGL or WebGL because of IPTV DRM security issues which means the browser is not accelerated. It's using a game engine to support openGL calls the PS Store uses.
2) Since it's possible to detect a PS3 connected to the PS store and not use WebGL, switch to code it supports, they must have plans to eventually support OpenGL with the PS3.
3) It currently has a OpenVG using XML XMB UI.
4) The PS3 is getting a OS level update to use Playready.

At this late date, Playready DRM means Sony is going to support DLNA CVP2 on the PS3 and that requires WebGL which likely means OpenGL support in the PS3 with a change for the XMB to the same UI the PS4 is using with Webkit native libraries always loaded.

The thread currently supports the PS4 better than the PS3 as all my speculation for the PS3 was derailed by the IPTV security issues Sony found before the Slim was released.

The PS4 has Glib support which is required by GTKWebkit for some features.
The PS3 webkit disclosure has Glib support disabled

+if !TARGET_POSIX
+global_cppflags += -DENABLE_GLIB_SUPPORT=1 This is interesting.
+endif

Glib will be required for Mono/PS Mobile on the PS3 and for video chat outside the Sony ecosystem. Currently Sony servers are needed instead of ICE. If the speculation that Playready support means DLNA CVP2 on the PS3 then Glib is coming and PS Mobile is possible on the PS3.
 
If you look at the PS4 open source list, Mono is listed as a Virtual Machine which was denied by Flachmatuch.

You lie. You are a liar. You are saying things that are not true. I never did that. If I did, QUOTE ME. You used the expression "virtual engine" which is MEANINGLESS and I pointed that out. This is my fucking JOB and words MEAN things. You cannot just replace word A with word B that sounds similar to your ignorant bullshitting self. But Mono itself *is not a Virtual Machine* - it just *contains* one, an implementation of the CLR.

All OS have a main loop but IO for efficiency is not part of the main loop on many Servers. Mono can be used as a CLI interpreter and doesn't need Dbus or to be patched into the main loop.

You are utterly clueless about OS architectures and you should stop pretending you know things you do not. "Patched into the main loop?" Seriously? Dbus runs as a goddamn unix daemon. Unix has NO GTK-like main loop. And "patching" means something completely different. The whole sentence cannot mean anything, no matter how hard you try to interpret it. It shows your utter cluelessness (and also absolute disrespect towards my profession) perfectly well.

This is a case of a stubborn Testosterone driven mule headed discussion where everyone was accurate but not fully accurate.

Bullshit. It's a case of me having a job that involves productive work (well, as productive as coding can be) and having some knowledge and experience about it, and you having a job that involves bullshitting and having knowledge and experience about putting irrelevant and unrelated acronyms one after another so that you appear as someone who knows their shit to people who trust you but don't quite understand what you're saying. Far from being "accurate", you simply have no clue whatsoever about what half the words you use actually mean.


And with this, I'm out, I have to go back to my job to code Virtual Engines that later have to be Patched into Main Loops to run on the well known GNOME application, MONO. Something something dbus POSIX IPTV Glib DLNA CVP2 Android.

Keep dem haters comin'. Can't wait for the next Jeff_Rigby redeemed thread.
It's actuallt pretty fascinating to read his posts.

I'm not a "hater". It all started when I simply pointed out an inaccuracy (Mono as a "GNOME engine"). Instead of admitting to this minor mistake, which may be completely irrelevant to his main point, he started to try to bullshit his way out of it, brought in "main loops" and "virtual engines" and that is pretty goddamn annoying. He could be a good journalist or whatever he is even without deep technical knowledge, he doesn't need to know everything perfectly. But when he started to bring absolutely *irrelevant* issues into the question and responded with paragraphs that were made up of random buzzwords and acronyms and tried to overwhelm me with absolutely irrelevant and meaningless pseudo-technical talk, I did become a bit pissed off.
 
You lie. You are a liar. You are saying things that are not true. I never did that. If I did, QUOTE ME. You used the expression "virtual engine" which is MEANINGLESS and I pointed that out. This is my fucking JOB and words MEAN things. You cannot just replace word A with word B that sounds similar to your ignorant bullshitting self. But Mono itself *is not a Virtual Machine* - it just *contains* one, an implementation of the CLR.

You are utterly clueless about OS architectures and you should stop pretending you know things you do not. "Patched into the main loop?" Seriously? Dbus runs as a goddamn unix daemon. Unix has NO GTK-like main loop. And "patching" means something completely different. The whole sentence cannot mean anything, no matter how hard you try to interpret it. It shows your utter cluelessness (and also absolute disrespect towards my profession) perfectly well.

Bullshit. It's a case of me having a job that involves productive work (well, as productive as coding can be) and having some knowledge and experience about it, and you having a job that involves bullshitting and having knowledge and experience about putting irrelevant and unrelated acronyms one after another so that you appear as someone who knows their shit to people who trust you but don't quite understand what you're saying. Far from being "accurate", you simply have no clue whatsoever about what half the words you use actually mean.

And with this, I'm out, I have to go back to my job to code Virtual Engines that later have to be Patched into Main Loops to run on the well known GNOME application, MONO. Something something dbus POSIX IPTV Glib DLNA CVP2 Android.
And you distort the truth to win an argument. Stop with the name calling.

A virtual engine is inside a virtual machine. Mono is the virtual engine for Mono the package and Virtual Machine just as Javascript is the engine for "Javascript the Machine. This is what I was taught and if I'm using words that a "professional" considers incorrect then sorry.

In discussions don't get so picky or prickly...if I associate virtual machine and engine and claim you denied it's a VM then forgive me I'm not trying to put words in your mouth.

Unix has no GTK-dbus like main loop but it has a main loop as I said. This is distorting what I said. Adding dbus in Linux requires Dbus in the main loop (blue) and calling dbus (orange) with the application as it's initialized..this is what I call patching into the main loop and spawning a dbus event driven loop. dbus as part of systemd is a daemon and an always running background process and dbus in the applications as used by Mono is what?

The following slide is from Samsung's Tizen ( "Systemd components" by Shmuel Csaba Otto Traian.) and only deals with systemd which they are using in their TVs and other CE platforms. Tizen will support DLNA CVP2 on their Smart TVs.

Acknowledged by you is that dbus is part of the spawned IO driven event loop and thus systemd damions are part of the main loop (blue below).

720px-Systemd_components.svg.png


http://en.wikipedia.org/wiki/Systemd said:
systemd is a suite of system management daemons, libraries, and utilities designed as a central management and configuration platform for the Linux computer operating system. Described by its authors as a "basic building block" for an operating system,[5] systemd primarily aims to replace the Linux init system (the first process executed in user space during the Linux startup process) inherited from UNIX System V and Berkeley Software Distribution (BSD). The name systemd adheres to the Unix convention of making daemons easier to distinguish by having the letter d as the last letter of the filename.[6]

Explain if I am in error in terms a 63 year old EE major who used a slide ruler in EE class and a IBM 360 with punch cards. Please try to educate everyone including me with a little more than you are blowing it out your ass . If an OS has no main loop then it ends when it reaches the end of the branch. How does a watchdog program work and what is it for?
 
And you distort the truth to win an argument. Stop with the name calling.

You claimed I denied that Mono was a "virtual machine". (Which as a whole it actually isn't, but a part of it is.) I have no idea how I "distorted the truth". Quote me and explain, in plain words if you are able, why and how I did that.

A virtual engine is inside a virtual machine.

At best, and I think I'm being very nice here, a "virtual engine" is a (afaik not very commonly used) synonym for "virtual machine". It is certainly not a technical term that denotes some concrete core part of a "virtual machine". A virtual machine is technically a "machine within a machine", an environment that can run code and is implemented as code within a wider environment that can run code; the two most important things being that a) how this "machine within a machine" works can be abstracted and standardised and basically made independent of the concrete hardware it's running on and b) its use of resources and communication with its environment is completely controllable from the outside.

Mono is the virtual engine for Mono the package and Virtual Machine just as Javascript is the engine for "Javascript the Machine.

Mono is not a "virtual engine for Mono the package and Virtual Machine", whatever that means, and is not just a "virtual machine". The implementation of an MS-specified "execution environment" (aka VM in MS-speak) is one *part of* Mono.

This is what I was taught and if I'm using words that a "professional" considers incorrect then sorry.

You first used the word "engine" was when you claimed Mono was a "GNOME engine". That has nothing to do with virtual machines and this actually does not mean anything. That was what I pointed out. Maybe it does mean something, of course, so please explain.

In discussions don't get so picky or prickly...if I associate virtual machine and engine and claim you denied it's a VM then forgive me I'm not trying to put words in your mouth.

Again, it is not a VM, only the execution environment is a VM and Mono has other parts (although indeed this is the most important part, which btw is what I said from the start). As for being "picky" in discussions - if pointing out misuse and abuse of technical terms and concepts (like "main loop") simply to build respect and ego is being "picky", I'm guilty as charged.

Unix has no GTK-dbus like main loop but it has a main loop as I said. This is distorting what I said. Adding dbus in Linux requires Dbus in the main loop (blue) and calling dbus (orange) with the application as it's initialized..this is what I call patching into the main loop and spawning a dbus event driven loop. dbus as part of systemd is a daemon and an always running background process and dbus in the applications as used by Mono is what?

"Adding dbus" requires that you start it as a daemon. That has nothing to do with a "main loop". The expression "main loop" is used for a loop that handles and dispatches events, in an event-based architecture where all communication happens through events. Unix has a different architecture and it has NO such "main loop" to which you "add" things. You certainly don't need to "patch" these "into the main loop".

Even if "all operating systems have a main loop" was true, the way you use that term when you say "adding dbus to the main loop" is completely incorrect.

The following slide is from Samsung's Tizen ( "Systemd components" by Shmuel Csaba Otto Traian.) and only deals with systemd which they are using in their TVs and other CE platforms. Tizen will support DLNA CVP2 on their Smart TVs.

:rolleyes

Acknowledged by you is that dbus is part of the spawned IO driven event loop and thus systemd damions are part of the main loop (blue below).

No, I am not "acknowledging" anything like that. These things run as daemons, not "parts of the main loop". That expression is completely irrelevant and meaningless here. It is a term *specific to event driven architectures*. Unixes are NOT structured that way. And apart from you, I've never heard anyone calling systemd core processes a "main loop".

720px-Systemd_components.svg.png


Explain if I am in error in terms a 63 year old EE major who used a slide ruler in EE class and a IBM 360 with punch cards.

Please try to educate everyone including me with a little more than you are blowing it out your ass .

I constantly provided simple explanations. All of my posts, if you look back, I tried to write in a way that people can understand. I know I'm not very good at it, but I at least try. And you responded to all of them with a barrage of irrelevant acronyms and equivocation. Unlike you, I try to write my posts as clearly as I possible so that people can point out if they're wrong. Which of course they often are, but in my opinion, it's much better to openly turn out to be wrong than to appear more knowledgeable than you are. And of course it is also completely impossible to have an actual discussion if people don't understand each other.

If an OS has no main loop then it ends when it reaches the end of the branch.

The "main event loop" is *specific to event driven software architectures* like GTK. This a software architecture where the dynamic operation of the system is approached through the concept of routing and handling "events". "Main loops" take messages from a queue or wherever and they process them (dispatch them to other processes or do something else based on them). They are overwhelmingly used on the higher levels of the architecture (typically GUIs). The Windows GUI, for example, was already "event driven" even in 3.1. I wrote message-handling "main loops" for Windows 3.1 programs already.

Unixes work differently. They are made up of several concurrently running but otherwise absolutely traditional programs ("processes"). From their own point of view, these can act as if they were completely separate and independent and access resources independently. There is a central scheduling and process management component (which is *not* called a "main loop") that can assigns resources (processing time and memory) to these different processes. This scheduling component does not receive and dispatch events between these processes in the way event driven systems do. But you *can* add *other processes* to the system (like a dbus daemon) that can take on such tasks.

There actually *are* things in Unix that are somewhat like events and they are called "signals". These are used to signal extraordinary situations (like someone pressing ctrl-c in a console). Unix programs can watch for and handle these signals.

How does a watchdog program work and what is it for?

??? Watchdogs are there to monitor the operation of complex systems and act when they detect problems. We use (not quite) watchdogs to periodically run high level data integrity tests for example. Watchdogs can be separate processes (or even separate hardware monitoring a more complex piece of hardware).
 
A virtual engine is inside a virtual machine. Mono is the virtual engine for Mono the package and Virtual Machine just as Javascript is the engine for "Javascript the Machine. This is what I was taught and if I'm using words that a "professional" considers incorrect then sorry.

That's exactly kinda the thing here. JavaScript engines (which of there are many, such as SpiderMonkey that's found in Firefox or V8 that comes with Google Chrome for example) interpret a language called JavaScript, which actually is an implementation of a standardized scripting language called ECMAScript (that has roots in early versions of JavaScript). And that's just scratching the surface.
 
That's exactly kinda the thing here. JavaScript engines (which of there are many, such as SpiderMonkey that's found in Firefox or V8 that comes with Google Chrome for example) interpret a language called JavaScript, which actually is an implementation of a standardized scripting language called ECMAScript (that has roots in early versions of JavaScript). And that's just scratching the surface.

I couldn't even interpret that "Javascript the Machine" sentence in a way that would make sense.
 
Top Bottom