Man pages, schman pages. Yes, I'll go so far as to say: schman pages.
Yeah, I'd always wished all man pages had a section heading like DESCRIPTION and SYNOPSIS called TUTORIAL.;)
I also wanted the EXAMPLES section to be mandatory in all man pages, instead of optional. A good page that has an EXAMPLES section is route(8). Many other commands really need it, like tar(1), sed(1) and tr(1). And sorry, but I really dislike info(1); I find it awkward and totally unfamiliar. You might as well use HTML pages and w3m(1) instead of man. And no thanks, I still prefer man for reference. info/w3m/lynx should be used for digressions, NOT a replacement for man. And some of the linux man pages (tar, make) are barely more useful than the command line --help.
Another thing: I would have read man pages more carefully a decade or two ago if all the OS's had this tool called 'manvi' which brings up man pages in VI so it's easy to read/search/save/grep. I drag it with me everywhere now.
Also, linux man pages in particular are often lacking or incomplete. They're getting better, but not up to the quality of, say, SGI man pages, which were policed regularly, and were the word of law on the sgi admin newsgroups. In SGI's case, since the source was closed, they had to have good man pages; RTSL was not an option.
My solution to this sort of thing was to write a simple queue system.
The queue list was the first page anyone saw. From that page, you could 'Enter a new problem request', which let users fill out a small form that has:
A one line description of the problem
An elabortate free form description
A priority chooser for hi/med/low/whatever
An email 'cc list' for the problem
The tasks would all show up in the queue, sorted by priority and status, or you could click on the headings to resort by name, date, etc.
Sysadmins could reprioritize, and add comments, which would be mailed to the user, and anyone else in the cclist.
The important thing:
*** Make the queue publically viewable ***
This way everyone sees what issues are afoot, without having to ask, or walk over to the sysadmin department. For a large company, this is important, as systems can easily become a 'hang out area' where people would bottle neck and commiserate, preventing the admins from getting work done.
By letting everyone see right away how busy things are, they can prioritize on the fly. You can browbeat people who make everything unreasonably 'high priority', and prioritize them down. Go to their managers if they're being persistent, so you can find out if things are really as important as the user makes it sound.
As the report grows longer than humanly manageable, which is inevitable, use it as documentation to the supervisors as proof you need more staff. It can also be used to show how many issues you (or your department) resolve per day.
This way, everything goes through the queue; data is entered by the users (so you don't have to do the paperwork for them, ie. a white board), and people can record problems as soon as they're encountered, complete with email feedback. Everyone at the company can see the queue at all times. Even remote users can file requests.
Prevents unnecessary confrontations, phone calls, and 'hanging out' near the sysadmin offices, letting the admins keep busy, and prevents things from falling through cracks.
When items are resolved, they go into an archive, which can be searchable via a simple regex search form.
I implemented this all back in 1996 with a few perl scripts for the systems department (of which I was not a member; I was a systems programmer), and ascii only files (one file per request) which were key:value files, and were easily grepable and fixable, and were part of the daily backups, so nothing could get lost, and database problems could be fixed easily.
I believe the system is still in use today at that company (though I've long since left), with the same name I gave the tool (the 'ASAP' system).
It worked well.. so well, other departments wanted me to make them one too, which I did for them easily enough. As it turns out, many departments have similar needs for such a system, where they are basically a 'problems in/solutions out' based department.
I taped paper towels over the air intakes of my file server where the air gets sucked into the machine, so I can see the dirt externally. When the towels get dark, I tape new ones on. Asswipe works well too. Just as long as it's thin enough, and doesn't block too much air flow. (Watch the internal heat sensors)
Computers are basically big vacuum cleaners that are on 24 hours. They suck in air, usually have intakes low on the box, and if the box is sitting on the floor, there really is no difference between it and a cheap vacuum.
Some towels and t/p pass air more easily than others; experiment. If it's multi-ply paper, I usually peel it into a single thin sheet, to avoid blocking too much air flow.
With such filters, the inside of the machine stays pretty clean.
Make sure to filter any sneaky alternate routes air is taking through the machine, such as around poorly fitted spare disk blanks, floppy drive holes, holes in the base of the box, or holes in the back of the box from slots that have no blanks. Put the blanks back, or tape off the hole.
Also, getting the damn boxes off of floor level helps a lot, due to the fact most dust bunny migration patterns involve running across the floor towards the low air intakes on the chassis.
You still need to check the machine for dirt, as really tiny dust particles still get through. But the big nasty stuff will be absent.
"[lawyers] would scour the Internet looking for the leaked code"
With all the possible variations of posting text strings, eg. as images, watermarks in images, or in ascii variations like l33t and ascii art, it'll be a lot tougher than just doing google searches for the code.
I'm surprised M$ hasn't figured out some crazy floating license scheme by now, so that such universal keys are unnecessary. A floating scheme would likely make sysadmins choke, but I'm sure MS could come up with some black box you plug into the net that issues floating 'boot licenses' for corporate customers that need it. (shrug)
For those of you who don't know the difference,
EST is 3 hours ahead of PST. Thus DeepSight
identified Slammer at about the same time as the
'rest of the Internet'
Yeah, I read it the same way; 9pm PST == 12am EST the next day.
I can only guess "midnight Saturday" means literally night time Saturday, or "12am Sunday", which would put the events 24 hours apart. I'm not sure which they mean; and neither is 'hours apart', which implies only a few hours.
The term "midnight" is bad enough, but to mix in different timezones just makes it worse.
Convert all the times to one timezone so it's clear; UTC or PST, I don't care which. They made the effort to translate one direct quote from (UTC) to PST, but failed to do that consistently as shown by your article quote.
Since the whole article seems to hinge on this comparison, it comes off pretty weak.
She has some great stuff. Her comics and drawings used to run in R.Crumb's "Weirdo" back in the 80's, and she's since come out with many of her own comics, including "Grit Bath", to name one of to several.
I was just cruising through her site, and came across this really weird rabbit. There's other great stuff there.. check it out. Her stuff is definitely 'from outer space';)
I dig surreal black+white illustrations myself; have some of my own work posted here and here.
Silently truncating code at 80 letters is good? It's a quick security hack; it prevents a buffer overflow, at the cost of losing information and seriously annoying users if they had data that was more than 80 letters long.
Sigh; can't we leave that as an exercise for the reader?;)
Certainly you can test for truncated conditions if need be; just add a strlen(3) test on 'cmd' and 'arg' after the scanf, eg:
scanf("%79s %79s", cmd, arg);// GOOD if ( strlen(cmd) >= 79 || strlen(arg) >= 79 ) { print error.. }
(I like to use the >= as a subtle reminder that input lines longer than 79 trigger this code, even if the string is never actually longer than 79 chars.)
In general I don't actually use plain old scanf much; I prefer to use a combo of fgets(3) and sscanf(3). This is a great way to implement very useful ascii file parsers without having to write a lot of complicated char-by-char parsing code. An fgets/sscanf technique can keep track of line numbers for error msgs (something scanf alone is not so good at), and can detect string truncation, line length issues, properly handle horizontal and vertical white space, braces '{' and '}'), multi and single line comments, word-by-word parsing vs. entire line parsing, etc. To give an idea:
No such document should be without mention of scanf(3) misuse, and gets(3) use at all.
Regarding scanf(3), many people don't realize this is Bad:
char cmd[80], arg[80]; scanf("%s %s", cmd, arg);// BAD
This is Good:
char cmd[80], arg[80]; scanf("%79s %79s", cmd, arg);// GOOD
This prevents a buffer overrun if a word contains 80 or more consecutive non-white characters.
Ditto for sscanf(3) and fscanf(3). Never forget the N+1 when declaring the arrays (eg. char s[80] vs %79s) to leave room for the NULL.
Here's a good command to run on all your.c files to find such problems:
egrep 'scanf(.*%s' *.c
..any lines that match are a potential problem.
And in a document like this, *definitely* point out the whole gets(3) problem; the granddaddy of them all. Never use gets(3), period. Use fgets(3) instead.
The gets(3) interface is inherently insecure; a problem waiting to happen by its mere existence. Any code that uses it is broken.
There are probably some others (someone mentioned strcpy) I'll try to post more if I think of them.
Is the console in that picture sporting a big ole BSOD..?
If so, maybe it was caused by a sysadmin snaring their ankle in those power cords hanging out of the front of the unit.. or maybe that power switch sticking out like a chair prevented a falling object from hitting the ground:/
I hate to be mean, as it's obviously a new product, and from a company that is likely new to machine room ergonomics, but it appears to have a few case design flaws that will probably contribute to downtime as much as the power outage the unit was designed to prevent.
Sure is a cute little thing though.. maybe in a future version they'll recess the cords in a well, and recess the power switch away from where it can accidentally be tripped. I like the case design otherwise.
I found it hard to find their prices online, but looking through their pages, I found this 2001 press release.
Shake Version 2.4 is now available worldwide. Shake 2.4 software is priced at $9,900. Additional render-only network licenses are available at $3,900.
Their prices may have changed since that press release (gotten lower).
Someone indicated a +200 host render farm; not taking into account a volume discount, a 200 host license would be $78,000.00 to run all 200 machines concurrently from the command line.
It ain't cheap; $4K is a lot to pay for a command line tool.
But then again, shake kicks ass speed wise. Much attention was paid to the I/O and optimization, even in the earliest versions. Once, in 1999 or so, I clocked it as faster to do a compositing operation than it took to copy the file with cp(1)..! In this case the source and destination files were on a remote NFS server, and were PAL resolution.
I'm guessing this was due to its multi-threading abilities.. (or maybe it was the crack I was smoking at the time;)) It does seem feasable that shake's multi-threading, involving multiple concurrent seek()/read()/write() operations, could easily make better use of the network bandwidth and I/O than cp(1) ever could. cp() is surely only doing single threaded read()write() operations in series. Maybe someday cp(1) will thread by default to make stuff go/fast/.
I have to wonder about buying a 200 host concurrent license of anything though. I mean, unless you distribute your load to multiple servers (which few companies, even big ones do), if you network doesn't bottleneck with that much concurrent throughput, your NFS server surely will. Anyone care to comment on/that/?
But, yes, all the rotating "3D" effects are hand drawn and hand/computer effected and animated AFAIK.
WRT the rotating stuff behind Max, yes, looking at the footage again, I see it could easily be backlit hand drawn art.. the graphics behind him have no actual 3D rotations, they just appear to be, but could be done with simple combination 2D rotations and pans on artwork with straight lines.
What got me confused, I see, is that on the same tape, right after the movie, I have a copy of the director's demo reel, which has a 'Radio Rentals' commercial featuring Max in front of a graphic that is definitely CG, replete with aliasing, and a slow, smooth, 3D rotation on a cube-like-thing. I guess I transposed that image with the sequences in the film, because there you get a good 30 seconds to look at that background while he delivers the Radio Rentals pitch.
However, I'd bet a virtual nickel that shots like the Network 23 building wireframes during the elevator chase, the wireframe hallways and spy cameras, the bryce lynch code breaking sequence, and car barrier arm sequences are all CG. In fact, not only CG, but/vector CG/, because all the artifacts of vector seem to be in there; letters that don't line up (vector often does that in strange ways), lack of aliasing, bright spots in the corners of letters, letters that wobble slightly, variation in line brightness as things on screen change, etc)
Would like to hear your report, though. It would probably be the only thing I ever heard directly from the people who worked on the original show.
> the first time I saw anything to do with Headroom was in the movie Spaceballs
That's interesting; was there a scene in Spaceballs with Max? I've seen it but don't recall.
What makes this interesting to me is while I was working at Video Image doing the on the screen graphics for the Max Headroom (American version) show, we were also working on the screen graphics for Spaceballs at the same time; both projects were in production at the same time. I'm wondering if it was a matter of convenience they stuck Max into Spaceballs, because the same effects company was working on both projects.
It seems the folks who owned Max never missed a chance to stick that character into all kinds of shows, commercials, etc. He got a lot of 'hip' exposure in those days, so I wouldn't be surprised if they stuck him into Spaceballs for that reason.
> Max Headroom wasn't animated in the sense you think, it was rotoscoped
I'm not so sure about rotoscoped.. I doubt it very much. I would imagine traditional video blue screen techniques were used to matte live action Max in the plastic suit over the CG grid background you see rotating around.
In fact, I'm pretty sure that HAS to be video matting, because of the video editing manipulation of Max (he pauses, then rewinds, stutters, etc) replete with video artifacts.
Rotoscoping is a really tough, costly, time consuming, inexact way to pull mattes, and is a film technique mostly, basically hand tracing each frame under an animation camera, then rephotographing and compositing as a holdout matte in an optical printer, or bipacking in camera. Very tough and expensive. Max Headroom (original) was a large budget, but I don't think it was/that/ large.;) And the American version/series was likely even cheaper (per foot). I worked on the american show's wireframe graphics, but not on the max stuff. And I'm fairly certain no roto was done on any of the Max sequences on the american show, it was surely video bluescreen or similar. But that's speculation.
You can see my other comments on the technical techniques here in the "not the original, though" thread, and one of my other replies higher in that same thread (which I can't seem to link to directly).
>> In the American version, we used a Cubicomp to do all of the 3D graphics >> vector sequences [..] >> I don't think we ever knew what system the original show was done >> on. I assumed it was a custom vector system.. anyone know? > [..] Hint - it wasn't done with computers...
Don't tell me it was backlit opticals.. no way!;)
The scenes I'm wondering about are the *3D* vector graphics scenes like the 'elevator sequence' with the vector wireframe of the Network 23 building, the bryce 'door code decryption' sequence which showed a rotating cube of letters, etc. I just can't see that stuff being backlit; trying to do 3D rotations with 2D animation is just too hard to draw, without it looking fake. I did the american show's graphics for the equivalent scenes, and studied those scenes quite hard; too fluid to be hand drawn.
However, shots like the vector graphics of 'exploding guy' in the original/could/ have been backlit, I suppose; it was a standing 2d image, and had no 3 dimensional aspects to it. There are other similar scenes that didn't have 3D graphics that could have been backlit too. But certainly not all scenes.
And of course Max was always live action, of him in a suit, manipulated with video editing, and other 'tricks' including the rotating graphics matted into the background.
And the parrot we thought was a 2D paint program that was 'drawn' to look like 3D CG. Just a few frames were needed to do the "CG parrot". If anything was amiga, as the 'techtv' article mentions, I'm guessing this was. Possibly also the 'rotating grid' behind max could have been amiga as well. It aliases heavily, which helps sell the 'graphics look' of liveaction Max in the foreground. But if you look at the other sequences, such as the bryce code decryption, aliasing is not much of a component, typical of vector systems. If there is aliasing at all, I'm guessing it's because it's re-scanned off a color monitor (which can alias a little bit; remember those color vector video games aliased a little). This is all speculation regarding the Amigas. We on the american show actually knew little about how the original show's graphics were done. We didn't use any Amigas for the on-screen graphics in the american show, it was all PC hardware. Video Image specialized in presenting on screen graphics in sync with film cameras; we shot the PC graphics on film then transferred to video for on-the-set playbacks. VI modified their video hardware (decks and monitors) to run at 24x.
I should digress; I mentioned in the above 'backlit opticals'. An example of backlit would be a black piece of paper with a hole in the middle. Put that over an animation camera's light table (similar to the florescent light tables one uses to trace artwork or look at slides). The result is a bright dot. Put a colored filter over the dot, and you now have a bright/colored/ dot. Then cover that with an 'opal glass' (which can be real frosted glass, or even a milky white 1/4" piece of acrylic) Look down at this, and you've now got a glowing dot with a fuzzy halo. Very cool look in the 80's; everything had to/glow/;)
Apply the above principle to a more complex graphic, like a grid cut out of the paper, and you've got a *colorful glowing grid*, a very important graphic in those days.
Taking it a step further, you can get a bunch of 2D effects animators to animate some nice graphics on paper, using rapidographs (accurate ink pens that draw very straight, even lines) stencils, templates, splines (drawing splines, which are bendable plastic and metal, not the mathematical kind) which are black drawings on white paper, that can then be photographed onto kodaliths, basically large, clear black and white negatives, which you can then use in place of the above 'black paper' example, to get moving, glowing artwork that looks just like a computer, assuming the 2D animator did a good job on the original artwork.
This technique was common in the 70's and 80's for glowing logos, and on screen graphics, and could often convincingly look like computer graphics.
For instance, the 'grid bugs' scene in TRON used this technique, a short scene that/wasn't/ CG.
Rocky Morton and Annabel Jankel's "Cucumber Productions" demo reel, which we also used for reference/inspiration had a large amount of backlit graphics; really great stuff. I still have a VHS copy of their reel with the commercials and videos I mentioned at the top of this thread.
So I wouldn't be surprised if many of the graphics scenes were done 'traditionally' using the above techniques. But some of the vector scenes were obviously CG.. I'm wondering what equipment was used to do/those/ scenes in the original.
I worked on the American version's series as one of the technical directors doing the on-screen graphics while at Video Image in 1986. I was one of two or three people who did the graphics; me and another guy did the 3D, and there was a mystery guy/gal who did the E.CARTER 'edison cam' overlay graphics.
I was more impressed with the original show ("Max Headroom: The Original Story, Lorimar Homevideo), namely acting, directing, and casting. It seemed to really have that filmic quality I don't think the series achieved. And I thought the screen graphics in the original were better than what we did. For one thing, they used/real/ vector graphics in the original. We had a copy of all the original graphics which we used for reference. Excellent stuff. We also didn't have input from the original directors, Rocky Morton and Annabel Jankel, who I think had a lot to do with the look and feel of the original.
In the American version, we used a Cubicomp to do all of the 3D graphics vector sequences, which was a pixel based system that could do anti-aliased vector rendering. So we basically 'simulated' the look of vector, but didn't fully achieve IMHO. We used 5 1/4" floppies to save our work, and worked on PCs. I don't think we ever knew what system the original show was done on. I assumed it was a custom vector system.. anyone know?
The original also used a great nixie-like fonts that caused me to write a special font program and hand-massaged bitmapped fonts just to simulate that look, which I think we used in the show, I can't recall.
We re-did many of the cg sequences from the original, including the barrier arm, sweeps of the Network 23 building, etc. so that the overall look was consistent with the new sequences we added, like the spinning crypto graphic. (I think I may have encoded my initials into that sequence) Remaking the old graphics was sad, because the original graphics were done so well, and I didn't feel we were doing it justice. I lamented to my boss, but he insisted we needed to keep a consistent look, and I doggedly agreed, but still was disheartened (I was young).
I'm fairly sure the original is easily available for rent.
From what I know of Annabel Jankel and Rocky Morton, they were a british husband/wife team that directed many weird and edgy commercials & music videos. My favorites were the backlit graphics for the Chaz Jankel music video "Questionnaire" (one of the first music videos I think I'd ever seen that used animated graphics, circa 1981), the mixed media in a Joni Mitchell video "Good Friends", which featured cut outs and xerography, and the Donald Fagen video "New Frontier", among others.
Slashdot Mirror
Yeah, I'd always wished all man pages had a section heading like DESCRIPTION and SYNOPSIS called TUTORIAL. ;)
I also wanted the EXAMPLES section to be mandatory in all man pages, instead of optional. A good page that has an EXAMPLES section is route(8). Many other commands really need it, like tar(1), sed(1) and tr(1). And sorry, but I really dislike info(1); I find it awkward and totally unfamiliar. You might as well use HTML pages and w3m(1) instead of man. And no thanks, I still prefer man for reference. info/w3m/lynx should be used for digressions, NOT a replacement for man. And some of the linux man pages (tar, make) are barely more useful than the command line --help.
Another thing: I would have read man pages more carefully a decade or two ago if all the OS's had this tool called 'manvi' which brings up man pages in VI so it's easy to read/search/save/grep. I drag it with me everywhere now.
Also, linux man pages in particular are often lacking or incomplete. They're getting better, but not up to the quality of, say, SGI man pages, which were policed regularly, and were the word of law on the sgi admin newsgroups. In SGI's case, since the source was closed, they had to have good man pages; RTSL was not an option.
The queue list was the first page anyone saw. From that page, you could 'Enter a new problem request', which let users fill out a small form that has:
- A one line description of the problem
- An elabortate free form description
- A priority chooser for hi/med/low/whatever
- An email 'cc list' for the problem
The tasks would all show up in the queue, sorted by priority and status, or you could click on the headings to resort by name, date, etc.Sysadmins could reprioritize, and add comments, which would be mailed to the user, and anyone else in the cclist.
The important thing:
- *** Make the queue publically viewable ***
This way everyone sees what issues are afoot, without having to ask, or walk over to the sysadmin department. For a large company, this is important, as systems can easily become a 'hang out area' where people would bottle neck and commiserate, preventing the admins from getting work done.By letting everyone see right away how busy things are, they can prioritize on the fly. You can browbeat people who make everything unreasonably 'high priority', and prioritize them down. Go to their managers if they're being persistent, so you can find out if things are really as important as the user makes it sound.
As the report grows longer than humanly manageable, which is inevitable, use it as documentation to the supervisors as proof you need more staff. It can also be used to show how many issues you (or your department) resolve per day.
This way, everything goes through the queue; data is entered by the users (so you don't have to do the paperwork for them, ie. a white board), and people can record problems as soon as they're encountered, complete with email feedback. Everyone at the company can see the queue at all times. Even remote users can file requests.
Prevents unnecessary confrontations, phone calls, and 'hanging out' near the sysadmin offices, letting the admins keep busy, and prevents things from falling through cracks.
When items are resolved, they go into an archive, which can be searchable via a simple regex search form.
I implemented this all back in 1996 with a few perl scripts for the systems department (of which I was not a member; I was a systems programmer), and ascii only files (one file per request) which were key:value files, and were easily grepable and fixable, and were part of the daily backups, so nothing could get lost, and database problems could be fixed easily.
I believe the system is still in use today at that company (though I've long since left), with the same name I gave the tool (the 'ASAP' system).
It worked well.. so well, other departments wanted me to make them one too, which I did for them easily enough. As it turns out, many departments have similar needs for such a system, where they are basically a 'problems in/solutions out' based department.
HTH.
Well, I just hope he's not running Windows.
http://www.windowscrash.com/
I taped paper towels over the air intakes of my file server where the air gets sucked into the machine, so I can see the dirt externally. When the towels get dark, I tape new ones on. Asswipe works well too. Just as long as it's thin enough, and doesn't block too much air flow. (Watch the internal heat sensors)
Computers are basically big vacuum cleaners that are on 24 hours. They suck in air, usually have intakes low on the box, and if the box is sitting on the floor, there really is no difference between it and a cheap vacuum.
Some towels and t/p pass air more easily than others; experiment. If it's multi-ply paper, I usually peel it into a single thin sheet, to avoid blocking too much air flow.
With such filters, the inside of the machine stays pretty clean.
Make sure to filter any sneaky alternate routes air is taking through the machine, such as around poorly fitted spare disk blanks, floppy drive holes, holes in the base of the box, or holes in the back of the box from slots that have no blanks. Put the blanks back, or tape off the hole.
Also, getting the damn boxes off of floor level helps a lot, due to the fact most dust bunny migration patterns involve running across the floor towards the low air intakes on the chassis.
You still need to check the machine for dirt, as really tiny dust particles still get through. But the big nasty stuff will be absent.
With all the possible variations of posting text strings, eg. as images, watermarks in images, or in ascii variations like l33t and ascii art, it'll be a lot tougher than just doing google searches for the code.
I'm surprised M$ hasn't figured out some crazy floating license scheme by now, so that such universal keys are unnecessary. A floating scheme would likely make sysadmins choke, but I'm sure MS could come up with some black box you plug into the net that issues floating 'boot licenses' for corporate customers that need it. (shrug)
Yeah, I read it the same way; 9pm PST == 12am EST the next day.
I can only guess "midnight Saturday" means literally night time Saturday, or "12am Sunday", which would put the events 24 hours apart. I'm not sure which they mean; and neither is 'hours apart', which implies only a few hours.
The term "midnight" is bad enough, but to mix in different timezones just makes it worse.
Convert all the times to one timezone so it's clear; UTC or PST, I don't care which. They made the effort to translate one direct quote from (UTC) to PST, but failed to do that consistently as shown by your article quote.
Since the whole article seems to hinge on this comparison, it comes off pretty weak.
She has some great stuff. Her comics and drawings used to run in R.Crumb's "Weirdo" back in the 80's, and she's since come out with many of her own comics, including "Grit Bath", to name one of to several.
I was just cruising through her site, and came across this really weird rabbit. There's other great stuff there.. check it out. Her stuff is definitely 'from outer space' ;)
I dig surreal black+white illustrations myself; have some of my own work posted here and here.
Sigh; can't we leave that as an exercise for the reader? ;)
Certainly you can test for truncated conditions if need be; just add a strlen(3) test on 'cmd' and 'arg' after the scanf, eg:
if ( strlen(cmd) >= 79 || strlen(arg) >= 79 ) { print error.. }
(I like to use the >= as a subtle reminder that input lines longer than 79 trigger this code, even if the string is never actually longer than 79 chars.)
In general I don't actually use plain old scanf much; I prefer to use a combo of fgets(3) and sscanf(3). This is a great way to implement very useful ascii file parsers without having to write a lot of complicated char-by-char parsing code. An fgets/sscanf technique can keep track of line numbers for error msgs (something scanf alone is not so good at), and can detect string truncation, line length issues, properly handle horizontal and vertical white space, braces '{' and '}'), multi and single line comments, word-by-word parsing vs. entire line parsing, etc. To give an idea:
char s[1024], cmd[80];
while ( fgets ( s, sizeof(s)-1, fp ) )
{
- ++line;
// keep track of lines
// ignore empty lines // ignore comments // parse commands..
..parse other commands..
}if ( sscanf(s, "%79s", cmd) == 0 ) continue;
if ( strlen(cmd) >= 79 ) { truncation error }
if ( cmd[0] == '#' ) continue;
if ( strcmp(cmd, "quit") == 0 ) exit(0);
fprintf(stderr, "%s: Line %d: unknown command '%s'\n%s", filename, line, cmd, s);
exit(1);
Regarding scanf(3), many people don't realize this is Bad:
scanf("%s %s", cmd, arg);
This is Good:
scanf("%79s %79s", cmd, arg);
This prevents a buffer overrun if a word contains 80 or more consecutive non-white characters.
Ditto for sscanf(3) and fscanf(3). Never forget the N+1 when declaring the arrays (eg. char s[80] vs %79s) to leave room for the NULL.
Here's a good command to run on all your .c files to find such problems:
And in a document like this, *definitely* point out the whole gets(3) problem; the granddaddy of them all. Never use gets(3), period. Use fgets(3) instead.
The gets(3) interface is inherently insecure; a problem waiting to happen by its mere existence. Any code that uses it is broken.
There are probably some others (someone mentioned strcpy) I'll try to post more if I think of them.
If so, maybe it was caused by a sysadmin snaring their ankle in those power cords hanging out of the front of the unit.. or maybe that power switch sticking out like a chair prevented a falling object from hitting the ground :/
I hate to be mean, as it's obviously a new product, and from a company that is likely new to machine room ergonomics, but it appears to have a few case design flaws that will probably contribute to downtime as much as the power outage the unit was designed to prevent.
Sure is a cute little thing though.. maybe in a future version they'll recess the cords in a well, and recess the power switch away from where it can accidentally be tripped. I like the case design otherwise.
Their prices may have changed since that press release (gotten lower).
Someone indicated a +200 host render farm; not taking into account a volume discount, a 200 host license would be $78,000.00 to run all 200 machines concurrently from the command line.
It ain't cheap; $4K is a lot to pay for a command line tool.
But then again, shake kicks ass speed wise. Much attention was paid to the I/O and optimization, even in the earliest versions. Once, in 1999 or so, I clocked it as faster to do a compositing operation than it took to copy the file with cp(1)..! In this case the source and destination files were on a remote NFS server, and were PAL resolution.
I'm guessing this was due to its multi-threading abilities.. (or maybe it was the crack I was smoking at the time ;)) It does seem feasable that shake's multi-threading, involving multiple concurrent seek()/read()/write() operations, could easily make better use of the network bandwidth and I/O than cp(1) ever could. cp() is surely only doing single threaded read()write() operations in series. Maybe someday cp(1) will thread by default to make stuff go /fast/.
I have to wonder about buying a 200 host concurrent license of anything though. I mean, unless you distribute your load to multiple servers (which few companies, even big ones do), if you network doesn't bottleneck with that much concurrent throughput, your NFS server surely will. Anyone care to comment on /that/?
WRT the rotating stuff behind Max, yes, looking at the footage again, I see it could easily be backlit hand drawn art.. the graphics behind him have no actual 3D rotations, they just appear to be, but could be done with simple combination 2D rotations and pans on artwork with straight lines.
What got me confused, I see, is that on the same tape, right after the movie, I have a copy of the director's demo reel, which has a 'Radio Rentals' commercial featuring Max in front of a graphic that is definitely CG, replete with aliasing, and a slow, smooth, 3D rotation on a cube-like-thing. I guess I transposed that image with the sequences in the film, because there you get a good 30 seconds to look at that background while he delivers the Radio Rentals pitch.
However, I'd bet a virtual nickel that shots like the Network 23 building wireframes during the elevator chase, the wireframe hallways and spy cameras, the bryce lynch code breaking sequence, and car barrier arm sequences are all CG. In fact, not only CG, but /vector CG/, because all the artifacts of vector seem to be in there; letters that don't line up (vector often does that in strange ways), lack of aliasing, bright spots in the corners of letters, letters that wobble slightly, variation in line brightness as things on screen change, etc)
Would like to hear your report, though. It would probably be the only thing I ever heard directly from the people who worked on the original show.
That's interesting; was there a scene in Spaceballs with Max? I've seen it but don't recall.
What makes this interesting to me is while I was working at Video Image doing the on the screen graphics for the Max Headroom (American version) show, we were also working on the screen graphics for Spaceballs at the same time; both projects were in production at the same time. I'm wondering if it was a matter of convenience they stuck Max into Spaceballs, because the same effects company was working on both projects.
It seems the folks who owned Max never missed a chance to stick that character into all kinds of shows, commercials, etc. He got a lot of 'hip' exposure in those days, so I wouldn't be surprised if they stuck him into Spaceballs for that reason.
I'm not so sure about rotoscoped.. I doubt it very much. I would imagine traditional video blue screen techniques were used to matte live action Max in the plastic suit over the CG grid background you see rotating around.
In fact, I'm pretty sure that HAS to be video matting, because of the video editing manipulation of Max (he pauses, then rewinds, stutters, etc) replete with video artifacts.
Rotoscoping is a really tough, costly, time consuming, inexact way to pull mattes, and is a film technique mostly, basically hand tracing each frame under an animation camera, then rephotographing and compositing as a holdout matte in an optical printer, or bipacking in camera. Very tough and expensive. Max Headroom (original) was a large budget, but I don't think it was /that/ large. ;) And the American version/series was likely even cheaper (per foot). I worked on the american show's wireframe graphics, but not on the max stuff. And I'm fairly certain no roto was done on any of the Max sequences on the american show, it was surely video bluescreen or similar. But that's speculation.
You can see my other comments on the technical techniques here in the "not the original, though" thread, and one of my other replies higher in that same thread (which I can't seem to link to directly).
>> In the American version, we used a Cubicomp to do all of the 3D graphics
;)
/could/ have been backlit, I suppose; it was a standing 2d image, and had no 3 dimensional aspects to it. There are other similar scenes that didn't have 3D graphics that could have been backlit too. But certainly not all scenes.
/colored/ dot. Then cover that with an 'opal glass' (which can be real frosted glass, or even a milky white 1/4" piece of acrylic) Look down at this, and you've now got a glowing dot with a fuzzy halo. Very cool look in the 80's; everything had to /glow/ ;)
/wasn't/ CG.
/those/ scenes in the original.
>> vector sequences [..]
>> I don't think we ever knew what system the original show was done
>> on. I assumed it was a custom vector system.. anyone know?
> [..] Hint - it wasn't done with computers...
Don't tell me it was backlit opticals.. no way!
The scenes I'm wondering about are the *3D* vector graphics scenes like the 'elevator sequence' with the vector wireframe of the Network 23 building, the bryce 'door code decryption' sequence which showed a rotating cube of letters, etc. I just can't see that stuff being backlit; trying to do 3D rotations with 2D animation is just too hard to draw, without it looking fake. I did the american show's graphics for the equivalent scenes, and studied those scenes quite hard; too fluid to be hand drawn.
However, shots like the vector graphics of 'exploding guy' in the original
And of course Max was always live action, of him in a suit, manipulated with video editing, and other 'tricks' including the rotating graphics matted into the background.
And the parrot we thought was a 2D paint program that was 'drawn' to look like 3D CG. Just a few frames were needed to do the "CG parrot". If anything was amiga, as the 'techtv' article mentions, I'm guessing this was. Possibly also the 'rotating grid' behind max could have been amiga as well. It aliases heavily, which helps sell the 'graphics look' of liveaction Max in the foreground. But if you look at the other sequences, such as the bryce code decryption, aliasing is not much of a component, typical of vector systems. If there is aliasing at all, I'm guessing it's because it's re-scanned off a color monitor (which can alias a little bit; remember those color vector video games aliased a little). This is all speculation regarding the Amigas. We on the american show actually knew little about how the original show's graphics were done. We didn't use any Amigas for the on-screen graphics in the american show, it was all PC hardware. Video Image specialized in presenting on screen graphics in sync with film cameras; we shot the PC graphics on film then transferred to video for on-the-set playbacks. VI modified their video hardware (decks and monitors) to run at 24x.
I should digress; I mentioned in the above 'backlit opticals'. An example of backlit would be a black piece of paper with a hole in the middle. Put that over an animation camera's light table (similar to the florescent light tables one uses to trace artwork or look at slides). The result is a bright dot. Put a colored filter over the dot, and you now have a bright
Apply the above principle to a more complex graphic, like a grid cut out of the paper, and you've got a *colorful glowing grid*, a very important graphic in those days.
Taking it a step further, you can get a bunch of 2D effects animators to animate some nice graphics on paper, using rapidographs (accurate ink pens that draw very straight, even lines) stencils, templates, splines (drawing splines, which are bendable plastic and metal, not the mathematical kind) which are black drawings on white paper, that can then be photographed onto kodaliths, basically large, clear black and white negatives, which you can then use in place of the above 'black paper' example, to get moving, glowing artwork that looks just like a computer, assuming the 2D animator did a good job on the original artwork.
This technique was common in the 70's and 80's for glowing logos, and on screen graphics, and could often convincingly look like computer graphics.
For instance, the 'grid bugs' scene in TRON used this technique, a short scene that
Rocky Morton and Annabel Jankel's "Cucumber Productions" demo reel, which we also used for reference/inspiration had a large amount of backlit graphics; really great stuff. I still have a VHS copy of their reel with the commercials and videos I mentioned at the top of this thread.
So I wouldn't be surprised if many of the graphics scenes were done 'traditionally' using the above techniques. But some of the vector scenes were obviously CG.. I'm wondering what equipment was used to do
I worked on the American version's series as one of the technical directors
/real/ vector graphics in the original. We had a copy of all
doing the on-screen graphics while at Video Image in 1986. I was one of
two or three people who did the graphics; me and another guy did the 3D,
and there was a mystery guy/gal who did the E.CARTER 'edison cam' overlay graphics.
I was more impressed with the original show ("Max Headroom: The Original Story,
Lorimar Homevideo), namely acting, directing, and casting. It seemed to really
have that filmic quality I don't think the series achieved. And I thought
the screen graphics in the original were better than what we did. For one
thing, they used
the original graphics which we used for reference. Excellent stuff. We also didn't
have input from the original directors, Rocky Morton and Annabel Jankel, who
I think had a lot to do with the look and feel of the original.
In the American version, we used a Cubicomp to do all of the 3D graphics
vector sequences, which was a pixel based system that could do anti-aliased
vector rendering. So we basically 'simulated' the look of vector, but didn't
fully achieve IMHO. We used 5 1/4" floppies to save our work, and worked
on PCs. I don't think we ever knew what system the original show was done
on. I assumed it was a custom vector system.. anyone know?
The original also used a great nixie-like fonts that caused me to write
a special font program and hand-massaged bitmapped fonts just to simulate
that look, which I think we used in the show, I can't recall.
We re-did many of the cg sequences from the original, including the
barrier arm, sweeps of the Network 23 building, etc. so that the overall look
was consistent with the new sequences we added, like the spinning crypto
graphic. (I think I may have encoded my initials into that sequence)
Remaking the old graphics was sad, because the original graphics were
done so well, and I didn't feel we were doing it justice. I lamented
to my boss, but he insisted we needed to keep a consistent look,
and I doggedly agreed, but still was disheartened (I was young).
I'm fairly sure the original is easily available for rent.
From what I know of Annabel Jankel and Rocky Morton, they were a british
husband/wife team that directed many weird and edgy commercials & music
videos. My favorites were the backlit graphics for the Chaz Jankel
music video "Questionnaire" (one of the first music videos I think I'd
ever seen that used animated graphics, circa 1981), the mixed media in a
Joni Mitchell video "Good Friends", which featured cut outs and xerography,
and the Donald Fagen video "New Frontier", among others.