What do you think about color depth? 8 bits per component is fine for TV viewing, but it might lead to visible banding/lack of dynamic range in a darkened theater. (I'd love to hear from you as I know DD is one of the few studios in the world that seems to truly care about recreating film's color and brightness response =)
At least with a digital projector the video signal can stay RGB all the way through the pipeline. I'm of the opinion that repeated RGB-YUV-RGB conversions are at least as liable to cause problems as 8-bit color...
Mackie (the audio equipment maker) does a really stellar job of writing interesting, funny manuals. I picked up my mixer manual to find out how the tape outs operated, and ended up spending an hour reading the whole thing...
Yes, the Lightwave manuals (and the community in general) were and are still great... Remember the Modeler plugin 'Fori's Boner'? I think it actually shipped with LW at one point (or maybe it's just left around from an earlier installation). And boy do I wish they'd finally ship make-not-suck.p (the secret plugin used by high-end SFX houses everywhere!)
Keep your valuable files on a Linux machine (running on good hardware you can trust, a stable kernel, a journaling filesystem, and software RAID if you want to go that far). Do backups from there. Run NFS to serve all non-Windows clients. Run SAMBA to serve Windows clients.
Sharing data files is easy with the NFS/SAMBA combination - e.g. non-Windows machines mount my home directory as/home/foo and on Windows it's H:\ - all the files are there.
Sharing software is less easy since none of the common UNIXy filesystem layouts really let you have binaries for multiple platforms available at once. There are unconventional layouts that do this, but you'll have to compile a lot of things yourself and mess with configure scripts a lot... I've given up on sharing binaries and libs; I just run Debian on as many of my systems as possible, and run a script now and then that ensures the same packages are installed on each machine.
For remote work I use SSH to set up a VPN. However, unless I'm on a very low-latency connection, I find it difficult to use a shell remotely, much less NFS. I usually end up manually rsync'ing the files I need.
I don't particularly care about proprietary as in "controlled by one company," but I do dislike proprietary as in "different from standard practice for no good reason." I think it was unfortunate that the inventors of DVD went off and created their own half-baked UI system when better alternatives were in already in use. (yeah, that's about par for the course for most consumer electronics standards... =)
Nor do I really like how most DVD releases use the menu UI system. I hate wading through un-stoppable movie menus to get where I want to go. I really wish DVD had the feature of laserdisc where you could just punch in "take me to frame #18275" and it would jump there immediately.
(BTW I believe the specs for the Flash.swf file format are freely available, although I am not aware of any complete Free Software implementation.)
The one thing I wish were done a little differently with DVD (from the perspective of one who occasionally needs to author them) is the menu system. Instead of DVD's convoluted, proprietary menu implementation, I'd really prefer to see something like Flash or even dynamic HTML with Javascript. Imagine what DVD creators could do if they knew every DVD player had a Flash interpreter... (acknowledging of course that Flash was in a much more primitive state back when DVDs were being developed, if it even existed at the time:])
Yes... Presumably software vendors have chosen their (high) prices because that's where the peak of the profit/price curve is. But as you point out, the profit curve might have another local maximum at the lower end of the price range, where profits could exceed those at the high end.
I can see the major software companies varying their prices by say 20% or 50% in search of the high-price local maximum, but they're probably too scared to drop down into the low-price regime (even if the low-price maximum would lead to higher profits overall).
This seems to be changing, however, in one market I am familiar with - 3D graphics software. Every major vendor (with the exception of Discreet) has announced huge price cuts in the last few months, including free or low-cost "educational" packages, and even some of the "pro" packages are now selling at 10% of their original price. You might say they're all looking for that low-cost sweet spot... (or, they could just be reacting to a saturated market and lack of innovation in their own products, but that's another discussion...)
This article, which I though was generally excellent, unfortunately stops short of naming the MPAA's true goal - continuing its monopoly on the production of blockbuster movies by ensuring that no high-quality filmmaking equipment falls into the hands of non-studio filmmakers.
Back in the pre-digital days it was easy for a determined independent artist to throw together some analog video equipment (eg consumer VHS decks, camcorders, and mixers) and make a film. The only thing you couldn't easily do is distribute the result to a wide audience...
Now, thanks to the internet, anyone who can compress some videos and set up a web server can theoretically distribute films.
*BUT* look at where the technology is going... There is no cheap digital recording and distribution system that is accessible to independent artists. (yeah, DV is fairly cheap - except for editing decks - but you can't *distribute* on DV). You can buy DVD burners for a few hundred dollars now, but consumer-level burners do not let you "author" a properly-formatted, CSS-scrambled DVD like the megadollar Hollywood systems can. And there is certainly no low-cost high-definition format on the horizon - HDCAM is insanely expensive, and HD DVD will be read-only. Broadcast digital video systems use obfuscated encryption methods and will only be accessible to studio productions.
It's in Hollywood's best interest to keep recording and distribution technologies out of the hands of independent artists. Using the cry of "piracy!" as a distraction, they are trying to pass laws that will basically make it illegal to use high-quality video equipment outside of the studio system. This way the MPAA companies will maintain their control over what films get made, resulting in fewer choices and higher prices (the inevitable consequences of a successful monopoly).
Incidentally, in my own production work I've already been hindered by the media industry's efforts. On two occasions I've had to perform a digital->analog->digital dub to record copy-protected music, *the rights for which I had legally paid for*... Also, I've been forced to reverse-engineer a high-definition video transmission format, because no such equipment is available to those without a studio-level budget.
Speaking of technology disasters- What about Microsoft Outlook, whose many unfixed security flaws have brought about waves of email-borne virii, costing millions of dollars in lost data and productivity?
Case independence is a UI issue that has leaked into low-level implementations and is an endless source of bugs and security errors.
I agree... I think most people don't see case-independence as a UI issue because they're used to English, where the mapping from uppercase to lowercase is trivial. (b = a + ('a' - 'A') or whatever)... But other langauges have much more complicated sets of characters that should be equivalent for "filename search" purposes - Consider Japanese, where you've got a much larger mapping (Katakana <-> Hiragana), or Chinese, where thousands of characters have both Traditional and Simplified forms (distinct Unicode codepoints), and there is no order whatsoever to the mapping. I doubt any sane OS developer would even consider embedding the huge Traditional/Simplified character mapping table in the kernel.
IMHO BSD shows more taste these days, at least considering things like restraint in the face of code/feature bloat... GLIBC is not my definition of taste! (Just *try* getting it to compile to less than 1MB, I dare you... Enjoy your 200KB statically-linked hello-world.c, and your 400KB static hello-world.cpp)
Sixty percent of those surveyed believe in ESP, psychic power, and alien abduction
I disagree with the implication of this statement - as if one's belief in ESP, psychic powers, and alien abductions means that one is obviously a science illiterate.
If one believes blindly, without considering the large volume of oppposing evidence, then I would say you are ignorant of science. But as far as I know there is no *unquestionably conclusive* evidence that disproves any of these things (we may have debunked every report of alien abduction, but that does not mean all future reports will be false also). So it would be equally unscientific to dismiss all claims of paranormal phenomena as ridiculous... (even stranger things than ESP have turned out to be true, despite overwhelming disbelief by scientists - consider quantum mechanics in its early days!)
Science is fundamentally about asking questions of the world, forming explanations, gathering evidence to test one's theories, and accepting the results - whether supportive or contrary. A scientifically-minded person always keeps a skeptical, though responsibly informed, view on the world.
Slashdot editors - Please stop posting minor product announcements as news items. There are lots of other sites that do a better job of covering this kind of thing. Please keep it to "Stuff that matters."
Bill, I think the "push vs pull" distinction he is talking about has to do with who dispatches events (i.e. where the huge switch(event_type) {...} statement is)... On Windows your own app does its own dispatching in the window procs. On GTK, Qt, etc, you set up event handlers using their API, and then the library does all the dispatching behind the scenes.
I am undecided which approach I like better. The GTK/Qt event handling systems are certainly more elegaant than Win32, but I have to admit I really like the simplicity of window procedures (MS uses these everywhere - 1 function pointer that gets an event code and 2 word-length args - simples as pie)... I'm pretty sure a typical Win32 app will dispatch events faster; GTK (the X widget library I'm most familiar with) introduces a heck of a lot of of overhead between the underlying call to select/poll and your event handler. I also like how Win32 makes it easy to take some action on several different events, just by adding some more code to the big switch() statement. (rather than mucking with lots of event handler registrations)
Re:extension? what do we need the extension for?
on
JPEG2000 Coming Soon
·
· Score: 2
The idea is that getting at least the first block of bytes of a file mapped into memory is much faster than opening the file. On Unix I propose that a block of data of a guaranteed minimum size be stored in the Inode and that getting it would be as fast as getting the permission of a file today
A lot of newer filesystems do pack small files into the inode (reiserfs, BFS, and xfs too, I think)... This is not too much of a leap from storing the first few bytes of a large file there too. (I would modify your statement about "mapping" the beginning of the file though - a simple read() will be much much faster when you consider the page table manipulation overhead of mmap()).
Have you looked at reiserfs? Hans Reiser shares this philosophy - although he is aiming more toward supporting things like hierarchical configuration documents being expressed as dense directory trees with tiny files, each holding only a few bytes (as opposed to a single text file with internal hierarchical structure, eg XML). I remember Reiser saying something like "who needs extended file attributes when you have very fast directories?" (*)
* incidentally, consider that Microsoft invented the Registry (which is essentially an in-memory filesystem) because storing all that data in a directory tree was too slow with NTFS...
You let the software call the built-in decrypt function and then once it's decrypted itself you suspend operation and write it out to file. Fix up the loader and you've got a working application.
I think you missed my point - by embedding the encryption into the CPU, you would *never* expose the decrypted code, not even in RAM. (the CPU could decrypt the instruction stream on the way from the L1 cache into the execution pipeline). With any software-based encryption scheme your method works fine - just use a debugger to dump the decrypted bytes. But a hardware scheme like this is not vulnerable to these attacks. (you'd literally have to open up the CPU core and probe the circuits to find the decrypted code or better yet the private key... I'm not sure that's even possible; at the very least you'd need some mega-expensive equipment)
Several people have pointed out that encrypted binaries would only be valid for one CPU. Yep... Since when do software companies care? I once got delayed by several days on a real project because my Ethernet card died, and I was using an expensive program that locks itself to your MAC address... (anyone know how to spoof a MAC address in Windows?)
Others will send some other public key, specifically one which they know the private key for.
That's why the software vendor has to check Intel's list first, to make sure the public key corresponds to a real CPU and was not just made up. (yes you could get a distributed effort going to reverse one of the public keys, but they could be arbitrarily long...)
Re:Some helpful links with reg code generation inf
on
More On Policing Shareware
·
· Score: 4, Interesting
There is a variant of this system that would be virtually impossible to crack... Intel & AMD would have to embed a private key in the CPU core. When buying software, you would present the public key that corresponds to your CPU. The software vendor would check this against a list of valid keys published by Intel (to prevent people from making their own key pairs), encrypt the software using your public key, and then send it to you. Your CPU would decrypt the code as it executes using the private key embedded in it. The binary would not work on any other CPU.
A hardware-based system like this is many orders of magnitude more secure than a software-based system, because the software remains encrypted all the way up to the CPU. The only way to break it would be to find one of the embedded private keys ($$$ equipment)... Or to convince a software vendor to encrypt with a made-up key that you know both public & private parts of...
BTW, this is also the basic framework for audio/video copy-prevention systems. (CSS works like this, except there are only a handful of private keys, and the CSS encryption algorithm is flawed)
You also have to consider L1/L2 cache space, which is unfortunately not as plentiful as RAM... If you're running 10 programs, and each one has its own version of, say, malloc() that takes, say, 10KB of L2 cache, then you've just given up 100KB of L2... (most consumer CPUs these days have only 256KB of L2, although some have 512...)
But nonetheless, in the end I'd still prefer to take the performance hit in order to become immune to versioning conflicts. Nobody seems to be able to get shared library/shared data versioning right... (Debian comes pretty close though, and I have high hopes for.NET assemblies... But it remains to be seen whether third-party.NET vendors will be able to keep things clean in the versioning department...)
It's not RedHat's fault that g++ breaks backward compatibility.
Yes, it is! They could have shipped the older version, or both! The role of a distributor like Red Hat is to insulate users from version skew and API breakage. I'd expect compatibility problems if I were compiling from source, but not with a "professional" distro...
Debian will eventually switch to the new libstdc++ as well... Of course. And when they do, they will *rename* the library, so that both versions can be installed concurrently, and no software will break.
The Fundamental Law of Software Packaging is: if the API changes (in a backwards-incompatible way), you must change the name of the library. Debian understands this. Red Hat does not.
Agreed. The moment I lost my faith in RPM was when I saw this on the mozilla FTP site:
Red_Hat_6x_RPMS/ Red_Hat_7x_RPMS/
Two different RPMs for different "versions" of Red Hat?!? I thought RPM was supposed to take care of dependencies automatically? (note: the reason for this is that Red Hat, for some unknown reason, shipped mutually-incompatible versions of libstdc++ in 6.x and 7.x.)
That was also the moment I decided to switch to Debian - now *those* developers *care* about proper version management. Bye bye, Red Hat.
Wouldn't the ideal desktop environment simply carry your own settings over to the new machine when you logged in? You should never have to be exposed to someone else's customized environment; you could just carry your own environment around with you...
(maybe Jef spent too much time around single-user Apple machines and not enough time on UNIX, hehe =)
NFS rocks. Coming from the PC world, I was shocked when I discovered how long this useful standard has been around, and how compatible the implementations are... A little while ago I added an old SGI Indy to my Linux network. I tried mounting my primary NFS share on it, expecting to spend several hours troubleshooting in IRIX before it would work. And whaddya know, it came up perfectly the first time =).
Slashdot Mirror
At least with a digital projector the video signal can stay RGB all the way through the pipeline. I'm of the opinion that repeated RGB-YUV-RGB conversions are at least as liable to cause problems as 8-bit color...
Mackie (the audio equipment maker) does a really stellar job of writing interesting, funny manuals. I picked up my mixer manual to find out how the tape outs operated, and ended up spending an hour reading the whole thing...
Yes, the Lightwave manuals (and the community in general) were and are still great... Remember the Modeler plugin 'Fori's Boner'? I think it actually shipped with LW at one point (or maybe it's just left around from an earlier installation). And boy do I wish they'd finally ship make-not-suck.p (the secret plugin used by high-end SFX houses everywhere!)
Keep your valuable files on a Linux machine (running on good hardware you can trust, a stable kernel, a journaling filesystem, and software RAID if you want to go that far). Do backups from there. Run NFS to serve all non-Windows clients. Run SAMBA to serve Windows clients.
/home/foo and on Windows it's H:\ - all the files are there.
Sharing data files is easy with the NFS/SAMBA combination - e.g. non-Windows machines mount my home directory as
Sharing software is less easy since none of the common UNIXy filesystem layouts really let you have binaries for multiple platforms available at once. There are unconventional layouts that do this, but you'll have to compile a lot of things yourself and mess with configure scripts a lot... I've given up on sharing binaries and libs; I just run Debian on as many of my systems as possible, and run a script now and then that ensures the same packages are installed on each machine.
For remote work I use SSH to set up a VPN. However, unless I'm on a very low-latency connection, I find it difficult to use a shell remotely, much less NFS. I usually end up manually rsync'ing the files I need.
Hehe, good one... I call it "Digital Restrictions Management" - 'cause that's what it is. "Our Motto: Helping You Do Less With Your Technology."
I don't particularly care about proprietary as in "controlled by one company," but I do dislike proprietary as in "different from standard practice for no good reason." I think it was unfortunate that the inventors of DVD went off and created their own half-baked UI system when better alternatives were in already in use. (yeah, that's about par for the course for most consumer electronics standards... =)
.swf file format are freely available, although I am not aware of any complete Free Software implementation.)
Nor do I really like how most DVD releases use the menu UI system. I hate wading through un-stoppable movie menus to get where I want to go. I really wish DVD had the feature of laserdisc where you could just punch in "take me to frame #18275" and it would jump there immediately.
(BTW I believe the specs for the Flash
The one thing I wish were done a little differently with DVD (from the perspective of one who occasionally needs to author them) is the menu system. Instead of DVD's convoluted, proprietary menu implementation, I'd really prefer to see something like Flash or even dynamic HTML with Javascript. Imagine what DVD creators could do if they knew every DVD player had a Flash interpreter... (acknowledging of course that Flash was in a much more primitive state back when DVDs were being developed, if it even existed at the time :])
Yes... Presumably software vendors have chosen their (high) prices because that's where the peak of the profit/price curve is. But as you point out, the profit curve might have another local maximum at the lower end of the price range, where profits could exceed those at the high end.
I can see the major software companies varying their prices by say 20% or 50% in search of the high-price local maximum, but they're probably too scared to drop down into the low-price regime (even if the low-price maximum would lead to higher profits overall).
This seems to be changing, however, in one market I am familiar with - 3D graphics software. Every major vendor (with the exception of Discreet) has announced huge price cuts in the last few months, including free or low-cost "educational" packages, and even some of the "pro" packages are now selling at 10% of their original price. You might say they're all looking for that low-cost sweet spot... (or, they could just be reacting to a saturated market and lack of innovation in their own products, but that's another discussion...)
This article, which I though was generally excellent, unfortunately stops short of naming the MPAA's true goal - continuing its monopoly on the production of blockbuster movies by ensuring that no high-quality filmmaking equipment falls into the hands of non-studio filmmakers.
Back in the pre-digital days it was easy for a determined independent artist to throw together some analog video equipment (eg consumer VHS decks, camcorders, and mixers) and make a film. The only thing you couldn't easily do is distribute the result to a wide audience...
Now, thanks to the internet, anyone who can compress some videos and set up a web server can theoretically distribute films.
*BUT* look at where the technology is going... There is no cheap digital recording and distribution system that is accessible to independent artists. (yeah, DV is fairly cheap - except for editing decks - but you can't *distribute* on DV). You can buy DVD burners for a few hundred dollars now, but consumer-level burners do not let you "author" a properly-formatted, CSS-scrambled DVD like the megadollar Hollywood systems can. And there is certainly no low-cost high-definition format on the horizon - HDCAM is insanely expensive, and HD DVD will be read-only. Broadcast digital video systems use obfuscated encryption methods and will only be accessible to studio productions.
It's in Hollywood's best interest to keep recording and distribution technologies out of the hands of independent artists. Using the cry of "piracy!" as a distraction, they are trying to pass laws that will basically make it illegal to use high-quality video equipment outside of the studio system. This way the MPAA companies will maintain their control over what films get made, resulting in fewer choices and higher prices (the inevitable consequences of a successful monopoly).
Incidentally, in my own production work I've already been hindered by the media industry's efforts. On two occasions I've had to perform a digital->analog->digital dub to record copy-protected music, *the rights for which I had legally paid for*... Also, I've been forced to reverse-engineer a high-definition video transmission format, because no such equipment is available to those without a studio-level budget.
Speaking of technology disasters- What about Microsoft Outlook, whose many unfixed security flaws have brought about waves of email-borne virii, costing millions of dollars in lost data and productivity?
I agree... I think most people don't see case-independence as a UI issue because they're used to English, where the mapping from uppercase to lowercase is trivial. (b = a + ('a' - 'A') or whatever)... But other langauges have much more complicated sets of characters that should be equivalent for "filename search" purposes - Consider Japanese, where you've got a much larger mapping (Katakana <-> Hiragana), or Chinese, where thousands of characters have both Traditional and Simplified forms (distinct Unicode codepoints), and there is no order whatsoever to the mapping. I doubt any sane OS developer would even consider embedding the huge Traditional/Simplified character mapping table in the kernel.
IMHO BSD shows more taste these days, at least considering things like restraint in the face of code/feature bloat... GLIBC is not my definition of taste! (Just *try* getting it to compile to less than 1MB, I dare you... Enjoy your 200KB statically-linked hello-world.c, and your 400KB static hello-world.cpp)
My preferred method of CD enhancement is the application of a 5.56mm projectile at 3000fps.
I disagree with the implication of this statement - as if one's belief in ESP, psychic powers, and alien abductions means that one is obviously a science illiterate.
If one believes blindly, without considering the large volume of oppposing evidence, then I would say you are ignorant of science. But as far as I know there is no *unquestionably conclusive* evidence that disproves any of these things (we may have debunked every report of alien abduction, but that does not mean all future reports will be false also). So it would be equally unscientific to dismiss all claims of paranormal phenomena as ridiculous... (even stranger things than ESP have turned out to be true, despite overwhelming disbelief by scientists - consider quantum mechanics in its early days!)
Science is fundamentally about asking questions of the world, forming explanations, gathering evidence to test one's theories, and accepting the results - whether supportive or contrary. A scientifically-minded person always keeps a skeptical, though responsibly informed, view on the world.
Slashdot editors - Please stop posting minor product announcements as news items. There are lots of other sites that do a better job of covering this kind of thing. Please keep it to "Stuff that matters."
Bill, I think the "push vs pull" distinction he is talking about has to do with who dispatches events (i.e. where the huge switch(event_type) {...} statement is)... On Windows your own app does its own dispatching in the window procs. On GTK, Qt, etc, you set up event handlers using their API, and then the library does all the dispatching behind the scenes.
I am undecided which approach I like better. The GTK/Qt event handling systems are certainly more elegaant than Win32, but I have to admit I really like the simplicity of window procedures (MS uses these everywhere - 1 function pointer that gets an event code and 2 word-length args - simples as pie)... I'm pretty sure a typical Win32 app will dispatch events faster; GTK (the X widget library I'm most familiar with) introduces a heck of a lot of of overhead between the underlying call to select/poll and your event handler. I also like how Win32 makes it easy to take some action on several different events, just by adding some more code to the big switch() statement. (rather than mucking with lots of event handler registrations)
A lot of newer filesystems do pack small files into the inode (reiserfs, BFS, and xfs too, I think)... This is not too much of a leap from storing the first few bytes of a large file there too. (I would modify your statement about "mapping" the beginning of the file though - a simple read() will be much much faster when you consider the page table manipulation overhead of mmap()).
Have you looked at reiserfs? Hans Reiser shares this philosophy - although he is aiming more toward supporting things like hierarchical configuration documents being expressed as dense directory trees with tiny files, each holding only a few bytes (as opposed to a single text file with internal hierarchical structure, eg XML). I remember Reiser saying something like "who needs extended file attributes when you have very fast directories?" (*)
* incidentally, consider that Microsoft invented the Registry (which is essentially an in-memory filesystem) because storing all that data in a directory tree was too slow with NTFS...
I think you missed my point - by embedding the encryption into the CPU, you would *never* expose the decrypted code, not even in RAM. (the CPU could decrypt the instruction stream on the way from the L1 cache into the execution pipeline). With any software-based encryption scheme your method works fine - just use a debugger to dump the decrypted bytes. But a hardware scheme like this is not vulnerable to these attacks. (you'd literally have to open up the CPU core and probe the circuits to find the decrypted code or better yet the private key... I'm not sure that's even possible; at the very least you'd need some mega-expensive equipment)
Several people have pointed out that encrypted binaries would only be valid for one CPU. Yep... Since when do software companies care? I once got delayed by several days on a real project because my Ethernet card died, and I was using an expensive program that locks itself to your MAC address... (anyone know how to spoof a MAC address in Windows?)
That's why the software vendor has to check Intel's list first, to make sure the public key corresponds to a real CPU and was not just made up. (yes you could get a distributed effort going to reverse one of the public keys, but they could be arbitrarily long...)
There is a variant of this system that would be virtually impossible to crack... Intel & AMD would have to embed a private key in the CPU core. When buying software, you would present the public key that corresponds to your CPU. The software vendor would check this against a list of valid keys published by Intel (to prevent people from making their own key pairs), encrypt the software using your public key, and then send it to you. Your CPU would decrypt the code as it executes using the private key embedded in it. The binary would not work on any other CPU.
A hardware-based system like this is many orders of magnitude more secure than a software-based system, because the software remains encrypted all the way up to the CPU. The only way to break it would be to find one of the embedded private keys ($$$ equipment)... Or to convince a software vendor to encrypt with a made-up key that you know both public & private parts of...
BTW, this is also the basic framework for audio/video copy-prevention systems. (CSS works like this, except there are only a handful of private keys, and the CSS encryption algorithm is flawed)
You also have to consider L1/L2 cache space, which is unfortunately not as plentiful as RAM... If you're running 10 programs, and each one has its own version of, say, malloc() that takes, say, 10KB of L2 cache, then you've just given up 100KB of L2... (most consumer CPUs these days have only 256KB of L2, although some have 512...)
.NET assemblies... But it remains to be seen whether third-party .NET vendors will be able to keep things clean in the versioning department...)
But nonetheless, in the end I'd still prefer to take the performance hit in order to become immune to versioning conflicts. Nobody seems to be able to get shared library/shared data versioning right... (Debian comes pretty close though, and I have high hopes for
It's not RedHat's fault that g++ breaks backward compatibility.
Yes, it is! They could have shipped the older version, or both! The role of a distributor like Red Hat is to insulate users from version skew and API breakage. I'd expect compatibility problems if I were compiling from source, but not with a "professional" distro...
Debian will eventually switch to the new libstdc++ as well...
Of course. And when they do, they will *rename* the library, so that both versions can be installed concurrently, and no software will break.
The Fundamental Law of Software Packaging is: if the API changes (in a backwards-incompatible way), you must change the name of the library. Debian understands this. Red Hat does not.
Agreed. The moment I lost my faith in RPM was when I saw this on the mozilla FTP site:
Red_Hat_6x_RPMS/
Red_Hat_7x_RPMS/
Two different RPMs for different "versions" of Red Hat?!? I thought RPM was supposed to take care of dependencies automatically? (note: the reason for this is that Red Hat, for some unknown reason, shipped mutually-incompatible versions of libstdc++ in 6.x and 7.x.)
That was also the moment I decided to switch to Debian - now *those* developers *care* about proper version management. Bye bye, Red Hat.
Wouldn't the ideal desktop environment simply carry your own settings over to the new machine when you logged in? You should never have to be exposed to someone else's customized environment; you could just carry your own environment around with you...
(maybe Jef spent too much time around single-user Apple machines and not enough time on UNIX, hehe =)
NFS rocks. Coming from the PC world, I was shocked when I discovered how long this useful standard has been around, and how compatible the implementations are... A little while ago I added an old SGI Indy to my Linux network. I tried mounting my primary NFS share on it, expecting to spend several hours troubleshooting in IRIX before it would work. And whaddya know, it came up perfectly the first time =).