What would you fix in Linux? - Linux

This is a discussion on What would you fix in Linux? - Linux ; This is probably going to open a large 55-gallon drum of worms, but I'm curious. Linux (or a Linux distro, more properly) has many problems (most of them minor compared to certain other solutions), and some of them are rather ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 26

Thread: What would you fix in Linux?

  1. What would you fix in Linux?

    This is probably going to open a large 55-gallon drum of
    worms, but I'm curious.

    Linux (or a Linux distro, more properly) has many problems
    (most of them minor compared to certain other solutions),
    and some of them are rather obvious, at least to me.

    1. Sound continues to be a minor sore point for me,
    though I'll admit it works for the most part when I'm not
    using composition tools such as Rosegarden. Rosegarden,
    however, is tricky; the requirements include jackd and
    fluidsynth (though there are a few other tools that can
    replace it) if one wants to generate actual sound from it.
    I'd like to see this process simplified, or at least
    explained sufficiently so that any n00b who's never heard
    of MIDI or sequencers can at least get something out.
    It's confusing me, the interrelationships between all
    three of these tools.

    To be fair, Rosegarden is perfectly usable without sound,
    if all one wants to do is compose sheet music. But I'm
    not Beethoven. ;-) Nor am I all that happy about the
    synthesizer waveforms, which apparently change every year;
    a composition which sounded nice under one set of conditions
    can sound horrible under another. I should note, however,
    that this is an *improvement* over certain games which are
    now so old they creak -- and can no longer run on hardware
    that can't emulate good old Soundblaster, IRQ 5, DMA 1,
    or some of its descendants.

    2. Video is interesting, and continues to get more
    interesting. In particular, X now has the ability to
    change resolutions, and SDL has had "full screen mode"
    for awhile. They could coordinate a little better, at
    least on my system -- perhaps it's a config thing, but my
    homegrown SDL application that goes full screen leaves X
    at the wrong resolution when it goes back. Not sure where
    that bug is hiding, frankly -- or whether X should compensate
    for bad programming on my part. A "nice to have".

    3. OpenGL could go across the network somehow. As one
    should already know, 'ssh -CXY' is a transparent X tunnel,
    but OpenGL cannot fit through that tunnel. While the
    usefulness of OpenGL across the network is debatable
    (there are better ways), it would be a "nice to have".

    4. Internally, Java's a bit of a mess -- not because it's
    not a capable solution, but because it's a bit hard to
    monitor. Briefly put, Java tends to gobble up memory from
    the OS and never return it back when it no longer needs it.
    While this unused memory can be swapped out (if one has
    sufficient swapspace), it would ideally just be returned
    back to the OS, for other, non-Java, processes to use.
    Whether this is even *possible* without major modifications
    to the JVM's subsystem or to libc is not clear to me; Amiga
    had free(), which never released RAM but is very portable,
    and FreeMem(), which is an AmigaOS-specific function
    which gives RAM back to anyone who needs it. Of course
    done sloppily one runs into fragmentation problems, which
    suggests we should only release RAM back to the OS in
    page-sized chunks, and make apporpriate modifications to
    malloc() to request page-sized chunks as opposed to using
    sbrk(); the double free() I consider a horrid anachonism.

    Java also has issues with open files; they don't get
    garbage collected. Of course one might quibble that
    open files should be explicitly closed anyway.

    5. I have no idea how we do this nicely, but I had to
    resolve Yet Another Broken Library Dependency on Gentoo.
    Gentoo may be unique in this issue but ddd for some reason
    depended on libXm.so.3 instead of libXm.so. Perhaps that's
    intentional, but a subsequent update, presumably of libXm,
    broke that dependency. I don't see this being unique to
    Gentoo, either; Gentoo reduces it but cannot possibly
    eliminate it, as what I suspect happened was along the
    lines of:

    libXm.so.3 built
    ddd built using libXm.so.3
    libXm.so.3 -> libXm.so.4 upgrade
    ddd now broken

    Gentoo does provide revdep-rebuild, to help in such cases. I
    don't know what other distros have, and for other distros it
    might be a touch simpler, since they don't have to compile
    from source. I don't see other distros being invulnerable
    to this issue.

    For its part revdep-rebuild could be a little faster, though
    part of that is simply that it has to scan through all of the
    executables and dlls it knows about -- and on my system,
    there are a lot of executables and dlls.

    6. The entire autogen/autotools/libtools/configure
    could be explained nicely somewhere. I'd love to build
    internationalizable, portable tools, but it's all Greek
    to me. Hopefully something on gnu.org can handle this one.

    7. I'll admit to some curiosity as to how to set up a
    standardized method (RPM?) to allow a non-superuser to
    install software, with a password prompt for him to become
    superuser. I would hope this is partially already done,
    and furthermore that the installation process pulls in
    (or brings up a request) for other RPMs as the dependency
    tree is searched. It is not clear to me whether the
    application developer or the distro manager be responsible
    for dependencies; one could make a case either way.
    The issue is further complicated by Gentoo and Debian,
    which have .ebuild and .deb files, respectively, plus other
    distros which are non-RPM based. All this suggests that
    distros have well-lit paths, but outside of those paths,
    it's a bit of a jungle -- though with /usr/local one can
    at least prune the worst of the branches into a somewhat
    manageable topiary.

    8. 'find . -name blah.blah' is a bit silly, though it works
    well enough if combined with other qualifiers. Ideally,
    though, one would have an equivalent to slocate which would
    be intelligent enough to search a filesystem *by name*
    (as opposed to by path). Such is possible on MacOSX,
    at least in theory. Of course multiple paths might be
    returned in some cases -- especially if someone's silly
    enough to 'namefind .keep' on a Gentoo system (.keep being
    used as a sort of marker to ensure important directories
    don't inadvertantly vanish). Certain regular expressions
    would be doable with a btree ("blah.*" is easy enough,
    though "*.blah" might have some issues).

    9. I'll admit to wondering whether the first few bytes
    of the file should be stored in the inode. Such appears
    to be the case in Microsoft's "MFS", which doesn't work
    all that well, but it would make finding magic numbers a
    bit easier. Of course if one can guarantee that the first
    data block is within the same cylinder as the inode, that
    might be sufficient -- though how one guarantee that when
    the interface card lies like a rug to the OS, and the disk
    lies to the card, is far from clear. (The reasons relate
    to that good old 10-bit cylinder addressing limitation.
    We'll be living with these issues for awhile, methinks,
    and the variable geometry most drives have doesn't
    help either -- though does make storage more efficient.
    Perhaps it will cease to be an issue when everyone switches
    to non-spindle-based flash RAM.)

    10. Somehow, someway, Linux needs to find its way and its
    niche. Briefly, Linux has no set direction -- this may not
    be a bad thing, but that doesn't mean it'll get anywhere.
    It has found a nice hiding place in the server arena, but
    FreeBSD has notions (and may be a better fit for some);
    also, Microsoft is an excellent server solution for those
    who can afford to buy it, the hardware hosting it, and the
    surrounding technology/software to keep the viruses out.

    Perhaps I'm being overly harsh in some areas, and missing
    others completely (I use older hardware, for example,
    and have no idea about the newfangled gizmos). In any
    event, opinions welcome, relevant comments tolerable,
    inanity generally ignored, flames routed to /dev/null, etc. ;-)

    --
    #191, ewill3@earthlink.net
    Useless C++ Programming Idea #110309238:
    item * f(item *p) { if(p = NULL) return new item; else return p; }
    ** Posted from http://www.teranews.com **

  2. Re: What would you fix in Linux?

    The Ghost In The Machine wrote:
    > This is probably going to open a large 55-gallon drum of
    > worms, but I'm curious.
    >
    > Linux (or a Linux distro, more properly) has many problems
    > (most of them minor compared to certain other solutions),
    > and some of them are rather obvious, at least to me.


    tl;dr Wireless support and troubleshooting, but things like this are
    being worked on all the time.

    Also, decent games.

  3. Re: What would you fix in Linux?

    On Tue, 27 May 2008 14:47:15 -0700, The Ghost In The Machine wrote:

    > This is probably going to open a large 55-gallon drum of worms, but I'm
    > curious.
    >

    (snip)
    >
    > 7. I'll admit to some curiosity as to how to set up a standardized
    > method (RPM?) to allow a non-superuser to install software, with a
    > password prompt for him to become superuser.


    sudo, and it can be a security nightmare.

    (snip)
    >
    > 10. Somehow, someway, Linux needs to find its way and its niche.
    > Briefly, Linux has no set direction -- this may not be a bad thing, but
    > that doesn't mean it'll get anywhere.


    Of course "Linux" doesn't have a direction. Neither does Microsoft or
    Apple, but at least Windows has Microsoft, and Apple has OS X. There is
    no one entity deciding the direction for OSS.


    > It has found a nice hiding place in the server arena,


    Yes, it has. It has also found found its place on my business and
    personal desktops.

    Hmmm ... note to self... try gain to get the admin to switch from W2k to
    PCLOS or Ubuntu ....

    > but FreeBSD has notions (and may be a better fit
    > for some); also, Microsoft is an excellent server solution for those who
    > can afford to buy it, the hardware hosting it, and the surrounding
    > technology/software to keep the viruses out.


    Why should they go out any pay so much more when they can use OSS?

    >
    > Perhaps I'm being overly harsh in some areas, and missing others
    > completely (I use older hardware, for example, and have no idea about
    > the newfangled gizmos). In any event, opinions welcome, relevant
    > comments tolerable, inanity generally ignored, flames routed to
    > /dev/null, etc. ;-)


    ... and you' get some flames... :-)

    --
    Rick

  4. Re: What would you fix in Linux?

    "Rick" stated in post
    -umdnf4vTrDwo6LVnZ2dnUVZ_qninZ2d@supernews.com on 5/29/08 4:38 PM:

    > On Tue, 27 May 2008 14:47:15 -0700, The Ghost In The Machine wrote:
    >
    >> This is probably going to open a large 55-gallon drum of worms, but I'm
    >> curious.
    >>

    > (snip)
    >>
    >> 7. I'll admit to some curiosity as to how to set up a standardized
    >> method (RPM?) to allow a non-superuser to install software, with a
    >> password prompt for him to become superuser.

    >
    > sudo, and it can be a security nightmare.
    >
    > (snip)
    >>
    >> 10. Somehow, someway, Linux needs to find its way and its niche.
    >> Briefly, Linux has no set direction -- this may not be a bad thing, but
    >> that doesn't mean it'll get anywhere.

    >
    > Of course "Linux" doesn't have a direction. Neither does Microsoft or
    > Apple, but at least Windows has Microsoft, and Apple has OS X. There is
    > no one entity deciding the direction for OSS.
    >
    >
    >> It has found a nice hiding place in the server arena,

    >
    > Yes, it has. It has also found found its place on my business and
    > personal desktops.


    Personal desktops... not in any meaningful way. The desktop is the *only*
    area Linus is concerned with and yet Linux is still less than 1% by all
    reasonable reports *and* it is free... and as you have said

    Millions have formatted a disk and installed Linux without problems.

    Sadly those who download it clearly are not sticking with it. Linux is just
    not ready for the desktop.

    > Hmmm ... note to self... try gain to get the admin to switch from W2k to
    > PCLOS or Ubuntu ....
    >
    >> but FreeBSD has notions (and may be a better fit
    >> for some); also, Microsoft is an excellent server solution for those who
    >> can afford to buy it, the hardware hosting it, and the surrounding
    >> technology/software to keep the viruses out.

    >
    > Why should they go out any pay so much more when they can use OSS?


    Because, perhaps, they are wise enough not to equate purchase price with
    overall price.

    >> Perhaps I'm being overly harsh in some areas, and missing others
    >> completely (I use older hardware, for example, and have no idea about
    >> the newfangled gizmos). In any event, opinions welcome, relevant
    >> comments tolerable, inanity generally ignored, flames routed to
    >> /dev/null, etc. ;-)

    >
    > .. and you' get some flames... :-)
    >




    --
    Computers are incredibly fast, accurate, and stupid: humans are incredibly
    slow, inaccurate and brilliant; together they are powerful beyond
    imagination. - attributed to Albert Einstein, likely apocryphal


  5. Re: What would you fix in Linux?

    On May 30, 7:32 am, Cork Soaker wrote:
    > The Ghost In The Machine wrote:
    >
    > > This is probably going to open a large 55-gallon drum of
    > > worms, but I'm curious.

    >
    > > Linux (or a Linux distro, more properly) has many problems
    > > (most of them minor compared to certain other solutions),
    > > and some of them are rather obvious, at least to me.

    >
    > tl;dr Wireless support and troubleshooting, but things like this are
    > being worked on all the time.
    >
    > Also, decent games.


    Not possible. Even with cedega you still have only a handful of games
    to play (officially supported).

    The linux gaming market is too small, and the OS environment isn't
    friendly to games - except for nividia's, no other gfx card can
    guarantee anything, not even full 2D acceleration.

  6. Re: What would you fix in Linux?


    "The Ghost In The Machine" wrote in message
    news:34cug5-d7d.ln1@sirius.tg00suus7038.net...
    > This is probably going to open a large 55-gallon drum of
    > worms, but I'm curious.
    >
    > Linux (or a Linux distro, more properly) has many problems
    > (most of them minor compared to certain other solutions),
    > and some of them are rather obvious, at least to me.
    >
    > 1. Sound continues to be a minor sore point for me,
    > though I'll admit it works for the most part when I'm not
    > using composition tools such as Rosegarden. Rosegarden,
    > however, is tricky; the requirements include jackd and
    > fluidsynth (though there are a few other tools that can
    > replace it) if one wants to generate actual sound from it.
    > I'd like to see this process simplified, or at least
    > explained sufficiently so that any n00b who's never heard
    > of MIDI or sequencers can at least get something out.
    > It's confusing me, the interrelationships between all
    > three of these tools.
    >
    > To be fair, Rosegarden is perfectly usable without sound,
    > if all one wants to do is compose sheet music. But I'm
    > not Beethoven. ;-) Nor am I all that happy about the
    > synthesizer waveforms, which apparently change every year;
    > a composition which sounded nice under one set of conditions
    > can sound horrible under another. I should note, however,
    > that this is an *improvement* over certain games which are
    > now so old they creak -- and can no longer run on hardware
    > that can't emulate good old Soundblaster, IRQ 5, DMA 1,
    > or some of its descendants.
    >
    > 2. Video is interesting, and continues to get more
    > interesting. In particular, X now has the ability to
    > change resolutions, and SDL has had "full screen mode"
    > for awhile. They could coordinate a little better, at
    > least on my system -- perhaps it's a config thing, but my
    > homegrown SDL application that goes full screen leaves X
    > at the wrong resolution when it goes back. Not sure where
    > that bug is hiding, frankly -- or whether X should compensate
    > for bad programming on my part. A "nice to have".
    >
    > 3. OpenGL could go across the network somehow. As one
    > should already know, 'ssh -CXY' is a transparent X tunnel,
    > but OpenGL cannot fit through that tunnel. While the
    > usefulness of OpenGL across the network is debatable
    > (there are better ways), it would be a "nice to have".
    >
    > 4. Internally, Java's a bit of a mess -- not because it's
    > not a capable solution, but because it's a bit hard to
    > monitor. Briefly put, Java tends to gobble up memory from
    > the OS and never return it back when it no longer needs it.
    > While this unused memory can be swapped out (if one has
    > sufficient swapspace), it would ideally just be returned
    > back to the OS, for other, non-Java, processes to use.
    > Whether this is even *possible* without major modifications
    > to the JVM's subsystem or to libc is not clear to me; Amiga
    > had free(), which never released RAM but is very portable,
    > and FreeMem(), which is an AmigaOS-specific function
    > which gives RAM back to anyone who needs it. Of course
    > done sloppily one runs into fragmentation problems, which
    > suggests we should only release RAM back to the OS in
    > page-sized chunks, and make apporpriate modifications to
    > malloc() to request page-sized chunks as opposed to using
    > sbrk(); the double free() I consider a horrid anachonism.
    >
    > Java also has issues with open files; they don't get
    > garbage collected. Of course one might quibble that
    > open files should be explicitly closed anyway.
    >
    > 5. I have no idea how we do this nicely, but I had to
    > resolve Yet Another Broken Library Dependency on Gentoo.
    > Gentoo may be unique in this issue but ddd for some reason
    > depended on libXm.so.3 instead of libXm.so. Perhaps that's
    > intentional, but a subsequent update, presumably of libXm,
    > broke that dependency. I don't see this being unique to
    > Gentoo, either; Gentoo reduces it but cannot possibly
    > eliminate it, as what I suspect happened was along the
    > lines of:
    >
    > libXm.so.3 built
    > ddd built using libXm.so.3
    > libXm.so.3 -> libXm.so.4 upgrade
    > ddd now broken
    >
    > Gentoo does provide revdep-rebuild, to help in such cases. I
    > don't know what other distros have, and for other distros it
    > might be a touch simpler, since they don't have to compile
    > from source. I don't see other distros being invulnerable
    > to this issue.
    >
    > For its part revdep-rebuild could be a little faster, though
    > part of that is simply that it has to scan through all of the
    > executables and dlls it knows about -- and on my system,
    > there are a lot of executables and dlls.
    >
    > 6. The entire autogen/autotools/libtools/configure
    > could be explained nicely somewhere. I'd love to build
    > internationalizable, portable tools, but it's all Greek
    > to me. Hopefully something on gnu.org can handle this one.
    >
    > 7. I'll admit to some curiosity as to how to set up a
    > standardized method (RPM?) to allow a non-superuser to
    > install software, with a password prompt for him to become
    > superuser. I would hope this is partially already done,
    > and furthermore that the installation process pulls in
    > (or brings up a request) for other RPMs as the dependency
    > tree is searched. It is not clear to me whether the
    > application developer or the distro manager be responsible
    > for dependencies; one could make a case either way.
    > The issue is further complicated by Gentoo and Debian,
    > which have .ebuild and .deb files, respectively, plus other
    > distros which are non-RPM based. All this suggests that
    > distros have well-lit paths, but outside of those paths,
    > it's a bit of a jungle -- though with /usr/local one can
    > at least prune the worst of the branches into a somewhat
    > manageable topiary.
    >
    > 8. 'find . -name blah.blah' is a bit silly, though it works
    > well enough if combined with other qualifiers. Ideally,
    > though, one would have an equivalent to slocate which would
    > be intelligent enough to search a filesystem *by name*
    > (as opposed to by path). Such is possible on MacOSX,
    > at least in theory. Of course multiple paths might be
    > returned in some cases -- especially if someone's silly
    > enough to 'namefind .keep' on a Gentoo system (.keep being
    > used as a sort of marker to ensure important directories
    > don't inadvertantly vanish). Certain regular expressions
    > would be doable with a btree ("blah.*" is easy enough,
    > though "*.blah" might have some issues).
    >
    > 9. I'll admit to wondering whether the first few bytes
    > of the file should be stored in the inode. Such appears
    > to be the case in Microsoft's "MFS", which doesn't work
    > all that well, but it would make finding magic numbers a
    > bit easier. Of course if one can guarantee that the first
    > data block is within the same cylinder as the inode, that
    > might be sufficient -- though how one guarantee that when
    > the interface card lies like a rug to the OS, and the disk
    > lies to the card, is far from clear. (The reasons relate
    > to that good old 10-bit cylinder addressing limitation.
    > We'll be living with these issues for awhile, methinks,
    > and the variable geometry most drives have doesn't
    > help either -- though does make storage more efficient.
    > Perhaps it will cease to be an issue when everyone switches
    > to non-spindle-based flash RAM.)
    >
    > 10. Somehow, someway, Linux needs to find its way and its
    > niche. Briefly, Linux has no set direction -- this may not
    > be a bad thing, but that doesn't mean it'll get anywhere.
    > It has found a nice hiding place in the server arena, but
    > FreeBSD has notions (and may be a better fit for some);
    > also, Microsoft is an excellent server solution for those
    > who can afford to buy it, the hardware hosting it, and the
    > surrounding technology/software to keep the viruses out.
    >
    > Perhaps I'm being overly harsh in some areas, and missing
    > others completely (I use older hardware, for example,
    > and have no idea about the newfangled gizmos). In any
    > event, opinions welcome, relevant comments tolerable,
    > inanity generally ignored, flames routed to /dev/null, etc. ;-)




    An argument of anything said is "and who's going to enforce that" or "and
    who's going to force people to follow these suggestions." Which brings me to
    the first improvement - Central Leadership and authority. There are
    maintainers of key parts like the kernel for example but there is nothing to
    stop or prevent someone from taking a part of linux (like the kernel) and
    morphing it into something that isn't compatible with the mainstream. Take
    the linux/unix filesystem for example. You'd think that the directory
    layout, names and purposes would be standardized by now. But it's not.

    Without Central Leadership and authority there is bound to be a lack of
    organization. And it shows. Imagine a company with no managers or bosses.
    Everyone simply comes in and does whatever they feel like doing. Hardly a
    recipe for success. And in linux you have what... a dozen different "package
    managers" and things like that. How many different sound systems are there,
    and how about just one "standard" version that works. Everyone is out there
    reinventing their own version of the wheel over and over again.

    Next item - A sensible way to upgrade. The package managers (sudo apt-get
    update/upgrade) works but not really. Say that I want to update my install
    of squid or samba. Okay... the binary files get updated. But what about the
    configuration settings. Why aren't those upgraded? The user is stuck with
    one of two options. Either completely overwrite their config settings with
    the latest file from the installer thereby losing all of the changes they
    made. Or the 2nd option is to keep their config file in which case they
    don't get any of the settings from the new version they just installed.
    Manually "merging" the existing config file with the new one is not a
    solution.

    Next item - (But only quickly). The quality of the installer varies too much
    from distro to distro. Windows comes pre-installed so it's not a fair
    comparison. But there's no reason why some linux installers are so much
    worse than others. While not as bad as it used to be, there's still to many
    times where linux gets installed, the computer reboots and the user gets a
    cryptic message from grub (ie - system now hosed for non-techies) or X
    refuses to start and the user gets dumped into a console with a login
    prompt.

    Next item - Weak laptop support. The two killer items here are hibernation,
    power management and wireless support. All the excuses in the world about
    manufacturers not making their design public to the linux community don't
    matter one single bit to the average user when this stuff doesn't work.

    Next item - Accessible and usefull documentation isn't there yet. The
    quality and style of documentation varies way too much from distro to distro
    and from application to application.

    Next item - Too much reliance on the command line. Not a problem for geeks
    and gurus but not a solution for common everyday people.

    Next item - Support for the latest hardware. Because some linux supports
    some SCSI adapter from 1993 isn't comforting to the guy who just bought a
    new laptop and finds out that linux won't support the built-in wireless,
    built-in webcam or fingerprint reader. Spending 20 hours searching the web
    for a solution and then downloading, compiling, installing and configuring a
    bunch of stuff that "might work" is not an answer.

    Next item - Too much diversity. Freedom of choice, diversity, blah-blah-blah
    is all nice and good in theory. But I use linux "enough" and have had
    problems. The typical scenario goes something like this: Search the web for
    "my problem" and get a bunch of hits. Find a hit where someone had the same
    problem and read the solution. Try using the solution to fix my problem. But
    it doesn't work. The same apps aren't there, the same config-settings aren't
    there and everything is "kind-of" the same but at the same time mostly
    different. Oh wait... that solution is for Ubuntu but I'm running SuSE.

    Okay, so next I find someone who had the problem on SuSE (and not Fedora, or
    Mandriva or PCLinux-OS). I try the solution suggested to them and once
    again... it's almost the same but not what I have. Oh wait... this solution
    is for SuSE 10.0 and I have SuSE 10.3 with a different version of kerberos
    and different version of samba.

    The matrix of X-many different incompatible distros multiplied by X-many
    different releases is too large. What works for one release of a certain
    distro at a certain version doesn't work for another. Finding the "right
    solution" for a particular problem can sometimes be like looking for a
    needle in a haystack.

    Next item - Installing applications. Great when it works. But when it
    doesn't.... (shhhhh - we can't acknowledge that here.) Too many applications
    need to be built or compiled. But there are dependencies on other things and
    it can quickly become a mess. Great when it works. Total chaos when it
    doesn't.

    Next item - File system too complicated. We have /bin, /sbin, /usr/bin,
    /usr/sbin, /lib, /usr/lib, /var, /var/lib and various other places where a
    file "might be." One distro stores files in one place but another distro
    stores files somewhere else and another version of the same distro may store
    files elsewhere. Clean up this mess. (Yeah... I'm talking to *you*.)






    ** Posted from http://www.teranews.com **

  7. Re: What would you fix in Linux?


    "The Ghost In The Machine" wrote in
    message news:34cug5-d7d.ln1@sirius.tg00suus7038.net...
    > This is probably going to open a large 55-gallon drum of
    > worms, but I'm curious.
    >
    > Linux (or a Linux distro, more properly) has many problems
    > (most of them minor compared to certain other solutions),
    > and some of them are rather obvious, at least to me.
    >



    Not so much in the actual code base of the kernel... but in userland I would
    eliminate all efforts of support windows based applications. WINE and MONO
    come to mind, almost immediately. They both should just... go away.


    --

    Jerry McBride (jmcbride@mail-on.us)

  8. Re: What would you fix in Linux?


    "Jerry McBride" wrote in message
    news:9kg6h5x7n.ln2@supertux.my.domain...
    >
    > "The Ghost In The Machine" wrote in
    > message news:34cug5-d7d.ln1@sirius.tg00suus7038.net...
    >> This is probably going to open a large 55-gallon drum of
    >> worms, but I'm curious.
    >>
    >> Linux (or a Linux distro, more properly) has many problems
    >> (most of them minor compared to certain other solutions),
    >> and some of them are rather obvious, at least to me.
    >>

    >
    >
    > Not so much in the actual code base of the kernel... but in userland I
    > would
    > eliminate all efforts of support windows based applications. WINE and
    > MONO
    > come to mind, almost immediately. They both should just... go away.


    Great idea. Special code should also be added to linux that makes it
    impossible to ever run Windows in a virtual machine. This combined with
    your idea will ensure that linux stays on 0.6% of the desktops for the next
    30 years.


    > --
    >
    > Jerry McBride (jmcbride@mail-on.us)



    ** Posted from http://www.teranews.com **

  9. Re: What would you fix in Linux?

    In comp.os.linux.advocacy, Jerry McBride

    wrote
    on Fri, 30 May 2008 19:53:01 -0400
    <9kg6h5x7n.ln2@supertux.my.domain>:
    >
    > "The Ghost In The Machine" wrote in
    > message news:34cug5-d7d.ln1@sirius.tg00suus7038.net...
    >> This is probably going to open a large 55-gallon drum of
    >> worms, but I'm curious.
    >>
    >> Linux (or a Linux distro, more properly) has many problems
    >> (most of them minor compared to certain other solutions),
    >> and some of them are rather obvious, at least to me.
    >>

    >
    >
    > Not so much in the actual code base of the kernel...


    True; the main problems I have are in video handling,
    which is a bit of a black art to me personally. My Kayak
    and my Pentium III-based box in particular have problems
    with X on occasion, when I switch out using Ctrl-Alt-Fn
    (basically, the video registers don't get set right and
    instead of chars, I get dots). Since I rarely use the
    Kayak (it's a Pentium 800 MHz and apparently has hardware
    problems) and don't use X on my Pentium III, these aren't
    exactly high priority issues for me.

    I'll admit part of my problem is that once I see a bug,
    I tend to walk around it, doing other things that tend not
    to elicit said bug. (There's one glaring exception: Bash
    tends to mess up its line editing in an xterm for some reason.
    I have to stretch the xterm as a workaround. Dunno if other
    terminal emulators have this problem, but I like xterm as it
    doesn't take a long time to fire up.)

    > but in userland I would
    > eliminate all efforts of support windows based applications.
    > WINE and MONO come to mind, almost immediately. They both
    > should just... go away.
    >


    Would that include IE from an Apache server? Be careful
    what you wish for... ;-)

    Agreed though that in a perfect world we'd not need Win32.
    It's a bodge on a kludge on a botch with a crutch --
    especially when one considers that one has to carefully
    save the returned value from SelectObject(). (This might
    not be as big a problem now that Win32/NT has been in
    use for so long, but it was an issue in Win16, and played
    merry hob with multithreaded apps as you might well imagine.)

    Admittedly, I rather like Mono, or at least its
    implementation on Linux, except for the fact that
    it depends on Microsoft technology, plus it has some
    minor technical deficiencies (mostly, it doesn't have a
    runtime optimizer like Java's JIT) and a fair number of
    implementation bugs (I consider it unfinished on Linux).
    But given a choice, I'd use Java anyway; it's less buggy,
    less encumbered, and more famililar to me personally; I
    might show disdain for java.util.List.get(int), as lists
    are ordered but getting the N'th element is an O(N) issue
    unless the backing store is an array, btree or other such
    more efficient structure, but I *know* about it, and can
    work around it.

    I wish I knew more about Squeak and Python. The former,
    though, tends to contain itself in its own little world
    (maybe at some point squeak.org will put out a version that
    does Squeaklets on the desktop; Smalltalk never got that
    popular but looks like it's far more reasonable from an OO
    standpoint than any other solution -- which may be why it
    never got that popular; it's not well understood :-) ),
    and the latter I've just not gotten around to learning
    despite its popularity, though I do know it has very
    Java-like packaging and a built-in help system.

    --
    #191, ewill3@earthlink.net
    "640K ought to be enough for anybody."
    - allegedly said by Bill Gates, 1981, but somebody had to make this up!
    ** Posted from http://www.teranews.com **

  10. Re: What would you fix in Linux?

    Ezekiel wrote:

    >
    > "Jerry McBride" wrote in message
    > news:9kg6h5x7n.ln2@supertux.my.domain...
    >>
    >> "The Ghost In The Machine" wrote in
    >> message news:34cug5-d7d.ln1@sirius.tg00suus7038.net...
    >>> This is probably going to open a large 55-gallon drum of
    >>> worms, but I'm curious.
    >>>
    >>> Linux (or a Linux distro, more properly) has many problems
    >>> (most of them minor compared to certain other solutions),
    >>> and some of them are rather obvious, at least to me.
    >>>

    >>
    >>
    >> Not so much in the actual code base of the kernel... but in userland I
    >> would
    >> eliminate all efforts of support windows based applications. WINE and
    >> MONO
    >> come to mind, almost immediately. They both should just... go away.

    >
    > Great idea. Special code should also be added to linux that makes it
    > impossible to ever run Windows in a virtual machine. This combined with
    > your idea will ensure that linux stays on 0.6% of the desktops for the
    > next 30 years.
    >


    I never suggested that virtual machine technologies should be touched in
    anymanner... just the direct support of windows filth via WINE and
    indirectly snuggleing up to MSFT via MONO... those two should "just go"...


    --

    Jerry McBride (jmcbride@mail-on.us)

  11. Re: What would you fix in Linux?

    What would I fix?

    In no particular order:

    .. Ditch Mono and all its dependants
    .. Ditch support for OOXML
    .. Move to Yum-presto and deltarpms for package distribution
    .. Improve Thunderbird's message filtering, and give it scoring
    .. Move Enlightenment from BSD to GPL3
    .. Move the kernel to GPL3
    .. Fix mkinitrd to set OHCI and UHCI to load in the correct order
    .. Make setting a backup policy part of all distro's install wizards
    .. Add an LTS distro to Fedora
    .. Move Ubuntu's Launchpad to GPL
    .. Make Tivoization, or any other form of GPL circumvention, illegal
    .. Make it mandatory for all hardware to be Open Specification
    .. Create an HTML5/SVG alternative to Flash
    .. Allow dump to use file names in its exception lists, rather than just
    inodes
    .. Make dumps mountable
    .. Make it mandatory for all hardware manufacturers to provide
    multi-platform versions of their BIOS and firmware updaters
    .. Add YUM-integrated dependency hinting and auto-install options to
    autoconf/automake
    .. Make copy-on-selection finally work between Mozilla apps and VNC

    There's probably lots of other stuff I've forgotten.

    --
    K.
    http://slated.org

    ..----
    | 'When it comes to knowledge, "ownership" just doesn't make sense'
    | ~ Cory Doctorow, The Guardian. http://tinyurl.com/22bgx8
    `----

    Fedora release 8 (Werewolf) on sky, running kernel 2.6.23.8-63.fc8
    03:00:30 up 161 days, 23:36, 6 users, load average: 0.19, 0.17, 0.14

  12. Re: What would you fix in Linux?

    On 2008-05-27, The Ghost In The Machine wrote:
    > This is probably going to open a large 55-gallon drum of
    > worms, but I'm curious.


    I love worms. They are great composters and produce superior fertilizer
    and soil conditioners.

    Bring on the worms!

    > Linux (or a Linux distro, more properly) has many problems
    > (most of them minor compared to certain other solutions),
    > and some of them are rather obvious, at least to me.


    Yep. Many problems. Nothing's perfect, especially developers.

    > 1. Sound continues to be a minor sore point for me,
    > though I'll admit it works for the most part when I'm not
    > using composition tools such as Rosegarden. Rosegarden,
    > however, is tricky; the requirements include jackd and
    > fluidsynth (though there are a few other tools that can
    > replace it) if one wants to generate actual sound from it.
    > I'd like to see this process simplified, or at least
    > explained sufficiently so that any n00b who's never heard
    > of MIDI or sequencers can at least get something out.
    > It's confusing me, the interrelationships between all
    > three of these tools.


    It's a royal pain in the arse, to put it mildly. I had to recompile one
    of my machines because rosegarden required a higher tick resolution than
    I had my kernel using. I'm yet to get all the toolchain together to run
    Rosegarden. I'll get there when I've got the time to fiddle about.

    > To be fair, Rosegarden is perfectly usable without sound,
    > if all one wants to do is compose sheet music. But I'm
    > not Beethoven. ;-) Nor am I all that happy about the
    > synthesizer waveforms, which apparently change every year;
    > a composition which sounded nice under one set of conditions
    > can sound horrible under another. I should note, however,
    > that this is an *improvement* over certain games which are
    > now so old they creak -- and can no longer run on hardware
    > that can't emulate good old Soundblaster, IRQ 5, DMA 1,
    > or some of its descendants.


    Sound mostly works, but I suspect the main problem still lies at the
    device driver level. There seems to be no desire by manufacturers to
    provide a common interface for peripheral devices attaching to x86 based
    machines. Until they do, then microsoft will always rule the roost in
    this area, as the device makers will always provide drivers for machines
    running the windows OS.

    > 2. Video is interesting, and continues to get more
    > interesting. In particular, X now has the ability to
    > change resolutions, and SDL has had "full screen mode"
    > for awhile. They could coordinate a little better, at
    > least on my system -- perhaps it's a config thing, but my
    > homegrown SDL application that goes full screen leaves X
    > at the wrong resolution when it goes back. Not sure where
    > that bug is hiding, frankly -- or whether X should compensate
    > for bad programming on my part. A "nice to have".


    Never done any programming using the SDL libraries do can't comment.

    > 3. OpenGL could go across the network somehow. As one
    > should already know, 'ssh -CXY' is a transparent X tunnel,
    > but OpenGL cannot fit through that tunnel. While the
    > usefulness of OpenGL across the network is debatable
    > (there are better ways), it would be a "nice to have".


    Hmmm... compiz across the network... that _would_ be interesting.

    > 4. Internally, Java's a bit of a mess -- not because it's
    > not a capable solution, but because it's a bit hard to
    > monitor. Briefly put, Java tends to gobble up memory from
    > the OS and never return it back when it no longer needs it.
    > While this unused memory can be swapped out (if one has
    > sufficient swapspace), it would ideally just be returned
    > back to the OS, for other, non-Java, processes to use.
    > Whether this is even *possible* without major modifications
    > to the JVM's subsystem or to libc is not clear to me; Amiga
    > had free(), which never released RAM but is very portable,
    > and FreeMem(), which is an AmigaOS-specific function
    > which gives RAM back to anyone who needs it. Of course
    > done sloppily one runs into fragmentation problems, which
    > suggests we should only release RAM back to the OS in
    > page-sized chunks, and make apporpriate modifications to
    > malloc() to request page-sized chunks as opposed to using
    > sbrk(); the double free() I consider a horrid anachonism.
    >
    > Java also has issues with open files; they don't get
    > garbage collected. Of course one might quibble that
    > open files should be explicitly closed anyway.


    Hmmm.. running a JVM is horrible. It is such a massive resource hog. I
    don't know what can be done, unless it can be broken down into a number
    of shortlived processes, each releasing memory when they exit.

    Great idea, pathetic execution.

    > 5. I have no idea how we do this nicely, but I had to
    > resolve Yet Another Broken Library Dependency on Gentoo.
    > Gentoo may be unique in this issue but ddd for some reason
    > depended on libXm.so.3 instead of libXm.so. Perhaps that's
    > intentional, but a subsequent update, presumably of libXm,
    > broke that dependency. I don't see this being unique to
    > Gentoo, either; Gentoo reduces it but cannot possibly
    > eliminate it, as what I suspect happened was along the
    > lines of:
    >
    > libXm.so.3 built
    > ddd built using libXm.so.3
    > libXm.so.3 -> libXm.so.4 upgrade
    > ddd now broken


    Ouch!

    I get annoyed about this constantly moving target. I don't know a
    solution other than to stifle innovation and improvement.

    I live with it and curse silently whenever a system update leaves me
    with a broken app. It's generally very easy to fix, and keeping an eye
    on the messages that are returned by the emerge system while updating
    (PORTDIR_ELOG_*) keeps me on top of things, usually.

    BTW.. I've used ddd and I hated it for the buggy mess it was. It must
    have improved in the last few years. I tend to stick with gdb.

    > Gentoo does provide revdep-rebuild, to help in such cases. I
    > don't know what other distros have, and for other distros it
    > might be a touch simpler, since they don't have to compile
    > from source. I don't see other distros being invulnerable
    > to this issue.


    Nope.. it's a GNU/linux quirk. If you want to run dynamically loaded
    libraries then you have to pay the price of innovation and improvement.

    If not, then just run a machine with static binaries... yeccch!

    > For its part revdep-rebuild could be a little faster, though
    > part of that is simply that it has to scan through all of the
    > executables and dlls it knows about -- and on my system,
    > there are a lot of executables and dlls.


    It's fast on my lappy, but not on the big desktops. Servers are OK.

    > 6. The entire autogen/autotools/libtools/configure
    > could be explained nicely somewhere. I'd love to build
    > internationalizable, portable tools, but it's all Greek
    > to me. Hopefully something on gnu.org can handle this one.


    It's a mess, but how can you change it now without leaving a trail of
    broken source in your wake?

    Now we have programs like jam and ftjam... and openoffice uses its own
    complete (and stupid) build system.

    Every time someone comes up with a new "alternative" to make you have
    yet another build system that MUST be installed on your machine in order
    to build the apps... phewww, it stinks to high heaven.

    It's a ****ing mess... I still stick with automake autoconf etc...
    despite their convoluted nature, and the lack of any decent
    documentation... the info docs are a ****ing disgrace.

    > 7. I'll admit to some curiosity as to how to set up a
    > standardized method (RPM?) to allow a non-superuser to
    > install software, with a password prompt for him to become
    > superuser. I would hope this is partially already done,
    > and furthermore that the installation process pulls in
    > (or brings up a request) for other RPMs as the dependency
    > tree is searched. It is not clear to me whether the
    > application developer or the distro manager be responsible
    > for dependencies; one could make a case either way.
    > The issue is further complicated by Gentoo and Debian,
    > which have .ebuild and .deb files, respectively, plus other
    > distros which are non-RPM based. All this suggests that
    > distros have well-lit paths, but outside of those paths,
    > it's a bit of a jungle -- though with /usr/local one can
    > at least prune the worst of the branches into a somewhat
    > manageable topiary.


    Personally, I couldn't care less about it. I've never come across a
    better system than the Gentoo package management system.

    I also don't really see the need for a standardised package management
    system. This will probably continue to stay in a state of flux until a
    perfect package management system is invented... ;-)

    >
    > 8. 'find . -name blah.blah' is a bit silly, though it works
    > well enough if combined with other qualifiers. Ideally,
    > though, one would have an equivalent to slocate which would
    > be intelligent enough to search a filesystem *by name*
    > (as opposed to by path). Such is possible on MacOSX,
    > at least in theory. Of course multiple paths might be
    > returned in some cases -- especially if someone's silly
    > enough to 'namefind .keep' on a Gentoo system (.keep being
    > used as a sort of marker to ensure important directories
    > don't inadvertantly vanish). Certain regular expressions
    > would be doable with a btree ("blah.*" is easy enough,
    > though "*.blah" might have some issues).


    Never seem to have much problem finding stuff on my machines. If I had a
    problem I'd design my own.

    > 9. I'll admit to wondering whether the first few bytes
    > of the file should be stored in the inode. Such appears
    > to be the case in Microsoft's "MFS", which doesn't work
    > all that well, but it would make finding magic numbers a
    > bit easier. Of course if one can guarantee that the first
    > data block is within the same cylinder as the inode, that
    > might be sufficient -- though how one guarantee that when
    > the interface card lies like a rug to the OS, and the disk
    > lies to the card, is far from clear. (The reasons relate
    > to that good old 10-bit cylinder addressing limitation.
    > We'll be living with these issues for awhile, methinks,
    > and the variable geometry most drives have doesn't
    > help either -- though does make storage more efficient.
    > Perhaps it will cease to be an issue when everyone switches
    > to non-spindle-based flash RAM.)


    Sound like you'd do better pushing **** uphill for very little gain.

    > 10. Somehow, someway, Linux needs to find its way and its
    > niche. Briefly, Linux has no set direction -- this may not
    > be a bad thing, but that doesn't mean it'll get anywhere.
    > It has found a nice hiding place in the server arena, but
    > FreeBSD has notions (and may be a better fit for some);
    > also, Microsoft is an excellent server solution for those
    > who can afford to buy it, the hardware hosting it, and the
    > surrounding technology/software to keep the viruses out.


    > Perhaps I'm being overly harsh in some areas, and missing
    > others completely (I use older hardware, for example,
    > and have no idea about the newfangled gizmos). In any
    > event, opinions welcome, relevant comments tolerable,
    > inanity generally ignored, flames routed to /dev/null, etc. ;-)


    I use a range of old/new hardware....

    Overall I think the main concerns are:

    a) sound. ALSA is OK, but still difficult to get running on all the
    different bloody cards with different bloody chipsets....

    b) Shared library links broken by library updates. How can we make it
    easier to keep the innovation and also keep our machines fully
    functional?

    --
    Regards,

    Gregory.
    Gentoo Linux - Penguin Power

  13. Re: What would you fix in Linux?

    On 2008-05-30, AqD wrote:
    > On May 30, 7:32 am, Cork Soaker wrote:
    >> The Ghost In The Machine wrote:
    >>
    >> > This is probably going to open a large 55-gallon drum of
    >> > worms, but I'm curious.

    >>
    >> > Linux (or a Linux distro, more properly) has many problems
    >> > (most of them minor compared to certain other solutions),
    >> > and some of them are rather obvious, at least to me.

    >>
    >> tl;dr Wireless support and troubleshooting, but things like this are
    >> being worked on all the time.
    >>
    >> Also, decent games.

    >
    > Not possible. Even with cedega you still have only a handful of games
    > to play (officially supported).
    >
    > The linux gaming market is too small, and the OS environment isn't
    > friendly to games - except for nividia's, no other gfx card can
    > guarantee anything, not even full 2D acceleration.


    Rubbish. ATI graphic cards, while not perfect, do a good job of 3D (as
    long as you download their proprietary drivers).


    --
    Regards,

    Gregory.
    Gentoo Linux - Penguin Power

  14. Re: What would you fix in Linux?

    Verily I say unto thee, that Gregory Shearman spake thusly:

    > Rubbish. ATI graphic cards, while not perfect, do a good job of 3D
    > (as long as you download their proprietary drivers).


    I play Q3 and ET:QW on my ATi X700 based system all the time, using only
    the Free radeon driver, without any problems, and at a decent speed too.

    --
    K.
    http://slated.org

    ..----
    | 'When it comes to knowledge, "ownership" just doesn't make sense'
    | ~ Cory Doctorow, The Guardian. http://tinyurl.com/22bgx8
    `----

    Fedora release 8 (Werewolf) on sky, running kernel 2.6.23.8-63.fc8
    04:28:33 up 162 days, 1:04, 6 users, load average: 0.17, 0.16, 0.18

  15. Re: What would you fix in Linux?

    On May 31, 11:15 am, Gregory Shearman
    wrote:
    > On 2008-05-30,AqD wrote:
    >
    >
    >
    > > On May 30, 7:32 am, Cork Soaker wrote:
    > >> The Ghost In The Machine wrote:

    >
    > >> > This is probably going to open a large 55-gallon drum of
    > >> > worms, but I'm curious.

    >
    > >> > Linux (or a Linux distro, more properly) has many problems
    > >> > (most of them minor compared to certain other solutions),
    > >> > and some of them are rather obvious, at least to me.

    >
    > >> tl;dr Wireless support and troubleshooting, but things like this are
    > >> being worked on all the time.

    >
    > >> Also, decent games.

    >
    > > Not possible. Even with cedega you still have only a handful of games
    > > to play (officially supported).

    >
    > > The linux gaming market is too small, and the OS environment isn't
    > > friendly to games - except for nividia's, no other gfx card can
    > > guarantee anything, not even full 2D acceleration.

    >
    > Rubbish. ATI graphic cards, while not perfect, do a good job of 3D (as
    > long as you download their proprietary drivers).


    And what else?

    Besides, ATI drivers are far from being perfect. There're many
    reported problems and it cannot even support hardware acceleration for
    RENDER (which all modern gfx cards can do)

  16. Re: What would you fix in Linux?

    On May 31, 11:28 am, Homer wrote:
    > Verily I say unto thee, that Gregory Shearman spake thusly:
    >
    > > Rubbish. ATI graphic cards, while not perfect, do a good job of 3D
    > > (as long as you download their proprietary drivers).

    >
    > I play Q3 and ET:QW on my ATi X700 based system all the time, using only
    > the Free radeon driver, without any problems, and at a decent speed too.


    By "decent" you mean the speed is as fast as the official driver?

    Anything below it is not acceptable.

  17. Re: What would you fix in Linux?

    On 2008-05-31, AqD wrote:
    > On May 31, 11:15 am, Gregory Shearman
    > wrote:
    >> On 2008-05-30,AqD wrote:
    >>
    >>
    >>
    >> > On May 30, 7:32 am, Cork Soaker wrote:
    >> >> The Ghost In The Machine wrote:

    >>
    >> >> > This is probably going to open a large 55-gallon drum of
    >> >> > worms, but I'm curious.

    >>
    >> >> > Linux (or a Linux distro, more properly) has many problems
    >> >> > (most of them minor compared to certain other solutions),
    >> >> > and some of them are rather obvious, at least to me.

    >>
    >> >> tl;dr Wireless support and troubleshooting, but things like this are
    >> >> being worked on all the time.

    >>
    >> >> Also, decent games.

    >>
    >> > Not possible. Even with cedega you still have only a handful of games
    >> > to play (officially supported).

    >>
    >> > The linux gaming market is too small, and the OS environment isn't
    >> > friendly to games - except for nividia's, no other gfx card can
    >> > guarantee anything, not even full 2D acceleration.

    >>
    >> Rubbish. ATI graphic cards, while not perfect, do a good job of 3D (as
    >> long as you download their proprietary drivers).

    >
    > And what else?


    What else do you need?

    > Besides, ATI drivers are far from being perfect. There're many
    > reported problems and it cannot even support hardware acceleration for
    > RENDER (which all modern gfx cards can do)


    I'm sure there are many problems with ATI cards... as there are with
    NVIDIA.

    Support for hardware accelerated RENDER? FFS, if you need such support
    then choose another card... sheesh!

    I have no quarrels with the card. I used to have quarrels with the
    proprietary driver, but now I have more trouble with legacy NVIDIA
    support with their proprietary driver. I'm forced to hack the kernel to
    get a stable driver running with an NVIDIA GeForce4 MX 440 (NV18).

    --
    Regards,

    Gregory.
    Gentoo Linux - Penguin Power

  18. Re: What would you fix in Linux?

    On May 31, 5:33 pm, Gregory Shearman wrote:
    > On 2008-05-31, AqD wrote:
    >
    >
    >
    >
    >
    >
    >
    > > On May 31, 11:15 am, Gregory Shearman
    > > wrote:
    > >> On 2008-05-30,AqD wrote:

    >
    > >> > On May 30, 7:32 am, Cork Soaker wrote:
    > >> >> The Ghost In The Machine wrote:

    >
    > >> >> > This is probably going to open a large 55-gallon drum of
    > >> >> > worms, but I'm curious.

    >
    > >> >> > Linux (or a Linux distro, more properly) has many problems
    > >> >> > (most of them minor compared to certain other solutions),
    > >> >> > and some of them are rather obvious, at least to me.

    >
    > >> >> tl;dr Wireless support and troubleshooting, but things like this are
    > >> >> being worked on all the time.

    >
    > >> >> Also, decent games.

    >
    > >> > Not possible. Even with cedega you still have only a handful of games
    > >> > to play (officially supported).

    >
    > >> > The linux gaming market is too small, and the OS environment isn't
    > >> > friendly to games - except for nividia's, no other gfx card can
    > >> > guarantee anything, not even full 2D acceleration.

    >
    > >> Rubbish. ATI graphic cards, while not perfect, do a good job of 3D (as
    > >> long as you download their proprietary drivers).

    >
    > > And what else?

    >
    > What else do you need?


    SiS, Intel, VIA, ....

    >
    > > Besides, ATI drivers are far from being perfect. There're many
    > > reported problems and it cannot even support hardware acceleration for
    > > RENDER (which all modern gfx cards can do)

    >
    > I'm sure there are many problems with ATI cards... as there are with
    > NVIDIA.


    Not many. Unless you're using composite desktop, the NVIDIA driver
    works just as fine as on windows, if not better.

    >
    > Support for hardware accelerated RENDER? FFS, if you need such support
    > then choose another card... sheesh!


    Problem is, RENDER/2D-composition is in fact supported by all modern
    gfx cards, and it's been so for MANY years. It's a shame many X
    drivers still don't implement it now.

    >
    > I have no quarrels with the card. I used to have quarrels with the
    > proprietary driver, but now I have more trouble with legacy NVIDIA
    > support with their proprietary driver. I'm forced to hack the kernel to
    > get a stable driver running with an NVIDIA GeForce4 MX 440 (NV18).


    Doesn't NVIDIA provide legacy drivers for old cards??

  19. Re: What would you fix in Linux?

    On 2008-05-31, AqD wrote:
    > On May 31, 5:33 pm, Gregory Shearman wrote:
    >> On 2008-05-31, AqD wrote:
    >>
    >>
    >>
    >>
    >>
    >>
    >>
    >> > On May 31, 11:15 am, Gregory Shearman
    >> > wrote:
    >> >> On 2008-05-30,AqD wrote:

    >>
    >> >> > On May 30, 7:32 am, Cork Soaker wrote:
    >> >> >> The Ghost In The Machine wrote:

    >>
    >> >> >> > This is probably going to open a large 55-gallon drum of
    >> >> >> > worms, but I'm curious.

    >>
    >> >> >> > Linux (or a Linux distro, more properly) has many problems
    >> >> >> > (most of them minor compared to certain other solutions),
    >> >> >> > and some of them are rather obvious, at least to me.

    >>
    >> >> >> tl;dr Wireless support and troubleshooting, but things like this are
    >> >> >> being worked on all the time.

    >>
    >> >> >> Also, decent games.

    >>
    >> >> > Not possible. Even with cedega you still have only a handful of games
    >> >> > to play (officially supported).

    >>
    >> >> > The linux gaming market is too small, and the OS environment isn't
    >> >> > friendly to games - except for nividia's, no other gfx card can
    >> >> > guarantee anything, not even full 2D acceleration.

    >>
    >> >> Rubbish. ATI graphic cards, while not perfect, do a good job of 3D (as
    >> >> long as you download their proprietary drivers).

    >>
    >> > And what else?

    >>
    >> What else do you need?

    >
    > SiS, Intel, VIA, ....


    Whatever.

    >>
    >> > Besides, ATI drivers are far from being perfect. There're many
    >> > reported problems and it cannot even support hardware acceleration for
    >> > RENDER (which all modern gfx cards can do)

    >>
    >> I'm sure there are many problems with ATI cards... as there are with
    >> NVIDIA.

    >
    > Not many. Unless you're using composite desktop, the NVIDIA driver
    > works just as fine as on windows, if not better.


    See below.

    >>
    >> Support for hardware accelerated RENDER? FFS, if you need such support
    >> then choose another card... sheesh!

    >
    > Problem is, RENDER/2D-composition is in fact supported by all modern
    > gfx cards, and it's been so for MANY years. It's a shame many X
    > drivers still don't implement it now.


    Boohoo... use another card if it worries you. As I've explained, I don't
    have any problems with the ATI card. I have had problems in the past,
    but these have been fixed.

    >
    >>
    >> I have no quarrels with the card. I used to have quarrels with the
    >> proprietary driver, but now I have more trouble with legacy NVIDIA
    >> support with their proprietary driver. I'm forced to hack the kernel to
    >> get a stable driver running with an NVIDIA GeForce4 MX 440 (NV18).

    >
    > Doesn't NVIDIA provide legacy drivers for old cards??


    On one of my machines (A pentium4 2.4G) I have to run the 96.43.01
    driver because the 96.43.05 driver is unstable and crashes X with a
    segfault. Compiling the 96.43.01 driver with the 2.6.24 kernel causes it
    to fail with "Can't find kernel version". I've had to hack the kernel
    source (a simple but ugly hack that is merely a link to another
    directory) in order to get it to compile. It now works.

    I can't run drivers newer than 96.xx.xx on the GeForce4 MX 440.

    --
    Regards,

    Gregory.
    Gentoo Linux - Penguin Power

  20. Re: What would you fix in Linux?

    On Sat, 31 May 2008 03:00:50 +0100, Homer wrote:

    > What would I fix?
    >
    > In no particular order:
    >
    > . Ditch Mono and all its dependants
    > . Ditch support for OOXML
    > . Move to Yum-presto and deltarpms for package distribution
    > . Improve Thunderbird's message filtering, and give it scoring
    > . Move Enlightenment from BSD to GPL3
    > . Move the kernel to GPL3
    > . Fix mkinitrd to set OHCI and UHCI to load in the correct order
    > . Make setting a backup policy part of all distro's install wizards
    > . Add an LTS distro to Fedora
    > . Move Ubuntu's Launchpad to GPL
    > . Make Tivoization, or any other form of GPL circumvention, illegal
    > . Make it mandatory for all hardware to be Open Specification
    > . Create an HTML5/SVG alternative to Flash
    > . Allow dump to use file names in its exception lists, rather than just
    > inodes
    > . Make dumps mountable
    > . Make it mandatory for all hardware manufacturers to provide
    > multi-platform versions of their BIOS and firmware updaters
    > . Add YUM-integrated dependency hinting and auto-install options to
    > autoconf/automake
    > . Make copy-on-selection finally work between Mozilla apps and VNC
    >
    > There's probably lots of other stuff I've forgotten.


    Notice that most this loons suggestions have little impact on an average
    user and are mostly hate stuff and demands.

    Typical Linux loon...

    FWIW I agree with what Ghost and Ezekiel wrote.

    --
    Moshe Goldfarb
    Collector of soaps from around the globe.
    Please visit The Hall of Linux Idiots:
    http://linuxidiots.blogspot.com/

+ Reply to Thread
Page 1 of 2 1 2 LastLast