Announcement

Collapse
No announcement yet.

Debating A Software Center For Fedora

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

  • #31
    No major problems with Fedora's current system

    Originally posted by Tiger_Coder View Post
    I use Ubuntu/Kubuntu and Arch at home. Fedora at university labs. Fedora package management GUI just sucks. Many time even command line yum don't work for lock of packagekit with some unknown package manager(updater may be?). I mean I like fedora's stability, Gnome3 and developer friendliness. But you can all achieve that with a good package management front-end.
    I haven't experienced any problems with either yum, or the gui Software Update and Add/Remove Packages for years (apparently there is a bug in the just-released FC16 installer, requiring a double-reinstall of bash -- if you aren't already aware of it, and are totally inept with google, it could cause some head scratching).

    I don't like how packages are listed in Add/Remove Software though, by obscurely generic descriptive titles, rather than just by the actual package name (e.g., "A BitTorrent Client", rather than "Azeurus"). It could also do a better job of showing real-time progress info for download and installation (actually yum in the cli does a better job of it).

    I feel it's 95% there, you could just rename it "Software Centre" / "App Store" / whatever, if that seems a tad more au courant.

    Comment


    • #32
      Synaptic and apt have ports to RPM.

      That being said, they're poorly maintained and almost anything else is better, I prefer Yum but urpm (Mandriva/Mageia) isn't bad either.

      PCLinuxOS has issues, depending on an unmaintained port of Debian's package manager to their fork of Mandriva is but one of them.

      Comment


      • #33
        Lol at the usual trolls trying to turn a Fedora software center thread into a programming language war.

        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.

        In fact, that's the problem with synaptic. It's written in C, which is why it is so slow and bloated. That's also why it's now abandonware that hasn't received a proper update in half a decade. But what did you expect when its source code uses Bzr source control (python)? Good riddance, I say, apt-get is faster and more efficient.

        Comment


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


          At any rate, as someone who has been using Fedora as my primary system for nearly five years, I have not noticed any significant problems with package management. I started out using YumEX, which is okay and is still being maintained I believe, but quickly dumped it in favour of the command-line elegance of plain yum. And I have never looked back.

          The only real time I had any trouble was when we were still using Pirut, which was a piece of shit and locked down the system preventing one from using yum proper. Packagekit is fine and is becoming a growing standard, and in my experience is certainly better than synaptic, which in my limited use is clunkier and harder to use. But I still prefer command-line yum for most of my package management needs.

          Plus Fedora as far as I know is the only system that offers DeltaRPM's and yum presto, which does make my life a LOT easier sometimes, though I could be wrong and some other RPM based distros could have it too. I do know there is nothing in the DEB world like it.

          And I think a lot of people seem to be ignoring the idea that makes the USC popular and at the same time makes it incompatible with Fedora: the fact you can distribute paid apps through it. Fedora will (rightfully) not distribute any proprietary or patented code by default in its distribution, so do you really expect it to sell you closed-source commercial applications?

          And for the most part, the only paid apps people really would want sold through such a service on Linux are games (as the amount of commercial proprietary software your average Linux user uses that are not games could be counted using the fingers on one hand), so why not get Desura and be done with it? It runs fine on any distribution, you are not locked to a certain distro when you purchase something, it does not contain DRM, its client code is going to be released, and the Desura guys have a better shot at promoting our platform than the USC people ever could.

          Comment


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

            Comment


            • #36
              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; 11-27-2011, 07:52 PM.

              Comment


              • #37
                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++.

                Comment


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

                  Comment


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

                    Comment


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

                      Comment


                      • #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, 10:06 AM.

                                Comment

                                Working...
                                X