Announcement

Collapse
No announcement yet.

Ubuntu Developing Its Own Calculator, Calendar, Etc

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

  • #51
    Originally posted by DanLamb View Post
    I was hoping that Ubuntu and company would clean up their game development SDKs so that normal PC game developers could natively support Linux with a modest porting effort and not a huge rewrite porting effort.
    The problem is not complicated SDKs (SDL works just fine) but rather the dependence that many Windows game programmers have on DirectX. If they could get that working on Linux then great, but other than that one path your comment does not make a lot of sense. There is nothing odd about our SDKs that should scare away "normal" developers.

    Comment


    • #52
      Originally posted by BO$$ View Post
      Well maybe the C++ code was shit. That is why Java performance was close. I am writing a game engine in Java for Android. I have routines in Java that take 10 times more time to run than C++. Of course C++ allows for better control over memory (allocators etc) so the code written through JNI is not exactly equivalent to Java but the result is what matters. Sometimes C++ is over a magnitude faster than Java (in Android using Dalvik VM haven't tested on Hotspot). Python from what I read is even slower than Java and combined with the slow startup the fact that Software Center was written in Python just shows they were cutting costs, not thinking about usability. I actually use a VM language as a main weapon and I would really like if it was just as fast as C++ but right as of now, expertly written C++ code kicks Java's ass really bad. Why do you think that most game engines are written in C++?

      And JNI calls take time. Calling it in a tight loop kills performance. So I am expecting that the same thing is true in Python.
      As much as I love Java, I agree that it shouldn't be the preferred language for certain implementations like game engines (at least where it matters, i.e., not Minecraft). The JIT compiler can help but there's still overhead with the JVM and such.

      Of course Sun didn't design Java with the intention of making the best programming language for all use cases. Their primary motivation was a platform independent implementation that didn't require recompilation. I.e., it was designed to help them move hardware at a time when everyone was moving to Windows. It's why they took Microsoft to court for their non-standard Java VM. So I think in that sense the Java expectations should be tempered accordingly.

      I think Java for Android helps Google in the sense that they can easily target a variety of platforms (x86, ARMv7, ARMv8, etc.) and in theory they can even plug in different kernels without losing much of their software catalog. Though Google was smart to allow native applications for games and such. I believe there are only a few JNI hooks to worry about in those cases?

      Comment


      • #53
        Originally posted by BO$$ View Post
        Could it be that there is some serious overhead when calling C from Python?
        No this overhead is usually very small, its most likely the fact that they are searching the entire database of application listings to get the 10(or whatever amount it is) top listings. Python is not to blame here. Python uses C code to preform some of its core functionality the paths to calling C are quite optimised.

        Originally posted by BO$$ View Post
        It's like arguing that applications written in Swing Java look and are just as responsive as those written in C++.
        No its not if anything its would be like comparing to an application written with a SWT GUI in Java as SWT uses the JNI to call a thrid party NATIVE library to draw the GUI just like GTK in the software centre.
        Last edited by timothyja; 13 March 2013, 07:05 PM.

        Comment


        • #54
          Originally posted by BO$$ View Post
          And JNI calls take time. Calling it in a tight loop kills performance. So I am expecting that the same thing is true in Python.
          My point exactly you do no research or tests you just assume things then post them as if they are fact.

          The solution to your problem is to write the calling loop code in C also. Rather than blaming JNI you should be designing your application to limit the number of calls to the interface. As the old saying goes a good tradesman never blames his tools.
          Last edited by timothyja; 13 March 2013, 07:08 PM.

          Comment


          • #55
            Originally posted by TemplarGR View Post
            Google didn't betray their existing userbase(Desktop users) to target another entirely different userbase(smartphone users). And also, Google didn't create fragmentation in key parts of the Free software stack. They created something new.

            Canonical is evil, it is now official!
            canonical is betraying their userbase??? i doubt more than (if at all) 2% of the ubuntu userbase is sharing your opinion. most ubuntu users do not even care about such things.

            beside of that, i do not see why they are betraying anybody. i am do not like most of this changes or at least watch them happening with scepsis, but i do not feel betrayed. they neither owe me anything nor have they cut off my ability to use what i want ON ubuntu.

            considering what they did and we all linux users are profiting DUE to canonical it is unfair to talk everything down to such a level only because they also did some thing you do not like.

            i see a development of another display server as a very dangerous thing, but i totally can understand why they did it. i most probably would have done the same. they need to catch up fast onto a at least for now yet a new market. waiting for others, or hoping that teaming with others plays out is very risky when things have to go fast.
            looking at the recent past i wouldn't be willing takiung this risk, i would try to do many crucial things myself. seems canonical thought the same.
            if they can handle this is yet to be see. maybe they switch back to wayland when they see that this competition gave the needed kick in the ass to such projects (see recent statement about gnomes wayland support progresseion).

            yes, canonicals recent action are dangerous, for all linux-ers. but it has some valid (for canoncical) arguments.

            Comment


            • #56
              Originally posted by BO$$ View Post
              It's not my problem. I was just trying to find some possible reasons why Software Center starts so slow. You're arguing that it isn't python that it takes a lot of time to retrieve data from Canonical. I am saying that it takes a lot of time to load the window as in the main window. After it loads the window it takes another couple of seconds to load the data and display it. But the first 10 seconds I just sit and wait for the window to appear.
              The calls are not in a loop. No I'm not saying it takes a long time to retrieve that data. The data is stored locally the search is done locally. Its only updated later in the background.
              The search I'm talking about are done at load time its part of the reason why there is delay in the window appearing and is just sitting there when it does as it does not know what it should be drawing yet. The searches look at what should be shown in the "whats new" and "popular" tiles on default software centre window.
              There are other initilisation that are done at startup that add to this slowdown and I can remmeber the order off the top of my head but my point is that its not just Pythons fault its the devs who wrote the software centre did not optimise it very well. You can optimise code in Python (obviously not as much as C/C++) but like I'm saying its very easy to just blame the language rather than coding for speed.

              Originally posted by BO$$ View Post
              Good tradesman never blames his tools? What a moronic saying.
              Its a very good analogy for a lot of slow code and it looks like it hit a nerve. To spell it out for you in this situation it means if the tools are shit a good programmer can make the best out of a bad situation.
              Last edited by timothyja; 13 March 2013, 08:11 PM.

              Comment


              • #57
                Originally posted by BO$$ View Post
                Can you people please stop arguing how it's impossible to do something in Linux while that used to work just fine since Windows 1.0? Why is it always that taking 15 seconds to start an application and choppy mouse movement nobody's fault and should be accepted unquestioned? And don't get me started on listening to music while copying a file.....
                Of course this must be somebodies fault. But since I never experience any of the symptoms you describe, not even on my ancient netbook with slow 4GB SSD and 630MHz CPU I would assume that there is not a general problem here, but either a problem with your distribution, the software you use or your ability to configure your system correctly. May it be possible that you use one of those "we release all 6 months, regardless how many bugs there are" distros?

                Fun fact: All programs involved in my favorite distro's package management system are written in plain Bash. Nonetheless they react instantly to anything I throw at them, even on the slowest machine. So I really assume that there is something wrong at your end and that this is not a problem with Linux in general.

                Maybe a small hint to a way to solve your problems: You are not satisfied with the way your distro works? Well, you have at least two option:
                1. Switch to something that works as you want it to.
                2. IIRC, you are a programmer and Ubuntu is open source. Get your hands dirty and fix what you think is broken instead of complaining.
                Last edited by Vim_User; 13 March 2013, 08:10 PM.

                Comment


                • #58
                  Originally posted by BO$$ View Post
                  Can you people please stop arguing how it's impossible to do something in Linux while that used to work just fine since Windows 1.0? Why is it always that taking 15 seconds to start an application and choppy mouse movement nobody's fault and should be accepted unquestioned? And don't get me started on listening to music while copying a file.....
                  Urrrr .... are you talking to me here? I've never said nor would I say anything was impossible to do in Linux that works in Windows.
                  A 15 second startup to a program should be questioned why do you think I did some investigation and pointed out to the dev's part of the reason the software centre was so slow. If you actually looked at the bug you would have seen I already submitted a patch to Debian that would speed up part of the load time. 1.1 seconds down to 0.1 seconds. I've never said dont question things my problem is with pointing the blame at the wrong thing.

                  Debian patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689717

                  Edit: Like Vim_User said why not take a look into the load time issue yourself, I would even be happy to help out. I initially thought that issue was Python being slow too but when I actually took a look at the code it was clear that there are other factors slowing it down.
                  Last edited by timothyja; 13 March 2013, 08:44 PM.

                  Comment


                  • #59
                    I feel that things may go really really wrong sooner or later about these idiotic decisions, bad spirit and perverted politics.

                    Comment


                    • #60
                      Originally posted by BO$$ View Post
                      It's not my problem. I was just trying to find some possible reasons why Software Center starts so slow.
                      Bullshit, a blatant lie. You repeatedly and explicitly said that python was to blame.

                      Comment

                      Working...
                      X