don't let the ineptitude of the USPO let you think that ALL patents are bad.
We are taking the narrow position that all software patents are bad. If you think otherwise, then would you please name a few good software patents? --
I am a Canadian citizen, but I live in Europe, and I have not only signed the petition (without apology) but I have taken the initiative to explain in very simple, clear terms to every government official I can get hold of just exactly how much the open-source initiative in Europe would be hurt should the current attempts to legalize software patents be successful. The flip side of the argument is of course to emphasize how many billions of Euros Europeans can expect to pay in tribute to Redmond should the open source initiative be derailed. I think this small PR campaign of mine has already had some effect, and I'm encouraged. Linux conferences tend to be a very good place to corral and communicate with government officials, as they are keeping an attentive eye on the Linux movement at the moment, and at least in Germany, have announced official support. The Linux Kongress this year was addressed the deputy minister of Education. I explained to her that the one thing the German government could do to help Linux more than anything else is to ensure that software patents stay illegal in Europe. Actually, I was surprised that she didn't already know this - it seemed like news to her, but she took it very seriously. It shows the value of simple communication.
The other thing I'm doing is encouraging the Linux company I work for to make their own voice heard in government circles, where the viewpoints of self-interested lawyers, certain U.S.software companies, and associated astroturfers are already more than adequately represented.
What can you do if you're not European and you're not in Europe? Write about it - everywhere. Make sure everybody in U.S. and Canada knows about what we are fighting for in Europe, and how that can come back to benefit ordinary citizens in all counties (by weakening the U.S. software patent system, resulting in lower software prices and faster innovation). If you come across some useful information, forward it to somebody you know in Europe. Talk to Europeans. Stay in contact, keeping talking about it. Email or write by snail mail to EU government officials stating how much you admire the sensible efforts to keep software patents illegal in Europe, and how much you wish your own government showed as much sense.
If you are Canadian, get hold of your MP *now* - write a letter - and ask what Canada is doing to make software patents illegal again, the way they were before. Canada in particular stands to suffer from software patents, and if Canada takes a stand it would not be the first time. Perhaps your MP just doesn't understand how much Canadian money is being exported *now* because of software patents. --
I somehow got on ITWorld's Linux spam list and have not been able to get off. They give you a web site along with their spam that has a form that doesn't work. Sending 'unsubscribe' to the supplied email address doesn't work. I suspect they just use the email hit, like any common spammer, to verify that you haven't just blocked them. Currently anything that comes into my mailbox with ITWorld or LinuxWorld goes straight to/dev/null, and I'm one unhappy puppy in this regard. --
Unexpected power-off is NOT the only thing which can happen to a filesystem. What about these disasters?
1) Bad block takes out part of your disk unexpectedly.
2) Your OS screws up and spews a mess onto your filesystem before it crashes. (there ARE bugs in the kernel!)
3) You have a minor headcrash which takes out one of your tracks, but the disk is still functional.
What're you gonna do? Tux2 isn't gonna help you.
You could restore your latest dump. You could
also attempt to repair the filesystem.
Yes, sure, in this case you want to run fsck to attempt a repair. Tux2 places a little extra information (one byte) in each inode to help fsck put things back together after such a disaster. After normal loss of power, intentional or otherwise there is no need to do fsck, any more than you would do a surface scan on your hard disk. Paranoia is a reason, I suppose. The point is, it's your choice. --
The only
reason that the metaroot has to be cloned and updated now is that the allocation table is linked there.
And because Tux2 aims to give you consistency that extends across files, so you want to be able to represent a filesystem state by just the metaroot. The possibility does exist to save a few blocks per phase by relaxing this and allowing subtree modifications... but... I'd see it more as an experimental kind of thing you could try after the basic atomic update is in place and solid, then you'd see how much you actually save. I'm thinking about these kinds of things too, and nice analysis by the way. --
Furthermore, should others report a bug before I suffer data loss, I can revert to plain old boring ext2 by just editing my fstab. Now that is a feature you
don't get with other journaling fs (ext3? I'm not sure).
Going from ext2 to tux2 is easy, as you know. Going back is harder because some of the metadata will have moved to non-traditional locations. Turning it back into ext2 requires a filesystem defrag to puts all the metadata (e.g., inode table) back into its original locations. For Tux2 this is an easy and safe operation, but you may have to wait a while before you see it because getting the basic reliable updating working, tested and benchmarked is more important. You'll see this feature before version 1.0 comes out but not in the first developer versions. --
With this game, grassroots Linux gaming has entered the big league. Oh, and don't forget Parsec. And a *lot* of others on the way. Check out crystal space. How long before we have an open source game to rival half life or unreal? (John Carmack is *already* open source so I don't count him:)
--
PROPERLY GRANTED patents allow people who thought up a new idea and put much effort and money into making it practical to protect their investment
by giving them a monopoly for a limited time. It also encourages inventors to make their inventions public knowledge rather than keeping them secret, so
other people can build on them (although you might have to negotiate a license fee or wait for the first patent to expire before you can put it into
production).// Not that either point is a justification for the one-click patent...
It doesn't work. The little guy *can't afford* to get a patent properly granted. The more 'properly' a patent is granted, the more the little guy can't afford it. Nothing about the patent system is working as it was intended to, and it never will. It's time for it do die, die, die.
Oh, and by the way, people build on ideas just fine without the help of the patent system. Better in fact, because they can put all their energy into their creative work and get it done sooner, so they can get famous sooner. Plus they get to *use* the other ideas when they build. Much easier to build on something than to have to completely reinvent it every time.
I just have one question: do you really *believe* that myth about the lone inventor, or are you just a cynical astroturfer? --
I recently made a posting to the linux-kernel list describing a situation caused by the patent system that is rather unfair to me, and to the entire open source community. While writing the post, I suddenly succumbed to the urge to add a rant about patents. Here's an excerpt:
Let me state my position on patents:
Patents are evil
Software patents are especially evil
Patents, and especially software patents, constitute nothing less
than government-sponsored theft of property that properly belongs
to humanity.
If we did not have any form of patent, humanity would be better
off.
If we did not have any form of patent, the world economy would
benefit. Yes, that means corporations too.
If we did not have any form of patent, *most voters would
benefit* <-- pay close attention to this one
Patents are anti-capitalist: they interfere with the proper
functioning of the market economy. Patents on business methods
are already rearing their ugly head.
It's getting worse. If the current trend continues, you will
soon see the life of patents being extended, you will see
patents being granted in areas that were previously considered
off-limits, and you will see countries outside the U.S. being
pressured into supporting the patent system in various ways.
We can't change the world overnight, but we do already possess
the power, if we excercise it, to send the laws that gave birth
to software patents back into the cesspool they crawled out of.
In spite of the popular myth about the lone inventor who strikes
it rich, the only real beneficiaries of patents are corporations.
Yes, a few lone inventors strike it rich, but not enough to undo
the damage done to humanity in general. Most lone inventors just
get ripped off by people who prey on them and their dreams.
If all patents were to vanish today and never come back research
in general would accelerate, not slow down. Linux is proof of
that.
Lawyers built the patent system. Tim O'Rielly once asked a
patent lawyer how he would feel if other lawyers could patent
legal arguments and charge him money to use those arguments in
court. Though he tried to twist out of answering that one,
eventually he had to admit that he had no answer. This lawyer
IIRC is the director of the U.S. Trade and Patent office.
tux2fs probably *will*
take more memory (substantially more?) than ext2 or a journaling filesystem, but with the amount of memory that most systems have available for file
cache, I doubt that is a problem.
I've analyzed that question and I think tux2 will only use a little more cache memory, not a lot more, and it could even be less - see below. Tux2 uses per-block copy-on-write, and when the old version of a block won't be used any more (the normal case) that means you can just change the disk block number in the buffer - no extra memory used at all. The only time extra memory is used is when a file block is written over and over again, every 10th of a second or so - then you will sometimes get two copies of it in memory at the same time. The first copy will disappear as soon as it finishes being transfered to disk. This kind of writing pattern is rare with normal data but is common with metadata. Fortunately metadata is about.1% of the total in a filesystem. My guess is you won't notice any extra load on the buffer cache.
In fact, I think Tux2 will take a load off the buffer/page cache because it doesn't let dirty data hang around a long time - it starts writing to disk a fraction of a second after you start writing to a file. My plan is to have Tux2 shorten its phase length under heavy memory pressure, so the space needed for dirty buffers will drop down to just 100-200K, and you'll still get good performance.
Cache memory for reading under Tux2 is the same as Ext2 and most other filesystems.
--
I'm curious...does anyone know how much more RAM/CPU Tux2/ReiserFS/... need over and beyond Ext2?
I wrote about RAM in another article - Tux2 won't use a lot more, and because of its ability to throttle the dirty cache, could use significantly less than we're used to.
As for CPU - I haven't really noticed a big difference vs Ext2 but I'm not in real-world testing situations yet. The only CPU intensive thing Tux2 does is make extra trips into the block allocation bitmaps. There are roughly zero extra trips the first time you write a file, and 100% extra trips if you rewrite the file without truncating it first - actually, a pretty rare thing to do. A database might do it though, and for that case I'll provide a per-file disable of the copy-on-write - the metadata will still be protected but the database will be responsible for doing its own crash recovery for the file data, which most databases do pretty well. In fact, the phase tree algorithm started life in a database. --
Slashdot Mirror
Nonsense - of course you can, unless you live in a very broken country.
--
We are taking the narrow position that all software patents are bad. If you think otherwise, then would you please name a few good software patents?
--
The other thing I'm doing is encouraging the Linux company I work for to make their own voice heard in government circles, where the viewpoints of self-interested lawyers, certain U.S.software companies, and associated astroturfers are already more than adequately represented.
What can you do if you're not European and you're not in Europe? Write about it - everywhere. Make sure everybody in U.S. and Canada knows about what we are fighting for in Europe, and how that can come back to benefit ordinary citizens in all counties (by weakening the U.S. software patent system, resulting in lower software prices and faster innovation). If you come across some useful information, forward it to somebody you know in Europe. Talk to Europeans. Stay in contact, keeping talking about it. Email or write by snail mail to EU government officials stating how much you admire the sensible efforts to keep software patents illegal in Europe, and how much you wish your own government showed as much sense.
If you are Canadian, get hold of your MP *now* - write a letter - and ask what Canada is doing to make software patents illegal again, the way they were before. Canada in particular stands to suffer from software patents, and if Canada takes a stand it would not be the first time. Perhaps your MP just doesn't understand how much Canadian money is being exported *now* because of software patents.
--
I somehow got on ITWorld's Linux spam list and have not been able to get off. They give you a web site along with their spam that has a form that doesn't work. Sending 'unsubscribe' to the supplied email address doesn't work. I suspect they just use the email hit, like any common spammer, to verify that you haven't just blocked them. Currently anything that comes into my mailbox with ITWorld or LinuxWorld goes straight to /dev/null, and I'm one unhappy puppy in this regard.
--
1) Bad block takes out part of your disk unexpectedly.
2) Your OS screws up and spews a mess onto your filesystem before it crashes. (there ARE bugs in the kernel!)
3) You have a minor headcrash which takes out one of your tracks, but the disk is still functional.
What're you gonna do? Tux2 isn't gonna help you.
You could restore your latest dump. You could also attempt to repair the filesystem.
Yes, sure, in this case you want to run fsck to attempt a repair. Tux2 places a little extra information (one byte) in each inode to help fsck put things back together after such a disaster. After normal loss of power, intentional or otherwise there is no need to do fsck, any more than you would do a surface scan on your hard disk. Paranoia is a reason, I suppose. The point is, it's your choice.
--
And because Tux2 aims to give you consistency that extends across files, so you want to be able to represent a filesystem state by just the metaroot. The possibility does exist to save a few blocks per phase by relaxing this and allowing subtree modifications... but... I'd see it more as an experimental kind of thing you could try after the basic atomic update is in place and solid, then you'd see how much you actually save. I'm thinking about these kinds of things too, and nice analysis by the way.
--
Going from ext2 to tux2 is easy, as you know. Going back is harder because some of the metadata will have moved to non-traditional locations. Turning it back into ext2 requires a filesystem defrag to puts all the metadata (e.g., inode table) back into its original locations. For Tux2 this is an easy and safe operation, but you may have to wait a while before you see it because getting the basic reliable updating working, tested and benchmarked is more important. You'll see this feature before version 1.0 comes out but not in the first developer versions.
--
With this game, grassroots Linux gaming has entered the big league. Oh, and don't forget Parsec. And a *lot* of others on the way. Check out crystal space. How long before we have an open source game to rival half life or unreal? (John Carmack is *already* open source so I don't count him:)
--
PROPERLY GRANTED patents allow people who thought up a new idea and put much effort and money into making it practical to protect their investment by giving them a monopoly for a limited time. It also encourages inventors to make their inventions public knowledge rather than keeping them secret, so other people can build on them (although you might have to negotiate a license fee or wait for the first patent to expire before you can put it into production). // Not that either point is a justification for the one-click patent...
It doesn't work. The little guy *can't afford* to get a patent properly granted. The more 'properly' a patent is granted, the more the little guy can't afford it. Nothing about the patent system is working as it was intended to, and it never will. It's time for it do die, die, die.
Oh, and by the way, people build on ideas just fine without the help of the patent system. Better in fact, because they can put all their energy into their creative work and get it done sooner, so they can get famous sooner. Plus they get to *use* the other ideas when they build. Much easier to build on something than to have to completely reinvent it every time.
I just have one question: do you really *believe* that myth about the lone inventor, or are you just a cynical astroturfer?
--
Let me state my position on patents: Here is my original linux-kernel posting and if you find this subject really interesting, here is the entire thread You'll be amazed what happens.
--
tux2fs probably *will* take more memory (substantially more?) than ext2 or a journaling filesystem, but with the amount of memory that most systems have available for file cache, I doubt that is a problem.
.1% of the total in a filesystem. My guess is you won't notice any extra load on the buffer cache.
I've analyzed that question and I think tux2 will only use a little more cache memory, not a lot more, and it could even be less - see below. Tux2 uses per-block copy-on-write, and when the old version of a block won't be used any more (the normal case) that means you can just change the disk block number in the buffer - no extra memory used at all. The only time extra memory is used is when a file block is written over and over again, every 10th of a second or so - then you will sometimes get two copies of it in memory at the same time. The first copy will disappear as soon as it finishes being transfered to disk. This kind of writing pattern is rare with normal data but is common with metadata. Fortunately metadata is about
In fact, I think Tux2 will take a load off the buffer/page cache because it doesn't let dirty data hang around a long time - it starts writing to disk a fraction of a second after you start writing to a file. My plan is to have Tux2 shorten its phase length under heavy memory pressure, so the space needed for dirty buffers will drop down to just 100-200K, and you'll still get good performance.
Cache memory for reading under Tux2 is the same as Ext2 and most other filesystems.
--
I'm curious...does anyone know how much more RAM/CPU Tux2/ReiserFS/... need over and beyond Ext2?
I wrote about RAM in another article - Tux2 won't use a lot more, and because of its ability to throttle the dirty cache, could use significantly less than we're used to.
As for CPU - I haven't really noticed a big difference vs Ext2 but I'm not in real-world testing situations yet. The only CPU intensive thing Tux2 does is make extra trips into the block allocation bitmaps. There are roughly zero extra trips the first time you write a file, and 100% extra trips if you rewrite the file without truncating it first - actually, a pretty rare thing to do. A database might do it though, and for that case I'll provide a per-file disable of the copy-on-write - the metadata will still be protected but the database will be responsible for doing its own crash recovery for the file data, which most databases do pretty well. In fact, the phase tree algorithm started life in a database.
--