I used to use Locus back in the days when I didn't have a internet connection at home (I lived in halls at uni and we had no landline) to tell me when I got email on a particular address so that I could nip across if I was, say, in the student bar, and read the mail. Importantly it was free for each SMS (unlike any other provider) so spammers didn't end up costing me a fortune.
Of course now I have broadband at home and fat pipes at work I don't need this anymore, but back then it was a real boon.
I guess what I'm saying is that these guys offered a real innovative service which I was really grateful for, and I wish them the best in the future.
Our site had code that created dynamic Flash movies with perl. Now, for those of you that can imagine dynamic image creation meets slashdot effect - think bigger and you're about there. Ouch!
My server got a load of about 50 and stopped responding to outside stuff (it timed out) but Linux didn't go down or crash.
Last month I spent two days printing out and binding the freely avaliable mod_perl guide. In the end I ended up with four bound sections that take up a lot of space. This took a lot of my time, and was a very frustrating experience (Dammit Jim, I'm a coder, not a reprographics clerk.)
I'd chip in 20usd to have this published, and know at least four other people who'd do the same. I simply am that lazy - and I think it would be great advocacy too. We rely a lot on this kind of information, and it'd be great to have it in meetings, take it home to read in the bath, on the desk not taking up screen space, etc, etc, etc.
What I'm basically trying to say is that there's a lot of online only material that I'd love to have in dead tree form as well. And I (and my firm) would be quite willing to pay to see it happen.
Yep, it's CPU intensive. That's why our server now has a load of 30.
However these are just demos. As I've said in other posts, they never were meant for widescale public debate. They were put up so that all the people we'd talked it over with could have a look at what could be done. Lots o' optomisation needs to be done.
Producing Flash files is really quite expensive. There's a lot of bit twiddling to be done. Most computer systems are quite happy shifting bytes around, but SWF files are packed right down to the bit level meaning that you might have tags (flash object definitions) that start on bit 4 or byte 6 and end 47 bits later. Now when you need to make changes you need to shift a whole load of bits across. On most systems that's quite expensive when you have to apply it to the whole file!
There are ways round this. Simon (the code's author) and I were talking about various ways to parse only part of the file and make good guesses about what is contained in the rest (so that you for example just search through and grab the alter the stuff you want) rather than deconstructing and then reconstructing the whole thing.
I guess the key is going to come down to the fact that in 99% of the time you don't actually have to create the thing every single time. More often than not, you can simply recreate it every 15 minutes or so, and just serve that version. I've done similar things with Java tickers in the past that grab data from the web via a perl script and update the files to be served often.
Anyway, if we compare and contrast to making images on the fly, I think you'll find that that's very slow too when scaled up to a couple of hunrded (let alone hundreds of thousand) users.
Ah, but we're (when I say we, I mean Simon is working on it and I am watching and hoping my server doesn't fall over again) working on a pure perl one.
One of the advantages in getting the Perl Flash stuff working is that you could parse SWF files and spit out any format you wanted (In theory - I stress - In theory.)
Many people I spoke to at YAPC::Europe were interested in doing this. We're striving for an XML version of the Flash file format atm. Soon (not today, not the day after, but soon) we should have something that can create an XML representation of the internal perl data structure that we can grab from a raw SWF file.
Ah, but it was up for public review (for all the people that were at YAPC::Europe and all those people on the list) before it was released to the masses. So we couldn't password protect it.
If we'd had some warning I could have at least done some simple anti-slashdot effect stuff. But now it's effectivly live I can't mess with the server without making things much worse.
It's like the perl OO model. We expect people to treat us nicely because it's the right thing to do, not because we've got a shotgun handy.
There's nothing wrong with the file format - It's simple vector graphics very well compacted.
The main problem with most Flash files is that they're created with the graphical editor. The graphical editor has a chip tool that chips away from the vector graphics and ends up creating a large number of polygons. Extra polygons = big files.
Of course with Simon's routines to create flash files from perl then this shouldn't be a problem.
For example, the Flash files I created for the Perl Flash talk at YAPC::Europe on this code (using this code) were under 10K a slide (including font info.)
This isn't the point though. This code isn't even slightly optomised. It's running as CGI on a server that's set up for mod-perl (stupid, but we only just moved these scripts to their new home and haven't altered them yet) Even if they were mod-perl then they wouldn't really be very quick - It's beta code.
However, Flash creation is *hard*. Don't ever expect it to be quick. However, sooner or later we'll write the version that only *alters* the SWF file rather than creating it from scratch.
It's not fair to judge concept code on it's performance.
Cool. One of the major things that this Flash project needs (apart from a *lot* more time to work on it) is some idea of where to go from here. Comments really, really welcome!
Currently Simon has written the wrap for the libswf that you've mentioned. But he's also written the parsing Tag routines for Flash 3. As you can understand, it really shouldn't be that hard to add a few more tags for Flash 4 and Flash 5 files if you've read and understood the spec.
I'd agree with your comments that there's a lot to Flash that what you can get with Flash 3. Flash 3 is only just Turning compatible for goodness sake! Flash 5 is really interesting and I'd love to get working on some of the more entertaining stuff.
One of the more challenging problems is that the interface we currently have is way too low level - the kind of people that need to use the tools aren't going to be interested in pushing and popping transformation matrices - they just want the text to scroll across the screen. And good on them...
How we do this, and what Flash 4 and Flash 5 tags we use to do this (and templates) is a *big* question.
First, Let me tell you who I am. I'm the owner/runner of 2shortplanks.com. This summer I gave the talk on Perl and Flash at YAPC::Europe. I've read and used the code.
Secondly, to all those people trying to see the demos. The machine load is currently at 30 - you may have to wait a bit;-) Good job we got that unlimmited bandwidth option from mailbox.
Thirdly, Simon (the authour of this code) is on holiday, snowboarding - So he can't speak to you lot, but I'll have a go at talking about where we were in the project before he left.
Simon did this code for his final year project based on an idea that I came up with but I was too lame to implement. Up to this point we are at a stage where we can sucessfully break apart a Flash movie with pure perl, and hold it as a data structure of vector graphics objects (well as SWF tags such as Rect, Shape, Text) that can be altered by access via attributes.
This has been a hard struggle for many reasons. Macromedia's open spec (which is linked elsewhere in this discussion) has many bugs in it that Simon had to work around. The other main difficulty is that Flash is a bit based file format, rather than a byte based format - read the spec and you'll see what I mean. (In other words you have 'tags' that take up less than a whole byte so you have to parse very slowly...) Simon had to write File::Binary (on CPAN) before he could start.
Simon has half done the creating perl code bit in pure perl. At this point the code is written, but isn't debugged. I don't think Simon or I am going to even attempt to do this as we've reached the point where it's logical to throw the code away and start from fresh (look mom, the evolutionary design model!) There's lots of changes we'd like to make - processing unparsed data - moving away from Class::Struct - rewriting the File::Binary to work better - template toolkit scripting ability.
One of the really cool things that Simon has done is wrap a binary library to spit out simple flash files. Unfortunatly this module is free as in beer, not as in speech (read: we don't have the C source code.) It has bugs that we can't fix, but this works in most cases - I prepared the slides for my talk at YAPC::Europe with it, as well as the demos that you, well, will be able to see the slashdot effect dies down.
Simon has been doing all this work in his spare time of late - which is very demanding. Sure, if someone was to offer him to work on it fulltime (*hint*) then a lot more could be done. At this time I'd like to thank Simon for all the hard work, often largely thankless, that he's done on this and other projects (YAPC::Europe, Acmemail, and countless help on other modules)
Now for a little news on the server itself. It wasn't ready to be slashdotted. The load is at 30 for goodness sake! Hooray for Linux not falling over! The code wasn't set up to be put under any kind of load - it's just beta code for discussion that has *no* respect for what it's running on. It should be running under mod-perl. It's not. It should not be using file-based temporary files. It is. It's a work in progress, what do you expect?;-)
In closing I'd just like to say it's a shame that we haven't had a chance to get this into some kind of workable form before the whole world decided to have a look and judge it. The site was thrown up in a rush (arn't they always) for discussion on the list. It would have been set up a lot better if we'd known the traffic we were about to get) and we'd love to have shown you a lot more.
Are you slashdot editors willing to let us have another go on the slashdot rollercoaster ride of server death in three months when we've got everything up to scratch? Go on, I dares you;-)
Hope that's been informative.
If you need any info on this then feel free to email me on mark@twoshortplanks.com and I'll be more than willing to talk over any issues. Though I'm in the UK and it's 12:30 in the morning on a Friday night atm, so don't expect a prompt reply!
There's a big difference between putting something up on the web for debate (as Simon did when he wanted the people on the london.pm mailing list to go over this.) And saying that something is up for the hostile viewing of the slashdot mob.
We *know* the html doesn't work for I.E. - Infact Simon was going to have a look at it as soon as he got back from his snowboarding holiday.
Look, this is the key issue here, that the machine has *not* been returned safely at all!
Without these wheels, the machine is useless. It can't encrypt. It's missing the cyphering mechanism...
If I install this with Gnome, what functionality will I get? Will drag and drop work (not that I really use it apart from netscape) ? What do I need to do to install it alongside gnome?
Sorry if these are simple questions, but I've never really used KDE since it first came out and I switched to gnome..
I still want to be able to use the GUI itself to do root commands though. Some things, like moving files around just make more sense to me in a graphical context...
It's not that I have to start my entire desktop enviroment when I want to do something as root (though if - note *if* - I was using windows I would have to,) it's that simply I have to start a seperate filemanger running in root mode just for that task, which is really annoying.
Compare to the simplicity of using a command prompt in a terminal...
So much easier. I don't have to navigate to where I was, I just become root, do exactly what I want and get out of root again. I want this from a GUI Filemanager....
It's not that I can't run the file manager as root, it's more that I don't always *want* it to be root.
You mentioned sudo, which I use on the command prompt and allows me to act as root when (and only when) I want. The great thing about unix is that you can run without privilages most of the time while doing your day-to-day stuff, and you don't have to worry (so much) about shooting yourself in the foot, but you still have the power to do things as root without logging out the whole desktop (unlike windows.)
I guess I just want a su (or sudo) like command/mode for gui file managers so I don't have to restart a new gui from the command prompt when I temporarly want root...
1) Run occasional 'commands' as root. I tend know the root password (and therefore should be able to do what I want when I want,) but for obvious reasons I don't want to be running as root all the time. At them momement if I want to use my GUI to perform an action as root (e.g. copy a file into/etc) I have to load up an entirely new GUI from the command line.
2) Switch between GUI and command line easier. Back when I used to use Windows I did this with the 'DOS Prompt Here' Power Tool and the 'Start.' command. Now I'm in Linux I find I can't swap backwards and forwards easily, and end up doing everything from the command prompt - but I shouldn't be forced to do this.
Can anyone tell me of a GUI File Manager that has these facilities?
Red Hat offers the standard Linux command-line tools for monitoring the server, such as iostat and vmstat. It has no graphical monitoring tools.
What about xload? I know it's just basic, but there you go.
Oh, while I'm at it they say at one point that Samba can be configured only with a ASCII file and then later go onto say you can use LinuxConf. How confusing
Slashdot Mirror
http://www.amazon.co.uk/exec/obidos/ASIN/B00005UO5 M
(series 1, 4th March 2002)
We're way ahead on Buffy as well.
Now if only we could keep up for movie releases.
I used to use Locus back in the days when I didn't have a internet connection at home (I lived in halls at uni and we had no landline) to tell me when I got email on a particular address so that I could nip across if I was, say, in the student bar, and read the mail. Importantly it was free for each SMS (unlike any other provider) so spammers didn't end up costing me a fortune.
Of course now I have broadband at home and fat pipes at work I don't need this anymore, but back then it was a real boon.
I guess what I'm saying is that these guys offered a real innovative service which I was really grateful for, and I wish them the best in the future.
A well known BBC television program....
Links
Been there, done that. Where's my award ;-)
Our site had code that created dynamic Flash movies with perl. Now, for those of you that can imagine dynamic image creation meets slashdot effect - think bigger and you're about there. Ouch!
My server got a load of about 50 and stopped responding to outside stuff (it timed out) but Linux didn't go down or crash.
Mark.
Last month I spent two days printing out and binding the freely avaliable mod_perl guide. In the end I ended up with four bound sections that take up a lot of space. This took a lot of my time, and was a very frustrating experience (Dammit Jim, I'm a coder, not a reprographics clerk.)
I'd chip in 20usd to have this published, and know at least four other people who'd do the same. I simply am that lazy - and I think it would be great advocacy too. We rely a lot on this kind of information, and it'd be great to have it in meetings, take it home to read in the bath, on the desk not taking up screen space, etc, etc, etc.
What I'm basically trying to say is that there's a lot of online only material that I'd love to have in dead tree form as well. And I (and my firm) would be quite willing to pay to see it happen.
> constitutional monarchy
;-)
We Brits don't have a constitution, do we?
Oh, 3am. Talk of Politics. Time to go to bed.
Yep, it's CPU intensive. That's why our server now has a load of 30.
However these are just demos. As I've said in other posts, they never were meant for widescale public debate. They were put up so that all the people we'd talked it over with could have a look at what could be done. Lots o' optomisation needs to be done.
Producing Flash files is really quite expensive. There's a lot of bit twiddling to be done. Most computer systems are quite happy shifting bytes around, but SWF files are packed right down to the bit level meaning that you might have tags (flash object definitions) that start on bit 4 or byte 6 and end 47 bits later. Now when you need to make changes you need to shift a whole load of bits across. On most systems that's quite expensive when you have to apply it to the whole file!
There are ways round this. Simon (the code's author) and I were talking about various ways to parse only part of the file and make good guesses about what is contained in the rest (so that you for example just search through and grab the alter the stuff you want) rather than deconstructing and then reconstructing the whole thing.
I guess the key is going to come down to the fact that in 99% of the time you don't actually have to create the thing every single time. More often than not, you can simply recreate it every 15 minutes or so, and just serve that version. I've done similar things with Java tickers in the past that grab data from the web via a perl script and update the files to be served often.
Anyway, if we compare and contrast to making images on the fly, I think you'll find that that's very slow too when scaled up to a couple of hunrded (let alone hundreds of thousand) users.
Later.
Mark.
(Owner/webmaster 2shortplanks.com)
I sure hope you mean the person who posted the link to slashdot, not me or Simon.
Later.
Mark.
(Owner, and webmaster, 2shortplanks.com)
Ah, but we're (when I say we, I mean Simon is working on it and I am watching and hoping my server doesn't fall over again) working on a pure perl one.
;-)
Parsing currently 'works'.
Creating new files has lots of bugs
Later.
Mark.
One of the advantages in getting the Perl Flash stuff working is that you could parse SWF files and spit out any format you wanted (In theory - I stress - In theory.)
Many people I spoke to at YAPC::Europe were interested in doing this. We're striving for an XML version of the Flash file format atm. Soon (not today, not the day after, but soon) we should have something that can create an XML representation of the internal perl data structure that we can grab from a raw SWF file.
Ah, but it was up for public review (for all the people that were at YAPC::Europe and all those people on the list) before it was released to the masses. So we couldn't password protect it.
;-)
If we'd had some warning I could have at least done some simple anti-slashdot effect stuff. But now it's effectivly live I can't mess with the server without making things much worse.
It's like the perl OO model. We expect people to treat us nicely because it's the right thing to do, not because we've got a shotgun handy.
Anyway, thanks for the interest
There's nothing wrong with the file format - It's simple vector graphics very well compacted.
The main problem with most Flash files is that they're created with the graphical editor. The graphical editor has a chip tool that chips away from the vector graphics and ends up creating a large number of polygons. Extra polygons = big files.
Of course with Simon's routines to create flash files from perl then this shouldn't be a problem.
For example, the Flash files I created for the Perl Flash talk at YAPC::Europe on this code (using this code) were under 10K a slide (including font info.)
Later.
Mark.
Server Specs (it's my server)
K6 500
256MB RAM
2Mb (up to 4Mb bursting) pipe.
This isn't the point though. This code isn't even slightly optomised. It's running as CGI on a server that's set up for mod-perl (stupid, but we only just moved these scripts to their new home and haven't altered them yet) Even if they were mod-perl then they wouldn't really be very quick - It's beta code.
However, Flash creation is *hard*. Don't ever expect it to be quick. However, sooner or later we'll write the version that only *alters* the SWF file rather than creating it from scratch.
It's not fair to judge concept code on it's performance.
Oh, powerpuff girls is on Cartoon Network.
Cool. One of the major things that this Flash project needs (apart from a *lot* more time to work on it) is some idea of where to go from here. Comments really, really welcome!
Currently Simon has written the wrap for the libswf that you've mentioned. But he's also written the parsing Tag routines for Flash 3. As you can understand, it really shouldn't be that hard to add a few more tags for Flash 4 and Flash 5 files if you've read and understood the spec.
I'd agree with your comments that there's a lot to Flash that what you can get with Flash 3. Flash 3 is only just Turning compatible for goodness sake! Flash 5 is really interesting and I'd love to get working on some of the more entertaining stuff.
One of the more challenging problems is that the interface we currently have is way too low level - the kind of people that need to use the tools aren't going to be interested in pushing and popping transformation matrices - they just want the text to scroll across the screen. And good on them...
How we do this, and what Flash 4 and Flash 5 tags we use to do this (and templates) is a *big* question.
Will subscribe!
First, Let me tell you who I am. I'm the owner/runner of 2shortplanks.com. This summer I gave the talk on Perl and Flash at YAPC::Europe. I've read and used the code.
;-) Good job we got that unlimmited bandwidth option from mailbox.
;-)
;-)
Secondly, to all those people trying to see the demos. The machine load is currently at 30 - you may have to wait a bit
Thirdly, Simon (the authour of this code) is on holiday, snowboarding - So he can't speak to you lot, but I'll have a go at talking about where we were in the project before he left.
Simon did this code for his final year project based on an idea that I came up with but I was too lame to implement. Up to this point we are at a stage where we can sucessfully break apart a Flash movie with pure perl, and hold it as a data structure of vector graphics objects (well as SWF tags such as Rect, Shape, Text) that can be altered by access via attributes.
This has been a hard struggle for many reasons. Macromedia's open spec (which is linked elsewhere in this discussion) has many bugs in it that Simon had to work around. The other main difficulty is that Flash is a bit based file format, rather than a byte based format - read the spec and you'll see what I mean. (In other words you have 'tags' that take up less than a whole byte so you have to parse very slowly...) Simon had to write File::Binary (on CPAN) before he could start.
Simon has half done the creating perl code bit in pure perl. At this point the code is written, but isn't debugged. I don't think Simon or I am going to even attempt to do this as we've reached the point where it's logical to throw the code away and start from fresh (look mom, the evolutionary design model!) There's lots of changes we'd like to make - processing unparsed data - moving away from Class::Struct - rewriting the File::Binary to work better - template toolkit scripting ability.
One of the really cool things that Simon has done is wrap a binary library to spit out simple flash files. Unfortunatly this module is free as in beer, not as in speech (read: we don't have the C source code.) It has bugs that we can't fix, but this works in most cases - I prepared the slides for my talk at YAPC::Europe with it, as well as the demos that you, well, will be able to see the slashdot effect dies down.
Simon has been doing all this work in his spare time of late - which is very demanding. Sure, if someone was to offer him to work on it fulltime (*hint*) then a lot more could be done. At this time I'd like to thank Simon for all the hard work, often largely thankless, that he's done on this and other projects (YAPC::Europe, Acmemail, and countless help on other modules)
Now for a little news on the server itself. It wasn't ready to be slashdotted. The load is at 30 for goodness sake! Hooray for Linux not falling over! The code wasn't set up to be put under any kind of load - it's just beta code for discussion that has *no* respect for what it's running on. It should be running under mod-perl. It's not. It should not be using file-based temporary files. It is. It's a work in progress, what do you expect?
In closing I'd just like to say it's a shame that we haven't had a chance to get this into some kind of workable form before the whole world decided to have a look and judge it. The site was thrown up in a rush (arn't they always) for discussion on the list. It would have been set up a lot better if we'd known the traffic we were about to get) and we'd love to have shown you a lot more.
Are you slashdot editors willing to let us have another go on the slashdot rollercoaster ride of server death in three months when we've got everything up to scratch? Go on, I dares you
Hope that's been informative.
If you need any info on this then feel free to email me on mark@twoshortplanks.com and I'll be more than willing to talk over any issues. Though I'm in the UK and it's 12:30 in the morning on a Friday night atm, so don't expect a prompt reply!
Later.
Mark.
I totally, disagree.
There's a big difference between putting something up on the web for debate (as Simon did when he wanted the people on the london.pm mailing list to go over this.) And saying that something is up for the hostile viewing of the slashdot mob.
We *know* the html doesn't work for I.E. - Infact Simon was going to have a look at it as soon as he got back from his snowboarding holiday.
Oh - the load on the machine is now at 30. Darn!
Look, this is the key issue here, that the machine has *not* been returned safely at all! Without these wheels, the machine is useless. It can't encrypt. It's missing the cyphering mechanism...
Okay, sounds good.
If I install this with Gnome, what functionality will I get? Will drag and drop work (not that I really use it apart from netscape) ? What do I need to do to install it alongside gnome?
Sorry if these are simple questions, but I've never really used KDE since it first came out and I switched to gnome..
Sounds good - very good in fact.
I still want to be able to use the GUI itself to do root commands though. Some things, like moving files around just make more sense to me in a graphical context...
You misunderstand.
/home/httpd/html
/home/httpd/html
It's not that I have to start my entire desktop enviroment when I want to do something as root (though if - note *if* - I was using windows I would have to,) it's that simply I have to start a seperate filemanger running in root mode just for that task, which is really annoying.
Compare to the simplicity of using a command prompt in a terminal...
[mark@pate mark]$ cp index.html
cp: overwrite `/home/httpd/html/index.html', overriding mode 0444? y
cp: cannot create regular file `/home/httpd/html/index.html': Permission denied
[mark@pate mark]$ su
Password:
[root@pate mark]# cp index.html
cp: overwrite `/home/httpd/html/index.html'? y
[root@pate mark]# exit
exit
[mark@pate mark]$
So much easier. I don't have to navigate to where I was, I just become root, do exactly what I want and get out of root again. I want this from a GUI Filemanager....
It's not that I can't run the file manager as root, it's more that I don't always *want* it to be root.
You mentioned sudo, which I use on the command prompt and allows me to act as root when (and only when) I want. The great thing about unix is that you can run without privilages most of the time while doing your day-to-day stuff, and you don't have to worry (so much) about shooting yourself in the foot, but you still have the power to do things as root without logging out the whole desktop (unlike windows.)
I guess I just want a su (or sudo) like command/mode for gui file managers so I don't have to restart a new gui from the command prompt when I temporarly want root...
..do two things
/etc) I have to load up an entirely new GUI from the command line.
.' command. Now I'm in Linux I find I can't swap backwards and forwards easily, and end up doing everything from the command prompt - but I shouldn't be forced to do this.
1) Run occasional 'commands' as root. I tend know the root password (and therefore should be able to do what I want when I want,) but for obvious reasons I don't want to be running as root all the time. At them momement if I want to use my GUI to perform an action as root (e.g. copy a file into
2) Switch between GUI and command line easier. Back when I used to use Windows I did this with the 'DOS Prompt Here' Power Tool and the 'Start
Can anyone tell me of a GUI File Manager that has these facilities?
To Quote :
What about xload? I know it's just basic, but there you go.
Oh, while I'm at it they say at one point that Samba can be configured only with a ASCII file and then later go onto say you can use LinuxConf. How confusing
Later.
Mark.