"Positive rights" and "negative rights" still have nothing at all to do with the discussion at hand, and are borderline non-sensical concepts.
For instance, programs having decent usability is a "negative right", because it means the programmer should refrain from restricting the user by writing programs that are hard to use. However, releasing the source code for a program is a "positive right" because it requires the programmer to go the extra length of packaging and distirbuting the source code.
I'm pretty sure you're the only person in the country, if not on the entire planet, to be smart enough to realize that that life was not actually in shades of brown at that time, so yeah, your suspicions are entirely correct!
Er... I don't mind the player much, it's decent enough. It's precisely the architecture that I hate with a passion, because it is both a pain in the ass to use, and utterly useless when it comes to plugging in new codecs.
DirectShow is also a pain in the ass to use, but at least its filter graphs work, and you can get media playing by just plugging in the individual components. Not so for Quicktime, which seems to leave it up to every demuxer to handle the decompression of the formats contained in the files.
"Horribly designed" is probably closer to the mark of what I was trying to say. The plugin architecture especially, as I've complained elsewhere in this thread, has some serious problems, and that's where DirectShow is soundly kicking its ass.
A major overhaul would be welcome, but I fear the plugin architecture wouldn't be signficantly changed to support proper filter graphs, as it would probably take a total rewrite. Well, I'd be happy to be proved wrong on this.
I was inexact - I meant to say, a demuxer that for.ogm files that contain video.
Using this demuxer, and opening a.ogm file that has multiple audio streams and a video stream, I get to hear all audio streams on top of each other, and get no video, despite having codecs installed for the video codec used (plain XviD).
Which was my point. The plugin system is totally broken, and completely fails to render the file although all the parts are in place.
PS: Calling me an "MS fanboi" is totally hilarious. Maybe you missed the part where I am a Mac OS X developer? Like so: http://wakaba.c3.cx/s/apps/xee.html
If it works so well, how come I can have an AVI demuxer, an MP3 codec, a WMV3 codec, yet not be able to play files with WMV3 video and MP3 audio in an AVI container?
DirectShow only needs the individual components installed, and it will build a codec graph that can decode the whole thing. Quicktime apparentyl does nothing of the kind, and forces every demuxer to handle video and audio formats on its own. This is probably the reason there is no MKV or OGG demuxer available for QuickTime.
Both as a user and as a developer, it is very easy to tell that Quicktime is horribly written. The plugin architecture is a mess, to the point that adding support for new codecs is nearly impossible (Watch the Flip4Mac team struggle to get WMV files playing in Quicktime - it's not pretty), the library is buggy (I have here a JPEG file that shows up just fine in most every viewer, but it will crash Quicktime hard, to the point where it sometimes crashes a couple more time on subsequent images), and programming for it is an utter pain in the ass.
Microsoft's DirectShow is by far the better architecture, and when MS manages to design a better API than yours, that's saying a lot.
No, I was quite deliberately non-puctuating and non-capitalizing it that way. There was a point being communicated by this, but I didn't really expect it to be picked up, and it obviously wasn't.
You're losing sight of the argument here. What I was saying was, on OS X, I can distribute my app as follows:
1. Compile app. 2. Right-click app bundle, select "Create Archive". 3. Upload archive to webserver. 4. Link archive on website. 5. User clicks link, doubleclicks archive, has program ready to run.
Linux:
1. Compile app. 2. Somehow create.deb file, I have no idea how. 3. Get.deb file onto official software repository (not going to happen). 4. Get.deb file onto alternative software repository (Don't know of any, don't know what it takes to get it there, not under my own control so I have no way to ensure it's available unless I run my own, no idea how to do that). 5. Post explanation for the user how to add this particular software repository to their package manager. At this point, most users balk.
This covers ONE distro. I now have to go on and do something with.rpms, and something for Gentoo, and something for whatever weird system someone else might be using. I probably have to set up my software development environment to cater to other people on wildly varying systems who are not in themselves developers, because in practice a lot of people will end up having to build from source anyway because I didn't cover their particular distro.
Slashdot Mirror
News for Luddites. Stuff that scares us.
Oh yeah, oppose technology on the grounds that it kind of sounds like something from the bible.
That's awesome. No, really. It's the same reason that I oppose abortions and women's suffrage!
News for Luddites. Stuff that scares us.
Yes, that was kind of the point. Any argument about "positive rights" or "negative rights" is fucking ridiculous.
"Positive rights" and "negative rights" still have nothing at all to do with the discussion at hand, and are borderline non-sensical concepts.
For instance, programs having decent usability is a "negative right", because it means the programmer should refrain from restricting the user by writing programs that are hard to use. However, releasing the source code for a program is a "positive right" because it requires the programmer to go the extra length of packaging and distirbuting the source code.
Meaningless concepts, silly semantics.
I didn't even read the article, yet I still know that article was argued from the GNU definition of free software, which you can read here:
http://www.gnu.org/philosophy/free-sw.html
Your statements have nothing to do with this definition.
Well, it's a good thing we have your brilliant intellect to put them right, then, isn't it?
I thought most Slashdotters already used their FOSS software on Linux.
I'm pretty sure you're the only person in the country, if not on the entire planet, to be smart enough to realize that that life was not actually in shades of brown at that time, so yeah, your suspicions are entirely correct!
Or how about you get another job that pays less but doesn't take up all your time, and actually have some time over for yourself?
I know, I know, CRAZY TALK.
Oh wow, good thing you pointed that out, or they'd never have realized! I'm sure they'll fix that in the next patch.
Here's a dollar: $
You can use it to buy a sense of humor!
Er... I don't mind the player much, it's decent enough. It's precisely the architecture that I hate with a passion, because it is both a pain in the ass to use, and utterly useless when it comes to plugging in new codecs.
DirectShow is also a pain in the ass to use, but at least its filter graphs work, and you can get media playing by just plugging in the individual components. Not so for Quicktime, which seems to leave it up to every demuxer to handle the decompression of the formats contained in the files.
"Horribly designed" is probably closer to the mark of what I was trying to say. The plugin architecture especially, as I've complained elsewhere in this thread, has some serious problems, and that's where DirectShow is soundly kicking its ass.
A major overhaul would be welcome, but I fear the plugin architecture wouldn't be signficantly changed to support proper filter graphs, as it would probably take a total rewrite. Well, I'd be happy to be proved wrong on this.
A strikingly apt summary. GJ!
I was inexact - I meant to say, a demuxer that for .ogm files that contain video.
.ogm file that has multiple audio streams and a video stream, I get to hear all audio streams on top of each other, and get no video, despite having codecs installed for the video codec used (plain XviD).
Using this demuxer, and opening a
Which was my point. The plugin system is totally broken, and completely fails to render the file although all the parts are in place.
PS: Calling me an "MS fanboi" is totally hilarious. Maybe you missed the part where I am a Mac OS X developer? Like so: http://wakaba.c3.cx/s/apps/xee.html
If it works so well, how come I can have an AVI demuxer, an MP3 codec, a WMV3 codec, yet not be able to play files with WMV3 video and MP3 audio in an AVI container?
w .aspx?catid=29&threadid=842&enterthread=yw .aspx?catid=29&threadid=1141&enterthread=y
DirectShow only needs the individual components installed, and it will build a codec graph that can decode the whole thing. Quicktime apparentyl does nothing of the kind, and forces every demuxer to handle video and audio formats on its own. This is probably the reason there is no MKV or OGG demuxer available for QuickTime.
See:
http://www.flip4mac.com/fusetalk/forum/messagevie
http://www.flip4mac.com/fusetalk/forum/messagevie
Both as a user and as a developer, it is very easy to tell that Quicktime is horribly written. The plugin architecture is a mess, to the point that adding support for new codecs is nearly impossible (Watch the Flip4Mac team struggle to get WMV files playing in Quicktime - it's not pretty), the library is buggy (I have here a JPEG file that shows up just fine in most every viewer, but it will crash Quicktime hard, to the point where it sometimes crashes a couple more time on subsequent images), and programming for it is an utter pain in the ass.
Microsoft's DirectShow is by far the better architecture, and when MS manages to design a better API than yours, that's saying a lot.
...perhaps they should fire the Quicktime team too?
Yes, yes, yes, yes, yes, YES, YES PLEASE!
Quicktime is such an utter piece of shit. This coming both from the perspective of a user and a developer.
If that is the case, then Aperture must really be an utter piece of shit, because the Lightroom beta I tried was horrible, the interface especially.
You are wrong about QuickTime on Windows: It is a very faithful port of QuickTime on Mac, which is also a total piece of shit.
This Slashdot article no verb.
No, I was quite deliberately non-puctuating and non-capitalizing it that way. There was a point being communicated by this, but I didn't really expect it to be picked up, and it obviously wasn't.
what
You're losing sight of the argument here. What I was saying was, on OS X, I can distribute my app as follows:
.deb file, I have no idea how. .deb file onto official software repository (not going to happen). .deb file onto alternative software repository (Don't know of any, don't know what it takes to get it there, not under my own control so I have no way to ensure it's available unless I run my own, no idea how to do that).
.rpms, and something for Gentoo, and something for whatever weird system someone else might be using. I probably have to set up my software development environment to cater to other people on wildly varying systems who are not in themselves developers, because in practice a lot of people will end up having to build from source anyway because I didn't cover their particular distro.
1. Compile app.
2. Right-click app bundle, select "Create Archive".
3. Upload archive to webserver.
4. Link archive on website.
5. User clicks link, doubleclicks archive, has program ready to run.
Linux:
1. Compile app.
2. Somehow create
3. Get
4. Get
5. Post explanation for the user how to add this particular software repository to their package manager. At this point, most users balk.
This covers ONE distro. I now have to go on and do something with