Who are you kidding Heater? That is exactly what X was intended for.
The subsystem is a perfect, headless compute server or node. Pipe it to a graphics system and go. Easy peasy.
One day, all these gui systems might just catch up with where the brilliant peeps, who gave us X, were decades before.
Edit: The only reason it seems clunky is so darn many people didn't get a real exposure to X.
What they got was single user, dedicated graphics nodes. Fine, but X is multi user, multi node, or host. All of that is OS agnostic too. Smart guys back then. Had vision that endures to this day.
The win subsystem case is ordinary, in that respect. A X user wouldn't even think about it. Just run a server and go.
Who are you kidding Heater? That is exactly what X was intended for.
Traditionally "cross-platform" was about that ability to use the same source code on multiple different machines/architectures/operating systems.
That is why the fetal Unix was rewritten in C. So that it could become a cross-platform solution and spread around.
So, taking "cross-platform" literally I don't regard building and running a program on one machine and displaying its output on another, different, machine as cross-platform solution.
X is a wonderful thing and all but I have issues with your suggestion:
1) Is it even possible to run 3D accelerated graphics over a remote, network, connection? On the rare occasions I have used X over a network connection it was unbearably slow even for regular software that did not need a GPU.
2) What about audio?
3) What about access to serial ports and other hardware?
1) Yes, I was doing it in the 90s at speeds you would not believe, on IRIX, 10T Ethernet, GLX extensions, High end solid modeling software.
I could put a big chunk of a car on the screen and go to town.
This did require an application developer to grok the system and allow OGL to do its thing. Apps today are crappy. Will work on a local, or high speed network. Anything else is a mess.
But, local X server in this case will be fine.
2) a mess. I do not understand how audio didn't get done X style. Audio is consistently painful on most things today.
3)X supported a lot with extensions. Google multi head. IRIX had it all built in, optimized. One common use was a shared station, one Onyx, several users, keyboards mice. Another was the VR wall type installations, multiple display nodes, mosaic style.
Is possible to have a lot of input devices associated with a display host. High end apps on SGI did just that. Buttons, dials joystick, mouse, keyboard...
Typically that is the only time I want to use X remotely for long time. There is some headless system, no display, keyboard, mouse etc. And I want to run some GUI application on it with it's display on my PC/laptop. Typically this has been so slow that I would not imagine trying to use it for long term serious use.
X was intended as multiplatform OS agnostic graphics, UI, BTW. It's a service, not an app, not a library.
As such it is brilliant. Back in the day our Unix based schematic capture and PCB layout suite ran on some Sun, Apollo or whatever machine and could displayed itself on our MS-DOS PC's.
From the point of view of writing a GUI app it makes no odds if the graphics system is a service or a library, server or client. There is an API for my app to use and I just want it to work. For example, my Qt based applications run on Windows where it has direct access to the graphics via Windows API and libraries. Or they run on Linux where they talk to an X server.
.Net Framework - Develop high performance applications in less time, on any platform. By Microsoft.
More accurately, .Net Standard is the cross-platform specification, .Net Core is the open-source, cross-platform implementation of .Net Standard, and .Net Framework is Windows only implementation (that also implements .Net Standard). And there's always been Mono, which was a cross-platform port of many parts of .Net Framework. With the introduction of .Net Standard (and the .Net Core implementation), Mono has been realigning itself to .Net Standard and replacing much of that portion of the code with the same codebase used by .Net Core. The point is... if you target .Net Standard, you can run on any platform that has a current .Net implementation.
Exactly. The .Net standard enables one to write cross-platform software. As does Java, Javascript, Python, etc.
Not a Microsoft product.
Might be. Especially when it is supplied my MS and uses the MS Chakracore Javascript engine rather than the usual Google V8 engine of original Node.js.
Wait a minute... what does all of this have to do with the original topic?
My sentiments exactly. When users from outside come to read this topic, they are provided with talk about .NET, JS, Linux, X.... which has nothing to do with the original thread topic.
That is the primary difference. Put it in the name.
Re: X
Sorry, I'll tend to go on about X. Many, many misconceptions. I'll hold my direct access to graphics comments for another day, save to say we live with screen scrapers and crunchers... ugh.
I think, basically, the whole problem that X was designed to solve is non-existent today. If it was ever a problem for the majority of computer users.
Here we are, having a discussion. The server handling this discussion is God knows where. The machine handling the graphical user interface is right here, under my nose. Or there, wherever you are.
The web of HTTP and HTML renders all that X stuff irrelevant.
Who would be crazy enough to try and build what we have here, now, using X?
My humble home router has a web interface. Not an X interface.
My databases in the cloud have a web interface. Not an X interface.
Lol, what they will do is reinvent it. JS can deliver rich experiences today. Just needs a little standardization and an easy to setup and run server.. hello X!
See, a network protocol works for all but the most demanding local graphics. And, frankly, the performance hit with a well designed TCP stack, like SGI did, is competitive with pipes, and other schemes.
The bonus is rich interactivity no matter what talks to what.
Edit: Starting another thread. In gen discussion.
You just watch. (Not for the thread. For X being reinvented, just like UNIX often does.)
I think Chip has already chosen a part code ?
To me P8X64SP does not make much sense, as the part is not 64 bit, and the package is not 64 pins, and the IO count is
never usually part of a part number... - users expect to see Code Size, and package suffix in part numbers.
If Parallax makes a 32 Smart pin version, that becomes P8X32SP. I can see a problem already....
.. but P2 does need an over-arching, easy to remember name, that can google-find. 'P2' fails that test.
I think Chip has already chosen a part code ?
To me P8X64SP does not make much sense, as the part is not 64 bit, and the package is not 64 pins, and the IO count is
never usually part of a part number... - users expect to see Code Size, and package suffix in part numbers.
If Parallax makes a 32 Smart pin version, that becomes P8X32SP. I can see a problem already....
.. but P2 does need an over-arching, easy to remember name, that can google-find. 'P2' fails that test.
IIRC P2Hot had the part number P8X32C.
That didn't really highlight the massive differences from the P8X32A either.
Luckily Parallax doesn't need a convoluted product selector like the "pthers". You can have a Propeller 1 or a Propeller 2, nice and easy.
Had they stuck with "nice and easy", the Propeller 1 would have been called Basic Stamp 2.
The Prop-2 is probably just a temporary code name.
It's really a far different chip than the other Parallax microcontrollers. The developers seem to have an interest in aerospace propulsion. There are propellers, turbo-props, turbo-fans, turbojets, ramjet, and the mother of all jet engines, the scramjet.
Had they stuck with "nice and easy", the Propeller 1 would have been called Basic Stamp 2.
The Prop-2 is probably just a temporary code name.
It's really a far different chip than the other Parallax microcontrollers. The developers seem to have an interest in aerospace propulsion. There are propellers, turbo-props, turbo-fans, turbojets, ramjet, and the mother of all jet engines, the scramjet.
The Propeller 1 was anything but Basic so Basic Stamp 2 would have been a major misnomer. With both P1 and P2 being multicore microcontrollers I don't see anything wrong with using the number of cores and I/O pins as part of the designation. Sometimes the simple and obvious choice is best.
PS - not that I really care what the designation is as long as I can buy a few.
You'd think after 12 years of development, the Prop-2 would be a major advance since the Prop-1, just like the Prop-1 was over the Stamp.
You and I may not care about the designation, but from a marketing perspective, a proper name is of paramount importance.
I think Prop-2 will do fine with current Parallax customers. But if you want to go after Raspberry Pi and Arduino customers, Parallax had better make a compelling story. Perhaps consider making the Prop-2 compatible with the Arduino IDE and the C-programming environment. I'm not saying getting rid of Spin, but I'm saying expand your customer base.
You'd think after 12 years of development, the Prop-2 would be a major advance since the Prop-1, just like the Prop-1 was over the Stamp.
You and I may not care about the designation, but from a marketing perspective, a proper name is of paramount importance.
I think Prop-2 will do fine with current Parallax customers. But if you want to go after Raspberry Pi and Arduino customers, Parallax had better make a compelling story. Perhaps consider making the Prop-2 compatible with the Arduino IDE and the C-programming environment. I'm not saying getting rid of Spin, but I'm saying expand your customer base.
From a marketing perspective I would hope that a good description of things like the multiple cores, smart I/O pins, deterministic timing, video capability, and other features of the architecture would make a compelling story.
Programming in C is already in the works, but why cripple a multi core cpu with an IDE for a single core chip?
Comments
Being able to run Linux/X Windows applications on Windows 10 with the new Linux Subsystem for Windows and an X server is a good trick.
I don't regard that as a "cross-platform" solution. It's a clunky way to get things running in places they were not designed for.
The subsystem is a perfect, headless compute server or node. Pipe it to a graphics system and go. Easy peasy.
One day, all these gui systems might just catch up with where the brilliant peeps, who gave us X, were decades before.
Edit: The only reason it seems clunky is so darn many people didn't get a real exposure to X.
What they got was single user, dedicated graphics nodes. Fine, but X is multi user, multi node, or host. All of that is OS agnostic too. Smart guys back then. Had vision that endures to this day.
The win subsystem case is ordinary, in that respect. A X user wouldn't even think about it. Just run a server and go.
Howtogeek! Even pretty ordinary users see this. Makes me happy.
That is why the fetal Unix was rewritten in C. So that it could become a cross-platform solution and spread around.
So, taking "cross-platform" literally I don't regard building and running a program on one machine and displaying its output on another, different, machine as cross-platform solution.
X is a wonderful thing and all but I have issues with your suggestion:
1) Is it even possible to run 3D accelerated graphics over a remote, network, connection? On the rare occasions I have used X over a network connection it was unbearably slow even for regular software that did not need a GPU.
2) What about audio?
3) What about access to serial ports and other hardware?
I could put a big chunk of a car on the screen and go to town.
This did require an application developer to grok the system and allow OGL to do its thing. Apps today are crappy. Will work on a local, or high speed network. Anything else is a mess.
But, local X server in this case will be fine.
2) a mess. I do not understand how audio didn't get done X style. Audio is consistently painful on most things today.
3)X supported a lot with extensions. Google multi head. IRIX had it all built in, optimized. One common use was a shared station, one Onyx, several users, keyboards mice. Another was the VR wall type installations, multiple display nodes, mosaic style.
Is possible to have a lot of input devices associated with a display host. High end apps on SGI did just that. Buttons, dials joystick, mouse, keyboard...
Typically that is the only time I want to use X remotely for long time. There is some headless system, no display, keyboard, mouse etc. And I want to run some GUI application on it with it's display on my PC/laptop. Typically this has been so slow that I would not imagine trying to use it for long term serious use. As such it is brilliant. Back in the day our Unix based schematic capture and PCB layout suite ran on some Sun, Apollo or whatever machine and could displayed itself on our MS-DOS PC's.
From the point of view of writing a GUI app it makes no odds if the graphics system is a service or a library, server or client. There is an API for my app to use and I just want it to work. For example, my Qt based applications run on Windows where it has direct access to the graphics via Windows API and libraries. Or they run on Linux where they talk to an X server.
More accurately, .Net Standard is the cross-platform specification, .Net Core is the open-source, cross-platform implementation of .Net Standard, and .Net Framework is Windows only implementation (that also implements .Net Standard). And there's always been Mono, which was a cross-platform port of many parts of .Net Framework. With the introduction of .Net Standard (and the .Net Core implementation), Mono has been realigning itself to .Net Standard and replacing much of that portion of the code with the same codebase used by .Net Core. The point is... if you target .Net Standard, you can run on any platform that has a current .Net implementation.
Not a Microsoft product.
Exactly. The .Net standard enables one to write cross-platform software. As does Java, Javascript, Python, etc.
Might be. Especially when it is supplied my MS and uses the MS Chakracore Javascript engine rather than the usual Google V8 engine of original Node.js.
https://blogs.windows.com/msedgedev/2017/07/27/node-chakracore-update-n-api-ios/
https://github.com/Microsoft/ChakraCore/wiki/Roadmap No idea. What was the question?
My sentiments exactly. When users from outside come to read this topic, they are provided with talk about .NET, JS, Linux, X.... which has nothing to do with the original thread topic.
We are way off topic here.
Which sounds a bit depressingly pääte to me.
As for the name...
Smart Pin Propeller
That is the primary difference. Put it in the name.
Re: X
Sorry, I'll tend to go on about X. Many, many misconceptions. I'll hold my direct access to graphics comments for another day, save to say we live with screen scrapers and crunchers... ugh.
Here we are, having a discussion. The server handling this discussion is God knows where. The machine handling the graphical user interface is right here, under my nose. Or there, wherever you are.
The web of HTTP and HTML renders all that X stuff irrelevant.
Who would be crazy enough to try and build what we have here, now, using X?
My humble home router has a web interface. Not an X interface.
My databases in the cloud have a web interface. Not an X interface.
And so on.
Why do we need the X network protocol?
See, a network protocol works for all but the most demanding local graphics. And, frankly, the performance hit with a well designed TCP stack, like SGI did, is competitive with pipes, and other schemes.
The bonus is rich interactivity no matter what talks to what.
Edit: Starting another thread. In gen discussion.
You just watch.
Propeller 2 - P8X64SP ?
To me P8X64SP does not make much sense, as the part is not 64 bit, and the package is not 64 pins, and the IO count is
never usually part of a part number... - users expect to see Code Size, and package suffix in part numbers.
If Parallax makes a 32 Smart pin version, that becomes P8X32SP. I can see a problem already....
.. but P2 does need an over-arching, easy to remember name, that can google-find. 'P2' fails that test.
That didn't really highlight the massive differences from the P8X32A either.
Luckily Parallax doesn't need a convoluted product selector like the "pthers".
You can have a Propeller 1 or a Propeller 2, nice and easy.
The Prop-2 is probably just a temporary code name.
It's really a far different chip than the other Parallax microcontrollers. The developers seem to have an interest in aerospace propulsion. There are propellers, turbo-props, turbo-fans, turbojets, ramjet, and the mother of all jet engines, the scramjet.
The Propeller 1 was anything but Basic so Basic Stamp 2 would have been a major misnomer. With both P1 and P2 being multicore microcontrollers I don't see anything wrong with using the number of cores and I/O pins as part of the designation. Sometimes the simple and obvious choice is best.
PS - not that I really care what the designation is as long as I can buy a few.
You and I may not care about the designation, but from a marketing perspective, a proper name is of paramount importance.
I think Prop-2 will do fine with current Parallax customers. But if you want to go after Raspberry Pi and Arduino customers, Parallax had better make a compelling story. Perhaps consider making the Prop-2 compatible with the Arduino IDE and the C-programming environment. I'm not saying getting rid of Spin, but I'm saying expand your customer base.
From a marketing perspective I would hope that a good description of things like the multiple cores, smart I/O pins, deterministic timing, video capability, and other features of the architecture would make a compelling story.
Programming in C is already in the works, but why cripple a multi core cpu with an IDE for a single core chip?
It may not limit you to a single core, but it does not do anything to make use of multiple cores easier either.