Whenever a nonsigning inventor gives a reason for refusing to sign the application oath or declaration, that reason should be stated in the petition.
Check the bloody law
Read the fucking link you posted, twonk. If I refuse to sign a patent application and also state a reason for refusal to sign then the company must petition the PTO and state that reason.
If this reason is noting (moral, don't like the patent, don't want my name out there, etc) then there would be little argument. If the reason is more substantial (I believe there is prior art, that the patent was obvious, etc) then the PTO has grounds to refuse the patent application.
While they don't need my permission, they do need to make every attempt to get it, and if I refuse they do need to tell the PTO why. Hell, if they fudge it I could go and tell the PTO why.
And if you refuse to sign (and are not dead) the patent office will (hopefully) like to know why. I can see it being a common thing and there could be some pretty valid legal/moral reasons for refusing to sign a patent application.
The reason patents was introduced was to make the information public and allow for others to benefit from the discovery if they get a proper licens or work in a completly diffrent field.
The thing is, until it's patented it's not disclosed- therefore it's a trade secret.
Make an anonymous posting somewhere, describing the innovation you came up with. If it has been disseminated before, it cannot be patented.
The problem with doing that is if the invention is not obvious and has paved the way for considerable financial gain then the company can probably trace it back to you through court orders for information; regardless of how anonymous you thought you were at the time.
It _IS_ a breach of your contract to release trade secrets outside of the company you work for. It's a pretty much standard clause in every employment contract. If it is traced back to you there could be loss of job, litigation, and possibly criminal charges depending on the severity that your company puts on the matter.
The do need to list the inventors by name, even if the patent belongs to a company. IIRC they do need to list your name on the patent, and that requires your consent/signature.
I agree with trying to convince the boss to see reason. You'll likely not succeed though.
It sounds like the usual bunch of suits trying to fluff up the value of their company with things that have little meaning and that they know very little about (patents pending that may or may not rejected later) before they flog it off and get rich.
...until they force this trusted all your spying are on done by us computing on us by legislation.
Then it gets really hard, although I guess not technically impossible.
Hmns a good analogy is: encrypt all my stuff give the cryptfile and keyfiles to my friends as a backup. I wonder if they're going to open it up and read it... um...
And maybe a new Windows update took care of the bots installed on some machines and the spammers had to spend time cracking the new Windows to get their bots to work again?
Flash photography damages the exhibits by exposing exhibits to excessive UV light.
And most people use cheap 'instamatic' point and shoot pieces of shit with a flash. Even a lot of tossers with good quality (read: expensive) kit don't know how to use it. They only have it to look like they're rich.
You can really understand why they ban photography in places like museums, libraries, etc. I've taken lots of photos in our local museum and was never hassled. I also did it with the flash deactivated. While I was snapping away your average strobelight joe schmuck was being asked to stop.
Getting offtopic for a minute (just because I want to have a rant), I was talking to the guys at work today. They are a bunch of well educated guys. Not one of them saw a problem with government CCTV, net monitoring, banning photography or anything like that. They all argued that "if you're not doing anything wrong then why not embrace it to let them make us safe from those terrists".
Why are people so fucking apathetic about these things? Today it's one small thing. Tomorrow another. In a few years what would seem like a big loss now seems insignificant and they take that too. Before you know it all your rights will be gone and we'll all be loving Orwell (or whatever they actually name 'big brother').
LFTP's scripted system allows mirroring the backup and only getting files that have changed. With some server-side scripting to dump database diffs it wouldn't be hard to make a FTP backup solution that only downloaded changed files.
rdiff-backup makes incremental diffs of individual files, which saves a lot of space for large files which have small changes like database backups, virtual machine images, and large mailspools.
And rsync with the link-dest option uses hard links, which occupy exactly the space for the inode they are using and no more.
A diff is a small file which occupies a small amount of space on your disk - a non-zero sized file will occupy at least 4k depending on the size of your file system.
Hard links use up a single inode and no more. Why mess about with diffs when you can change into a directory and see yesterday's backup? Don't like yesterdays? Change into another and see the day before that. The depth is limited by the number of inodes you have in your filesystem / number of inodes used in filesystem being backed up.
Mantis looks OK but I prefer something that doesn't need quite as much work to integrate:)
Redmine and Trac both just accept a repository path and bam - integration. Redmine does a bit of a messy with the repo by reading all the changeset information the first time you connect it to the repo though; that can take a long time if it's a well-established repo.
Tortise isn't an issue tracker, it's a front end to Subversion. The OP wants an issue tracker (Think Trac, Bugzilla, Redmine, etc) which is a different beast.
We've been using Trac for a long time and it worked well.
We since discovered Redmine which does about the same job, is themed prettier and seems to be a bit easier to use. All in all Trac and Redmine both do about the same things.
Redmine has a built-in user management, which I'm taking advantage of in our SVN/Hg web server to authenticate users with (single sign on)
Redmine also has support for multiple projects in one tracker, whereas trac needs multiple installs for multiple disjointed projects. The workflow manager in Redmine is also really easy to use; no dicking about writing python scripts to control your workflow.
Redmine talks to Svn, Git, Mercurial, Bazzar and a couple of other source control tools, which is useful if you ever need to move on to those tools. Trac is pretty rooted on subversion, though it does have a Git plugin.
Both are pretty easy to install, but I had Redmine up and running in about 4 minutes whereas it took a bit of messing about to get Trac running.
Redmine also has the manager friendly theme (think that horrible facebook style) so managers will goo and gaa over it then sign off that it be implemented.
My first (memorable) program was written with my dad on the C64. He's not a programmer, but we got a C64 when I was about 4 or 5 and I was keen to know all there was to know about it.
He started reading magazines and got some books that taught him the basics then we'd spend time together building basic (pun intended) things. The first one that did anything memorable was a christmas tree on the screen complete with a flashing light on the top.
It was all downhill from there. Once the basics are in place more and more advanced things follow. Soon you've outgrown your interpreted language and are sitting at the machine level to make it do things fast enough.
Of course, back then it was all very easy. The 8-bit machines only had a handful of opcodes and a small amount of unmanaged memory (well the C64 had a ROM bank that you could cut out if you needed the RAM it shadowed). To make graphics it was a simple matter of poking in a few registers and then writing to the graphics memory directly.
There was no pesky OS or memory management getting in your way. The machine also wasn't very fast, so to do cool things you had to learn about interrupt driven events, 'multi tasking', and designing for optimisation from the start.
These days learning programming like that is nigh-on impossible. The OS hides the machine from you and presents a not-so-neat interface to all the hardware. The machine is fast so there is never any real desire to optimise and programmers aren't learning good principles for it.
If the GP's teenage son is really interested in learning programming perhaps a small microcontroller project would be a good place to start. PICs and AVR cores are quite simple to implement and program. Investigate a development kit instead of diving into programming the PC.
An IDE with good code browsing tools is much better than a mere text editor.
I'll agree that sometimes having extra power available is key to performing some tasks. A lot of the time the extra 'power' is also very superficial and can hinder if the dev doesn't understand that it is very limited.
What you think is shitty and what I think is shitty are two different things.
There is no "my IDE" nor is there a place for personal preference over productivity
That's a very power-freak way of doing things. If you enforce rules like that then you're asking for trouble. I've worked in a few places now and I can tell you that the places that enforce those kind of rules almost never get very far.
In fact, the second-last job I was at was haemorrhaging people for exactly that reason. They went from 40 devs to 10 in the space of 12 months and couldn't find decent replacements because word got around that they sucked.
As I say, there's ways of standardising the environment without forcing everyone to use tools that they don't like day in, day out.
Don't dismiss a tool without knowledge. Ide's have come a long way since vc++ 6...
I've tried a stack of tools and I always come back to the simplest ones because they're the ones that piss off into the background and let you do your job.
That said, VC6 had a nice debugger in it; I guess you need a good debugger when you're working with Windows...
When you have disparate IDEs and you want to add to the java path for a certain project and you show how to do it in one IDE,
And when you're tied to an IDE you're tied to devs who are comfortable and you're also relying on the fact that it will continue doing what you need it to do from now and until forever.
It's not really that hard to standardise a build/dev environment. A set of required packages installed. A set of required BASH scripts installed and bashrc (or whatever) login settings installed at the system level.
If your build is managed by Makefiles then there's no need for everyone to use your choice of shitty IDE when they can all use the tools that work best in the situations they need.
Believe it or not, most of the pioneering work in computing was done with line-based editors and console-mode tools. I wouldn't be too quick to dismiss them when talented devs are working with them.
Slashdot Mirror
The real answer to your problem is use a secure protocol like SSH which does everything you just asked for natively.
Does it encrypt and sign the files one-by-one so that the admin of the remote site (who you don't trust) can't read, alter or share them on you?
Whenever a nonsigning inventor gives a reason for refusing to sign the application oath or declaration, that reason should be stated in the petition.
Check the bloody law
Read the fucking link you posted, twonk. If I refuse to sign a patent application and also state a reason for refusal to sign then the company must petition the PTO and state that reason.
If this reason is noting (moral, don't like the patent, don't want my name out there, etc) then there would be little argument. If the reason is more substantial (I believe there is prior art, that the patent was obvious, etc) then the PTO has grounds to refuse the patent application.
While they don't need my permission, they do need to make every attempt to get it, and if I refuse they do need to tell the PTO why. Hell, if they fudge it I could go and tell the PTO why.
If you refuse to sign
And if you refuse to sign (and are not dead) the patent office will (hopefully) like to know why. I can see it being a common thing and there could be some pretty valid legal/moral reasons for refusing to sign a patent application.
The reason patents was introduced was to make the information public and allow for others to benefit from the discovery if they get a proper licens or work in a completly diffrent field.
The thing is, until it's patented it's not disclosed- therefore it's a trade secret.
Make an anonymous posting somewhere, describing the innovation you came up with. If it has been disseminated before, it cannot be patented.
The problem with doing that is if the invention is not obvious and has paved the way for considerable financial gain then the company can probably trace it back to you through court orders for information; regardless of how anonymous you thought you were at the time.
It _IS_ a breach of your contract to release trade secrets outside of the company you work for. It's a pretty much standard clause in every employment contract. If it is traced back to you there could be loss of job, litigation, and possibly criminal charges depending on the severity that your company puts on the matter.
The do need to list the inventors by name, even if the patent belongs to a company. IIRC they do need to list your name on the patent, and that requires your consent/signature.
I agree with trying to convince the boss to see reason. You'll likely not succeed though.
It sounds like the usual bunch of suits trying to fluff up the value of their company with things that have little meaning and that they know very little about (patents pending that may or may not rejected later) before they flog it off and get rich.
...until they force this trusted all your spying are on done by us computing on us by legislation.
Then it gets really hard, although I guess not technically impossible.
Hmns a good analogy is: encrypt all my stuff give the cryptfile and keyfiles to my friends as a backup. I wonder if they're going to open it up and read it... um...
And maybe a new Windows update took care of the bots installed on some machines and the spammers had to spend time cracking the new Windows to get their bots to work again?
*grumble* collect
In Nigeria
Were you delivering or trying to colled my$47,463,678,456 US?
Flash photography damages the exhibits by exposing exhibits to excessive UV light.
And most people use cheap 'instamatic' point and shoot pieces of shit with a flash. Even a lot of tossers with good quality (read: expensive) kit don't know how to use it. They only have it to look like they're rich.
You can really understand why they ban photography in places like museums, libraries, etc. I've taken lots of photos in our local museum and was never hassled. I also did it with the flash deactivated. While I was snapping away your average strobelight joe schmuck was being asked to stop.
Getting offtopic for a minute (just because I want to have a rant), I was talking to the guys at work today. They are a bunch of well educated guys. Not one of them saw a problem with government CCTV, net monitoring, banning photography or anything like that. They all argued that "if you're not doing anything wrong then why not embrace it to let them make us safe from those terrists".
Why are people so fucking apathetic about these things? Today it's one small thing. Tomorrow another. In a few years what would seem like a big loss now seems insignificant and they take that too. Before you know it all your rights will be gone and we'll all be loving Orwell (or whatever they actually name 'big brother').
your wiki measures you!
I suggest a new strategy, let the Wiki win!
Silent Bob would do it so much cooler. He's use his mum's vibrator and some chicken wire and shit.
So that makes that you are stuck with FTP
wget --mirror?
LFTP's scripted system allows mirroring the backup and only getting files that have changed. With some server-side scripting to dump database diffs it wouldn't be hard to make a FTP backup solution that only downloaded changed files.
rdiff-backup makes incremental diffs of individual files, which saves a lot of space for large files which have small changes like database backups, virtual machine images, and large mailspools.
And rsync with the link-dest option uses hard links, which occupy exactly the space for the inode they are using and no more.
A diff is a small file which occupies a small amount of space on your disk - a non-zero sized file will occupy at least 4k depending on the size of your file system.
Hard links use up a single inode and no more. Why mess about with diffs when you can change into a directory and see yesterday's backup? Don't like yesterdays? Change into another and see the day before that. The depth is limited by the number of inodes you have in your filesystem / number of inodes used in filesystem being backed up.
Mantis looks OK but I prefer something that doesn't need quite as much work to integrate :)
Redmine and Trac both just accept a repository path and bam - integration. Redmine does a bit of a messy with the repo by reading all the changeset information the first time you connect it to the repo though; that can take a long time if it's a well-established repo.
Tortise isn't an issue tracker, it's a front end to Subversion. The OP wants an issue tracker (Think Trac, Bugzilla, Redmine, etc) which is a different beast.
We've been using Trac for a long time and it worked well.
We since discovered Redmine which does about the same job, is themed prettier and seems to be a bit easier to use. All in all Trac and Redmine both do about the same things.
Redmine has a built-in user management, which I'm taking advantage of in our SVN/Hg web server to authenticate users with (single sign on)
Redmine also has support for multiple projects in one tracker, whereas trac needs multiple installs for multiple disjointed projects. The workflow manager in Redmine is also really easy to use; no dicking about writing python scripts to control your workflow.
Redmine talks to Svn, Git, Mercurial, Bazzar and a couple of other source control tools, which is useful if you ever need to move on to those tools. Trac is pretty rooted on subversion, though it does have a Git plugin.
Both are pretty easy to install, but I had Redmine up and running in about 4 minutes whereas it took a bit of messing about to get Trac running.
Redmine also has the manager friendly theme (think that horrible facebook style) so managers will goo and gaa over it then sign off that it be implemented.
Really? Like, everywhere in the world
I wouldn't be surprised!
My first (memorable) program was written with my dad on the C64. He's not a programmer, but we got a C64 when I was about 4 or 5 and I was keen to know all there was to know about it.
He started reading magazines and got some books that taught him the basics then we'd spend time together building basic (pun intended) things. The first one that did anything memorable was a christmas tree on the screen complete with a flashing light on the top.
It was all downhill from there. Once the basics are in place more and more advanced things follow. Soon you've outgrown your interpreted language and are sitting at the machine level to make it do things fast enough.
Of course, back then it was all very easy. The 8-bit machines only had a handful of opcodes and a small amount of unmanaged memory (well the C64 had a ROM bank that you could cut out if you needed the RAM it shadowed). To make graphics it was a simple matter of poking in a few registers and then writing to the graphics memory directly.
There was no pesky OS or memory management getting in your way. The machine also wasn't very fast, so to do cool things you had to learn about interrupt driven events, 'multi tasking', and designing for optimisation from the start.
These days learning programming like that is nigh-on impossible. The OS hides the machine from you and presents a not-so-neat interface to all the hardware. The machine is fast so there is never any real desire to optimise and programmers aren't learning good principles for it.
If the GP's teenage son is really interested in learning programming perhaps a small microcontroller project would be a good place to start. PICs and AVR cores are quite simple to implement and program. Investigate a development kit instead of diving into programming the PC.
An IDE with good code browsing tools is much better than a mere text editor.
I'll agree that sometimes having extra power available is key to performing some tasks. A lot of the time the extra 'power' is also very superficial and can hinder if the dev doesn't understand that it is very limited.
If there's evidence the IDE is "shitty",
What you think is shitty and what I think is shitty are two different things.
There is no "my IDE" nor is there a place for personal preference over productivity
That's a very power-freak way of doing things. If you enforce rules like that then you're asking for trouble. I've worked in a few places now and I can tell you that the places that enforce those kind of rules almost never get very far.
In fact, the second-last job I was at was haemorrhaging people for exactly that reason. They went from 40 devs to 10 in the space of 12 months and couldn't find decent replacements because word got around that they sucked.
As I say, there's ways of standardising the environment without forcing everyone to use tools that they don't like day in, day out.
Don't dismiss a tool without knowledge. Ide's have come a long way since vc++ 6...
I've tried a stack of tools and I always come back to the simplest ones because they're the ones that piss off into the background and let you do your job.
That said, VC6 had a nice debugger in it; I guess you need a good debugger when you're working with Windows...
When you have disparate IDEs and you want to add to the java path for a certain project and you show how to do it in one IDE,
And when you're tied to an IDE you're tied to devs who are comfortable and you're also relying on the fact that it will continue doing what you need it to do from now and until forever.
It's not really that hard to standardise a build/dev environment. A set of required packages installed. A set of required BASH scripts installed and bashrc (or whatever) login settings installed at the system level.
If your build is managed by Makefiles then there's no need for everyone to use your choice of shitty IDE when they can all use the tools that work best in the situations they need.
Believe it or not, most of the pioneering work in computing was done with line-based editors and console-mode tools. I wouldn't be too quick to dismiss them when talented devs are working with them.