Announcement

Collapse
No announcement yet.

Help me help Linux, tell me about Linux problems

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

  • #21
    One! Two! Three... here we go!

    I can name some ideas:
    1) Power Saving & reclocking for GPUs. Right now it is not perfect. For example, dynpm on AMD HD5xxx/HD6xxx GPUs works but fails to reclock GPU quickly so screen blinks and hence reclocking is disabled by default. Other powersave modes have some shortcomings as well. So virtially no distros dare to use these modes by default. There could be some other prob's but I only have Intel and AMD GPUs and Intel one is so low powered that I can't admit I have a problem even if it fails at powersave. In the ideal world I would expect GPUs to be reclocked as smooth and transparent to users as CPUs are being reclocked right now. In real world there seems to be some issues so far.

    2) OpenCL. This is probably quite interesting thing. There is work ongoing and it's set to land sooner or later. And it would be good if it happens sooner so Linux would pioneer in high-speed computing. This could be both good achievement and interesting thing if someone is inclined on dealing with unusual architectures and devices. And xorg even haves EVoC initiative for students.

    3) Better OpenGL support in opensource drivers could be handy as well. It's nice to catch up with proprietary drivers :-) (they're real nightmare to use)

    4) Btrfs... I think it's a future of file systems. Yet it definitely needs more work on it. While dealing with FS specifics could be not so easy and I don't know if there is lack of hands, it still would be cool if this one arrives in release shape a bit faster.

    Note: these problems are from user's point of view. I haven't contacted appropriate dev teams or whatever to check if they're seeking for new hands :P

    p.s. and of course, choose only what you would like to do yourself. That's the only way to make things enjoyable and release something good as the result.
    Last edited by 0xBADCODE; 10 June 2012, 01:40 PM.

    Comment


    • #22
      Originally posted by Alliancemd View Post
      What about SDL and Kowalski project?
      SDL and Kowalski don't support MP3, MOD, Ogg, MIDI, etc, etc, etc. They are core audio engines, not media+audio engines.

      In other words, if you were to code an FMOD alternative, you would use SDL or Kowalski (or both?) in order to do it.

      Comment


      • #23
        Right off hand the single biggest problem facing /Linux is deliberate downstream development breaks.

        For example: Debian(Ubuntu)'s forking of Debian(pure) and breaking both binary compatibility and tool-chain compatibility; and then failing to merge or submit changes back up into Debian(pure).

        The /Linux software ecosystem is also harmed by development cliques that may not have a purpose or a reason. To quote myself:

        As far as Linus's post goes, well, I have my own feelings on the Gnome project. From my perspective the Gnome project completed it's purpose long ago when Trolltech opened up the QT kit under a GPL license and established a foundation to look after QT. Ubersoft actually mocked this well over a decade ago: https://www.eviscerati.org/comics/co...ant-win-losing

        The current Gnome... clique... seems to have either lost sight of why Gnome was created to begin with, or just have no idea of Gnome's development roots and reason for existence. From my perspective the Gnome developers have never really gotten together and decided why they are doing what they are doing.

        This could explain why we, as in outsiders to the Gnome development,_ continue to see development on the basis of non-nonsensical ideas such as removing clutter or making this grandma friendly. I'm sorry if the Gnome Developers are offended by this, but their Human Interface Design group is full of something that smells a lot like excrement.

        I think realization that the Gnome developers really don't have a grasp on what Gnome is, or what is for, is starting to seep into some of the harder heads. As much as I dislike Canonical, they at least had the sense to start on something else. Granted, why Canonical didn't just drop Gnome, pull in KDE4, and then write their own Plasma-Interface to meet their UI requirements still eludes me. It would have been a much saner approach than trying to create a new GTK desktop from the ground up. Additionally it would have enabled Canonical to position Ubuntu to directly address a greater amount of downstream user-needs.

        As far as the ultimate design goals go... well... I'm sorry. Design by FisherPrice is not a good thing. Emphasis on single screen workflow is not a good thing. Specific to Gnome, I am in complete agreement with Linus. Relying on extensions to replace functionality that was included by default in previous versions is just... dumb. Really. Really. Dumb.

        I believe a point could also be made about the inablity of the Gnome or Canonical developers to consider previous usage patterns. When the KDE developers dropped the KDE3 codebase and worked on KDE4, early releases of KDE4 lacked features in the mature KDE3.x codebase. These features were not lacking because they were gone, they were lacking because they had not been rewritten and added back in. Somewhere around KDE4.4 or 4.5, the KDE4 desktop caught back up to the KDE3 functionality... and in the current KDE4.8 branch... completely blow KDE3's functionality out of the water... while... get this... still enabling users to use the KDE4 desktop exactly like they used the KDE3 desktop

        Both Gnome 3 and Canonical Unity seem to have no comprehension on how they can push their desktop experience forward while still enabling functionality and User-interface behavior for users who do not want any changes to their User-Experience.
        One of the advantages to Open-Source is that developers can do anything they want, work on any project they want. However, that advantage can ultimately cut both ways.

        Very good developers can work on projects that really should have been set aside over a decade ago when the project goal was completed. By the same token, developers that have no real business in open-source software can keep attracting attention despite their past actions that should have rendered then permanent persona-non-grata: case in point being perennial snake-oil salesman / conman, Con Kolivas.

        There also is a problem with /Linux press coverage. Many big-media journalists, such as those employed by the Associated Press or Reuters, are generally incompetent in reporting on GNU/Linux events. The press coverage is also cluttered by paid shills like Florien Mueller, or by outright liars and trolls like Matt Hartley. To pick on Phoronix for a moment, this site has a real bad habit of trying to push stories on ReiserFS or Mono... and really... respectably /Linux journalists should give either topic a wide berth. Not to put too fine a point on it, I really question the credibility of anybody who would report on Mono/C# as a _good_ thing or something worth looking at.

        Thankfully the GNU/Linux software ecosystem is large enough, and varied enough, to work around most problems.

        Comment


        • #24
          Originally posted by Saist View Post
          By the same token, developers that have no real business in open-source software can keep attracting attention despite their past actions that should have rendered then permanent persona-non-grata: case in point being perennial snake-oil salesman / conman, Con Kolivas.
          Dude, being an ass is not a good thing. He has done much more for desktop Linux then you ever will.

          Your personal war against Con has no place here. It's between you and him. No reason to flame him publicly. You're just being an ass here.

          Comment


          • #25
            FSF's List

            Have you seen the FSF's priority project list: https://www.fsf.org/campaigns/priority-projects/



            Out of those, I believe Reverse Debugging in GDB would help all development the most.

            From me:
            * I would like to see someone building Windows versions of software (Firefox, LibreOffice) with an open source compiler. Let's remove our need to use Microsoft's compiler at all. If you can make it faster to the point they can switch, then that would be great.
            * Help port major applications to newest libraries - GTK3, Python3, etc.

            Comment


            • #26
              1) Instead of around a hundred package formats there should be one. Not two not three just one. Why is it so hard to reach a consensus on this.

              2) Wayland can't come soon enough.

              3) Be more tolerant to proprietary software and drivers. No "Don't Be negative In The Freedom Dimension" kind of behavior.

              4) As with the package format just decide on one main toolkit. Offer the rest but have one single officially marketed and be the main toolkit for new developers to use. I don't even care which one it is as long as there is just one.

              Comment


              • #27
                Originally posted by Alliancemd View Post
                My coordinator(and me too) wants me to invent something or write an open source alternative to something proprietary which doesn't have an open source alternative(which I find VERY hard, every thing has an open source alternative).

                Not true. There is no open source alternative to OmniOutliner, for example.

                Outliners as a whole are a very unrepresented niche on Linux, especially when compared to what's available on OS X.

                OmniOutliner is a single-pane, multi-column outliner. Most Linux "outliners" are multipane, with a "treeview" in one pane representing the outline hierarchy and another pane containing the contents of the current node. Editing an outline in a multi-pane editor is not at all like editing one in a single-pane editor. See the series of articles at atpm.com for more information on this class of applications.

                Comment


                • #28
                  Not a snowball chance in the hell.

                  Originally posted by lgstoian View Post
                  1) Instead of around a hundred package formats there should be one. Not two not three just one. Why is it so hard to reach a consensus on this.

                  2) Wayland can't come soon enough.

                  3) Be more tolerant to proprietary software and drivers. No "Don't Be negative In The Freedom Dimension" kind of behavior.

                  4) As with the package format just decide on one main toolkit. Offer the rest but have one single officially marketed and be the main toolkit for new developers to use. I don't even care which one it is as long as there is just one.
                  And why someone would need yet another windows?
                  1) You can't force free people to go One Microsoft Way, because freedom implies availability of choice.
                  2) Agree, good thing. Though xorg is more developed and mature and some ppl are using it's networking features, etc.
                  3) Wrong. Just use windows, they're perfectly tolerant to this. But nobody needs yet another windows. You see, I use Linux because it's opensource drivers are better than proprietary and their support not depends on some corporate decisions.
                  4) <sarcasm> Oh yeah, just after forcing people to talk only one "proper" language, enforcing only one "proper" religion, one "proper" culture, one "proper" government and one proper way to live. </sacrasm>

                  As for me, you will be far easier using Windows. It matches your way of thinking better. And it's pointless to make another one if there is no differences. You can see ReactOS but it lacks momentum. Guess why. Nobody needs "just another Windows, opensource edition".
                  Last edited by 0xBADCODE; 10 June 2012, 03:19 PM.

                  Comment


                  • #29
                    On a serious note...

                    As for what's bad in Linux I can admit that:
                    1) Graphic subsystem still needs improvement:
                    - GPU reclocking and powersaving should be as smooth as it happens for CPUs these days.
                    - OpenCL in open dirvers really needed to enable many acceleration techniques (like GPGPU video decoding and image processing, etc).
                    - OpenGL still not on par with proprietary drivers (which are horrible, troublesome and have low quality).

                    2) I can admit it could be nice to get btrfs on wheels. Fast file system with snapshots, flexible disk space management and so on could be really good thing to add up.

                    Comment


                    • #30
                      Originally posted by Saist View Post
                      case in point being perennial snake-oil salesman / conman, Con Kolivas.
                      Kolivas is a quite competent programmer. He even coded his own bitcoin miner, quite popular in some circles and just a serious and opensource example of advanved OpenCL use and even more than that. He also known for BFS. While ideas behind BFS are debatable, some people seems to like these patches. And in fact his scheduler is better for 1-2 CPUs than Molnar's one. Sure, it wouldn't shine on 128-core CPUs but that would matter in future and/or only on some large servers. While he can have a point when it comes to desktop. It seems to be both a little faster and give a bit better latency on common desktops at the cost of ability to handle larger configurations adequately.

                      Comment

                      Working...
                      X