Yes, it would be a good idea if the server could spill window buffers into main RAM if video RAM fills up. (I'm not sure what X and GDI do about this - I have a feeling they might just fail the buffer allocation). A lot of OpenGL drivers do this kind of thing for texture allocation.
You have to be careful though because there is a performance penalty for transferring data to/from the video card. In fact this is the primary reason Mac OSX feels so slow - all drawing (including window compositing) is done on the CPU, and window buffers must be uploaded to the graphics card before they can be drawn. (Jaguar improves the architecture somewhat - I think it does window compositing in graphics hardware, but rendering of the window contents is still done on the CPU).
Your description is correct. However the blocking behavior is simply an implementation detail of the window manager; if the developers of MS Windows cared enough to fix it, I'm sure they could easily change the wm so that it only blocks the misbehaving application, and lets other applications run normally.
By the same token, it should be possible for an X window manager and X application to cooperate and properly synchonize window resizing.
Thank you for pointing this out! I have also done some very detailed studies of why window dragging and resizing suck so badly on X. I discovered a few things:
* XFree's event loop is triggered by mouse and keyboard input, not the vertical retrace. This means that XFree will (stupidly) attempt to handle more than one mouse event per display refresh, which is a waste of time and creates flicker. XFree also appears to ignore mouse movement events occasionally (which is why window dragging on X feels "sticky" sometimes).
Incidentally, if you have a USB mouse, try dropping your display resolution so you can achieve a 125Hz refresh rate. You will notice that window dragging becomes *much* smoother, and flicker almost entirely disappears. This is because USB mice send events at a fixed rate of 125Hz, so you are forcing the X server to operate "in sync" with the mouse. (but you are only matching the interrupt rate; there is still a "phase shift" - this creates interesting artifacts where a window will "tear" in a fixed place)
* The main problem with window resizing is that the application and the window manager operate too asynchronously. On MS Windows, once the window manager sends the first resize event to the app, it will block until the app repaints itself. But on X the window managers do NOT block, so the window border can continue to move, and get arbitrarily out of sync with the window contents.
Yes you can use X pixmaps (and on NT you can use images) to make fake double-buffering. However this still requires a round trip to the app for it to say "the way to repaint is to copy this area". This is nowhere near as good as double-buffering understood by the system, as it is in OS/X and in the newer versions of Windows.
By this are you referring to the ability of drawing into an offscreen pixmap, and then setting that pixmap as the background of a window? I know I've done this on X. It is very smooth. The server effectively handles all redraw events itself.
The only problem is that you could run out of video RAM, so I'd only recommend this technique for windows that are especially expensive to redraw (e.g. an OpenGL window).
Yes, I'd say that RPM + automatic dependency downloader = APT. However, the important thing is that the developers of APT-based distributions traditionally pay a lot more attention to forward- and backward-compatibility than RPM-based distros.
As you pointed out, on Debian the major library version number is appended to the library name, e.g. libgnomeprint0. This is because the Debian people know that at some point in the future, the GNOME developers *will* break the libgnomeprint API. Then they will label the new package libgnomeprint1, and all your software continues to work. On Redhat it would still be named libgnomeprint, and you wouldn't be able to install the new version until all apps using the old version are fixed and recompiled...
Give APT to the Redhat folks, and before long you will end up in "APT hell," I guarantee it =).
glibc and gcc breakages are a separate issue. The developers of those packages need to be shot... I've read posts to the gcc mailing lists regarding libgcc that show most gcc developers haven't the faintest idea what "backwards compatibility" means.
Very, very good points, especially about regression testing. Most software companies have enough trouble verifying that their own code works correctly; it gets worse when third-party dll developers can make changes at their whim...
Binary software vendors have been doing a better job of not breaking DLL interfaces. It comes out of necessity - you can't just ask each of your customers to recompile a whole bunch of things every time you make a change (like some open-source library developers have been known to do =).
Consider the *immense* lengths that Microsoft has gone to in order to avoid breaking user32.dll and msvcrt.dll after umpteen different changes. (e.g. according to Joel Spolsky/Joelonsoftware.com, MS kept a bug in malloc/free just so that SimCity would continue to run on Windows 95).
I do see a certain advantage to DLLs however - cache footprint. It is better to have one shared copy of a "hot" function like malloc() than many statically-linked copies... But this is a really small concern.
Keep in mind that even if all executables are 100% statically linked, they still depend on a stable kernel syscall interface. The Linux kernel developers have been pretty good about binary API stability over the years, but there have been occasional breakages. (e.g. changing the layout of files in/proc)
Actually, a Gaussian blur is a very good thing to do if the DAC's maximum sample rate happens to be lower than the original sample rate of your music =)...
I am very impressed with the results that have been coming out of NVIDIA and Stanford, such as their work on ray-tracing and global illumination (!) on commodity graphics cards.
The one thing, however, that I see blocking the use of GPUs for general-purpose high-quality rendering is sampling (the technique of avoiding aliases by low-pass filtering the scene at various stages of rendering). All of the GPUs I have seen are limited to dumb box filtering of texture and pixel samples. (i.e. calculate the color at several points inside a region and average the results). The best software renderers do a much more careful job of surpressing high frequencies while keeping the good low frequencies. (e.g. using a several-pixel-wide Gaussian or windowed sinc filter). While these methods are more computationally expensive than the box, they are much better low-pass filters. It makes good sense to choose them for final high-quality rendering.
High depth (10-16 bits/component) framebuffers are another necessity, but I hear they will be available in hardware very soon...
Re:I know, it's a feature.
on
Pet Bugs?
·
· Score: 2
Are you sure you weren't just seeing stdio line buffering? Assuming Perl's print() uses stdio internally, output won't be flushed to stdout until it sees a \n character.
Cost of new money cost of counterfeiting
on
Greenbacks No More
·
· Score: 2
Changing the form of paper money is not without costs. Consider that vending machines, subway machines, and any other bill-accepting device must be upgraded to recognize the new format.
I read in the USA Today this morning that last time our paper currency was altered (1996), it cost the vending industry $350 million to adapt. The same article quotes that only about $50 million in counterfeit currency is passed per year.
Is it just me, or does this sound like a huge waste of money? By changing the currency once again, the government is going to force the vending industry through another huge upgrade, the costs of which will inevitably be passed on to consumers. All to counter a measly $50 million in counterfeiting?
I understand that aside from the dollar cost of counterfeiting, there is also the issue of trust in the currency (a legitimate dollar is worth a little less when counterfeiting is widely suspected). But still, the vending industry's $350 million investment only lasted 6 years, and I bet most of the money was spent earlier rather than later, so even the amortized cost is still much higher than the cost of counterfeiting.
I wouldn't be surprised to find out if the lawmakers that allowed this just happen to be in the home state/city of a vending machine parts manufacturer... Government waste makes me sick.
I firmly believe that once nanotechnology becomes advanced enough, most other forms of medicine will disappear. There will be no reason to mess with exotic pharmaceutical compounds when you can have little machines roving around your body, "fixing" things mechanically...
Re:standardized locations, etc.
on
Is RPM Doomed?
·
· Score: 2
I like jcast's idea of '/etc/prefixes'. The main point is that this should be taken care of automatically by the package manager. Either that or dropping the boilerplate "export LD_LIBRARY_PATH=foo" script in/usr/bin. I consider Mozilla a good citizen in that all you have to do is link 'mozilla' into/usr/bin and you're all set to go. But consider what happens when you try to install a typical package somewhere other than/usr/local/lib - you can certainly do it with './configure --prefix=/foo', but what happens is THE ABSOLUTE PATHS TO THE LIBRARIES GET HARD-CODED INTO THE EXECUTABLES (can you tell I hate 'ld -rpath' with a vengeance?). If you decide to move the package somewhere else, all executables will break.
BTW I don't really get the whole UNIX thing about never putting '.' into PATH or LD_LIBRARY_PATH. I know it theoretically creates a vulnerability, but has anyone exploited it (in recent history)? Shouldn't binaries and libraries be installed in read-only directories, so that only root could slip in a substitute libc.so? (if root is hostile then you are fucked anyway). Sure you could theoretically be duped into running a malicous 'ls', but is this really a big enough risk to justify the torture of typing./foo all the time? (I swear we could delay the onset of RSI by years if we eliminated './' and 'export LD_LIBRARY_PATH=...' =)
I like the idea of designating a 'core' set of libraries (libc, libpthreads, etc) and binaries (ls, cp, mv, etc) that could never be over-ridden...
I don't understand why people treat "the UNIX way" as some holy order that can't evolve into anything better. UNIX is just one system some guys at Bell Labs hacked out in the 60's. It's not without flaws. (I'm reminded of my IRIX box, which keeps the binary for 'ping' in/etc/ping...). There are lots of groups trying to "do UNIX better" (Miguel of GNOME is explicit about it); of course not all of them will succeed, but I will certainly bet you that we haven't reached the local maximum yet.
Yes, I understand that most prudent Windows developers ship a specific version of MFC.dll and msvcrt.dll. Not all Windows DLLs have remained as compatible as the core...
But you never see anyone replacing gdi32 or advapi32. On the other hand, on Linux I've been bitten several times by incompatibilities between glibc 2.1 and 2.2. (heck even the man pages admit incompatibilities - see 'snprintf' and 'mkstemp'). To me this is akin to a link failure on 'malloc' or 'printf'. It just shouldn't happen in this day and age! I *should* be able to ship a program dynamically linked against GTK, or libtiff, or whatever, and just have it work, same as I can link against user32.dll and know that CreateWindow will act like it should.
I think Microsoft is taking a step in the right direction with.NET assemblies (and their checksummed APIs). A major reason for DLL breakage in the free software world is the lack of any sort of warning that you've broken the API; something as subtle as adding a new virtual function to a C++ class will break binary compatibility... It would be great to have a program that could flag things like this.
If you want to have different versions of a shared library, that's fine, just as long as it's a purely one-dimensional, monotonically increasing measure (i.e. if I declare my program depends on version 4 of libfoo.so, it should be guaranteed to work with version 4, 5, and 50, but not necessarily 1, 2, or 3). But sadly most libraries evolve in such a way that you have to place a ceiling as well as a floor on the appropriate version for your program =).
My favorite approach is to get the API right the first time, and promise never to change it. (yeah, throw release early, release often out the window)... I have actually achieved this with my dv1394 kernel driver - the API was frozen on day one of release, and it has never changed. It took some hard work to convince myself that the API was sufficient for all possible uses, but it was definitely worth it to avoid version skew altogether.
Incidentally, I have to give credit to the developers of GTK. I have been following them through the 2.0 release process, and it seems like they are one of the first free software projects to really take library compatibility seriously.
Re:standardized locations, etc.
on
Is RPM Doomed?
·
· Score: 2
On Windows, the only way the OS knows about a.systemwide dll is when you've added an entry to the registry for it.
I do agree with Windows' conventions on DLL use - '.' is always in the DLL search path, and it's conventional when starting GUI programs to chdir() to their "bin" directory... In order to get this effect on Linux, you have to stick a boilerplate script in/usr/bin that sets LD_LIBRARY_PATH, PATH, etc (Mozilla is a good example of this).
I think one avenue of attack no one has considered yet is modifying/bin/sh. Instead of using a pre-set PATH, perhaps the shell should take it upon itself to search for packages with/bin/ directories, and set LD_LIBRARY_PATH to the corresponding/lib/ directory automatically...
You have to start to think of/usr/bin not as the directory where all your executables go, but simply a directory of command names that are accessible to the shell...
One of the flaws of a shared library directory is that free software developers are notoriously bad at preserving backwards- and forwards- compatibility between different library versions. It does no good to have a single libfoo.so when one of its users relies on a bug in an old version of the library, and another user won't run because it needs a symbol from a newer version.
I can agree with having a common set of very basic libraries - libc, libX11, libgtk, etc - that are used by many programs and whose interfaces have been NAILED DOWN. But pretty much anything else is just too exotic and risky to justify sharing libs.
I am currently working on a commercial software package for Linux, and we firmly plan to link everything statically, except for libc. (we have even considered bypassing glibc - which is bloated and forwards-incompatible - and making the kernel itself our only dependency).
This point may not move you, but Windows has done fine for many years, and over there hardly any "common" libraries exist aside from the stable MS-provided ones (user32.dll, comctrl32.dll, etc...). This may be because Windows developers tend to scream and shout very loudly when somebody breaks the API of a shared library...
I've often thought along these lines, but I don't think a "scaled" approach would really work for most patents. If you made the power of a patent proportional to the R&D cost to invent it, then every company would just cook their books and claim that each and every little device cost $billions...
I do, however, think that certain specific areas could benefit from more or less powerful patents. I know that some kinds of drugs (eg for rare diseases) wouldn't be profitable enough under the current system for companies to justify developing them. Perhaps a special long-term patent could be granted to encourage research into these medicines... And on the other hand, 20 years is way too long for a patent on a software algorithm or method of business...
I will have enough bandwidth when I get transfer rates comprable to the those on my motherboard.
Yes, that's a good observation... You have to watch out for the latency though! Today most software hardly "maxes out" DDR/RDRAM memory because of fetch latencies. Then consider that the pure speed-of-light delay to Korea is on the order of 0.1 seconds...There's no way you're going to be able to run general-purpose software with that kind of latency; heck you would even be able to see the delay on each mouse click!
(come to think of it, this implies that physical size is a fundamental limiting factor on the speed of computers - it does no good to have an infinitely fast CPU if its parts can't communicate rapidly due to speed-of-light delays...)
As the maintainer of a (very small but useful) piece of the Linux kernel, I disagree with the assertion that driver maintenance (keeping up with an unstable API) is cheap. I am very annoyed at the steady stream of patches I have to apply to keep up with even the 2.4 kernel. The worst part is when someone sends a patch directly to Linus or Marcelo - bypassing me and the other guys who maintain our kernel subsystem - so that the mainline kernel ends up out of sync with our own development code repository. We spend too much of our limited kernel-development time chasing API mismatches when we could be fixing real bugs or adding features. (fortunately most API-change problems are caught at compile-time, but there was one recent instance where an unexpected kernel change led to a HUGE but silent memory leak in my code)
I would very, very much prefer if the driver API were frozen at least for the "stable" kernel series. I don't really mind what happens in 2.5.x.
I understand and agree with Linus' philosophy that large-scale code breakages are sometimes required to force reluctant stragglers to adapt to a new, improved API. Just don't do this in a "stable" kernel series!
IMHO the world would also be a better place if binary-only driver vendors (read NVIDIA) had to target only one, stable kernel API. But feel free to disagree...
I believe so, but I haven't actually tested it yet... D-VHS simply requires an MPEG-2 Transport Stream, which is a packetized encoding of one or more MPEG-2 Program Streams. I have been very successfully converting MPEG-2 Program Streams from many sources into MPEG-2 Transport Streams. (this step requires Transport Stream multiplexer software, most of which is non-free. But I have been trying to create my own multiplexer...)
We may find this ironic, but the BPDG actually has a documented set of convoluted rules for what capabilities consumer HDTV equipment will be "allowed" to have. E.g. you can have a digital HDTV output - as long as it is scrambled. You can have an analog output - but only if it is down-converted to NTSC resolution... etc etc...
Unfortunately it is not that simple - the encryption key is specific to the stream... In order to get the key you must go through a handshaking process with the transmitting device - during which you must "prove" that you are a licensed decoder (presumably by proving that you know some sort of secret only given to licensed vendors). I'm not too familiar with the details though, and it's entirely possible that someone will crack this scheme just like CSS was cracked. But the simple approach of playing back a scrambled scream verbatim does not work.
That is correct. The JVC D-VHS deck actually supports a range of resolutions - 720x480 (like DVD) and several HD formats up to 1920x1080 ("1080i" HDTV). It is my understanding that D-Theater commercial releases will be encoded at the full 1080i resolution.
It would be insanely cool if the D-VHS deck's MPEG-2 decoder could understand 3:2 pulldown flags, and generate a true 24fps output. With the right projection system you could essentially get the same image quality as a digital cinema movie theater in your own home! (but you'd need to play it at 1080p (60 frames/sec) or 24p (24 frames/sec), which are unfortunately beyond the range of consumer-level HDTV equipment...
AFAIK the current plan for HDTV DVD calls for using MPEG-4 compression to cram an HDTV movie into almost the same space as today's MPEG-2 SD movies.
D-VHS uses the same MPEG-2 codec as DVD, just at about double the bitrate (the D-VHS streams I have seen are encoded at 15-20MBit/sec, versus 7-9MBit/sec for DVD). So there is only a factor of two difference in data rate, which will be made up for by the new MPEG-4 codec and/or higher-capacity DVDs (shorter wavelength lasers).
I haven't gotten the equipment I need (a nice HDTV monitor) to really evaluate the image quality of D-VHS vs DVD. (For those of you lucky enough to receive HDTV via satellite or over the airwaves, D-VHS will look virtually the same).
Some of the currently-available D-VHS decks support FireWire I/O. This allows one to record and play video to the deck with a computer (the streams can be recorded from the deck - e.g. for PVR-style timeshifting of HDTV - or generated and encoded yourself).
Several people at avsforum.com have already gotten this working using MPEG2-over-FireWire support built into Windows XP.
Dan Dennedy and I are working on a Linux driver that will provide the same functionality as Windows XP. (it will appear at linux1394.sourceforge.net; it's not ready for release yet though).
D-VHS is a truly versatile format. The deck I have experience with (JVC) can record and play MPEG-2 streams at a wide variety of bitrates (up to 29MBit/sec) and formats (720x480 NTSC up to 1920x1080 HDTV)... The encoding is standard MPEG-2, so you can make and play your own HDTV content (I've done it already), and you could probably also do things like record a DVD to tape without re-compressing the video.
Note however that Windows XP and my drivers can only handle cleartext MPEG-2 streams (either home-made or recorded from broadcast/satellite HDTV). The new "D-Theater" standard is basically like DVD's CSS; the MPEG-2 streams will come in a scrambled format that is "impossible" to read without a licensed decoder.
You are very right... There is a big difference between "theft" and "infringement" - both are and should be illegal, but their economic consequences are not the same. Consider that if you really, truly, cannot afford to buy a CD, and decide to download and enjoy it, you will have increased the net happiness of society without costing much at all. (whereas if you really, truly cannot afford to buy food to eat, and steal from someone else, then your gain becomes their loss)... It's only when there are too many freeloaders that the underside of infringement appears - less production of art due to diminished financial returns. In my opinion we very rarely reach this point, despite what the content industry claims. (I doubt there are thousands of budding artists out there saying "gee I'd love to make music, but then it would all get ripped off by freeloaders, I think I'll work a desk job instead...")
BTW unless Eminem has a really sweet record deal, he's out much less than $15 when you decide not to but the CD - probably less than $1 ! =)
(yeah recording engineers & marketers have to take a cut, blah blah blah - no way does that justify current CD prices...)
Slashdot Mirror
Yes, it would be a good idea if the server could spill window buffers into main RAM if video RAM fills up. (I'm not sure what X and GDI do about this - I have a feeling they might just fail the buffer allocation). A lot of OpenGL drivers do this kind of thing for texture allocation.
You have to be careful though because there is a performance penalty for transferring data to/from the video card. In fact this is the primary reason Mac OSX feels so slow - all drawing (including window compositing) is done on the CPU, and window buffers must be uploaded to the graphics card before they can be drawn. (Jaguar improves the architecture somewhat - I think it does window compositing in graphics hardware, but rendering of the window contents is still done on the CPU).
Your description is correct. However the blocking behavior is simply an implementation detail of the window manager; if the developers of MS Windows cared enough to fix it, I'm sure they could easily change the wm so that it only blocks the misbehaving application, and lets other applications run normally.
By the same token, it should be possible for an X window manager and X application to cooperate and properly synchonize window resizing.
Thank you for pointing this out! I have also done some very detailed studies of why window dragging and resizing suck so badly on X. I discovered a few things:
* XFree's event loop is triggered by mouse and keyboard input, not the vertical retrace. This means that XFree will (stupidly) attempt to handle more than one mouse event per display refresh, which is a waste of time and creates flicker. XFree also appears to ignore mouse movement events occasionally (which is why window dragging on X feels "sticky" sometimes).
Incidentally, if you have a USB mouse, try dropping your display resolution so you can achieve a 125Hz refresh rate. You will notice that window dragging becomes *much* smoother, and flicker almost entirely disappears. This is because USB mice send events at a fixed rate of 125Hz, so you are forcing the X server to operate "in sync" with the mouse. (but you are only matching the interrupt rate; there is still a "phase shift" - this creates interesting artifacts where a window will "tear" in a fixed place)
* The main problem with window resizing is that the application and the window manager operate too asynchronously. On MS Windows, once the window manager sends the first resize event to the app, it will block until the app repaints itself. But on X the window managers do NOT block, so the window border can continue to move, and get arbitrarily out of sync with the window contents.
By this are you referring to the ability of drawing into an offscreen pixmap, and then setting that pixmap as the background of a window? I know I've done this on X. It is very smooth. The server effectively handles all redraw events itself.
The only problem is that you could run out of video RAM, so I'd only recommend this technique for windows that are especially expensive to redraw (e.g. an OpenGL window).
Yes, I'd say that RPM + automatic dependency downloader = APT. However, the important thing is that the developers of APT-based distributions traditionally pay a lot more attention to forward- and backward-compatibility than RPM-based distros.
As you pointed out, on Debian the major library version number is appended to the library name, e.g. libgnomeprint0. This is because the Debian people know that at some point in the future, the GNOME developers *will* break the libgnomeprint API. Then they will label the new package libgnomeprint1, and all your software continues to work. On Redhat it would still be named libgnomeprint, and you wouldn't be able to install the new version until all apps using the old version are fixed and recompiled...
Give APT to the Redhat folks, and before long you will end up in "APT hell," I guarantee it =).
glibc and gcc breakages are a separate issue. The developers of those packages need to be shot... I've read posts to the gcc mailing lists regarding libgcc that show most gcc developers haven't the faintest idea what "backwards compatibility" means.
Very, very good points, especially about regression testing. Most software companies have enough trouble verifying that their own code works correctly; it gets worse when third-party dll developers can make changes at their whim...
/proc)
Binary software vendors have been doing a better job of not breaking DLL interfaces. It comes out of necessity - you can't just ask each of your customers to recompile a whole bunch of things every time you make a change (like some open-source library developers have been known to do =).
Consider the *immense* lengths that Microsoft has gone to in order to avoid breaking user32.dll and msvcrt.dll after umpteen different changes. (e.g. according to Joel Spolsky/Joelonsoftware.com, MS kept a bug in malloc/free just so that SimCity would continue to run on Windows 95).
I do see a certain advantage to DLLs however - cache footprint. It is better to have one shared copy of a "hot" function like malloc() than many statically-linked copies... But this is a really small concern.
Keep in mind that even if all executables are 100% statically linked, they still depend on a stable kernel syscall interface. The Linux kernel developers have been pretty good about binary API stability over the years, but there have been occasional breakages. (e.g. changing the layout of files in
Actually, a Gaussian blur is a very good thing to do if the DAC's maximum sample rate happens to be lower than the original sample rate of your music =)...
I am very impressed with the results that have been coming out of NVIDIA and Stanford, such as their work on ray-tracing and global illumination (!) on commodity graphics cards.
The one thing, however, that I see blocking the use of GPUs for general-purpose high-quality rendering is sampling (the technique of avoiding aliases by low-pass filtering the scene at various stages of rendering). All of the GPUs I have seen are limited to dumb box filtering of texture and pixel samples. (i.e. calculate the color at several points inside a region and average the results). The best software renderers do a much more careful job of surpressing high frequencies while keeping the good low frequencies. (e.g. using a several-pixel-wide Gaussian or windowed sinc filter). While these methods are more computationally expensive than the box, they are much better low-pass filters. It makes good sense to choose them for final high-quality rendering.
High depth (10-16 bits/component) framebuffers are another necessity, but I hear they will be available in hardware very soon...
Are you sure you weren't just seeing stdio line buffering? Assuming Perl's print() uses stdio internally, output won't be flushed to stdout until it sees a \n character.
Changing the form of paper money is not without costs. Consider that vending machines, subway machines, and any other bill-accepting device must be upgraded to recognize the new format.
I read in the USA Today this morning that last time our paper currency was altered (1996), it cost the vending industry $350 million to adapt. The same article quotes that only about $50 million in counterfeit currency is passed per year.
Is it just me, or does this sound like a huge waste of money? By changing the currency once again, the government is going to force the vending industry through another huge upgrade, the costs of which will inevitably be passed on to consumers. All to counter a measly $50 million in counterfeiting?
I understand that aside from the dollar cost of counterfeiting, there is also the issue of trust in the currency (a legitimate dollar is worth a little less when counterfeiting is widely suspected). But still, the vending industry's $350 million investment only lasted 6 years, and I bet most of the money was spent earlier rather than later, so even the amortized cost is still much higher than the cost of counterfeiting.
I wouldn't be surprised to find out if the lawmakers that allowed this just happen to be in the home state/city of a vending machine parts manufacturer... Government waste makes me sick.
I firmly believe that once nanotechnology becomes advanced enough, most other forms of medicine will disappear. There will be no reason to mess with exotic pharmaceutical compounds when you can have little machines roving around your body, "fixing" things mechanically...
I like jcast's idea of '/etc/prefixes'. The main point is that this should be taken care of automatically by the package manager. Either that or dropping the boilerplate "export LD_LIBRARY_PATH=foo" script in /usr/bin. I consider Mozilla a good citizen in that all you have to do is link 'mozilla' into /usr/bin and you're all set to go. But consider what happens when you try to install a typical package somewhere other than /usr/local/lib - you can certainly do it with './configure --prefix=/foo', but what happens is THE ABSOLUTE PATHS TO THE LIBRARIES GET HARD-CODED INTO THE EXECUTABLES (can you tell I hate 'ld -rpath' with a vengeance?). If you decide to move the package somewhere else, all executables will break.
./foo all the time? (I swear we could delay the onset of RSI by years if we eliminated './' and 'export LD_LIBRARY_PATH=...' =)
/etc/ping...). There are lots of groups trying to "do UNIX better" (Miguel of GNOME is explicit about it); of course not all of them will succeed, but I will certainly bet you that we haven't reached the local maximum yet.
BTW I don't really get the whole UNIX thing about never putting '.' into PATH or LD_LIBRARY_PATH. I know it theoretically creates a vulnerability, but has anyone exploited it (in recent history)? Shouldn't binaries and libraries be installed in read-only directories, so that only root could slip in a substitute libc.so? (if root is hostile then you are fucked anyway). Sure you could theoretically be duped into running a malicous 'ls', but is this really a big enough risk to justify the torture of typing
I like the idea of designating a 'core' set of libraries (libc, libpthreads, etc) and binaries (ls, cp, mv, etc) that could never be over-ridden...
I don't understand why people treat "the UNIX way" as some holy order that can't evolve into anything better. UNIX is just one system some guys at Bell Labs hacked out in the 60's. It's not without flaws. (I'm reminded of my IRIX box, which keeps the binary for 'ping' in
Yes, I understand that most prudent Windows developers ship a specific version of MFC.dll and msvcrt.dll. Not all Windows DLLs have remained as compatible as the core...
.NET assemblies (and their checksummed APIs). A major reason for DLL breakage in the free software world is the lack of any sort of warning that you've broken the API; something as subtle as adding a new virtual function to a C++ class will break binary compatibility... It would be great to have a program that could flag things like this.
But you never see anyone replacing gdi32 or advapi32. On the other hand, on Linux I've been bitten several times by incompatibilities between glibc 2.1 and 2.2. (heck even the man pages admit incompatibilities - see 'snprintf' and 'mkstemp'). To me this is akin to a link failure on 'malloc' or 'printf'. It just shouldn't happen in this day and age! I *should* be able to ship a program dynamically linked against GTK, or libtiff, or whatever, and just have it work, same as I can link against user32.dll and know that CreateWindow will act like it should.
I think Microsoft is taking a step in the right direction with
If you want to have different versions of a shared library, that's fine, just as long as it's a purely one-dimensional, monotonically increasing measure (i.e. if I declare my program depends on version 4 of libfoo.so, it should be guaranteed to work with version 4, 5, and 50, but not necessarily 1, 2, or 3). But sadly most libraries evolve in such a way that you have to place a ceiling as well as a floor on the appropriate version for your program =).
My favorite approach is to get the API right the first time, and promise never to change it. (yeah, throw release early, release often out the window)... I have actually achieved this with my dv1394 kernel driver - the API was frozen on day one of release, and it has never changed. It took some hard work to convince myself that the API was sufficient for all possible uses, but it was definitely worth it to avoid version skew altogether.
Incidentally, I have to give credit to the developers of GTK. I have been following them through the 2.0 release process, and it seems like they are one of the first free software projects to really take library compatibility seriously.
On Windows, the only way the OS knows about a .systemwide dll is when you've added an entry to the registry for it.
/usr/bin that sets LD_LIBRARY_PATH, PATH, etc (Mozilla is a good example of this).
/bin/sh. Instead of using a pre-set PATH, perhaps the shell should take it upon itself to search for packages with /bin/ directories, and set LD_LIBRARY_PATH to the corresponding /lib/ directory automatically...
/usr/bin not as the directory where all your executables go, but simply a directory of command names that are accessible to the shell...
I do agree with Windows' conventions on DLL use - '.' is always in the DLL search path, and it's conventional when starting GUI programs to chdir() to their "bin" directory... In order to get this effect on Linux, you have to stick a boilerplate script in
I think one avenue of attack no one has considered yet is modifying
You have to start to think of
One of the flaws of a shared library directory is that free software developers are notoriously bad at preserving backwards- and forwards- compatibility between different library versions. It does no good to have a single libfoo.so when one of its users relies on a bug in an old version of the library, and another user won't run because it needs a symbol from a newer version.
I can agree with having a common set of very basic libraries - libc, libX11, libgtk, etc - that are used by many programs and whose interfaces have been NAILED DOWN. But pretty much anything else is just too exotic and risky to justify sharing libs.
I am currently working on a commercial software package for Linux, and we firmly plan to link everything statically, except for libc. (we have even considered bypassing glibc - which is bloated and forwards-incompatible - and making the kernel itself our only dependency).
This point may not move you, but Windows has done fine for many years, and over there hardly any "common" libraries exist aside from the stable MS-provided ones (user32.dll, comctrl32.dll, etc...). This may be because Windows developers tend to scream and shout very loudly when somebody breaks the API of a shared library...
I've often thought along these lines, but I don't think a "scaled" approach would really work for most patents. If you made the power of a patent proportional to the R&D cost to invent it, then every company would just cook their books and claim that each and every little device cost $billions...
I do, however, think that certain specific areas could benefit from more or less powerful patents. I know that some kinds of drugs (eg for rare diseases) wouldn't be profitable enough under the current system for companies to justify developing them. Perhaps a special long-term patent could be granted to encourage research into these medicines... And on the other hand, 20 years is way too long for a patent on a software algorithm or method of business...
I will have enough bandwidth when I get transfer rates comprable to the those on my motherboard.
Yes, that's a good observation... You have to watch out for the latency though! Today most software hardly "maxes out" DDR/RDRAM memory because of fetch latencies. Then consider that the pure speed-of-light delay to Korea is on the order of 0.1 seconds...There's no way you're going to be able to run general-purpose software with that kind of latency; heck you would even be able to see the delay on each mouse click!
(come to think of it, this implies that physical size is a fundamental limiting factor on the speed of computers - it does no good to have an infinitely fast CPU if its parts can't communicate rapidly due to speed-of-light delays...)
As the maintainer of a (very small but useful) piece of the Linux kernel, I disagree with the assertion that driver maintenance (keeping up with an unstable API) is cheap. I am very annoyed at the steady stream of patches I have to apply to keep up with even the 2.4 kernel. The worst part is when someone sends a patch directly to Linus or Marcelo - bypassing me and the other guys who maintain our kernel subsystem - so that the mainline kernel ends up out of sync with our own development code repository. We spend too much of our limited kernel-development time chasing API mismatches when we could be fixing real bugs or adding features. (fortunately most API-change problems are caught at compile-time, but there was one recent instance where an unexpected kernel change led to a HUGE but silent memory leak in my code)
I would very, very much prefer if the driver API were frozen at least for the "stable" kernel series. I don't really mind what happens in 2.5.x.
I understand and agree with Linus' philosophy that large-scale code breakages are sometimes required to force reluctant stragglers to adapt to a new, improved API. Just don't do this in a "stable" kernel series!
IMHO the world would also be a better place if binary-only driver vendors (read NVIDIA) had to target only one, stable kernel API. But feel free to disagree...
I believe so, but I haven't actually tested it yet... D-VHS simply requires an MPEG-2 Transport Stream, which is a packetized encoding of one or more MPEG-2 Program Streams. I have been very successfully converting MPEG-2 Program Streams from many sources into MPEG-2 Transport Streams. (this step requires Transport Stream multiplexer software, most of which is non-free. But I have been trying to create my own multiplexer...)
We may find this ironic, but the BPDG actually has a documented set of convoluted rules for what capabilities consumer HDTV equipment will be "allowed" to have. E.g. you can have a digital HDTV output - as long as it is scrambled. You can have an analog output - but only if it is down-converted to NTSC resolution... etc etc...
Unfortunately it is not that simple - the encryption key is specific to the stream... In order to get the key you must go through a handshaking process with the transmitting device - during which you must "prove" that you are a licensed decoder (presumably by proving that you know some sort of secret only given to licensed vendors). I'm not too familiar with the details though, and it's entirely possible that someone will crack this scheme just like CSS was cracked. But the simple approach of playing back a scrambled scream verbatim does not work.
That is correct. The JVC D-VHS deck actually supports a range of resolutions - 720x480 (like DVD) and several HD formats up to 1920x1080 ("1080i" HDTV). It is my understanding that D-Theater commercial releases will be encoded at the full 1080i resolution.
It would be insanely cool if the D-VHS deck's MPEG-2 decoder could understand 3:2 pulldown flags, and generate a true 24fps output. With the right projection system you could essentially get the same image quality as a digital cinema movie theater in your own home! (but you'd need to play it at 1080p (60 frames/sec) or 24p (24 frames/sec), which are unfortunately beyond the range of consumer-level HDTV equipment...
AFAIK the current plan for HDTV DVD calls for using MPEG-4 compression to cram an HDTV movie into almost the same space as today's MPEG-2 SD movies.
D-VHS uses the same MPEG-2 codec as DVD, just at about double the bitrate (the D-VHS streams I have seen are encoded at 15-20MBit/sec, versus 7-9MBit/sec for DVD). So there is only a factor of two difference in data rate, which will be made up for by the new MPEG-4 codec and/or higher-capacity DVDs (shorter wavelength lasers).
I haven't gotten the equipment I need (a nice HDTV monitor) to really evaluate the image quality of D-VHS vs DVD. (For those of you lucky enough to receive HDTV via satellite or over the airwaves, D-VHS will look virtually the same).
Some of the currently-available D-VHS decks support FireWire I/O. This allows one to record and play video to the deck with a computer (the streams can be recorded from the deck - e.g. for PVR-style timeshifting of HDTV - or generated and encoded yourself).
Several people at avsforum.com have already gotten this working using MPEG2-over-FireWire support built into Windows XP.
Dan Dennedy and I are working on a Linux driver that will provide the same functionality as Windows XP. (it will appear at linux1394.sourceforge.net; it's not ready for release yet though).
D-VHS is a truly versatile format. The deck I have experience with (JVC) can record and play MPEG-2 streams at a wide variety of bitrates (up to 29MBit/sec) and formats (720x480 NTSC up to 1920x1080 HDTV)... The encoding is standard MPEG-2, so you can make and play your own HDTV content (I've done it already), and you could probably also do things like record a DVD to tape without re-compressing the video.
Note however that Windows XP and my drivers can only handle cleartext MPEG-2 streams (either home-made or recorded from broadcast/satellite HDTV). The new "D-Theater" standard is basically like DVD's CSS; the MPEG-2 streams will come in a scrambled format that is "impossible" to read without a licensed decoder.
You are very right... There is a big difference between "theft" and "infringement" - both are and should be illegal, but their economic consequences are not the same. Consider that if you really, truly, cannot afford to buy a CD, and decide to download and enjoy it, you will have increased the net happiness of society without costing much at all. (whereas if you really, truly cannot afford to buy food to eat, and steal from someone else, then your gain becomes their loss)... It's only when there are too many freeloaders that the underside of infringement appears - less production of art due to diminished financial returns. In my opinion we very rarely reach this point, despite what the content industry claims. (I doubt there are thousands of budding artists out there saying "gee I'd love to make music, but then it would all get ripped off by freeloaders, I think I'll work a desk job instead...")
BTW unless Eminem has a really sweet record deal, he's out much less than $15 when you decide not to but the CD - probably less than $1 ! =)
(yeah recording engineers & marketers have to take a cut, blah blah blah - no way does that justify current CD prices...)