Announcement

Collapse
No announcement yet.

Debating A Software Center For Fedora

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

  • Nevertime
    replied
    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.

    Leave a comment:


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

    Leave a comment:


  • OlegOlegovich
    replied
    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.

    Leave a comment:


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

    Leave a comment:


  • OlegOlegovich
    replied
    Originally posted by curaga View Post
    But I have yet to see one responsive python app.
    Gajim (after the initial startup), Mercurial, MyPaint or QuodLibet seem pretty responsive to me.

    Leave a comment:


  • curaga
    replied
    Yes, writing bad code can be done in any language. But I have yet to see one responsive python app. Ubuntu in particular loves to ship them.

    Leave a comment:


  • Veerappan
    replied
    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?

    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++.
    He doesn't come out and say it, but I'm pretty sure that he means to imply here that code maintainability and limited amounts of developer time are sometimes more important considerations than raw performance. Yes, the entire post was tongue-in-cheek, but I do agree with the sentiment behind it... Just because Java/C#/perl/etc have VM/interpreter overhead doesn't mean that we should abandon them entirely.

    In the case of GUI apps, it's entirely possible that responsiveness issues are more due to abuse of a (non-)threaded programming model than the language being used.

    Leave a comment:


  • curaga
    replied
    Originally posted by BlackStar View Post
    Also lol at those who believe that programmers are not lazy sons of bitches. Hint: we are. We cut corners whenever we can and we write inefficient corner if we can get away with it. If a program appears slow, it's your fault: get off your lazy ass and upgrade your hardware already.

    Do you know how freaking inefficient C++ is? How much overhead it has? We can make a program run 2-3x as fast by abandoning this bloated inefficient language in favor of raw assembly, but we are fucking lazy and don't do that.

    But if we did, you'd be fucking amazed at how much *faster* your button clicking would become. Those 2 second pauses you are talking about? They'd be fucking eliminated - but nooo, we just keep using stupid inefficient C++ stuff such as virtual functions (thrashing your L1 cache), exceptions (bloating the binaries and thrashing the L2 cache), new/delete/malloc/free (fragmenting memory) when we could, you know, just use lea eax, [eax] directly and bypass all this cruft.
    Quite. So you're saying that to run a package manager applet, you need to have an i7 monster with more ram than hd?

    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++.

    Leave a comment:


  • pvtcupcakes
    replied
    Originally posted by cl333r View Post
    Only a lier or a naive one would issue such statements. I'm talking about the fact that native/compiled apps which are usually written in C/C++/Vala a priori have speed advantages over python/ruby/whatever scripts for not having to run an additional VM/interpreter and not having to waste extra CPU cycles on dynamic compilation when running, not to mention other stuff. Before arguing make sure you understand what you're talking about and don't bring up cheap shots anymore please.
    Modern desktop CPUs are so powerful these days, that it's almost pointless to "optimize" most user applications. Unless you're doing some server or science-y stuff, then performance is basically a non issue for plain old GUI applications.

    If there is ever a pause in a GUI application, it's certainly caused by the developer doing something on the GUI thread that they shouldn't be. You can write C++ applications that freezes up the GUI by doing something like downloading a file over the Internet without creating a separate thread for it to run on.

    And I don't know what you're talking about with "cheap shot".

    Even Portage, the performance junkie's dream package manager on Gentoo is written in Python.
    So is Yum on Fedora/Red Hat.

    The Awesome window manager, which people go crazy over for being "lightweight" and "fast" is written in Lua.
    Last edited by pvtcupcakes; 27 November 2011, 08:52 PM.

    Leave a comment:


  • crazycheese
    replied
    Originally posted by leif81 View Post
    Windows doesn't have one and it seems to be doing alright...
    I never said windows is user friendly. It is, was and will be extremely user-hostile.
    If not its market position and hence monopoly over standards and as result - availability of software, windows would have died around OS/2 era already.
    The monopoly position was achieved by criminal efforts and hence windows is illegal by its nature.

    Leave a comment:

Working...
X