Folks, if you're going to be sneaky, at least do enough research to make sure you're really being sneaky.
Yes, but how do we know this wasn't intentional? Maybe the employee in charge of the redacting wanted that part of the memo to get out, so he deliberately redacted improperly.
Not at all. That law does not require that any works be deposited with copyright libraries; it simply allows the minister to make regulations which would specify which works did, or did not, need to be deposited.
Now, trusting ministers to make sensible decisions (eg, requiring that peer-reviewed e-journals be deposited, not requiring that web sites be deposited) may be hopelessly optimistic, but the law isn't completely absurd.
because you know, the concept of people selling to other people is obviously a new one
Patents do not cover *concepts*; patents cover *methods*. This patent does not concern the concept of people selling to other people; it covers a method of people selling to other people.
Now, I'm inclined to say that the patent is still likely to be bogus, but we should critique it for the right reasons.
Hmm... strictly speaking, every copyrighted work should be deposited with the Briitish Library, Bodleian Library (Oxford), Cambridge University Library, National Library of Scotland, Library of Trinity College Dublin and the National Library of Wales.
The only problem is that not everyone will trust you -- you seem like a decent guy to me:) -- so having it rolled into the official FreeBSD Project stuff would make it perfect.
That's exactly one of the reasons I don't want it as part of the project yet. Right now, quite independent of the issue of trusting the *person* building updates, people have to trust the *machine* building updates -- which isn't exactly an ideal situation. Of course, people trust the root CVS repository, but that's something which can be verified; it's hard to verify binaries.
Something I will be working on is the ability to have several machines independently building updates and verifying each other's updates; the update client would then refuse to install any updates unless they were signed by (for example) 18 out of the 20 update-building boxes.
Hrm, that's useful, but it still requires a machine for applying patches and rebuilding. Not sure if that guy offers the resulting binaries -- whatever the case, it'd be so much better to have them distributed via FreeBSD's main site and FTP mirrors.
I publish binary updates for 4.7-RELEASE and 4.8-RELEASE right now. I will be publishing updates for 4.9-RELEASE as well, and also 5.x RELEASES once I get some new hardware.
This will be integrated into FreeBSD more fully in the future (included in base, updates built and distributed by the project), but there are some improvements I want to make first.
Got a source to back that up? (Eg a description of such an algorithm
Ok, here's a description of the algorithm: 1. Chop the (old) file into pieces. 2. Work out appoximately where those pieces go. 3. Fill in any holes and correct any errors from step 2.
Of course, that isn't incredibly useful -- but I can't explain any further without, well, writing a ten page paper about this. Be patient, wait for the paper, and all will become clear.
It isn't. The edit distance D is equal to I+S -- rsync uses a factor of k more bandwidth than necessary for dealing with isolated substitutions.
You're saying that substitutions can be done in constant bandwith inpendent of the file size?!
Well... there's actually a factor of log(n/S) which I omitted. And the n/k is actually n/k log(n) (for both algorithms). But keeping track of logarithmic factors gets a bit silly -- people like to assume that they can perform things like address operations in constant time (which isn't really true).
Where is the 'n/k' bandwidth going to? Is that protocol overhead?
The n/k is used to transmit block checksums, in order to identify which parts of the file need to be transmitted (the kD).
You would really be "entitled" to bash rsync if you had come up with a superior implementation yourself, but I would hope you could at least point one out.
I come from an academic background, where it's perfectly acceptable to bash someone based on theory.
Yes, the code is coming. But it takes time to write; give me a few months, ok?
Nice to know that so many are compelled to avoid their profs long enough to something useful
I don't see the connection. Samba isn't useful because Andrew didn't want to do any real work at the time -- Samba is useful because Andrew's a skilled programmer. Rsync (even with its flaws) is far more important than Samba.
Likewise, I put together FreeBSD Update (see.sig) while I was avoiding doing any real work; but my real work is going to be far more important than FreeBSD Update in the end.
Rsync is overrated. It's useful for files with local edits (eg, text and source code), but performs poorly on files which tend to have global, sparse, changes (eg, most data files, and all executables). Changing one character will result in an entire block being transmitted -- put another way, the bandwidth usage is O(n/k+kD), where n is the file size, D is the edit distance, and k is a parameter (the block size).
This is considerably worse than necessary; it is possible to cut the bandwidth down to O(n/k+kI+S), where n,k are as above, I is the number of inserts/deletes, and S is the number of substitutions. For executable files, this can easily result in a fivefold improvement.
Rsync is certainly a useful tool, but it isn't the synchronization-tool-to-end- all-synchronization-tools which many people consider it to be.
(Side note: I have the same DPhil supervisor as Andrew Tridgell, so I feel perfectly entitled to bash my fellow student's work.)
Those are normally design patents, not utility patents -- they don't stop other people making a product which uses the same principles to achieve the same effect, but instead restrict people from making products which look the same.
Ok, so ldd tells you that all your applications use libc (what a surprise). Readelf tells you that the functions which were patched aren't called directly by your application.
Oops. Library functions can call other library functions. How do you identify if the functions touched by a patch are called indirectly by any given application?
Often it is better to spend an extra 10 minutes planning and save a minute or two on downtime.
Ok, you've got 10 minutes to plan. Which of your services use the foo_bar library call from libc?
No, let's be generous: You've got *two weeks* to plan, and the entire readership of the freebsd-security mailing list. Which system binaries use the xdr_mem calls from libc? (This is a real example; nobody had any clue until I did a recompile-and-compare.)
if your server needs 50 services running to work at all, then restarting them all one at a time means that the server is not down for any continuous period of time
If your server needs 50 services running in order to work at all, then restarting them one at a time means that your server is down for a *long* time. Ok, maybe not a long *continuous* period of time, but the total downtime would be considerably longer than if you restart them all simultaneously.
Exactly. You don't *need* to reboot, but unless you know exactly what library calls all of your application software makes -- which is generally not possible even if you wrote the software yourself -- you'll need to restart everything.
And if you're going to restart all the processes running on a machine... why not just reboot?
Ah. Now your inexperience in the *nix world shines through. There IS no guessing. Upgrade apache, restart the apache service (httpd.. maybe slightly confusing..). Upgrade mysql, restart mysqld.
Are you sure about that? I know that some paper is produced using pulp from old growth forests; but I thought that was just because there's lots of small bits and pieces left over (after the large pieces of lumber have been cut) which can't be used for anything else.
Well, the USA came in close second on the "weasely countries" list; I imagine that Jacques Chirac would have garnered more votes if many Americans had been able to recognize his name.
I've had several people offer me access to their boxes; but that really isn't useful. When people run FreeBSD Update, they're running blind -- there isn't any way for them to verify that I haven't inserted a trojan into the "updates" I publish.
The updates are signed, of course -- with my public key -- but in order for that to be any use I have to be building the updates on a system which is secure. Using a system, to which I only have remote access, offered by someone I don't know, doesn't qualify as "secure".:)
Slashdot Mirror
Folks, if you're going to be sneaky, at least do enough research to make sure you're really being sneaky.
Yes, but how do we know this wasn't intentional? Maybe the employee in charge of the redacting wanted that part of the memo to get out, so he deliberately redacted improperly.
Or maybe that's just what he wants us to think...
My immediate reaction was "yes, all version control systems suck, but was subversion really bad enough to arrest someone over?"
s/modera/edi/
Not at all. That law does not require that any works be deposited with copyright libraries; it simply allows the minister to make regulations which would specify which works did, or did not, need to be deposited.
Now, trusting ministers to make sensible decisions (eg, requiring that peer-reviewed e-journals be deposited, not requiring that web sites be deposited) may be hopelessly optimistic, but the law isn't completely absurd.
because you know, the concept of people selling to other people is obviously a new one
Patents do not cover *concepts*; patents cover *methods*. This patent does not concern the concept of people selling to other people; it covers a method of people selling to other people.
Now, I'm inclined to say that the patent is still likely to be bogus, but we should critique it for the right reasons.
You see half-naked women? Where?
Hmm... strictly speaking, every copyrighted work should be deposited with the Briitish Library, Bodleian Library (Oxford), Cambridge University Library, National Library of Scotland, Library of Trinity College Dublin and the National Library of Wales.
I believe that only applies to *printed* works.
The only problem is that not everyone will trust you -- you seem like a decent guy to me :) -- so having it rolled into the official FreeBSD Project stuff would make it perfect.
That's exactly one of the reasons I don't want it as part of the project yet. Right now, quite independent of the issue of trusting the *person* building updates, people have to trust the *machine* building updates -- which isn't exactly an ideal situation. Of course, people trust the root CVS repository, but that's something which can be verified; it's hard to verify binaries.
Something I will be working on is the ability to have several machines independently building updates and verifying each other's updates; the update client would then refuse to install any updates unless they were signed by (for example) 18 out of the 20 update-building boxes.
Hrm, that's useful, but it still requires a machine for applying patches and rebuilding. Not sure if that guy offers the resulting binaries -- whatever the case, it'd be so much better to have them distributed via FreeBSD's main site and FTP mirrors.
I publish binary updates for 4.7-RELEASE and 4.8-RELEASE right now. I will be publishing updates for 4.9-RELEASE as well, and also 5.x RELEASES once I get some new hardware.
This will be integrated into FreeBSD more fully in the future (included in base, updates built and distributed by the project), but there are some improvements I want to make first.
Or, more usefully: FreeBSD Update, which is also in the FreeBSD ports tree (security/freebsd-update).
Got a source to back that up? (Eg a description of such an algorithm
Ok, here's a description of the algorithm:
1. Chop the (old) file into pieces.
2. Work out appoximately where those pieces go.
3. Fill in any holes and correct any errors from step 2.
Of course, that isn't incredibly useful -- but I can't explain any further without, well, writing a ten page paper about this. Be patient, wait for the paper, and all will become clear.
Could you explain why 'kD=kI+S'?
It isn't. The edit distance D is equal to I+S -- rsync uses a factor of k more bandwidth than necessary for dealing with isolated substitutions.
You're saying that substitutions can be done in constant bandwith inpendent of the file size?!
Well... there's actually a factor of log(n/S) which I omitted. And the n/k is actually n/k log(n) (for both algorithms). But keeping track of logarithmic factors gets a bit silly -- people like to assume that they can perform things like address operations in constant time (which isn't really true).
Where is the 'n/k' bandwidth going to? Is that protocol overhead?
The n/k is used to transmit block checksums, in order to identify which parts of the file need to be transmitted (the kD).
You would really be "entitled" to bash rsync if you had come up with a superior implementation yourself, but I would hope you could at least point one out.
I come from an academic background, where it's perfectly acceptable to bash someone based on theory.
Yes, the code is coming. But it takes time to write; give me a few months, ok?
Nice to know that so many are compelled to avoid their profs long enough to something useful
.sig) while I was avoiding doing any real work; but my real work is going to be far more important than FreeBSD Update in the end.
I don't see the connection. Samba isn't useful because Andrew didn't want to do any real work at the time -- Samba is useful because Andrew's a skilled programmer. Rsync (even with its flaws) is far more important than Samba.
Likewise, I put together FreeBSD Update (see
Rsync is overrated. It's useful for files with local edits (eg, text and source code), but performs poorly on files which tend to have global, sparse, changes (eg, most data files, and all executables). Changing one character will result in an entire block being transmitted -- put another way, the bandwidth usage is O(n/k+kD), where n is the file size, D is the edit distance, and k is a parameter (the block size).
This is considerably worse than necessary; it is possible to cut the bandwidth down to O(n/k+kI+S), where n,k are as above, I is the number of inserts/deletes, and S is the number of substitutions. For executable files, this can easily result in a fivefold improvement.
Rsync is certainly a useful tool, but it isn't the synchronization-tool-to-end- all-synchronization-tools which many people consider it to be.
(Side note: I have the same DPhil supervisor as Andrew Tridgell, so I feel perfectly entitled to bash my fellow student's work.)
Those are normally design patents, not utility patents -- they don't stop other people making a product which uses the same principles to achieve the same effect, but instead restrict people from making products which look the same.
Ok, so ldd tells you that all your applications use libc (what a surprise). Readelf tells you that the functions which were patched aren't called directly by your application.
Oops. Library functions can call other library functions. How do you identify if the functions touched by a patch are called indirectly by any given application?
Often it is better to spend an extra 10 minutes planning and save a minute or two on downtime.
Ok, you've got 10 minutes to plan. Which of your services use the foo_bar library call from libc?
No, let's be generous: You've got *two weeks* to plan, and the entire readership of the freebsd-security mailing list. Which system binaries use the xdr_mem calls from libc? (This is a real example; nobody had any clue until I did a recompile-and-compare.)
if your server needs 50 services running to work at all, then restarting them all one at a time means that the server is not down for any continuous period of time
If your server needs 50 services running in order to work at all, then restarting them one at a time means that your server is down for a *long* time. Ok, maybe not a long *continuous* period of time, but the total downtime would be considerably longer than if you restart them all simultaneously.
Exactly. You don't *need* to reboot, but unless you know exactly what library calls all of your application software makes -- which is generally not possible even if you wrote the software yourself -- you'll need to restart everything.
And if you're going to restart all the processes running on a machine... why not just reboot?
But sometimes I just have faith that the Debian Developers know what they are doing.
Do you have enough faith to login as root via unencrypted telnet? Probably not.
So why do you have enough faith to download patches using a protocol which completely lacks cryptographic security?
Ah. Now your inexperience in the *nix world shines through. There IS no guessing. Upgrade apache, restart the apache service (httpd .. maybe slightly confusing..). Upgrade mysql, restart mysqld.
I just upgraded libc. What do I have to restart?
Old growth logging for paper does occur in BC
Are you sure about that? I know that some paper is produced using pulp from old growth forests; but I thought that was just because there's lots of small bits and pieces left over (after the large pieces of lumber have been cut) which can't be used for anything else.
Well, the USA came in close second on the "weasely countries" list; I imagine that Jacques Chirac would have garnered more votes if many Americans had been able to recognize his name.
I've had several people offer me access to their boxes; but that really isn't useful. When people run FreeBSD Update, they're running blind -- there isn't any way for them to verify that I haven't inserted a trojan into the "updates" I publish.
:)
The updates are signed, of course -- with my public key -- but in order for that to be any use I have to be building the updates on a system which is secure. Using a system, to which I only have remote access, offered by someone I don't know, doesn't qualify as "secure".
The problem with not calling it GNU/Linux is that it's more GNU than Linux.
True, but most distributions are also more Mozilla, X, and several other things, than they are GNU.
Should we be referring to RedHat Mozilla/XFree86/GNOME/emacs/BSD/GNU/Linux?