The two aren't necessarily dependent
on
Longhorn in 2006
·
· Score: 1
No doubt Longhorn will target being able to leverage DRM hardware, but should DRM hardware become widely available before 2006, then you can bet there will be an XP service pack that will provide support for it. Also, DRM hadware won't take off big-time unless there is software that can take advantage of it, so I doubt MS will wait for Longhorn to implement it - another reason to do a DRM-enabled XP service pack.
Not from my recent experience
on
Does C# Measure Up?
·
· Score: 4, Insightful
I am in the process of coding a data collection server application in Java which collects data from remote devices that dail up over a phone line. The application must interface with the serial port at a low level, send email, generate XLS files, send faxes, create charts, and, of course, communicate with a DBMS. It also has a significant GUI component as well. Oh yes, this application must be able to run both on Linux and Windows (2000 or XP).
I have been developing on Linux. All in all, to date I've coded around 30,000 lines of code. Because of the high level of portability of the APIs, I had to change all of about a dozen lines of code to get it up and running on Windows. That's one dozen out of 30,000. There's now way you could even come close to that using C or C++, regardless of how cross-platform the library developers say their libraries are.
As far as performance, Java may have been slow three of four years ago, but the last several versions of the JDK and the HotSpot JVM have seen a steady and rapid improvement in performance and stability. SWING, although it has improved, may still be a bit slow, but computational code written in Java is only slightly slower than in C++. Even current versions of SWING, although arbuably slower than native GUIs like GTK+ or QT, are fast enough so as to not be noticable on any machine faster than 800MHz or so.
Most people who say Java is unstable or slow are remembering their experience from the JDK 1.1 days. The current JDK 1.4 bears little resemblance to that in terms of performance and maturity.
Java changing slowly but not Stagnant
on
Java vs .NET
·
· Score: 1
I have been developing Java apps for several years now. For the last year and a half or so, while recent releases of the JDK may not have added a ton of new features, they have been making steady improvements in the quality of what is there. Many, many bugs have been resolved, and performance has improved markedly. The APIs have not been entirely stagnant either. Recent JDKs have seen the introduction of several useful new APIs such as XML object serialization (which I have been using extensively) and several others which I'm less familiar with.
On the other hand, Sun could probably benefit in a PR sense from submitting portions of the system to statndards bodies and by using a more liberal open source license in some cases.
What you say is true, although some of it was originally developed with military uses in mind besides just public good. The problem is that as the commercial software market grew bigger and bigger during the '60s, '70s, and '80s, the government slowly withdrew financial support and left more and more software development in the hands of private companies. What I think the original poster is calling for is a reversal of this trend, which I tend to agree with in many cases.
A really good page which deals partially with the history of this process can be found here.
Here is another good page, also worth a read, which makes a case for government support of open source software.
Actually, VHS won the consumer war not because it was more compatible with anything (there was really nothing to be compatible with, other than Beta, which it obviously wasn't compatible with). It won the war because it was more convenient for consumers - it was more convenient because VHS could record two hours in SP mode (a length long enough to cover most movies), when at the time, Beta could not.
DVD+R/RW has some subtle technical advantages that may turn out to give it a similar edge for consumers, like the ability to directly record variable bitrate MPEG in real time in a mode that is still highly video compatible. It's still a gamble for Phillips et al - nobody really knows whether this will end up being a big consumer advantage, but folks like Dell apparently think so, potentially enough of an advantage to overcome the slight compatibility gap. In addition, that compatibility gap is only going to get narrower (actually, better for both formats), because virtually all players being made now can play anything, and what gap exists is largely solvable with the booktype field
Still, If I were producing DVDs for distribution to many people, and I didn't want to worry about setting booktypes, it makes sense to choose DVD-R/RW at the current time. This may change though in another few years when almost everyone has replaced their really old players and the compatibility gap has narrowed to statistical insignificance.
First point - All DVDs contain a field which identifies to the player the type of media. This field is called the "booktype". There are a handful of players which will refuse to play a disc if it is not tagged with one of the "acceptable" booktypes, even though the player would physically be able to play it. From the various searching around I've done, it appears that from a physical point of view, there should be very few players that can play a -R disc that can't play a +R disc (e.g., they both have very similar reflectivities, etc.).
Most DVD writers have the ability to let you force the writing of a certain booktype field. Many of the players in the test which failed to read +R discs are likely to have done so because their firmware refused to play based on the booktype field. Setting the booktype of a +R disk to DVD-ROM or DVD-R would probably narrow the compatability gap significantly.
An excellent technical discussion of this and other issues appears on this page, near the bottom of the page.
Second point - DVD+R/RW is becoming more popular because, outside of just compatability, there are some other subtle (or not-so-subtle, depending on your application) technical advantages. The biggest one is the ability to do fine resolution (a few bit-times) lossless linking in all recording modes.
Again, the above page has an excellent technical discussion of this near the bottom (section labeled "What does the + in DVD+R/RW stand for").
The bottom line is that due to the way lossless linking is performed in DVD-R in DAO mode (the most video-compatible mode), compatibility is dependent on linking data being "corrected away" by the ECC, whereas in +R/RW, the links are physically so small that a +R sector with a link is logically indistinguishable from a DVD-ROM sector.
The primary importance of all this is that it allows real-time low-bitrate MPEG data, say from a capture card or from the internet (which will inherently cause buffer underruns due to it's low bitrate), to be directly written to DVD with compatability as high as if the data were first all written to a file and then written to DVD at once. Companies like Dell, etc., must feel that this will become a big consumer advantage because of the large amount of disk space and added inconvenience required to first store the MPEG in files and then write them to DVD.
There are also some other subtle techincal advantages which can be seen from the above document.
So, for consumers who want to do things like capture video from their camcorders and copy it to DVD in a simple manner, +R may be the best choice as long as their player is compatable (which it likely is since the compatibility gap isn't that big), whereas for someone who is producing DVDs which are to be distributed to many people with no knowlege of which player they have, -R may be better, although they could always increase compatability of +R by using the booktype field.
They just want their movies to work on Uncle Bob's DVD player, puchased 3 years ago... it ain't gonna work with DVD+RW.
This just plain isn't true. If you browse through sites like dvdrhelp.com, which I did recently, you will find two things: 1) the user reports of compatability vary considerably even within the same DVD player model, and 2) if you average the results (which you must do because there is so much "noise" in them), there is very little difference between the two formats in terms of compatability. If one is better than the other, it is by only a few percentage points at most.
I have played +R disks in many players made during the last 5 years, and have not had any problems. The surface reflectivities of the two types of disk are very similar, and a player which is physically capable of playing a -R will almost always play a +R, at least in my experience. Some players might refuse to play a disk which is tagged as a +R, but there are utilities available which will let you change the so-called "book type" field to get around this problem.
I agree that end users will not have any issue with the two types of DVD-R/RW, but there is one difference that probably will make a difference to some consumers. DVD+R/RW is capable of recording with lossless linking in the mode which is the most compatable with video DVD players (see this page (near the bottom) for a technical description of this issue). What this feature means is that with +R/RW, you can stream variable bitrate MPEG directly to the DVD and have the resulting disk be more compatable with video DVD players than with -R/RW, which wasn't designed with this in mind. My hunch is that this is one of the reasons M$ has decided to put its weight behind +R/RW (along with the Mt. Rainier stuff).
The bottom line is that for all users who don't need to stream MPEG directly to the DVD (which probably includes most Linux users), there is very little practical difference between the formats. Both formats have the support of some heavy hitters and neither one is likely to go away anytime soon.
DVD-R/RW is backed by the DVD Forum, as well as a long list of hardware manufacturers. A few months ago, this would have given this format the edge. Microsoft, however, has recently thrown its weight into the +R/RW camp along with the many hardware manufacturers which were already supporting it. This sort of evens things out.
I assume the reason MS decided to back +R/RW is because of its ability to provide lossless linking in the recording mode that is the most compatable with video DVD players. This feature allows realtime streaming of low bitrate MPEG directly to video-compatable DVD which is something MS probably figures many consumers will want to do.
The fact that both formats have strong backing probably means that we will have to live with both formats for longer than we previously thought unless one camp or the other suddenly backs down, which is unlikely.
As for me, I have a +R/RW, and am so far very happy with it. It is well supported in Linux through the growisofs utility, and I haven't had any problem with compatability of the +R media in video DVD players.
The growisofs webpage mentioned above has a good technical discussion of the lossless linking issue and why this is supposedly an advantage for +R/RW (look near the bottom of the page), although I personally don't do realtime MPEG streaming to DVD.
For me, it's been a bitter-sweet progression over the years.
The first "real" printer I ever bought was an Epson FX-286 wide carriage dot matrix printer, 17 or 18 years ago. The print quality is typical crappy dot matrix, but the printer still works (although I haven't re-inked the ribbon now for several years), and it never missed a dot.
The next printer was an Epson EPL-7000 laser printer, purchased probably around 14 years ago when I needed better graphics capabilities and letter quality printing. The print quality of course was much better (300 dpi), and this printer also still works well and has never had any problems, although it tends to curl paper even more than most laser printers. The toner cartriges are very espensive in comparison to other small lasers, but they also last very long.
Then things started changing. I began buying inkjet printers for their color capability. I first bought an HP Deskjet 855C. This printer worked for about four or five years until it stopped printing properly in color. I still use it as a backup monochrome printer.
Still wanting color, I replaced the HP with an Epson Stylus Color 1520 wide format inkjet printer. By this time the print quality was quite good - 720x1440 and it did a pretty decent job printing photos even though it's only a four color printer. This printer still works; however, I have had constant paper feed problems with it, and the head nozzels clog occasionally if it goes more than three or four weeks without being used. Presumably this is due to the fine geometry print heads.
Wanting better photo quality, I recently purchased an Epson Stylus Photo 1280 about a year ago. This printer still works of course and seems to have fewer paper feed problmes than the 1520, but the head clogging problem is worse. At least a few nozzels clog almost every time that the printer goes unused for more than two weeks. The photographic output quality, however, is exceptional (although perhaps not quite as good as can be had today).
Clearly, the higher volumes and lower prices have brought about a reduction in quality and longevity of printers, but what do you expect - you get what you pay for. The flip side is that the quality of the output, particularly for photographs, is better than it has ever been, and you are paying much less for most newer printers, so they don't owe you much when they die after only a few years.
I'll respond to this posting because it is much more well thought out and a lot less inflammatory than your other reply.
As I mentioned in a reply to another post, the budget constraints we are under are such that unless we go *extremely* inexpensive, we may either end up with nothing, or very much less than we wanted (this particular effort is completely parent-funded).
As I also mentioned in the other post, the tools involved here, although they are less polished than their commercial counterparts, are not actually *that* bad (I probably made it sound worse than it actually is). In some ways, they are even better than some of the other tools mentioned. For example, iMovie would probably be inadequate - we need at least the ability to do multi-track editing and compositing. Final Cut Express provides this capability and would probably work for us, but it still costs $299 (maybe a bit less with discounts), and it doesn't have keyframe controlled effects (which Cinelerra does).
You are right that there are already many technical aspects to making videos and movies, as well as many artistic aspects. The point is that it is not necessary to make CS experts out of everyone to use our paradigm. We're not talking about compiling and installing kernels or setting up firewalls here, we're talking about maybe having to type in a one-liner into a command prompt window to do something that might be a menu item or GUI function in the commercial program. Someone who can master all of the other technical details you mentioned can probably handle this.
It's true that there will be some "real" CS knowledge required to get things all set up, but that will be handled by the hadful of kids involved who actually *are* computer-savvy (there are several).
You can put together a viable suite for about $1500
This is true, but in our particular case, even this it too much. Next year, due to budget constraints, the school will be laying off several teachers and eliminating several courses school wide. This effort to set up a small cinematography lab is being funded entirely from parent donations, so it really has to be extremely inexpensive.
The demo system we put together with the above mentioned OSS software was based on an Athlon 2000+ platform and totaled out around $400 for everything, assuming a 17" monitor. Even at this price, we probably won't be able to afford as many machines as we would like.
Additionally, even though the OSS tools are not yet as polished as their commercial counterparts, they are still quite usable once you get past the initial learning curve, and the amount of technical knowledge shouldn't be overwhelming to the point where it hinders their creative efforts. The GUI-based tools such as Cinelerra and GIMP are not that hard to use, and the common command line operations can be wrapped in simple scripts by the more computer savvy students. These students are at an age where they are capable of picking up new things fairly quickly. A handful of the kids are already technically inclined, and this should help smooth things out for the others.
However, the constraints need to be carefully evaluated against the objectives of the course.
Definitely true, but unfortunately in this case, they also need to be evaluated against the possibility of not getting anything at all, or getting significantly less than we want.
Ever try getting a budget-constrained school to spend $10,000 per seat for video editing tools? Good luck. My 9th grade son is working to set up a video editing media lab at his high school, which is having to lay teachers off next year because of budget shortfalls.
The only way to achieve this in the current economic climate is by going for low-cost solutions. This means using either 1) low cost or free commercial software, which is usually very limiting (e.g., single track, poor effects control, etc.), or 2) using open source software, which tends to be better in capabilities, but more buggy and harder to set up and use.
He's put together a demonstration system using Linux, Cinelerra, Blender, Gimp, Transcode, and mjpegtools. No, it's not all simple point-and-click brain-dead easy, and some of the software, particularly Cinelerra, is still buggy and crashes periodically, but there is a surprising amount of functionality there for a very reasonable cost (like $0.00).
Yes, there will likely be a bigger learning curve than for the $10,000 package, and some technical knowledge will be required to get the good results that are possible from this. In some ways this is a good thing - there is nothing wrong with high schoolers coming away with a little technical knowledge.
Honestly, I don't know how you're going to fix this aspect of the OS without doing what Microsoft has done - compromise fundamental stability and security in favor of useability.
Stability and Security are not really what need to be sacrificed to make Linux more transparent to typical end users, it's diversity and choice that would have to be sacrificed.
What Microsoft has that Linux doesn't have is *control* of the entire structure of the operating system and all its basic components (e.g., printing, fonts, display, etc., etc.). Because of this control, Windows can appear much more consistent at all levels to both software developers and users. This consistencey helps lead to transparency by encouraging most sofware developers to basically do things the same way so that users always (or at least most of the time) know what to expect.
A "Linux OS", on the other hand, consists of a Linux kernel (with each distro putting different features in their kernel) and hundreds of other components and layers that most people normally think of as part of the operating system that come from hundreds of different sources. Some basic things, like good font management across screen, printing, and applications, are either completely missing or only just beginning to get implemented, and they are getting implemented in different ways by different groups of people.
So far, it's been the distro makers' job to try to provide the vertical and horizontal integration that makes all these separate components interoperate smoothly and transparently. The problem is that the components can be so different that getting them to interoperate as smoothly as in Windows (where one company controls everything) is nearly impossible.
Most Linux-oriented people feel that the balance should go in favor of choice and diversity rather than consistency, even if it means less in the way of transparency and clean integration. I tend to agree with this, but I also hope that over time, the projects that produce the myriad of components that make up a Linux system will cooperate at increasingly deeper levels with each other so that we can ultimately have the best of both worlds - choice, diversity, *and* transparency and consistency.
There is a bibliography project underway for Open Office. In fact, one of the early tasks of the project is to develop a detailed list of user requirements, so I'm sure they would welcome input from heavy users of bibliography features.
This presentation contains content that your browser may not be able to show properly. This presentation was optimized for more recent versions of Microsoft Internet Explorer.
Cross platform IDE, Single platform documentation:-(
Unfortunately, applications which are in niche markets will be last to migrate. For applications where the absolute number of users is fairly small, the 2-3% market share of Linux translates to a potential number of users that is too small to support for a traditional commercial software company.
There are exceptions, of course. The Film industry, for example has been opting for Linux, and as a result, a lot of traditionally "nichey" software has been ported to Linux.
This definitely seems to be a troll (and an overactive one the last few days).
If you search Slashdot users for "miguel", several listings come up. The one that appears to be the real Miguel is this one . The ID is 7116. This listing also point to what more likely seems to be Miguel's true home page.
The difference is that CDROM is a format that is ubiquitous in the mass market, and Syquest drives are not and have never been. It may eventually happen, but it will be a much longer time before equipment to read CDs is completely unavailable, even after it is no longer a popular format. Media technology that has become ubiquitous will be readable for a longer time because there will sufficient demand to justify products for a longer period of time.
An example is vinyl LPs. Very few consumers have purchased vinyl LPs for more than 15 years, and yet most major consumer electronics stores sell at least a few models of turntable, and common replacement parts like cartriges and needles are still available. There are so many LPs out there that people will still want to play them and these items will probably still be available for many years to come.
As for 5.25" floppies, I still have several 5.25" floppy drives, and I can still plug a them into the floppy controller of a modern PC motherboard and read the disks, assuming the data is still readable.
The main problem is that even CDROMs cannot be archived forever even if the equipment is there to read them. The real answer is to periodically transfer the media to a format that is current every 10 years or so.
My son and I have been capturing analog video and producing short digital videos and movies for past few months. We have made a goal to do this entirely in Linux and have learned a bit along the way that may be of use to others. My son has recently made some videos for his high school classes that have been voted best in the class. Here's what worked for us:
1. Start with a reasonably recent model PC, such as an Athlon 1700+ or better built on a decent motherboard. Give it at least 512Mb of RAM and make sure you have at least 20Mb or more of free disk space.
2. Use a relatively recent version of Linux with at least a 2.4.18 kernel. Most distributions which use this kernel (e.g., Red Hat 7.3) include drivers which support the capture cards listed below.
3. We've been using two types of PCI capture cards: an Iomega Buz, and a Linux Media Labs LML33. The Buz is out of production, but it can regularly be had on ebay for $20-$40. It is based on the Zoran MJPEG chipset and Phillips video encoder chips. As a side benefit, it also contains an ultra SCSI controller that is supposedly supported in Linux, though I haven't tried it yet. The LML33 was designed spefically with Linux in mind, and is also based on the Zoran MJPEG chipset, but it uses a BrookTree video encoder. It is also a bit more expensive; we paid $125 for a used one on ebay. Both cards are well supported in Linux, and produce high quality DVD-resolution 720x480 video at 30 frames/second.
4. Install a recent version of mjpegtools. The most important piece of mjpegtools is the lavrec utility, which supports recording from the Zoran cards to either AVI or Quicktime formatted MJPEG files. mjpegtools also includes several other useful utilities.
5. Install a recent distribution of Transcode. Transcode is a very useful suite of command line utilities for transcoding and processing videos and supports just about every video codec available on Linux.
6. Install Cinelerra and Blender. Cinelerra is a bit quirky, still tends to crash a lot, and is butt-ugly, but it has some awesome editing and compositing abilities including multiple layer editing and compositing, and keyframe-based effects control. The most recent version also contains a nice adaptive de-interlace filter. Cinelerra also contains a very nice translate filter that can be used to trim edge artifacts that often appear in captured video. Blender is gread for things like generating 3-D titles and short 3-D blurbs and transition animations if you like to do those kinds of things. Gimp is also quite useful for generating titles and editing individual frames if that is required.
With the above combination of hardware and software, you can achive very close to DVD quality results with very little outlay of cash in a completely Linux environment, and the results can be quite satisfying. My son has been making videos for his high school classes and I have been digitizing old home videos and it's been quite fun.
My 9th grade son has been using Cinelerra to put together several cinematography projects for school. It does crash occasionally so you want to make sure you save your layouts periodically, and it uses HUGE amounts of memory when loading in video files (it seems to want to store everything in memory), but it has a pretty decent set of features, including multi-layer editing, numerous effects and transitions, and clustered rendering. It may not be as mature as the best commercial packages, but it's already as good as or better than most of the low-end programs that come with most capture devices. He's been using Blender to do 3D titles and credits and stuff like that.
The combination of Cinelerra + Blender + FilmGimp is pretty decent considering it's all open source. You can do better with commercial software, but not without spending many thousands of dollars.
If this year's TurboTax with its nasty DRM runs in VMWare, then you could create a separate VM for running TurboTax, and when you are done, back up the VM disk file to a CDROM and have a restorable installation of TurboTax that could be run on any machine at a later date (as long as it has VMWare).
I used last year's TurboTax in VMWare with no problem, but I've been holding off this year because of the DRM issue. If the DRM'd version runs in VMWare, this could eliminate some of the concerns.
The internet PC store Mwave has both Mwave and ECS brand notebook computers that are available without an OS. Prices aren't too bad either. The ECS models are a little unconventional, as they don't have internal batteries - they use only external batteries that must be purchased separately.
I've said this numerous times here in the past, but the responsibility for dependency hell rests squarely on the shoulders of the developers.
Most OSS developers have a "purist" attitude when they distribute a binary (assuming they even do), that every last library must be dynamically linked.
Before you flame me, of course I realize that dynamic linking is an important concept, and it was even more important in the days when computers had very limited memory and disk space. But it is also the cause of a lot of dependency hell.
Now, no sane person would suggest statically linking everything. Large, stable libraries like the C library, X, and such should clearly be dynamically linked in most applications. But when an application uses a dozen small bleeding-edge libraries that are no where near current in recent distributions, then statically linking those libraries in binaries can result in much less dependency hell and a lot more users happily trying out your software.
As those libraries eventually become stable, then go back to dynamically linking them. A good rule of thumb would be that if your application won't run on the current release of popular distros (such as RedHat, Mandrake, Suse) because of bleeding-edge library dependencies, then those particular libraries should be statically linked in your binaries until they are stable in current distros.
If the stubborn "purism" of complete dynamic linking could give way to a combined type of linking strategy, dependency hell would largely disappear overnight.
Slashdot Mirror
No doubt Longhorn will target being able to leverage DRM hardware, but should DRM hardware become widely available before 2006, then you can bet there will be an XP service pack that will provide support for it. Also, DRM hadware won't take off big-time unless there is software that can take advantage of it, so I doubt MS will wait for Longhorn to implement it - another reason to do a DRM-enabled XP service pack.
I am in the process of coding a data collection server application in Java which collects data from remote devices that dail up over a phone line. The application must interface with the serial port at a low level, send email, generate XLS files, send faxes, create charts, and, of course, communicate with a DBMS. It also has a significant GUI component as well. Oh yes, this application must be able to run both on Linux and Windows (2000 or XP).
I have been developing on Linux. All in all, to date I've coded around 30,000 lines of code. Because of the high level of portability of the APIs, I had to change all of about a dozen lines of code to get it up and running on Windows. That's one dozen out of 30,000. There's now way you could even come close to that using C or C++, regardless of how cross-platform the library developers say their libraries are.
As far as performance, Java may have been slow three of four years ago, but the last several versions of the JDK and the HotSpot JVM have seen a steady and rapid improvement in performance and stability. SWING, although it has improved, may still be a bit slow, but computational code written in Java is only slightly slower than in C++. Even current versions of SWING, although arbuably slower than native GUIs like GTK+ or QT, are fast enough so as to not be noticable on any machine faster than 800MHz or so.
Most people who say Java is unstable or slow are remembering their experience from the JDK 1.1 days. The current JDK 1.4 bears little resemblance to that in terms of performance and maturity.
I have been developing Java apps for several years now. For the last year and a half or so, while recent releases of the JDK may not have added a ton of new features, they have been making steady improvements in the quality of what is there. Many, many bugs have been resolved, and performance has improved markedly. The APIs have not been entirely stagnant either. Recent JDKs have seen the introduction of several useful new APIs such as XML object serialization (which I have been using extensively) and several others which I'm less familiar with.
On the other hand, Sun could probably benefit in a PR sense from submitting portions of the system to statndards bodies and by using a more liberal open source license in some cases.
What you say is true, although some of it was originally developed with military uses in mind besides just public good. The problem is that as the commercial software market grew bigger and bigger during the '60s, '70s, and '80s, the government slowly withdrew financial support and left more and more software development in the hands of private companies. What I think the original poster is calling for is a reversal of this trend, which I tend to agree with in many cases.
A really good page which deals partially with the history of this process can be found here.
Here is another good page, also worth a read, which makes a case for government support of open source software.
Actually, VHS won the consumer war not because it was more compatible with anything (there was really nothing to be compatible with, other than Beta, which it obviously wasn't compatible with). It won the war because it was more convenient for consumers - it was more convenient because VHS could record two hours in SP mode (a length long enough to cover most movies), when at the time, Beta could not.
DVD+R/RW has some subtle technical advantages that may turn out to give it a similar edge for consumers, like the ability to directly record variable bitrate MPEG in real time in a mode that is still highly video compatible. It's still a gamble for Phillips et al - nobody really knows whether this will end up being a big consumer advantage, but folks like Dell apparently think so, potentially enough of an advantage to overcome the slight compatibility gap. In addition, that compatibility gap is only going to get narrower (actually, better for both formats), because virtually all players being made now can play anything, and what gap exists is largely solvable with the booktype field
Still, If I were producing DVDs for distribution to many people, and I didn't want to worry about setting booktypes, it makes sense to choose DVD-R/RW at the current time. This may change though in another few years when almost everyone has replaced their really old players and the compatibility gap has narrowed to statistical insignificance.
First point - All DVDs contain a field which identifies to the player the type of media. This field is called the "booktype". There are a handful of players which will refuse to play a disc if it is not tagged with one of the "acceptable" booktypes, even though the player would physically be able to play it. From the various searching around I've done, it appears that from a physical point of view, there should be very few players that can play a -R disc that can't play a +R disc (e.g., they both have very similar reflectivities, etc.).
Most DVD writers have the ability to let you force the writing of a certain booktype field. Many of the players in the test which failed to read +R discs are likely to have done so because their firmware refused to play based on the booktype field. Setting the booktype of a +R disk to DVD-ROM or DVD-R would probably narrow the compatability gap significantly.
An excellent technical discussion of this and other issues appears on this page, near the bottom of the page.
Second point - DVD+R/RW is becoming more popular because, outside of just compatability, there are some other subtle (or not-so-subtle, depending on your application) technical advantages. The biggest one is the ability to do fine resolution (a few bit-times) lossless linking in all recording modes.
Again, the above page has an excellent technical discussion of this near the bottom (section labeled "What does the + in DVD+R/RW stand for").
The bottom line is that due to the way lossless linking is performed in DVD-R in DAO mode (the most video-compatible mode), compatibility is dependent on linking data being "corrected away" by the ECC, whereas in +R/RW, the links are physically so small that a +R sector with a link is logically indistinguishable from a DVD-ROM sector.
The primary importance of all this is that it allows real-time low-bitrate MPEG data, say from a capture card or from the internet (which will inherently cause buffer underruns due to it's low bitrate), to be directly written to DVD with compatability as high as if the data were first all written to a file and then written to DVD at once. Companies like Dell, etc., must feel that this will become a big consumer advantage because of the large amount of disk space and added inconvenience required to first store the MPEG in files and then write them to DVD.
There are also some other subtle techincal advantages which can be seen from the above document.
So, for consumers who want to do things like capture video from their camcorders and copy it to DVD in a simple manner, +R may be the best choice as long as their player is compatable (which it likely is since the compatibility gap isn't that big), whereas for someone who is producing DVDs which are to be distributed to many people with no knowlege of which player they have, -R may be better, although they could always increase compatability of +R by using the booktype field.
They just want their movies to work on Uncle Bob's DVD player, puchased 3 years ago... it ain't gonna work with DVD+RW.
This just plain isn't true. If you browse through sites like dvdrhelp.com, which I did recently, you will find two things: 1) the user reports of compatability vary considerably even within the same DVD player model, and 2) if you average the results (which you must do because there is so much "noise" in them), there is very little difference between the two formats in terms of compatability. If one is better than the other, it is by only a few percentage points at most.
I have played +R disks in many players made during the last 5 years, and have not had any problems. The surface reflectivities of the two types of disk are very similar, and a player which is physically capable of playing a -R will almost always play a +R, at least in my experience. Some players might refuse to play a disk which is tagged as a +R, but there are utilities available which will let you change the so-called "book type" field to get around this problem.
I agree that end users will not have any issue with the two types of DVD-R/RW, but there is one difference that probably will make a difference to some consumers. DVD+R/RW is capable of recording with lossless linking in the mode which is the most compatable with video DVD players (see this page (near the bottom) for a technical description of this issue). What this feature means is that with +R/RW, you can stream variable bitrate MPEG directly to the DVD and have the resulting disk be more compatable with video DVD players than with -R/RW, which wasn't designed with this in mind. My hunch is that this is one of the reasons M$ has decided to put its weight behind +R/RW (along with the Mt. Rainier stuff).
The bottom line is that for all users who don't need to stream MPEG directly to the DVD (which probably includes most Linux users), there is very little practical difference between the formats. Both formats have the support of some heavy hitters and neither one is likely to go away anytime soon.
DVD-R/RW is backed by the DVD Forum, as well as a long list of hardware manufacturers. A few months ago, this would have given this format the edge. Microsoft, however, has recently thrown its weight into the +R/RW camp along with the many hardware manufacturers which were already supporting it. This sort of evens things out.
I assume the reason MS decided to back +R/RW is because of its ability to provide lossless linking in the recording mode that is the most compatable with video DVD players. This feature allows realtime streaming of low bitrate MPEG directly to video-compatable DVD which is something MS probably figures many consumers will want to do.
The fact that both formats have strong backing probably means that we will have to live with both formats for longer than we previously thought unless one camp or the other suddenly backs down, which is unlikely.
As for me, I have a +R/RW, and am so far very happy with it. It is well supported in Linux through the growisofs utility, and I haven't had any problem with compatability of the +R media in video DVD players.
The growisofs webpage mentioned above has a good technical discussion of the lossless linking issue and why this is supposedly an advantage for +R/RW (look near the bottom of the page), although I personally don't do realtime MPEG streaming to DVD.
"You are part of the anti-war movement, and traitor!"
For me, it's been a bitter-sweet progression over the years.
The first "real" printer I ever bought was an Epson FX-286 wide carriage dot matrix printer, 17 or 18 years ago. The print quality is typical crappy dot matrix, but the printer still works (although I haven't re-inked the ribbon now for several years), and it never missed a dot.
The next printer was an Epson EPL-7000 laser printer, purchased probably around 14 years ago when I needed better graphics capabilities and letter quality printing. The print quality of course was much better (300 dpi), and this printer also still works well and has never had any problems, although it tends to curl paper even more than most laser printers. The toner cartriges are very espensive in comparison to other small lasers, but they also last very long.
Then things started changing. I began buying inkjet printers for their color capability. I first bought an HP Deskjet 855C. This printer worked for about four or five years until it stopped printing properly in color. I still use it as a backup monochrome printer.
Still wanting color, I replaced the HP with an Epson Stylus Color 1520 wide format inkjet printer. By this time the print quality was quite good - 720x1440 and it did a pretty decent job printing photos even though it's only a four color printer. This printer still works; however, I have had constant paper feed problems with it, and the head nozzels clog occasionally if it goes more than three or four weeks without being used. Presumably this is due to the fine geometry print heads.
Wanting better photo quality, I recently purchased an Epson Stylus Photo 1280 about a year ago. This printer still works of course and seems to have fewer paper feed problmes than the 1520, but the head clogging problem is worse. At least a few nozzels clog almost every time that the printer goes unused for more than two weeks. The photographic output quality, however, is exceptional (although perhaps not quite as good as can be had today).
Clearly, the higher volumes and lower prices have brought about a reduction in quality and longevity of printers, but what do you expect - you get what you pay for. The flip side is that the quality of the output, particularly for photographs, is better than it has ever been, and you are paying much less for most newer printers, so they don't owe you much when they die after only a few years.
I'll respond to this posting because it is much more well thought out and a lot less inflammatory than your other reply.
As I mentioned in a reply to another post, the budget constraints we are under are such that unless we go *extremely* inexpensive, we may either end up with nothing, or very much less than we wanted (this particular effort is completely parent-funded).
As I also mentioned in the other post, the tools involved here, although they are less polished than their commercial counterparts, are not actually *that* bad (I probably made it sound worse than it actually is). In some ways, they are even better than some of the other tools mentioned. For example, iMovie would probably be inadequate - we need at least the ability to do multi-track editing and compositing. Final Cut Express provides this capability and would probably work for us, but it still costs $299 (maybe a bit less with discounts), and it doesn't have keyframe controlled effects (which Cinelerra does).
You are right that there are already many technical aspects to making videos and movies, as well as many artistic aspects. The point is that it is not necessary to make CS experts out of everyone to use our paradigm. We're not talking about compiling and installing kernels or setting up firewalls here, we're talking about maybe having to type in a one-liner into a command prompt window to do something that might be a menu item or GUI function in the commercial program. Someone who can master all of the other technical details you mentioned can probably handle this.
It's true that there will be some "real" CS knowledge required to get things all set up, but that will be handled by the hadful of kids involved who actually *are* computer-savvy (there are several).
You can put together a viable suite for about $1500
This is true, but in our particular case, even this it too much. Next year, due to budget constraints, the school will be laying off several teachers and eliminating several courses school wide. This effort to set up a small cinematography lab is being funded entirely from parent donations, so it really has to be extremely inexpensive.
The demo system we put together with the above mentioned OSS software was based on an Athlon 2000+ platform and totaled out around $400 for everything, assuming a 17" monitor. Even at this price, we probably won't be able to afford as many machines as we would like.
Additionally, even though the OSS tools are not yet as polished as their commercial counterparts, they are still quite usable once you get past the initial learning curve, and the amount of technical knowledge shouldn't be overwhelming to the point where it hinders their creative efforts. The GUI-based tools such as Cinelerra and GIMP are not that hard to use, and the common command line operations can be wrapped in simple scripts by the more computer savvy students. These students are at an age where they are capable of picking up new things fairly quickly. A handful of the kids are already technically inclined, and this should help smooth things out for the others.
However, the constraints need to be carefully evaluated against the objectives of the course.
Definitely true, but unfortunately in this case, they also need to be evaluated against the possibility of not getting anything at all, or getting significantly less than we want.
Ever try getting a budget-constrained school to spend $10,000 per seat for video editing tools? Good luck. My 9th grade son is working to set up a video editing media lab at his high school, which is having to lay teachers off next year because of budget shortfalls.
The only way to achieve this in the current economic climate is by going for low-cost solutions. This means using either 1) low cost or free commercial software, which is usually very limiting (e.g., single track, poor effects control, etc.), or 2) using open source software, which tends to be better in capabilities, but more buggy and harder to set up and use.
He's put together a demonstration system using Linux, Cinelerra, Blender, Gimp, Transcode, and mjpegtools. No, it's not all simple point-and-click brain-dead easy, and some of the software, particularly Cinelerra, is still buggy and crashes periodically, but there is a surprising amount of functionality there for a very reasonable cost (like $0.00).
Yes, there will likely be a bigger learning curve than for the $10,000 package, and some technical knowledge will be required to get the good results that are possible from this. In some ways this is a good thing - there is nothing wrong with high schoolers coming away with a little technical knowledge.
Honestly, I don't know how you're going to fix this aspect of the OS without doing what Microsoft has done - compromise fundamental stability and security in favor of useability.
Stability and Security are not really what need to be sacrificed to make Linux more transparent to typical end users, it's diversity and choice that would have to be sacrificed.
What Microsoft has that Linux doesn't have is *control* of the entire structure of the operating system and all its basic components (e.g., printing, fonts, display, etc., etc.). Because of this control, Windows can appear much more consistent at all levels to both software developers and users. This consistencey helps lead to transparency by encouraging most sofware developers to basically do things the same way so that users always (or at least most of the time) know what to expect.
A "Linux OS", on the other hand, consists of a Linux kernel (with each distro putting different features in their kernel) and hundreds of other components and layers that most people normally think of as part of the operating system that come from hundreds of different sources. Some basic things, like good font management across screen, printing, and applications, are either completely missing or only just beginning to get implemented, and they are getting implemented in different ways by different groups of people.
So far, it's been the distro makers' job to try to provide the vertical and horizontal integration that makes all these separate components interoperate smoothly and transparently. The problem is that the components can be so different that getting them to interoperate as smoothly as in Windows (where one company controls everything) is nearly impossible.
Most Linux-oriented people feel that the balance should go in favor of choice and diversity rather than consistency, even if it means less in the way of transparency and clean integration. I tend to agree with this, but I also hope that over time, the projects that produce the myriad of components that make up a Linux system will cooperate at increasingly deeper levels with each other so that we can ultimately have the best of both worlds - choice, diversity, *and* transparency and consistency.
There is a bibliography project underway for Open Office. In fact, one of the early tasks of the project is to develop a detailed list of user requirements, so I'm sure they would welcome input from heavy users of bibliography features.
...version 1.3 on Linux, which quite up-to-date. If there is any laziness, it is on the part of those who speak before checking the facts.
Here is the result:
:-(
This presentation contains content that your browser may not be able to show properly. This presentation was optimized for more recent versions of Microsoft Internet Explorer.
Cross platform IDE, Single platform documentation
Unfortunately, applications which are in niche markets will be last to migrate. For applications where the absolute number of users is fairly small, the 2-3% market share of Linux translates to a potential number of users that is too small to support for a traditional commercial software company.
There are exceptions, of course. The Film industry, for example has been opting for Linux, and as a result, a lot of traditionally "nichey" software has been ported to Linux.
This definitely seems to be a troll (and an overactive one the last few days).
If you search Slashdot users for "miguel", several listings come up. The one that appears to be the real Miguel is this one . The ID is 7116. This listing also point to what more likely seems to be Miguel's true home page.
The difference is that CDROM is a format that is ubiquitous in the mass market, and Syquest drives are not and have never been. It may eventually happen, but it will be a much longer time before equipment to read CDs is completely unavailable, even after it is no longer a popular format. Media technology that has become ubiquitous will be readable for a longer time because there will sufficient demand to justify products for a longer period of time.
An example is vinyl LPs. Very few consumers have purchased vinyl LPs for more than 15 years, and yet most major consumer electronics stores sell at least a few models of turntable, and common replacement parts like cartriges and needles are still available. There are so many LPs out there that people will still want to play them and these items will probably still be available for many years to come.
As for 5.25" floppies, I still have several 5.25" floppy drives, and I can still plug a them into the floppy controller of a modern PC motherboard and read the disks, assuming the data is still readable.
The main problem is that even CDROMs cannot be archived forever even if the equipment is there to read them. The real answer is to periodically transfer the media to a format that is current every 10 years or so.
My son and I have been capturing analog video and producing short digital videos and movies for past few months. We have made a goal to do this entirely in Linux and have learned a bit along the way that may be of use to others. My son has recently made some videos for his high school classes that have been voted best in the class. Here's what worked for us:
1. Start with a reasonably recent model PC, such as an Athlon 1700+ or better built on a decent motherboard. Give it at least 512Mb of RAM and make sure you have at least 20Mb or more of free disk space.
2. Use a relatively recent version of Linux with at least a 2.4.18 kernel. Most distributions which use this kernel (e.g., Red Hat 7.3) include drivers which support the capture cards listed below.
3. We've been using two types of PCI capture cards: an Iomega Buz, and a Linux Media Labs LML33. The Buz is out of production, but it can regularly be had on ebay for $20-$40. It is based on the Zoran MJPEG chipset and Phillips video encoder chips. As a side benefit, it also contains an ultra SCSI controller that is supposedly supported in Linux, though I haven't tried it yet. The LML33 was designed spefically with Linux in mind, and is also based on the Zoran MJPEG chipset, but it uses a BrookTree video encoder. It is also a bit more expensive; we paid $125 for a used one on ebay. Both cards are well supported in Linux, and produce high quality DVD-resolution 720x480 video at 30 frames/second.
4. Install a recent version of mjpegtools. The most important piece of mjpegtools is the lavrec utility, which supports recording from the Zoran cards to either AVI or Quicktime formatted MJPEG files. mjpegtools also includes several other useful utilities.
5. Install a recent distribution of Transcode. Transcode is a very useful suite of command line utilities for transcoding and processing videos and supports just about every video codec available on Linux.
6. Install Cinelerra and Blender. Cinelerra is a bit quirky, still tends to crash a lot, and is butt-ugly, but it has some awesome editing and compositing abilities including multiple layer editing and compositing, and keyframe-based effects control. The most recent version also contains a nice adaptive de-interlace filter. Cinelerra also contains a very nice translate filter that can be used to trim edge artifacts that often appear in captured video. Blender is gread for things like generating 3-D titles and short 3-D blurbs and transition animations if you like to do those kinds of things. Gimp is also quite useful for generating titles and editing individual frames if that is required.
With the above combination of hardware and software, you can achive very close to DVD quality results with very little outlay of cash in a completely Linux environment, and the results can be quite satisfying. My son has been making videos for his high school classes and I have been digitizing old home videos and it's been quite fun.
My 9th grade son has been using Cinelerra to put together several cinematography projects for school. It does crash occasionally so you want to make sure you save your layouts periodically, and it uses HUGE amounts of memory when loading in video files (it seems to want to store everything in memory), but it has a pretty decent set of features, including multi-layer editing, numerous effects and transitions, and clustered rendering. It may not be as mature as the best commercial packages, but it's already as good as or better than most of the low-end programs that come with most capture devices. He's been using Blender to do 3D titles and credits and stuff like that.
The combination of Cinelerra + Blender + FilmGimp is pretty decent considering it's all open source. You can do better with commercial software, but not without spending many thousands of dollars.
If this year's TurboTax with its nasty DRM runs in VMWare, then you could create a separate VM for running TurboTax, and when you are done, back up the VM disk file to a CDROM and have a restorable installation of TurboTax that could be run on any machine at a later date (as long as it has VMWare).
I used last year's TurboTax in VMWare with no problem, but I've been holding off this year because of the DRM issue. If the DRM'd version runs in VMWare, this could eliminate some of the concerns.
The internet PC store Mwave has both Mwave and ECS brand notebook computers that are available without an OS. Prices aren't too bad either. The ECS models are a little unconventional, as they don't have internal batteries - they use only external batteries that must be purchased separately.
I've said this numerous times here in the past, but the responsibility for dependency hell rests squarely on the shoulders of the developers.
Most OSS developers have a "purist" attitude when they distribute a binary (assuming they even do), that every last library must be dynamically linked.
Before you flame me, of course I realize that dynamic linking is an important concept, and it was even more important in the days when computers had very limited memory and disk space. But it is also the cause of a lot of dependency hell.
Now, no sane person would suggest statically linking everything. Large, stable libraries like the C library, X, and such should clearly be dynamically linked in most applications. But when an application uses a dozen small bleeding-edge libraries that are no where near current in recent distributions, then statically linking those libraries in binaries can result in much less dependency hell and a lot more users happily trying out your software.
As those libraries eventually become stable, then go back to dynamically linking them. A good rule of thumb would be that if your application won't run on the current release of popular distros (such as RedHat, Mandrake, Suse) because of bleeding-edge library dependencies, then those particular libraries should be statically linked in your binaries until they are stable in current distros.
If the stubborn "purism" of complete dynamic linking could give way to a combined type of linking strategy, dependency hell would largely disappear overnight.