Now, 94% is some serious CPU utilization. The best results from Sun's marketing brochures don't quite touch that. More recently IBM has taken scalability in linux up to a much larger number of processors (no barriers existed in source code, the developers just didn't have 128 CPU machines to play with).
So, no, I don't think SMP scalability has any relevance to choosing Sun/IBM/HP/Tru64 linux. It is strictly a hardware issue.
There are SOME things big iron has - like better logical volume management (I am familiar with Tru64 resizeable file systems and domains). I am beginning to think, however, the niche for which big iron UNIX has an advantage over linux is fairly small, and growing smaller and smaller by the year.
Sendmail is large because it's flexible and powerful. It has much (much) more power than qmail, which is why people still use it.
People still use it because apps were built interoperable with sendmail, and are configured that way by default, and most admins do not want to chase the interoperability configuration around. It is easier to just apply the myriad patches to sendmail, and of course there is the side benefit of using the sendmail OReilly book as a doorstop (you gotta wonder why it is the longest tech book OReilly sells).
Only because there is a cold hard cash offer on bugs in qmail doesnt mean there are no bugs? Maybe if "someone" finds a qmail bug s/he might want to keep it to themselves just to be able to exploit it for much more profit than the cash offered.
Qmail has stood without known exploit for 6 years now.
Hate to break it to you, but ANY program of medium to large size will never be bug free and exploitless.
Find a bug in qmail that allows an outsider to do so much as change file permissions of a file he should not be allowed to. There has not ever been one, and there is cold hard cash offered.
Secure code is not impossible. However, if you start with sendmail or BIND and try to achieve security, well, good luck.
Unless you are an expert at this sort of thing and have a lot of free time you aren't going to write C code to beat LAPACK.
I must be an expert. I needed to solve a matrix equation involving a 1700x1700 autocorrelation matrix.
Try defining that in Matlab.
I hacked it up in C, used gsl to solve the matrix, and had results MUCH faster than Matlab can provide them. And, the kicker in this case was that the memory usage of C was trivial compared to that of matlab - gsl used about 25 MBytes, Matlab threw the 256 M RAM machine into swap.
Matlab is a toy scripting language that is good for small data sets, where memory dwarfs the problem at hand, and when the speed of prototyping the algorithm is the limiting factor (which is really really often).
But still, get down to serious crunching, and people are rewriting algorithms in C or ForTran to save time.
Matlab has evolved considerably from a Matrix Laboratory to a general all purpose numerical programming and plotting scripting language. Kinda like a blunt swiss army knife.
The reason why it sends info about other applications (and third party drivers for that matter) is so that they can attempt to be a single-source vendor of patches if needed.
I dunno if you've noticed, but the updater is becoming a large source of irritation for OEM vendors. Sony, for one, prefers that you get your updates from them rather than Microsoft, as the Microsoft updates tend to botch their systems.
Microsoft is no longer the operating system maintainer - the OEM is. This has HUGE ramifications down the line wrt the control Microsoft maintains over the personal PC.
to see a summary of the things that daemontools does compared to other init strategies. You have to run something in inittab to ensure that process restarting is clean and reliable. The daemontools package also makes it easy for one daemon to check all the others, re-start the dead ones, add and/or remove services at will, signal them cleanly, and is available under all flavors of Unix.
You MAY think that is only an incremental improvement over init. I don't.
not re-inventing the wheel just because he reckons he can do it 0.001% better than everyone else (svcmgr).
Exactly what is svcmgr replacing that it only does things 0.0001% better than?
Phrased more simply, what exactly is there to check that service daemons are running, and starts them if they are not?
Whereas daemontools replaces init scripts, it also does the job of checking that services are still running, and starts them if they are not. It is a very useful daemon - a supervising master daemon to watch all the other daemons, because time has shown that daemons aren't very good at watching themselves.
The inventor doesn't get paid a wage. He gets paid the value of "being first to market" for his invention.
The system breaks down if this value is less than what would be a reasonable wage for the inventor's time.
The inventor can, of course, make substantially more than that, depending on the value of being first to market. If the inventor makes something easily, and it is REALLY tough to reverse engineer, then he makes a lot of money. As he should - he did something easily that others cannot do.
The system does not, however, have much reward for inventors that do things that others can do quickly and easily, just for being first. A kind of penalty for making obvious inventions that does not exist now.
You are evil. Some poor guy spends $40 000 on inventing an idea for you, and you just cover his expenses?
Quite the contrary.
First of all, it is not my idea, and you are a flippin idjit for thinking I was doing anything more than explaining the point of the economic theory.
Second of all, the amount an inventor would be paid would reflect the advantage his invention could give to the purchaser. The system only works if this amount is equal or greater than the inventor's costs. It can be much more.
Instead of an invention having a value associated with a 17 or 20 year monopoly, it has a value associated with the value of being first to market. This value is MUCH less (obviously), but may be perfectly adequate to support innovation.
They suggest a dramatic reduction in IP protection, and argue it will increase innovation. I am quite sure they are right in some markets, and unsure about all markets.
Of course an individual or corporation ought to have rights to the unique result of their own creative work, and they should also have the right to transfer these rights to anyone they please if it is in their own interest. Exclusive rights over something like the text of a particular, source code to a particular program, or a particular performance of a popular song, do not translate into a "monopoly" in the general case: It only forces competitors to produce their own original products, which produces diversity that we as consumers should value anyway.
The point of the new economic theory is that by creating something new - something that would today be called copyrightable or patentable - the inventor already has a form of monopoly rights. He has the unique widget he has invented. He can sell this invention to the highest bidder. The highest bidder can then be first to market.
The system works if "being first to market" has a substantial advantage. Substantial means they can afford to pay the inventor for his time. So, if the inventor spent $40,000 inventing his widget, the advantage of being first to market needs to allow a bidder to pay the inventor that $40,000. Then, the system functions.
This would definitely result in a dramatic decrease in value of invention, but could result in a dramatic increase in innovation. There are still problems, though. The theory depends critically on the ratio in cost between creation and "value of being first to market". Reverse engineering something doesn't happen overnight, but it could happen really fast if a big corporation saw your idea, and put a large number of good people on it (I guess, then, their argument would say the right of being first to market must be substantial if someone will allot so many resources to duplication - therefore the inventor must have been well paid).
I guess I sorta see them arguing that 1-2 years of monopoly protection will be conveyed by being first to market, and that would be enough. They may be right.
I have an HP linux laptop. I blew away Windows NT about 3 years ago, and installed linux. It was light for the time (4 lbs), and had the right range of compromises I was looking for. But, HP laptops are, I think, just relabeled Dell laptops.
Anyway, $0.02. HP is really oriented towards corporate sales and not personal sales, and it is dern near impossible trying to get decent specs from them. But, the machine has worked like a charm so far, and its been through a lot.
Back to the original poster. If you want Firewire built in, you gotta buy a MAC or a SONY. If you won't pay for Windows, you will get a MAC. End of story. However, I dislike the SONY laptop keyboards, and the Macs run like crippled pigs (even if they look beautiful and have sweet user interfaces).
I am not sure what I would get now. The built-in Firewire is much more limiting than you would think, due to licensing issues. In laptop use I have come to value battery life more and more, as well as a decent keyboard. I'd probably look at Crusoe powered laptops to get good battery life, and then look for one with a good keyboard.
Don't you get that? If the MPlayer authors actually cared about well-written software, it would use carefully crafted, modular APIs between all the component parts. I could add Quicktime codecs to MPlayer just by copying a hypothetical mp_qtime.so into lib/mplayer/codecs.
You don't use Mplayer, do you? To add a codec, simply copy it to the codec directory. End of story. BTW, Mplayer supports all Quicktime codecs.
Apple don't permit you to hack into the Sorensen codecs and get them to work outside Quicktime Player.
Actually, so far, they have. The legal arguments are several.
1) The binary is the same as Windows, and performs the same functions, and is freely downloadable from the provider. Apple. Provided the user does the download, no big deal.
2) The code itself uses a plug-in architecture for Windows and Quicktime dlls, so that copyright issues on different sides of the plug-in interface are separated.
So, Mplayer is GPL, but can still use Windows dlls, when they are available.
The MPlayer team should do the same, and stop relying on other people's binaries for their glory.
They DID reverse engineer SVQ1. And, others are coming, but until they are available, the movies may still be played using the Windows binary codecs, available via plug-in.
Also, the source only re-distribution requirement is now gone, and the binary optimizes for hardware on the fly.
Mplayer is a very impressive piece of software engineering.
1) What WMs work with what video programs. 2) What libraries are required. 3) What version of gcc you used *G* 4) What flags are set, where to set them, and what's "right" for a wide range of systems, say, a few nVIDIA and ATI systems on AMD and Intel chips, and/or any specific motherboard-related issues. 5) All the other variables I've overlooked, but that you didn't, that make the difference between "It Works" and "It Doesn't".
One working example.
First, install Debian. Use this in your/etc/apt/sources/list deb http://marillat.free.fr/ unstable main
To install, run apt-get install mplayer-686 apt-get install ffmpeg
Also, grab the extra binary codecs from the Mplayer site and throw them in/usr/lib/win32
To play a vid, download it first. IF you get a stupid quicktime page thingy, load the page source, use "wget" to grab the vid, and play it.
If you get a windows streaming site, use mplayer -dumpstream to dump the stream to an ASF file on disk, and then play it. I usually use the options -vo xv and -xy 2 (or 3) to enlarge, and ensure usage of the XVideo extension.
So much for playing vids. To record digital vids, do the following
1) grab a cheap Firewire card. If you pay more than $20 you paid too much.
2) Build Firewire options into kernel and load the modules (or reboot if you build them in)
3) Use kino to grab digital video. Again, from Debian, apt-get install kino. Edit in kino, export to a type 2 AVI file.
4) Use ffmpeg to make a divx file. I like to use these options -f avi -vcodec mpeg4 -s 360x240 -b 200 -g 300 -bf 2 -acodec mp3 -ab 128
If you have a lot of motion consider also using -4mv and -me FULL. If you have an IDE drive make sure dma transfer is enabled.
I initially trained on about 200 emails. At first, I got 1 spam per day, or so. There have not yet been any false positives (good mail classified as spam).
A week later, I get 1 spam in my inbox every 3-4 days, and no good mail has been classified as spam. All I need to do it take the false identifications and re-classify them. That means, every 3-4 days I take the spam in my inbox and re-scan it through bogofilter (cat SPAM | bogofilter -S). That is all. It is not any effort, really, after the initial training. Then, the filter does all the work, and you don't need to worry about blacklisting or whitelisting or anything.
The really important thing is that the filter statistically optimizes YOUR manual email classification. The best source of email classifying is YOU looking at an email, and Bayesian filtering is the only method that is optimized to do that.
Bayesian filtering merely using a statistically optimized method to duplicate the classification of the user for which it is working. If trained on enough of YOUR email, it will work exceedingly well in classifying YOUR future email.
Put another way, I tried blacklisting filtering, and fixed token filtering, and performance was pretty poor. In contrast, I am quite happy with bogofilter's performance. But, of the various methods, only Bayesian filtering takes the preferences of the individual user as its primary basis for sorting email.
BTW, your link is pretty much useless in showing why Sponsky may or may not think Bayesian methods are intractable. He more or less just rants that draconian MTA based filters are doing harm - I agree with him. But the word Bayesian doesn't even appear on the page to which you linked. And that makes you a Troll.
The basics are, you take all good mails, and create a database of words used in them. Make a different database for spam mails. Then, for each incoming mail, compare to each database, and classify as spam or non-spam.
The algorithm starts out conservative, ie: you get most of the mail classified as good. For each "good" email that is spam, you manually re-classify it.
Then, after a few weeks, the filter does all the work. It is basically using word-databases to compare emails and classify them the way you, the user would. Periodically you will receive another spam email, then you re-classify it, and never see an email like it again (in your inbox).
Bogofilter and CRM114 are among the more successful efforts so far, but there are many. And they are FAR more successful than blacklist/whitelist/fixed token comparison filters. But Bayesian filtering is just a near optimal way to replicate the classification of the user, which is also why it works so well.
Excuse me, but when the money was invested in these movies in the 1920's, 1930's, etc., it was done with full knowledge that eventually the copyright would expire and revenue from these works would dwindle.
Look, the justices know the law. Their comments during the arguments phase made it abundantly clear that they understand it is ridiculous from a POV of constitutional law to retroactively extend copyrights.
But they also live in this world. The economy is weak and not so stable right now, and if they rule against the Bono Act, they also rule against previous copyright extensions, which makes several decades of copyrighted work public domain. This would be a colossal economic hit to the major media companies, and to the US economy. This was also something they noted during arguments.
So they noted it was stupid and passed the buck back to Congress. They lack spines and/or didn't want to do things to make the Bush administration's life tougher by causing the value of the large media companies to take an instant hit.
Mplayer is very very advanced. First, on the playback. It takes advantage of all hardware available by probing at runtime, so you are guaranteed to have playback at optimized speed. This is substantially better than WMP. It also will resize any video, will allow you to dump streams from the web to your hard drive.
Second, it plays anything WMP can play. And, it plays anything Quicktime can play. And, it plays anything REAL can play. Mostly, it uses their own native Windows decoders. A media player is about playing media - it is not so relevant to discuss advantages of different formats. But while you are at it...
Ogg Vorbis is on the same level as mp3 or wma for encoding audio, better in most tests, but it depends a little on how you test it. It is as fine an audio codec as anyone has.
I do agree than WMV7-9 video codecs are quite good, in my experience better than alternatives (this will depend a little on what and how you encode). Credit where credit is due - the windows video codecs are really good.
1. If I create a GPL'd plugin for WinAmp, does that make WinAmp GPL? I think most reasonable people think the answer is no.
Of course not. You have to realize the nuances of what makes a derivative work extend far beyond the cut-and-dried. A plug-in interface is defined more clearly than other interfaces. It specifically exists so that the plug-in and the program don't need to know anything about each other except the plug-in interface. As such, this creates a boundary on expression. Neither program cares what specific expression is used, as long as the functionality of the interface is met. In this case, there are no copyright issues relating to derivatives. Either program could be GPL, or properietary, or anything, really, as long as copyright restrictions are the only issue.
Stating the obvious, but a dynamic library is nothing more than a set of entry points with documented behavior. By design. That's what it's intended to do. Calling something that uses a tool to do something a derivation of the original work is on shaky ground. That's like arguing a novel written in emacs is GPL. Anyway, I'm not arguing that a license couldn't provent this sort of thing; I just think version 2 of the GPL doesn't.
Again, it really depends on how well defined the interface is. For example, if two libraries exist that perform the same function (say, Motif and lesstif, assuming for a second they are identical functionally), then there is no derivative issue for linking to them dynamically. This happens because the interface is demonstrably well-defined. Even if one is GPLd, you can still link to it, because your calling program is not a derivative of the program it links to. Your program only needs the well-defined interface.
Now, if a unique library exists that is GPLd, then linking to it may be considered a derivative work. The argument would be that the specific expression in the library is critical b/c it is the only source for the library function. This case is really the only one that RMS argues for. It has yet to be decided.
But a lot of the issue boils down to the separation of expression from function. Plug-in interfaces do this. Functions provided by multiple different expressions in libraries do this. But, in the case of functions provided uniquely by a single GPL'd library, there are issues yet to be resolved wrt derivative status.
Why is my application considered a derivative of a unique GPL'd library that it uses, but my shell script which uses a unique GPL'd utility is not? Both are dependent upon a unique expression of code.
I think the argument that would be put forth is that the expectation of a GPL'd userspace program is that calling it places no restrictions on the caller, whereas the expectations are different for a library.
This argument would call the shell script "fair use", but the library call a derivative. There are comparable analogies. In my field, I lecture classes. I can take material directly from published papers, cite them, and use their figures in my lectures. This is fair use. However, I cannot do the same with a textbook chapter, because the expectation is different. In many cases the figures are even the same, but it is OK for me to photocopy and re-distribute the original manuscript version, but not the textbook version. This all has to do with the author's expectation of how his copyrighted material will be used, and that then falling under fair use.
I've thought about it a LOT, and my answers indicate what I think a judge would decide based on existing copyright decisions. I think the reality is that specifics in some cases will make dynamic linking non-derivative sometimes, and derivative other times.
Function and expression are separable even in unique libraries.
It is not enough that they be separable. There has to be a demonstration of separability. The first ROM-BIOS was copyrighted by IBM. Compaq had one set of engineers document its function by studying it directly. Then, a second set of engineers used only the documents to create the clone (without using the expression). They had a demonstration of separability.
With a unique library there is not yet a demonstration of separability. The argument would be that the program is dependent on the expression of the unique library (because its function and expression are not demonstrably separated yet). And dependency on expression makes something a derivative. Once a duplicate library exists, there is only dependency on function, and there is no longer a copyright derivative. This argument implies the function is derived from the specific expression only as long as there is no other source of the expression, which I believe is consistent with existing interpretations of copyright law.
If you MUST include GPL licensed code (ie the header file in question) to make the binary you wish to distribute, you have created a (partially) derivative work.
Yes, except that the header may be read and prototyped without using the same expression trivially. So, there is such an easy work-around, it seems silly to have it at all. I mean, I could write a PERL program to dupe a header quite easily.
If you don't agree with the GPL restrictions on distribution, don't distribute GPL code, or any part of it.
Copyright law only goes so far. The restrictions in question about the GPL only apply if a program is a derivative. So, the essential question here is what makes something a derivative. I think including the header is a laughable legal argument, in part because it may be worked around trivially.
The FSF feels fairly confident that a library that provides a unique function makes something that links to it a derivative. The uniqueness is fairly critical wrt copyright law.
No, but dependency is a critical aspect of being able to make the "conceptual wall" argument. That is, if there are multiple libraries that fulfill the API, and your program links to one of them, your program is only adhering to the API. The fact that multiple libraries adhere to the API indicates it is functional, and not related directly to expression. So, your program is dependent on a function, and not an expression, and as such is not a derivative work. Remember, copyright covers expression, and not function.
In the case of a unique library, the function and expression are inseparable, so establishing depency on function is adequate for establishing derivative on expression. This is my understanding of how copyright law will relate to dynamic linking, but I don't think anyone is 100% sure of how a judge will call it.
Slashdot Mirror
Web page from Sun on scalability
Note that it doesn't describe what happens between 1 and 4 CPUs.
Linux kernel compilation benchmark, showing that 4 CPUs each crunch about 94% of what 1 cpu can crunch
Now, 94% is some serious CPU utilization. The best results from Sun's marketing brochures don't quite touch that. More recently IBM has taken scalability in linux up to a much larger number of processors (no barriers existed in source code, the developers just didn't have 128 CPU machines to play with).
So, no, I don't think SMP scalability has any relevance to choosing Sun/IBM/HP/Tru64 linux. It is strictly a hardware issue.
There are SOME things big iron has - like better logical volume management (I am familiar with Tru64 resizeable file systems and domains). I am beginning to think, however, the niche for which big iron UNIX has an advantage over linux is fairly small, and growing smaller and smaller by the year.
Sendmail is large because it's flexible and powerful. It has much (much) more power than qmail, which is why people still use it.
People still use it because apps were built interoperable with sendmail, and are configured that way by default, and most admins do not want to chase the interoperability configuration around. It is easier to just apply the myriad patches to sendmail, and of course there is the side benefit of using the sendmail OReilly book as a doorstop (you gotta wonder why it is the longest tech book OReilly sells).
Only because there is a cold hard cash offer on bugs in qmail doesnt mean there are no bugs? Maybe if "someone" finds a qmail bug s/he might want to keep it to themselves just to be able to exploit it for much more profit than the cash offered.
Qmail has stood without known exploit for 6 years now.
Hate to break it to you, but ANY program of medium to large size will never be bug free and exploitless.
Find a bug in qmail that allows an outsider to do so much as change file permissions of a file he should not be allowed to. There has not ever been one, and there is cold hard cash offered.
Secure code is not impossible. However, if you start with sendmail or BIND and try to achieve security, well, good luck.
Unless you are an expert at this sort of thing and have a lot of free time you aren't going to write C code to beat LAPACK.
I must be an expert. I needed to solve a matrix equation involving a 1700x1700 autocorrelation matrix.
Try defining that in Matlab.
I hacked it up in C, used gsl to solve the matrix, and had results MUCH faster than Matlab can provide them. And, the kicker in this case was that the memory usage of C was trivial compared to that of matlab - gsl used about 25 MBytes, Matlab threw the 256 M RAM machine into swap.
Matlab is a toy scripting language that is good for small data sets, where memory dwarfs the problem at hand, and when the speed of prototyping the algorithm is the limiting factor (which is really really often).
But still, get down to serious crunching, and people are rewriting algorithms in C or ForTran to save time.
Matlab has evolved considerably from a Matrix Laboratory to a general all purpose numerical programming and plotting scripting language. Kinda like a blunt swiss army knife.
The reason why it sends info about other applications (and third party drivers for that matter) is so that they can attempt to be a single-source vendor of patches if needed.
I dunno if you've noticed, but the updater is becoming a large source of irritation for OEM vendors. Sony, for one, prefers that you get your updates from them rather than Microsoft, as the Microsoft updates tend to botch their systems.
Microsoft is no longer the operating system maintainer - the OEM is. This has HUGE ramifications down the line wrt the control Microsoft maintains over the personal PC.
See This page
to see a summary of the things that daemontools does compared to other init strategies. You have to run something in inittab to ensure that process restarting is clean and reliable. The daemontools package also makes it easy for one daemon to check all the others, re-start the dead ones, add and/or remove services at will, signal them cleanly, and is available under all flavors of Unix.
You MAY think that is only an incremental improvement over init. I don't.
not re-inventing the wheel just because he reckons he can do it 0.001% better than everyone else (svcmgr).
Exactly what is svcmgr replacing that it only does things 0.0001% better than?
Phrased more simply, what exactly is there to check that service daemons are running, and starts them if they are not?
Whereas daemontools replaces init scripts, it also does the job of checking that services are still running, and starts them if they are not. It is a very useful daemon - a supervising master daemon to watch all the other daemons, because time has shown that daemons aren't very good at watching themselves.
The inventor doesn't get paid a wage. He gets paid the value of "being first to market" for his invention.
The system breaks down if this value is less than what would be a reasonable wage for the inventor's time.
The inventor can, of course, make substantially more than that, depending on the value of being first to market. If the inventor makes something easily, and it is REALLY tough to reverse engineer, then he makes a lot of money. As he should - he did something easily that others cannot do.
The system does not, however, have much reward for inventors that do things that others can do quickly and easily, just for being first. A kind of penalty for making obvious inventions that does not exist now.
You are evil. Some poor guy spends $40 000 on inventing an idea for you, and you just cover his expenses?
Quite the contrary.
First of all, it is not my idea, and you are a flippin idjit for thinking I was doing anything more than explaining the point of the economic theory.
Second of all, the amount an inventor would be paid would reflect the advantage his invention could give to the purchaser. The system only works if this amount is equal or greater than the inventor's costs. It can be much more.
Instead of an invention having a value associated with a 17 or 20 year monopoly, it has a value associated with the value of being first to market. This value is MUCH less (obviously), but may be perfectly adequate to support innovation.
They suggest a dramatic reduction in IP protection, and argue it will increase innovation. I am quite sure they are right in some markets, and unsure about all markets.
Of course an individual or corporation ought to have rights to the unique result of their own creative work, and they should also have the right to transfer these rights to anyone they please if it is in their own interest. Exclusive rights over something like the text of a particular, source code to a particular program, or a particular performance of a popular song, do not translate into a "monopoly" in the general case: It only forces competitors to produce their own original products, which produces diversity that we as consumers should value anyway.
The point of the new economic theory is that by creating something new - something that would today be called copyrightable or patentable - the inventor already has a form of monopoly rights. He has the unique widget he has invented. He can sell this invention to the highest bidder. The highest bidder can then be first to market.
The system works if "being first to market" has a substantial advantage. Substantial means they can afford to pay the inventor for his time. So, if the inventor spent $40,000 inventing his widget, the advantage of being first to market needs to allow a bidder to pay the inventor that $40,000. Then, the system functions.
This would definitely result in a dramatic decrease in value of invention, but could result in a dramatic increase in innovation. There are still problems, though. The theory depends critically on the ratio in cost between creation and "value of being first to market". Reverse engineering something doesn't happen overnight, but it could happen really fast if a big corporation saw your idea, and put a large number of good people on it (I guess, then, their argument would say the right of being first to market must be substantial if someone will allot so many resources to duplication - therefore the inventor must have been well paid).
I guess I sorta see them arguing that 1-2 years of monopoly protection will be conveyed by being first to market, and that would be enough. They may be right.
I have an HP linux laptop. I blew away Windows NT about 3 years ago, and installed linux. It was light for the time (4 lbs), and had the right range of compromises I was looking for. But, HP laptops are, I think, just relabeled Dell laptops.
Anyway, $0.02. HP is really oriented towards corporate sales and not personal sales, and it is dern near impossible trying to get decent specs from them. But, the machine has worked like a charm so far, and its been through a lot.
Back to the original poster. If you want Firewire built in, you gotta buy a MAC or a SONY. If you won't pay for Windows, you will get a MAC. End of story. However, I dislike the SONY laptop keyboards, and the Macs run like crippled pigs (even if they look beautiful and have sweet user interfaces).
I am not sure what I would get now. The built-in Firewire is much more limiting than you would think, due to licensing issues. In laptop use I have come to value battery life more and more, as well as a decent keyboard. I'd probably look at Crusoe powered laptops to get good battery life, and then look for one with a good keyboard.
Don't you get that? If the MPlayer authors actually cared about well-written software, it would use carefully crafted, modular APIs between all the component parts. I could add Quicktime codecs to MPlayer just by copying a hypothetical mp_qtime.so into lib/mplayer/codecs.
You don't use Mplayer, do you? To add a codec, simply copy it to the codec directory. End of story. BTW, Mplayer supports all Quicktime codecs.
Apple don't permit you to hack into the Sorensen codecs and get them to work outside Quicktime Player.
Actually, so far, they have. The legal arguments are several.
1) The binary is the same as Windows, and performs the same functions, and is freely downloadable from the provider. Apple. Provided the user does the download, no big deal.
2) The code itself uses a plug-in architecture for Windows and Quicktime dlls, so that copyright issues on different sides of the plug-in interface are separated.
So, Mplayer is GPL, but can still use Windows dlls, when they are available.
The MPlayer team should do the same, and stop relying on other people's binaries for their glory.
They DID reverse engineer SVQ1. And, others are coming, but until they are available, the movies may still be played using the Windows binary codecs, available via plug-in.
Also, the source only re-distribution requirement is now gone, and the binary optimizes for hardware on the fly.
Mplayer is a very impressive piece of software engineering.
So write up an FAQ. Tell us:
/etc/apt/sources/list
/usr/lib/win32
1) What WMs work with what video programs.
2) What libraries are required.
3) What version of gcc you used *G*
4) What flags are set, where to set them, and what's "right" for a wide range of systems, say, a few nVIDIA and ATI systems on AMD and Intel chips, and/or any specific motherboard-related issues.
5) All the other variables I've overlooked, but that you didn't, that make the difference between "It Works" and "It Doesn't".
One working example.
First, install Debian. Use this in your
deb http://marillat.free.fr/ unstable main
To install, run
apt-get install mplayer-686
apt-get install ffmpeg
Also, grab the extra binary codecs from the Mplayer site and throw them in
That site is here
To play a vid, download it first. IF you get a stupid quicktime page thingy, load the page source, use "wget" to grab the vid, and play it.
If you get a windows streaming site, use mplayer -dumpstream to dump the stream to an ASF file on disk, and then play it. I usually use the options -vo xv and -xy 2 (or 3) to enlarge, and ensure usage of the XVideo extension.
So much for playing vids. To record digital vids, do the following
1) grab a cheap Firewire card. If you pay more than $20 you paid too much.
2) Build Firewire options into kernel and load the modules (or reboot if you build them in)
3) Use kino to grab digital video. Again, from Debian, apt-get install kino. Edit in kino, export to a type 2 AVI file.
4) Use ffmpeg to make a divx file. I like to use these options
-f avi
-vcodec mpeg4
-s 360x240
-b 200
-g 300
-bf 2
-acodec mp3
-ab 128
If you have a lot of motion consider also using -4mv and -me FULL. If you have an IDE drive make sure dma transfer is enabled.
Again, just one working example.
I think you misunderstand how easy bogofilter is.
I initially trained on about 200 emails. At first, I got 1 spam per day, or so. There have not yet been any false positives (good mail classified as spam).
A week later, I get 1 spam in my inbox every 3-4 days, and no good mail has been classified as spam. All I need to do it take the false identifications and re-classify them. That means, every 3-4 days I take the spam in my inbox and re-scan it through bogofilter (cat SPAM | bogofilter -S). That is all. It is not any effort, really, after the initial training. Then, the filter does all the work, and you don't need to worry about blacklisting or whitelisting or anything.
The really important thing is that the filter statistically optimizes YOUR manual email classification. The best source of email classifying is YOU looking at an email, and Bayesian filtering is the only method that is optimized to do that.
I think you are wrong.
Bayesian filtering merely using a statistically optimized method to duplicate the classification of the user for which it is working. If trained on enough of YOUR email, it will work exceedingly well in classifying YOUR future email.
Put another way, I tried blacklisting filtering, and fixed token filtering, and performance was pretty poor. In contrast, I am quite happy with bogofilter's performance. But, of the various methods, only Bayesian filtering takes the preferences of the individual user as its primary basis for sorting email.
BTW, your link is pretty much useless in showing why Sponsky may or may not think Bayesian methods are intractable. He more or less just rants that draconian MTA based filters are doing harm - I agree with him. But the word Bayesian doesn't even appear on the page to which you linked. And that makes you a Troll.
The basics are, you take all good mails, and create a database of words used in them. Make a different database for spam mails. Then, for each incoming mail, compare to each database, and classify as spam or non-spam.
The algorithm starts out conservative, ie: you get most of the mail classified as good. For each "good" email that is spam, you manually re-classify it.
Then, after a few weeks, the filter does all the work. It is basically using word-databases to compare emails and classify them the way you, the user would. Periodically you will receive another spam email, then you re-classify it, and never see an email like it again (in your inbox).
Bogofilter and CRM114 are among the more successful efforts so far, but there are many. And they are FAR more successful than blacklist/whitelist/fixed token comparison filters. But Bayesian filtering is just a near optimal way to replicate the classification of the user, which is also why it works so well.
Excuse me, but when the money was invested in these movies in the 1920's, 1930's, etc., it was done with full knowledge that eventually the copyright would expire and revenue from these works would dwindle.
Look, the justices know the law. Their comments during the arguments phase made it abundantly clear that they understand it is ridiculous from a POV of constitutional law to retroactively extend copyrights.
But they also live in this world. The economy is weak and not so stable right now, and if they rule against the Bono Act, they also rule against previous copyright extensions, which makes several decades of copyrighted work public domain. This would be a colossal economic hit to the major media companies, and to the US economy. This was also something they noted during arguments.
So they noted it was stupid and passed the buck back to Congress. They lack spines and/or didn't want to do things to make the Bush administration's life tougher by causing the value of the large media companies to take an instant hit.
Nice troll.
Mplayer is very very advanced. First, on the playback. It takes advantage of all hardware available by probing at runtime, so you are guaranteed to have playback at optimized speed. This is substantially better than WMP. It also will resize any video, will allow you to dump streams from the web to your hard drive.
Second, it plays anything WMP can play. And, it plays anything Quicktime can play. And, it plays anything REAL can play. Mostly, it uses their own native Windows decoders. A media player is about playing media - it is not so relevant to discuss advantages of different formats. But while you are at it...
Ogg Vorbis is on the same level as mp3 or wma for encoding audio, better in most tests, but it depends a little on how you test it. It is as fine an audio codec as anyone has.
I do agree than WMV7-9 video codecs are quite good, in my experience better than alternatives (this will depend a little on what and how you encode). Credit where credit is due - the windows video codecs are really good.
Mplayer rules.
They did the first hack to get Windows Dlls to work. Xine followed suit.
Then, mplayer hacked to get Windows Quicktime dlls to work. And realplayer.
Mplayer can play just about any media file.
1. If I create a GPL'd plugin for WinAmp, does that make WinAmp GPL? I think most reasonable people think the answer is no.
Of course not. You have to realize the nuances of what makes a derivative work extend far beyond the cut-and-dried. A plug-in interface is defined more clearly than other interfaces. It specifically exists so that the plug-in and the program don't need to know anything about each other except the plug-in interface. As such, this creates a boundary on expression. Neither program cares what specific expression is used, as long as the functionality of the interface is met. In this case, there are no copyright issues relating to derivatives. Either program could be GPL, or properietary, or anything, really, as long as copyright restrictions are the only issue.
Stating the obvious, but a dynamic library is nothing more than a set of entry points with documented behavior. By design. That's what it's intended to do. Calling something that uses a tool to do something a derivation of the original work is on shaky ground. That's like arguing a novel written in emacs is GPL. Anyway, I'm not arguing that a license couldn't provent this sort of thing; I just think version 2 of the GPL doesn't.
Again, it really depends on how well defined the interface is. For example, if two libraries exist that perform the same function (say, Motif and lesstif, assuming for a second they are identical functionally), then there is no derivative issue for linking to them dynamically. This happens because the interface is demonstrably well-defined. Even if one is GPLd, you can still link to it, because your calling program is not a derivative of the program it links to. Your program only needs the well-defined interface.
Now, if a unique library exists that is GPLd, then linking to it may be considered a derivative work. The argument would be that the specific expression in the library is critical b/c it is the only source for the library function. This case is really the only one that RMS argues for. It has yet to be decided.
But a lot of the issue boils down to the separation of expression from function. Plug-in interfaces do this. Functions provided by multiple different expressions in libraries do this. But, in the case of functions provided uniquely by a single GPL'd library, there are issues yet to be resolved wrt derivative status.
Why is my application considered a derivative of a unique GPL'd library that it uses, but my shell script which uses a unique GPL'd utility is not? Both are dependent upon a unique expression of code.
I think the argument that would be put forth is that the expectation of a GPL'd userspace program is that calling it places no restrictions on the caller, whereas the expectations are different for a library.
This argument would call the shell script "fair use", but the library call a derivative. There are comparable analogies. In my field, I lecture classes. I can take material directly from published papers, cite them, and use their figures in my lectures. This is fair use. However, I cannot do the same with a textbook chapter, because the expectation is different. In many cases the figures are even the same, but it is OK for me to photocopy and re-distribute the original manuscript version, but not the textbook version. This all has to do with the author's expectation of how his copyrighted material will be used, and that then falling under fair use.
I've thought about it a LOT, and my answers indicate what I think a judge would decide based on existing copyright decisions. I think the reality is that specifics in some cases will make dynamic linking non-derivative sometimes, and derivative other times.
Function and expression are separable even in unique libraries.
It is not enough that they be separable. There has to be a demonstration of separability. The first ROM-BIOS was copyrighted by IBM. Compaq had one set of engineers document its function by studying it directly. Then, a second set of engineers used only the documents to create the clone (without using the expression). They had a demonstration of separability.
With a unique library there is not yet a demonstration of separability. The argument would be that the program is dependent on the expression of the unique library (because its function and expression are not demonstrably separated yet). And dependency on expression makes something a derivative. Once a duplicate library exists, there is only dependency on function, and there is no longer a copyright derivative. This argument implies the function is derived from the specific expression only as long as there is no other source of the expression, which I believe is consistent with existing interpretations of copyright law.
If you MUST include GPL licensed code (ie the header file in question) to make the binary you wish to distribute, you have created a (partially) derivative work.
Yes, except that the header may be read and prototyped without using the same expression trivially. So, there is such an easy work-around, it seems silly to have it at all. I mean, I could write a PERL program to dupe a header quite easily.
If you don't agree with the GPL restrictions on distribution, don't distribute GPL code, or any part of it.
Copyright law only goes so far. The restrictions in question about the GPL only apply if a program is a derivative. So, the essential question here is what makes something a derivative. I think including the header is a laughable legal argument, in part because it may be worked around trivially.
The FSF feels fairly confident that a library that provides a unique function makes something that links to it a derivative. The uniqueness is fairly critical wrt copyright law.
Dependency is not derivation.
No, but dependency is a critical aspect of being able to make the "conceptual wall" argument. That is, if there are multiple libraries that fulfill the API, and your program links to one of them, your program is only adhering to the API. The fact that multiple libraries adhere to the API indicates it is functional, and not related directly to expression. So, your program is dependent on a function, and not an expression, and as such is not a derivative work. Remember, copyright covers expression, and not function.
In the case of a unique library, the function and expression are inseparable, so establishing depency on function is adequate for establishing derivative on expression. This is my understanding of how copyright law will relate to dynamic linking, but I don't think anyone is 100% sure of how a judge will call it.