I still think it's a shame Mono has gone off doing C# when the analogous project based on Java would already be much further along--there are several free, open source Java compilers, a good open source JIT from Intel, and lots of library code. Furthermore, such a Java project could have started several years ago, when the Gnome crowd was still claiming that anything other than plain C was just not suitable for writing applications or GUIs in.
It looks like the Mono project still has a couple of years of work ahead of them until they get to a reasonably full features C# implementation. Let's hope it's worth it.
Competing with Microsoft isn't easy, but Netscape was doing just fine until it started falling more and more behind IE in terms of functionality and performance. And Netscape fell behind because it tried to pursue all sorts of pie-in-the-sky stuff instead of focussing on cleaning up its codebase.
Yes, Microsoft did do illegal things, and Microsoft should get punished for that. But what Microsoft did wasn't sufficient to kill Netscape. Netscape killed Netscape.
There have been plenty of all-in-one LCD computers prior to that--they are called "laptops". And there have also been non-laptop all-in-one computers prior to the Mac; they were used in many industrial applications.
The 20th Anniversary Macintosh also resembles the Compaq Concerto. The Concerto not only had a smaller footprint while providing the same functionality, but also could be used as a laptop and as a pen computer.
While the Concerto is really old now and was too heavy as a pen computer, as a laptop and as a desktop machine, it was an elegant, unpretentious, and practical. I would find an iMac with that form factor much more appealing than what Apple actually came up with.
Re:Missing innovation in iMac/Profile
on
iMac LCD Impostors
·
· Score: 2
Jobs actually talked about that. He said the main reason they didn't have wireless keyboards was because they didn't have a good way of powering them yet. When a wireless keyboard runs out of power, it's definitely not very intuitive, and if you are out of batteries and it's your only keyboard, you have a real problem.
The article talks about how Gateway will want to compete with the iMac. There is no indication that Gateway will clone the design. In fact, it rather looks like Gateway will simply come out with a cleaner-looking, thinner version of the Gateway 3: no floating screen, but a screen with the CPU integrated into it. If they make it look nice and sell it at a reasonable price, that could be a great machine. And, unlike Apple, Gateway seems like they are smart enough to offer a 17" screen on a $2000 machine.
Apple isn't the first company to come up with a computer with a floating screen and the CPU in the base--IBM (and perhaps others) did that a few years ago (IBM's earlier designs actually were nicer looking than the current X series).
Personally, I find this kind of design gimmicky anyway. With the Graphite iMac, Apple hit a design sweet spot, but the new iMacs don't do it for me--they atttract too much attention. To me, something like a high-end Sony LCD with a computer the size of an Espresso PC (about the footprint of a CD case) looks much nicer. Sorry, Apple.
We already have an encumbered, open-source Java-like runtime, Sun's Java implementation itself. It's very mature and very complete and it's the industry standard.
If Microsoft wants to gain ground, they need to do better. That would mean an LGPL or BSD licensed, high-quality and high-performance CLI. If they can't do that, then they might as well forget it. A Microsoft "community source license" is even less attractive than a Sun community source license, and Microsoft's technology, so far, is less mature and less complete than Sun's.
I think the bad economy forced people to figure out that that hardware was undervalued. In particular if you are running Linux, a 200MHz laptop is a great machine for just about anything you might want to do.
Where we really need improvements are with battery life and screens, and those are slow in coming along. There are some hard technological and design problems there (how do you fit a 17" screen into a 10" package without making your users look like the Borg?).
There are some special purpose digital cameras for whiteboard capture. Take a look at the HawkEye
Of course, for casual whiteboard capture, any modern digital camera will do.
There are lots of conductive plastics, so this isn't exactly new. Furthermore, you can bend wires into any shape you want. It may or may not be a little more expensive to manufacture, but a company that wanted to have an antenna that doesn't stick out could bend a wire and route it around the case. Or, they can just print the antenna on a flexible printed circuit board (which some do). In fact, many cell phones have the antenna be an integral part of the case.
In fact, there are several cell phones that use integral antennas. Why don't all have it? I suspect it's because an antenna that sticks out beyond the part of the phone that is covered by your hand probably works better.
Re:I hope MPEG-4 fails
on
More on MPEG4
·
· Score: 2
Mixing video and film source at their native frame rates is very useful if you're dealing with content that is mixed film and video source. Like a "making of" documentary. It also isn't hard to do: you let each frame have its own duration, instead of having a global frame rate for the file. QuickTime had this working fine in 1991, on 20 MHz computers.
For someone who presents this standard as being a boon for such a wide range of uses, that is a very narrow view.
No, playing mixed rate content on a general purpose computer isn't all that hard. But
for processing the content in any interesting way, it's an enormous burden. All of a sudden, for every interframe computation, I have to worry about different timings. I mean, what thresholds am I even supposed to use for automatic scene cut detection? How are motion analysis algorithms supposed to deal with the transition? How am I supposed to handle cases that integrate information over several seconds? How am I supposed to do an FFT along the time dimensions with non-uniform temporal samples?
There are answers to all of those (a fairly simple one is to cut the video apart into separate clips whenever the framerate changes, but that's kind of expensive), but they are a headache I don't need. Most developers won't even think of this possibility before their product fails and they get a bug report, or, worse, they'll just generate bad output.
And for what is all that complexity there? There are much simpler ways of dealing with a succession of video clips at different frame rates than making it part of the stream format. This functionality in MPEG-4 is completely redundant, and there are lots more issues like that lurking in the MPEG-4 standard.
It's wrong to think of MPEG-4 as "a single standard" in the sense that any implementation needs to handle all of the spec. A given implementation only needs to handle the Profile@Level it targets, which vary wildly in complexity.
As a developer, either I don't handle the oddball cases that most sane people will never use, in which case I take a beating from a vocal minority of users, or I handle them, in which case I have to invest a lot of extra work for no useful functionality. The failure of the MPEG-4 committee to make the hard choices is one of the things that makes the standard so bad. How is living with a handful of different "profiles" much better than living with a handful of different video formats?
But is that open-source codec going to work with new mobile phones from different vendors, over lossy networks?
No, it's not. But that's not because of some technical limitations, it's because the MPEG-LA members will push their proprietary technology into products whether users want it or not. That's just adding insult to injury.
Re:I hope MPEG-4 fails
on
More on MPEG4
·
· Score: 2
MPEG-4 is meant to solve much more complex problems. You might want to read through the "MPEG-4 Applications" document, which describes what the design goals of MPEG-4, and sample ways to use it.
I did read through the MPEG-4 documents. In fact, I was representing my company at the time (we were developing multimedia databases and video processing solutions) at the MPEG-4 meetings for a while until I quit over the futility of the effort. MPEG-4 was going to happen in the same way bad weather happens: you can anticipate it, you can't do anything about it, and you'll just have to live with it and contain the damage it causes.
E.g., AVI and ASF can't mix sections of 29.97 and 24 fps content in a single file. Might not sound like a big deal, but it is a huge deal for some kinds of content.
See, the fact that you think that that's even a good idea shows that you just don't get it. Try working out a cost/benefit analysis for supporting that feature alone.
Saying that MPEG-4 is overly complex is like saying the international phone system is overly complex because all you want to do is store compressed speech in a file on your computer. It may be overly complex for what you personally want to do, but not for the people who created it.
By that argument, why don't we define a single standard for all electrical, electronic, and data processing devices? Wouldn't it be great? Everything could talk to everything else. Well, the real world doesn't work that way.
In my view, good standards are focussed, standardize existing practice, and are reasonably easy to implement. MPEG-4 satisfies none of those criteria. When the need arises for two different pieces of functionality to be brought together, then, and no sooner, do you start standardizing the combination.
To me, MPEG-4 is intellectual self-gratification by a group of academics and developers from large companies. It's an attempt to push their technology and pipe dreams onto the public, irrespective of demand or needs. Demand and needs are a simple, scalable, easy-to-implement, patent-unencumbered video and audio codec. And, by gosh, open source is going to supply that. Unless the MPEG-4 cartell manages to push MPEG-4 through business and legal maneuvers, MPEG-4 will fail, as it should.
Re:I hope MPEG-4 fails
on
More on MPEG4
·
· Score: 2
Just being able to play a rectangular movie with audio isn't even scratching the surface.
Who cares? I want a good video compression format. Something that's simple, portable, free, and widely used. Telling me that I really want something else is futile because I know I don't want something else. And I suspect most people who look at MPEG-4 are in my boat. MPEG-4 just doesn't fulfill that need very well.
Going forward anyone who needs to develop a new media tool can start with MPEG-4, instead of starting with scratch.
Why should the do so? The MPEG-4 standard is not very good at those other things. It would be a waste of resources to try and comply with it.
MPEG-4 is a big toolbox of features that can be used to build many different solutions
No. MPEG-4 is a big set of descriptions and rules for how to build a toolbox. That doesn't help me get my work done faster, it makes my work more difficult.
It's important that the open source community understand that building a real competitior to MPEG-4 is a task on the order of magnitude of building an OS from scratch.
And my point is that the way to win is not to play the MPEG-4 game, but instead to deliver a focussed codec just for video compression. As for all the other stuff, the open source community has pretty much all the functionality already implemented that are part of MPEG-4, they are just not implemented using MPEG-4 formats and they are not integrated. And that's good as far as I'm concerned.
I think MPEG-4 will end up like TIFF: a small subset of it is supported grudgingly by some software libraries and many devices, but the rest of the world will move on to greener pastures. TIFF could have become the default image format for the web, but its complexity and generality killed it, among other things because implementations never ended up interoperating well.
What could catch on? Perhaps a good open source codec with an almost trivial stream format. And for people who want a more general container format and love the complexity, that stream encapsulated into Quicktime might address their needs. MPEG-4 doesn't enter into the picture.
Re:I hope MPEG-4 fails
on
More on MPEG4
·
· Score: 2
Bandwidth has gotten cheaper much faster than screen resolution has increased. And that means that the task of designing a video codec has gotten a lot simpler than it used to be. Whether it is "cheap" in an absolute sense is hard to say. Having several times the bandwidth a T1 connection at home for $60/month suggests to me that it has become cheap even in an absolute sense.
I hope MPEG-4 fails
on
More on MPEG4
·
· Score: 5, Insightful
I agree with Ben Waggoner: MPEG-4 was designed by a large committee of industry experts and open source codecs don't have a prayer of reaching the complexity of MPEG-4. And you know what? That's a good thing.
MPEG-4 is a complete mess. It tries to be the next generation MPEG-2, flash, speech synthesis, content management, and a lot more things all rolled into one. And MPEG-4 tries to serve too many masters: software encoders and decoders, consumer electronics devices, industrial applications, multimedia databases, and others. If MPEG-LA prices MPEG-4 out of the market, we can all sigh a collective sigh of relief because the MPEG-4 standard just sucks. MPEG-4 would be a bad idea even if there were no licensing fees.
What we need is a simple, scalable video codec. It does not have to have any bells and whistles. All it needs to do is represent a video stream and a collection of audio streams together. It should get rid of the interlacing mess from MPEG-2, it should allow for video of different sizes, and maybe it should allow for the inclusion of user-defined synchronized byte streams, and that's about it.
Open source video codec developers do not have to worry about low-level hardware implementability (that only matters for cut-throat pricing on devices you don't really want to use anyway; anything else can get a general-purpose processor), they don't have to worry about making DVD manufacturers happy, and they don't need to squeeze the last 50% of compression out of their format (machines and disks are cheap). There are now plenty of well-documented research techniques for audio and video compression, some even with open source implementation, that open source developers can use.
So, no, nobody would be able to compete with MPEG-4. But what open source video codecs can deliver is a simple, reasonably efficient, scalable, easily implementable video codec. And that's a lot better than MPEG-4.
You say that as if convolution and removing high frequency components from the spectrum (say, using an FFT) are significantly different techniques; they aren't. Things get a little more interesting once you go to non-linear techniques.
But, ultimately, font smoothing and anti-aliasing are limited techniques: a gray square just isn't the same as a white square with a thin black line running through it, no matter how much processing you do to decide on the shade of gray.
It's hard to compare these things via screen shots because a good antialiasing engine will take into account the kind of monitor you are using.
However, in my subjective judgement, the MacOS9 screenshot you provide is just awful, both when viewed on an LCD and a regular CRT (but you may be using a weird gamma). Not only is the font too small to be anti-aliased usefully, the same page mixes anti-aliased and non-anti aliased text.
The nicest rendering of the page is perhaps on XP using ClearType, not because of anti-aliasing, but because it gets a somewhat higher resolution at the same pixel size. MacOSX with font smoothing on a CRT also looks pretty nice to me. Unlike your screenshot, both XP and OSX use smoothing more consistently, which probably contributes to the improved appearance.
However, with font smoothing in both XP and OSX, diagonal lines become too thinned out, and if you go down in font size further, the page becomes an unreadable blur. Arguably, the non-smoothed/non-anti aliased version of the page (which I tried on both XP and Linux), is still the most readable, and it looks sharp, consistent, and readable at font sizes even smaller than what your page shows.
As I was saying, anti-aliasing makes some large fonts more pleasing to look at but it doesn't seem to improve readability much, and you run the risk of severely degrading readability and appearance on some pages. Anti-aliasing and font smoothing do belong in PhotoShop and similar applications, where the goal is to make a small amount of large text look nice; for interactive use, they are mostly gimmicks as far as I'm concerned. If you want nicer looking text on a display, your best bet is to buy a higher resolution monitor or to use something like ClearType.
(Discussing the differences in meaning between "font smoothing" and "anti-aliasing" could fill another page.)
Your company could just develop a priorietary work-alike of the GPL'ed library. You already get complete source code to a sample implementation, a design, algorithms, and probably documentation. That's more than enough to make it really easy to develop your own version. You can even out-source that to India or China for a pittance. And there would be nothing wrong with that: the idea of open source is that you look at it and learn from it.
Instead, your company is embarking on some hare-brained, complicated scheme to try to defraud open source developers, risking a legal injunction against their product, damages, and the wrath (and competition) of open source developers.
Obviously, there is something fundamentally wrong with your company's management, ethics, and business plan. I recommend jumping ship now, before the s*** hits the fan.
Bzzzt. Printing is analog, it's naturally anti-aliased.
Well, maybe that's what they tell the arts majors. However, the term "aliasing" actually refers to what happens when you try to exceed the Nyquist limit: different frequencies are "aliased" together. Anti-aliasing removes that by band-limiting the signal in some way prior to sampling. When you print with toner on paper, there is nothing band-limited about the resulting image: the toner/paper transition has very high contrast edges at just about any resolution you care to look and those result in very high frequency components in the image.
the fact the the text doesn't look butt-ugly as usual.
You demonstrate a common occupational hazard for people working in graphics: you prefer style over function.
Think about anti-aliased text on a 150 dpi monitor.
For most monitors, you wouldn't even be able to tell the difference. And for a high-resolution monitor designed to display text, you make the display worse if you try to anti-alias.
Usually. What about when it isn't?
If you composite onto an image, the text needs to undergo the same filtering as the the image has undergone or it will look unnatural. In the case of compositing text into television images, there happens to be a single answer because, by convention, television cameras try to degrade the image in roughly the same traditional way. For digital images you find on computers, the filter could be anything.
Computer text is usually rendered onto a solid color and displayed on a high-quality, high-bandwidth device. That has almost nothing to do with rendering text for overlay onto a pictorial background and display on a low-pass, noisy device like broadcast television. Rendering text for GUIs the way you render it for television would be like slapping people in the face to get their attention and just would drive them crazy.
Anti-aliasing for computer displays is overrated anyway. Whether it helps or hurts readability depends on the font and font size, and on high resolution displays it is pointless. Printed matter isn't anti-aliased either, and printed matter is the gold standard for good looking text.
So, if you want text that looks nice, get yourself a 150dpi or higher monitor and don't bother with anti-aliasing. Anything else is a kludge.
Sure, it finally gives you some reasonable I/O and power management functionality on PC hardware. But it is really an ugly kludge on top of lousy hardware. It is just stunning how many things about interrupts, I/O regions, and power management the PC architecture managed to get wrong. ACPI only "rocks" because a decade and a half of PC hardware have lowered expectations so much.
So, you are saying that as long as our boys come home anything goes? Sorry, but that's not the way war works. Nations that don't stick to the ground rules of war are considered rogue nations, and the US does not want to fall into that category. If it ever did, the US would find itself at the receiving end of trade sanctions, embargoes, and worse. No nation, not even the US, can unilaterally decide what the ground rules for war are.
If you are worried about people sitting behind desks condemning soldiers and civilians to death, worry about the politicians that start these wars. None of the wars the US has engaged in since WWII have had much justification in US "defense", nor have they been particularly effective.
Your cell phone operates in the GHz range and probably uses digital coding, so it's largely impervious to anything but very large levels of noise. Your radio stations are frequency modulated and less susceptible to noise.
It's amplitude modulated signals and shortwave that are most susceptible to interference. Consumer devices don't use those much anymore, but they are still widely used by amateur radio operators, scientific equipment, and public service organizations.
Turn your radio to an AM station or try a shortwave receiver and you'll probably see a lot of interference.
I don't see any mention of shielding on their web site. If you cause interference with a PC using this case (and you probably will), you may be forced to stop operating it. In any case, it just isn't very nice to your neighbors to run an unshielded computer.
I hope the Canadian equivalent of the FCC will stop this company from selling the case. Selling unshielded computer cases just is pretty irresponsible.
It looks like the Mono project still has a couple of years of work ahead of them until they get to a reasonably full features C# implementation. Let's hope it's worth it.
Yes, Microsoft did do illegal things, and Microsoft should get punished for that. But what Microsoft did wasn't sufficient to kill Netscape. Netscape killed Netscape.
There have been plenty of all-in-one desktop LCD computers prior to the 20th anniversary mac, not to mention zillions of laptops.
The 20th Anniversary Macintosh also resembles the Compaq Concerto. The Concerto not only had a smaller footprint while providing the same functionality, but also could be used as a laptop and as a pen computer.
While the Concerto is really old now and was too heavy as a pen computer, as a laptop and as a desktop machine, it was an elegant, unpretentious, and practical. I would find an iMac with that form factor much more appealing than what Apple actually came up with.
Jobs actually talked about that. He said the main reason they didn't have wireless keyboards was because they didn't have a good way of powering them yet. When a wireless keyboard runs out of power, it's definitely not very intuitive, and if you are out of batteries and it's your only keyboard, you have a real problem.
Apple isn't the first company to come up with a computer with a floating screen and the CPU in the base--IBM (and perhaps others) did that a few years ago (IBM's earlier designs actually were nicer looking than the current X series).
Personally, I find this kind of design gimmicky anyway. With the Graphite iMac, Apple hit a design sweet spot, but the new iMacs don't do it for me--they atttract too much attention. To me, something like a high-end Sony LCD with a computer the size of an Espresso PC (about the footprint of a CD case) looks much nicer. Sorry, Apple.
If Microsoft wants to gain ground, they need to do better. That would mean an LGPL or BSD licensed, high-quality and high-performance CLI. If they can't do that, then they might as well forget it. A Microsoft "community source license" is even less attractive than a Sun community source license, and Microsoft's technology, so far, is less mature and less complete than Sun's.
Where we really need improvements are with battery life and screens, and those are slow in coming along. There are some hard technological and design problems there (how do you fit a 17" screen into a 10" package without making your users look like the Borg?).
There are some special purpose digital cameras for whiteboard capture. Take a look at the HawkEye Of course, for casual whiteboard capture, any modern digital camera will do.
In fact, there are several cell phones that use integral antennas. Why don't all have it? I suspect it's because an antenna that sticks out beyond the part of the phone that is covered by your hand probably works better.
For someone who presents this standard as being a boon for such a wide range of uses, that is a very narrow view.
No, playing mixed rate content on a general purpose computer isn't all that hard. But for processing the content in any interesting way, it's an enormous burden. All of a sudden, for every interframe computation, I have to worry about different timings. I mean, what thresholds am I even supposed to use for automatic scene cut detection? How are motion analysis algorithms supposed to deal with the transition? How am I supposed to handle cases that integrate information over several seconds? How am I supposed to do an FFT along the time dimensions with non-uniform temporal samples?
There are answers to all of those (a fairly simple one is to cut the video apart into separate clips whenever the framerate changes, but that's kind of expensive), but they are a headache I don't need. Most developers won't even think of this possibility before their product fails and they get a bug report, or, worse, they'll just generate bad output.
And for what is all that complexity there? There are much simpler ways of dealing with a succession of video clips at different frame rates than making it part of the stream format. This functionality in MPEG-4 is completely redundant, and there are lots more issues like that lurking in the MPEG-4 standard.
It's wrong to think of MPEG-4 as "a single standard" in the sense that any implementation needs to handle all of the spec. A given implementation only needs to handle the Profile@Level it targets, which vary wildly in complexity.
As a developer, either I don't handle the oddball cases that most sane people will never use, in which case I take a beating from a vocal minority of users, or I handle them, in which case I have to invest a lot of extra work for no useful functionality. The failure of the MPEG-4 committee to make the hard choices is one of the things that makes the standard so bad. How is living with a handful of different "profiles" much better than living with a handful of different video formats?
But is that open-source codec going to work with new mobile phones from different vendors, over lossy networks?
No, it's not. But that's not because of some technical limitations, it's because the MPEG-LA members will push their proprietary technology into products whether users want it or not. That's just adding insult to injury.
I did read through the MPEG-4 documents. In fact, I was representing my company at the time (we were developing multimedia databases and video processing solutions) at the MPEG-4 meetings for a while until I quit over the futility of the effort. MPEG-4 was going to happen in the same way bad weather happens: you can anticipate it, you can't do anything about it, and you'll just have to live with it and contain the damage it causes.
E.g., AVI and ASF can't mix sections of 29.97 and 24 fps content in a single file. Might not sound like a big deal, but it is a huge deal for some kinds of content.
See, the fact that you think that that's even a good idea shows that you just don't get it. Try working out a cost/benefit analysis for supporting that feature alone.
Saying that MPEG-4 is overly complex is like saying the international phone system is overly complex because all you want to do is store compressed speech in a file on your computer. It may be overly complex for what you personally want to do, but not for the people who created it.
By that argument, why don't we define a single standard for all electrical, electronic, and data processing devices? Wouldn't it be great? Everything could talk to everything else. Well, the real world doesn't work that way.
In my view, good standards are focussed, standardize existing practice, and are reasonably easy to implement. MPEG-4 satisfies none of those criteria. When the need arises for two different pieces of functionality to be brought together, then, and no sooner, do you start standardizing the combination.
To me, MPEG-4 is intellectual self-gratification by a group of academics and developers from large companies. It's an attempt to push their technology and pipe dreams onto the public, irrespective of demand or needs. Demand and needs are a simple, scalable, easy-to-implement, patent-unencumbered video and audio codec. And, by gosh, open source is going to supply that. Unless the MPEG-4 cartell manages to push MPEG-4 through business and legal maneuvers, MPEG-4 will fail, as it should.
Who cares? I want a good video compression format. Something that's simple, portable, free, and widely used. Telling me that I really want something else is futile because I know I don't want something else. And I suspect most people who look at MPEG-4 are in my boat. MPEG-4 just doesn't fulfill that need very well.
Going forward anyone who needs to develop a new media tool can start with MPEG-4, instead of starting with scratch.
Why should the do so? The MPEG-4 standard is not very good at those other things. It would be a waste of resources to try and comply with it.
MPEG-4 is a big toolbox of features that can be used to build many different solutions
No. MPEG-4 is a big set of descriptions and rules for how to build a toolbox. That doesn't help me get my work done faster, it makes my work more difficult.
It's important that the open source community understand that building a real competitior to MPEG-4 is a task on the order of magnitude of building an OS from scratch.
And my point is that the way to win is not to play the MPEG-4 game, but instead to deliver a focussed codec just for video compression. As for all the other stuff, the open source community has pretty much all the functionality already implemented that are part of MPEG-4, they are just not implemented using MPEG-4 formats and they are not integrated. And that's good as far as I'm concerned.
I think MPEG-4 will end up like TIFF: a small subset of it is supported grudgingly by some software libraries and many devices, but the rest of the world will move on to greener pastures. TIFF could have become the default image format for the web, but its complexity and generality killed it, among other things because implementations never ended up interoperating well.
What could catch on? Perhaps a good open source codec with an almost trivial stream format. And for people who want a more general container format and love the complexity, that stream encapsulated into Quicktime might address their needs. MPEG-4 doesn't enter into the picture.
Bandwidth has gotten cheaper much faster than screen resolution has increased. And that means that the task of designing a video codec has gotten a lot simpler than it used to be. Whether it is "cheap" in an absolute sense is hard to say. Having several times the bandwidth a T1 connection at home for $60/month suggests to me that it has become cheap even in an absolute sense.
MPEG-4 is a complete mess. It tries to be the next generation MPEG-2, flash, speech synthesis, content management, and a lot more things all rolled into one. And MPEG-4 tries to serve too many masters: software encoders and decoders, consumer electronics devices, industrial applications, multimedia databases, and others. If MPEG-LA prices MPEG-4 out of the market, we can all sigh a collective sigh of relief because the MPEG-4 standard just sucks. MPEG-4 would be a bad idea even if there were no licensing fees.
What we need is a simple, scalable video codec. It does not have to have any bells and whistles. All it needs to do is represent a video stream and a collection of audio streams together. It should get rid of the interlacing mess from MPEG-2, it should allow for video of different sizes, and maybe it should allow for the inclusion of user-defined synchronized byte streams, and that's about it.
Open source video codec developers do not have to worry about low-level hardware implementability (that only matters for cut-throat pricing on devices you don't really want to use anyway; anything else can get a general-purpose processor), they don't have to worry about making DVD manufacturers happy, and they don't need to squeeze the last 50% of compression out of their format (machines and disks are cheap). There are now plenty of well-documented research techniques for audio and video compression, some even with open source implementation, that open source developers can use.
So, no, nobody would be able to compete with MPEG-4. But what open source video codecs can deliver is a simple, reasonably efficient, scalable, easily implementable video codec. And that's a lot better than MPEG-4.
But, ultimately, font smoothing and anti-aliasing are limited techniques: a gray square just isn't the same as a white square with a thin black line running through it, no matter how much processing you do to decide on the shade of gray.
However, in my subjective judgement, the MacOS9 screenshot you provide is just awful, both when viewed on an LCD and a regular CRT (but you may be using a weird gamma). Not only is the font too small to be anti-aliased usefully, the same page mixes anti-aliased and non-anti aliased text.
The nicest rendering of the page is perhaps on XP using ClearType, not because of anti-aliasing, but because it gets a somewhat higher resolution at the same pixel size. MacOSX with font smoothing on a CRT also looks pretty nice to me. Unlike your screenshot, both XP and OSX use smoothing more consistently, which probably contributes to the improved appearance.
However, with font smoothing in both XP and OSX, diagonal lines become too thinned out, and if you go down in font size further, the page becomes an unreadable blur. Arguably, the non-smoothed/non-anti aliased version of the page (which I tried on both XP and Linux), is still the most readable, and it looks sharp, consistent, and readable at font sizes even smaller than what your page shows.
As I was saying, anti-aliasing makes some large fonts more pleasing to look at but it doesn't seem to improve readability much, and you run the risk of severely degrading readability and appearance on some pages. Anti-aliasing and font smoothing do belong in PhotoShop and similar applications, where the goal is to make a small amount of large text look nice; for interactive use, they are mostly gimmicks as far as I'm concerned. If you want nicer looking text on a display, your best bet is to buy a higher resolution monitor or to use something like ClearType.
(Discussing the differences in meaning between "font smoothing" and "anti-aliasing" could fill another page.)
Instead, your company is embarking on some hare-brained, complicated scheme to try to defraud open source developers, risking a legal injunction against their product, damages, and the wrath (and competition) of open source developers.
Obviously, there is something fundamentally wrong with your company's management, ethics, and business plan. I recommend jumping ship now, before the s*** hits the fan.
Well, maybe that's what they tell the arts majors. However, the term "aliasing" actually refers to what happens when you try to exceed the Nyquist limit: different frequencies are "aliased" together. Anti-aliasing removes that by band-limiting the signal in some way prior to sampling. When you print with toner on paper, there is nothing band-limited about the resulting image: the toner/paper transition has very high contrast edges at just about any resolution you care to look and those result in very high frequency components in the image.
the fact the the text doesn't look butt-ugly as usual.
You demonstrate a common occupational hazard for people working in graphics: you prefer style over function.
Think about anti-aliased text on a 150 dpi monitor.
For most monitors, you wouldn't even be able to tell the difference. And for a high-resolution monitor designed to display text, you make the display worse if you try to anti-alias.
Usually. What about when it isn't?
If you composite onto an image, the text needs to undergo the same filtering as the the image has undergone or it will look unnatural. In the case of compositing text into television images, there happens to be a single answer because, by convention, television cameras try to degrade the image in roughly the same traditional way. For digital images you find on computers, the filter could be anything.
Anti-aliasing for computer displays is overrated anyway. Whether it helps or hurts readability depends on the font and font size, and on high resolution displays it is pointless. Printed matter isn't anti-aliased either, and printed matter is the gold standard for good looking text.
So, if you want text that looks nice, get yourself a 150dpi or higher monitor and don't bother with anti-aliasing. Anything else is a kludge.
Sure, it finally gives you some reasonable I/O and power management functionality on PC hardware. But it is really an ugly kludge on top of lousy hardware. It is just stunning how many things about interrupts, I/O regions, and power management the PC architecture managed to get wrong. ACPI only "rocks" because a decade and a half of PC hardware have lowered expectations so much.
If you are worried about people sitting behind desks condemning soldiers and civilians to death, worry about the politicians that start these wars. None of the wars the US has engaged in since WWII have had much justification in US "defense", nor have they been particularly effective.
It's amplitude modulated signals and shortwave that are most susceptible to interference. Consumer devices don't use those much anymore, but they are still widely used by amateur radio operators, scientific equipment, and public service organizations.
Turn your radio to an AM station or try a shortwave receiver and you'll probably see a lot of interference.
No, just an amateur radio operator. There's nothing to "sell". Cheap metal cases are very nicely shielded; use them.
I hope the Canadian equivalent of the FCC will stop this company from selling the case. Selling unshielded computer cases just is pretty irresponsible.