It doesn't break such code -- if that code is expecting png datastreams one after the other, then it won't find a PNG header after the first one. The "bunch of user chunks" after the IEND are simply an entire PNG, minus the 8-byte PNG header, hardly random chunks. Finally, EOF is mentioned nowhere -- the number of frames that are expected to follow is clearly specified as part of the anIm chunk; EOF before this would be an error/incomplete data condition, and nothing more.
Unfortunately, the press release about Red Carpet Express and Red Carpet Corporate Connect erroneously left an important bit of information. Red Carpet will remain free. Red Carpet Express is an optional service which gives you guaranteed access to the latest updates, even if the main public Red Carpet server is congested. Red Carpet Corporate Connect offers additional features to corporate workgroup users.
The conspiracy theorists will no doubt continue to accuse us of "selling out" at every step of the way; I'm too busy working on adding additional features to Red Carpet to get upset at this point. I hope that anyone with questions regarding Red Carpet or other Ximian products/services will at least contact Ximian directly.
If you are compiling from source, you will indeed have to build a number of prerequisite libraries that track Evolution development, such as gal. This is no different than including all these libraries inside the evolution source tree -- except that these libraries are also used by other projects, and as such are independent modules. Now that bonobo, oaf, and others are stable, this isn't as big of a problem.
If you just want to install Ximian Evolution, you can easily use Red Carpet to do it -- it will figure out exactly what packages you need and take care of the whole problem for you.
Ever try playing a 640x480 game on a 1024x768 laptop LCD? Yucko.
I don't buy this. I regularily play games such as Diablo II on my laptop. However, the laptop in question (IBM X20) uses ATI's Rage Mobility M chipset, which does hardware upsampling to 1024x768, so 640x480 appears as a quite smooth image. (800x600 doesn't fare so well, but it's still quite decent.)
Even without that, you have the ability to simply use a 640x480 chunk of the middle of your screen, or specify a constant multiplier; hopefully the video cards apple uses to drive these LCDs -- currently ATI Radeons, I believe -- will allow you to say "I want to view 640x480 pixel-doubled on my 1280x1024 LCD" or similar.
The big problem with LCDs and games is if the pixel speed on the display is too low, thus not allowing the LCD to keep up with the frames that the game is displaying because it can't change pixel colors fast enough. I doubt any of Apple's displays would suffer from this problem, since they are intended to be used for things like video editing.
The issue of winex vs. native ports isn't just about getting the game running. Asking any windows game house to add a port to a competely new operating system is asking them to do quite a bit. Thanks to libraries such as SDL, OpenGL, and OpenAL, the actual work involved in porting the code may be quite small. However, the company will have to train their support staff on how to support their games under Linux -- something that is not an easy task. ("Okay, sir, you're running XFree 4.0.2.. do you have the latest NVidia drivers? Oh, you're using the open source drivers and not the binary only ones.. well, the ones that appear to work were from CVS dated Jan 15, can you try rebuilding with those? Oh, you'll have to rebuild X to get those to work, let me tell you how...")
The other issue is that while winex may be able to get the game going, there are still a number of minor barriers. Many games are (still, pointlessly) using various forms of copy protection that require the OS to jump through hoops to read bad sectors or other such nonsense from the CD-ROM.
I don't think a large amount of this functionality is supported under wine -- thud you'd have to convince the game company to either redo their copy protection or get rid of it altogether... both not very likely things.
There are obviously problems with both approaches; on one hand, wine can be extended and patched to allow various forms of copy protection and other such nasty hacks to work, and on the other, perhaps Linux will become such a large market that game companies will plan to support it from the start. Perhaps Linux on the Desktop will become a viable target for application developers -- something that can't happen until the various low-level packages stabilize. And we're a long way from that yet.
The problem is that rpmfind employs a spider to find rpms and place them in the database. Thus, even if you know what the source URL is, anyone can create, say, a directory structure that looks like a Red Hat distro and place trojaned files in there -- then they can track downloads, and voila, an instant list of who (probably) installed what package. And this is something that can be trivially done today. The only way to guard against this is to verify signatures, something that I would say 90% of casual users simply don't when using rpm manually.
Actually, unless something has changed in the past little while, debs do not support signing. The uploads are signed by the maintainers, but a user who downloads debs from one of the root debian mirrors or elsewhere has no way to verify where it came from. Conectiva has extended apt to handle signatures for rpms (with their apt-rpm system), but I don't think they've done anything with debs. Red Carpet verifies deb signatures by downloading a detached signature for every deb (thus maintaining compatability while also being able to verify at least Ximian's packages).
In a sense, this may be a hard problem to solve, simply because the debain project is so distributed -- there is no "debian package" key that can be used to sign all the debs that are available in the official distributions, and requiring a user to have each of the maintainers' public keys in their keyring is impractical. Perhaps there could be a debian packaging key that is automatically used to sign a package after a maintainer uploads it, but the security of this would be questionable.
This makes sense in that they are paying for their connectivity, and could even be paying based on bandwidth used (i.e. Akamai). This is one way for them to recoup these costs. They should, however, allow mirrors to download the software for free and host free mirrors.
If not, then they shouldn't complain if someone does mirror their CD image (after paying for either the physical CD or the download). Then again, this depends on the specific licenses involved, although I would assume that their distro is fully GPLd...
I just ran into this as well from using some custom developed scripts; however, the scheme by which cddb/gracenote/whatever the name du jour is uses to 'authenticate' licensed users is just the already-existing 'hello' part of the cddb protocol. So, an application can simply pretend to be one of the licensed applications (xmcd 2.5, for one) and everything works fine; the modification for this in the FreeDB.pm perl module is trivial. There is nothing that Gracenote can do against this; they are simply trying to make life difficult.
It is in any case ridiculous that cddb.com has decided to do this, and we should definitively support the freedb.org efforts by entering data for CDs that aren't already in the database -- now if only there was an official procedure for 'correcting' freedb entries:-)
It was my understanding that motion picture titles are not themselves copyrightable. (I could be wrong about this, though;-) The MPAA does offer a registration service, but only MPAA signatories are bound by the MPAA's decisions regarding title conflicts. In the case of a title conflict, the MPAA has the final decision (especially if the parties involved are signatories). Blizzard would own the copyright on content based on the Diablo games, etc., but cannot copyright a motion picture title itself.
However, in this case, considering that New Line is much more prominent in the motion picture industry than Blizzard is, New Line might indeed win such a conflict...
One thing to notice is that both images posted here use subpixel rendering, which is only useful on LCD displays. Subpixel rendering uses the knowledge that each pixel is made up of a discrete set of red, green, and blue rectangles, that are next to each other. The glyph rendering code can then use this knowledge to make text appear smoother, since it can turn on, say, the red channel of an adjacent pixel, knowing that it's it's physically next to the blue channel of the previous pixel. Keith Packard has more info on his pages at his web page, including a few sample screenshots with subpixel rendering turned off and on.
However, this only helps on LCDs. It is not possible on CRTs to have as fine of control over individual color channels. As such, these screenshots might look suboptimal or blurry on non-LCD displays. Note that some may recognize that this is very similar to what Microsoft calls ClearType (R, tm, whatever). Indeed it is -- however, that name is owned by MS. Jacob suggested SchweetFont as a possible alternative name.:-)
The slashdot screenshot referenced was done using an older version of some color code; this has since been fixed. I've placed a new screenshot in place of the old one.
There's a few buglets, but they're mostly related to memory usage and getting the right font based on the requested X font; other than that, things work fairly well.. (I run my entire desktop antialiased with only minor glitches).
I for one am glad to see that DirecTV is fighting back not with threats and lawyers, but with some pretty clever hacking on their part. I'm actually quite impressed that they pulled off what they did -- slowly building up the necessary code, piece by seeminly innocuous piece, until they struck. (Having it occur a week before the superbowl was a masterful stroke as well.) Many hackers consider what they do a sort of game, and DirecTV decided to actively participate.
This is in contrast to most other companies and organizations, such as the Microsoft and the RIAA/MPAA... even companies such as Rambus, Apple, Fraunhoffer, etc. who attempt to enforce what they feel is 'their' property not by any technical means, but by patents and lawsuits.
Now, I'm disgusted by, for example, what the MPAA is trying to do with DeCSS; however, I would have a lot more respect for them if they took a more DirecTV-type approach, and tried to figure out technical means to 'throw a wrench in the works'. If they think some of their.. property (? content? data? I'm not even sure exactly...) is being violated, they should be able to protect it themselves. They don't have the luxury of being able to update the embedded software on all existing DVD players; maybe they could just declare that they screwed up, and that DVDs can't offer the kind of content control that they want. (Of course, it's a bit late to propose any kind of alternative, but still.)
In any case, DirecTV's being a good guy throughout this, I would think -- and I might even be buying their systems in the future. (This in contrast to other satellite networks that will be locking out some HD content from being viewed with HDTV equipment that doesn't have media access control capabilities!)
I recently spoke with a pediatric clininc that was looking to move to a more modern appointment and billing system. They are using an antiquated DOS and NetWare based system that has grown insufficient for their needs. Unfortunately, when they showed me the top two offerings, they both were horrible. One that they investigated involved the server being somewhere in Texas, while they (at their clinic) used Citrix WinFrame to view applications on the server, with 6 stations running concurrently over SDSL!
In talking with them, it seemed that there were really no flexible, modern solutions for what they needed -- a multi-physician appointment scheduling and billing system. It sounds like it should be a fairly straightforward thing to implement -- a decent database backend (say, PostgreSQL) along with a nice GNOME/Gtk front-end (of course, I say this never having written such a system;-). But all the solutions providers seem to be pushing old technology that they may have dressed up as 'client server' from something that isn't (i.e. the Citrix WinFrame attempts), or have just put a pretty face on some big iron server (i.e. using TN3270 as a front-end).
I'm glad to hear about attempts such as the one described to create a modern medical office -- it will be interesting to see what problems they run into and how they are solved. Hopefully something like this will be a wakeup call to solutions providers.
Incidentally, from a free software perspective, I wonder if a free software application could be accepted in this community. Small clinics could use the software as-is, and large clinics could contract the developer for customization. But again, would such a solution be looked down on because it's free and open sourced, something not often (ever?) heard in the medical community?
Slashdot Mirror
It doesn't break such code -- if that code is expecting png datastreams one after the other, then it won't find a PNG header after the first one. The "bunch of user chunks" after the IEND are simply an entire PNG, minus the 8-byte PNG header, hardly random chunks. Finally, EOF is mentioned nowhere -- the number of frames that are expected to follow is clearly specified as part of the anIm chunk; EOF before this would be an error/incomplete data condition, and nothing more.
Unfortunately, the press release about Red Carpet Express and Red Carpet Corporate Connect erroneously left an important bit of information. Red Carpet will remain free. Red Carpet Express is an optional service which gives you guaranteed access to the latest updates, even if the main public Red Carpet server is congested. Red Carpet Corporate Connect offers additional features to corporate workgroup users.
The conspiracy theorists will no doubt continue to accuse us of "selling out" at every step of the way; I'm too busy working on adding additional features to Red Carpet to get upset at this point. I hope that anyone with questions regarding Red Carpet or other Ximian products/services will at least contact Ximian directly.
If you are compiling from source, you will indeed have to build a number of prerequisite libraries that track Evolution development, such as gal. This is no different than including all these libraries inside the evolution source tree -- except that these libraries are also used by other projects, and as such are independent modules. Now that bonobo, oaf, and others are stable, this isn't as big of a problem.
If you just want to install Ximian Evolution, you can easily use Red Carpet to do it -- it will figure out exactly what packages you need and take care of the whole problem for you.
I don't buy this. I regularily play games such as Diablo II on my laptop. However, the laptop in question (IBM X20) uses ATI's Rage Mobility M chipset, which does hardware upsampling to 1024x768, so 640x480 appears as a quite smooth image. (800x600 doesn't fare so well, but it's still quite decent.)
Even without that, you have the ability to simply use a 640x480 chunk of the middle of your screen, or specify a constant multiplier; hopefully the video cards apple uses to drive these LCDs -- currently ATI Radeons, I believe -- will allow you to say "I want to view 640x480 pixel-doubled on my 1280x1024 LCD" or similar.
The big problem with LCDs and games is if the pixel speed on the display is too low, thus not allowing the LCD to keep up with the frames that the game is displaying because it can't change pixel colors fast enough. I doubt any of Apple's displays would suffer from this problem, since they are intended to be used for things like video editing.
The other issue is that while winex may be able to get the game going, there are still a number of minor barriers. Many games are (still, pointlessly) using various forms of copy protection that require the OS to jump through hoops to read bad sectors or other such nonsense from the CD-ROM.
I don't think a large amount of this functionality is supported under wine -- thud you'd have to convince the game company to either redo their copy protection or get rid of it altogether... both not very likely things.
There are obviously problems with both approaches; on one hand, wine can be extended and patched to allow various forms of copy protection and other such nasty hacks to work, and on the other, perhaps Linux will become such a large market that game companies will plan to support it from the start. Perhaps Linux on the Desktop will become a viable target for application developers -- something that can't happen until the various low-level packages stabilize. And we're a long way from that yet.
The problem is that rpmfind employs a spider to find rpms and place them in the database. Thus, even if you know what the source URL is, anyone can create, say, a directory structure that looks like a Red Hat distro and place trojaned files in there -- then they can track downloads, and voila, an instant list of who (probably) installed what package. And this is something that can be trivially done today. The only way to guard against this is to verify signatures, something that I would say 90% of casual users simply don't when using rpm manually.
Actually, unless something has changed in the past little while, debs do not support signing. The uploads are signed by the maintainers, but a user who downloads debs from one of the root debian mirrors or elsewhere has no way to verify where it came from. Conectiva has extended apt to handle signatures for rpms (with their apt-rpm system), but I don't think they've done anything with debs. Red Carpet verifies deb signatures by downloading a detached signature for every deb (thus maintaining compatability while also being able to verify at least Ximian's packages).
In a sense, this may be a hard problem to solve, simply because the debain project is so distributed -- there is no "debian package" key that can be used to sign all the debs that are available in the official distributions, and requiring a user to have each of the maintainers' public keys in their keyring is impractical. Perhaps there could be a debian packaging key that is automatically used to sign a package after a maintainer uploads it, but the security of this would be questionable.
This makes sense in that they are paying for their connectivity, and could even be paying based on bandwidth used (i.e. Akamai). This is one way for them to recoup these costs. They should, however, allow mirrors to download the software for free and host free mirrors.
If not, then they shouldn't complain if someone does mirror their CD image (after paying for either the physical CD or the download). Then again, this depends on the specific licenses involved, although I would assume that their distro is fully GPLd...
It is in any case ridiculous that cddb.com has decided to do this, and we should definitively support the freedb.org efforts by entering data for CDs that aren't already in the database -- now if only there was an official procedure for 'correcting' freedb entries :-)
It was my understanding that motion picture titles are not themselves copyrightable. (I could be wrong about this, though ;-) The MPAA does offer a registration service, but only MPAA signatories are bound by the MPAA's decisions regarding title conflicts. In the case of a title conflict, the MPAA has the final decision (especially if the parties involved are signatories). Blizzard would own the copyright on content based on the Diablo games, etc., but cannot copyright a motion picture title itself.
However, in this case, considering that New Line is much more prominent in the motion picture industry than Blizzard is, New Line might indeed win such a conflict...
One thing to notice is that both images posted here use subpixel rendering, which is only useful on LCD displays. Subpixel rendering uses the knowledge that each pixel is made up of a discrete set of red, green, and blue rectangles, that are next to each other. The glyph rendering code can then use this knowledge to make text appear smoother, since it can turn on, say, the red channel of an adjacent pixel, knowing that it's it's physically next to the blue channel of the previous pixel. Keith Packard has more info on his pages at his web page, including a few sample screenshots with subpixel rendering turned off and on.
:-)
However, this only helps on LCDs. It is not possible on CRTs to have as fine of control over individual color channels. As such, these screenshots might look suboptimal or blurry on non-LCD displays. Note that some may recognize that this is very similar to what Microsoft calls ClearType (R, tm, whatever). Indeed it is -- however, that name is owned by MS. Jacob suggested SchweetFont as a possible alternative name.
The slashdot screenshot referenced was done using an older version of some color code; this has since been fixed. I've placed a new screenshot in place of the old one.
There's a few buglets, but they're mostly related to memory usage and getting the right font based on the requested X font; other than that, things work fairly well.. (I run my entire desktop antialiased with only minor glitches).
I for one am glad to see that DirecTV is fighting back not with threats and lawyers, but with some pretty clever hacking on their part. I'm actually quite impressed that they pulled off what they did -- slowly building up the necessary code, piece by seeminly innocuous piece, until they struck. (Having it occur a week before the superbowl was a masterful stroke as well.) Many hackers consider what they do a sort of game, and DirecTV decided to actively participate.
This is in contrast to most other companies and organizations, such as the Microsoft and the RIAA/MPAA... even companies such as Rambus, Apple, Fraunhoffer, etc. who attempt to enforce what they feel is 'their' property not by any technical means, but by patents and lawsuits.
Now, I'm disgusted by, for example, what the MPAA is trying to do with DeCSS; however, I would have a lot more respect for them if they took a more DirecTV-type approach, and tried to figure out technical means to 'throw a wrench in the works'. If they think some of their.. property (? content? data? I'm not even sure exactly...) is being violated, they should be able to protect it themselves. They don't have the luxury of being able to update the embedded software on all existing DVD players; maybe they could just declare that they screwed up, and that DVDs can't offer the kind of content control that they want. (Of course, it's a bit late to propose any kind of alternative, but still.)
In any case, DirecTV's being a good guy throughout this, I would think -- and I might even be buying their systems in the future. (This in contrast to other satellite networks that will be locking out some HD content from being viewed with HDTV equipment that doesn't have media access control capabilities!)
I recently spoke with a pediatric clininc that was looking to move to a more modern appointment and billing system. They are using an antiquated DOS and NetWare based system that has grown insufficient for their needs. Unfortunately, when they showed me the top two offerings, they both were horrible. One that they investigated involved the server being somewhere in Texas, while they (at their clinic) used Citrix WinFrame to view applications on the server, with 6 stations running concurrently over SDSL!
;-). But all the solutions providers seem to be pushing old technology that they may have dressed up as 'client server' from something that isn't (i.e. the Citrix WinFrame attempts), or have just put a pretty face on some big iron server (i.e. using TN3270 as a front-end).
In talking with them, it seemed that there were really no flexible, modern solutions for what they needed -- a multi-physician appointment scheduling and billing system. It sounds like it should be a fairly straightforward thing to implement -- a decent database backend (say, PostgreSQL) along with a nice GNOME/Gtk front-end (of course, I say this never having written such a system
I'm glad to hear about attempts such as the one described to create a modern medical office -- it will be interesting to see what problems they run into and how they are solved. Hopefully something like this will be a wakeup call to solutions providers.
Incidentally, from a free software perspective, I wonder if a free software application could be accepted in this community. Small clinics could use the software as-is, and large clinics could contract the developer for customization. But again, would such a solution be looked down on because it's free and open sourced, something not often (ever?) heard in the medical community?