<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to 8: reconsider the addition of system and kill commands ...</title><link>https://sourceforge.net/p/kidbasic/support-requests/8/</link><description>Recent changes to 8: reconsider the addition of system and kill commands ...</description><atom:link href="https://sourceforge.net/p/kidbasic/support-requests/8/feed.rss" rel="self"/><language>en</language><lastBuildDate>Tue, 07 Sep 2010 23:37:24 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/kidbasic/support-requests/8/feed.rss" rel="self" type="application/rss+xml"/><item><title>reconsider the addition of system and kill commands ...</title><link>https://sourceforge.net/p/kidbasic/support-requests/8/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;I would suggest to seriously reconsider the addition of the system and the kill commands, they will basically allow kids to delete crucial files, possibly even system files. I am personally not convinced about the educational value of providing access to system level details that are better hidden to most users; a programming environment like kidbasic is all about trying out new things, running experimental code. And my personal view is that experimental code should always be run ina "sandbox" environment, like a VM for example ... now starting to provide access to system level APIs to execute arbitrary commands or unlink files could possibly be problematic, especially once users start to share "fun scripts" to erase files or run arbitrary commands - not all kids will immediately understand every piece of code, and so it is very well possible that kidbasic could be used to cause harm... &lt;br /&gt;
If these commands are really deemed necessary, I would personlly consider providing a kidbasic specific verification dialog that EXPLAINS exactly to the user what is happening when a certain command is executed or a particular file is to be deleted.&lt;/p&gt;
&lt;p&gt;Confirming this should then only be possible by the user, and not within kidbasic directly, i.e. using a modal MessageBoxA dialog&lt;/p&gt;
&lt;p&gt;Don't get me wrong, I am absolutely aware of the fact that other BASIC dialects (or scripting languages) provide even more access to such low level APIs, however I have always been convinced that this is not right for a teaching environment - which really should be "SANDBOXED" in my eyes, whenever code is run that might possibly harm the system, the user should be made directly aware of this. As soon as it's possible for people to run code in kidbasic that could theoretically render their system usable, I can no longer allow kids to run kidbasic on every computer, certainly not on MS windows systems where ACL is much less securely implemented than on Linux ... which basically means that a kid could -for examle- delete a complete Windows OS, including important documents, just by running experimental code.&lt;/p&gt;
&lt;p&gt;So, yeah - I am somewhat opposed to this ... even though I can see that this could be useful for more advanced things.&lt;br /&gt;
Maybe the best thing would be to introduce some form of "system level firewall" for enabling/disabling access to such APIs.&lt;/p&gt;
&lt;p&gt;I really don't know for sure... but I would hate seeing people report how their kids managed to delete important data by running some rogue kidbasic programs, that -quite possibly- they may not even have written themselves let alone have understood in the first place.&lt;/p&gt;
&lt;p&gt;J.D.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Anonymous</dc:creator><pubDate>Tue, 07 Sep 2010 23:37:24 -0000</pubDate><guid>https://sourceforge.net7941f91777f60d228fbd389d00d71882b54281a8</guid></item></channel></rss>