That's what looking over sholders is for. With enough determination anything is defeatable.
The comment on wondering how many were tagged reminded me of the RFID tagsd we use on cattle. We know how much each steer in our feed lot eats and when they do it.
Heh. The Salt Lake and Provo LUGs should get together and start a deathwatch. Basically, people would take turns outside their corporate offices, manning a sign that says, "I bid $5." Victory comes when Darl comes out and accepts the offer.
You got to wonder what the liabilities SCO would have at that point. I wouldn't touch them if I was paid to buy them.
No. Last I looked you could get FLASH based CompactFlash II format cards all the way up to 1G byte. They were also mentioning plans for larger ones. Nice thing about compact flash is you just strap the right pin and they behave like an IDE disk. All it takes is a passive converter to connect them to and IDE bus.
The most tech I've done in years is to run worms on old green and amber screen terminals and set them in the windows next to the door. Looks much better if you have one with a detachable keyboard. They usually are partially hidden by a netting with leaves and other forest floor debris in it. It makes an interesting effect to have the worms crawling about under the debris. I use black construction paper to hide the bezels of the terminals.
Open Source software is "World Citezen #1". I gives and takes freely from all irreguardless of race, creed, ethnic origin, and a host of other commonly used descrimination divisors.
Ever heard of Allison Transmittion? They make automatic transmittions for use in semis and other heavy duty uses. Infact they are considered one of the best transmittion makers out there. Many fleet operators won't buy a truck unless it has an Allison transmittion.
Send your film to a proper lab and you won't get the scratches and finger prints. Also have them put the negatives in proper archival quality sleeves. If you see finger prints on the negatives when they come to you complain loudly as that is damage. When printing it is nearly impossible to remove a fingerprint with out washing the negative. Whenever you get a negative wet the emulsion surface softens and is much more easily dammaged. Blow off dust with a clean air supply, never use your finger, and only use a very soft brush as a last resort. Also control dust in you film handling area. I'd strongly reccomend getting something like a HEPE filter from Target or Walmart and run it all the time in your film handling area. When handling the negatives, only touch the edges and never touch the surfaces. Clenliness is also a must. When I was working in the studio I would wash my hands a few times over the day to remove finger oils. We didn't use goves because of dust from the fibers. We'd also dust the counter a few times using a dust magnet type cloth. Usually between each set of negatives we worked with. The sequence was clean the light box area, find and dust off the negative storage box, then clean the hands and finally bring out the negatives and/or slides. Following those rules we only had to touch up one negative in two years. Either the film came scratched or the photo lab scratched it, we don't know which but when I unpacked it at the light box it was already scratched. We never had problems with dust specs.
Going full SLR digital is also out of my price range for now. I'd really like to. I want to go back into profesional photography. Being able to capture perfect color ballance is a must as far as I'm concerned. With a digital camera that can capture color ballance off a white card this becomes easy. Color ballance was one area I found frustrating using regular film. The problem is it really requires using different films for differnt light sources and adjusting the color setting when making prints. Needing the different films causes one to need multiple film backs or camera bodies which raises costs. Sure you can use filters to reballance things but that is only a half measure and complicates the printing process. Also usually you can't control what the guy in the photo lab sets the color wheels on the enlarger to unless you go to a custom lab and that costs $$$. It is about $8,000-10,000 for the EOS camera setup I want to start out with. Going film only drops the price by a $1,000.
Actually shutter sync isn't the problem. Just stop draining the CCD cells, open shutter, close shutter, then read off. This assumes you are putting a CCD chip behind a regular camera body in place of the film.
I do remember seeing a writeup on a film canister shaped device that went in place of the regular 35mm film cartridge. It had a toung off of it that housed the CCD chip and positioned it in the regular film plane area. Main issue I see with it is the film plane area varies from camera to camera.
I've spent the past several years writing networking applications, and this is my philosophy: Anytime there is *any* chance of a packet being lost or arriving out of order, you must write code that assumes every packet has a high probability of being lost. I've seen people make assumptions that since it's running on an ethernet lan they will never lose UDP packets, then their app becomes very unstable. Even when sending UDP packets to localhost they can be lost. When designing UDP software it shouldn't be a matter of how often packets are lost, but how well your code deals with lost packets.
This is vary true. You must code UDP applications to deal with packet loss, and yes packets can be dropped when going from localhost to localhost. Overfill the network transmit or receive capacities or use up all buffer space, packets will be dropped. There is no way around that without changing the UDP protocal. Afterall if your application sends out 10,000 UDP packets per second and the network can only handle 2,000 per second, the other 8,000 are to be dropped. For TCP connection loss is all you have to code for.
Hmmm, I'd love to see an "Enforce Godwin's Law" in my Comment Options on Slashdot. Just check the little box and everything is cut off at the first post mentioning Nazis or Hitler.
"History doesn't repeat itself, but it does rhyme."
Young grasshopper, you obviously know little of history. This flag will only cause "First Hitler" and "First Nazis" posts and thus make any flag like that useless. Wave the right flag, the bull will charge. Think carefully about it.
With a shift in emphasis to quizzes and tests, rather than actual coding, I can only see this as working to lower the quality level of students' programming skills.
Considering most of my programming classes had test questions that made you write procedures and functions I don't see how this will change much. The people who actually know how to program will pass and the others won't.
And what will you do when the code for the virus is recompiled to run in *NIX? No OS is perfectly secure, the fact that *NIX based OSes and Mac OS was not hit is just an indication of the limited programing skills and/or time of the creator.
Atleast under *NIX one has permitions and optional quotas. Both help greatly in keeping crap from infecting a system or causing DoS situations. As an example I'm running a news retreival program under the account news. If someone managed to exploit it they would only be able to fill up partition/data2. That is because that is the only place that the news user is allowd to create or modify files. I even have news locked out of using the main/tmp directory. If it dosen't need access something I disabled it via access control lists. I also have throttles on the maximum percentage of memory and CPU allowed.
Buy StarOffice for all and switch everybody over to it. Keep your user systems running Windows, but stop upgrading them, just patch them as needed for security. Let new hardware purchases supply new Windows licenses if needed, otherwise buy OS less machines and put Linux and StarOffice on them for new employies and upgrades.
The need for specialized applications may hamper your getting fully off M$ products. First try them all under Wine, noting sucesses and failures. Contact the software suppliers in question for the ones that don't work and ask when they will have them running under Linux natively or under Linux/Wine. Do so in a respectfull manner, and use company letterhead in all snailmail corespondence. Tell them specifically that your company has made the decision to switch to Linux (even if it isn't true) and you want their app on Linux or you will go elsewhere. Don't forget to mention your position in the company. Embelish it a bit if needed.
Make sure you have licenses for all the installed software, if not remove it from the system.
The PhotoPC project has both Linux and Windows support and deals with cameras via serial or USB. It is designed with command line options so it should be easier to hack into a PDA setting. I've done some hacking, but I'm not happy with my results yet. I also want to do computer controlled digital time lapse photography. I've dome alot by hand, but one misses the timing every so often.
When I need guaranteed timing I dedicate a microcontroller. You can do your calculations on the linux box then send the result to the micro controller which then passes it on at the right time. Yes it is a bit of hardware, but many things can be done with quite simple hardware setups. On a robot of mine I have all the low level functions handled by dedicated micro controllers. They all talk to the host Linux system which isn't even a real time based system and everything gets done on time. All the high level decisions are done on programs run on the Linux host and then they tell the micro controllers what to do and when to do it. The micro controllers also feed information on events to the programs. The only thing I did special was memory lock the programs. Otherwise they are running under a stock 2.2 kernel from a Debian distribution.
A trick to help keep a bunch of micro controllers running along with the same timing is to use a clock generator chip rather than give each micro controller it's own crystal. You feed the output from it to all the micro controllers as their clock input. Then they all run lock step with each other. If they have a separate timer input that also can be fed from a shared clock. An interupt input can also be used to syncronize all the micro controllers.
On your Linux, strip out as many of they system programs as you can. Many services are started that you just won't need, and they will compete for valuable CPU time.
Sure; the radiation leakage from your television set is easily strong enough to be picked up by a van across the street and reconstructed to show the actual picture you are seeing.
Since they are the cable company (and presumably a monopoly), they have access to all of the cable video streams which you could be watching. If your signal matches one which you aren't paying for, then know you're stealing cable.
Is it technology that is available to the average joe? Not likely. To use it they would need a search warrant. Monitoring like that falls under the illegal search part of the constitution. Dosen't matter that it is a company doing the search, they still need the search warrent.
No, most are found out by stupidities like bragging, and or modifying the cable companies equipment on the pole.
May not have been general purpose, but it was the first use of digital logic, drum memory, capacitor based memory (think DRAM), paper IO, bit serial processing, and parallel computing.
Do both. One can still have the cup of coffee or tea. This just allows one to choose a better tasing tea without having to select for caffein content. This also opens up a hole slew of other better tasting beverages that are sans caffein.
I've been looking for in circuit programible devices MCUs, DSPs, FPGA, etc. that are able to be programmed from Linux while in circuit. Which devices can be, and what sites tell how to go about it?
Slashdot Mirror
The comment on wondering how many were tagged reminded me of the RFID tagsd we use on cattle. We know how much each steer in our feed lot eats and when they do it.
You got to wonder what the liabilities SCO would have at that point. I wouldn't touch them if I was paid to buy them.
And it looks like IBM has tacked on a legal bill to their motion for summary judgement.
No. Last I looked you could get FLASH based CompactFlash II format cards all the way up to 1G byte. They were also mentioning plans for larger ones. Nice thing about compact flash is you just strap the right pin and they behave like an IDE disk. All it takes is a passive converter to connect them to and IDE bus.
The most tech I've done in years is to run worms on old green and amber screen terminals and set them in the windows next to the door. Looks much better if you have one with a detachable keyboard. They usually are partially hidden by a netting with leaves and other forest floor debris in it. It makes an interesting effect to have the worms crawling about under the debris. I use black construction paper to hide the bezels of the terminals.
Spread this far and wide.
Ever heard of Allison Transmittion? They make automatic transmittions for use in semis and other heavy duty uses. Infact they are considered one of the best transmittion makers out there. Many fleet operators won't buy a truck unless it has an Allison transmittion.
Send your film to a proper lab and you won't get the scratches and finger prints. Also have them put the negatives in proper archival quality sleeves. If you see finger prints on the negatives when they come to you complain loudly as that is damage. When printing it is nearly impossible to remove a fingerprint with out washing the negative. Whenever you get a negative wet the emulsion surface softens and is much more easily dammaged. Blow off dust with a clean air supply, never use your finger, and only use a very soft brush as a last resort. Also control dust in you film handling area. I'd strongly reccomend getting something like a HEPE filter from Target or Walmart and run it all the time in your film handling area. When handling the negatives, only touch the edges and never touch the surfaces. Clenliness is also a must. When I was working in the studio I would wash my hands a few times over the day to remove finger oils. We didn't use goves because of dust from the fibers. We'd also dust the counter a few times using a dust magnet type cloth. Usually between each set of negatives we worked with. The sequence was clean the light box area, find and dust off the negative storage box, then clean the hands and finally bring out the negatives and/or slides. Following those rules we only had to touch up one negative in two years. Either the film came scratched or the photo lab scratched it, we don't know which but when I unpacked it at the light box it was already scratched. We never had problems with dust specs.
Going full SLR digital is also out of my price range for now. I'd really like to. I want to go back into profesional photography. Being able to capture perfect color ballance is a must as far as I'm concerned. With a digital camera that can capture color ballance off a white card this becomes easy. Color ballance was one area I found frustrating using regular film. The problem is it really requires using different films for differnt light sources and adjusting the color setting when making prints. Needing the different films causes one to need multiple film backs or camera bodies which raises costs. Sure you can use filters to reballance things but that is only a half measure and complicates the printing process. Also usually you can't control what the guy in the photo lab sets the color wheels on the enlarger to unless you go to a custom lab and that costs $$$. It is about $8,000-10,000 for the EOS camera setup I want to start out with. Going film only drops the price by a $1,000.
I do remember seeing a writeup on a film canister shaped device that went in place of the regular 35mm film cartridge. It had a toung off of it that housed the CCD chip and positioned it in the regular film plane area. Main issue I see with it is the film plane area varies from camera to camera.
This is vary true. You must code UDP applications to deal with packet loss, and yes packets can be dropped when going from localhost to localhost. Overfill the network transmit or receive capacities or use up all buffer space, packets will be dropped. There is no way around that without changing the UDP protocal. Afterall if your application sends out 10,000 UDP packets per second and the network can only handle 2,000 per second, the other 8,000 are to be dropped. For TCP connection loss is all you have to code for.
"History doesn't repeat itself, but it does rhyme."
Young grasshopper, you obviously know little of history. This flag will only cause "First Hitler" and "First Nazis" posts and thus make any flag like that useless. Wave the right flag, the bull will charge. Think carefully about it.
Allergies not witstanding, the Pop Tart also won't poison you if you eat it. ;-)
Considering most of my programming classes had test questions that made you write procedures and functions I don't see how this will change much. The people who actually know how to program will pass and the others won't.
Atleast under *NIX one has permitions and optional quotas. Both help greatly in keeping crap from infecting a system or causing DoS situations. As an example I'm running a news retreival program under the account news. If someone managed to exploit it they would only be able to fill up partition /data2. That is because that is the only place that the news user is allowd to create or modify files. I even have news locked out of using the main /tmp directory. If it dosen't need access something I disabled it via access control lists. I also have throttles on the maximum percentage of memory and CPU allowed.
The need for specialized applications may hamper your getting fully off M$ products. First try them all under Wine, noting sucesses and failures. Contact the software suppliers in question for the ones that don't work and ask when they will have them running under Linux natively or under Linux/Wine. Do so in a respectfull manner, and use company letterhead in all snailmail corespondence. Tell them specifically that your company has made the decision to switch to Linux (even if it isn't true) and you want their app on Linux or you will go elsewhere. Don't forget to mention your position in the company. Embelish it a bit if needed.
Make sure you have licenses for all the installed software, if not remove it from the system.
Strip the letter and forward it... May not be the wisest thing to do, but what the heck.
The PhotoPC project has both Linux and Windows support and deals with cameras via serial or USB. It is designed with command line options so it should be easier to hack into a PDA setting. I've done some hacking, but I'm not happy with my results yet. I also want to do computer controlled digital time lapse photography. I've dome alot by hand, but one misses the timing every so often.
A trick to help keep a bunch of micro controllers running along with the same timing is to use a clock generator chip rather than give each micro controller it's own crystal. You feed the output from it to all the micro controllers as their clock input. Then they all run lock step with each other. If they have a separate timer input that also can be fed from a shared clock. An interupt input can also be used to syncronize all the micro controllers.
On your Linux, strip out as many of they system programs as you can. Many services are started that you just won't need, and they will compete for valuable CPU time.
Since they are the cable company (and presumably a monopoly), they have access to all of the cable video streams which you could be watching. If your signal matches one which you aren't paying for, then know you're stealing cable.
Is it technology that is available to the average joe? Not likely. To use it they would need a search warrant. Monitoring like that falls under the illegal search part of the constitution. Dosen't matter that it is a company doing the search, they still need the search warrent.
No, most are found out by stupidities like bragging, and or modifying the cable companies equipment on the pole.
To easy to abuse, and way to much overhead for the ISP at the receiving end.
May not have been general purpose, but it was the first use of digital logic, drum memory, capacitor based memory (think DRAM), paper IO, bit serial processing, and parallel computing.
Do both. One can still have the cup of coffee or tea. This just allows one to choose a better tasing tea without having to select for caffein content. This also opens up a hole slew of other better tasting beverages that are sans caffein.
If your not muslim you can forget Egypt and Morrocco.
I've been looking for in circuit programible devices MCUs, DSPs, FPGA, etc. that are able to be programmed from Linux while in circuit. Which devices can be, and what sites tell how to go about it?