The Sistina way does work. Aladdin (the Ghostscript people) have been using it for years. The only difference is that they didn't behave in a sneaky way.
Raph Levien, the current Ghostscript maintainer, has a variety of rants and rambles about this very topic in his diary.
The Linux makefiles use the "-pipe" flag to gcc. This causes gcc to pre-process, compile and assemble in parallel, using pipes rather than temporary files. Thus, a straight "make" of a kernel already uses multiple CPUs if available (though in a pretty minimal way).
Minor nit (only politeness (oops) prevents me from decrying the preceding (parent) post as utter nonsense):
Hashing isn't really constant time. It's still logarithmic
Not at all. Under favourable circumstances, hash insertion and searching can be logarithmic. But, in terms of complexity, such tasks didn't get any easier. In the worst case, hashing and insertion are exactly the same as a linear list. In those worst cases, they transform trivially to a linear search.
Matthew - Who dealt with this shit for too long to let this one slip past.
From what I know of WAFL (the Netapp filesystem) snapshots should have been a fairly easy thing to implement.
WAFL is a "write anywhere" filesystem. Greatly simplified, this essentially means that when a disk write (don't confuse this with a filesystem write, which will usually be cached and not hit disk for a while) occurs, the newly written block will be written in the free block nearest to the current disk-head position.
When the transaction is complete (be it a write, a file extension, or whatever) the original data block (which will be located elsewhere on disk) will be released.
When your filesystem works that way, you already have a lot of code which deals with the possibility that block N of a file may be written in multiple locations. From there, it's not unusually difficult to handle the case that block X on disk may hold data for multiple files. (The cases really aren't as independant as you might think.)
So, rather than returning obsoleted blocks to the pool of available blocks immediately, a copy-on-write strategy is used to hold chosen versions around without wasting enormous amounts of space with copies or (more importantly) I/O bandwidth with copying.
There was a thread on the reiserfs list about copy-on-write a while ago (prompted by the silly "Microsoft invents symlinks" article here). Hans Reiser has said that he would like have efficient copy-on-write for reiserfs, though it's not a priority. He has also said in the past that what he calls a "wandering log" (which will boil down to the same thing as write-anywhere) is fairly high up the TODO list for reiserfs.
Don't expect to see this sort of stuff done well on top of a traditional Unix filesystem like FFS or ext2, though. Even with journalling, ext2 is, I think, too far from the requirements of this sort of thing to provide a useful base.
Peter Braam (one of the Coda guys) and some others are working on a new distributed filesystem called InterMezzo. Its intention is to provide Coda's features, but utilise the features (ie. journalling) and performance (cf. reiserfs) of the local filesystem on both the server and client.
It is my hope that it will prove a lot better integrated with Linux(-based GNU systems:-) than Coda. If it fulfills it promise, I have at least a hundred machines which I am looking to install it on.
In my last job at a small ISP, one of our clients got shut down for a barbie parody.
I managed to retrieve a few of the images from my cache (they're at http://ferret.lmh.ox.ac.uk/~weejock/barbie/) but the rest of the site is basically lost an gone forever.
We would have fought it, but we didn't have the money or the time to, so the site got taken down. Shame really, as I found it rather amusing.
There are huge parts of the Linux kernel that were "borrowed" from one or another of the BSDs, and now find themselves under the GPL.
That is simply not true. Yes, there is the odd bit, but there were never any "huge parts". The old ipfwadm code is the closest to an example, and that has been replaced (twice!) now.
I suspect that there will be the odd ex-BSD driver, especially in the non-i386 ports, but otherwise, I think that your claim is rude.
I have the beginnings of a small toy IDS, which can detect some of the uglier and more problematic packets that you might have the misfortune to see floating around your network (things like land, the common Winnuke exploits).
Once I have IP fragment/TCP reassembly done (this may be done off-line) it may actually be quite useful.
Drop me an email if you want to play with it.
Alternatively, the Netfilter stuff in recent 2.3 kernels provides a very interesting way to do a lot of the filtering in kernelspace, saving an awful lot of copying and latency.
As usual, it's a controversial point, but the way I see it, were Linux to share Java's fate, it would mean that it is seen as a useful, if not fully proven technology, that the world is prepared to evaluate dispassionately and use only if it suits them, which sounds fine to me...
Would you really prefer a bunch of stupid corporations to jump on Linux the way that hundreds of others have jumped on Windows?
Matthew - not a Java fan, but not a probably detractor either
Follow anything like this to conclusion, and you will just convince yourself even further that the crypto export/import/usage laws are thoroughly ridiculous.
I always thought that law was somewhat like a mathematical proof, where legislators attempted to capture their intention elegantly, and without holes.
It seems that reductio ad absurdum doesn't really apply in this case, though.
Why not just post "there's another editorial on Daemon News"? We know what it's going to say.
Just because the article didn't rant, rave or curse, doesn't make it "Well written". It's just more of the usual FUD (yes, I do mean FUD).
I don't think the author made a point or claim (true or otherwise) that hadn't been made dozens of times before.
His claim that NetBSD runs on more architectures than any other OS may be true, but only just, and unless I am much mistaken, Linux is roughly at parity on CPUs.
Linux has real, portable SMP. I don't believe that the SMP in NetBSD or FreeBSD comes even close, for performance or platform support. I'm willing to be proved wrong, but I don't believe that any free BSD even has kernel threading support. The people who know about such things freely admit that Linux' networking is better (if not by much).
NetBSD rocks. OpenBSD rocks. FreeBSD probably rocks though, unlike the others, it doesn't fill a niche that Linux doesn't (for me).
I don't feel the need to slag off their work. I don't even abuse BSD users:-). Should rants like this article really be acceptable just because they come from a minority standpoint?
Unless I missed something, these "secure audio" formats weren't cracked.
Rather, someone found a way to bypass them, and extract them to some other, non-protected, format.
Ask any cryptographer if pgp has been cracked because Unix provides a ptrace(2) interface. Even Windows provides a usable debugging interface. By extension surely all copy protection on these has been cracked.
This is why the DVD people have put entensive restrictions on implementations, particularly in software.
I'm not in favour of any of these so-called secure formats, because I think that they represent a rather extensive missing-of-the-point, but I see no evidence that the technology (specifically the mathematics) behind them has been "cracked" or otherwise broken.
Matthew.
Re:Variants would make nice gateway/firewall/route
on
Linux on a SIMM
·
· Score: 1
Does anyone know if the processor could handle a 100baseT connection?
Not a chance. I'd be surprised if it could saturate 10bT, let alone 100.
I'm looking forward to setting one up as a dialup router, though...
I'm with you on this one, though maybe for different reasons.
I really don't believe that Eric Raymond represents us (for almost any value of "us" you might care to choose). He seems like an OK guy, but it's increasingly obvious that he has lost track of what we (well, I) thought he was doing - representing us - and is now doing something very different - preaching to us.
Slashdot Mirror
The Sistina way does work. Aladdin (the Ghostscript people) have been using it for years. The only difference is that they didn't behave in a sneaky way.
Raph Levien, the current Ghostscript maintainer, has a variety of rants and rambles about this very topic in his diary.
Sheep? Between foot-and-mouth and slashdot, there are none left for Microsoft.
The Linux makefiles use the "-pipe" flag to gcc. This causes gcc to pre-process, compile and assemble in parallel, using pipes rather than temporary files. Thus, a straight "make" of a kernel already uses multiple CPUs if available (though in a pretty minimal way).
Minor nit (only politeness (oops) prevents me from decrying the preceding (parent) post as utter nonsense):
Not at all. Under favourable circumstances, hash insertion and searching can be logarithmic. But, in terms of complexity, such tasks didn't get any easier. In the worst case, hashing and insertion are exactly the same as a linear list. In those worst cases, they transform trivially to a linear search.
Matthew
- Who dealt with this shit for too long to let this one slip past.
Pi was pretentious tat.
I quite liked the soundtrack, but the acting, script and direction were all way, way overdone.
Don't get me wrong, I don't mind the odd arty film, but I don't think Pi had much to offer.
Never mind, it's not as if I would have gone to see the Batman film anyway :-)
Matthew.WAFL is a "write anywhere" filesystem. Greatly simplified, this essentially means that when a disk write (don't confuse this with a filesystem write, which will usually be cached and not hit disk for a while) occurs, the newly written block will be written in the free block nearest to the current disk-head position.
When the transaction is complete (be it a write, a file extension, or whatever) the original data block (which will be located elsewhere on disk) will be released.
When your filesystem works that way, you already have a lot of code which deals with the possibility that block N of a file may be written in multiple locations. From there, it's not unusually difficult to handle the case that block X on disk may hold data for multiple files. (The cases really aren't as independant as you might think.)
So, rather than returning obsoleted blocks to the pool of available blocks immediately, a copy-on-write strategy is used to hold chosen versions around without wasting enormous amounts of space with copies or (more importantly) I/O bandwidth with copying.
There was a thread on the reiserfs list about copy-on-write a while ago (prompted by the silly "Microsoft invents symlinks" article here). Hans Reiser has said that he would like have efficient copy-on-write for reiserfs, though it's not a priority. He has also said in the past that what he calls a "wandering log" (which will boil down to the same thing as write-anywhere) is fairly high up the TODO list for reiserfs.
Don't expect to see this sort of stuff done well on top of a traditional Unix filesystem like FFS or ext2, though. Even with journalling, ext2 is, I think, too far from the requirements of this sort of thing to provide a useful base.
Matthew.
It is my hope that it will prove a lot better integrated with Linux(-based GNU systems :-) than Coda. If it fulfills it promise, I have at least a hundred machines which I am looking to install it on.
Matthew.
I managed to retrieve a few of the images from my cache (they're at http://ferret.lmh.ox.ac.uk/~weejock/barbie/) but the rest of the site is basically lost an gone forever.
We would have fought it, but we didn't have the money or the time to, so the site got taken down. Shame really, as I found it rather amusing.
Matthew.
That is simply not true. Yes, there is the odd bit, but there were never any "huge parts". The old ipfwadm code is the closest to an example, and that has been replaced (twice!) now.
I suspect that there will be the odd ex-BSD driver, especially in the non-i386 ports, but otherwise, I think that your claim is rude.
Matthew.
The original works OK under dosemu, but I could never get accelerated 3D that way...
Matthew.
bang sounds better to me on Unix, though.
Of course, the correct pronunciation of #! is shebang..
Matthew.
In fact, I don't think it's even close.
Matthew.
Once I have IP fragment/TCP reassembly done (this may be done off-line) it may actually be quite useful.
Drop me an email if you want to play with it.
Alternatively, the Netfilter stuff in recent 2.3 kernels provides a very interesting way to do a lot of the filtering in kernelspace, saving an awful lot of copying and latency.
Matthew.
I guess we now have all the more incentive to hack on Dia, then.
Matthew.
Matthew.
Their web site looks rather stale (over a year since the last obvious update) but they're exactly the kind of business that you're talking about.
Matthew.
Would you really prefer a bunch of stupid corporations to jump on Linux the way that hundreds of others have jumped on Windows?
Matthew
- not a Java fan, but not a probably detractor either
I always thought that law was somewhat like a mathematical proof, where legislators attempted to capture their intention elegantly, and without holes.
It seems that reductio ad absurdum doesn't really apply in this case, though.
Matthew.
Just because the article didn't rant, rave or curse, doesn't make it "Well written". It's just more of the usual FUD (yes, I do mean FUD).
I don't think the author made a point or claim (true or otherwise) that hadn't been made dozens of times before.
His claim that NetBSD runs on more architectures than any other OS may be true, but only just, and unless I am much mistaken, Linux is roughly at parity on CPUs.
Linux has real, portable SMP. I don't believe that the SMP in NetBSD or FreeBSD comes even close, for performance or platform support. I'm willing to be proved wrong, but I don't believe that any free BSD even has kernel threading support. The people who know about such things freely admit that Linux' networking is better (if not by much).
NetBSD rocks. OpenBSD rocks. FreeBSD probably rocks though, unlike the others, it doesn't fill a niche that Linux doesn't (for me).
I don't feel the need to slag off their work. I don't even abuse BSD users :-). Should rants like this article really be acceptable just because they come from a minority standpoint?
Matthew.
Rather, someone found a way to bypass them, and extract them to some other, non-protected, format.
Ask any cryptographer if pgp has been cracked because Unix provides a ptrace(2) interface. Even Windows provides a usable debugging interface. By extension surely all copy protection on these has been cracked.
This is why the DVD people have put entensive restrictions on implementations, particularly in software.
I'm not in favour of any of these so-called secure formats, because I think that they represent a rather extensive missing-of-the-point, but I see no evidence that the technology (specifically the mathematics) behind them has been "cracked" or otherwise broken.
Matthew.
I'm looking forward to setting one up as a dialup router, though...
Matthew.
Why is X a User Interface? It sounds much more like an API to me..
Matthew.
I really don't believe that Eric Raymond represents us (for almost any value of "us" you might care to choose). He seems like an OK guy, but it's increasingly obvious that he has lost track of what we (well, I) thought he was doing - representing us - and is now doing something very different - preaching to us.
Matthew.
Matthew.