Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 48

Thread: AMD Catalyst 9.8 Preview

  1. #11
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,777

    Default

    Hopefully.

    Btw, the Windows 9.8 drivers are already up on akamai.net and downloadable (for over a day now), even though there's no official announcement yet. I hope that:

    https://a248.e.akamai.net/f/674/9206...x86.x86_64.run

    will become active soon too

  2. #12
    Join Date
    Jul 2009
    Posts
    90

    Default

    Quote Originally Posted by d2kx View Post
    Remember it's only two months until Ubuntu 9.10 which uses Linux 2.6.31 and they'll want to support that from the beginning.
    Ubuntu just needs to use a patched kernel that still exports find_task_by_vpid

  3. #13
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,577

    Default

    Quote Originally Posted by ObiWan View Post
    Ubuntu just needs to use a patched kernel that still exports find_task_by_vpid
    Maybe... Doing that would give an interesting sign to the rest of the community though. As in, that distro maintainers can override kernel developers' decisions on kernel development. (strictly speaking this already happened at least once, eg Debian vs radeon microcode)

  4. #14
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,126

    Default

    Quote Originally Posted by nanonyme View Post
    Maybe... Doing that would give an interesting sign to the rest of the community though. As in, that distro maintainers can override kernel developers' decisions on kernel development. (strictly speaking this already happened at least once, eg Debian vs radeon microcode)
    What? Distro maintainers have been patching and modifying the kernel forever - that's their job!

  5. #15
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,577

    Default

    Quote Originally Posted by BlackStar View Post
    What? Distro maintainers have been patching and modifying the kernel forever - that's their job!
    It most definitely isn't the job of distro maintainers to have an opinion on where kernel development should head. If it was, they should be kernel developers. Fixing bugs is one thing to but re-exporting symbols means they disagree with where Linux kernel developers think the kernel should be going. I'm not sure I consider that a very good sign.

  6. #16
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,126

    Default

    Quote Originally Posted by nanonyme View Post
    It most definitely isn't the job of distro maintainers to have an opinion on where kernel development should head. If it was, they should be kernel developers. Fixing bugs is one thing to but re-exporting symbols means they disagree with where Linux kernel developers think the kernel should be going. I'm not sure I consider that a very good sign.
    In a perfect world, this makes sense. However, we don't live in a perfect world and no distro maintainer will let a significant number of systems break if he can help it.

    It's the maintainer's job to smooth things over and make sure the distro will work for the largest amount of users. This might involve mean patching the kernel (all distros); it might involve pulling out-of-tree branches (Fedora, I'm looking at you); it most certainly doesn't mean sitting back and enjoying the carnage when widely-used software stops working for one reason or another.

    I don't see this as a bad thing. The maintainer frees the kernel devs from the burden of supporting legacy software. Sooner or later, the legacy software will either be upgraded or it will become too costly to maintain and will be dropped (see Arch and fglrx).

  7. #17
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,777

    Default

    Quote Originally Posted by nanonyme View Post
    It most definitely isn't the job of distro maintainers to have an opinion on where kernel development should head. If it was, they should be kernel developers. Fixing bugs is one thing to but re-exporting symbols means they disagree with where Linux kernel developers think the kernel should be going. I'm not sure I consider that a very good sign.
    I remember reading on lkml the developers themselves say that distros are encouraged to change the kernel however they see fit. Upstream kernel does not deal with distro issues when it can avoid it. It's the distro's job to modify it and produce their own flair of the kernel. And they consider this a "Good Thing". Upstream is the "vanilla" flavor and it's not intended to be suitable for every one.

  8. #18
    Join Date
    Mar 2009
    Posts
    27

    Default

    its already downloadable, but still not announced

  9. #19
    Join Date
    Oct 2007
    Posts
    912

    Default

    Quote Originally Posted by nanonyme View Post
    That note about the primitive restart sounds a bit funky. If that list of extensions actually is getting in as new stuff and they get the support for two new Linux versions, I'd probably be impressed if I still used the closed drivers.
    Not really - it's probably something that won't concern most people (in other words, that bit on primitive restart isn't very funky), and actually might make things cleaner elsewhere. It's just a natural progression away from the whole client state enable/disable.

    I'll definitely be looking forward to the glsl 1.40 support.

  10. #20
    Join Date
    Jun 2008
    Location
    Italy
    Posts
    74

    Default

    Quote Originally Posted by Dinth View Post
    its already downloadable, but still not announced
    Wut? Vherr?

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •