Announcement

Collapse
No announcement yet.

NTFS-3G Merges With NTFSprogs, Plus New Version

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic NTFS-3G Merges With NTFSprogs, Plus New Version

    NTFS-3G Merges With NTFSprogs, Plus New Version

    Phoronix: NTFS-3G Merges With NTFSprogs, Plus New Version

    The NTFS-3G project, which provides a file-system driver with read/write support for Microsoft's NTFS file-system on Linux, has merged with ntfsprogs. The ntfsprogs package provides various utilities for the Linux NTFS file-system like mkntfs, ntfsclone, ntfsundelete, and ntfsdefrag. Merging NTFS-3G and ntfsprogs was the logical move and now there's a stable release of the merged software: ntfs-3g_ntfsprogs...

    http://www.phoronix.com/vr.php?view=OTMxNQ

  • Nobu
    replied
    To make myself clear, it's a logical decision, based on business and legal reasons. Not a philosophical decision based on "I like this one more," or "this one is not free, so I won't use it, even if I can afford it".

    Leave a comment:


  • Nobu
    replied
    Originally posted by yogi_berra View Post
    They can, they chose not to, making the problem philosophical, not technical and not legal.
    Like I said, "being able to work around the problem does not make it philosophical; that is only the case if they have a significant group of customers who want Red Hat to pursue the work-around, yet they refuse to." Would you buy a license (which is needed only because of a new feature that you don't need) for a browser plug-in that you and almost none of your customers use, just because it fixes a security flaw? Especially considering the format's decrease in usage, I wouldn't.

    In the case of Fluendo's mp3 codec, the situation is even worse, because Fluendo can't even make the fix available (from what I understand), so Red Hat's only choices are to either leave their customers vulnerable, or remove it from the supported repo. Having an obligation to their customers, the second option is the obvious choice, since their customers can always get it for themselves, if they want to put themselves at risk.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by yogi_berra View Post
    Your premise would be great if Red Hat couldn't afford to purchase licenses for said codecs. They can, they chose not to, making the problem philosophical, not technical and not legal.
    That sounds more like an economic problem than a philosophical one. Their customers don't want to pay for it.

    Leave a comment:


  • yogi_berra
    replied
    Originally posted by Nobu View Post
    Looks like a technical, legal problem, to me. It only becomes philosophical when you make it so, by saying that you should ignore license restrictions, which Red Hat cannot do. And, no, being able to work around the problem does not make it philosophical; that is only the case if they have a significant group of customers who want Red Hat to pursue the work-around, yet they refuse to.
    Your premise would be great if Red Hat couldn't afford to purchase licenses for said codecs. They can, they chose not to, making the problem philosophical, not technical and not legal.

    Leave a comment:


  • Nobu
    replied
    Originally posted by yogi_berra View Post
    I can't help that you do not appreciate quality sarcasm.

    I would, however, point out the problem you point to as being a "technical" problem is a philosophical problem as there was nothing technically preventing Red Hat from shipping the next version of Real Player beyond a lack of willingness to do so.
    Looks like a technical, legal problem, to me. It only becomes philosophical when you make it so, by saying that you should ignore license restrictions, which Red Hat cannot do. And, no, being able to work around the problem does not make it philosophical; that is only the case if they have a significant group of customers who want Red Hat to pursue the work-around, yet they refuse to.

    Leave a comment:


  • yogi_berra
    replied
    Originally posted by RahulSundaram View Post
    This isn't a theoretical or philosophical problem. One example

    https://rhn.redhat.com/errata/RHSA-2008-0812.html

    Your sarcasm (not thinly veiled really) is unwarranted and unnecessary in this case. . Yes, it is true that Red Hat might include licensed components in a extras repository if there is a sufficient demand for it however my point was that it will never be in the main repository and it is not possible to ignore legal and technical issues regardless of whether end users care about them.
    I can't help that you do not appreciate quality sarcasm.

    I would, however, point out the problem you point to as being a "technical" problem is a philosophical problem as there was nothing technically preventing Red Hat from shipping the next version of Real Player beyond a lack of willingness to do so.

    Leave a comment:


  • pvtcupcakes
    replied
    Originally posted by smitty3268 View Post
    I find it hard to believe that Red Hat and Fluendo couldn't work out a reasonable solution to this given the amount of money that would be involved. Surely you could become a 'preferred customer' or something and work this out. But I certainly understand why it's not worth it. I can't imagine the enterprise market is clamoring for such a feature, so there's no reason for Red Hat to provide it.
    I agree, who would want MP3 playback on their server? Are corporations going to blare their pirated music over the intercom using a RHEL box or something? I just really don't see a use for it.

    If your server is streaming MP3s, you don't need a codec on the server to do that as you're only transmitting the MP3 file and the client machine decodes it.

    It might be kind of nice if Red Hat could distribute an MP3 codec with Fedora, but enabling RPM Fusion is fine with me. And as was posted earlier, Red Hat would only have a sort of "3rd party" repo for the MP3 codec anyway. So it's either a 3rd party repo, or a 3rd party repo.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by RahulSundaram View Post
    If you can't effectively modify software to integrate with the distribution properly and if you don't have the freedom to fix potential security issues, then it a serious liability to include them and vendors have to take such things into consideration for inclusion of any components. This isn't a theoretical or philosophical problem.
    I find it hard to believe that Red Hat and Fluendo couldn't work out a reasonable solution to this given the amount of money that would be involved. Surely you could become a 'preferred customer' or something and work this out. But I certainly understand why it's not worth it. I can't imagine the enterprise market is clamoring for such a feature, so there's no reason for Red Hat to provide it.

    Leave a comment:


  • RahulSundaram
    replied
    My point had nothing whatsoever to do with FSF either. If you can't effectively modify software to integrate with the distribution properly and if you don't have the freedom to fix potential security issues, then it a serious liability to include them and vendors have to take such things into consideration for inclusion of any components. This isn't a theoretical or philosophical problem. One example

    https://rhn.redhat.com/errata/RHSA-2008-0812.html

    Your sarcasm (not thinly veiled really) is unwarranted and unnecessary in this case. . Yes, it is true that Red Hat might include licensed components in a extras repository if there is a sufficient demand for it however my point was that it will never be in the main repository and it is not possible to ignore legal and technical issues regardless of whether end users care about them.

    Leave a comment:

Working...
X