> Just because a problem is hard or impossible to solve doesn't make it automatically equivalent to the halting problem.
Of course not, but proving correctness of a C program is the halting problem, and that is what was described.
I was very careful to use the word "algorithm" as opposed to "solution." There may be a "good enough" solution. There is no algorithm.
There is no algorithm to do what you are describing (google for "halting problem")
You could run something like lint to catch common C errors.
Better than that though is to profile your code actually running, to see buffer overflows and leaks that actually occur (google for valgrind).
But most of these exploits are specially crafted input that produce buffer overflows. Typical input won't. So it is very hard to test for buffer overflows.
The only 100% way to work these kinds of problems out is to write code in higher level languages, so at least you'll get an exception and fail closed in the case of a buffer overflow.
But in C, the only way to resolve these problems is
1) Don't write code with buffer overflows (hard) 2) Find and fix buffer overflows in code review (harder) 3) Write good enough negative test cases that you find the buffer overflows (really hard for even a good tester).
You missed the real reason for this tactic: to `encourage' hardware manufacturers to play nice and release the source code to their drivers by making open source drivers the path of least resistance.
Well, for an embedded system you don't need any VM. You can just program in C or assembler for your target.
But say you want to take the VM approach, I suppose one is as good as any. Forth has the advantage though of being older, tried, and tested.
To my mind the main things going for Java and.Net is the fairly comprehensive runtime. But none of that comes along with you onto the embedded platform, so why not just go with old stolid Forth, with as much assembler as you need?
Frankly though most uCs do just fine with whatever C compiler exists that has been tailored to that uC. Unless you're just dying for C# or Java syntax, the mainstream firmware programmer who will hopefully maintain the software (and keep support requests away from your desk) is probably going to be more comfortable with C or assembler, remotely possibly Forth.
Come on... you know the network is always admined by some jackass with a superiority complex. He likes you to have to ask him, and he likes to say no.
And if he doesn't say no, he says, please fill out this form, it could take a week to go through upper management, at which point he throws it in a big stack of forms that are not going anywhere.
At this point, the upstart competition that simply does whatever it takes to get things done efficiently, on time, would already be completed with the work.
Everything in life is a tradeoff. You have to decide whether impeding folks work, in each case, is worth the consequences.
Well if you're going to do it, that's the way I'd do it...
This whole subject of being able to disallow USB storage devices is pointless. It is one small factor in a system like you're describing which actually has a chance of stopping wholesale transfers of information, and at least catching abuses after the fact (good monitoring)
If it were someone else I'd call bullshit, but it sounds true...
The USA NSA probably disagrees with me on a lot of things. So?
You seem to be implying that I am against file access controls. I'm not. I'm against blanket device or i/o controls to the computer.
If someone is not trustworthy, they should not have access to confidential documents. That is fine with me. That kind of technologically enforced policy makes perfect sense. You are controlling the data where it makes sense to control it, as an access control *on the data*
What I am saying is that access control between devices you can connect to a machine rarely make sense. The control should be on the file and the user, not the I/O ports.
If you have top secret data that you really can't have copied, but certain individuals you can't trust not to mishandle confidential documents need to access them (???) then you have to have a machine separated from the network and glue put in all the ports, and no printers, and goggles for the viewscreen and an obscured keyboard. Anything less is just fooling around, unless you are screening all individuals for portable electronic devices and pencils.
Also you might want to wack them on the head on their way out of the building every do so they don't remember something secret...
That's why I say if you don't trust the folks you are giving the important keys to, you're screwed anyway.
You can protect all the data on the machine by removing the keyboard and monitor ports, and all the I/O ports, and welding the case shut, and bolting it to the floor.
But that machine won't be good for much anymore. The correct place to control is not the I/O ports (with the special exception of networking ports that connect to the outside world... and even then you don't control the ports, you do in/outbound firewall and proxy at the software level).
Placing sales peoples pictures on a machine with sensitive data isn't a problem. Copying sensitive data off the machine is. Protect the data (access rights, encryption, etc.), monitor the employee.
Short of crap like Trusted Computing, copying is not controllable, because machines are designed to efficiently process and share data, That is their purpose and they are not useful if you can't do those things. If you want to protect the data, encrypt it, access control it, firewall it, and only share the keys with those you have good reason to trust.
Yes, corporations must comply with the law. Employees must comply with the law. That means teaching them what they must do to comply, making it easy to comply, and monitoring that they comply. Nowhere did I argue that sensitive data should not be protected; passwords, access controls/rights, and encryption can give you those things.
Keep in mind that somebody has the keys to the data. There's no way to enforce proper behavior short of assigning someone to monitor him 24/7. And there are always holes.
For anyone that doesn't have the keys to the data, banning storage devices does no good; they theoretically can't get to the data anyway.
Your best bet is to restrict data access to those few who need it (the gatekeeper), and then get to know/monitor/know you can trust the guy.
It's a bad analogy, but you miss my point. I believe that the corporation is making the wrong policy.
The policy should be "don't copy or redistribute x type of corporate data without authorization."
Not "Thou shalt not use a USB storage device."
The reason being that the employee may have a perfectly good reason for connecting a USB storage device that ill advised red tape cannot predict. A general policy against copying certain types of data without authorization covers the actual goal you want to achieve, rather than getting in the way of employees getting their work done.
>I believe most people consider their door a barrier. It's often one of the strongest, sturdiest parts of their home.
Then most people would be WRONG, at least if you consider it a barrier against people... it's mostly there to keep out the elements while easily allowing you to get in/out of the house.
Sure if you enforce the barrier by putting bars on all the doors, windows, chimney, etc. you can garner a fair amount of physical security, at the significant expense of utility (hence people being burned alive in their barred fortress).
Computers are information processing, storage and retrieval devices. Any impediment to those functions is foolishness. Now I'm not saying encrpytion, access rights, etc. don't make sense... secrecy is often important. What I am saying is that data transfer between devices is neither inherently good or bad.
In fact, the better way to handle this particular problem is via simple tripwires. If folks are regularly abusing equipment for inappropriate purposes, you need to take them out of positions where they have access to sensitive information in the first place and/or fire them, simple as that.
Just because you wish that employees be treated as automatons with no ability to make intelligent choices doesn't mean you should.
A USB drive is not a gun. And I don't think guns have much utility in the typical workplace...
If you want employees to be effective and efficient they need to be empowered to do their work. Putting in artificial roadblocks is just red tape. You need to justify that policies will do what you want them to do. Otherwise, they just get in the way of good people trying to do their work.
If they are the small percentage with bad intent, actually looking to do damage, you're fighting a lost cause. Managers need to know, monitor, and demand that policy be followed. An important aspect of that is not making pointless policies that don't solve a real problem.
You imply connecting a USB storage device can have no legitimate purpose. I can think of many legitimate reasons, and so can you. I'd start with backups, testing a hard drive sent in from the field without opening the case, data recovery in the same circumstance, etc.
Technology is almost never inherently good or bad. In particular something as generic as a storage device is neither good or bad or even to be minimized as a "gadget" which is "in violation of security policies."
To paraphrase, Hardware doesn't violate policy. People do.
Unless you have bars all over the place, a homeowners door is a message/statement, not a barrier.
It says, don't open this/enter without permission.
Disabling USB storage is an attempt to enforce policy by technological means. It is not a message. And it implies a mistaken belief that it is a good defense, which it ain't...
When it comes to truly sensitive data, it isn't just "any idiot" you're really worried about.
First you have to worry about the guy that has the password to the machine and can decrypt the data. He's the one that is going to steal the data... he knows where it is, he knows how to get to it.
Otherwise the person you're worried about is a hacker. And he's NOT an idiot either.
So what is your point? Breaking the machine so things that should normally work don't just gets in the way of using the machine normally. It's a cost benefit thing... you're incurring a cost, less usability, for no benefit, that is, you're barring people that aren't going to steal the data from stealing it.
No, I think that if you are going to solve a problem you need to make a serious, comprehensive attempt to solve it.
This is just one facet of the problem. Patching this whole is just to give the unknowledgeable a false sense of security. And that is more dangerous than leaving them worried, which might prompt more serious consideration.
Credit card information can be pretty well locked down. It is normally restricted to one machine, and that machine is restricted to a certain set of users. It should be stored encrypted, and only some folks should have the keys.
Disabling USB storage devices on such a machine won't help if you don't trust the employee that has access. In fact that is probably the real issue; trying to let technology replace taking real responsibility for knowing and monitoring your employees. People steal data, and you need to know that your people aren't going to steal it. It's more of a human problem than a technical one.
But you're missing the fact that these schemes don't work for folks that know what they're doing, which is who you are trying to control.
Everyone else, i.e. the people that are just trying to get their work done, are the ones impacted by these efforts.
USB storage devices may be a closeable hole. Are you going to close these too:
1. The Internet. Companies try. But if you can make a web request, send an email, etc. you can send data out of the company, very efficiently. Even the most byzantine "Great Firewall of Company X" leaves this door wide open. They may put a proxy, etc. That doesn't close the hole.
In fact, anyone worth their salt can create an encrypted VPN over any two way channel you give them.
2. The serial port, say connected to a cell phone, or a laptop.
3. The Parallel port. Laplink cable and a laptop, or maybe a parallel connected MP3 player (old models available for $5-$30 on ebay).
4. The ethernet port. Seriously, have you seen a computer that didn't allow connections to other machines on unpriveleged sockets? The Rio Karma comes to mind as something you could hook up there.
5. Floppy disk drive
6. CD-ROM burner. Typically easily available on every corporate network I've seen.
7. USB port on other protocols than "Storage," like say the simple USB peer-to-peer network cables.
8. Photons emitted by the monitors convey information which may be written down or relayed over a telephone or photographsed with a camera
9. Directly connected, and network printers. If you really want to, you can just print it out, and likely you could print a heck of a lot of info reduced down so small that you could shove the piece of paper in your nose and blow it up later to a readable size.
Given all of this, I'd say it is pointless to try to close all the holes without a ground up redesign of how operating system security works, and even then, there are ways around it. Neither Microsoft nor industry is going there any time soon, so why get in the way of folks just trying to get their work done if the problem isn't really solved?
Myself, I gave up on modern "portables" some time back. Battery life sucks so bad, they always need to be plugged in. They heat up like a mo-fo. The keyboards invariably suck. And their hard drives are serious underperformers.
Since I need to plug in anyway, as a contractor, when I need to go on-site, I take my Shuttle XPC in a little cart, with a real buckling-spring UNICOMP keyboard. It's got 2GB of RAM and a fast CPU, can run VMWare handily so I can launch Winders from my Debian system as necessary.
I just use the monitor at whatever desk the client decides to assign me for the day.
If I carry a laptop any more it's a Tandy Model 102, and I just use it for editing text. Now that thing is portable... 20 hours on 4 AA batteries, passes the drop test, and has an excellent keyboard. I transfer files to/from via the serial port.
We're working on a memory/flash storage expansion for it at http://bitchin100.com/remem_project.html
What Bush doesn't seem to understand is that terrorists don't appear out of a vacuum.
Think in your own context, what could cause you to become a terrorist? Well, if a Foreign state killed your family, took your property by force and confined you to a refugee camp, do you think that would do it?
Or perhaps your country is hit by an epidemic and the other richer countries stand by and let hundreds of thousands die because they need to protect their precious monopolies on high priced drugs and related intellectual property?
Add to that some religious fanaticism that gives you to believe that all of this warrents total war against your oppressor, and that God himself commands it.
At some level, we all understand this including the Bush administration. But it seems it is more convenient just to make a show of force against a foreign country that has little if anything to do with Al Qaida. The war in Afghanistan was justified. The war in Iraq, is not, at least by current events (in fact, a war in Iraq could have been justified by the attempt on the first President Bush's life by Iraqi intelligence).
And in fact every bit of collateral civilian damage in Iraq has the possibility of creating another jihadi. How is this supposed to make sense?
It doesn't. And unfortunately neither candidate is addressing the issue of how to alter our foreign policy to stop manufacturing new waves of terrorists.
"They never stop thinking about new ways to harm our country and our people, and neither do we."
I've had good results with transym OCR. I had to run it under VmWare. I tried all the F/OSS but it produced unusable results. I think it cost around $40
I am heading up a project to convert an out of print computer book to LaTeX (with the author's permission) and one of the volunteers suggested this package. One other nice thing about it is that the registered version comes with API documentation and VB6 source code to the front end, so you can change it however you want as long as you don't need to modify the engine.
For myself, I will be teaching my daughter to respect the copyrights of proprietary software developers who are (jackbooted) members of the BSA by never copying their software from permanent storage into RAM.
If you sign one of these agreements that oblige you to disclose all inventions when you sign up with the company, you don't, and they come after you for disclosing stuff you freely gave them while employed, well, I guess you get what you deserve.
I signed one with one company. I'll never sign another as long as I can avoid it.
Look to the past. We were getting 20 hours battery life with regular non-proprietary AA batteries back in the 80's.
TRS-80 Model 100, 102 Cambridge Z88 Amstrad NC100 Amstrad NC200
Serious keyboards, (except the Z88... but then its membrane keyboard is actually near silent so it has advantages).
Instant-on, no boot time, no harddrive to wear down, the Model 100s pass the drop test.
Universal interface called "RS232" you can connect it to practically anything
LCD screen is actually visible outdoors.
32K RAM of course in the model 100 but we're going to fix that:-)
Modern laptops are barely more portable than the old luggables. I don't even carry one anymore. I have a little foldable cart with a Shuttle Xpc in it for serious work.
Slashdot Mirror
> Just because a problem is hard or impossible to solve doesn't make it automatically equivalent to the halting problem. Of course not, but proving correctness of a C program is the halting problem, and that is what was described. I was very careful to use the word "algorithm" as opposed to "solution." There may be a "good enough" solution. There is no algorithm.
There is no algorithm to do what you are describing (google for "halting problem")
You could run something like lint to catch common C errors.
Better than that though is to profile your code actually running, to see buffer overflows and leaks that actually occur (google for valgrind).
But most of these exploits are specially crafted input that produce buffer overflows. Typical input won't. So it is very hard to test for buffer overflows.
The only 100% way to work these kinds of problems out is to write code in higher level languages, so at least you'll get an exception and fail closed in the case of a buffer overflow.
But in C, the only way to resolve these problems is
1) Don't write code with buffer overflows (hard)
2) Find and fix buffer overflows in code review (harder)
3) Write good enough negative test cases that you find the buffer overflows (really hard for even a good tester).
You missed the real reason for this tactic: to `encourage' hardware manufacturers to play nice and release the source code to their drivers by making open source drivers the path of least resistance.
Well, for an embedded system you don't need any VM. You can just program in C or assembler for your target.
.Net is the fairly comprehensive runtime. But none of that comes along with you onto the embedded platform, so why not just go with old stolid Forth, with as much assembler as you need?
But say you want to take the VM approach, I suppose one is as good as any. Forth has the advantage though of being older, tried, and tested.
To my mind the main things going for Java and
Frankly though most uCs do just fine with whatever C compiler exists that has been tailored to that uC. Unless you're just dying for C# or Java syntax, the mainstream firmware programmer who will hopefully maintain the software (and keep support requests away from your desk) is probably going to be more comfortable with C or assembler, remotely possibly Forth.
.Net for an embedded uC? No more appropriate than Java would be.
C, or assembler, or Forth.
-- John.
Come on... you know the network is always admined by some jackass with a superiority complex. He likes you to have to ask him, and he likes to say no.
And if he doesn't say no, he says, please fill out this form, it could take a week to go through upper management, at which point he throws it in a big stack of forms that are not going anywhere.
At this point, the upstart competition that simply does whatever it takes to get things done efficiently, on time, would already be completed with the work.
Everything in life is a tradeoff. You have to decide whether impeding folks work, in each case, is worth the consequences.
Well if you're going to do it, that's the way I'd do it...
This whole subject of being able to disallow USB storage devices is pointless. It is one small factor in a system like you're describing which actually has a chance of stopping wholesale transfers of information, and at least catching abuses after the fact (good monitoring)
If it were someone else I'd call bullshit, but it sounds true...
Yes you've worked with guys like me before. We're called Engineers.
I've worked with guys like you before. You're called... to fix my email or because I can't print...
Do you seriously think Office Space is an example of how corporate IT should work? It was a frigging SATIRE for chrissake!
Access controls and permissions should be properties of the user and the file. Not the I/O port. That's just my opinion, so sorry if that offends you.
The USA NSA probably disagrees with me on a lot of things. So?
You seem to be implying that I am against file access controls. I'm not. I'm against blanket device or i/o controls to the computer.
If someone is not trustworthy, they should not have access to confidential documents. That is fine with me. That kind of technologically enforced policy makes perfect sense. You are controlling the data where it makes sense to control it, as an access control *on the data*
What I am saying is that access control between devices you can connect to a machine rarely make sense. The control should be on the file and the user, not the I/O ports.
If you have top secret data that you really can't have copied, but certain individuals you can't trust not to mishandle confidential documents need to access them (???) then you have to have a machine separated from the network and glue put in all the ports, and no printers, and goggles for the viewscreen and an obscured keyboard. Anything less is just fooling around, unless you are screening all individuals for portable electronic devices and pencils.
Also you might want to wack them on the head on their way out of the building every do so they don't remember something secret...
That's why I say if you don't trust the folks you are giving the important keys to, you're screwed anyway.
You can protect all the data on the machine by removing the keyboard and monitor ports, and all the I/O ports, and welding the case shut, and bolting it to the floor.
But that machine won't be good for much anymore. The correct place to control is not the I/O ports (with the special exception of networking ports that connect to the outside world... and even then you don't control the ports, you do in/outbound firewall and proxy at the software level).
Placing sales peoples pictures on a machine with sensitive data isn't a problem. Copying sensitive data off the machine is. Protect the data (access rights, encryption, etc.), monitor the employee.
Short of crap like Trusted Computing, copying is not controllable, because machines are designed to efficiently process and share data, That is their purpose and they are not useful if you can't do those things. If you want to protect the data, encrypt it, access control it, firewall it, and only share the keys with those you have good reason to trust.
Yes, corporations must comply with the law. Employees must comply with the law. That means teaching them what they must do to comply, making it easy to comply, and monitoring that they comply. Nowhere did I argue that sensitive data should not be protected; passwords, access controls/rights, and encryption can give you those things.
Keep in mind that somebody has the keys to the data. There's no way to enforce proper behavior short of assigning someone to monitor him 24/7. And there are always holes.
For anyone that doesn't have the keys to the data, banning storage devices does no good; they theoretically can't get to the data anyway.
Your best bet is to restrict data access to those few who need it (the gatekeeper), and then get to know/monitor/know you can trust the guy.
It's a bad analogy, but you miss my point. I believe that the corporation is making the wrong policy.
The policy should be "don't copy or redistribute x type of corporate data without authorization."
Not "Thou shalt not use a USB storage device."
The reason being that the employee may have a perfectly good reason for connecting a USB storage device that ill advised red tape cannot predict. A general policy against copying certain types of data without authorization covers the actual goal you want to achieve, rather than getting in the way of employees getting their work done.
>I believe most people consider their door a barrier. It's often one of the strongest, sturdiest parts of their home.
Then most people would be WRONG, at least if you consider it a barrier against people... it's mostly there to keep out the elements while easily allowing you to get in/out of the house.
Sure if you enforce the barrier by putting bars on all the doors, windows, chimney, etc. you can garner a fair amount of physical security, at the significant expense of utility (hence people being burned alive in their barred fortress).
Computers are information processing, storage and retrieval devices. Any impediment to those functions is foolishness. Now I'm not saying encrpytion, access rights, etc. don't make sense... secrecy is often important. What I am saying is that data transfer between devices is neither inherently good or bad.
In fact, the better way to handle this particular problem is via simple tripwires. If folks are regularly abusing equipment for inappropriate purposes, you need to take them out of positions where they have access to sensitive information in the first place and/or fire them, simple as that.
Just because you wish that employees be treated as automatons with no ability to make intelligent choices doesn't mean you should.
A USB drive is not a gun. And I don't think guns have much utility in the typical workplace...
If you want employees to be effective and efficient they need to be empowered to do their work. Putting in artificial roadblocks is just red tape. You need to justify that policies will do what you want them to do. Otherwise, they just get in the way of good people trying to do their work.
If they are the small percentage with bad intent, actually looking to do damage, you're fighting a lost cause. Managers need to know, monitor, and demand that policy be followed. An important aspect of that is not making pointless policies that don't solve a real problem.
You imply connecting a USB storage device can have no legitimate purpose. I can think of many legitimate reasons, and so can you. I'd start with backups, testing a hard drive sent in from the field without opening the case, data recovery in the same circumstance, etc.
Technology is almost never inherently good or bad. In particular something as generic as a storage device is neither good or bad or even to be minimized as a "gadget" which is "in violation of security policies."
To paraphrase, Hardware doesn't violate policy. People do.
Poor analogy.
Unless you have bars all over the place, a homeowners door is a message/statement, not a barrier.
It says, don't open this/enter without permission.
Disabling USB storage is an attempt to enforce policy by technological means. It is not a message. And it implies a mistaken belief that it is a good defense, which it ain't...
When it comes to truly sensitive data, it isn't just "any idiot" you're really worried about.
First you have to worry about the guy that has the password to the machine and can decrypt the data. He's the one that is going to steal the data... he knows where it is, he knows how to get to it.
Otherwise the person you're worried about is a hacker. And he's NOT an idiot either.
So what is your point? Breaking the machine so things that should normally work don't just gets in the way of using the machine normally. It's a cost benefit thing... you're incurring a cost, less usability, for no benefit, that is, you're barring people that aren't going to steal the data from stealing it.
-- John.
No, I think that if you are going to solve a problem you need to make a serious, comprehensive attempt to solve it.
This is just one facet of the problem. Patching this whole is just to give the unknowledgeable a false sense of security. And that is more dangerous than leaving them worried, which might prompt more serious consideration.
Credit card information can be pretty well locked down. It is normally restricted to one machine, and that machine is restricted to a certain set of users. It should be stored encrypted, and only some folks should have the keys.
Disabling USB storage devices on such a machine won't help if you don't trust the employee that has access. In fact that is probably the real issue; trying to let technology replace taking real responsibility for knowing and monitoring your employees. People steal data, and you need to know that your people aren't going to steal it. It's more of a human problem than a technical one.
But you're missing the fact that these schemes don't work for folks that know what they're doing, which is who you are trying to control.
Everyone else, i.e. the people that are just trying to get their work done, are the ones impacted by these efforts.
USB storage devices may be a closeable hole. Are you going to close these too:
1. The Internet. Companies try. But if you can make a web request, send an email, etc. you can send data out of the company, very efficiently. Even the most byzantine "Great Firewall of Company X" leaves this door wide open. They may put a proxy, etc. That doesn't close the hole.
In fact, anyone worth their salt can create an encrypted VPN over any two way channel you give them.
2. The serial port, say connected to a cell phone, or a laptop.
3. The Parallel port. Laplink cable and a laptop, or maybe a parallel connected MP3 player (old models available for $5-$30 on ebay).
4. The ethernet port. Seriously, have you seen a computer that didn't allow connections to other machines on unpriveleged sockets? The Rio Karma comes to mind as something you could hook up there.
5. Floppy disk drive
6. CD-ROM burner. Typically easily available on every corporate network I've seen.
7. USB port on other protocols than "Storage," like say the simple USB peer-to-peer network cables.
8. Photons emitted by the monitors convey information which may be written down or relayed over a telephone or photographsed with a camera
9. Directly connected, and network printers. If you really want to, you can just print it out, and likely you could print a heck of a lot of info reduced down so small that you could shove the piece of paper in your nose and blow it up later to a readable size.
Given all of this, I'd say it is pointless to try to close all the holes without a ground up redesign of how operating system security works, and even then, there are ways around it. Neither Microsoft nor industry is going there any time soon, so why get in the way of folks just trying to get their work done if the problem isn't really solved?
-- John.
Myself, I gave up on modern "portables" some time back. Battery life sucks so bad, they always need to be plugged in. They heat up like a mo-fo. The keyboards invariably suck. And their hard drives are serious underperformers.
Since I need to plug in anyway, as a contractor, when I need to go on-site, I take my Shuttle XPC in a little cart, with a real buckling-spring UNICOMP keyboard. It's got 2GB of RAM and a fast CPU, can run VMWare handily so I can launch Winders from my Debian system as necessary.
I just use the monitor at whatever desk the client decides to assign me for the day.
If I carry a laptop any more it's a Tandy Model 102, and I just use it for editing text. Now that thing is portable... 20 hours on 4 AA batteries, passes the drop test, and has an excellent keyboard. I transfer files to/from via the serial port.
We're working on a memory/flash storage expansion for it at http://bitchin100.com/remem_project.html
-- John.
I found a different truth in the misstatement.
What Bush doesn't seem to understand is that terrorists don't appear out of a vacuum.
Think in your own context, what could cause you to become a terrorist? Well, if a Foreign state killed your family, took your property by force and confined you to a refugee camp, do you think that would do it?
Or perhaps your country is hit by an epidemic and the other richer countries stand by and let hundreds of thousands die because they need to protect their precious monopolies on high priced drugs and related intellectual property?
Add to that some religious fanaticism that gives you to believe that all of this warrents total war against your oppressor, and that God himself commands it.
At some level, we all understand this including the Bush administration. But it seems it is more convenient just to make a show of force against a foreign country that has little if anything to do with Al Qaida. The war in Afghanistan was justified. The war in Iraq, is not, at least by current events (in fact, a war in Iraq could have been justified by the attempt on the first President Bush's life by Iraqi intelligence).
And in fact every bit of collateral civilian damage in Iraq has the possibility of creating another jihadi. How is this supposed to make sense?
It doesn't. And unfortunately neither candidate is addressing the issue of how to alter our foreign policy to stop manufacturing new waves of terrorists.
"They never stop thinking about new ways to harm our country and our people, and neither do we."
Indeed.
I've had good results with transym OCR. I had to run it under VmWare. I tried all the F/OSS but it produced unusable results. I think it cost around $40
I am heading up a project to convert an out of print computer book to LaTeX (with the author's permission) and one of the volunteers suggested this package. One other nice thing about it is that the registered version comes with API documentation and VB6 source code to the front end, so you can change it however you want as long as you don't need to modify the engine.
For myself, I will be teaching my daughter to respect the copyrights of proprietary software developers who are (jackbooted) members of the BSA by never copying their software from permanent storage into RAM.
If you sign one of these agreements that oblige you to disclose all inventions when you sign up with the company, you don't, and they come after you for disclosing stuff you freely gave them while employed, well, I guess you get what you deserve.
I signed one with one company. I'll never sign another as long as I can avoid it.
Look to the past. We were getting 20 hours battery life with regular non-proprietary AA batteries back in the 80's.
:-)
TRS-80 Model 100, 102
Cambridge Z88
Amstrad NC100
Amstrad NC200
Serious keyboards, (except the Z88... but then its membrane keyboard is actually near silent so it has advantages).
Instant-on, no boot time, no harddrive to wear down, the Model 100s pass the drop test.
Universal interface called "RS232" you can connect it to practically anything
LCD screen is actually visible outdoors.
32K RAM of course in the model 100 but we're going to fix that
Modern laptops are barely more portable than the old luggables. I don't even carry one anymore. I have a little foldable cart with a Shuttle Xpc in it for serious work.