Announcement

Collapse
No announcement yet.

NTFS-3G Merges With NTFSprogs, Plus New Version

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

  • #16
    Originally posted by RahulSundaram View Post
    Red Hat Linux 7 hasn't been relevant for years and years now. If we go back far enough, we can find Red Hat Linux without RPM as well. I was talking about current distros. If you are a person willing to switch distros rather than run a couple of commands, be my guest and have fun!
    That's the thing, I switched once and have been happy ever since instead of having to re-live a peeve on a constant basis.

    Comment


    • #17
      Enterprise Linux distros don't do upgrades that often and this is no constant peeve at all. RHEL for instance has 7 to 10 years of updates and gets new releases every few years and when customers do upgrade which is rarely they have bigger things to worry about than a extra package or two they need to install. RHN Satellite and kickstart can do this and more with ease across thousands of systems. They worry more about hardware or software certification, compatibility with custom apps, security, performance etc. In other words, for the target market of Red Hat, this isn't a problem.

      If on the other hand, you are talking about Fedora, it does come with NTFS-3g by default.

      Comment


      • #18
        Originally posted by RahulSundaram View Post
        Enterprise Linux distros don't do upgrades that often and this is no constant peeve at all. RHEL for instance has 7 to 10 years of updates and gets new releases every few years and when customers do upgrade which is rarely they have bigger things to worry about than a extra package or two they need to install. RHN Satellite and kickstart can do this and more with ease across thousands of systems. They worry more about hardware or software certification, compatibility with custom apps, security, performance etc. In other words, for the target market of Red Hat, this isn't a problem.
        If I worried about all of that I'd be using (and do for that usage) SLES/SLED instead in those scenarios.

        If on the other hand, you are talking about Fedora, it does come with NTFS-3g by default.
        Again my original comment was referring to RH when it wasn't just a enterprise solution but also serviced the regular user as well.

        Comment


        • #19
          Hi

          Yes, it become clear to me in the course of the discussion that you are talking about an old situation and not a current one. It's natural to assume in the absence of further clarification that "Red Hat" refers to RHEL and not RHL any longer. Not a relevant or interesting discussion for me to talk about RHL. So I will stop here

          Comment


          • #20
            RHL.. that brings back terrible memories of wrestling with a wireless driver (realtek 8180) that was part open and part binary, and only built for RHL 8.0. I so wanted to use Mandrake, but no internet was a deal breaker. That sent me back to Windows for a few years.

            Comment


            • #21
              Originally posted by RahulSundaram View Post
              Regardless of whether individual users care about it or not, it is reality just as much as EL doesn't include MP3 codecs or a dvd player or whatever. Either there are legal issues or there isn't enough customer demand to justify inclusion or any number of other reasons.
              Because we all know Red Hat can't afford to be generous and give away anything as trivial as a codec like Fluendo does, for anyone to use to listen to mp3s.

              There is no legal reason for that decision, its purely because there is no demand for that in the workstation market.

              Comment


              • #22
                There is actually a legal/technical twist to the Fluendo MP3 codec. Even though the code is under the MIT license, the patent grant limits modifications. If you do any modification to the codecs, you lose the patent grant and the code has a potential security issue that needs to be fixed (https://core.fluendo.com/gstreamer/trac/ticket/24 ). I am unaware of whether this reason is enough to avoid including it but things are not always what they seem at first glance.

                Comment


                • #23
                  Originally posted by RahulSundaram View Post
                  There is actually a legal/technical twist to the Fluendo MP3 codec. Even though the code is under the MIT license, the patent grant limits modifications. If you do any modification to the codecs, you lose the patent grant and the code has a potential security issue that needs to be fixed (https://core.fluendo.com/gstreamer/trac/ticket/24 ). I am unaware of whether this reason is enough to avoid including it but things are not always what they seem at first glance.
                  Oh sure someone at the F$F would take issue with distributing it like they currently do with Fluendo, but that wasn't my point.

                  The point of my thinly veiled sarcasm was that Red Hat is clearly able to afford a license to any codec they would want to distribute and could do so easily if they chose to. They don't as there is no market for mp3 or DVD playback on workstations and servers.

                  But if it helps you can tell your Bosses that doing so would be a good excuse to jack up subscription fees.

                  Comment


                  • #24
                    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.

                    Comment


                    • #25
                      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.

                      Comment


                      • #26
                        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.

                        Comment


                        • #27
                          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.

                          Comment


                          • #28
                            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.

                            Comment


                            • #29
                              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.

                              Comment


                              • #30
                                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.

                                Comment

                                Working...
                                X