Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Upgrades Wireless Networking Graphics Software Linux Hardware

Linux 2.6.28 Promises Year-End Presents 305

darthcamaro writes "Little penguins all around the world are waiting for Penguin-Master Linus Torvalds to deliver some Glogg inspired Xmas cheer in the form of the new 2.6.28 kernel. Among the innovations in 2.6.28 are ext4 as stable, wireless USB drivers, better KVM support and the GEM graphic memory management technology. 'We now have a proper memory manager for video memory, the GEM [Graphics Execution Manager] memory manager,' Greg Kroah-Hartman said. 'This gives Linux much better graphics performance than it previously had.'"
This discussion has been archived. No new comments can be posted.

Linux 2.6.28 Promises Year-End Presents

Comments Filter:
  • Comment removed (Score:5, Interesting)

    by account_deleted ( 4530225 ) on Wednesday December 24, 2008 @07:19PM (#26226823)
    Comment removed based on user account deletion
  • Re:The new graphics (Score:5, Interesting)

    by diegocgteleline.es ( 653730 ) on Wednesday December 24, 2008 @07:54PM (#26227013)

    I recommend reading this link [rojtberg.net] to get an idea of what's going on in the Linux graphics stack:

    "So currently there is not one field where construction done but several. These are 2D Acceleration, Memory Management, 3D Acceleration and 2D Modesetting. And they are all being worked on at the same time to speed things up.

    But the problem is that more or less all of these depend on proper Memory Management, which is also the hardest thing to get right.

    Now lets look at how Xorg works today; every Xorg driver implements its own way of memory management and provides the DRI1 functionality when it comes to 3D. Furthermore it is responsible for modesetting, which is quite suboptimal, since some perliminary modesetting is already done in kernel, so it can output messages during bootup. The Xorg driver resets the hardware again when it is loaded.

    Kernel Based Modesetting

    In order to solve this duplication the modesetting code is about to be moved into the kernel, so the hardware can be setup once and for all. But since modesetting involves memory management which is not done properly yet too."

  • Re:Nice start... (Score:5, Interesting)

    by Anpheus ( 908711 ) on Wednesday December 24, 2008 @08:43PM (#26227285)

    Because the UAC window is on an independent desktop that other applications cannot interact with. The only possible flaw is if something has installed itself as a mouse or keyboard input driver, I believe. But doing that will spawn a great big red unsigned driver prompt.

  • Re:The new graphics (Score:5, Interesting)

    by dow ( 7718 ) on Wednesday December 24, 2008 @09:29PM (#26227515)

    What should be important is that maybe next gen games should be released on Linux as a platform equal to Windows.

    I was a long term Linux user, who went to XP just for the games. My gaming rig is waiting an RMA on a PSU, so rebuilt an old system and installed Slackware.

    On an older machine with slower drives and a quarter the Ram, the responsiveness of the OS is amazing. If mainstream games were released for Linux I'd have no choice.

    Sadly, I mainly use computers these days for relaxation, shopping and play, and if I'd continued as I set out, would no doubt be a full time Linux user... However, as a gamer, I put up with XP64 as a day to day OS.

  • by Yfrwlf ( 998822 ) on Wednesday December 24, 2008 @09:47PM (#26227611)
    "instead of having a distinct HAL in X you use the system one"

    Wasn't that their point? That it's a separate system, so that if it fails, you'll still at least have the command line?

    You can always make the argument that, well, if the code is good, then it should work, so what is the issue here that everyone is beating around the bush about? I think it's stability via intelligent programming. If you have the command line as a failsafe for when X fails, it gives you extra protection against bugs, which will always be there somewhere. You shouldn't just expect code to be written correctly, you should fortify yourself for when things break. If this can still be done even with kernel mode setting and such, if the kernel can switch to a failsafe if GEM or whatnot fails, then that will certainly help. Simplifying software stacks and creating APIs for performance and ease of programming = good. Removing failsafes = scary, unless they added some other failsafe somewhere else or whatnot, or maybe there's already one there.

    And no, don't say reformat reinstall, that's the Windows failsafe. :P
  • by Creepy Crawler ( 680178 ) on Wednesday December 24, 2008 @10:14PM (#26227721)

    Akin to that idea: so you think that regular memory handling should be done by the shell? That is the analogue to X handling graphic memory.

  • by StuffMaster ( 412029 ) on Wednesday December 24, 2008 @10:51PM (#26227867)

    I've actually had this happen to me. After a couple of years, my video card decided to 'degrade' its performance. It would sometimes lock up (completely, no numlock or anything) when playing certain games, but after 30-90 seconds, Windows would change modes to tell me there was a problem with my card. Pretty nice if you ask me.

    I've since lowered the resolution to avoid this.

  • Re:Stable?? (Score:3, Interesting)

    by siride ( 974284 ) on Wednesday December 24, 2008 @11:44PM (#26228047)
    There are stable branches: older kernel releases. They keep getting bugfixes and security fixes for some time.
  • by Paradigm_Complex ( 968558 ) on Thursday December 25, 2008 @01:16AM (#26228377)
    You're correct that the vast majority of improvements in the Linux kernel - when taken by themselves - are unlikely to change anything for any specific end user. These become significant when you add them all together. Odds are slim that any one person will ever use some new hardware support being added in a given kernel update, or some notice some change that ups battery life by couple a percent. However, when you compare the hardware support or battery life of a modern Linux distro to one even a few years old the change is drastic.

    There is a huge number of examples I could give, but a recent event really stands out for me. Just a couple days ago a friend was having computer problems (couldn't read a DVD) and wasn't sure if it was a hardware or software issue. A simple check was to boot off Linux off of a USB flash drive and see if it worked (it didn't - ends up the DVD was funky). What's amazing here is that on a completely random system - built as a Windows gaming machine without Linux in mind - a Linux install which has never seen this hardware before performed flawlessly. It booted off of the USB drive faster than the (clean, relatively minimal bloat) XP did from the hard drive, detected and automatically connected to wifi, et al. Everything just worked.

    Adding support for a few new webcams or wifi adapters or some new memory management or power stuff isn't going to make a difference. Doing that repeatedly for years, however, and all of a sudden you've got the best hardware support (out of the box anyways) and best performing OS around.
  • Re:2009 (Score:3, Interesting)

    by jalefkowit ( 101585 ) <jason@jaso3.14nlefkowitz.com minus pi> on Thursday December 25, 2008 @01:47AM (#26228501) Homepage

    "The future is already here. It's just not evenly distributed." -- William Gibson

  • Re:The new graphics (Score:5, Interesting)

    by Antique Geekmeister ( 740220 ) on Thursday December 25, 2008 @02:58AM (#26228753)

    The NVidia blobs remain a big problem. It's not the kernel blob: it's their replacement by setting aside of the OpenGL libraries, used to access the NVidia features. This part of the NVidia process destabilizes every OS that it touches because any updates to those libraries overwrite the NVidia libraries and seriously break your graphical setup.

    It's theoretically possible to rewrite the Xorg and Mesa packages to cooperate with this by bundling the Nvidia package and its libraries to a package matching the Mesa components and install one or the other, but no one has yet done so. So NVidia remains a dangerously unstable set of tools to install in any sytem that gets any updates otherwise.

  • by twilight30 ( 84644 ) on Thursday December 25, 2008 @03:18AM (#26228825) Homepage

    Hi everyone,
    Ever since 2.6.27.x came out I have not been able to compile from source and have the internet connection work correctly at all.

    Basically I try to take old source configs and run them in the new kernels, but I get the same result.

    Even binary Ubuntu kernel builds fail to run internet connections correctly...

    Apparently this item may be related to it:
    http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fd6149d332973bafa50f03ddb0ea9513e67f4517 [kernel.org]

    (regarding the reordering of TCP options... how do I fix it?)

    Any advice very gratefully appreciated ...
    M

  • by Anonymous Coward on Thursday December 25, 2008 @05:21AM (#26229133)

    Still funny how it is GEM and DRI again. Before we had the Graphics Execution Manager and Direct Rendering Interface there was a time with Graphical Environment Manager and Digital Research Inc.

  • by Mandrel ( 765308 ) on Thursday December 25, 2008 @05:48AM (#26229199)

    I hope this fixes the two annoyances I have with Linux:

    1. Doing an ls on a directory containing 1000 ext3 files on my quite modern computer takes nearly 10 seconds.
    2. Deleting a multi-gig file such as a TV recording locks up the OS so badly that other apps freeze. If mencoder is recording TV it will fail to keep up with the stream. AV sync is lost, ruining the rest of the recording.

  • by TheRaven64 ( 641858 ) on Thursday December 25, 2008 @06:46AM (#26229297) Journal

    Although not part of GEM, one related improvement is moving modesetting into the kernel. Currently, when you switch to an X11 VT, X11 requests the console be set back to VGA then initialises it to the correct mode itself. This is really horrible, and doesn't play nice with power management (because the kernel doesn't know anything about the GPU state, so can't easily save and restore it). The modesetting branch in X.org has been defining some clean kernel interfaces for doing this, simplifying both the kernel and the X server in the process (since both previously contained lots of special-purpose code for doing the same thing for each device).

    As with GEM, this isn't a Linux-specific thing, it's driven by X.org and being implemented on Linux, *BSD and Solaris.

  • by spaceturtle ( 687994 ) on Thursday December 25, 2008 @07:51AM (#26229437)

    Well, at the moment we don't really have the command line as a failsafe. When the X server crashes it seems to lock up the keyboard so Cntl-Alt-F1 doesn't switch to the VT (though I can usually ssh in, and restart X, but then I could also ssh -Y and restart X with a remote GUI, so the "commandline" doesn't really help here).

    The problem is the currently we have three different things that can directly mess with the video hardware: The framebuffer, DRI and the X server [lwn.net], and so any of these can cause trouble. This can lead to worse than triple the number of bugs because interactions between these can cause trouble.

    Its similar to how having a database server tends to be more reliable than having clients directly accessing the database files. Yes, the database server adds a single point of failure, but that is better than having 20+ nodes each of which can horribly corrupt the database files. While in principle GEM could fail, so could the hundred other modules in my kernel. And a bug in GEM is unlikely to be as serious as a bug in ext3/4.

  • Re:The new graphics (Score:5, Interesting)

    by Elektroschock ( 659467 ) on Thursday December 25, 2008 @10:40AM (#26229869)

    Basically the next generation games consoles will be based on Linux + some API.

  • Re:Nice start... (Score:3, Interesting)

    by TheNetAvenger ( 624455 ) on Thursday December 25, 2008 @12:39PM (#26230325)

    GDI graphics are not hardware accelerated on windows vista (WDDM 1.0), you can read this everywhere on the internet

    As I responded above, this is a misconception... Yes the GDI is no longer 2D GPU assisted, but that doesn't mean that NONE of the GDI/GDI+ functions are shoved through the 3D GPU.

    Look up font rendering, DIB/Bitmap functions, GDI+ calls that do anti-aliasing all the way to layered and transparent Windows that are all processed using the 3D side of the GPU.

    However you are also correct that WDDM 1.1 revisits the GDI/GDI+ functions and add more to the mix that will be 3D GPU assisted, but again not EVERYTHING will get an equivalent replacement as there are times it is just faster to process the GDI function on the CPU.

    So WDDM 1.0 is 'some' and WDDM 1.1. is 'more' GDI 3D acceleration.

    BTW If I just threw up my hands and said, yes you are 100% correct, you are still proving the point I was making that Apple is light years BEHIND Windows in this regard and has no plans to bring acceleration to legacy GUI drawing function on OS X.

  • by Paradigm_Complex ( 968558 ) on Thursday December 25, 2008 @06:57PM (#26232087)

    Does that just mean the addition of new drivers or a revamp of the existing? I have some no name wifi usb that uses zd1211rw and it's pretty easy to make it fall over.

    I'm not sure about this case, but in the past it has been both. My wireless usb stick (rt73) WAS supported in Ubuntu Dapper (and Edgy?) but after that it stopped working (required me to throw the firmware into /lib/firmware - once I do that it works fine).

    From that experience I gather that yes, it is possible for them to revamp currently working drivers; however, it would probably be easier for you to just buy a supported card. May be a bit late to ask for it as a Christmas present, sadly.

With your bare hands?!?

Working...