Announcement

Collapse
No announcement yet.

Why Desktop Linux Sucks and What We can Do About It

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

  • #41
    Originally posted by Craig73 View Post
    You guys seem to contradict yourself
    - gstreamer sucks
    - phonon is great
    - phonon uses gstreamer
    Phonon CAN use gstreamer. I used the Gstreamer back-end for a little while, because there was a massive memory leak with Xine's. It got the job done, but it had me crawling back to SMplayer whenever I wanted to watch something.

    Phonon is great for application developers. All they have to do is tell Phonon "play this video" or "play this sound", regardless of what the video is, what the sound is, or (and this is a biggie) what platform it's on. KDE runs on Linux, Solaris, *BSD, OS X and Windows.

    Not every Windows user has Gstreamer on their system. I'm willing to bet the same holds true for OS X users. Rather than have ever application developer port from Gstreamer (Linux) to Direct Show (Windows) and/or Quicktime (OS X) to have cross-platform apps, they write for Phonon. And then the Phonon dev's (and ONLY them) worry about coding hooks for different back-ends.

    I'm not saying "Phonon is the greatest thing ever!" But, compared to aRTs, it is a Good Thing. It's a step in the right direction.

    What I AM saying is that if everyone writes their applications for Gstreamer, Gstreamer won't magically be a better system. It'll stick be an underperforming multimedia system.

    Comment


    • #42
      Originally posted by deanjo View Post
      You notice how you are now pointing to thing totally un-hardware related, all those issues were addressed with subsequent updates. Do you really want me to go into the list of breakages of simular issues with linux? Unfortunately that would require dozens of posts as micheal has a limit on the number of characters per post. Seriously stick on topic.
      I'm really sticking on topic, but you probably don't. I'm not interested if those issues were addressed with updates or not. I can give you dozens of hackintosh issues if you want, because it seems you still want to make not fair comparisons. Un-hardware means not hardware right? If yes why should I give you hardware related issues?

      Comment


      • #43
        Originally posted by kraftman View Post
        I'm really sticking on topic, but you probably don't. I'm not interested if those issues were addressed with updates or not. I can give you dozens of hackintosh issues if you want, because it seems you still want to make not fair comparisons. Un-hardware means not hardware right? If yes why should I give you hardware related issues?
        Because that is EXACTLY what the video talks about. It is referring to hardware that used to work but no longer does. You are the one bring up issues totally not related. Your last post was about ways to make the kernel panic and such and has NOTHING to do about upgrades breaking basic hardware. Those are more a case of "if Jupiter is in the sign of Libra and it's raining in the sierra and you fart to the west not the east, you can get get a panic" Seriously did you even watch the video or just mentally tune out at the first slide?
        Last edited by deanjo; 03 May 2009, 06:00 PM.

        Comment


        • #44
          Originally posted by deanjo View Post
          Because that is EXACTLY what the video talks about. It is referring to hardware that used to work but no longer does. You are the one bring up issues totally not related. Your last post was about ways to make the kernel panic and such and has NOTHING to do about upgrades breaking basic hardware. Those are more a case of "if Jupiter is in the sign of Libra and it's raining in the sierra and you fart to the west not the east, you can get get a panic"
          Actually I gave you software related issues which prevented hardware to work. And you wanted examples where OS X doesn't upgrade well (or at all). You also said:

          Not 1 of those issues is kernel nor the wifi stacks related. 3rd party, yes, defective hardware, yes but not 1 example of OS X breaking itself.
          So I gave you some examples where hardware (or even entire system) that used to work no longer does, because of kernel panics.

          Those are more a case of "if Jupiter is in the sign of Libra and it's raining in the sierra and you fart to the west not the east, you can get get a panic"
          And those are more cases about install some 3rd party apps.

          Comment


          • #45
            Originally posted by kraftman View Post
            Actually I gave you software related issues which prevented hardware to work. And you wanted examples where OS X doesn't upgrade well (or at all). You also said:

            So I gave you some examples where hardware (or even entire system) that used to work no longer does, because of kernel panics.



            And those are more cases about install some 3rd party apps.

            You have not once given me 1 example of a base system breaking a base system. I can however show you quite literally thousands of examples where this has happened in the linux kernel. If you want to bring in examples where non-base apps spur kernel panics then by all means, lets find a forum where I can post a list greater then the lines of code in the linux kernel.
            Last edited by deanjo; 03 May 2009, 06:37 PM.

            Comment


            • #46
              Originally posted by deanjo View Post
              You have not once given me 1 example of a base system breaking a base system. I can however show you quite literally thousands of examples where this has happened in the linux kernel.
              Here we're reaching the point. I repeated for few times if you want to compare those systems compare their preinstalled versions or compare their hackintosh versions. That should be fair. Don't forget many of those 'thousands examples' are due to using experimental drivers. So, to make this comparison really fair you should ignore reports where experimental drivers were used, because apple devs don't use Open Development Model, so users aren't able to use experimental drivers.

              If you want to bring in examples where non-base apps spur kernel panics then by all means, lets find a forum where I can post a list greater then the lines of code in the linux kernel.
              I can do the same when comes to hackintosh installs :>

              It's 00.46 AM here, so Good Night
              Last edited by kraftman; 03 May 2009, 06:46 PM.

              Comment


              • #47
                Originally posted by kraftman View Post
                Here we're reaching the point. I repeated for few times if you want to compare those systems compare their preinstalled versions or compare their hackintosh versions. That should be fair. Don't forget many of those 'thousands examples' are due to using experimental drivers. So, to make this comparison really fair you should ignore reports where experimental drivers were used, because apple devs don't use Open Development Model, so users aren't able to use experimental drivers.

                I can do the same when comes to hackintosh installs :>

                It's 00.46 AM here, so Good Night
                No it is not fair at all to compare to a hackintosh. You compare a hackintosh then I should be able to compare a linux system with blobs. Same thing. By the same reason you scream blobs fuck up linux, I can scream 3rd party screws up OS X. BTW, OS X's driver model is very well documented and opensource.

                Comment


                • #48
                  Could anyone tell me which distro doesnt have pulseaudio or gstreamer enabled? Or the way to disable it on Ubuntu 9.04? Seems like every major distro these days has pulseaudio enabled by default.

                  Comment


                  • #49
                    Gentoo :P Probably ArchLinux too.

                    Comment


                    • #50
                      Originally posted by deanjo View Post
                      Even the fully open wifi chipsets (ralink comes to mind for example) out there still have many regressions and can be somewhat a pain in the ass to get going if ever and often breaks on updates. You will not see however an airport card become useless on a darwin update, and if it was to happen, you would see a fast update to fix the issue. Even 3rd party devices like ralink tend to have their drivers up to snuff on OS X and don't break with the frequency they do on linux.
                      I completely disagree. My ralink-based USB wireless stick (RT2501USB) has worked out-of-the-box with zero issues since Ubuntu 8.04 (when I bought it). Do you have any kind of evidence for the problems you describe?
                      Originally posted by deanjo View Post
                      Again, I'm not saying that regressions don't happen in windows or osx. They do happen. Your regression that you are referring to with the XP to Vista is understandable. That was a major overhaul of the OS akin to a Linux 2.4 to Linux 2.6 upgrade of which a lot of stuff was broken in those early 2.6 kernels that worked fine in 2.4. A Win2k to XP upgrade was far less eventful as they for the most part were the same. Windows and OS X do many upgrades to their kernels through the products lifespan. Most of which do not result in breaking core functionality. The same cannot be said even on point releases on linux. This is what the video is more or less referring too. Even though for example Ubuntu 9.04 is what they consider a "major" upgrade the changes to it are relatively small then say a OS X 10.3 to 10.4 release or a XP to Vista release. I often think that linux would be much improved if they decided to draw the line somewhere as to what legacy hardware it supports. I'm not saying completely cut off that hardware from linux use but maybe have a legacy branch of the hardware (seriously do we really need ISA and support for products that have not been made for a better part of a decade in the mainline? Think how much easier maintenance would be without all that legacy code to worry about in the latest release ).
                      Numbering and naming, especially in linux, really has zero reflection on actual software change. I mean, in Ubuntu 9.10 we're probably going to have a new default file-system on a minor version number upgrade.

                      Again, do you have any references to back up your assertions?

                      Comment

                      Working...
                      X