AltME groups: search

ubuntu sounds good. there is a kubuntu or something beased on kde. 
also, dont know about ubuntu, but on debian if i would install a 
kde-program without having kde, it would suggest a lot packeages, 
and 100mb later i would have everything including desktop i guess.

http://www.debian.org/distrib/packages, at the bottom you can enter 
a filename and usually get its package. most libs have compat-somethings. 
i guess the packages on ubuntu are similar, and that they have a 
similar page. (my link shows in german here, i guess thats some smartness. 
you should see something in your language).

the interesting thing is usually the .so.6, which is the version-number. 
you can install multiple versions of libs, and altme wants an old 
one.

and expert in pasting error messages in google.

http://lists.ubuntu.com/archives/ubuntu-bugs/2005-July/068257.html

http://lists.ubuntu.com/archives/ubuntu-bugs/2005-July/069412.html
till now i know you have a bug.

and they play the ball to  altmes/sdk . http://lists.ubuntu.com/archives/ubuntu-bugs/2005-July/069415.html
*sigh*

I'm on Ubuntu Hoary here, which is basically Debian, and I'm running 
View and AltME

I have libxaw6, libxaw7 and libxaw8 installed, which are standard 
Ubuntu packages. libxaw7 is the standard XFree86 library, libxaw6 
is the older X11 library, and libxaw8 is a new version of libxaw7

just install Mandriva 2006 and then Rebol/Altme. Altme is acting 
different than the old Mandrake 10.1 install. It's showing all the 
messages in the All Groups-not the Rebol group etc ?

it can be done (with a *lot* of effort), but it's too risky. it's 
much easier to rent a new server with reiser and move the data.

maybe you can do it by adding a new hd to the server. still a non-trivial 
task though, and i would try it on a local machine at least twice 
before attempting on a remote machine. :)

robert,  I would ask your hosting company if they can give you access 
to the terminal server  (so that you ssh there and then you can reboot 
and see boot messages as if you were on a local terminal - note you 
might have to configure the server first

otherwise you're better off letting them handle the os upgrade or 
better ask for a up to date box (e.g. with Fedora core 4) and migrate

the terminal server is used by the hosting company to access multiple 
servers consoles without having physical consoles. When they reboot 
a machine the can get the bios boot messages because there is a console 
cable to the terminal server and they normally access the terminal 
server via ssh

Is it very different from knoppix? HAs knoppix stiil the better hardware-detection? 
Than 1-2weeks knoppix and thenubuntu?

Knoppix still has better detection, but yes, it's primarily a live 
CD. I use Ubuntu in most cases, but I use MEPIS instead of Knoppix, 
which is also very nice and can both be installed and used as a live 
CD, like Ubuntu

I've installed Ubuntu for my girlfriend and it seems to work without 
problems. My win-comp crashed badly again so I'm thinging about changing 
my OS. I want to know what alternatives are there, what distro seems 
to work best. I tried Mepis yesterday but was dissapointed, it had 
some strange problems.

easy to use =  Xandros, linspire, mepis, pcbsd. I personally use 
linspire ( the only one that finds all my hardware and it works), 
mepis is real nice but it won't detect my 4 port lan ( only 2 ports) 
Xandros crashes with my video card, pcbsd ( freebsd) is very nice 
but right know it has issues with flat monitors, Oh Oh you can try 
PClinuxOS it is easy too and with a lot of eye candy.

well my fav is still Mandriva-works out of the door and is the only 
distro that worked under Vmware.tried both ubuntu

Damn Small Linux 2.0 released..  http://www.damnsmalllinux.org/index.html


Damn Small is small enough and smart enough to do the following things:


    * Boot from a business card CD as a live linux distribution (LiveCD)
    * Boot from a USB pen drive

    * Boot from within a host operating system (that's right, it can 
    run *inside* Windows)

    * Run very nicely from an IDE Compact Flash drive via a method we 
    call "frugal install"

    * Transform into a Debian OS with a traditional hard drive install
    * Run light enough to power a 486DX with 16MB of Ram

    * Run fully in RAM with as little as 128MB (you will be amazed at 
    how fast your computer can be!)

    * Modularly grow -- DSL is highly extendable without the need to 
    customize

50mb and includes.. 


XMMS (MP3, CD Music, and MPEG), FTP client, Dillo web browser, links 
web browser, FireFox, spreadsheet, Sylpheed email, spellcheck (US 
English), a word-processor (FLwriter), three editors (Beaver, Vim, 
and Nano [Pico clone]), graphics editing and viewing (Xpaint, and 
xzgv), Xpdf (PDF Viewer), emelFM (file manager), Naim (AIM, ICQ, 
IRC), VNCviwer, Rdesktop, SSH/SCP server and client, DHCP client, 
PPP, PPPoE (ADSL), a web server, calculator, generic and GhostScript 
printer support, NFS, Fluxbox window manager, games, system monitoring 
apps, a host of command line tools, USB support, and pcmcia support, 
some wireless support.

or remove all the other junk and put just REBOL on top of the kernel...

and suse on Vmware and only mandriva could coonect to the net/play 
mp3s and other important stuff PLUS Rebol -  Altme

Robert, you may find the right glibc rpm here: http://rpmfind.net/linux/RPM/index.html

Be sure to read about the different ones, so you get the right one.

You should be able to have more than one version of glibc installed 
at the same time (so everything will work). There are programs with 
GUIs in RedHat Linux to install rpms, or you can use the rpm command 
from the command line.

It's been a while, since I used Linux, and it can be a hazzle to 
update sometimes.

hazzle would a good portmanteau word combing hassle and hazzard :-)

