As we know, the signal is not confined to a single room unless you've got some of that silver wallpaper that was mentioned a while back.
Otherwise it's quite feasible to get a signal through two or three walls or a floor.
A large percentage of people still do not bother to / are able to configure WEP/WPA security on their access points. These people would be opening up the university network to unauthorized access, making their own internal server infrastructure (including valuable data like research material) for anyone close enough to an access point to see.
Yes, it's a rather draconian measure, but what other choice is there? They can't insist on setting up all student access points themselves (and then changing the password) can they?
Though the sentiment is clear: developers should not test or QA certify their own code. There is the obvious problem of the moral standards (or lack thereof) of the engineer ("Aw shit it broke, ah f*ck it. It's 2am. Label it. I'm off home."), there's also the psychological effect of engineers subconsciencly shying away from testing areas they know are not sufficiently protected with validation and exception handling, or where the specification (if there/was/ one) was fuzzy.
In my experience, if you want to nail your shorts to the mast and say "we believe in software product quality", make it the primary responsibility of a group of people with a named leader. Have that leader own the QA process (and DEFINE that process so it is refinable and repeatable) and BLAME that team as a whole when the software blows up in production. This is the only metric that really matters to that team. Link pay to that metric.
Yes, that's harsh. Yes, the team will be reviled and hated. You - and they - will have to deal with that.
But over time, the QA team will develop a bulletproof QA process. Google for IBM's "Black Team" for an example of a QA team that worked.
Nash: I don't exactly know what I am required to say in order for you to have intercourse with me. But could we assume that I said all that? I mean essentially we are talking about fluid exchange right? So could we go just straight to the sex?
Dolby Digital film prints do this. Certain film releases with a DD optical digital track contain firmware upgrades which are read into the decoder along with the soundtrack. The player upgrades its firmware EEPROM and the new software is effective the next time the decoder is turned on.
Never heard any occurences of this going wrong, I guess everything is checksummed up the wazoo. Always struck me as a very elegant solution to the problem.
Well, if ever there was a thread I could advertise in, this has to be it!:-)
I write a lot of music in my spare time, from orchestral scores to lullabyes, themes and easy jazz. I guess it's light, it's easy to listen to, good for backgrounds and just chilling out. Anyway, have a listen. Suggest 'This Time For Real', then 'If You Only Knew', then take it from there:-)
LOL:-) You could in theory splice in a single frame, but you'd end up with two splices (head and tail splice) in quick succession, so the image would have an obvious jump in it. Maybe the best way would be to wait for a flash frame (completely clear/white image) and paste the subliminal image into that - you wouldn't have to splice and the thickness should still be thin enough to go through the gate:)
The theatre is rather old - there are trailers in the stockroom from 1980;-) The projectors aren't exactly 'new' either.
Agree with comment about being careless and causing scratches - very true. I can do a complete thread in about 2.5 minutes but not if the film's still on the rewinding machine;-)
There is no room in the gallery for platters, unfortunately; otherwise we'd have 'em. The one-over-the-other reel mounting thing is the biggest pain in the bottom... especially since some of the guys like to reel on more film than the spools will actually hold.
It is extremely rare since modern film stock, although non-flam, does melt. It is possible to get a film-tension device that you put in the film path somewhere, which will automatically close the lamp house isolating shield if the tension goes slack. These are usually retro-fits however.
I've had situations where a splice has come undone on the projector; in which case it's a case of grabbing the splice block from the editing bench, legging it over to the project, chopping, matching and resplicing with a frame-on-frame splice (the strongest kind) and getting the film back up and running.
A 35mm print will offer much greater resolution than 1080 lines, although it is still projected at 24fps. I believe the figure is something of the order of approximately 4000x3000 grains per frame; although that depends on the print stock.
You have to look after prints very carefully if they are to remain pristine. Guidelines from Eastman/Kodak and Agfa call for positive pressure in the projection gallery to minimize dust, as well as gloves etc. Prints have been arriving on a new film stock which, although sturdier than original stock, develops a high static charge (I get zapped 3-ish times a night) and attracts dust like you _would_not_believe_. The new stock cannot be spliced with film glue because it does not 'take' - you must use tape or splicing film. This means the reel changes (every 20-odd minutes as a rule) are less smooth; you'll see a jump as the splice goes through the gate, and the dolby digital reader might switch out of digital and you'll get a second or so of analogue fall-back. The DTS reader is much better, and will free-wheel for a few seconds before falling back to analogue (it's only reading timecode from the print, not the whole digital frame, like SRD).
If the cinema is using a platter system, the reels of film lie flat, and can be projected a second time without rewinding. Rewinding places a high stress on the film. Starting a rewind must be done delicately because the 'pull' from the take-up reel can stretch the film and produce green burn marks.
If, like us, you have a horizontal reel system, apart from the strain on the projectionist (having to lift huge reels of 2.5 miles of film to eye level;-), then the films have to be rewound. Given the extreme turnaround times (often 10 minutes between films) and the average rewinding time (8-12 minutes) you can see that there is a lot of pressure to get the show started. Often we're showing you the advert reel while the feature is still rewinding; then doing a quick threading between adverts and film. Multiply this by the number of theaters and you quickly have organised mayhem. It's easy to make a threading error, which can lead to scratches on the print, burn marks, the print can jump out of the film path, or become skew in the gate (nice row of dots down the print).
It's not uncommon to have three or for un-rewound films around the gallery when the system descends into chaos:-)
If you have a new 35mm print, good sound and good masking, the quality can be absolutely superb. Of course, digital projection will remove a lot of the variables involved in projection, so you should at least get a concistent experience.
Is that the case? What language is all the menu stuff written in? Some Flash-like language? Are the individual tracks (files) on a DVD region coded separately?
Would it be possible, for instance, to write some part of the menu system in such a way that it tries to open a part of the disk (or a VOB file or whatever) that is coded for a different region -- and then check if the open succeeded?
It seems that players which can have their region codes set manually should be okay in the face of this new check.
Region-Free players will not reject any tracks on the basis of region alone - I guess the software on the individual disks will therefore flash up the message and stubbornly refuse to play in this case...
But I know that the early players that could be hacked were not Region-Free or 'multi-region', they were single-region players that could have their region changed. My Philips player (can't remember the model number) does this - all I have to do is enter an easy-to-remember 30-odd digit code on the remote;-)
After applying the change, the player simply thinks that it's in a different region. These new disks should still play perfectly well.
I think a few software players operate the same way.
Of course, any new software players that try to actively circumvent this probably won't receive a CSS decryption key (don't really know how that works anyway)...
As an aditional point, companies that produce Unix operating systems often receive internal pricing (i.e. supposedly cheaper) on their O/S licenses, so you'll find that Unix is still greatly used in these shops.
I interned for a year at HP, and although we were far removed from the O/S group, the server platform of choice was, of course, HP/UX.
Persevere with your search for a Unix position - big shops are still a great way to learn Unix - and the skills and knowledge you'll acquire can easily be applied to Linux (with a few caveats).
You're right, but although I don't expect professionals to leave their code uncommented and undocumented, it still *is* that way in a lot of cases.
Back where I worked last, the support organisation wouldn't accept code for maintenance until it had gone through at least one code review to check maintainability. If it wasn't maintainable, it went back to the developers until it *was*. There was an incentive for the devlopers to do it right first time as they didn't get grief from their managers for making the handover late and being over budget.
I should probably add that as finalists on the Distributed Computing Course we were tasked with building a load-balancing system which would take a process and run it accross the system, returning results when the process ended. I think I solved it by having a daemon run on each box which would serve the box load and accept incoming processes. A master daemon would take new processes, find the lowest-loaded box and send them off. The process itself was linked against a library of functions, one of which organised for the process to be moved to the least-loaded box. The problem was the process had to be network-aware. Moving arbitrary user-space processes requires various kernel structures be unhooked and moved too (not within the project scope). It worked pretty well; it was nice (in a geeky way) to have the lab to onesself occasionaly and to hear the process migrating around the room (disk activity gave it away). When the process ended, the distribution daemon on whatever box it was one would send its output back to the master. I'm a little hazy, there may have been more daemons involved and I don't want to dig out my coursework (I promised the psychologist never to look at it again:)
Are you perchance at Stafford? This seems almost exactly what we had to do for OS years ago when I was a second year. Basically (without giving away what you're supposed to do) we had a version 1 linux lab and had to modify the scheduler so as to bias a certain profile of process. We were using version 1 because the rt scheduler was manageable then, I think in V2 it kind of started taking steroids and acquired all the SMP functions. Is Phil Cornes still at Staffs?
The core files you're seeing save the segment of memory in which the program was running. They can be used in conjunction with a debugger and image with debugging information to recreate the state of the application when it crashed, enabling the programmer to glean information about which instruction caused the crash.
Dumping the kernel on a crash is not new but it is useful, in much the same way.
Under HP-UX, as far as I remember, when the kernel crashes it is dumped into the swap device starting backwards from the end of swap. One of the first actions of the boot sequence (and boy can that take a long time) is to check whether there is a kernel image written in swap. If so, it's copied out and can be sent back to the kernel team for investigation.
Of course, if your boot sequence doesn't copy out the kernel, you've got a finite time to get it out yourself before it's overwritten by the ever-advancing swap data.
Slashdot Mirror
As we know, the signal is not confined to a single room unless you've got some of that silver wallpaper that was mentioned a while back.
Otherwise it's quite feasible to get a signal through two or three walls or a floor.
A large percentage of people still do not bother to / are able to configure WEP/WPA security on their access points. These people would be opening up the university network to unauthorized access, making their own internal server infrastructure (including valuable data like research material) for anyone close enough to an access point to see.
Yes, it's a rather draconian measure, but what other choice is there? They can't insist on setting up all student access points themselves (and then changing the password) can they?
I think you forgot a 'not'.
/was/ one) was fuzzy.
Though the sentiment is clear: developers should not test or QA certify their own code. There is the obvious problem of the moral standards (or lack thereof) of the engineer ("Aw shit it broke, ah f*ck it. It's 2am. Label it. I'm off home."), there's also the psychological effect of engineers subconsciencly shying away from testing areas they know are not sufficiently protected with validation and exception handling, or where the specification (if there
In my experience, if you want to nail your shorts to the mast and say "we believe in software product quality", make it the primary responsibility of a group of people with a named leader. Have that leader own the QA process (and DEFINE that process so it is refinable and repeatable) and BLAME that team as a whole when the software blows up in production. This is the only metric that really matters to that team. Link pay to that metric.
Yes, that's harsh. Yes, the team will be reviled and hated. You - and they - will have to deal with that.
But over time, the QA team will develop a bulletproof QA process. Google for IBM's "Black Team" for an example of a QA team that worked.
-JH
Nash: I don't exactly know what I am required to say in order for you to have intercourse with me. But could we assume that I said all that? I mean essentially we are talking about fluid exchange right? So could we go just straight to the sex?
(Courtesy IMDB)
Dolby Digital film prints do this. Certain film releases with a DD optical digital track contain firmware upgrades which are read into the decoder along with the soundtrack. The player upgrades its firmware EEPROM and the new software is effective the next time the decoder is turned on.
Never heard any occurences of this going wrong, I guess everything is checksummed up the wazoo. Always struck me as a very elegant solution to the problem.
Well, if ever there was a thread I could advertise in, this has to be it! :-)
:-)
:-)
I write a lot of music in my spare time, from orchestral scores to lullabyes, themes and easy jazz. I guess it's light, it's easy to listen to, good for backgrounds and just chilling out. Anyway, have a listen. Suggest 'This Time For Real', then 'If You Only Knew', then take it from there
http://www.hawksley.net/mp3
If you're modding and you like it - mod me up
Enjoy all,
John
LOL :-) You could in theory splice in a single frame, but you'd end up with two splices (head and tail splice) in quick succession, so the image would have an obvious jump in it. Maybe the best way would be to wait for a flash frame (completely clear/white image) and paste the subliminal image into that - you wouldn't have to splice and the thickness should still be thin enough to go through the gate :)
The theatre is rather old - there are trailers in the stockroom from 1980 ;-) The projectors aren't exactly 'new' either.
;-)
Agree with comment about being careless and causing scratches - very true. I can do a complete thread in about 2.5 minutes but not if the film's still on the rewinding machine
There is no room in the gallery for platters, unfortunately; otherwise we'd have 'em. The one-over-the-other reel mounting thing is the biggest pain in the bottom... especially since some of the guys like to reel on more film than the spools will actually hold.
It is extremely rare since modern film stock, although non-flam, does melt. It is possible to get a film-tension device that you put in the film path somewhere, which will automatically close the lamp house isolating shield if the tension goes slack. These are usually retro-fits however.
I've had situations where a splice has come undone on the projector; in which case it's a case of grabbing the splice block from the editing bench, legging it over to the project, chopping, matching and resplicing with a frame-on-frame splice (the strongest kind) and getting the film back up and running.
I am a projectionist.
;-), then the films have to be rewound. Given the extreme turnaround times (often 10 minutes between films) and the average rewinding time (8-12 minutes) you can see that there is a lot of pressure to get the show started. Often we're showing you the advert reel while the feature is still rewinding; then doing a quick threading between adverts and film. Multiply this by the number of theaters and you quickly have organised mayhem. It's easy to make a threading error, which can lead to scratches on the print, burn marks, the print can jump out of the film path, or become skew in the gate (nice row of dots down the print).
:-)
A 35mm print will offer much greater resolution than 1080 lines, although it is still projected at 24fps. I believe the figure is something of the order of approximately 4000x3000 grains per frame; although that depends on the print stock.
You have to look after prints very carefully if they are to remain pristine. Guidelines from Eastman/Kodak and Agfa call for positive pressure in the projection gallery to minimize dust, as well as gloves etc. Prints have been arriving on a new film stock which, although sturdier than original stock, develops a high static charge (I get zapped 3-ish times a night) and attracts dust like you _would_not_believe_. The new stock cannot be spliced with film glue because it does not 'take' - you must use tape or splicing film. This means the reel changes (every 20-odd minutes as a rule) are less smooth; you'll see a jump as the splice goes through the gate, and the dolby digital reader might switch out of digital and you'll get a second or so of analogue fall-back. The DTS reader is much better, and will free-wheel for a few seconds before falling back to analogue (it's only reading timecode from the print, not the whole digital frame, like SRD).
If the cinema is using a platter system, the reels of film lie flat, and can be projected a second time without rewinding. Rewinding places a high stress on the film. Starting a rewind must be done delicately because the 'pull' from the take-up reel can stretch the film and produce green burn marks.
If, like us, you have a horizontal reel system, apart from the strain on the projectionist (having to lift huge reels of 2.5 miles of film to eye level
It's not uncommon to have three or for un-rewound films around the gallery when the system descends into chaos
If you have a new 35mm print, good sound and good masking, the quality can be absolutely superb. Of course, digital projection will remove a lot of the variables involved in projection, so you should at least get a concistent experience.
Is that the case? What language is all the menu stuff written in? Some Flash-like language? Are the individual tracks (files) on a DVD region coded separately?
Would it be possible, for instance, to write some part of the menu system in such a way that it tries to open a part of the disk (or a VOB file or whatever) that is coded for a different region -- and then check if the open succeeded?
Just wondering...
-J
It seems that players which can have their region codes set manually should be okay in the face of this new check.
;-)
Region-Free players will not reject any tracks on the basis of region alone - I guess the software on the individual disks will therefore flash up the message and stubbornly refuse to play in this case...
But I know that the early players that could be hacked were not Region-Free or 'multi-region', they were single-region players that could have their region changed. My Philips player (can't remember the model number) does this - all I have to do is enter an easy-to-remember 30-odd digit code on the remote
After applying the change, the player simply thinks that it's in a different region. These new disks should still play perfectly well.
I think a few software players operate the same way.
Of course, any new software players that try to actively circumvent this probably won't receive a CSS decryption key (don't really know how that works anyway)...
Cheers,
-J.
As an aditional point, companies that produce Unix operating systems often receive internal pricing (i.e. supposedly cheaper) on their O/S licenses, so you'll find that Unix is still greatly used in these shops.
I interned for a year at HP, and although we were far removed from the O/S group, the server platform of choice was, of course, HP/UX.
Persevere with your search for a Unix position - big shops are still a great way to learn Unix - and the skills and knowledge you'll acquire can easily be applied to Linux (with a few caveats).
- A good place to start might be http://jobs.hp.com/.
- Agilent is a spin-off of some HP divisions, they also take interns: http://jobs.agilent.com.
- Finally, HP spun off it's Mechanical Design Division into CoCreate Software, whose jobs page is here.
Good luck!You're right, but although I don't expect professionals to leave their code uncommented and undocumented, it still *is* that way in a lot of cases.
Back where I worked last, the support organisation wouldn't accept code for maintenance until it had gone through at least one code review to check maintainability. If it wasn't maintainable, it went back to the developers until it *was*. There was an incentive for the devlopers to do it right first time as they didn't get grief from their managers for making the handover late and being over budget.
I should probably add that as finalists on the Distributed Computing Course we were tasked with building a load-balancing system which would take a process and run it accross the system, returning results when the process ended. I think I solved it by having a daemon run on each box which would serve the box load and accept incoming processes. A master daemon would take new processes, find the lowest-loaded box and send them off. The process itself was linked against a library of functions, one of which organised for the process to be moved to the least-loaded box. The problem was the process had to be network-aware. Moving arbitrary user-space processes requires various kernel structures be unhooked and moved too (not within the project scope). It worked pretty well; it was nice (in a geeky way) to have the lab to onesself occasionaly and to hear the process migrating around the room (disk activity gave it away). When the process ended, the distribution daemon on whatever box it was one would send its output back to the master. I'm a little hazy, there may have been more daemons involved and I don't want to dig out my coursework (I promised the psychologist never to look at it again :)
Are you perchance at Stafford? This seems almost exactly what we had to do for OS years ago when I was a second year. Basically (without giving away what you're supposed to do) we had a version 1 linux lab and had to modify the scheduler so as to bias a certain profile of process. We were using version 1 because the rt scheduler was manageable then, I think in V2 it kind of started taking steroids and acquired all the SMP functions. Is Phil Cornes still at Staffs?
The core files you're seeing save the segment of memory in which the program was running. They can be used in conjunction with a debugger and image with debugging information to recreate the state of the application when it crashed, enabling the programmer to glean information about which instruction caused the crash.
Dumping the kernel on a crash is not new but it is useful, in much the same way.
Under HP-UX, as far as I remember, when the kernel crashes it is dumped into the swap device starting backwards from the end of swap. One of the first actions of the boot sequence (and boy can that take a long time) is to check whether there is a kernel image written in swap. If so, it's copied out and can be sent back to the kernel team for investigation.
Of course, if your boot sequence doesn't copy out the kernel, you've got a finite time to get it out yourself before it's overwritten by the ever-advancing swap data.
-John