Read the website. (Oh wait, this is/., nobody does that).
A system that understands the text it is compressing will compress better than one that doesn't.
The winner improved upon previous compression programs by adding semantic modelling. Improving the modeling further would improve the results. You're heading towards language understanding.
Microsoft is fighting a big battle AGAINST both formats with WMA Pro and VC-1. It makes little sense for them to release a player that supports them. It's would be like Intel adopting AMD64, but instead of it being out of necessity, doing it voluntarly.
I don't believe a word of it. Next news item: Microsoft releases Word for Linux:P
>We're running 2.4 GHz machines, and Java is just as quick and responsive >as any other app.
Do you ever regularly use Java applications? I have the impression you don't, or you wouldn't state such a plainly wrong fact.
At least on Windows (argubly by far the most important platform), as soon as there is some load, Java applications' GUI reponds MUCH slower than any native application.
I don't even think this is Java itself being slow, but the Windows kernel giving higher priority to threads that deal with UI elements. Since Java is not having a native GUI with Swing, it can't get the same treatment.
It's quite easy to test: just start something which puts heavy load on the system, then try to use a Java application. It's not hard to see where the "Swing is slow" idea comes from!
>This is a troll. "Background FSCK" isn't BSD's answer to journaling. Soft >updates is Dr. McKusick's implementation to maintain filesystem integrity in >the event of a system failure. BSD doesn't need journaling, it has soft >udpates.
Uhm, no. softupdates is a nice (and performant) way to get quick restarts when something crashes, but it isn't close to journalling at all. You still have to run fsck, and yes, it can run in the background, but it *still has to run*.
If you're looking at Terabytes of data, this is very painful and takes ages, whereas a journalling filesystem has no need to do this.
There are certainly important applications where journalling is a must. Just because most home users or small servers don't need it, doesn't mean that softupdates removes the need for it entirely.
I'm actually pretty sure FreeBSD will switch to journalling eventually.
AMD64 support is still less than stellar from what I know. I'd simply run a desktop system in 32-bit mode for now, be it Linux or FreeBSD, or you'll get bitten by the "missing/broken essential program that I really wanted" problem sooner or later.
The FreeBSD Java problems has more or less disappeared, given that there's now even an official version.
>Open source has fewer bugs irregardless of overall developers quality, >because it's the quality of the best developer that has access to the code >that matters. It doesn't matter if 99.999% of the people who have access to >the code are ignorant, or unwilling to debug it. It's enough that *one* >competent developer gets motivated to fix that bug. The more people who have >access to the code, the greater probability that among them will exist one >competent and motivated programmer.
Which in the real world never ever happens, because there's many more times crap open source code coming out than there are good programmers.
Proof: Just look at 99% of the projects on sf.net.
>In UNIX a driver does not nuke the system unless there are no alternatives, >and a great deal of effort is made to make sure this doesn't happen. In >Windows land all the DDK examples in both DOS Windows and NT, upon >encountering a problem, they are encouraged to issue a stop. (similar to a >kernel panic) rather than fail to operate.
Uhm, it's not as if the Linux kernel won't PANIC (or was it BUG, there are multiple, IIRC) if there's a problem. Your statement has no base in reality, pure FUD.
>The "stable/unstable" development model does not work so well with huge >projects like the linux kernel is.
I think FreeBSD is nice proof that you are wrong. See below.
>Remember the hell that FreeBSD 5.x was and how much has affected to the >FreeBSD project, remember windows Vista.
With FreeBSD 5.x, if you had a working system (be it 4.x), you could choose not to upgrade until the mess was sorted out. Such things are mostly impossible with Linux, because critical fixes are intermigned with new bugs.
The system is harder on the developers at the benefit of giving the users much more stability and security. I think Microsoft understands this very well.
Yes, it's pretty much the same thing. You can pick a specific RELENG version, though, like RELENG_6_0, which puts you on FreeBSD 6.0, and you will still receive all critical vulnerability patches, but no changes to anything else (which prevents regressions as in the Linux example).
2.6.16 fixed a critical vulernability over 2.6.15. It also breaks several network drivers.
There was a time when you could grab the next stable kernel, for example when there was an exploit and you really had to, and you'd know you'd only get *more* stability. Now it's exactly the opposite. If you have to upgrade, you're just screwed.
This started around the time they added reiserfs in the stable series although it was far from stable yet. It's not new in the 2.6 series, really. It's a wrong philosophy.
Compare this to FreeBSD release engineering with RELENG, STABLE and CURRENT. FreeLinux anyone?:-P
I don't care what you read. Most sources are wrong and quote each other or other wrong sources anyway.
As for quoting the FhG site as an argument, do I need to even comment on that?
But if you insist, even they state:
1991: Incorporating contributions by Hannover University, AT&T, and Thomson, the Fraunhofer team improved the OCF algorithm which yields a powerful new audio codec called ASPEC (Adaptive Spectral Perceptual Entropy Coding).
If you delve into audio coding literature, you'll find that many of the critical papers came out of AT&T, more so than out of FhG. Also, if FhG really did all the work, then why do some many other companies have essential patents on the technology? As I said, crediting MP3 almost entirely to FhG is a historical injustice. Fortunately for the other contributors, their patent income doesn't depend on what the uninformed public (specifically retarded moderators here) think:)
In all seriousness...how can this even be possible as a lawsuit. I think someone didn't refresh their browser and saw a joke news story from April 1st.
MPEG2 and all MPEG related standards are "owned" by MPEG LA, who licenses the technology. It would be one thing if Microsoft deployed a product with MPEG2 playback capabilities without paying the license, but then where is Lucent in all this? Is this some crappy dredge up of a vague compression scheme like Unisys pulled?
*Nowhere* does the MPEG LA guarantee that if you license from them that you will get _all_ patents related to the standard. In fact, you can be sure there are big disclaimers in their contracts that it's not necessarily true. The MPEG LA can't avoid more than anyone else the risk of submarine patents.
AT&T pulled a similar one a while ago with the MPEG4 video standard.
>If (as is the case of mp4), the consortium owns all of the patents required >for the mp4 concept
The whole point is that it turns out now that they don't. And given the the technology is already massively popular, AT&T can now cash in as they will dictate the terms.
AT&T does get royalities from MPEG, via the MPEG LA patent pool. However, they have sat on this video patent until the standard was popular enough, so they could force people to license it outside the patent pool.
The patent pool is supposed to ensure that you pay to a centralized enitity for usage of all patents relating to a particular standard. Without this, the standards would be hopeless, since you'd have to negotiate patent licenses with 100's of seperate companies.
What AT&T did was just sit on it until the standard was so popular that certain companies couldn't afford to _not_ support it any more, even if that means paying AT&T, well, whatever AT&T asks.
So yes, AT&T is certainly entitled to some bucks, but the way they did this undermines the whole MPEG system. One wonders what brought them to this.
Audio - yes. Video - no. AT&T is not a part of the MPEG video patent pool. So even if you got a license to legally use MPEG video, you're still screwed.
Slashdot Mirror
Read the website. (Oh wait, this is /., nobody does that).
A system that understands the text it is compressing will compress better than one that doesn't.
The winner improved upon previous compression programs by adding semantic modelling. Improving the modeling further would improve the results. You're heading towards language understanding.
Well, there *is* a restriction on the amount of time/CPU. Just read the website.
Whatever is "reasonable" is just personal preference.
>According to http://prize.hutter1.net/ this happened on Sept 25 of 2006.
There is waiting period for public comment/verification etc...
But then there would be no point in including both. (Unless MS likes to pay patent fees to it's competitors)
This makes no sense whatsoever.
:P
A Microsoft player supporting H.264 and AAC?
Microsoft is fighting a big battle AGAINST both formats with WMA Pro and VC-1. It makes little sense for them to release a player that supports them. It's would be like Intel adopting AMD64, but instead of it being out of necessity, doing it voluntarly.
I don't believe a word of it. Next news item: Microsoft releases Word for Linux
>(like chess - you need really great chess players to 'teach' the computers and, at
>some point, the computer will outplay the master).
No, you don't...all good engines are written by good programmers, not good chessplayers.
Would you want the flight control system written by a good pilot that's a basic programmer or a good programmer that's a basic pilot?
>We're running 2.4 GHz machines, and Java is just as quick and responsive
>as any other app.
Do you ever regularly use Java applications? I have the impression you don't, or you wouldn't state such a plainly wrong fact.
At least on Windows (argubly by far the most important platform), as soon as there is some load, Java applications' GUI reponds MUCH slower than any native application.
I don't even think this is Java itself being slow, but the Windows kernel giving higher priority to threads that deal with UI elements. Since Java is not having a native GUI with Swing, it can't get the same treatment.
It's quite easy to test: just start something which puts heavy load on the system, then try to use a Java application. It's not hard to see where the "Swing is slow" idea comes from!
>Stability and polish are up to the distro maintainers -- on everything. Not
>just the desktop, not just the apps, but on the kernel, too.
I think the point of the main article is that this really is becoming an unmaintainable situation.
>And Synaptic is far, far ahead of ports management on FreeBSD.
I don't use Ubuntu, but I'm curious: how does it handle the case where a config file's format has changed for the software you are upgrading?
In Gentoo this was a horrible mess. FreeBSD has mergemaster which is very good. I'm curious if there are even better ways.
>Is that the smugness of an OpenBSD user I hear in your tone? It's hard to
>tell, as your post had no real point.
He's probably pointing out that if "pf" is what you want, then you might as well use the original version in OpenBSD.
>This is a troll. "Background FSCK" isn't BSD's answer to journaling. Soft
>updates is Dr. McKusick's implementation to maintain filesystem integrity in
>the event of a system failure. BSD doesn't need journaling, it has soft
>udpates.
Uhm, no. softupdates is a nice (and performant) way to get quick restarts when something crashes, but it isn't close to journalling at all. You still have to run fsck, and yes, it can run in the background, but it *still has to run*.
If you're looking at Terabytes of data, this is very painful and takes ages, whereas a journalling filesystem has no need to do this.
There are certainly important applications where journalling is a must. Just because most home users or small servers don't need it, doesn't mean that softupdates removes the need for it entirely.
I'm actually pretty sure FreeBSD will switch to journalling eventually.
AMD64 support is still less than stellar from what I know. I'd simply run a desktop system in 32-bit mode for now, be it Linux or FreeBSD, or you'll get bitten by the "missing/broken essential program that I really wanted" problem sooner or later.
The FreeBSD Java problems has more or less disappeared, given that there's now even an official version.
>Open source has fewer bugs irregardless of overall developers quality, >because it's the quality of the best developer that has access to the code >that matters. It doesn't matter if 99.999% of the people who have access to >the code are ignorant, or unwilling to debug it. It's enough that *one* >competent developer gets motivated to fix that bug. The more people who have >access to the code, the greater probability that among them will exist one >competent and motivated programmer.
Which in the real world never ever happens, because there's many more times crap open source code coming out than there are good programmers.
Proof: Just look at 99% of the projects on sf.net.
>Microkernel is not the answer -- encapsulation is the answer.
But encapsulation means stable interfaces. Not acceptable for the Linux crowd (GPL binary drivers blablalba).
Of course you are right though. One main reason why so many things get broken is that all drivers need a rewrite on each interface change.
>In UNIX a driver does not nuke the system unless there are no alternatives,
>and a great deal of effort is made to make sure this doesn't happen. In
>Windows land all the DDK examples in both DOS Windows and NT, upon
>encountering a problem, they are encouraged to issue a stop. (similar to a
>kernel panic) rather than fail to operate.
Uhm, it's not as if the Linux kernel won't PANIC (or was it BUG, there are multiple, IIRC) if there's a problem. Your statement has no base in reality, pure FUD.
>The "stable/unstable" development model does not work so well with huge
>projects like the linux kernel is.
I think FreeBSD is nice proof that you are wrong. See below.
>Remember the hell that FreeBSD 5.x was and how much has affected to the
>FreeBSD project, remember windows Vista.
With FreeBSD 5.x, if you had a working system (be it 4.x), you could choose not to upgrade until the mess was sorted out. Such things are mostly impossible with Linux, because critical fixes are intermigned with new bugs.
The system is harder on the developers at the benefit of giving the users much more stability and security. I think Microsoft understands this very well.
Yes, it's pretty much the same thing. You can pick a specific RELENG version, though, like RELENG_6_0, which puts you on FreeBSD 6.0, and you will still receive all critical vulnerability patches, but no changes to anything else (which prevents regressions as in the Linux example).
>Certainly you agree that Windows (he didn't specify XP/2003, remember, just
>Windows in general) is known for problems like that more than Linux is?
Maybe because Windows is just more well-known in general?
2.6.16 fixed a critical vulernability over 2.6.15. It also breaks several network drivers.
:-P
There was a time when you could grab the next stable kernel, for example when there was an exploit and you really had to, and you'd know you'd only get *more* stability. Now it's exactly the opposite. If you have to upgrade, you're just screwed.
This started around the time they added reiserfs in the stable series although it was far from stable yet. It's not new in the 2.6 series, really. It's a wrong philosophy.
Compare this to FreeBSD release engineering with RELENG, STABLE and CURRENT. FreeLinux anyone?
I don't care what you read. Most sources are wrong and quote each other or other wrong sources anyway.
:)
As for quoting the FhG site as an argument, do I need to even comment on that?
But if you insist, even they state:
1991: Incorporating contributions by Hannover University, AT&T, and Thomson, the Fraunhofer team improved the OCF algorithm which yields a powerful new audio codec called ASPEC (Adaptive Spectral Perceptual Entropy Coding).
If you delve into audio coding literature, you'll find that many of the critical papers came out of AT&T, more so than out of FhG. Also, if FhG really did all the work, then why do some many other companies have essential patents on the technology? As I said, crediting MP3 almost entirely to FhG is a historical injustice. Fortunately for the other contributors, their patent income doesn't depend on what the uninformed public (specifically retarded moderators here) think
>not to mention the Fraunhofer Institute, which developed the original MP3 ...
>codec
Actually, a lot of the critical development was done at AT&T Laboratories, a US company.
Crediting Fraunhofer with MP3 is somewhat of a historical injustice. The standard was finalized with contributions from a dozen companies.
>If (as is the case of mp4), the consortium owns all of the patents required
>for the mp4 concept
The whole point is that it turns out now that they don't. And given the the technology is already massively popular, AT&T can now cash in as they will dictate the terms.
AT&T does get royalities from MPEG, via the MPEG LA patent pool. However, they have sat on this video patent until the standard was popular enough, so they could force people to license it outside the patent pool.
The patent pool is supposed to ensure that you pay to a centralized enitity for usage of all patents relating to a particular standard. Without this, the standards would be hopeless, since you'd have to negotiate patent licenses with 100's of seperate companies.
What AT&T did was just sit on it until the standard was so popular that certain companies couldn't afford to _not_ support it any more, even if that means paying AT&T, well, whatever AT&T asks.
So yes, AT&T is certainly entitled to some bucks, but the way they did this undermines the whole MPEG system. One wonders what brought them to this.
Audio - yes. Video - no. AT&T is not a part of the MPEG video patent pool. So even if you got a license to legally use MPEG video, you're still screwed.