Except linux has version-numbers in the filenames and ms has not 
:)

And:
[[root-:-km1428] root]# ldd /usr/local/bin/rebcmd

/usr/local/bin/rebcmd: /lib/i686/libc.so.6: version `GLIBC_2.3' not 
found (required by /usr/local/bin/rebcmd)
        libm.so.6 => /lib/i686/libm.so.6 (0x4001e000)
        libdl.so.2 => /lib/libdl.so.2 (0x40041000)
        libc.so.6 => /lib/i686/libc.so.6 (0x40045000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Robert, actually Linux not only has not solved the DLL problem, they 
are even worse in some respects. In particular, you'd need to compile 
and distribute a different version of REBOL for each linux distro, 
not because the code is any different, but because it needs to link 
to different version of libs and so on (with different include files...); 
there is no way to ensure compatibitly.

Well, its not designed for binaries.. Interface os thru a wrapper, 
distribute the wrapper and rebol.o, problem solved..

Why Web Applications Can be Problematic and Unreliable
 -- http://www.sys-con.com/story/?storyid=47364&de=1

and why would it work with encapped scripts?

well, my cgi scripts run well.. very well.. I just tried to encap 
them and..  :-(

Take a look at http://www.johnsons-web.com/cgi-bin/test.r.This is 
very bizarre! If you use netscape, you will see the entire usage 
message from rebol displayed prior to the mime-type header. If you 
use IE, it is likely that some but not all of these effects will 
be obfuscated, but you should be able

to see the entire output if you view the source. The sources from 
the script is being sent from a windows computer to a linux server. 
Now, if

I use a FTP client like WS_FTP which as a "ascii" mode, it automatically 
converts line enders to unix style, and this problem does not occur.

Josh Mitts is in charge of the project and this discussion.

Josh, is there some way to automate the build process, and do the 
certificates or whatever, so when you leave again, a new version 
can still be easily built?

and is this restriction to running one plugin only per page stil 
present?

And please feel free to hack at it, try exploting buffer overruns, 
etc.

but at some point it'll be essential to run encapsulated scripts 
and use secure connections

I need the plugin for an application that could potentially be used 
for a few thousand users in an open enterprise environment, but signed 
scripts and security are essential there.

in short, we have to make sure that the right users are running the 
script and only those users have access to data (customers, accounting, 
etc.)

one issue is size. do we distribute /pro/view to everyone, and make 
everyone download a bigger file? or do we have two different plugin, 
two different sizes?

The latest client request I got was to have it called something other 
than "REBOL". I know this sounds funny to us, but they were doing 
a demo and the potential client did *not* like the idea of installing 
something that sounded rebellious. Seriously, this happened.

The URL for download is: http://www.rebol.net/plugin/moz-1/.

Installation instructions: Download all the files. Copy them to your 
plugins directory (except test.html). Open test.html and it should 
work.

Please post bugs, comments, and suggestions to this group. All feedback 
is welcome!

did you download and copy the files to your firefox plugins directory?

close and restart firefox?

I didn't restart. I now reloaded the page after dismissing the missing 
plugins message bar and the plugin disappeared now

go ahead and restart firefox. that's key.

it works if you close the tab and open the url in a new one

Not RAMBO. Maybe create a checklist here and put them on it.

hit back button and forward and then  cyprhes worked. guess it was 
still downloading something.

Now I recall one my old rant... would be very nice if  there's a 
way to call rebol func from javascript.  Something like: 

<input type="button" value="Send" onclick="rebPlugin.evaluate('send');"> 

So we can build an html interface and use plugin & rebol instead 
of  XMLHttpRequest and Javascript

Is this group more for bug fixes to the new plugin, or is it a place 
to make suggestions and discuss security issues?

Security Issues:

- We should to be able to restrict with the secure native what files 
and dlls the plugin can access.

- The default security of the RT-provided plugin (not encapped by 
a third-party) should prohibit any access to any local files or libraries 
at all, even in the same directory as the script, and prohibit access 
to third-party network addresses as well. Or at least ask.

- There should be some way to access the site's cookies from the 
plugin, because there shouldn't be any other way to store local data 
on the client computer's hard drive. Anything short of that will 
be a security hole.

- There should be no way to reduce the default security of the plugin 
through the use of plugin params.

- Any attempt to reduce access should prompt the user for permission, 
in terms a non-technical user can understand. This means rewriting 
the security dialogs to be more user-friendly.

- Any relaxation of these default security restrictions should require 
encapping the script.

- A user (or their lawyer) should to be able to (perhaps through 
RT) track down the author of any encapped script.

- An encapped script should count as a seperate plugin as far as 
the user is concerned, at least as far as permission-to-install is 
concerned.


Basically, the default security of the plugin should not allow scripts 
to do anything you wouldn't want your worst enemy to do on your computer. 
People will try to use this plugin for advertisements, for webbugs, 
for spyware, for every nasty thing that you aren't evil enough to 
think of. Avoiding that kind of thing should be the focus of the 
default security settings. Anything less will make the plugin unsafe 
to install.

Might I add that a requestor should appear for EACH port access needed 
and the remote url MUST be clearly identified, each time.

Yes, and design the security dialog so that longer URLs are able 
to be fully shown,either by wrapping or scrolling.

we should also be allowed, as a user, to filter out ip adresses and 
urls which we never want to accept.

Hmm.  I want to access libraries, and run scripts ( batch files ) 
which I create dynamically

graham, this is why, I think this should be configurable, you could 
allow the plugin to only load and save from specific dirs.

hum, disk space is a concern.  maybe the plugin could simply enforce 
the use of one single write space and protect individual sessions 
from accessing other sessions.

this could easily be handled like a cache and user could impose size 
limits on individual and collective size of all sessions.

We don't want the default plugin to be able to put even a single 
byte outside of the browser's purview without prompting the user 
first. Users have enough security problems to deal with without wondering 
if their banner ads are putting files on their hard drive. As it 
is I know many users who use AdBlock as a security measure - they 
don't care whether they see ads, but many of those ads contain nasty 
code and spyware installers.

No offence to you Graham - you are (apparently) one of the good guys. 
But what you are describing is exactly the kind of behavior that 
we should restrict to encapped scripts that should require an additional 
installation notice, maybe even seperate plugins. Either that or 
through the encapping process  have RT act like a certificate authority, 
allowing us to take an encrypted script and have RT tell us who licensed 
theparticular SDK that encrypted it.  That way we can have the authorities 
(or lawyers) track down an evil developer.

Let's see what a "neutered" plugin can do:
- REBOL/Services
- All of REBOL's GUI and graphics stuff.
- Access browser data (that is site-specific)
You can do a lot with that. Look at Flash.

Let it prompt the user for files to work on, using the system file 
dialog even, and then allow the plugin to work on only the files 
that the user specifies. That should be a good balance.

Personally, I feel that the plugin will never gain general acceptance 
unless it is, to use Graham's phrase, "neutered" to the extent that 
it has no local files access and can make no system calls. It should 
be constrained within the browser's environment just like JavaScript 
and Java Applets.

The places a browser puts persistent data, and manages that data, 
are cookies and the temporary file cache. There are already security 
restrictions and management tools for those places. That existing 
persistent storage should be sufficient for REBOL scripts loaded 
by the regular plugin. Any other storage should be on the server, 
with the same server access restrictions as JavaScript. Anything 
more should be restricted to trusted sites.

say I have a farm of  pcs running some seti like application and 
rebol using the browser plugin with lns to send the results back 
to a server.

What we may need is a way to partially encap scripts:

- Encrypt them using the SDK licensee's key in a way that can be 
decrypted by the plugin and traced to the licensee.

- Decrypt them with RT's plugin rather than bundling them with native 
code.

- Prompt when loading them the first time, perhaps with company info 
like IE does with ActiveX controls.
- Give encapped scripts a sandbox directory like rebsite scripts.

- Let these scripts do what they must, knowing that if they are malicious 
you know who to sue.

Basically, Java Applets and JavaScript have no access to local files.

Java Applets can be digitally signed and you can grant "trusted applets" 
local access.


I'm not sure how much this is used and whether people really grant 
trusted access.

Java applets and JavaScript scripts are usually only allowed to access 
their own server over the network. I think you can make that same 
restriction to REBOL using the secure native.

Without prompting the user, cookies and JavaScript. Perhaps REBOL 
could prompt for any additional files it needed to access using a 
standard file open dialog (by standard I mean native).

Anything more would require a cryptographically signed script, traceable 
to your SDK license key, and thus to you.

and so, what about attempts to run it outside the browser? I'm thinking 
licensed scripts that someone figured out to download separately 
and tries to run it directly in REBOL/View. I'm not sure how much 
of an issue this is, but it's a first step towards reverse engineering.

apple and konfabulator widgets would not be as numerous if signing 
was required for scripts

Anonymous scripts should be able to read through the browser cache, 
at least for files from their own site, but should assume that those 
files won't necessarily persist beyond the browsing session. You 
don't want to give them a sandbox that doesn't have its space limited 
by the browser's existing facilities, for security and privacy reasons. 
You definitely don't want anonymous scripts to store more than cookies 
on your systems.


The guideline you should set for default behavior of anonymous scripts 
is to limit it to the activities that would be OK for deliberately 
malicious code to do. Assume that all anonymous code is out to get 
you until proven otherwise. This is a browser plugin you know - it 
will be used in banner ads.

and "sell" it to the AJAX developer community :-)

BTW, someone needs to consider the new plugin activation that Microsoft 
added to get around that BS patent, and what effect it will have 
on the IE browser plugin.

Hello Josh! I have one request. Try to run this:

under IE:
http://www.rebol.cz/~cyphre/plugin-ie.html

under Mozilla/FF etc.:
http://www.rebol.cz/~cyphre/plugin-moz.html


Drag the green box using mouse and try to move it quickly over the 
screen. You can see the time lag when the green box is updating the 
position.

Now try this from normal Rebol/View console:
do http://www.rebol.cz/~cyphre/plugin-moz-test.r


You can see there is no lag and the green box is updated very quickly.

Do yo have any idea what could cause this difference?

my specualtions: 

1. Are you always blitting the whole screen in the plugin versions? 
This could cause the slowdown as there should be updated only the 
part with green box on the screen.

2. Could be the slowdown cause by different(higher)  amount of mouse 
events which are pumped from browser to the plugin?

I have two wishes re. Rebol and the browser -- 1) to use Rebol as 
a language replacement for JS, and 2) to be able to launch Rebol 
scripts intelligently.  The importance of running Rebol as a Flash 
replacement is a distant third.

2) I have brought up before -- a plugin could intercept and interpret 
a Rebol script, using the header metadata to create a launch 'page'.

Please post your bugs and feature reqs there....one bug/feature request 
per item. Repro steps and target platform (for bugs) and clear descriptions 
with examples  (for feature requests) help :)

We need to investigate it. On IE, this is accomplished through a 
COM Interface to the browser object (via IDispatch), and then we 
call the method execScript on the IHTMLWindow object, passing the 
string of the code. But on Mozilla, there is no such COM interface, 
so we need to find if there is an interface available to the plugin 
to pass JS code.

2) Build an automatic updating mechanism into the plugin, so it will 
check for new updates, prompt the user if he or she wants to download 
those updates, and then install on-top of the previous installation.

(2) is what I am leaning towards, and that is also the approach Flash 
takes. It involves making some changes to the installation architecture, 
developing an installer program to drop the files over-the-top of 
the previous files, and writing some REBOL script to check for new 
updates.

(note: The REBOL standalone EXE currently does something similar, 
but the difference is that the plugin doesn't know where it is installed...yet 
(so it can't drop the files over the old ones), and plus, the installation 
process for updating 2 DLLs is different than updating 1 EXE).

Yes, the installation will have to be quick. That's not a problem 
though, as we can download the files in the background (similar to 
what Flash and Acrobat Reader do).

not just that, but there should be a ridicoulus minimum amount of 
instructions to install it. such as: 1. go to this site to observe 
the installation. 2. click here to test. and that should be it. I 
know that's very difficult to do, but it should be the goal.

(I want to change the above priority list. Mozilla 1.3.2 and IE 1.3.3 
are equal priority, pri 2)

3. REBOL script within plugin launches updater EXE, which asks user: 
"Would you like to install REBOL/Plugin? Note: Your browser will 
have to be restarted."

 4. Updater EXE closes browser, copies files, and re-opens browser 
 to the page the user was at.

5. new plugin launches seamlessly and runs the old script.

console = popup window and some users hate those

Well, we can throw it into Qtask, let everyone log any task they 
want, and then you can assign them priorities.  This is what Qtask 
does.

but like the first plugin version do not forget to take proxy configuration 
of IE or FireFox and the bypass-proxy input !!!!!!

For plugin updating, you could make the minimum version a parameter 
and have the plugin update if the requested version isn't installed, 
or fail if the requested version doesn't exist.

As for things like do-browser, it would be nice if the copy of REBOL 
called by the plugin could be passed some callbacks to which it would 
delegate some basic functionality like requesting a local file, proxy 
settings, do-browser, etc. This would allow the plugin to better 
integrate with the browser's existing behavior and security infrastructure.

By the way Josh, the security discussion we were having last night 
wasn't noise. Without the security restrictions discussed above noone 
would be able to safely install this plugin and allow it to run scripts 
from any but the most trusted sites. This is important.

thanks for the feedback. i apologize if i conveyed the idea that 
security discussions are noise. What I mean is that I don't have 
the bandwidth to sift through pages of discussion and build the plugin 
at the same time. So, for my sake, we need some kind of itemized 
system where Carl and I can tackle the issues one-by-one.

And -- yes, I need to read through the conversations, but a free-for-all 
format (that includes bugs, etc.) doesn't really work for me. Maybe 
a checklist, or perhaps, Qtask (mentioned above)?

It's pretty good, simple and easy to use.