Announcement

Collapse
No announcement yet.

Debating A Software Center For Fedora

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

  • #41
    Gajim (after the initial startup)
    Mmhm. I don't think Mercurial's a GUI app either.

    Comment


    • #42
      Originally posted by curaga View Post
      Mmhm. I don't think Mercurial's a GUI app either.
      Sorry, just listed common user-facing applications in Python.

      As for initial startup: this has more to do with PyGtk bindings rather than Python itself. Good news is that this will probably change in the future:
      http://gnomejournal.org/article/118/...ct-and-gnome-3
      And, as a nice side effect, with PyGObject we were able to address the terribly slow startup and memory usage of PyGtk applications.

      Comment


      • #43
        Thanks, now that I think about it, it's possible all python guis I've seen have been gtk.

        Comment


        • #44
          Perhaps a better option, rather than messing with linux distros individual ways of doing things would be to make Linux distros have out of the box android app support and was able to download any android app from any source online and run it and for linux software keep things as they are.

          Comment


          • #45
            Originally posted by curaga View Post
            Quite. So you're saying that to run a package manager applet, you need to have an i7 monster with more ram than hd?
            Indeed, I don't really believe your 486 can cut it anymore. Time for an upgrade.

            Also how you jumped from interpreted to C++ [you're right of course there, I'm mostly embedded]. But the jump from C++ to say python is more than from C to C++.
            You are aware that this very argument I made was common 10-15 years ago, right? C++ was the slow evil beast that no sane programmer would use, because HOLY BLOATED MOFO. And C was the slow beast 20 years ago in the ASM vs C holy wars.

            Did C and C++ suddenly become fast? No, they are as slow (compared to ASM) as they ever was. So what changed? Software complexity. Software has become so complex that the time you need to hand-optimize any moderately large project has become longer than the mean time between new-gen CPU releases. The trade-off is simply not worth it.

            Java, once considered slow and bloated, now powers half the world's smartphones. Ruby, PHP and Python, all slower than Java, power most of the web. A large part of scientific analysis is performed in Matlab - another slow, bloated language. Even embedded systems now run C# and, given, the choice, most sane people would prefer that over C provided it fits the power and performance profile (you'd be surprised how often it does).

            C++ is the COBOL of today. It will always exist, but at some point most people will consider as a painful memory of the dark ages.

            (Edit: Ubuntu Software Center should be optimized to startup faster. That's not done by rewriting in C but by improving the current code. Note that the update-manager is C and is almost as slow, which might point to a systemic problem.)
            Last edited by BlackStar; 11-29-2011, 11:06 AM.

            Comment


            • #46
              Did C and C++ suddenly become fast?
              No, the hw penetration became good enough that they became acceptable. Python and friends are not at that point yet, and probably will not be in years.

              The fact that Intel releases a new gen yearly has nothing to do with hw penetration. Using 1% or less of user base as an argument to be slow just doesn't cut it.

              Comment


              • #47
                Also, for your mobile Java mention, it's widely regarded as the reason Android UI is still laggy even on quad core phones.

                Comment


                • #48
                  Originally posted by Nevertime View Post
                  Perhaps a better option, rather than messing with linux distros individual ways of doing things would be to make Linux distros have out of the box android app support and was able to download any android app from any source online and run it and for linux software keep things as they are.
                  I'm all for that! The synergy would be huge and Linux popularity would skyrocket if people could create and distribute applications as easily as in the Android market!

                  But no Linux entity will even consider that option. Canonical wants to create its own smartphone and TVs (that noone sane will buy), Novell is dead, Red Hat has given app on the desktop and Google is not a Linux shop (it's got its own incompatible OS). Debian and Gentoo are their own little microcosms and don't really care for popularity (nor have the raw firepower to support such a project).

                  Still, too bad... It's a huge opportunity that will apparently remain untapped.

                  Comment


                  • #49
                    Originally posted by curaga View Post
                    Also, for your mobile Java mention, it's widely regarded as the reason Android UI is still laggy even on quad core phones.
                    Which is wrong, of course.

                    Comment


                    • #50
                      Originally posted by curaga View Post
                      No, the hw penetration became good enough that they became acceptable. Python and friends are not at that point yet, and probably will not be in years.
                      Python has been acceptable and widely used for more than a decade. It's one of the most popular languages right now. Claiming that CΡUs are not fast enough for Python is not only disingenuous, it is dead wrong.

                      The fact that Intel releases a new gen yearly has nothing to do with hw penetration. Using 1% or less of user base as an argument to be slow just doesn't cut it.
                      No? Oh, I forgot, you are the one with the 486. Don't mind me, carry on then.

                      Normal people refer to market penetration charts for CPUs and see what is actually in use today, check trends for the near future and design software to run on what people actually use. If you did that (and it's quite obvious you haven't) you'd see that Python, even Ruby, are quite acceptable for modern software - if they weren't, you can bet they wouldn't be quite as popular as they are.

                      Comment

                      Working...
                      X