I should add: coffee is different from tobacco, because the tobacco itself is harmful, not just the nicotine. AFAICT, Coffee is not particularly harmful, except for the caffiene.
And if GM tobacco plants were introduced, and I was convinced that nicotine-free tobacco was a Good Thing, you'd still have to convince me that this was the only reasonable way to obtain nicotine-free tobacco.
"No" what? No one would smoke nicotine-free tobacco at all? If that's what you're saying, I mostly agree.
However, there's a lot of talk about the psychological addiction of smoking (aside from chemical). Perhaps those smokers would smoke nicotine-free tobacco.
Nicotine-free tobacco would be completely boneheaded. Non-smokers still wouldn't smoke it, because it'd still be bad for you. Smokers wouldn't smoke it, becase the nicotine's what they're addicted to. (Non-chemically-addicted smokers might smoke it.)
It's American clothing. It's clearly derived from American Independence day. Speaking as a Canadian, this does nothing for me. ['cept demonstrate the incredible power of American myopia yet again.]
Usually, I'm a GPL supporter, but I can understand the reasoning behind using BSD here.
They're trying to establish a new video standard, which isn't easy. So they want to encourage the maximum number of developers to participate. A BSD license will do that.
It's questionable whether someone would spend the effort to take the codec, improve it significantly, and make it proprietary. In any case, such a proprietary version would probably not catch on.
Remember, there are no effective patents in this case, so the Sorenson problem would seem not to apply.
And Xiph now has a track record of actually maintaining their code, making it better, not pulling funny tricks.
Oh, I (or you) can make this new code GPL today. Just download it, change the license at the top, and post it. But what would be the point of that? There'd still be the BSD version, and it would be better-maintained.
No, flour, rice, salt and water aren't plurals. You don't talk about "a water" or "a rice". Words like that are mass nouns.
There are also words whose plural is the same as their singular. "Fish" comes to mind. You can catch "two fish", but you can also catch "two fishes", depending where you're from.
Re:There is nothing wrong with RPMs. Only packager
on
Is RPM Doomed?
·
· Score: 2
Yes, I've been corrected on this already-- file dependencies are not the only option. It does look like the mere existance of file dependencies is problematic, though.
Re:There is nothing wrong with RPMs. Only packager
on
Is RPM Doomed?
·
· Score: 2
Yeah, I thought the "Red Hat.deb" idea was probably farfetched. It's nice to know that.rpm does have technical merits-- makes it easier to understand why distros and the LSB continue to use it.
You have more control over your system if your system understands what's installed on it. Standardized systems like.rpm or.deb provide this. InstallShield (despite being used by 90% of Windows programs) does not. It turns each application into a big black box. Windows knows how to ask it to uninstall itself, and that's all it knows.
Why do you think there are programs like Uninstall Manager? Uninstall utilities are designed to give the user greater control than application-provided uninstallers. They wouldn't exist if that control wasn't lacking.
I can't count the number of times a setup.exe has offered or attempted to install old versions of Quicktime, Acrobat Reader or DirectX. This is because Windows has no standard way of knowing what packages are installed.
With RPM, you'd have one package for each, you'd download the latest, and that would be that.
With APT, you'd just do apt-get upgrade, and it would take care of the dependencies for you.
The tasks that installers perform are well-known and easy to understand. Even if funky, bizarre commands are needed during the installation process to initialize the package, installers provide the ability to run scripts.
There's no reason why a custom installer is needed, and there are a lot of good reasons why a standardized package management system is useful. But not all package management systems are equal.
In Debian, the approach to this problem is the 'task' packages: You "apt-get install task-gnome-desktop", and it installs a whole bunch of reasonable defaults.
(The "task" packages are content-free-- they consist only of dependencies on other packages).
Re:There is nothing wrong with RPMs. Only packager
on
Is RPM Doomed?
·
· Score: 3, Interesting
Actually, there is a limitation of.rpm that hinders the APT4RPM functionality-- file dependencies..rpm archives depend on specific files, while.debs depend on specific packages. This can be worked around, essentially by creating a list that maps files-that-are-depended-upon to packages-containing-these.
But yes, there is at least one technical superiority of the.deb file format. I have never heard any argument that.rpms have a technical superiority to.debs, so I have to wonder: why don't RPM-based distros don't switch to deb? They could just adopt the.deb file format as RPM 5, make the tools speak deb, and stop worrying about it. They'd serve their users better and reduce duplication of effort.
Or perhaps users should take it into their own hands. Using tools like 'alien', it might be possible to take the apt4rpm approach one step further-- create an unofficial 'Redhat.deb' distribution-- the same packages as Red Hat, but in a different package format.
The thing is that everything that Nvidia's said sounds like they don't intend to play that game. Most of these comments are the "knee-jerk-haven't read-the-article" level.
Proprietary standards are not a bad thing when there are no open standards. In fact, many standards bodies look to current practice for examples of standards. If everyone waited for standards, there would be fewer (or worse) standards. And for a proprietary standard, this one seems pretty open.
I understand that Nvidia has been heavily involved in the creation of the suspiciously-similar OpenGL 2.0. Their release of Cg will give them useful information for refining the standard. It's also a solid pragmatic decision-- since many people are using Direct3D, they can either laugh and point at them or release something similar to OpenGL 2.0 that works with Direct3D. It also gets the tools to people now, rather than when OGL 2 is done.
The release of Cg could have the benefits I describe, or it could be as bad as you suggest. At this time, I don't think there's enough reason to think either one of them's true.
I disagree. Platforms have different strengths. If we say that platform foo is excellent for servers but lousy for desktops, and platform bar is excellent for desktops but lousy for servers, then your TCO will be lower with both than with either alone.
As long as two different platforms have different strengths, you can reduce TCO by taking advantage of their strengths.
If you're using win95 for your servers and Red Hat 3 for your desktops, you'd be better off with a monoculture. (And may whatever god you believe in have mercy on your soul!)
In fact, I'd go so far as to say that effective deployment of technology will never increase costs.
Err, Jews don't actually call the supreme being "gee, underscore, dee". They just feel (or at least some do) that it's profane to write the name of the holy one in books that are not holy. So they write "G_d" the same way people write, "What the f___?"
Actually, many shows are filmed on film, so it might be possible to remaster them in HDTV. That would require the original film and the will, of course.
Sure, Red Hat's being nice to developers using certain licenses, but they're not being nice to anyone else. If Red Hat's patenting obvious or semi-obvious things, they can still use those patents against other companies-- that's what they have the patents for. Even if the patents are obvious. Or invalid.
Patents on the obvious are bad. They reduce competition, and give the big dogs levers to hit the smaller dogs with.
Not good enough. Patent things, or else don't. This middle of the road patent-but-not-against-friends crap just muddies the waters.
When Red Hat feels threatened by some smaller company, you can bet that patent portfolio will come out.
Ah, but why write your own wrappers when someone (and not just someone, but lots of people) has written wrappers for you? Why worry about the design when there's a design already done and reviewed and redone?
Give me a good reason to reinvent the wheel, and I will. Hell, I used to reinvent the wheel for bad reasons or no reason. Wanna see my StringBuffer class? Didn't think so.
I've been using gtkmm on a little project of mine, and it's quite nice. I used gtkmm to give a gui to du. Used code from 2 different open source projects to do what I wanted.
Every line of code you reuse is more likely to be right than every line you write. If it's already been written, if it's already been tested, it's one less thing to worry about.
Slashdot Mirror
Yeah, but I meant "prior to 1986. . ."
This could be bad.
That's the only creation date I can find for the JPEG standard (ISO/IEC 10918-1:1994)
.
That, unfortunately, puts this patent way before the JPEG standard. I hope there's prior art. .
I should add: coffee is different from tobacco, because the tobacco itself is harmful, not just the nicotine. AFAICT, Coffee is not particularly harmful, except for the caffiene.
And if GM tobacco plants were introduced, and I was convinced that nicotine-free tobacco was a Good Thing, you'd still have to convince me that this was the only reasonable way to obtain nicotine-free tobacco.
"No" what? No one would smoke nicotine-free tobacco at all? If that's what you're saying, I mostly agree.
However, there's a lot of talk about the psychological addiction of smoking (aside from chemical). Perhaps those smokers would smoke nicotine-free tobacco.
I still think it's a boneheaded idea, though.
Nicotine-free tobacco would be completely boneheaded. Non-smokers still wouldn't smoke it, because it'd still be bad for you. Smokers wouldn't smoke it, becase the nicotine's what they're addicted to. (Non-chemically-addicted smokers might smoke it.)
Sure, but.
It's American clothing. It's clearly derived from American Independence day. Speaking as a Canadian, this does nothing for me. ['cept demonstrate the incredible power of American myopia yet again.]
Usually, I'm a GPL supporter, but I can understand the reasoning behind using BSD here.
They're trying to establish a new video standard, which isn't easy. So they want to encourage the maximum number of developers to participate. A BSD license will do that.
It's questionable whether someone would spend the effort to take the codec, improve it significantly, and make it proprietary. In any case, such a proprietary version would probably not catch on.
Remember, there are no effective patents in this case, so the Sorenson problem would seem not to apply.
And Xiph now has a track record of actually maintaining their code, making it better, not pulling funny tricks.
Oh, I (or you) can make this new code GPL today. Just download it, change the license at the top, and post it. But what would be the point of that? There'd still be the BSD version, and it would be better-maintained.
If Windows NT (and derivatives) had a good POSIX implementation, we wouldn't need Cygwin as much.
No, flour, rice, salt and water aren't plurals.
You don't talk about "a water" or "a rice". Words like that are mass nouns.
There are also words whose plural is the same as their singular. "Fish" comes to mind. You can catch "two fish", but you can also catch "two fishes", depending where you're from.
Yes, I've been corrected on this already-- file dependencies are not the only option. It does look like the mere existance of file dependencies is problematic, though.
Yeah, I thought the "Red Hat .deb" idea was probably farfetched. It's nice to know that .rpm does have technical merits-- makes it easier to understand why distros and the LSB continue to use it.
You have more control over your system if your system understands what's installed on it. Standardized systems like .rpm or .deb provide this. InstallShield (despite being used by 90% of Windows programs) does not. It turns each application into a big black box. Windows knows how to ask it to uninstall itself, and that's all it knows.
Why do you think there are programs like Uninstall Manager? Uninstall utilities are designed to give the user greater control than application-provided uninstallers. They wouldn't exist if that control wasn't lacking.
I can't count the number of times a setup.exe has offered or attempted to install old versions of Quicktime, Acrobat Reader or DirectX. This is because Windows has no standard way of knowing what packages are installed.
With RPM, you'd have one package for each, you'd download the latest, and that would be that.
With APT, you'd just do apt-get upgrade, and it would take care of the dependencies for you.
The tasks that installers perform are well-known and easy to understand. Even if funky, bizarre commands are needed during the installation process to initialize the package, installers provide the ability to run scripts.
There's no reason why a custom installer is needed, and there are a lot of good reasons why a standardized package management system is useful. But not all package management systems are equal.
In Debian, the approach to this problem is the 'task' packages: You "apt-get install task-gnome-desktop", and it installs a whole bunch of reasonable defaults.
(The "task" packages are content-free-- they consist only of dependencies on other packages).
Actually, there is a limitation of .rpm that hinders the APT4RPM functionality-- file dependencies. .rpm archives depend on specific files, while .debs depend on specific packages. This can be worked around, essentially by creating a list that maps files-that-are-depended-upon to packages-containing-these.
But yes, there is at least one technical superiority of the .deb file format. I have never heard any argument that .rpms have a technical superiority to .debs, so I have to wonder: why don't RPM-based distros don't switch to deb? They could just adopt the .deb file format as RPM 5, make the tools speak deb, and stop worrying about it. They'd serve their users better and reduce duplication of effort.
Or perhaps users should take it into their own hands. Using tools like 'alien', it might be possible to take the apt4rpm approach one step further-- create an unofficial 'Redhat .deb' distribution-- the same packages as Red Hat, but in a different package format.
The thing is that everything that Nvidia's said sounds like they don't intend to play that game. Most of these comments are the "knee-jerk-haven't read-the-article" level.
Proprietary standards are not a bad thing when there are no open standards. In fact, many standards bodies look to current practice for examples of standards. If everyone waited for standards, there would be fewer (or worse) standards. And for a proprietary standard, this one seems pretty open.
I understand that Nvidia has been heavily involved in the creation of the suspiciously-similar OpenGL 2.0. Their release of Cg will give them useful information for refining the standard. It's also a solid pragmatic decision-- since many people are using Direct3D, they can either laugh and point at them or release something similar to OpenGL 2.0 that works with Direct3D. It also gets the tools to people now, rather than when OGL 2 is done.
The release of Cg could have the benefits I describe, or it could be as bad as you suggest. At this time, I don't think there's enough reason to think either one of them's true.
Actually, Daemon Tools supports commandline options, so you can create shortcuts that (using a batch file) automatically mount the required image:
---begin cdrun.bat---
"c:\program files\d-tools\daemon.exe" -unmount 0
"c:\program files\d-tools\daemon.exe" -mount 0,%1
cd %2
%3
---end cdrun.bat---
Then create shortcuts to the batch file that supply
image file, program directory and program name in that order, and you're set.
(Lines 1 and 3 may not actually be needed)-- I haven't tested.
128 k? Cry a lot?
Sure it's non-standard-- except that it works with ATI cards. Doh!
I disagree. Platforms have different strengths. If we say that platform foo is excellent for servers but lousy for desktops, and platform bar is excellent for desktops but lousy for servers, then your TCO will be lower with both than with either alone.
As long as two different platforms have different strengths, you can reduce TCO by taking advantage of their strengths.
If you're using win95 for your servers and Red Hat 3 for your desktops, you'd be better off with a monoculture. (And may whatever god you believe in have mercy on your soul!)
In fact, I'd go so far as to say that effective deployment of technology will never increase costs.
Err, Jews don't actually call the supreme being "gee, underscore, dee". They just feel (or at least some do) that it's profane to write the name of the holy one in books that are not holy. So they write "G_d" the same way people write, "What the f___?"
Actually, many shows are filmed on film, so it might be possible to remaster them in HDTV. That would require the original film and the will, of course.
Cool. It didn't last time I tried it. Guess TTSSH gets put out to pasture. . .
I like and use putty, but it doesn't support SSH (X) forwarding. For that, I use TTSSH.
Sure, Red Hat's being nice to developers using certain licenses, but they're not being nice to anyone else. If Red Hat's patenting obvious or semi-obvious things, they can still use those patents against other companies-- that's what they have the patents for. Even if the patents are obvious. Or invalid.
Patents on the obvious are bad. They reduce competition, and give the big dogs levers to hit the smaller dogs with.
Not good enough. Patent things, or else don't. This middle of the road patent-but-not-against-friends crap just muddies the waters.
When Red Hat feels threatened by some smaller company, you can bet that patent portfolio will come out.
Ah, but why write your own wrappers when someone (and not just someone, but lots of people) has written wrappers for you? Why worry about the design when there's a design already done and reviewed and redone?
Give me a good reason to reinvent the wheel, and I will. Hell, I used to reinvent the wheel for bad reasons or no reason. Wanna see my StringBuffer class? Didn't think so.
I've been using gtkmm on a little project of mine, and it's quite nice. I used gtkmm to give a gui to du. Used code from 2 different open source projects to do what I wanted.
Every line of code you reuse is more likely to be right than every line you write. If it's already been written, if it's already been tested, it's one less thing to worry about.