OK, smart-ass. How about "Conceptually, RAM chips are pretty easy to design." Is that better? As for the "I never said the design process was easy" statement, the key word here is process. The thread devolved into a discussion of the competitive pressures placed on RAM manufacturers and the tweaking they have to do to the process in order to squeeze more bit density into a chip. But you'd know that from reading the thread...
Memory is easy to design if you never plan to sell it. If you want to be competitve in the market, it is insanely difficult.
I never said the design process was easy. I just said I wouldn't characterize the end-product as intricate. And really, the engineering effort, as I understand it, goes into packing the bits tighter -- how to make each cell as small as possible. Once you have figured out the tricks, laying out a grid of cells isn't rocket science. Scaling your grid larger works up to a point, until the chip gets too big to be profitable.
I also think your assertion that CPU design is "a bunch of hdl that you can get 10 trained monkeys to write" is a gross exaggeration and an insult to CPU designers. I'll agree, though, that process refinement is tricky business.
But none of this speaks to my point that I wouldn't use "intricate" to describe RAM design. (See my other reply in another subthread of this discussion.)
While everything you say may be true, my objection was to the use of the term "intricate" to describe RAM chip design. The layout isn't intricate at all. It is a highly regular structure. Not convoluted. Not intricate.
To bolster my point, let's look at the definition of the word intricate: "1. Having many complexly arranged elements; elaborate. 2. Solvable or comprehensible only with painstaking effort. Complex."
The physical structure does not satisfy the definition of "intricate." The complexity of RAM development stems from the inherent problems of solid-state physics that must be gotten around to pack the bits ever more densely. The economic drive to be competitive forces innovations in increasing bit density, but once the design work is done and the production process has been tweaked... that's it. The end result might be a marvel of engineering, but it's not intricate as the word is defined, sorry. Maybe the engineering process could be described as intricate (though I would consider this a stretch), but not the end result.
While it may well be that the compression algorithms are an integral part of the file formats in question, that's not the issue I was addressing. You are committing a logical fallacy by trying to conflate two separate issues. (Note also that I do not agree to your "inseparable" claim, see below.)
I was responding to this assertion:
If, as you say, that file formats are not patentable, trademarkable, or copyrightable, then how do you explain problems with GIF and JPEG file formats, just to mention a couple off the top of my head?
The Anonymous Coward who wrote this apparently does not believe that file formats are not patentable.
File formats are not patentable. Period. In the case of GIF and JPEG, the compression algorithms are where the patents lie. These compression algorithms exist independently of the GIF and JPEG file formats, and in fact have other applications. (The LZW algorithm utilized by GIF was used for years in hardware applications, such as hard disk controllers. That's why the LZW patent was granted in the first place -- because at the time, you had to have a concrete implementation of an algorithm in firmware/hardware to claim a patent on an algorithm. It's only recently that algorithms have been patented on their own without regard to concrete implementation.)
Believe me, a image viewer which claims to support GIFs (but only if they're uncompressed) is not going to be taken seriously.
And this is an argument why? (That was a rhetorical question. You've committed a logical fallacy.) You haven't even addressed the issue I've raised.
Bottom line, someone asserted that file formats are not patentable, some AC refuses to believe this fact, and I responded with facts. The fact is, the file formats themselves are not patented. Technologies that these file formats rely upon are patented, which is not the same thing. You're trying to conflate the two, and you can't. The other AC to whom I was responding was attempting to conflate these two issues, and was equally wrong.
The mere fact that these compression algorithms exist independently of the GIF and JPEG file formats, and the fact that they have other applications entirely separate from their use in GIF and JPEG, proves that these compression algorithms are not "inseparable" from the file formats, as you asserted. (Inseparable would imply that the algorithms can not stand on their own as much as it would imply that the file formats can't stand on their own. While the latter may be true, the former is not.)
A file format is just a uniform way to put data into a file for a specific purpose. A file format, then, is uniquely identified by the structure of the data and by the other technologies that may be leveraged, such as certain transformations that must be applied to the data. While the specification for a file format may reference an algorithm used for data transformation, the algorithm itself isn't usually given in the specification. In the case of JPEG and GIF, those algorithms are externally referenced, although a reference implementation (or suggestions for implementation) may be provided. Some of the old Compuserve GIF documentation gave tips on implementing LZW in software, for instance.
The point I'm making is, if someone patents an algorithm for compressing data, and that algorithm is relied upon for writing e.g. GIF files, the patent is not on the file format, it is on the compression algorithm, period. To speak otherwise is to confuse matters. When the AC to whom I initially responded posed the question "If, as you say, that file formats are not patentable, trademarkable, or copyrightable, then how do you explain problems with GIF and JPEG file formats[...]?" he was trying to imply that GIF and JPEG were proof that file formats were patentable. This is not the case, and I think I've proven my point. One thing does not logically follow from the other.
I know that this is already done with some flash memory chips on the market -- there are spare cells which become active as other cells become unreliable or unusable. Flash memory has a finite number of write cycles, so this practice is a cheap way to extend the life of a flash chip.
Of course, flash memory relies on a file system to do a lot of the heavy lifting...
As for DRAM... well, the logic to map out bad bits would have to reside on the chip, thus increasing real-estate consumption. So the chips would have to grow bigger to accommodate the logic to do this, and that would lower yields. This might negate any gains from having the logic there in the first place!
I recognize that the RAM is, if not the, then one of the most intricate and cost-intensive parts to produce and to purchase.
Well, I can't speak to the cost-intensive part of your assertion, since I am not privy to some details about the economics of chip production. But intricate? Not hardly. DRAM and SRAM chips are laid out mostly in a grid, with very little real-estate set aside for control logic. The only complexity is the control logic; the rest of the chip is just a matrix of transistors (and, in the case of DRAM, one capacitor per transistor to actually store the bit).
RAM chips are pretty easy to design and lay out because of the inherent regularity in their structure.
If, as you say, that file formats are not patentable, trademarkable, or copyrightable, then how do you explain problems with GIF and JPEG file formats, just to mention a couple off the top of my head?
Because the legal problems with GIF and JPEG stemmed from the compression algorithms used by these file formats, and not from the file formats themselves. Just like the original poster said, dipshit. Learn to do a little research first.
Interestingly enough, I set up a TiVo Series 2 last night for the first time, and noticed something. There's a LED back-light for the TiVo logo on the front of the unit, and this back-light can be configured in software -- there's a menu item to set the level of illumination behind the TiVo logo (or turn it off altogether). So software controlled variable illumination in a piece of hardware (specifically, chassis illumination) has certainly been done before, albeit not on the scale probably implied by the Apple patent. The TiVo faceplace is translucent; presumably, an array of LEDs could be placed behind such a plastic plate to provide patterning, but I doubt this has much value for a device that is going to sit under your TV or in a stereo rack next to it. I believe the backlight for the TiVo logo is also a monochrome white LED, so that's one minor difference.
Is this the next logical step after ditching 'e-mail' in favor of 'email'
Actually, if you follow the link in this particular line of the slashdot article, you'll find Wired News's article on why they abandoned 'email' for 'e-mail' -- because 'e-mail' is grammatically correct, and 'email' is not, at least according to their reasoning. (It's actually a pretty good article, and one I read years ago.) Wired News did this ostensibly because the medium has "grown up" and the stylistic rules for the publication should reflect this. Or something.
Were one to read the slashdot article without following the link, you'd think that Wired dumped the hyphen from 'e-mail,' when in fact they didn't dump the hyphen at all -- rather, they started using it. This usage agrees with Webster and the OED and various other style guides in the industry. The previous use of 'email' without the hyphen was what they got rid of.
Personally, I don't care if people capitalize 'internet' or not. I prefer to capitalize it in most of my writing, because the Internet is a thing, a unique entity unto itself, and deserves to be considered a proper noun. It's not quite the same thing as television, which is a more nebulous and abstract concept (the word could describe the technology in general, the broadcast standard, the hardware used to display the broadcasts, or the programming that is being broadcast).
This has been mentioned in another sub-thread, but Toshiba recently announced 60 GB 1.8 inch hard drives, and said that Apple had already placed an order for them. But Apple denied they were releasing a 60 GB iPod. At the time, the only device Apple had that we knew of which used the 1.8 inch hard drives was the iPod...
So, if Apple is ordering a ton of 60 GB drives from Toshiba, and if they're not used in iPods, where are those drives going? With judicious power management, and a stripped down kernel and UI, such a tablet device could run a version of OS X. I wouldn't bet on network boot over 802.11g, though. There's too much stuff to be shipping over the wireless LAN every time the device needs to be reset/rebooted. OTOH, a tiny 60 GB hard drive which doesn't consume much power would be perfect -- it can hold an operating system and a huge cache of files locally.
I remember when MacOS X would require you to pay for upgrades
Nice troll. You only pay for major releases of OS X; minor point releases are free updates. Apple's still providing security updates for older versions of OS X (e.g., Jaguar) even though their focus is on the current release (i.e., Panther) and the next major release (Tiger).
This is the way it's been, and the way it will be for the foreseeable future. Of course, I'm sure you're one of those people who whined about Apple charging money to go from OS X 10.0 to OS X 10.1, but they gave a discount to early adopters, and even made the update CD freely available for a limited time in various stores such as CompUSA.
To use your parlance, and to bring this back to the discussion at hand, SP2 is not an "upgrade" the way you mean "upgrade" in the context of other OSes (such as MacOS X). Rather, SP2 is more analogous to a point release. An "upgrade" would be moving from, say, Windows 2000 to Windows XP. (Similarly, moving from MacOS X 10.2 "Jaguar" to 10.3 "Panther" is an upgrade.) SP2 for Windows XP is thus more analogous to, say, moving from MacOS 10.3.4 to the newly released 10.3.5. Which was free, and didn't break nearly as many apps as SP2 apparently did for some XP users.
Why are they advertising to users that already bought the unit in space that could be used for functionality?
Probably because ReplayTV relies on their users upgrading. Since service is tied to the hardware and non-transferrable, this has the intentional side-benefit of shifting older ReplayTV users from the older, less profitable revenue model for the program guide service (pay once when you buy the unit, and get service for the life of the unit) to the newer, more flexible and profitable revenue model (pay less for the unit, but pay monthly for the program guide service, unless you opt to buy lifetime service up front).
Truthfully, I prefer the user interface of ReplayTV to that of TiVO. TiVO's interface is a little more friendly, but it's also very... Playskool. Also, I like the new ReplayTV units that have built-in ethernet -- no need to buy a USB-ethernet adapter as you must with the TiVO series 2. Of course, TiVO's home media option is nice, but ReplayTV at least supports progressive scan output, and with a little bit of software, you can rip the video streams off the ReplayTV and archive them on your home computer.
It burns me that the only HD-capable DVR is a DirecTiVO unit that you can't get without DirecTV service. Of all the items in the article's wish list, this is the most obvious must-have feature for the future, and I agree with its number 1 placement on both lists. We need OTA HD recording, and cable HD recording as well, and we need it in a stand-alone unit that doesn't require you to be a DirecTV customer.
But back to a turbine, which you say is impossible for to evolve on its own...
Whoa, hold on there. He said it was "hard," not impossible. You can't argue effectively if you mis-state other people's points of argument.
Then again, if you didn't deliberately fudge what someone else said, it wouldn't bolster your own viewpoint, now would it?
Oh, and incidentally, whereas a flagellum exists in nature, and could be argued to be a "continuously spinning thing," the tech that makes the flagellum work doesn't scale up very well at all. That's why you don't see macroscopic animals with similar mechanisms on a macroscopic scale -- what works at cellular scale wouldn't work on a multi-cellular scale. This is why my sperm cells have flagella, and my tracheal epithelial cells have cilia, but I have to walk to locomote.
Um, no, read the article. The analogy used in the article was that of "eating one's own seed corn." As in, doing something stupid and short-sighted that will cost you in the long run.
Yes, the person who posted this to Slashdot mangled the analogy in the Computerworld article. The quote from the article:
Scarafino compared it to eating one's seed corn.
Makes more sense this way. You eat feed corn (or rather, livestock does); you save your seed corn to plant next year's crop. Eating your seed corn is thus a very bad, short-sighted thing.
Been done. Apparently, Photoshop has this "feature" implemented; it's an option in its "Save for Web" dialog. (There's a link in another branch of this discussion thread, but to save you time, you can look at this page for the info.) I guess this is useful for web developers who want to shave a few KB off each image file, but for the kinds of things you'd use GIF or PNG for, I can't imagine that this would be very beneficial.
FWIW, if you actually read the article that you linked to, it's pretty clear that Photoshop is simply pre-filtering the image before writing it out as a GIF or PNG. The goal is to pre-filter/pre-process the image so that the lossless compression in GIF or PNG can more efficiently do its job.
This isn't a hack to GIF or PNG; rather, this is a pre-processing step to reduce the amount of actual information in the image, thereby making it more compressible. You could do something similar by JPEG-compressing an image at a lower quality setting, then re-loading it and saving the resulting bitmap as a GIF or PNG.
If the IDAT chunk is just a raw stream of pixels, with no header information at the start of each row or magic bytes giving palette, image size etc., then compressing it lossily will be easy.
Well, there's a magic byte at the beginning of each row of pixels to specify the filtering strategy employed for that row of pixels. Read the spec.
I don't intend to use PNG to compress photorealistic images but screenshots, line drawings and other things PNG is traditionally good at.
Then you're completely off-base in wanting to do lossy compression for these cases. Lossy compression is a liability for things like screenshots and line drawings. Lossy compression doesn't make sense for cases like this, except maybe for some screen shots where you don't care about preserving things like text. Introducing artifacts, which is a byproduct of any kind of lossy compression, is simply unacceptable for the uses that PNG was intended for, especially the examples you give.
The good thing is that you can do whatever bizarre hacks you want in the compression code and the reader of the file doesn't have to know about any of it.
And you'd serve to convince people that PNG has "poor quality" compared to other file formats. Average users won't know that you used some kind of borked implementation of PNG to write files that use some kind of brain damaged lossy compression. They'll look at the result and think either that PNG sucks (a very undesirable outcome), or that someone over-processed the image before writing it as a PNG (which is pretty close to the truth).
Now maybe you'll understand my hostility to your idea.
I believe that, given enough time, any cleverly crafted "bug" that was secretly inserted into the Linux kernel (or other open source software) would be detected by human beings during the normal course of code auditing and testing. Code being checked in to an OSS project falls into one of two categories: fixes for existing bugs, or new features. Short of a rewrite of a key routine, it would be difficult to insert a clever bit of subversive code into a bug fix. As for new features... well, until such code has been used and tested extensively, it should be viewed with suspicion. Indeed, many new features in Linux are often still marked as experimental long after these features are in common use. Such features can always be conditionally omitted from compilation.
Subverting the compiler tools is a slightly sneakier way to achieve the same end-goal, but a government funded project would presumably make sure that the approved tools for development, including the compiler, are all well-tested and thoroughly code reviewed.
The one genuine threat of a trojan horse sleeping in open source software would be something that was placed there by a superintelligent operator. I'm talking about something that would happen after a Vingean Singularity, though. Only something of superhuman intelligence could scatter a plethora of seemingly unrelated bugs throughout the many source files of a project, bugs that would work in concert to create an unforeseen outcome under very specific circumstances. A human programmer might find one or two of these, but chances are that most would be too cleverly hidden to be found by a human at all... and of course, the net effect is the result of emergent behavior of all the little pieces misbehaving together in a certain pattern.
Yes, I know, this is really pie-in-the-sky philosophizing at this point. But I think about the Skroderiders in Vinge's A Fire Upon the Deep, and I wonder if our military systems could ever be compromised in such a way.
Based on what you described, this is the most asinine hack I've ever heard of. The "correct" way to integrate lossy compression into PNG is to add support for it to the specification -- but since the PNG team and the W3C won't go for that, you'd have to fork the spec. And not call the result PNG, of course, because it wouldn't be compliant with the spec.
Specifically, you'd need to specify a new compression type (there's a field for this in the PNG header chunk), and you would need to figure out how to embed the lossy-compressed data stream into appropriate image data chunks. You would not want to do what you're describing here, which is... well... bordering on the ludicrous.
After following the link, I have a better idea of what was intended, but I'm perplexed at how you could jack with the zlib implementation to mutilate the lossless compression, then turn around and claim that you'd need to turn the lossy-ness on and off. To quote:
Then modify libpng to turn on lossiness while writing rows of pixels and turn it off again when writing header type stuff. To do this I need to find out more about the PNG file format.
Yeah, no kidding. The header chunk isn't compressed with zlib. The only data that is compressed with zlib is the bytestream embedded in the IDAT chunks, and the bytestream embedded in the ZTXT chunks. (I'm going from memory on the name of that last chunk type, but it's the chunk that supports compressed text. For that, you do not want to use a hacked-up version of zlib, obviously, or the text you get back will be gibberish.)
If it seems that I'm openly hostile to your idea, it's because I am. It's clear to me that the hacks to zlib needed to make this work might not work universally. Wavelet techniques and Fourier-like transforms have been shown to be much more appropriate for lossy compression of photo-realisitc images. (JPEG uses a Discrete Cosine Transform, which is a Fourier-like transform, coupled with Huffman encoding of the DCT coefficients that survive culling. JPEG2000 uses wavelets IIRC.)
BTW, the results of your "compression" scheme on the color test image given on the site you linked to are atrocious. Even the artifacts from overzealous JPEG compression are more acceptable than the horizontal streaking caused by your tweaking of zlib. No file size savings are worth the type of image degradation that is incurred.
Because it was meant to be lossless-only. To alter this is to fundamentally alter what PNG is meant to do. The spec writers all agreed, that PNG shouldn't be another TIFF. If you want to see what will happen to PNG if you start adding in every compression scheme and ever possible color space (e.g., CMYK, RGB, YCbCr), just take a look at TIFF. TIFF supports both lossy and lossless compression, every conceivable interlacing scheme known to man, and every color space you can think of -- and most TIFF readers only handle a subset of TIFF images because the spec encompasses so much!
The issue isn't precisely one of dogma, it's one of design by intent. The intent was to create a better lossless image format that would replace GIF, and something that did not have the complexities associated with TIFF. The mailing list discussions among the PNG spec developers were very animated, sometimes bordering on flamage, and a few folks suggested things along the lines of what you're suggesting -- and were shot down. If you want to deal with bilevel images specifically, use JBIG. If you want to deal with lossy image compression, you have JPEG and JPEG2000. PNG doesn't need to try and do what those other file formats already do, and better. (Yes, you can store bilevel images in PNG, but specialized bilevel encoding schemes such as Group III/IV Fax and JBIG do a better job in many cases.)
Current versions of Replay do not include "official" show sharing anymore.
Is that so? Maybe I'm misunderstanding you, but according to this FAQ on ReplayTV's site, they still support streaming over your home LAN:
Room-to-Room Streaming - Watch It Anywhere: Now all ReplayTV DVRs come with built-in home networking capabilities that allow you to connect 2, 3, up to 8 ReplayTV DVRs together. Anything you record can be streamed in real-time to any networked DVR in your house. Want to enjoy the big game on the good TV but the kids are watching the big dinosaur? Send the dino into the den-the kids won't miss a minute. After the game, bring the family together for the Sunday night movie that was recording upstairs. A built-in RJ-45 Ethernet connector works with wired and wireless networks (802.11G suggested for wireless streaming).
The only caveat is that you can't stream shows between different generations of ReplayTV (e.g., you can't stream from a 4xxx series to a 5xxx series device).
Perhaps by "show sharing" you meant streaming shows over the internet to someone else? In that sense, yes, that feature was disabled to placate Hollywood.
PNG was designed to be lossless-only. There is, AFAIK, no effort underway to add lossy compression to the PNG specification. I believe that MNG (the superset of PNG which supports animation) can support JPEG-compressed frames, but since I had no hand in the MNG spec, I don't know this for certain.
PNG may have a size advantage, but seems to render much slower. If you include transmission and rendering time in the total picture, gif beats png by a large margin.
This is purely subjective, and FUD. On a modern CPU, with a modern graphics card, both GIF and PNG should take the same amount of time to "render." The process of rendering includes taking the data, decompressing it, and writing the pixels to the display device.
It's quite possible that some web browsers may have a very broken PNG rendering engine, but that's not a fault of the file format. PNG was designed to render progressively as it's downloaded, just like GIF. (I should know, I'm one of the specification co-authors for PNG.) PNG also has a much cooler interlacing scheme than GIF, which has made it a favorite for many set-top box developers (think next generation cable boxes).
IE displays PNG's properly, with transparency, and it's still non-lossy. IE only doesnt properly support the alpha channel of PNG's.
Just to clarify... Mac IE displays all PNGs properly, even with alpha channel. Windows IE displays PNGs with indexed transparency properly, but not PNGs with alpha channel transparency.
And yes, I know that Mac IE is discontinued, but it's still a useful browser to test with. It still has many features that its Windows counterpart lacks (such as better PNG support).
Slashdot Mirror
OK, smart-ass. How about "Conceptually, RAM chips are pretty easy to design." Is that better? As for the "I never said the design process was easy" statement, the key word here is process. The thread devolved into a discussion of the competitive pressures placed on RAM manufacturers and the tweaking they have to do to the process in order to squeeze more bit density into a chip. But you'd know that from reading the thread...
Everyone else knew what I meant.
I never said the design process was easy. I just said I wouldn't characterize the end-product as intricate. And really, the engineering effort, as I understand it, goes into packing the bits tighter -- how to make each cell as small as possible. Once you have figured out the tricks, laying out a grid of cells isn't rocket science. Scaling your grid larger works up to a point, until the chip gets too big to be profitable.
I also think your assertion that CPU design is "a bunch of hdl that you can get 10 trained monkeys to write" is a gross exaggeration and an insult to CPU designers. I'll agree, though, that process refinement is tricky business.
But none of this speaks to my point that I wouldn't use "intricate" to describe RAM design. (See my other reply in another subthread of this discussion.)
While everything you say may be true, my objection was to the use of the term "intricate" to describe RAM chip design. The layout isn't intricate at all. It is a highly regular structure. Not convoluted. Not intricate.
To bolster my point, let's look at the definition of the word intricate: "1. Having many complexly arranged elements; elaborate. 2. Solvable or comprehensible only with painstaking effort. Complex."
The physical structure does not satisfy the definition of "intricate." The complexity of RAM development stems from the inherent problems of solid-state physics that must be gotten around to pack the bits ever more densely. The economic drive to be competitive forces innovations in increasing bit density, but once the design work is done and the production process has been tweaked... that's it. The end result might be a marvel of engineering, but it's not intricate as the word is defined, sorry. Maybe the engineering process could be described as intricate (though I would consider this a stretch), but not the end result.
I was responding to this assertion:
The Anonymous Coward who wrote this apparently does not believe that file formats are not patentable.
File formats are not patentable. Period. In the case of GIF and JPEG, the compression algorithms are where the patents lie. These compression algorithms exist independently of the GIF and JPEG file formats, and in fact have other applications. (The LZW algorithm utilized by GIF was used for years in hardware applications, such as hard disk controllers. That's why the LZW patent was granted in the first place -- because at the time, you had to have a concrete implementation of an algorithm in firmware/hardware to claim a patent on an algorithm. It's only recently that algorithms have been patented on their own without regard to concrete implementation.)
And this is an argument why? (That was a rhetorical question. You've committed a logical fallacy.) You haven't even addressed the issue I've raised.
Bottom line, someone asserted that file formats are not patentable, some AC refuses to believe this fact, and I responded with facts. The fact is, the file formats themselves are not patented. Technologies that these file formats rely upon are patented, which is not the same thing. You're trying to conflate the two, and you can't. The other AC to whom I was responding was attempting to conflate these two issues, and was equally wrong.
The mere fact that these compression algorithms exist independently of the GIF and JPEG file formats, and the fact that they have other applications entirely separate from their use in GIF and JPEG, proves that these compression algorithms are not "inseparable" from the file formats, as you asserted. (Inseparable would imply that the algorithms can not stand on their own as much as it would imply that the file formats can't stand on their own. While the latter may be true, the former is not.)
A file format is just a uniform way to put data into a file for a specific purpose. A file format, then, is uniquely identified by the structure of the data and by the other technologies that may be leveraged, such as certain transformations that must be applied to the data. While the specification for a file format may reference an algorithm used for data transformation, the algorithm itself isn't usually given in the specification. In the case of JPEG and GIF, those algorithms are externally referenced, although a reference implementation (or suggestions for implementation) may be provided. Some of the old Compuserve GIF documentation gave tips on implementing LZW in software, for instance.
The point I'm making is, if someone patents an algorithm for compressing data, and that algorithm is relied upon for writing e.g. GIF files, the patent is not on the file format, it is on the compression algorithm, period. To speak otherwise is to confuse matters. When the AC to whom I initially responded posed the question "If, as you say, that file formats are not patentable, trademarkable, or copyrightable, then how do you explain problems with GIF and JPEG file formats[...]?" he was trying to imply that GIF and JPEG were proof that file formats were patentable. This is not the case, and I think I've proven my point. One thing does not logically follow from the other.
And to the jackass
I know that this is already done with some flash memory chips on the market -- there are spare cells which become active as other cells become unreliable or unusable. Flash memory has a finite number of write cycles, so this practice is a cheap way to extend the life of a flash chip.
Of course, flash memory relies on a file system to do a lot of the heavy lifting...
As for DRAM... well, the logic to map out bad bits would have to reside on the chip, thus increasing real-estate consumption. So the chips would have to grow bigger to accommodate the logic to do this, and that would lower yields. This might negate any gains from having the logic there in the first place!
Well, I can't speak to the cost-intensive part of your assertion, since I am not privy to some details about the economics of chip production. But intricate? Not hardly. DRAM and SRAM chips are laid out mostly in a grid, with very little real-estate set aside for control logic. The only complexity is the control logic; the rest of the chip is just a matrix of transistors (and, in the case of DRAM, one capacitor per transistor to actually store the bit).
RAM chips are pretty easy to design and lay out because of the inherent regularity in their structure.
Because the legal problems with GIF and JPEG stemmed from the compression algorithms used by these file formats, and not from the file formats themselves. Just like the original poster said, dipshit. Learn to do a little research first.
Interestingly enough, I set up a TiVo Series 2 last night for the first time, and noticed something. There's a LED back-light for the TiVo logo on the front of the unit, and this back-light can be configured in software -- there's a menu item to set the level of illumination behind the TiVo logo (or turn it off altogether). So software controlled variable illumination in a piece of hardware (specifically, chassis illumination) has certainly been done before, albeit not on the scale probably implied by the Apple patent. The TiVo faceplace is translucent; presumably, an array of LEDs could be placed behind such a plastic plate to provide patterning, but I doubt this has much value for a device that is going to sit under your TV or in a stereo rack next to it. I believe the backlight for the TiVo logo is also a monochrome white LED, so that's one minor difference.
Actually, if you follow the link in this particular line of the slashdot article, you'll find Wired News's article on why they abandoned 'email' for 'e-mail' -- because 'e-mail' is grammatically correct, and 'email' is not, at least according to their reasoning. (It's actually a pretty good article, and one I read years ago.) Wired News did this ostensibly because the medium has "grown up" and the stylistic rules for the publication should reflect this. Or something.
Were one to read the slashdot article without following the link, you'd think that Wired dumped the hyphen from 'e-mail,' when in fact they didn't dump the hyphen at all -- rather, they started using it. This usage agrees with Webster and the OED and various other style guides in the industry. The previous use of 'email' without the hyphen was what they got rid of.
Personally, I don't care if people capitalize 'internet' or not. I prefer to capitalize it in most of my writing, because the Internet is a thing, a unique entity unto itself, and deserves to be considered a proper noun. It's not quite the same thing as television, which is a more nebulous and abstract concept (the word could describe the technology in general, the broadcast standard, the hardware used to display the broadcasts, or the programming that is being broadcast).
This has been mentioned in another sub-thread, but Toshiba recently announced 60 GB 1.8 inch hard drives, and said that Apple had already placed an order for them. But Apple denied they were releasing a 60 GB iPod. At the time, the only device Apple had that we knew of which used the 1.8 inch hard drives was the iPod...
So, if Apple is ordering a ton of 60 GB drives from Toshiba, and if they're not used in iPods, where are those drives going? With judicious power management, and a stripped down kernel and UI, such a tablet device could run a version of OS X. I wouldn't bet on network boot over 802.11g, though. There's too much stuff to be shipping over the wireless LAN every time the device needs to be reset/rebooted. OTOH, a tiny 60 GB hard drive which doesn't consume much power would be perfect -- it can hold an operating system and a huge cache of files locally.
Nice troll. You only pay for major releases of OS X; minor point releases are free updates. Apple's still providing security updates for older versions of OS X (e.g., Jaguar) even though their focus is on the current release (i.e., Panther) and the next major release (Tiger).
This is the way it's been, and the way it will be for the foreseeable future. Of course, I'm sure you're one of those people who whined about Apple charging money to go from OS X 10.0 to OS X 10.1, but they gave a discount to early adopters, and even made the update CD freely available for a limited time in various stores such as CompUSA.
To use your parlance, and to bring this back to the discussion at hand, SP2 is not an "upgrade" the way you mean "upgrade" in the context of other OSes (such as MacOS X). Rather, SP2 is more analogous to a point release. An "upgrade" would be moving from, say, Windows 2000 to Windows XP. (Similarly, moving from MacOS X 10.2 "Jaguar" to 10.3 "Panther" is an upgrade.) SP2 for Windows XP is thus more analogous to, say, moving from MacOS 10.3.4 to the newly released 10.3.5. Which was free, and didn't break nearly as many apps as SP2 apparently did for some XP users.
Probably because ReplayTV relies on their users upgrading. Since service is tied to the hardware and non-transferrable, this has the intentional side-benefit of shifting older ReplayTV users from the older, less profitable revenue model for the program guide service (pay once when you buy the unit, and get service for the life of the unit) to the newer, more flexible and profitable revenue model (pay less for the unit, but pay monthly for the program guide service, unless you opt to buy lifetime service up front).
Truthfully, I prefer the user interface of ReplayTV to that of TiVO. TiVO's interface is a little more friendly, but it's also very... Playskool. Also, I like the new ReplayTV units that have built-in ethernet -- no need to buy a USB-ethernet adapter as you must with the TiVO series 2. Of course, TiVO's home media option is nice, but ReplayTV at least supports progressive scan output, and with a little bit of software, you can rip the video streams off the ReplayTV and archive them on your home computer.
It burns me that the only HD-capable DVR is a DirecTiVO unit that you can't get without DirecTV service. Of all the items in the article's wish list, this is the most obvious must-have feature for the future, and I agree with its number 1 placement on both lists. We need OTA HD recording, and cable HD recording as well, and we need it in a stand-alone unit that doesn't require you to be a DirecTV customer.
Whoa, hold on there. He said it was "hard," not impossible. You can't argue effectively if you mis-state other people's points of argument.
Then again, if you didn't deliberately fudge what someone else said, it wouldn't bolster your own viewpoint, now would it?
Oh, and incidentally, whereas a flagellum exists in nature, and could be argued to be a "continuously spinning thing," the tech that makes the flagellum work doesn't scale up very well at all. That's why you don't see macroscopic animals with similar mechanisms on a macroscopic scale -- what works at cellular scale wouldn't work on a multi-cellular scale. This is why my sperm cells have flagella, and my tracheal epithelial cells have cilia, but I have to walk to locomote.
Um, no, read the article. The analogy used in the article was that of "eating one's own seed corn." As in, doing something stupid and short-sighted that will cost you in the long run.
Idiots these days.
Makes more sense this way. You eat feed corn (or rather, livestock does); you save your seed corn to plant next year's crop. Eating your seed corn is thus a very bad, short-sighted thing.
Been done. Apparently, Photoshop has this "feature" implemented; it's an option in its "Save for Web" dialog. (There's a link in another branch of this discussion thread, but to save you time, you can look at this page for the info.) I guess this is useful for web developers who want to shave a few KB off each image file, but for the kinds of things you'd use GIF or PNG for, I can't imagine that this would be very beneficial.
FWIW, if you actually read the article that you linked to, it's pretty clear that Photoshop is simply pre-filtering the image before writing it out as a GIF or PNG. The goal is to pre-filter/pre-process the image so that the lossless compression in GIF or PNG can more efficiently do its job.
This isn't a hack to GIF or PNG; rather, this is a pre-processing step to reduce the amount of actual information in the image, thereby making it more compressible. You could do something similar by JPEG-compressing an image at a lower quality setting, then re-loading it and saving the resulting bitmap as a GIF or PNG.
Well, there's a magic byte at the beginning of each row of pixels to specify the filtering strategy employed for that row of pixels. Read the spec.
Then you're completely off-base in wanting to do lossy compression for these cases. Lossy compression is a liability for things like screenshots and line drawings. Lossy compression doesn't make sense for cases like this, except maybe for some screen shots where you don't care about preserving things like text. Introducing artifacts, which is a byproduct of any kind of lossy compression, is simply unacceptable for the uses that PNG was intended for, especially the examples you give.
And you'd serve to convince people that PNG has "poor quality" compared to other file formats. Average users won't know that you used some kind of borked implementation of PNG to write files that use some kind of brain damaged lossy compression. They'll look at the result and think either that PNG sucks (a very undesirable outcome), or that someone over-processed the image before writing it as a PNG (which is pretty close to the truth).
Now maybe you'll understand my hostility to your idea.
I believe that, given enough time, any cleverly crafted "bug" that was secretly inserted into the Linux kernel (or other open source software) would be detected by human beings during the normal course of code auditing and testing. Code being checked in to an OSS project falls into one of two categories: fixes for existing bugs, or new features. Short of a rewrite of a key routine, it would be difficult to insert a clever bit of subversive code into a bug fix. As for new features... well, until such code has been used and tested extensively, it should be viewed with suspicion. Indeed, many new features in Linux are often still marked as experimental long after these features are in common use. Such features can always be conditionally omitted from compilation.
Subverting the compiler tools is a slightly sneakier way to achieve the same end-goal, but a government funded project would presumably make sure that the approved tools for development, including the compiler, are all well-tested and thoroughly code reviewed.
The one genuine threat of a trojan horse sleeping in open source software would be something that was placed there by a superintelligent operator. I'm talking about something that would happen after a Vingean Singularity, though. Only something of superhuman intelligence could scatter a plethora of seemingly unrelated bugs throughout the many source files of a project, bugs that would work in concert to create an unforeseen outcome under very specific circumstances. A human programmer might find one or two of these, but chances are that most would be too cleverly hidden to be found by a human at all... and of course, the net effect is the result of emergent behavior of all the little pieces misbehaving together in a certain pattern.
Yes, I know, this is really pie-in-the-sky philosophizing at this point. But I think about the Skroderiders in Vinge's A Fire Upon the Deep, and I wonder if our military systems could ever be compromised in such a way.
Specifically, you'd need to specify a new compression type (there's a field for this in the PNG header chunk), and you would need to figure out how to embed the lossy-compressed data stream into appropriate image data chunks. You would not want to do what you're describing here, which is... well... bordering on the ludicrous.
After following the link, I have a better idea of what was intended, but I'm perplexed at how you could jack with the zlib implementation to mutilate the lossless compression, then turn around and claim that you'd need to turn the lossy-ness on and off. To quote:Yeah, no kidding. The header chunk isn't compressed with zlib. The only data that is compressed with zlib is the bytestream embedded in the IDAT chunks, and the bytestream embedded in the ZTXT chunks. (I'm going from memory on the name of that last chunk type, but it's the chunk that supports compressed text. For that, you do not want to use a hacked-up version of zlib, obviously, or the text you get back will be gibberish.)
If it seems that I'm openly hostile to your idea, it's because I am. It's clear to me that the hacks to zlib needed to make this work might not work universally. Wavelet techniques and Fourier-like transforms have been shown to be much more appropriate for lossy compression of photo-realisitc images. (JPEG uses a Discrete Cosine Transform, which is a Fourier-like transform, coupled with Huffman encoding of the DCT coefficients that survive culling. JPEG2000 uses wavelets IIRC.)
BTW, the results of your "compression" scheme on the color test image given on the site you linked to are atrocious. Even the artifacts from overzealous JPEG compression are more acceptable than the horizontal streaking caused by your tweaking of zlib. No file size savings are worth the type of image degradation that is incurred.
Because it was meant to be lossless-only. To alter this is to fundamentally alter what PNG is meant to do. The spec writers all agreed, that PNG shouldn't be another TIFF. If you want to see what will happen to PNG if you start adding in every compression scheme and ever possible color space (e.g., CMYK, RGB, YCbCr), just take a look at TIFF. TIFF supports both lossy and lossless compression, every conceivable interlacing scheme known to man, and every color space you can think of -- and most TIFF readers only handle a subset of TIFF images because the spec encompasses so much!
The issue isn't precisely one of dogma, it's one of design by intent. The intent was to create a better lossless image format that would replace GIF, and something that did not have the complexities associated with TIFF. The mailing list discussions among the PNG spec developers were very animated, sometimes bordering on flamage, and a few folks suggested things along the lines of what you're suggesting -- and were shot down. If you want to deal with bilevel images specifically, use JBIG. If you want to deal with lossy image compression, you have JPEG and JPEG2000. PNG doesn't need to try and do what those other file formats already do, and better. (Yes, you can store bilevel images in PNG, but specialized bilevel encoding schemes such as Group III/IV Fax and JBIG do a better job in many cases.)
Is that so? Maybe I'm misunderstanding you, but according to this FAQ on ReplayTV's site, they still support streaming over your home LAN:
The only caveat is that you can't stream shows between different generations of ReplayTV (e.g., you can't stream from a 4xxx series to a 5xxx series device).
Perhaps by "show sharing" you meant streaming shows over the internet to someone else? In that sense, yes, that feature was disabled to placate Hollywood.
PNG was designed to be lossless-only. There is, AFAIK, no effort underway to add lossy compression to the PNG specification. I believe that MNG (the superset of PNG which supports animation) can support JPEG-compressed frames, but since I had no hand in the MNG spec, I don't know this for certain.
Again, PNG is for lossless, non-animated images.
This is purely subjective, and FUD. On a modern CPU, with a modern graphics card, both GIF and PNG should take the same amount of time to "render." The process of rendering includes taking the data, decompressing it, and writing the pixels to the display device.
It's quite possible that some web browsers may have a very broken PNG rendering engine, but that's not a fault of the file format. PNG was designed to render progressively as it's downloaded, just like GIF. (I should know, I'm one of the specification co-authors for PNG.) PNG also has a much cooler interlacing scheme than GIF, which has made it a favorite for many set-top box developers (think next generation cable boxes).
Just to clarify... Mac IE displays all PNGs properly, even with alpha channel. Windows IE displays PNGs with indexed transparency properly, but not PNGs with alpha channel transparency.
And yes, I know that Mac IE is discontinued, but it's still a useful browser to test with. It still has many features that its Windows counterpart lacks (such as better PNG support).