It should be pointed out x86-64 has security facilities that are equivalent to a harvard architecture, protection levels, setting pages with read/write/execute bits and so forth, as with the NX bit. The problem here is Word, and the security profiles at the OS level that allow scripts to access the filesystem. A harvard architecture would introduce inefficiencies in memory and bus utilization without giving you anything that you cant get with page tables and privilege levels on
The code should go into a sandbox, or not be run at all. A sandbox is an option both OS level, and the interpreter. Running code without that in a DOC file IS nuts. Reducing the kernel attack surface like Chrome has done is one tactic that can be used, using a controller/controllee sandbox. Its not rocket science. Its just plain incompetence to not do this.
Not really necessary at the CPU level, a good OS can allow you to do a RBAC rule that will block any file from being executed in a user writeable directory. It should be up to the OS to provide a complete security model. The thinking of putting overly complex security models into the CPU is wrong. This is because if a bug slips in its harder to update the CPU. The CPU has basic page functionality, NX bits, privelege levels adn so on that provide the basic tools needed for the OS to implement any security model needed.
What do you recommend? C/C++ programs facing the internet? I dont think there exists many large C/C++ programs that have not had severe buffer overflows. PHP/Perl/Ruby etc with their automatic memory management are relatively safe by comparison.
As long as it is clearly documented what it will do, and you know what precisely what it will having it automatically do things isnt necessarily bad, can save time, as long as finer grain control is allowed. If it is poorly documented and does unexpected things, this is pretty bad. Allowing a system command to be run is a pretty nasty undocumented automatic behaviour.
Radio Shack has been selling consumer electronics for a long, long time, over 50 years at least. And yes, people did buy stuff there. The hobbyist market is not large enough to keep them alive, just not enough people like that around. Amazon did it in. Amazon can run losses for 20 years because its a wall street darling, so its been undercutting everyone else. Antitrust behaviour, if you ask me.
There seems to be a deliberate attempt to destroy the sensibilities, intellect,morals of the population by putting out of all of this out of tune, profane, creepy, depressing, dismal, tasteless, trashy, low grade music that appeals mainly to crackheads, deadbeats stoners, self obsessed and arrogant millenials, sado-depressive types and the like. Pop, rap, rock, its all garbage. Real music disappeared long ago, Now we have this bleak, dystopian nonsense that seems to be designed to destroy the minds of those who listen to it. So, nothing worth buying here, I advise everyone to not purchase this garbage and put hollywood out of business for good. It would do our society a big favor.
The best solution to this is for cross platform toolkits to emulate whenever possible missing OS features. Otherwise you have feature testing to write apps adaptively, using cross OS APIs when the underlying OS has the feature, but this is far from optimal. Providing the OS provides some basic underlying features, features can be emulated by a toolkit. Adaption always has to happen with a number of variables like screen real estate
I mention that is much much safer to run Javascript code on a VM in a sandboxed browser process than it is to run machine code compiled with C++ full of hanging pointers, bad mallocs, buffer overflows, running directly exposed to the OS Kernel interface.
So your suggesting I should have to run dozens of network aware applications with crappy C/C++ code rather than relatively safe sandboxed JS code in a single browser program? In many ways the browser is an improvement. So, you would rather run network applications and remote scripts directly on the OS rather than "have an OS on an OS". You want basically where people download all of these untrusted applications that run directly on the OS like the bad old shareware/trojan days.
The need for a stable API is a seperate issue from the need to sandbox and run remotely downloaded code in a VM, written in a memory safe interpreted language rather than the awful C/C++.Static web pages have no business using JS, I agree, but for a dynamic program, running an application inside a sandboxed brower on a Javascipt VM is heck of a lot safer than running it as a machine code binary compiled from buffer overflow filled C++ fully exposed to the OS Kernel interface.
HTML/CSS should be used for static data, then JS used for dynamic data. I would rather not be forced to use seperate browsers/apps for dynamic and static web pages, however.
Um, have you ever heard of DOM and Javascript, there is your framework. Improvements can be made on this foundation. Also, the bidirectional communications are improving with WebSockets. Serialization? Ever heard of XML or JSON?
Standards can be a double edge sword. They foster compatibility but also slow down progress too much. A good standard should allow non-standard extensions and a mechanism for apps to detect and to live without extensions. Then, extensions can be folded into the main standard.
Not necessarily. A good toolkit would emulate what the OS does not support as well as possible. For anything beyond that, applications could be written to adaptively live without certain features only when not available. But given a good toolkit, that should be unnecessary.
The problems you describe can either be solved by the cross platform compatability library either emulating features on its own, or by applications adapting to absense of a feature by using an alternative or living without the feature when it is not available on an OS. Preferably the first alternative. Provided a basic level of functionality, anything can be implemented at the library/app layer. For instance, if you have a 24 bit video array buffer, you can implement any 3D operation in software, even though all you an give to the OS is bitmap data. It may not be perfect, it may be slow, but it can be done and its better than nothing.
There is an issue with cross platform libraries keeping up with applications needs so that apps are not tempted to include OS specific code. The library should meet the needs of the application rather than vice versa. App developers if they need an OS feature, instead of putting an OS specific call in thousands of places in apps, should just add a compatability layer once to the cross platform library, this way when they move to a new OS, they only need to update one peice code rather than thousands.
You mention web standards. For some while, they were indeed very weak, which was their own fault. Browsers dragged their feet on providing features but at the same time they provided horrible plugin models for OS level plugins. Basiclaly the browsers were saying, we dont provide the feature you need and dont care, but please write an OS dependant plugin using NSAPI so your web page can only be viewed on Windows. Thank you. Mozilla was guilty of that as any. I think it would be much preferable as an alternative to have provided a canvas to web apps in the browser to which vector and bitmap primatives could be drawn with javascript, rather than unleash a flood of low level plugins which had bad OS dependant code. Yes, eventually this is what ended up happening. I think we also have to accept 3D APIs in the browser to stave off OS dependant plugins adn third party apps.
As far as source code goes, the mainframe era was sort of open source, they made their money on hardware and did not copyright the OS, that changed when OS/Hardware mandatory bundling was banned and third party OSs entered the fray. IBM stopped making copyright free MVS around 1980, you can still run the "open source" MVS version 3.8J, the last copyright free version, as Turnkey MVS (Tk3 or Tk4) today on Hercules. It was the shift that happened in the 70s and 80s to closed source that spawned GNU.
Of course its possible. Several options exist. It involves using a cross platform library that provides the same API on all OSs and hides the OS level variances. To make this really work well of course a complete and powerful API is needed to account for the unpredictable needs of a wide variety of programs. Preferably, APIs for audio, graphics, 3D, video, access to audio and video input output devices, and so on is needed. One such library that has done this is Qt. As far as languages, C/C++ were designed to be cross platform but I do not recommend these in applications due to how difficult it is to write software without security problems with them. I am quite fond of Python and Qt used together.
There is also Java which is another good option.
It would save time in the long run for an application developer, if they found that a cross platform library needs a new feature for their app, to add this to a cross platform library, rather than code OS specific code directly into their application. This avoids having to port applications to a changing list of target platforms, and it tends to easier to add a compatability layer once to a library and then call that hundreds of thousands of times from app code, than it would be to change possibly hundreds or thousands of lines of app code. If you have a function that accesses OS level feature, and is called a thousands of times from applications, and you need to port that app to a new OS, its easier to make a single change by adding a new compatability binding for the function for a new target OS, rather than change the many thousands of invocations of the function.
He is a bunch of senseless babble. The nul and undefined nonsense is basically what color to paint the shed nonsense, that has more to do with just changing something for the sake of change or for some spurious reason. They have some convoluted reason but its some highly obfuscated answer using complicated convoluted argumentation to hide its trite baselessness. Functional programming tends to turn into a mess and is not itself a "feature" because many procedural languages have a full set of functional features, functional languages do not offer something other languages do not, its more about what they do not have to fit some puristic idea of the functional cult zealots. the comments about let and define are more nitpicking rather than a real substantial issue. So there are two ways to define a variable. So what? The sky is not falling.
Attempting to go functional leads to horrendous obfuscation and bizzarre code when you try to interact with the external environment. Thanks, but no thanks.
There is no need to replace javascript and this itself is a waste of time and resources, because everyone who knows javascript would have to learn a completely new language, and they will waste time doing so rather than just getting stuff done. People like Crockford are talkers rather than doers who sit around talking about how they are going to make life difficult for others and coming up with crazy schemes to waste peoples time. They are like beauracrats who come up with senseless regulations, they contribute nothing but they enjoy the feeling of power of being able to obstruct productive people.
the best thing we can do is ignore nonsense from these kinds of people.
Uber is basically garbage. A large corporation that is becoming the amazon of cabs, reducing wages for the purpose of corporate profits. Want to do something good for your community? Hire a local cab driver to keep the money in your local community rather than give it to this big corporation to be siphoned off for some overpaid CEO.
Slashdot Mirror
It should be pointed out x86-64 has security facilities that are equivalent to a harvard architecture, protection levels, setting pages with read/write/execute bits and so forth, as with the NX bit. The problem here is Word, and the security profiles at the OS level that allow scripts to access the filesystem. A harvard architecture would introduce inefficiencies in memory and bus utilization without giving you anything that you cant get with page tables and privilege levels on
The code should go into a sandbox, or not be run at all. A sandbox is an option both OS level, and the interpreter. Running code without that in a DOC file IS nuts. Reducing the kernel attack surface like Chrome has done is one tactic that can be used, using a controller/controllee sandbox. Its not rocket science. Its just plain incompetence to not do this.
Not really necessary at the CPU level, a good OS can allow you to do a RBAC rule that will block any file from being executed in a user writeable directory. It should be up to the OS to provide a complete security model. The thinking of putting overly complex security models into the CPU is wrong. This is because if a bug slips in its harder to update the CPU. The CPU has basic page functionality, NX bits, privelege levels adn so on that provide the basic tools needed for the OS to implement any security model needed.
But then they find a way to break out of the VM
What about LibreOffice? Does it run code in document files/allow them access to the system?
What do you recommend? C/C++ programs facing the internet? I dont think there exists many large C/C++ programs that have not had severe buffer overflows. PHP/Perl/Ruby etc with their automatic memory management are relatively safe by comparison.
As long as it is clearly documented what it will do, and you know what precisely what it will having it automatically do things isnt necessarily bad, can save time, as long as finer grain control is allowed. If it is poorly documented and does unexpected things, this is pretty bad. Allowing a system command to be run is a pretty nasty undocumented automatic behaviour.
What would you recommend instead?
Kafka claims to be a streaming platform, and Struts claims to be an MVC framework. So, they serve different domains it would seem.
Amazon did it in. I don't know if anything could have saved it.
Radio Shack has been selling consumer electronics for a long, long time, over 50 years at least. And yes, people did buy stuff there. The hobbyist market is not large enough to keep them alive, just not enough people like that around. Amazon did it in. Amazon can run losses for 20 years because its a wall street darling, so its been undercutting everyone else. Antitrust behaviour, if you ask me.
There seems to be a deliberate attempt to destroy the sensibilities, intellect ,morals of the population by putting out of all of this out of tune, profane, creepy, depressing, dismal, tasteless, trashy, low grade music that appeals mainly to crackheads, deadbeats stoners, self obsessed and arrogant millenials, sado-depressive types and the like. Pop, rap, rock, its all garbage. Real music disappeared long ago, Now we have this bleak, dystopian nonsense that seems to be designed to destroy the minds of those who listen to it. So, nothing worth buying here, I advise everyone to not purchase this garbage and put hollywood out of business for good. It would do our society a big favor.
The best solution to this is for cross platform toolkits to emulate whenever possible missing OS features. Otherwise you have feature testing to write apps adaptively, using cross OS APIs when the underlying OS has the feature, but this is far from optimal. Providing the OS provides some basic underlying features, features can be emulated by a toolkit. Adaption always has to happen with a number of variables like screen real estate
I mention that is much much safer to run Javascript code on a VM in a sandboxed browser process than it is to run machine code compiled with C++ full of hanging pointers, bad mallocs, buffer overflows, running directly exposed to the OS Kernel interface.
So your suggesting I should have to run dozens of network aware applications with crappy C/C++ code rather than relatively safe sandboxed JS code in a single browser program? In many ways the browser is an improvement. So, you would rather run network applications and remote scripts directly on the OS rather than "have an OS on an OS". You want basically where people download all of these untrusted applications that run directly on the OS like the bad old shareware/trojan days.
The need for a stable API is a seperate issue from the need to sandbox and run remotely downloaded code in a VM, written in a memory safe interpreted language rather than the awful C/C++.Static web pages have no business using JS, I agree, but for a dynamic program, running an application inside a sandboxed brower on a Javascipt VM is heck of a lot safer than running it as a machine code binary compiled from buffer overflow filled C++ fully exposed to the OS Kernel interface.
HTML/CSS should be used for static data, then JS used for dynamic data. I would rather not be forced to use seperate browsers/apps for dynamic and static web pages, however.
Um, have you ever heard of DOM and Javascript, there is your framework. Improvements can be made on this foundation. Also, the bidirectional communications are improving with WebSockets. Serialization? Ever heard of XML or JSON?
Standards can be a double edge sword. They foster compatibility but also slow down progress too much. A good standard should allow non-standard extensions and a mechanism for apps to detect and to live without extensions. Then, extensions can be folded into the main standard.
Not necessarily. A good toolkit would emulate what the OS does not support as well as possible. For anything beyond that, applications could be written to adaptively live without certain features only when not available. But given a good toolkit, that should be unnecessary.
The problems you describe can either be solved by the cross platform compatability library either emulating features on its own, or by applications adapting to absense of a feature by using an alternative or living without the feature when it is not available on an OS. Preferably the first alternative. Provided a basic level of functionality, anything can be implemented at the library/app layer. For instance, if you have a 24 bit video array buffer, you can implement any 3D operation in software, even though all you an give to the OS is bitmap data. It may not be perfect, it may be slow, but it can be done and its better than nothing.
There is an issue with cross platform libraries keeping up with applications needs so that apps are not tempted to include OS specific code. The library should meet the needs of the application rather than vice versa. App developers if they need an OS feature, instead of putting an OS specific call in thousands of places in apps, should just add a compatability layer once to the cross platform library, this way when they move to a new OS, they only need to update one peice code rather than thousands.
You mention web standards. For some while, they were indeed very weak, which was their own fault. Browsers dragged their feet on providing features but at the same time they provided horrible plugin models for OS level plugins. Basiclaly the browsers were saying, we dont provide the feature you need and dont care, but please write an OS dependant plugin using NSAPI so your web page can only be viewed on Windows. Thank you. Mozilla was guilty of that as any. I think it would be much preferable as an alternative to have provided a canvas to web apps in the browser to which vector and bitmap primatives could be drawn with javascript, rather than unleash a flood of low level plugins which had bad OS dependant code. Yes, eventually this is what ended up happening. I think we also have to accept 3D APIs in the browser to stave off OS dependant plugins adn third party apps.
As far as source code goes, the mainframe era was sort of open source, they made their money on hardware and did not copyright the OS, that changed when OS/Hardware mandatory bundling was banned and third party OSs entered the fray. IBM stopped making copyright free MVS around 1980, you can still run the "open source" MVS version 3.8J, the last copyright free version, as Turnkey MVS (Tk3 or Tk4) today on Hercules. It was the shift that happened in the 70s and 80s to closed source that spawned GNU.
Of course its possible. Several options exist. It involves using a cross platform library that provides the same API on all OSs and hides the OS level variances. To make this really work well of course a complete and powerful API is needed to account for the unpredictable needs of a wide variety of programs. Preferably, APIs for audio, graphics, 3D, video, access to audio and video input output devices, and so on is needed. One such library that has done this is Qt. As far as languages, C/C++ were designed to be cross platform but I do not recommend these in applications due to how difficult it is to write software without security problems with them. I am quite fond of Python and Qt used together.
There is also Java which is another good option.
It would save time in the long run for an application developer, if they found that a cross platform library needs a new feature for their app, to add this to a cross platform library, rather than code OS specific code directly into their application. This avoids having to port applications to a changing list of target platforms, and it tends to easier to add a compatability layer once to a library and then call that hundreds of thousands of times from app code, than it would be to change possibly hundreds or thousands of lines of app code. If you have a function that accesses OS level feature, and is called a thousands of times from applications, and you need to port that app to a new OS, its easier to make a single change by adding a new compatability binding for the function for a new target OS, rather than change the many thousands of invocations of the function.
Agreed. 100%.
He is a bunch of senseless babble. The nul and undefined nonsense is basically what color to paint the shed nonsense, that has more to do with just changing something for the sake of change or for some spurious reason. They have some convoluted reason but its some highly obfuscated answer using complicated convoluted argumentation to hide its trite baselessness. Functional programming tends to turn into a mess and is not itself a "feature" because many procedural languages have a full set of functional features, functional languages do not offer something other languages do not, its more about what they do not have to fit some puristic idea of the functional cult zealots. the comments about let and define are more nitpicking rather than a real substantial issue. So there are two ways to define a variable. So what? The sky is not falling.
Attempting to go functional leads to horrendous obfuscation and bizzarre code when you try to interact with the external environment. Thanks, but no thanks.
There is no need to replace javascript and this itself is a waste of time and resources, because everyone who knows javascript would have to learn a completely new language, and they will waste time doing so rather than just getting stuff done. People like Crockford are talkers rather than doers who sit around talking about how they are going to make life difficult for others and coming up with crazy schemes to waste peoples time. They are like beauracrats who come up with senseless regulations, they contribute nothing but they enjoy the feeling of power of being able to obstruct productive people.
the best thing we can do is ignore nonsense from these kinds of people.
Uber is basically garbage. A large corporation that is becoming the amazon of cabs, reducing wages for the purpose of corporate profits. Want to do something good for your community? Hire a local cab driver to keep the money in your local community rather than give it to this big corporation to be siphoned off for some overpaid CEO.