thing with biodiesel is the whole food vs. energy... are we really going to grow crops to power vehicles when so many people starve?
We've had this conversation before. The idea that there's a world food shortage is a misconception. In fact, there's a fairly significant annual food surplus. Some of the surplus food is stockpiled, while some is just lost.
People starve because there is a local food shortage where they live. We could get our (where "our" refers to anybody who lives where there's a food surplus, like here in the US) surplus food to them if only it weren't for the excessive cost of fuel.
Full circle.
Re:it isnt an apple product...
on
CaptyTV for Mac
·
· Score: 2
hell, theres no tuner...
No? The Fish says:
When it can connect the antenna to the CaptycTv, choosing the area of the house from pre-setting where the channel of entire country is registered, when the tuner it will set (you use the receiver and the like, it can connect to the video input terminal).
While this is naturally a lousy translation, it sounds to me like there's a tuner in the box. Also, according to the translated web page, you tell the software what to record by choosing from a program schedule downloaded over the Internet. That implies that the box has an inboard tuner.
Re:I hope you mean firewire
on
CaptyTV for Mac
·
· Score: 3, Informative
USB doesn't have nearly enough bandwith for video
USB's 12 Mbps is plenty fast enough for compressed video, a la Tivo. Video compressed at 2 or 4 Mbps is acceptable for a PVR. At 8 Mbps, it's almost indistinguishable from uncompressed video to the untrained eye.
FilmAVID costs (since I last checked) $32k. Thirty. Two. Thousand. Dollars. American.
Hmm. Given that you can't even get a Media Composer for less than about $30,000, stripped, I'd say you're way off here. The Film Composer starting price is around $70,000, not counting storage.
your monitors (not cheapass NTSC teevees, we're talking real-live production monitors, they run about $500 each, and you need at least one)
Again I must say hmm. Maybe you're talking about a used 14" PVM or something. A decent BVM will cost you at least ten times that figure. More if you get the SDI input option.
All in all, to edit film on an AVID system, you're looking at about $65k for a "good" system.
No, all in all, to edit film on an Avid, you're looking at a base, entry, can't-do-it-for-less price of $70,000 or so. A "good" system will run you around $200,000.
Here's the thing about the film business. Most of the editing and compositing work in Hollywood is done on a flat-rate contact. In other words, one house says, "Cut your film at my post house for $50,000," and another says, "Cut it at mine for $40,000." The second house wins.
The second house was able to under-bid the first one because they bought twenty G4s with FCP to do their off-lining, instead of 20 Avid Media Composers. The G4s cost about $8,000 apiece, while a Media Composer goes for somewhere around $100,000. So the second house kept their expenses down, under-bid the job, and got the work.
For film editing, yeah, quality costs. But quality only matters when you go to do the final edit. The vast majority of the work is done in the offline, and if you can cut costs there, you're doing it right.
Basically you don't know what you're talking about.
I don't think so. Most of the consumer 3D apps I'm familiar with (games and whatnot) have a free-running internal clock. If they can run hard-real-time off the vertical refresh, then that's cool and all. But it's news to me.
...refresh rates with framerates above the refresh rate of the monitor.
Strangely, most people don't seem to realize that this is a BAD THING, unless your app is running at an integer multiple of your monitor refresh rate.
To make it simple, imagine your monitor scans at 60 Hz. So every 60th of a second (16.67 msec) you get a whole new frame drawn on the screen. Assume, for sake of argument, that drawing the screen takes zero time. It's just instantaneous.
To achieve smooth motion, the same amount of time must pass between each frame. This is guaranteed if your application renders 60 frames per second. Unless you drop a frame somewhere, you'll see one rendered frame for every screen refresh, and you'll perceive smooth motion.
But what if you drive your screen at 60 Hz, but your application renders 95 frames per second. (Assume that it's exactly 95 fps all the time, rather than a variable frame rate, just to make the math work out for this example.)
When you run your game or whatever, the clock starts at zero. The first frame from the graphics pipeline is in the display buffer, so when the monitor gets ready to draw the screen, it draws frame zero.
10.53 msec later, the application has drawn the second frame, so it swaps buffers. The display buffer now has frame 1 in it. The application now starts drawing frame 2.
But the graphics card isn't ready to draw frame 1 on the monitor until a little over 6 msec later, at t = 16.67. At that time, though, the application hasn't finished drawing frame 2 yet, so frame 1 is still in the display buffer. The monitor draws frame 1. Game frame 1 comes after game frame 0, so we're still in sync.
During this time, the application has been working on frame 2. It finishes frame 2 at t = 21.05 msec and swaps buffers. Frame 2 is now in the display buffer, and the application starts drawing on frame 3.
The monitor is ready to draw frame 2 at t = 33.33 msec. So it reaches for the frame from the display buffer... but what's this? The frame in the display buffer isn't frame 2. It's frame 3! We dropped a frame somehow!
In the meantime, at t = 31.58 msec, the application had finished drawing frame 3. It swapped buffers again, before the graphics card got a chance to display frame 2. Frame 2 disappeared from the display buffer, never having been shown on the monitor. That's a dropped frame, and it's a bad thing.
Games aren't hard-real-time applications, of course. They run freely, sometimes drawing frames more quickly, and sometimes less quickly, depending on the load. This is okay. But don't just assume that because your game runs consistently at a rate higher than your monitor, you won't be dropping frames. In fact, you'll drop frames like crazy, at a rate determined by how far your game frame rate is from your monitor rate, in modulo arithmetic.
Well, then, again we're back to the irrelevance of extreme examples. Okay, that was an example of a terrible licensing scheme. But since it's not representative, it's fundamentally meaningless.
However, with proprietry software, the tendency is to make the licenses as complicated as possible, so as to make it hard for one's competitors.
Speaking as someone who manages the development and deployment of proprietary software, I don't think you're quite right about that. Our end-user license is a page long, with pretty small type. It's complex, but not absurdly so.
We've (actually, our lawyers) have made it as complicated as it needs to be to define our relationship with our customers, while keeping it as simple as possible. If it's too complex, it'll be ambiguous or obtuse, and it won't hold up legally.
We're not thinking about our competitors. We're thinking about ourselves and our customers.
Touche, but things were different then. If the environment were the same-- computers used mostly in academic institutions and mostly by enthusiasts-- then the model would work. Except it isn't.
Grandmothers use laptops now. My boss thinks himself an expert because he knows how to use Windows 98 Internet Connection Sharing. The world is a different place.
Applying the free software model to a big environment like this one sounds... improbable in the extreme.
Yeah, Vim is fine. GCC is a decent compiler, although in a lot of cases a different compiler produces better results. (If your goal is to use the same compiler on different architectures, though, GCC is for you.)
KDE and Gnome are not as good as the classic Mac OS UI, the Mac OS X UI, or the Windows 9x/NT4/2000/XP UI. This is my opinion, but I believe it's an educated one, and I think many people agree with me. KDE and Gnome are usually acceptable user interfaces, but they're not as good as their commercial competition. Sometimes they're very not-as-good.
Mozilla is inferior to Internet Explorer on Windows in terms of speed and simplicity. On other platforms, though, Mozilla is as good or better than competing browsers. I think this says more about the sorry state of browsers other than IE for Windows than it does about Mozilla.
Open Office? Terrible. I'd rather use MS Office, AppleWorks, or WordPerfect.
Apache (which you didn't mention, but maybe should have) is the best web server available. Sort of the exception that proves the rule, I think.
That was certainly an interesting example, but I don't think it's a very useful one in context of this discussion. The fact that there are bad-- read "needlessly complex"-- license models out there doesn't necessarily mean that licenses are, prima facie, bad.
I think, in most circumstances, software licensing works fine. You sort of chose the worst possible example of obtuse licensing to make a point, and I don't think that's helpful in the big sense.
It would be easy to dismiss this comment as hippy-dippy-there-he-goes-again. But consider what we are seeing now, with attempts to control people and programmers via the DMCA and similar ilk. Isn't he RIGHT?
"Marge, I agree with you in theory. In theory, communism works. In theory."
While some of the ideas behind the free software movement may be based in valid principles, as long as software is fundamentally an economy, free software (in either sense of the term) will be marginalized.
RMS is talking about taking software-- writing it, obtaining it, and using it-- out of the economic model and putting it into something different. A new kind of model that has never been done before.
And whenever anybody talks about an entirely new model for a system-- one that has never been tried before-- I'm skeptical.
Um... okay. I suppose this may be true if you're using the right ORB. But in general it sounds like you're confusing dynamic linking with remote procedure calls. I say this because you use the words "CORBA" and "DLL," apparently, to refer to the same thing. They don't.
It's an issue of address space. If I dlopen() a library and dlsym() a symbol, I can then call the function associated with that symbol and have that function run inside the calling program's address space, using the program code from the DSO I opened. It is, for all purposes, as if that code had been compiled into my program from the beginning. I can do things like pass it pointers and get pointers in return, because we're all running in one big happy address space.
Generally speaking, though, calls over CORBA interfaces (I won't speak about COM because I neither know about, nor are particularly interested in, it) cause code to be executed in another address space. Even if the other program is started at first reference, there's still another program out there, with a separate address space. Calling it requires a context switch, and it also (and more importantly) requires that you serialize and send any relevant data from caller to callee, and back again. If you're a program like Photoshop, and the plugin is going to operate on the image in memory, a requirement that you must pass the whole image to the plug-in process would be pretty dumb.
While it may be possible to use an ORB to broker calls to and from DSOs linked into your application at compile time, I'm not aware of any method for using the ORB to link in objects at run time. Of course there may be one, but I'm not aware of it.
Generally, I'm coming down on the side that says CORBA (and possibly COM, if it's fundamentally similar to CORBA) is great and cool, but utterly and completely inappropriate for writing plug-ins, in the traditional sense.
Well, assuming that you absolutely must design a plugin system, lookin into some runtime aggregation systems (COM or CORBA depending on your platform and needs). That's basically with these techologies are for.
Hmm... I don't think I agree.
When I think "plugin," I think of an application loading and executing some code from a DSO or whatever at run-time.
When I think "CORBA," I think of two running applications communicating with each other at run-time.
They're fundamentally different things. If you were to design your plug-in architecture using CORBA, you'd have to have your programmers build little applications that would have to be started and to run alongside your main app, just so your main app could make remote calls to them. Seems kinda silly to me.
Re:If only it were true...
on
OS X for Intel
·
· Score: 5, Informative
3. Allow other vendors to sell compatible hardware, maintain standards similar to the PC-99 standard. Get money off the OS licensing.
Yes, we all saw how well that worked back in 1995-1997.
Like it or not, approve of it or not, right now Apple is a hardware company. Their software-- great though it is-- exists to drive sales of their computers.
I think there's a strong argument to be made right now that Apple's sales aren't being hurt by the differences between the Mac hardware and PC hardware. The G4 Cube was the only Mac in recent years that didn't sell faster than they could make 'em, and Apple dropped it faster than a... fast... dropping thing.
Apple keeps prices high through three basic values: quality, coolness, and scarcity. People buy Macs because they're great computers, or because they or their software are cool, and that's where your demand comes from. Scarcity keeps the prices high.
If Apple were to change their strategy to a software-only model, they would be sacrificing two-and-a-half of those three things. That'd be bad all around.
As I seem to recall, the majority of final formats in the digital realm are in MPEG-2, as that is what the current mastering/delivery solution is.
Yes... but you hit the nail on the head when you said "final format." Although some outlets choose to encode manually before broadcasting, most outlets encode right before the signal go to the transmitter as part of an unattended real-time process. For all intents and purposes, the transmitter or uplink or distribution-system-you-like takes uncompressed SDI or HD-SDI as its input.
Digital Betacam and DVD both use MPEG-2
Bzzt. Digital Betacam (HDCAM too, for that matter) uses a proprietary DCT-based compression algorithm that usually results in around 2:1 compression for SD, 10:1 for HD. D-5 is purely uncompressed, and a lot of post houses use D-5 instead of D-Beta. In the HD world, the D-6 is purely uncompressed. It's a monster VTR, though.
With HDTV coming up in the future, how are editors/equipment suppose to deal with uncompressed data streams of frames larger than current NTSC/PAL frame sizes? Even with fast enough computers, achieving those disk writing speeds to capture the video realtime to a system uncompressed would literally flood almost any physical storage bus solution.
Oh, you'd be surprised. First of all, we've been doing HD nonlinear for over three years now, using Fire on an Onyx2. It's getting to the point where you can do some HD work on a PC or Mac, although no editor who's ever worked on a Fire will ever go back to the desktop. You get spoiled by all the real-time stuff.
Handling the basic data I/O isn't hard. Say you work in 8-bit YUV, 4:2:2. You can pack an entire pixel into two bytes (eight bits for luminance, and four bits each for the two color samples). That's 4,147,200 bytes per frame at 1920x1080 (make it simple; don't count the vertical interval). At thirty frames per second, that's about 120 MB per second. Two fibre channel loops (or one 2 Gb loop) with about eight disks can accomplish that. HDTV at 1080 lines isn't delivered as frames, of course, but as fields. This has no relevance on the storage of data on the disk, because the math works out the same either way.
RGB is more complex, though. Discreet uses RGB internally because all the SGI media libraries deal with it best. So you need three bytes for each pixel, making your data rate one-third more. That's a bit over 180 MB/s, which is still easily doable with commodity hardware.
(The software is tricker. I leave constructing a filesystem that is capable of real-time random-access playback and recording of multi-resolution data to be an exercise for the reader. It's much, much harder than you think. You can get around it, though, by buffering like crazy and using lots of disks.)
But, of course, if you're editing you have to be able to play back two streams of video at the same time. (Think real-time dissolve.) Double that. For RGB, that's about 360 MB/s of raw disk bandwidth required. Even with overhead, that's still within what one 64-bit, 66 MHz PCI bus can do.
Of course, once you get that data onto your disks, you still have to be able to read it and pump it to the video card in real time. If you wanna do anything to it on the way-- like apply a color correction, for instance-- you have to pass it through the CPU. It's easier to do that sort of thing on an SGI than on a PC, because the graphics hardware on an SGI can do lots of stuff in real time without having to bog down the CPUs.
Long story short, you can do HD on a PC or a Mac. If you've never done any high-end work, it's pretty amazing. On the other hand, if you have worked on a Fire or such, HDTV on the desktop sucks.
(Disclaimer: I don't work for Discreet, though this post may sound like I do. Consider me an experienced observer.)
You're not horribly out of date. Flame still runs on Octane, albeit with next-gen graphics now instead of the MXI/MXE that you worked with. We use FC disks instead of SCSI, which means fewer channels. Discreet is finally getting rid of their Stream audio subsystem-- which was left over from the Onyx days, when there was no other digital audio in the computer-- and replacing it with optical audio input and output through a break-out box that has analog and AES spigots. (I don't remember if Flame did audio in '99, but it has now for quite some time.) But besides these things, the hardware and software haven't changed much.
But the PC world has caught up, somewhat. The 64-bit, 66 MHz PCI bus offers something like 500 MB/s of bandwidth, which is plenty fast for standard definition, and acceptable for high definition. PC processors have gotten fast enough to be able to run mediocre, untuned code at acceptable speeds. And Discreet is using some mildly exotic hardware coprocessor stuff for their new product, if my sources are to be believed. Kind of like Avid's hardware DVE component, except inside the computer on a PCI card. Not sure of the details.
The point, though, is that PCs are catching up through brute force. For example, Discreet's apps depend quite a bit on the digital media libraries bundled with IRIX, the SGI OS. These libraries, particularly ImageVision and dmedia, are largely composed of handwritten assembler code. They were tuned to the nines years ago, and have remained mostly untouched since the mid 90s. This allowed those old, slow (relatively) SGI machines to do amazing things in real time.
Microsoft's media libraries have never been very good by comparison. But CPUs are getting to the point where they're sufficiently fast to get the job done at a much lower efficiency.
Plus which, look at it from a business perspective. There's just not that much more work that can be done to Smoke or Fire, Flame or Inferno. The improvements that are happening now are either fairly marginal-- like the color warper-- or kind of half-assed-- like bolting various shared storage technologies atop Stone+Wire. If Discreet builds a sufficiently advanced system, maybe not revolutionary but good enough to convince their customers to buy it, then they're in a really good business position.
Which is easier to develop for, Windows, SGI, or Linux? Which is easier to find programmers for? If you were going to start from scratch on a whole new app, and you didn't require one particular OS or class of hardware for any good reason, which platform would be your first choice?
Yup. We can talk about superiority all day long, but the bottom line is that it's faster and easier to develop and deploy major apps on Windows. Assuming, of course, that your app doesn't do anything Microsoft might be interested in integrating into the OS.
You might be surprised. One of the big video effects/editing companies is Discreet; they're not as big as Avid, of course, but they're second in popularity, I think. They sell Smoke and Fire (editing) and Flame and Inferno (effects), among other things.
Those apps run on SGI workstations, either Octanes or Onyx 2/Onyx 3000s. The app is full-screen, and highly modal rather than windowed. No windows or menu bars or palettes or anything. It's a very different interface, and not intuitive at all, but once you learn you way around it's incredibly fast. I've watched experienced Smoke editors fly though the app faster than I could follow. Amazing.
If Discreet were to port those apps over to Linux, I don't think any of the artists would notice or care. The underlying OS is invisible-- and irrelevant-- at that point.
Of course, Discreet's next-generation product is going to be based on Windows XP. So it's kind of a moot point.
Most television shows and minor Hollywood production companies still use Video Toaster for the few things you still can't do in Adobe Premier and After Effects.
Actually, most television shows (in my experience) are still cut in linear*. Those that are cut in nonlinear are done with Avids; the crappy stuff comes out of a Media Composer or a Symphony, while the relatively big-budget shows are sometimes cut on a DS. The really big-ticket shows are finished on a Smoke. Most of the HD stuff, to my knowledge, is done in Smoke.
Video Toaster is just an also-ran.
Right now, Final Cut Pro is also an also-ran, but lots of houses seem to be replacing Media Composers with FCP for off-lining.
*Linear editing, in with video tape machines. Opposed to nonlinear editing, like with computers.
Slashdot Mirror
Also the cover for Hyperion is inaccurate anyways - the Shrike has four arms. Why even bother to put it on the cover with only two?
Keep reading. My paperback copy of The Rise of Endymion, the fourth and last book in the series, features a four-armed Shrike on the cover.
Not only does it get points for cover accuracy, but it also has the most wrenching and satisfying ending of any book I've read recently.
I think Endymion was the most entertaining of the four, but the last one gets serious credit for being so... right.
This looks like the opensource motto `release early, release often'.
Actually, it's more like a real-world application of the common programming aphorism: don't optimize too early.
thing with biodiesel is the whole food vs. energy... are we really going to grow crops to power vehicles when so many people starve?
We've had this conversation before. The idea that there's a world food shortage is a misconception. In fact, there's a fairly significant annual food surplus. Some of the surplus food is stockpiled, while some is just lost.
People starve because there is a local food shortage where they live. We could get our (where "our" refers to anybody who lives where there's a food surplus, like here in the US) surplus food to them if only it weren't for the excessive cost of fuel.
Full circle.
hell, theres no tuner...
No? The Fish says:
When it can connect the antenna to the CaptycTv, choosing the area of the house from pre-setting where the channel of entire country is registered, when the tuner it will set (you use the receiver and the like, it can connect to the video input terminal).
While this is naturally a lousy translation, it sounds to me like there's a tuner in the box. Also, according to the translated web page, you tell the software what to record by choosing from a program schedule downloaded over the Internet. That implies that the box has an inboard tuner.
USB doesn't have nearly enough bandwith for video
USB's 12 Mbps is plenty fast enough for compressed video, a la Tivo. Video compressed at 2 or 4 Mbps is acceptable for a PVR. At 8 Mbps, it's almost indistinguishable from uncompressed video to the untrained eye.
FilmAVID costs (since I last checked) $32k. Thirty. Two. Thousand. Dollars. American.
Hmm. Given that you can't even get a Media Composer for less than about $30,000, stripped, I'd say you're way off here. The Film Composer starting price is around $70,000, not counting storage.
your monitors (not cheapass NTSC teevees, we're talking real-live production monitors, they run about $500 each, and you need at least one)
Again I must say hmm. Maybe you're talking about a used 14" PVM or something. A decent BVM will cost you at least ten times that figure. More if you get the SDI input option.
All in all, to edit film on an AVID system, you're looking at about $65k for a "good" system.
No, all in all, to edit film on an Avid, you're looking at a base, entry, can't-do-it-for-less price of $70,000 or so. A "good" system will run you around $200,000.
Just thought I'd clarify that a bit.
Here's the thing about the film business. Most of the editing and compositing work in Hollywood is done on a flat-rate contact. In other words, one house says, "Cut your film at my post house for $50,000," and another says, "Cut it at mine for $40,000." The second house wins.
The second house was able to under-bid the first one because they bought twenty G4s with FCP to do their off-lining, instead of 20 Avid Media Composers. The G4s cost about $8,000 apiece, while a Media Composer goes for somewhere around $100,000. So the second house kept their expenses down, under-bid the job, and got the work.
For film editing, yeah, quality costs. But quality only matters when you go to do the final edit. The vast majority of the work is done in the offline, and if you can cut costs there, you're doing it right.
Basically you don't know what you're talking about.
I don't think so. Most of the consumer 3D apps I'm familiar with (games and whatnot) have a free-running internal clock. If they can run hard-real-time off the vertical refresh, then that's cool and all. But it's news to me.
...refresh rates with framerates above the refresh rate of the monitor.
Strangely, most people don't seem to realize that this is a BAD THING, unless your app is running at an integer multiple of your monitor refresh rate.
To make it simple, imagine your monitor scans at 60 Hz. So every 60th of a second (16.67 msec) you get a whole new frame drawn on the screen. Assume, for sake of argument, that drawing the screen takes zero time. It's just instantaneous.
To achieve smooth motion, the same amount of time must pass between each frame. This is guaranteed if your application renders 60 frames per second. Unless you drop a frame somewhere, you'll see one rendered frame for every screen refresh, and you'll perceive smooth motion.
But what if you drive your screen at 60 Hz, but your application renders 95 frames per second. (Assume that it's exactly 95 fps all the time, rather than a variable frame rate, just to make the math work out for this example.)
When you run your game or whatever, the clock starts at zero. The first frame from the graphics pipeline is in the display buffer, so when the monitor gets ready to draw the screen, it draws frame zero.
10.53 msec later, the application has drawn the second frame, so it swaps buffers. The display buffer now has frame 1 in it. The application now starts drawing frame 2.
But the graphics card isn't ready to draw frame 1 on the monitor until a little over 6 msec later, at t = 16.67. At that time, though, the application hasn't finished drawing frame 2 yet, so frame 1 is still in the display buffer. The monitor draws frame 1. Game frame 1 comes after game frame 0, so we're still in sync.
During this time, the application has been working on frame 2. It finishes frame 2 at t = 21.05 msec and swaps buffers. Frame 2 is now in the display buffer, and the application starts drawing on frame 3.
The monitor is ready to draw frame 2 at t = 33.33 msec. So it reaches for the frame from the display buffer... but what's this? The frame in the display buffer isn't frame 2. It's frame 3! We dropped a frame somehow!
In the meantime, at t = 31.58 msec, the application had finished drawing frame 3. It swapped buffers again, before the graphics card got a chance to display frame 2. Frame 2 disappeared from the display buffer, never having been shown on the monitor. That's a dropped frame, and it's a bad thing.
Games aren't hard-real-time applications, of course. They run freely, sometimes drawing frames more quickly, and sometimes less quickly, depending on the load. This is okay. But don't just assume that because your game runs consistently at a rate higher than your monitor, you won't be dropping frames. In fact, you'll drop frames like crazy, at a rate determined by how far your game frame rate is from your monitor rate, in modulo arithmetic.
Well, then, again we're back to the irrelevance of extreme examples. Okay, that was an example of a terrible licensing scheme. But since it's not representative, it's fundamentally meaningless.
There it goes. Sooner or later every Slashdot thread about the merits of free software will disintegrate into a Microsoft bitch-fest.
Sigh. Bored now.
However, with proprietry software, the tendency is to make the licenses as complicated as possible, so as to make it hard for one's competitors.
Speaking as someone who manages the development and deployment of proprietary software, I don't think you're quite right about that. Our end-user license is a page long, with pretty small type. It's complex, but not absurdly so.
We've (actually, our lawyers) have made it as complicated as it needs to be to define our relationship with our customers, while keeping it as simple as possible. If it's too complex, it'll be ambiguous or obtuse, and it won't hold up legally.
We're not thinking about our competitors. We're thinking about ourselves and our customers.
That is beacuse COM has in-proc servers, meaning that it is on the same adress space, and is extremely fast.
;-)
See? There you go. I didn't know that. I therefore reframe my opinion: CORBA is bad for plugins, and COM is just plain bad.
(I was kidding. Don't post anything about how COM is okay. I have no opinion about COM.)
Touche, but things were different then. If the environment were the same-- computers used mostly in academic institutions and mostly by enthusiasts-- then the model would work. Except it isn't.
Grandmothers use laptops now. My boss thinks himself an expert because he knows how to use Windows 98 Internet Connection Sharing. The world is a different place.
Applying the free software model to a big environment like this one sounds... improbable in the extreme.
Yeah, Vim is fine. GCC is a decent compiler, although in a lot of cases a different compiler produces better results. (If your goal is to use the same compiler on different architectures, though, GCC is for you.)
KDE and Gnome are not as good as the classic Mac OS UI, the Mac OS X UI, or the Windows 9x/NT4/2000/XP UI. This is my opinion, but I believe it's an educated one, and I think many people agree with me. KDE and Gnome are usually acceptable user interfaces, but they're not as good as their commercial competition. Sometimes they're very not-as-good.
Mozilla is inferior to Internet Explorer on Windows in terms of speed and simplicity. On other platforms, though, Mozilla is as good or better than competing browsers. I think this says more about the sorry state of browsers other than IE for Windows than it does about Mozilla.
Open Office? Terrible. I'd rather use MS Office, AppleWorks, or WordPerfect.
Apache (which you didn't mention, but maybe should have) is the best web server available. Sort of the exception that proves the rule, I think.
That was certainly an interesting example, but I don't think it's a very useful one in context of this discussion. The fact that there are bad-- read "needlessly complex"-- license models out there doesn't necessarily mean that licenses are, prima facie, bad.
I think, in most circumstances, software licensing works fine. You sort of chose the worst possible example of obtuse licensing to make a point, and I don't think that's helpful in the big sense.
It would be easy to dismiss this comment as hippy-dippy-there-he-goes-again. But consider what we are seeing now, with attempts to control people and programmers via the DMCA and similar ilk. Isn't he RIGHT?
"Marge, I agree with you in theory. In theory, communism works. In theory."
While some of the ideas behind the free software movement may be based in valid principles, as long as software is fundamentally an economy, free software (in either sense of the term) will be marginalized.
RMS is talking about taking software-- writing it, obtaining it, and using it-- out of the economic model and putting it into something different. A new kind of model that has never been done before.
And whenever anybody talks about an entirely new model for a system-- one that has never been tried before-- I'm skeptical.
The average speed of talking is 125wpm...
Of course, the average speed of talking when one is actually thinking about what one is saying is somewhat lower than that.
Um... okay. I suppose this may be true if you're using the right ORB. But in general it sounds like you're confusing dynamic linking with remote procedure calls. I say this because you use the words "CORBA" and "DLL," apparently, to refer to the same thing. They don't.
It's an issue of address space. If I dlopen() a library and dlsym() a symbol, I can then call the function associated with that symbol and have that function run inside the calling program's address space, using the program code from the DSO I opened. It is, for all purposes, as if that code had been compiled into my program from the beginning. I can do things like pass it pointers and get pointers in return, because we're all running in one big happy address space.
Generally speaking, though, calls over CORBA interfaces (I won't speak about COM because I neither know about, nor are particularly interested in, it) cause code to be executed in another address space. Even if the other program is started at first reference, there's still another program out there, with a separate address space. Calling it requires a context switch, and it also (and more importantly) requires that you serialize and send any relevant data from caller to callee, and back again. If you're a program like Photoshop, and the plugin is going to operate on the image in memory, a requirement that you must pass the whole image to the plug-in process would be pretty dumb.
While it may be possible to use an ORB to broker calls to and from DSOs linked into your application at compile time, I'm not aware of any method for using the ORB to link in objects at run time. Of course there may be one, but I'm not aware of it.
Generally, I'm coming down on the side that says CORBA (and possibly COM, if it's fundamentally similar to CORBA) is great and cool, but utterly and completely inappropriate for writing plug-ins, in the traditional sense.
Well, assuming that you absolutely must design a plugin system, lookin into some runtime aggregation systems (COM or CORBA depending on your platform and needs). That's basically with these techologies are for.
Hmm... I don't think I agree.
When I think "plugin," I think of an application loading and executing some code from a DSO or whatever at run-time.
When I think "CORBA," I think of two running applications communicating with each other at run-time.
They're fundamentally different things. If you were to design your plug-in architecture using CORBA, you'd have to have your programmers build little applications that would have to be started and to run alongside your main app, just so your main app could make remote calls to them. Seems kinda silly to me.
3. Allow other vendors to sell compatible hardware, maintain standards similar to the PC-99 standard. Get money off the OS licensing.
Yes, we all saw how well that worked back in 1995-1997.
Like it or not, approve of it or not, right now Apple is a hardware company. Their software-- great though it is-- exists to drive sales of their computers.
I think there's a strong argument to be made right now that Apple's sales aren't being hurt by the differences between the Mac hardware and PC hardware. The G4 Cube was the only Mac in recent years that didn't sell faster than they could make 'em, and Apple dropped it faster than a... fast... dropping thing.
Apple keeps prices high through three basic values: quality, coolness, and scarcity. People buy Macs because they're great computers, or because they or their software are cool, and that's where your demand comes from. Scarcity keeps the prices high.
If Apple were to change their strategy to a software-only model, they would be sacrificing two-and-a-half of those three things. That'd be bad all around.
As I seem to recall, the majority of final formats in the digital realm are in MPEG-2, as that is what the current mastering/delivery solution is.
Yes... but you hit the nail on the head when you said "final format." Although some outlets choose to encode manually before broadcasting, most outlets encode right before the signal go to the transmitter as part of an unattended real-time process. For all intents and purposes, the transmitter or uplink or distribution-system-you-like takes uncompressed SDI or HD-SDI as its input.
Digital Betacam and DVD both use MPEG-2
Bzzt. Digital Betacam (HDCAM too, for that matter) uses a proprietary DCT-based compression algorithm that usually results in around 2:1 compression for SD, 10:1 for HD. D-5 is purely uncompressed, and a lot of post houses use D-5 instead of D-Beta. In the HD world, the D-6 is purely uncompressed. It's a monster VTR, though.
With HDTV coming up in the future, how are editors/equipment suppose to deal with uncompressed data streams of frames larger than current NTSC/PAL frame sizes? Even with fast enough computers, achieving those disk writing speeds to capture the video realtime to a system uncompressed would literally flood almost any physical storage bus solution.
Oh, you'd be surprised. First of all, we've been doing HD nonlinear for over three years now, using Fire on an Onyx2. It's getting to the point where you can do some HD work on a PC or Mac, although no editor who's ever worked on a Fire will ever go back to the desktop. You get spoiled by all the real-time stuff.
Handling the basic data I/O isn't hard. Say you work in 8-bit YUV, 4:2:2. You can pack an entire pixel into two bytes (eight bits for luminance, and four bits each for the two color samples). That's 4,147,200 bytes per frame at 1920x1080 (make it simple; don't count the vertical interval). At thirty frames per second, that's about 120 MB per second. Two fibre channel loops (or one 2 Gb loop) with about eight disks can accomplish that. HDTV at 1080 lines isn't delivered as frames, of course, but as fields. This has no relevance on the storage of data on the disk, because the math works out the same either way.
RGB is more complex, though. Discreet uses RGB internally because all the SGI media libraries deal with it best. So you need three bytes for each pixel, making your data rate one-third more. That's a bit over 180 MB/s, which is still easily doable with commodity hardware.
(The software is tricker. I leave constructing a filesystem that is capable of real-time random-access playback and recording of multi-resolution data to be an exercise for the reader. It's much, much harder than you think. You can get around it, though, by buffering like crazy and using lots of disks.)
But, of course, if you're editing you have to be able to play back two streams of video at the same time. (Think real-time dissolve.) Double that. For RGB, that's about 360 MB/s of raw disk bandwidth required. Even with overhead, that's still within what one 64-bit, 66 MHz PCI bus can do.
Of course, once you get that data onto your disks, you still have to be able to read it and pump it to the video card in real time. If you wanna do anything to it on the way-- like apply a color correction, for instance-- you have to pass it through the CPU. It's easier to do that sort of thing on an SGI than on a PC, because the graphics hardware on an SGI can do lots of stuff in real time without having to bog down the CPUs.
Long story short, you can do HD on a PC or a Mac. If you've never done any high-end work, it's pretty amazing. On the other hand, if you have worked on a Fire or such, HDTV on the desktop sucks.
(Disclaimer: I don't work for Discreet, though this post may sound like I do. Consider me an experienced observer.)
You're not horribly out of date. Flame still runs on Octane, albeit with next-gen graphics now instead of the MXI/MXE that you worked with. We use FC disks instead of SCSI, which means fewer channels. Discreet is finally getting rid of their Stream audio subsystem-- which was left over from the Onyx days, when there was no other digital audio in the computer-- and replacing it with optical audio input and output through a break-out box that has analog and AES spigots. (I don't remember if Flame did audio in '99, but it has now for quite some time.) But besides these things, the hardware and software haven't changed much.
But the PC world has caught up, somewhat. The 64-bit, 66 MHz PCI bus offers something like 500 MB/s of bandwidth, which is plenty fast for standard definition, and acceptable for high definition. PC processors have gotten fast enough to be able to run mediocre, untuned code at acceptable speeds. And Discreet is using some mildly exotic hardware coprocessor stuff for their new product, if my sources are to be believed. Kind of like Avid's hardware DVE component, except inside the computer on a PCI card. Not sure of the details.
The point, though, is that PCs are catching up through brute force. For example, Discreet's apps depend quite a bit on the digital media libraries bundled with IRIX, the SGI OS. These libraries, particularly ImageVision and dmedia, are largely composed of handwritten assembler code. They were tuned to the nines years ago, and have remained mostly untouched since the mid 90s. This allowed those old, slow (relatively) SGI machines to do amazing things in real time.
Microsoft's media libraries have never been very good by comparison. But CPUs are getting to the point where they're sufficiently fast to get the job done at a much lower efficiency.
Plus which, look at it from a business perspective. There's just not that much more work that can be done to Smoke or Fire, Flame or Inferno. The improvements that are happening now are either fairly marginal-- like the color warper-- or kind of half-assed-- like bolting various shared storage technologies atop Stone+Wire. If Discreet builds a sufficiently advanced system, maybe not revolutionary but good enough to convince their customers to buy it, then they're in a really good business position.
Which is easier to develop for, Windows, SGI, or Linux? Which is easier to find programmers for? If you were going to start from scratch on a whole new app, and you didn't require one particular OS or class of hardware for any good reason, which platform would be your first choice?
Yup. We can talk about superiority all day long, but the bottom line is that it's faster and easier to develop and deploy major apps on Windows. Assuming, of course, that your app doesn't do anything Microsoft might be interested in integrating into the OS.
You might be surprised. One of the big video effects/editing companies is Discreet; they're not as big as Avid, of course, but they're second in popularity, I think. They sell Smoke and Fire (editing) and Flame and Inferno (effects), among other things.
Those apps run on SGI workstations, either Octanes or Onyx 2/Onyx 3000s. The app is full-screen, and highly modal rather than windowed. No windows or menu bars or palettes or anything. It's a very different interface, and not intuitive at all, but once you learn you way around it's incredibly fast. I've watched experienced Smoke editors fly though the app faster than I could follow. Amazing.
If Discreet were to port those apps over to Linux, I don't think any of the artists would notice or care. The underlying OS is invisible-- and irrelevant-- at that point.
Of course, Discreet's next-generation product is going to be based on Windows XP. So it's kind of a moot point.
Most television shows and minor Hollywood production companies still use Video Toaster for the few things you still can't do in Adobe Premier and After Effects.
Actually, most television shows (in my experience) are still cut in linear*. Those that are cut in nonlinear are done with Avids; the crappy stuff comes out of a Media Composer or a Symphony, while the relatively big-budget shows are sometimes cut on a DS. The really big-ticket shows are finished on a Smoke. Most of the HD stuff, to my knowledge, is done in Smoke.
Video Toaster is just an also-ran.
Right now, Final Cut Pro is also an also-ran, but lots of houses seem to be replacing Media Composers with FCP for off-lining.
*Linear editing, in with video tape machines. Opposed to nonlinear editing, like with computers.