Let's get some email addresses of state assembly members, PUC members, the gubernatorial candidates, etc., list them on slashdot, and I bet just a few tens of thousands of emails will get us some action.....
What a bank considers an ID confirmation is just pathetic. I mean, come one, Mother's maiden name when every other bank also uses it? 4 digit pin codes?
They belong back in the 19th century!
We need to task the NSA, or a DARPA project, or any serious professional, with coming up with a secure banking id system, one that meets serious security standards, and just get the damn problem fixed. I think that if you picked any code breaker at random and gave him the task, he'd come up with something a hell of a lot better than what we got. If you held a nice contest, it would come out really nice.
If we got some modern crypto-spooks involved, if we could get to where the KGB had to sweat even a little to crack our identity system, identity theft would be a crime very few could give a try. Just try reading a few books about what the KGB and CIA have to do to crack each other's security, and then compare that to mother's maiden name and social security number.
That is the solution.
As a minor improvement, all credit cards should be required by law to have photos on them that were supplied by the government, and verified to be the unique current registered photo for that id.
All transactions not serious crypto-verified should be illegal to report to a credit agency.
UPS is bad. Don't use UPS for anything more fragile than a book.
At least half the boxes that come to my house through UPS have visible damage on the outside, box seams busted from squishing, etc. Their employees just don't care.
You need to do a spreadsheet with a budget, but list only the Principal Investigator by name, that way if someone quits, everything is still fine. List people by job name not real name.
Accounting requires someone capable of real math or experienced, preferably both, because you need to calculate indirect costs and read about what is unbillable, etc. Take the accounting very seriously, any carelessness or worse will get you into real trouble (including legal prosecution if it is more than carelessness), and the auditors tend to know just where you are likely to screw things up (after a few decades of auditing academics they become good at that). Supervise all timesheets carefully at the end of the month, people WILL bill time to the wrong project. The usual pattern is for them to switch activities but continue to bill to the same project for reasons of thought conservation.
Review your expenses every 30 days, this is usually required, and it is a good idea, because after 30 days things get harder to remember....
Be terse and concise in your proposal if you can, they like that. If your proposal is half the max length, they won't be complaining....
Working for DARPA was a very positive experience, except for the accounting (nobody's fault, proper accounting is a lot of work), and the clerks who are supposed to send the checks (they waste enormous amounts of senior management time, and Congress jerks the funding around also, make sure you are very conservative about your cash flow). Still, it was great to work for them, and we learned from them (they are rather expert in computer security).
www.namesys.com/whitepaper.html describes why the relational model is not the right one for large heterogeneous stores (filesystems), and describes the approach ReiserFS (a Linux filesystem used mostly in Europe) is taking instead.
Hans
I think project IRIS from MIT is more interesting
on
DNSSEC: Good Enough?
·
· Score: 4, Informative
Time for ICANN to be obsoleted by a nice DARPA funded project from MIT and Berkeley. The guys working on it are pretty bright, and DNS is what distributed hash tables are best for.
I get reports (not verified by me) that ReiserFS V3 is an order of magnitude faster when used as a backend for an XML database than relational databases that were tried. So, if your data happens to have a hierarchical structure, or, you can put it into one, then you are likely to get a performance gain. If your data does not have a hierarchical structure, then you need to wait for V6 where we plan to expand the semantics.
If you want to be able to "cat filenameX/..owner" to see who owns "filenameX", you need to use V4.
If you are using metadata journaling, then a file that you are in the middle of writing to when it crashes can have garbage added to it. Note that Unix filesystems have had this feature since the days of FFS and UFS. Use data-journaling if you find that unacceptable. ReiserFS V3 supports both data-journaling and meta-data journaling now.
Be warned though, that all fixed location journals double the transfer time cost of performing writes because the data must first be written to the journal, and then written somewhere else. This is why we don't make data journaling the default in v3. Trust me, full data journaling would have been far easier to code first than meta data journaling, but it isn't in the interest of the 'average' user.
Now V4 is an atomic filesystem, which is much better than data journaling, because it means that all filesystem operations are performed fully atomically. Your write syscall either fully happens or it does not. Applications can have multiple filesystem operations performed atomically. We do this without writing the data twice through use of a technique called wandering logs, which I describe in a posting below (and on our website).
The difference between us and an LSF is that we perform well BEFORE you run the repacker, and we merely perform even better after you run it. LSF's required that you run the repacker to get good read performance, we don't. V4 kicks V3's butt without the repacker by a lot (due to dancing trees, allocate on flush, extents, and ending the use of BLOBS, among other things). With the repacker, it will just kick it harder.
Our approach synthesizes a lot of approaches, rather than considering one technique to be the answer to everything. This makes our performance more robust, as the different approaches each cover over each other's lackings. There are some situations in which using a repacker is higher performance than making lots of little changes while constantly maintaining optimal allocation of files.
It is important that you use a distro that bases their kernel on 2.4.18, or later, when using ReiserFS. There exists a distro that bases their enterprise server kernel on 2.4.9, and intentionally declines to add any reiserfs bugfixes since then. (This is the same distro that once shipped their kernel with the ReiserFS debugging code turned on so that we would go slow.) Do NOT use their kernel with ReiserFS. Generally when someone reports that they are having really bad experiences with ReiserFS, it turns out they are using that kernel.
I generally recommend using the latest official kernel from Marcelo, and not any distro kernels, but the SuSE kernels tend to have effective ReiserFS support also, and not everyone out there shares my non-technical preference for a common community developed kernel.
Re:"but you won't need to fsck"
on
Reiser4 Benchmarks
·
· Score: 5, Informative
That was V3. V4 is an atomic filesystem, which means that every filesystem operation is performed as a fully atomic transaction. This is more secure than the guarantees of data journaling, as data journaling doesn't necessarily guarantee that the write will complete.
The reason we are able to do this in V4 but not in V3 is that V4 uses what I call wandering logs. With wandering logs, instead of copying data first to the journal, and then after commit copying it from the journal to the rest of the filesystem, (thereby writing the data twice), we just change our definition of where the journal is. I don't think that data journaling is worth going half-speed for most users. With V4, we not only don't go half-speed, we go faster than V3 ever went.
These are the names of the two dogs that were sent into outerspace by Russia.
Re:I don't understand the statistics
on
Reiser4 Benchmarks
·
· Score: 5, Informative
The script that creates the comparison tables divides the other filesystems by the base filesystem. The problem is that Reiser4 was used as the base filesystem in one of the benchmarks, but not the other. So in one benchmark, green is good, and the other benchmark, red is good.
I would have fixed this before posting to lkml, but I had to catch a plane, sorry about that.
No, V4 is not backward compatible with V3. V3 and V4 are kept as separate codebases so that the new V4 features don't destabilize V3. We are very serious about avoiding adding new features to V3, so that it can become a zero defect product.
However, there is a tool called convertfs (as well as tar) which can convert V3 to V4. It can also convert ext2 to V3 or V4 or V3 or V4 to ext2. It is pretty clever (and written by someone outside our team), in that it creates a loop back mounted target filesystem inside a file inside the source filesystem, copies everything from the source to the target, and then reshuffles the blocks of the file so that they are at the offsets on the device that they were at within the file.
In regards to attributes on attributes, some (regular unix plugin ) files have relationships to other files that are implemented using stat data plugins, but the stat data files don't have stat data themselves. There are lots of specific plugin implementation details, but it works without infinite recursion problems
It should be optional which files are backed up. Now the interesting question is, what should the interface for that be? For instance, should only one version be maintained until you do the first commit, then two versions until you do the second commit?
Or, alternatively, should one specify that for a particular file every write creates a new version, or that every close creates a new version, or is there a place for all three approaches, depending on the user's needs?
I don't think it is possible to configure ReiserFS wrongly and to lose data as the above suggests. What is very possible is to use it with the wrong kernel and obsolete utilities. If you use ReiserFS with RedHat, get an OFFICIAL kernel from Marcelo, not a redhat kernel, and get the latest utilities off of our website.
I would take a guess that the users complaining about losing data are redhat kernel users and the ones that are happy are SuSE or official kernel users. When you compare stability of ReiserFS and ext3, try to compare them using the same version of the official kernel. We have generally been more stable than ext3 in the official kernels at any given moment in time, in large part because we were about 6 months ahead of them in the development cycle. Remember that RedHat does not tend to keep up with ReiserFS updates in its nonofficial kernels.
Recent RedHat kernels are probably much more stable than the old ones because they have bugfixes from more recent official kernels, but remember that these are the guys who in one of their releases compiled reiserfs with debugging turned on to make it slower than ext3, so I would go with an official kernel if it was me.
V3 of reiserfs is very stable currently. We go for months without bug reports and we have a lot of users in Europe. This is in large part because we put all our new features into V4. V4 will be unstable for quite some time.
Avoiding deadlock, dealing with transaction timeouts, controlling permissions on who can keep a transaction open for how long, these are all very serious issues that have us first making transactions available to plugins and trusted processes only in the first release. However, there is a LOT you can do with just plugins and trusted processes to make user data more secure.
Take a look at www.namesys.com/v4/reiser4_the_atomic_fs.html
and at www.namesys.com/v4/v4.html.
We will be adding support for semi-structured data querying in the next major release, assuming that we find funding for it. The semantics for it are described at www.namesys.com/whitepaper.html, which also explains why I don't think the relational model is effective for semi-structured data stores such as a general purpose filesystem is normally used for.
Ego is surely not the only motivation for writing free software, but it is the one that we as a community can make more effective as a motivation. Not everyone contributes to charity for the sake of fame, but respecting those who perform charity is a good thing for society to do even when reputation is not sufficient to make the charitable act worthwhile.
There is a definable difference between credits and ads. Credits describe how someone contributed. Ads attempt to sell something other than the program.
Credits are the clearly good part of what the entertainment industry does. Ads are the evil they found necessary, or at least the evil they desired, and maybe we won't share it with them. I personally would rather pay than be advertised to: my time is expensive. I don't mind watching credits, somehow I respect them enough to not mind them.
This "People First" posting above describes the poetic foundation of a belief that I share, and it does a lot to convey why the members of this discussion disagree.
I don't agree with the bottom part of what he writes though, when he says that most of the good ideas have been found in CS, rather I think that ideas multiply, and the more ideas have been found, the more ideas can be found.
For a long time I have found it irritating that they talk about hypotheses like the big bang "theory" with the pretence that they have even the slightest idea what is going on.
With this new evidence, they still have no clue what the universe is up to as a whole. The whole thing was just an exercise in speculation no more informed than the Bible. It still is. It will remain that way for a very long time.
Just accept it, you are a bunch of pretentious hairless mutant monkeys living on an insignificant speck of dirt, and the universe isn't interested in bothering to tell you what is going on, and you are never going to figure it out in your lifetime.
Well, folks, if you don't like this, then try the following. Take your Dell computer that is 3 years old. Tell Dell that you don't accept the EULA on the security patch from MS that gives them sysadmin rights to your machine. Tell them that you want a full refund on their machine because they won't provide you with technical support for any OS other than Windows, and Windows without security patches is not what you agreed to buy, and a computer without technical support is useless. Then, when they refuse, sue them in small claims court in a state that protects consumer rights (e.g. California). In a state small claims court a consumer typically does a lot better than in a federal court.
Chances of winning might be pretty good actually, when you consider that you were not told that you must agree to give MS sysadmin rights on your computer at the time of sale, and conditioning security patches on such agreement constitutes a change in the agreement made after the sale, thus voiding the sale agreement.
I think I am going to give this a try when I get back to the US. I'll let you all know if it works.
The beauty of it is that if it threatens to put Dell out of business, they sue MS. Remember, you don't have standing to sue MS yourself over the security patch EULA, thanks to our wondrous Supreme Court and their Illinois Brick decision.
(I am really pissed at Dell for telling me everytime my dual boot system has a hardware problem visible under both OSes (which is ever since I bought it) that they won't support me unless I remove Linux and install pure Windows. Never let Dell sales folks convince your company that Dell computers are suitable for a mixed Linux and Windows environment. Avoid them like the plague for Linux.)
Slashdot Mirror
Let's get some email addresses of state assembly members, PUC members, the gubernatorial candidates, etc., list them on slashdot, and I bet just a few tens of thousands of emails will get us some action.....
What a bank considers an ID confirmation is just pathetic. I mean, come one, Mother's maiden name when every other bank also uses it? 4 digit pin codes?
They belong back in the 19th century!
We need to task the NSA, or a DARPA project, or any serious professional, with coming up with a secure banking id system, one that meets serious security standards, and just get the damn problem fixed. I think that if you picked any code breaker at random and gave him the task, he'd come up with something a hell of a lot better than what we got. If you held a nice contest, it would come out really nice.
If we got some modern crypto-spooks involved, if we could get to where the KGB had to sweat even a little to crack our identity system, identity theft would be a crime very few could give a try. Just try reading a few books about what the KGB and CIA have to do to crack each other's security, and then compare that to mother's maiden name and social security number.
That is the solution.
As a minor improvement, all credit cards should be required by law to have photos on them that were supplied by the government, and verified to be the unique current registered photo for that id.
All transactions not serious crypto-verified should be illegal to report to a credit agency.
UPS is bad. Don't use UPS for anything more fragile than a book.
At least half the boxes that come to my house through UPS have visible damage on the outside, box seams busted from squishing, etc. Their employees just don't care.
They usually have a proposal information booklet.
You need to do a spreadsheet with a budget, but list only the Principal Investigator by name, that way if someone quits, everything is still fine. List people by job name not real name.
Accounting requires someone capable of real math or experienced, preferably both, because you need to calculate indirect costs and read about what is unbillable, etc. Take the accounting very seriously, any carelessness or worse will get you into real trouble (including legal prosecution if it is more than carelessness), and the auditors tend to know just where you are likely to screw things up (after a few decades of auditing academics they become good at that). Supervise all timesheets carefully at the end of the month, people WILL bill time to the wrong project. The usual pattern is for them to switch activities but continue to bill to the same project for reasons of thought conservation.
Review your expenses every 30 days, this is usually required, and it is a good idea, because after 30 days things get harder to remember....
Be terse and concise in your proposal if you can, they like that. If your proposal is half the max length, they won't be complaining....
Working for DARPA was a very positive experience, except for the accounting (nobody's fault, proper accounting is a lot of work), and the clerks who are supposed to send the checks (they waste enormous amounts of senior management time, and Congress jerks the funding around also, make sure you are very conservative about your cash flow). Still, it was great to work for them, and we learned from them (they are rather expert in computer security).
www.namesys.com/whitepaper.html describes why the relational model is not the right one for large heterogeneous stores (filesystems), and describes the approach ReiserFS (a Linux filesystem used mostly in Europe) is taking instead.
Hans
Time for ICANN to be obsoleted by a nice DARPA funded project from MIT and Berkeley. The guys working on it are pretty bright, and DNS is what distributed hash tables are best for.
You can find it at IRIS
I get reports (not verified by me) that ReiserFS V3 is an order of magnitude faster when used as a backend for an XML database than relational databases that were tried. So, if your data happens to have a hierarchical structure, or, you can put it into one, then you are likely to get a performance gain. If your data does not have a hierarchical structure, then you need to wait for V6 where we plan to expand the semantics.
If you want to be able to "cat filenameX/..owner" to see who owns "filenameX", you need to use V4.
If you are using metadata journaling, then a file that you are in the middle of writing to when it crashes can have garbage added to it. Note that Unix filesystems have had this feature since the days of FFS and UFS. Use data-journaling if you find that unacceptable. ReiserFS V3 supports both data-journaling and meta-data journaling now.
Be warned though, that all fixed location journals double the transfer time cost of performing writes because the data must first be written to the journal, and then written somewhere else. This is why we don't make data journaling the default in v3. Trust me, full data journaling would have been far easier to code first than meta data journaling, but it isn't in the interest of the 'average' user.
Now V4 is an atomic filesystem, which is much better than data journaling, because it means that all filesystem operations are performed fully atomically. Your write syscall either fully happens or it does not. Applications can have multiple filesystem operations performed atomically. We do this without writing the data twice through use of a technique called wandering logs, which I describe in a posting below (and on our website).
The difference between us and an LSF is that we perform well BEFORE you run the repacker, and we merely perform even better after you run it. LSF's required that you run the repacker to get good read performance, we don't. V4 kicks V3's butt without the repacker by a lot (due to dancing trees, allocate on flush, extents, and ending the use of BLOBS, among other things). With the repacker, it will just kick it harder.
Our approach synthesizes a lot of approaches, rather than considering one technique to be the answer to everything. This makes our performance more robust, as the different approaches each cover over each other's lackings. There are some situations in which using a repacker is higher performance than making lots of little changes while constantly maintaining optimal allocation of files.
The repacker will be ready in a few weeks.
It is important that you use a distro that bases their kernel on 2.4.18, or later, when using ReiserFS. There exists a distro that bases their enterprise server kernel on 2.4.9, and intentionally declines to add any reiserfs bugfixes since then. (This is the same distro that once shipped their kernel with the ReiserFS debugging code turned on so that we would go slow.) Do NOT use their kernel with ReiserFS. Generally when someone reports that they are having really bad experiences with ReiserFS, it turns out they are using that kernel.
I generally recommend using the latest official kernel from Marcelo, and not any distro kernels, but the SuSE kernels tend to have effective ReiserFS support also, and not everyone out there shares my non-technical preference for a common community developed kernel.
That was V3. V4 is an atomic filesystem, which means that every filesystem operation is performed as a fully atomic transaction. This is more secure than the guarantees of data journaling, as data journaling doesn't necessarily guarantee that the write will complete.
The reason we are able to do this in V4 but not in V3 is that V4 uses what I call wandering logs. With wandering logs, instead of copying data first to the journal, and then after commit copying it from the journal to the rest of the filesystem, (thereby writing the data twice), we just change our definition of where the journal is. I don't think that data journaling is worth going half-speed for most users. With V4, we not only don't go half-speed, we go faster than V3 ever went.
For more details, please take a look at http:www.namesys.com/v4/v4.html
These are the names of the two dogs that were sent into outerspace by Russia.
The script that creates the comparison tables divides the other filesystems by the base filesystem. The problem is that Reiser4 was used as the base filesystem in one of the benchmarks, but not the other. So in one benchmark, green is good, and the other benchmark, red is good.
I would have fixed this before posting to lkml, but I had to catch a plane, sorry about that.
No, V4 is not backward compatible with V3. V3 and V4 are kept as separate codebases so that the new V4 features don't destabilize V3. We are very serious about avoiding adding new features to V3, so that it can become a zero defect product.
However, there is a tool called convertfs (as well as tar) which can convert V3 to V4. It can also convert ext2 to V3 or V4 or V3 or V4 to ext2. It is pretty clever (and written by someone outside our team), in that it creates a loop back mounted target filesystem inside a file inside the source filesystem, copies everything from the source to the target, and then reshuffles the blocks of the file so that they are at the offsets on the device that they were at within the file.
No, it is not a toy, it is a style convention.
In regards to attributes on attributes, some (regular unix plugin ) files have relationships to other files that are implemented using stat data plugins, but the stat data files don't have stat data themselves. There are lots of specific plugin implementation details, but it works without infinite recursion problems
They got funded to develop a PKI infrastructure with real verification of identity for the EU.
It should be optional which files are backed up. Now the interesting question is, what should the interface for that be? For instance, should only one version be maintained until you do the first commit, then two versions until you do the second commit?
Or, alternatively, should one specify that for a particular file every write creates a new version, or that every close creates a new version, or is there a place for all three approaches, depending on the user's needs?
I don't think it is possible to configure ReiserFS wrongly and to lose data as the above suggests. What is very possible is to use it with the wrong kernel and obsolete utilities. If you use ReiserFS with RedHat, get an OFFICIAL kernel from Marcelo, not a redhat kernel, and get the latest utilities off of our website.
I would take a guess that the users complaining about losing data are redhat kernel users and the ones that are happy are SuSE or official kernel users. When you compare stability of ReiserFS and ext3, try to compare them using the same version of the official kernel. We have generally been more stable than ext3 in the official kernels at any given moment in time, in large part because we were about 6 months ahead of them in the development cycle. Remember that RedHat does not tend to keep up with ReiserFS updates in its nonofficial kernels.
Recent RedHat kernels are probably much more stable than the old ones because they have bugfixes from more recent official kernels, but remember that these are the guys who in one of their releases compiled reiserfs with debugging turned on to make it slower than ext3, so I would go with an official kernel if it was me.
V3 of reiserfs is very stable currently. We go for months without bug reports and we have a lot of users in Europe. This is in large part because we put all our new features into V4. V4 will be unstable for quite some time.
Avoiding deadlock, dealing with transaction timeouts, controlling permissions on who can keep a transaction open for how long, these are all very serious issues that have us first making transactions available to plugins and trusted processes only in the first release. However, there is a LOT you can do with just plugins and trusted processes to make user data more secure.
Take a look at www.namesys.com/v4/reiser4_the_atomic_fs.html
and at www.namesys.com/v4/v4.html.
We will be adding support for semi-structured data querying in the next major release, assuming that we find funding for it. The semantics for it are described at www.namesys.com/whitepaper.html, which also explains why I don't think the relational model is effective for semi-structured data stores such as a general purpose filesystem is normally used for.
Best,
Hans
Ego is surely not the only motivation for writing free software, but it is the one that we as a community can make more effective as a motivation. Not everyone contributes to charity for the sake of fame, but respecting those who perform charity is a good thing for society to do even when reputation is not sufficient to make the charitable act worthwhile.
There is a definable difference between credits and ads. Credits describe how someone contributed. Ads attempt to sell something other than the program.
Credits are the clearly good part of what the entertainment industry does. Ads are the evil they found necessary, or at least the evil they desired, and maybe we won't share it with them. I personally would rather pay than be advertised to: my time is expensive. I don't mind watching credits, somehow I respect them enough to not mind them.
This "People First" posting above describes the poetic foundation of a belief that I share, and it does a lot to convey why the members of this discussion disagree.
I don't agree with the bottom part of what he writes though, when he says that most of the good ideas have been found in CS, rather I think that ideas multiply, and the more ideas have been found, the more ideas can be found.
Best To All,
Hans
The filesystem? There is more than one you know....;-) ReiserFS V3 is rather stable nowadays.... (V4 is still early beta code).
Hans
For a long time I have found it irritating that they talk about hypotheses like the big bang "theory" with the pretence that they have even the slightest idea what is going on.
With this new evidence, they still have no clue what the universe is up to as a whole. The whole thing was just an exercise in speculation no more informed than the Bible. It still is. It will remain that way for a very long time.
Just accept it, you are a bunch of pretentious hairless mutant monkeys living on an insignificant speck of dirt, and the universe isn't interested in bothering to tell you what is going on, and you are never going to figure it out in your lifetime.
Kind of amusing actually....
We can handle any technical problem a typical Linux kernel programmer can handle, and most of us even know Windows too.:)
Hans
Well, folks, if you don't like this, then try the following. Take your Dell computer that is 3 years old. Tell Dell that you don't accept the EULA on the security patch from MS that gives them sysadmin rights to your machine. Tell them that you want a full refund on their machine because they won't provide you with technical support for any OS other than Windows, and Windows without security patches is not what you agreed to buy, and a computer without technical support is useless. Then, when they refuse, sue them in small claims court in a state that protects consumer rights (e.g. California). In a state small claims court a consumer typically does a lot better than in a federal court.
Chances of winning might be pretty good actually, when you consider that you were not told that you must agree to give MS sysadmin rights on your computer at the time of sale, and conditioning security patches on such agreement constitutes a change in the agreement made after the sale, thus voiding the sale agreement.
I think I am going to give this a try when I get back to the US. I'll let you all know if it works.
The beauty of it is that if it threatens to put Dell out of business, they sue MS. Remember, you don't have standing to sue MS yourself over the security patch EULA, thanks to our wondrous Supreme Court and their Illinois Brick decision.
(I am really pissed at Dell for telling me everytime my dual boot system has a hardware problem visible under both OSes (which is ever since I bought it) that they won't support me unless I remove Linux and install pure Windows. Never let Dell sales folks convince your company that Dell computers are suitable for a mixed Linux and Windows environment. Avoid them like the plague for Linux.)