Announcement

Collapse
No announcement yet.

please provide more useful information

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

  • please provide more useful information

    Hello..

    In general i find that you test alot of hardware, mostly always stuff that is relevant to people, however, i sadly also find that your tests are almost always not very useful to people, or atleast me..

    the first example is with graphics cards, you provide lots of benchmarks, but more interresting information is compatibility and bugs, for instance you never seem to hit the countless of bugs people with ati experience, rendering the actual benchmark pointless, as we can not purchase based on your recommendations, as we do not know if the stuff really works, or what kinds of nasty issues we will run into.

    Secondly, and well, perhaps abit of an extension to the first, you write that you test with ubuntu and fedora for example, well, thats not really useful to people. Ubuntu is incredibly shaky, does all sorts of weird things.. For example, i have purchased a motherboard from gigabyte, which you said all pheripherals works out of the box with.. So i connect the system up, and find that they really do not (atleast not under !ubuntu). First thing thats weird is that audio doesent work at all the way its supposed to, i was able to mostly work around that though, but more annoyingly the two onboard realtek 8111c nic's are giving heaps of trouble.. on livecds with <2.6.25(aka all of them), only 1 nic works, the others thinks its fiber nic and detects no link.. when i boot into 2.6.25, both nic's work, but only if i enable either ONE of apic or msi.. not with both.. So PLEAASSEE test the hardware with VANILLA kernels on distributions which does _NO_ weird weird mystical stuff.. like slackware or gentoo or arch.. or at the very least compile your own kernels on these systems... otherwise your reviews are not worth much to us. Also, very useful information would be to attach dmesgs, lspci's, /proc/interrupts and such.. For instance, it took me about 2 months to find someone with a specific gigabyte motherboard that could show me /proc/interrupts, yet you had such a board, and could as easily as nothing have put this extremely useful (to me) information online.

    Dont get me wrong, i apreciate your work, but you could easily be very much more useful, with very little work.

  • #2
    Originally posted by Redeeman View Post
    So PLEAASSEE test the hardware with VANILLA kernels
    Most (new) Linux users never build their own kernel, they take
    whatever the distro thinks is appropriate. So just slapping a "standard" distro on the hardware make sense IMO, since this is
    what most people are going to do anyway (you and I who build and
    test bleeding edge -git/-mm kernels don't count as most people )

    I agree with the "more information please" bit; I too am mostly
    interested in dmesg, lspci and other hw info output, preferably
    from latest vanilla (-git) kernels with all funky and new features enabled. (I still miss the phoronix hardware database...)

    Comment


    • #3
      but why only cater to new linux users? besides, at some point alot of them are going to want to do more, for some reason, and then they might very well hit trouble.

      also, even if they do use ubuntu for example, then they might well loose hardware support at the next ubuntu, as ubuntu suffers enormously from the fact that whatever "magic" they do to make these things "work", very often changes to the next release, leaving people stranded. A garantuee that the hardware works with inkernel vanilla drivers is a very very useful thing.

      Comment


      • #4
        New users shouldn't be excluded due to complexity. The vast majority of the users of Linux could fall under your classification of 'new users'.

        Why use Slackware, Gentoo etc when the vast majority of the people using Linux are using Fedora/Redhat, SuSE, Mandriva etc? Yes, you may well say that Gentoo etc, use the 'vanilla' kernels, but you optimise the kernels when you compile them, so they are not really 'vanilla' any more are they?

        More people are going to find the reviews of Fedora or Ubuntu useful than a review using slackware. Unfortunately, that is the way mass media works. If you want Slackware reviews, you could always review some hardware yourself...

        With respect to your question about dmesg's, lspci's etc, how much information would you deem enough. Last time I looked my dmesg file was 433 lines long. What else would you like to see? strace outputs? How much detail is enough? I know, I'm getting ridiculous, but, my point is that the level of detail you are asking for would drive the average 'new' linux user away from a very useful resource. I've been using linux for 8 years now, and I find trawling though dmesg files slightly tedious on my own system, let alone someone else's. As for /proc/interrupts, well, I can only guess at what information is being shown there. How many times would you like Phoronix to explain what each line is for before you complain that this is 'noob' stuff and isn't needed?

        Sorry if this appears to be a rant. In a way it is, but I'm hoping that you are beginning to see my point. The level of detail may be a bit basic, sometimes even for me, but they have to cater to the 'new user' masses, not the 'uber-geeks' like yourself .

        Oh, I have tried to compile my own kernel (using CentOS 4 as the starting point...) but it failed miserably. Probably because of my starting point.

        I hope you understand what I'm getting at, and also understand that I'm not getting at you personally.

        Andy

        P.S. I actually don't like Ubuntu. I find it annoying to use and a little bit too simple, even for me...
        Last edited by Shielder; 10 April 2008, 08:22 AM.

        Comment


        • #5
          Originally posted by Shielder View Post
          With respect to your question about dmesg's, lspci's etc, how much information would you deem enough. Last time I looked my
          dmesg file was 433 lines long
          Just the usual driver outputs-- you know, build a kernel without
          all the debug stuff, boot it, load all drivers relevant for the
          system. dmesg shouldn't be more than 300-400 lines
          at most. A link to the info somewhere at the end of the article
          is enough.


          What else would you like to see? strace outputs?
          Don't be silly, strace has nothing to do with hardware, so
          it's uninteresting ;-)
          EDIT: maybe the BIOS' DSDT? I'm especially interested in DSDT's of Sony laptops with ambient light sensors

          Comment


          • #6
            I did say I was being ridiculous. But my point stands. Phoronix have only a finite amount of space in which to post the article, so they have to target certain sections of the readership. Unfortunately, those sections are not the more technically minded ones.

            Yes, links to the log file would be useful, but that also takes space and bandwidth.

            I do see the OPs point, and I agree with it (strangely enough) but I can also see the problems that this would cause to Phoronix and the extra effort, time and cost it would cause, just for a relatively small (but growing) section of the readership. I would like to get more involved in the more technical side of linux (I do indeed wnat to do more Redeerman) but I just haven't got the time at the mo.

            Andy

            Comment


            • #7
              At least the dmesg/lspci/lsusb/... stuff could be made part of the
              Phoronix Test Suite (even if the info comes from a crappy ubuntu kernel). Those text files probably consume less space than a single picture of the hardware

              Comment


              • #8
                Originally posted by mlau View Post
                At least the dmesg/lspci/lsusb/... stuff could be made part of the
                Phoronix Test Suite (even if the info comes from a crappy ubuntu kernel).
                It will be part of the suite.
                Michael Larabel
                https://www.michaellarabel.com/

                Comment


                • #9
                  #4 shielder:

                  you completely misunderstand me, i am NOT saying to exclude new users, not at all, i am merely asking for more information which benefits people that may not be new users, but it does not hurt new users in any way..

                  something like dmesg, lspci, interrupts etc can easily be attached or even uploaded to some file listing dir, and that should not bother ANYONE, and if it does, something is wrong with them.

                  and btw, about kernels: i do no optimization beyond what the kernel does.. and as long as i dont patch my kernel, its still vanilla.

                  #5 mlau:
                  yeah exactly, just a link to these ressources, im not saying/expecting/requesting that the information be put on front page, just a link to the files with this information, it could even be packaged up in a tarball..

                  #6 shielder:
                  i hardly think phoronix lacks the space to link to a tarball with this information, nor the storage space to hold it... and if they do, ill gladly contribute this..

                  #8:
                  please also include /proc/interrupts as it is very useful..

                  Comment


                  • #10
                    As I said above, I agree with you. But finding the right level of detail that will suit everyone is hard. Phoronix had decided to provide basic information. With the new test suite, they have the capability to provide more information in a standard format.

                    I actually think it is a good idea, presenting it in a way that many people can understand is going to be the hard bit.

                    You are right in that I misunderstood your point. Sorry if I got the wrong end of the stick.

                    Andy

                    Comment

                    Working...
                    X