Jack Valenti said:
Ive seen camcorded movies that are uploaded to the Net and they are very, very watchable.
Thanks, Jack! I used to think camcorder
movies were crap, but now that I have your
personal recommendation, I'll be certain to
avoid such prejudice in the future!
Sometimes I wonder if guys like these have done
a proper analysis of the situation. Or is it
more a case of "If this works, we'll make BILLION$$$!!!" without understanding the nature of the system underlying the "If".
I was amused by this quote from the second page:
The greatest obstacle to the digital media industry is the development of a secure, online, open marketplace that protects the creator's intellectual property while rewarding a culture that supports the creation of art.
So they're saying... that their project is the
greatest obstacle to the digital media industry ?
I hate Perl. I hate interpreters. I hate pathetic attempts at object oriented behavior.
Perl OO is actually very elegant. Let's check the
three primary characteristics of OO, against Perl:
Inheritance - tick
Encapsulation - tick
Polymorphism - tick
Inheritance - How much "overhead" is there in creating a new class in perl? Almost nothing; simply set your package name and then start writing methods.
Perl takes care of inheritance, even multiple
inheritance on every method call. Since objects
are usually created as hashrefs, there's no
ambiguity about the contents of an object
which inherits from multiple parent classes.
There's no need for separating declarations and
definitions - just "use" the package names which
you need - typically only when instantiating new
members of those classes.
Encapsulation - probably perl's biggest advantage is that the hashref (associative array) is a first-class datatype in the language. There is no need for container classes, because you can store anything you like in a hashref. Hashrefs handle easily many real-world problem domains: categorisation of source data (e.g. sum by month), easy creation of data structures of arbitrary complexity, dynamic modification of said data
structures. Programmers spend less time thinking up elegant designs for linked lists or btree structures to hold data.
A hashref neatly encapsulates an object's instance data and it permits inspection. Sure it's possible to change a value inside a hashref without going through a class's setting method - but then, it's not perl's job to set the rules of object access. You set the rules yourself and you're solely responsible to follow them. Getting back to the hashrefs though, most importantly the use of hashrefs means that there is no need to to declare every single item of instance data which a class has - each class can add to and take from its instance data at will.
Polymorphism - a perl object is a reference to something, blessed into a class. Any perl code can call an object's methods without having to know anything about the class of the object. In C++ for comparison, a reference needs to be declared as some class, and only the methods defined for that class can be used on it. What if you want to pass in references to any of several classes? Well, all those classes have to have a common parent class, and only the parent class methods can be used by the code which is using the reference. What if they don't have a common parent class? Well that's tough, but there are a lot of kludges which C++ coders can use to get around the language restrictions, like casting references and templates. Perl OO has none of these design flaws - you have a reference, doesn't matter what it is, you can call its methods.
Memory management - unlike C for example, perl has automatic memory management. Storage is returned to the heap when it goes out of scope or when the last reference to it is deleted. Sure C++ has "new", but you have to know when to call "delete".
First class string support - most programs use strings a lot, and it's very convenient to have first-class string support within the language (and automatic memory management so strings can
be extended without overflowing a buffer).
First class regex support - again, very convenient, very flexible, very quick to write
Certainly perl can be used to write hideously ugly and unmaintainable code - but then it can also be used to write neat and well-structured code.
I came from a C / C++ background. I found coding OO perl to result in much more natural OO design
than was possible in C++. I could focus on designing a system of independent classes which provided functionality, and a set of interoperable classes which solved the application problem, rather than trying to fit my needs into what C++ could do, or even worse spending time trying to get around the limitations of C++. There's a reason that C++ is so devoid of public class
We fixed this, and bam, we now take nearly a hundred complaints to be blacklisted.
It doesn't sound like much of an achievement, nor something you should be
proud of. AOL still blacklists you, albeit at a higher threshold, and when it happens
you still need to do some kind of pleading with AOL to take you out of their spammer list.
Indeed; Algis Budrys published a book in the 1970s
called
Michaelmas where the protagonist communicated with his ultra-intelligent computer through subvocal speech detected by implants.
I suspect that most non-tech people believe the correct way to mend a keyboard after having (say) a can of Pepsi spilled onto it is to blow-dry it with a hairdryer.
I saw one like that a few weeks ago... keys warped by the heat, still sticky... and this was a notebook too.
The most likely long-term result (apart from IBM first grinding SCO into dust, and then grinding the dust into subatomic particles) is that Unix becomes free - either IBM will own the copyright and decline to enforce it, or Novell will own the copyright and decline to enforce it, or a judge will rule that Unix's had so many parents and so many un-named contributors that it is effectively un-copyrightable.
Net result is that Microsoft can never again use Unix as a weapon against linux.
First, they'll add DRM and continue to call it MP3 even though the file formats are incompatible. "MP3" files won't play in a traditional MP3 player.
Next, "MP3" files will be distributed widely on the P2P networks. Vendors will sell "MP3" songs. People with traditional MP3 players will never know whether an "MP3" file they are about to download is a real MP3 file or not.
The resulting confusion will send MP3 and the P2P networks into obscurity.
I beg to differ. I'm running Debian Woody on, among other things, a 486SX notebook computer (that's SX as in no math coprocessor!) with 8 megs ram and about 200 megs of hard drive.
Though it's not fast, it runs correctly and it is modern code which is being maintained for security bugs. The kernel is 2.4.24 and I can use it with my pcmcia wifi card just fine.
What you really need is a distributed, serverless filesystem -
one which lets you store files on all your disk drives on the LAN,
with automatic redundancy of data (so if a machine goes down or its
storage becomes unavailable, you still have a copy of your data
blocks on one or more of the other machines) and ability to
access those files from any machine on the LAN. A serverless filesystem
is one in which the participating machines act as peers - i.e. no
master server. Distributed and serverless filesystems are a hot
research area right now but I'm sorry to say that they're not
yet ready for the mainstream.
I went through the "is CODA right for me?" phase, and also
"is InterMezzo right for me?" and also spent tens of hours researching
distributed filesystems and cluster filesystems online... my conclusion
is that the area is still immature, I will let the pot simmer for a
few more years (hopefully not many), and use NFS with one or two
servers in the meantime.
My situation: desire for scalable and fault-tolerant distributed
filesystem for home use with minimal maintenance or balancing
effort. Emphasis on scalable - I want to be able to grow the
filesystem essentially without limit. I also don't want to
spend much time moving data between partitions. And last
but not least, the bigger the filesystem grows, the less
able I will be to back it up properly. I want redundancy so
that if a disk dies the data is mirrored onto another disk,
or if a server dies then the clients can continue to access
the filesystem through another server.
All that seems to be quite a tall order. I checked out CODA, afs, PVFS,
sgi's xfs, frangipani, petal, NFS, InterMezzo, berkeley's xfs, jfs, Sistina's
gfs and some project Microsoft is doing to build a serverless filesystem
based on a no-trust paradigm (that's quite unusual for Microsoft!).
Berkeley's xFS (now.cs.berkeley.edu/Xfs) sounded the most
promising but it appears to be a defunct project. The source code is
online however, so maybe somebody can resurrect it.
Frangipani sounds interesting also, and maybe a little more alive than xFS.
On the other hand CODA, afs, intermezzo and Lustre are all in active
development. afs IMHO suffered from kerberitis, i.e. once you
start using kerberos it invades everything and it has lots of
problems (which I read about on the openAFS list every day).
AFS doesn't support live replication either - replication is done
in a batch sense.
CODA doesn't scale and doesn't have expected filesystem
semantics. For 80 gigs of server space I would require
3.2 gigs of virtual memory, and there's a limit to the size
of a CODA directory (256k) which isn't seen in ordinary filesystems.
There's also the full-file-download "feature". CODA
is good for serving small filesystems to frequently disconnected
clients but it is not good for serving the gigabyte AVIs which I
want to share with my family.
InterMezzo is a lot more lightweight than CODA and will scale a
lot better, but it's still a mirroring system rather than a
network filesystem. I might use that to mirror my remote server
where I just want to keep the data replicated and have write access
on both the server and the client, but it's again not a solution for
my situation.
The best thing about intermezzo is that it sits on top of a regular
filesystem, so if you lose intermezzo the data is still safe in
the underlying filesystem. CODA creates its own filesystem within
files on a regular filesystem, and if you lose CODA then the data
is trapped.
Frangipani is based on sharing data blocks, so like NFS it should be
suitable for distributing files of arbitrary size. I need to look at it
in a lot more detail; this is probably the right way to build a cluster
filesystem for the long haul. For the short term, Intermezzo is probably
the right way for a lot of people: it copies files from place to place
on top of existing filesystems.
I got motivated to look at Frangipani again.
No sour
I'm a fussy pen-user even though my handwriting is terrible.
Parker pens are my preference. I've been using them since University. In particular, the Parker Frontier with the translucent plastic body and the rubberised lower third (for grip). Unlike metal-bodied pens, this pen is not cold to the touch. It looks kick-ass, isn't expensive, and is easy to hold (with the rubberised grip). And it comes with a lifetime guarantee!
I have two Frontiers - one ballpoint and one fountain. They come in a small plastic case which has fittings for both pens, the users' manual (!) and two additional fountain pen ink refills.
Ink is as important as the look and feel of the pen. Ever looked closely at ballpoint ink as the pen moves over the paper? Usually it's criss-crossed with little white lines due to ball imperfection or the ink hasn't transferred properly. That's annoying, and it looks terrible, but the Parker ink refills I use don't exhibit that problem.
The fountain pen seems to gobble up ink. I use it rarely and I have to put in a new cartridge pretty much every time I write with it. That's a sure sign that I should use the fountain pen more. It needs a new nib anyway. I've had the nib completely to pieces and it is astounding how much ink is inside.
For me, despite my appalling handwriting, the benefits of using a bit better than the typical throwaway pen are clear: I always know where my pens are; on the rare occasion I let people borrow them I make sure I get them back; the quality is better and I have a carrying case.
In situations where I can't bring my frontiers, I prefer a throwaway Papermate Flexgrip fine, because the ink is alright.
Like most I've acquired a collection of hundreds of junk pens over the years; unlike most they've been centralised into a few tins full of pens. Whenever anybody suggests buying another junk pen I merely have to shake a tin full of pens at them to drive home the point that we don't really need yet another junk pen.
I've tried most types. Rollerballs were all the rage when they were developed but I think they're worse than ballpoint - the thinner ink and lower friction on the ball emphasizes every poor writing movement. Gel ink rollers seem terrible as well. Bic style ballpoints with thick ink (particularly black ink) require a lot more pressure and - as a previous poster pointed out - tire the hand correspondingly more. Ultra-fine markers with felt tips (e.g. Pilot) are alright; certainly no worse than ballpoints despite being writing by scratching. Fountain pens are nice for making well-formed wide strokes but a bad nib (like mine) makes it scratching. Pencils, particularly clutch pencils, require more pressure - good for drawing of course, but not good for me.
Choice of paper is important too. I use unlined art diaries (double-ring bound) for permanent notes, and a tear-off pad for jotting. The art diary uses 110gsm acid-free paper, and it was chosen because it gives a good result with the fountain pen. Certain types of paper will cause the fountain pen ink to run, or too-smooth paper will mean that the ink doesn't sink into the paper enough and smudges. The double-ring bind means I can open the pages 360 degrees with no sticking. I rarely tear out pages because the book is intended for a permanent record of whatever.
The jotting pad is intended for very temporary use - by throwing away each page as soon as possible after it is written. Otherwise I'd be eventually buried in small scraps of paper.
Post-It notes are verboten here: if it's something I need to do, then it must go into my computerised todo list. If it's something I need to remember, then I have a system for that too. They're too small for effective note jotting and the adhesive on the back becomes ineffective after a few stickings. They're also a nuisance to shred.
All temporary writings are shredded before they go into the garbage. It's just basic maintenance of privacy. It's very unlikely that somebody is going through my garbage in par
Slashdot Mirror
Thanks, Jack! I used to think camcorder movies were crap, but now that I have your personal recommendation, I'll be certain to avoid such prejudice in the future!
I was amused by this quote from the second page:
So they're saying ... that their project is the
greatest obstacle to the digital media industry ?
Damn I thought that title read Artificial Pron created
Perl OO is actually very elegant. Let's check the three primary characteristics of OO, against Perl:
Inheritance - How much "overhead" is there in creating a new class in perl? Almost nothing; simply set your package name and then start writing methods. Perl takes care of inheritance, even multiple inheritance on every method call. Since objects are usually created as hashrefs, there's no ambiguity about the contents of an object which inherits from multiple parent classes.
There's no need for separating declarations and definitions - just "use" the package names which you need - typically only when instantiating new members of those classes.
Encapsulation - probably perl's biggest advantage is that the hashref (associative array) is a first-class datatype in the language. There is no need for container classes, because you can store anything you like in a hashref. Hashrefs handle easily many real-world problem domains: categorisation of source data (e.g. sum by month), easy creation of data structures of arbitrary complexity, dynamic modification of said data structures. Programmers spend less time thinking up elegant designs for linked lists or btree structures to hold data. A hashref neatly encapsulates an object's instance data and it permits inspection. Sure it's possible to change a value inside a hashref without going through a class's setting method - but then, it's not perl's job to set the rules of object access. You set the rules yourself and you're solely responsible to follow them. Getting back to the hashrefs though, most importantly the use of hashrefs means that there is no need to to declare every single item of instance data which a class has - each class can add to and take from its instance data at will.
Polymorphism - a perl object is a reference to something, blessed into a class. Any perl code can call an object's methods without having to know anything about the class of the object. In C++ for comparison, a reference needs to be declared as some class, and only the methods defined for that class can be used on it. What if you want to pass in references to any of several classes? Well, all those classes have to have a common parent class, and only the parent class methods can be used by the code which is using the reference. What if they don't have a common parent class? Well that's tough, but there are a lot of kludges which C++ coders can use to get around the language restrictions, like casting references and templates. Perl OO has none of these design flaws - you have a reference, doesn't matter what it is, you can call its methods.
Memory management - unlike C for example, perl has automatic memory management. Storage is returned to the heap when it goes out of scope or when the last reference to it is deleted. Sure C++ has "new", but you have to know when to call "delete".
First class string support - most programs use strings a lot, and it's very convenient to have first-class string support within the language (and automatic memory management so strings can be extended without overflowing a buffer).
First class regex support - again, very convenient, very flexible, very quick to write
Certainly perl can be used to write hideously ugly and unmaintainable code - but then it can also be used to write neat and well-structured code.
I came from a C / C++ background. I found coding OO perl to result in much more natural OO design than was possible in C++. I could focus on designing a system of independent classes which provided functionality, and a set of interoperable classes which solved the application problem, rather than trying to fit my needs into what C++ could do, or even worse spending time trying to get around the limitations of C++. There's a reason that C++ is so devoid of public class
... is a Model M that lights up :-)
For litigious bastards, displacing the previous litigious bastards who will henceforth be known simply as bastards.
You missed one:
Slashdot says; the universe is flat !!! :-)
The sad reality is that this database will be used to intrude upon the privacy of the 99.9999999% of people who are not terrorists.
It doesn't sound like much of an achievement, nor something you should be proud of. AOL still blacklists you, albeit at a higher threshold, and when it happens you still need to do some kind of pleading with AOL to take you out of their spammer list.
Indeed; Algis Budrys published a book in the 1970s called Michaelmas where the protagonist communicated with his ultra-intelligent computer through subvocal speech detected by implants.
I saw one like that a few weeks ago ... keys warped by the heat, still sticky ... and this was a notebook too.
Now the RIAA will get all concerned about pirated album covers ...
Net result is that Microsoft can never again use Unix as a weapon against linux.
This is an attempt to extinguish the mp3 format.
First, they'll add DRM and continue to call it MP3 even though the file formats are incompatible. "MP3" files won't play in a traditional MP3 player.
Next, "MP3" files will be distributed widely on the P2P networks. Vendors will sell "MP3" songs. People with traditional MP3 players will never know whether an "MP3" file they are about to download is a real MP3 file or not.
The resulting confusion will send MP3 and the P2P networks into obscurity.
I beg to differ. I'm running Debian Woody on, among other things, a 486SX notebook computer (that's SX as in no math coprocessor!) with 8 megs ram and about 200 megs of hard drive.
Though it's not fast, it runs correctly and it is modern code which is being maintained for security bugs. The kernel is 2.4.24 and I can use it with my pcmcia wifi card just fine.
There's an even better map of the universe here, at http://www.anzwers.org/free/universe/index.html
It is mentioned in Douglas R Hofstadter's book Godel, Escher, Bach: An Eternal Golden Braid.
In Soviet Russia, DOT slashes You!
My understanding from reading some previous article is that the site did not serve MP3s but merely linked to MP3s found online.
What you really need is a distributed, serverless filesystem - one which lets you store files on all your disk drives on the LAN, with automatic redundancy of data (so if a machine goes down or its storage becomes unavailable, you still have a copy of your data blocks on one or more of the other machines) and ability to access those files from any machine on the LAN. A serverless filesystem is one in which the participating machines act as peers - i.e. no master server. Distributed and serverless filesystems are a hot research area right now but I'm sorry to say that they're not yet ready for the mainstream.
I went through the "is CODA right for me?" phase, and also "is InterMezzo right for me?" and also spent tens of hours researching distributed filesystems and cluster filesystems online ... my conclusion
is that the area is still immature, I will let the pot simmer for a
few more years (hopefully not many), and use NFS with one or two
servers in the meantime.
My situation: desire for scalable and fault-tolerant distributed filesystem for home use with minimal maintenance or balancing effort. Emphasis on scalable - I want to be able to grow the filesystem essentially without limit. I also don't want to spend much time moving data between partitions. And last but not least, the bigger the filesystem grows, the less able I will be to back it up properly. I want redundancy so that if a disk dies the data is mirrored onto another disk, or if a server dies then the clients can continue to access the filesystem through another server.
All that seems to be quite a tall order. I checked out CODA, afs, PVFS, sgi's xfs, frangipani, petal, NFS, InterMezzo, berkeley's xfs, jfs, Sistina's gfs and some project Microsoft is doing to build a serverless filesystem based on a no-trust paradigm (that's quite unusual for Microsoft!).
Berkeley's xFS (now.cs.berkeley.edu/Xfs) sounded the most promising but it appears to be a defunct project. The source code is online however, so maybe somebody can resurrect it. Frangipani sounds interesting also, and maybe a little more alive than xFS.
On the other hand CODA, afs, intermezzo and Lustre are all in active development. afs IMHO suffered from kerberitis, i.e. once you start using kerberos it invades everything and it has lots of problems (which I read about on the openAFS list every day). AFS doesn't support live replication either - replication is done in a batch sense.
CODA doesn't scale and doesn't have expected filesystem semantics. For 80 gigs of server space I would require 3.2 gigs of virtual memory, and there's a limit to the size of a CODA directory (256k) which isn't seen in ordinary filesystems. There's also the full-file-download "feature". CODA is good for serving small filesystems to frequently disconnected clients but it is not good for serving the gigabyte AVIs which I want to share with my family.
InterMezzo is a lot more lightweight than CODA and will scale a lot better, but it's still a mirroring system rather than a network filesystem. I might use that to mirror my remote server where I just want to keep the data replicated and have write access on both the server and the client, but it's again not a solution for my situation.
The best thing about intermezzo is that it sits on top of a regular filesystem, so if you lose intermezzo the data is still safe in the underlying filesystem. CODA creates its own filesystem within files on a regular filesystem, and if you lose CODA then the data is trapped.
Frangipani is based on sharing data blocks, so like NFS it should be suitable for distributing files of arbitrary size. I need to look at it in a lot more detail; this is probably the right way to build a cluster filesystem for the long haul. For the short term, Intermezzo is probably the right way for a lot of people: it copies files from place to place on top of existing filesystems.
I got motivated to look at Frangipani again. No sour
Verisign would make 404 errors redirect to themselves if it were possible (score 1, irony).
IBM buckling spring keyboard. I'll upgrade my mobo, disks, screen, whatever - but the keyboard stays!
Parker pens are my preference. I've been using them since University. In particular, the Parker Frontier with the translucent plastic body and the rubberised lower third (for grip). Unlike metal-bodied pens, this pen is not cold to the touch. It looks kick-ass, isn't expensive, and is easy to hold (with the rubberised grip). And it comes with a lifetime guarantee!
I have two Frontiers - one ballpoint and one fountain. They come in a small plastic case which has fittings for both pens, the users' manual (!) and two additional fountain pen ink refills.
Ink is as important as the look and feel of the pen. Ever looked closely at ballpoint ink as the pen moves over the paper? Usually it's criss-crossed with little white lines due to ball imperfection or the ink hasn't transferred properly. That's annoying, and it looks terrible, but the Parker ink refills I use don't exhibit that problem.
The fountain pen seems to gobble up ink. I use it rarely and I have to put in a new cartridge pretty much every time I write with it. That's a sure sign that I should use the fountain pen more. It needs a new nib anyway. I've had the nib completely to pieces and it is astounding how much ink is inside.
For me, despite my appalling handwriting, the benefits of using a bit better than the typical throwaway pen are clear: I always know where my pens are; on the rare occasion I let people borrow them I make sure I get them back; the quality is better and I have a carrying case.
In situations where I can't bring my frontiers, I prefer a throwaway Papermate Flexgrip fine, because the ink is alright.
Like most I've acquired a collection of hundreds of junk pens over the years; unlike most they've been centralised into a few tins full of pens. Whenever anybody suggests buying another junk pen I merely have to shake a tin full of pens at them to drive home the point that we don't really need yet another junk pen.
I've tried most types. Rollerballs were all the rage when they were developed but I think they're worse than ballpoint - the thinner ink and lower friction on the ball emphasizes every poor writing movement. Gel ink rollers seem terrible as well. Bic style ballpoints with thick ink (particularly black ink) require a lot more pressure and - as a previous poster pointed out - tire the hand correspondingly more. Ultra-fine markers with felt tips (e.g. Pilot) are alright; certainly no worse than ballpoints despite being writing by scratching. Fountain pens are nice for making well-formed wide strokes but a bad nib (like mine) makes it scratching. Pencils, particularly clutch pencils, require more pressure - good for drawing of course, but not good for me.
Choice of paper is important too. I use unlined art diaries (double-ring bound) for permanent notes, and a tear-off pad for jotting. The art diary uses 110gsm acid-free paper, and it was chosen because it gives a good result with the fountain pen. Certain types of paper will cause the fountain pen ink to run, or too-smooth paper will mean that the ink doesn't sink into the paper enough and smudges. The double-ring bind means I can open the pages 360 degrees with no sticking. I rarely tear out pages because the book is intended for a permanent record of whatever.
The jotting pad is intended for very temporary use - by throwing away each page as soon as possible after it is written. Otherwise I'd be eventually buried in small scraps of paper.
Post-It notes are verboten here: if it's something I need to do, then it must go into my computerised todo list. If it's something I need to remember, then I have a system for that too. They're too small for effective note jotting and the adhesive on the back becomes ineffective after a few stickings. They're also a nuisance to shred.
All temporary writings are shredded before they go into the garbage. It's just basic maintenance of privacy. It's very unlikely that somebody is going through my garbage in par
I got 161 hits for "SCO is smoking crack" and no suggestion from google at all that any of linus, rms or esr were smoking crack.