Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×

X.Org Releases First Modular Source Roll-Up 176

Posted by ScuttleMonkey from the not-to-be-confused-with-the-fruit-variety dept.
NewsForge is reporting that X.Org has released their first modular roll-up release. From the article: "All X11R7.0 derivative ("modularized") releases divide the source code into logically distinct modules, separately developed, built, and maintained by the community of X.Org developers. This concentrates and accelerates development time, supporting continuous modification, testing, and publication of each module.The new modular format offers focused development, and rapid and independent updates and distribution of tested modular components as they are ready, freed from the biennial maintenance release timetable."
This discussion has been archived. No new comments can be posted.

X.Org Releases First Modular Source Roll-Up More

X.Org Releases First Modular Source Roll-Up

Comments Filter:

  • I wonder (Score:1, Flamebait)

    by overshoot ( 39700 )
    if this will do anything to get 7.0 to a usable state sooner?

    Way-kewl feature list, but about like driving in the Bradshaws: more rock than road.

    • 7.0 release candidates have been working great for me for months now. Of course that is with stock drivers; no proprietary nvidia driver or anything.
    • I'm using Xorg 7 in kubuntu flight 7, never crashed my X once, not even with my proprietry ati drivers.
  • I could not be happier. Modular design clarifies architecture and simplifies targeted enhancements. Better X, faster. What's not to like?

  • Gentoo (Score:3, Informative)

    by binkzz ( 779594 ) on Monday May 22, 2006 @08:13PM (#15384616) Journal
    This should make it a whole lot easier on the Gentoo user machines - we will no longer have to recompile the entire X.Org source on every update.

    I heard rumours of KDE going a similar route in the future.

    • Re:Gentoo (Score:2, Informative)

      by rmsmith ( 930507 )
      KDE is already modularised. See the KDE split ebuilds in portage, for example.
      • Aren't those just the few big ones (ie. kde-base, kde-graphics, kde-games, etc)?

        I meant that KDE could go into thousands of small modules instead (eg., each game being a separate module).
        • They already are. Portage has the kde-meta package which can install the roughly-300 separate components individually.
        • Nah. Every KDE individual component is installable as of Jan 2005. The 'kde-base' and 'kde-graphics' ebuilds are the old monolithic ebuilds. More info here. [gentoo.org]
        • There's two types of KDE ebuilds for it at the moment: the old huge ones and new separate ones. They don't help all that much though, since every time there's a new official release they change the version number for everything so you end up compiling them all one at a time anyway. The split X.Org packages are more useful though, since you can install it without the evil, evil bitmap sans-serif fonts.
          • The bitmap serif fonts are non-evil then?
          • Quiet! You'll make Tuomo Valkonen, author of Ion3 mad. He only linkes bitmap fonts. He's already holding antialiasing support in Ion3 hostage [cs.tut.fi] learns to understand his point of view, if you set him off, there is no telling what he'll do.
    • Have you seen the number of packages [gentoo.org] you need to add to packages.keywords to switch to X.Org 7.0 in Gentoo? There's no way any sane person will do that until they move it all to the stable branch. echo "=x11-base/xorg-x11-6.9.0-r1" >> /etc/portage/package.unmask is the way to go.
      • I guess they could use a meta-package for that.
        It would also be nice if they made a way so that you could have it fairly simple and not install all the stuff you don't need.
        • I'm pretty sure there is a meta-package. The problem is, even if you put the meta-package in package.keywords, it'll still complain about all its dependencies being masked. If I found a good way to import that entire file into package.keywords (Why oh why didn't they provide a version with ~x86 appended to each line? I'm way too lazy to do it in vim.), a simple "emerge xorg-x11" would work.
          • for $p in `cat list.txt` do; echo "$p ~x86" >> done.txt; done
            Or something. The syntax may need fixing - I'm a bit hazy on bash, and I don't have a bash prompt to test it on at work.

            But that's approximately how I solved the problem when I installed it the other week.
          • (Why oh why didn't they provide a version with ~x86 appended to each line? I'm way too lazy to do it in vim.)

            Because you don't have to add the ~x86, it's implicit (just like ~amd64 would be for amd64). Just copy and paste that file into package.keywords. Alternatively, open that file and try this in vim:

            ^[ggqfA ~x86^[jq294@f
            , where ^[ is, of course, the Esc key.
            • Because you don't have to add the ~x86, it's implicit (just like ~amd64 would be for amd64). Just copy and paste that file into package.keywords. Alternatively, open that file and try this in vim:

              ^[ggqfA ~x86^[jq294@f

              , where ^[ is, of course, the Esc key.               ....and then they say that vim is not user friendly! Ha!

              (coming from a long-time vim user)
      • This sane Gentoo user is just waiting for 7.0 to go stable. It might be fun to play with, but I've got less time than I need, right now.

        But the big question...
        Is OpenGL hardware for S3 Savage in 7.0?
        My mom's machine has a KM133, (integrated Savage) and every now and then I'd like to have OpenGL on it, since Grandma's house is the place for Nostalgia Games. (Like Quake1 or Doom-era) But I'm clearly not putting anything but Stable on her machine, since most maintenance is from 600 miles away.
        • The real question is, is an S3 Savage fast enough that you'd even notice whether it was hardware-accelerated or not?! ; )

          But seriously, instead of spending your valuable time (say, $20/hour at the minimum) worrying about drivers, you'd be better off paying $100 on a faster CPU and mobo. You could easily waste 5 hours screwing around with X...

        • Re:Gentoo (Score:2, Interesting)

          by Godji ( 957148 )
          Is OpenGL hardware for S3 Savage in 7.0?

          Yes! A friend of mine with a laptop with one of these cards said that with XOrg 7 came the first time he had hardware-accelerated OpenGL in Linux.

          Please allow me to critisize you for a moment: I've been running 7.0 since it came out (before it was in ~x86 even). I'm perfectly sane. Somebody has to test new software if it is ever to become stable. Also, everyone will have to do the transition sooner it later, so I might as well do it now. The modularized system ha
      • Not for a while now:

        $ cat package.keywords
        ~sys-devel/gcc-4.0.2 -*
        ~sys-libs/glibc-2.3.6 -*
        dev-util/motor ~x86

        $ equery list -p xorg
        [ Searching for package 'xorg' in all categories among: ]
        * installed packages
        [I--] [ ~] app-doc/xorg-docs-1.1 (0)
        [I--] [ ~] x11-base/xorg-server-1.0.2-r4 (0)
        [I--] [ ~] x11-base/xorg-x11-7.0-r1 (0)
        [I--] [ ~] x11-misc/xorg-cf-files-1.0.1-r3 (0)
        * Portage tree (/usr/portage)
        [-P-] [M ] app-doc/xorg-sgml-doctools-1.0.1 (0)
        [-P-] [M~] x11-base/xorg-server-1.0.99.903 (0)
        [-P
        • Wait, if you don't even have xorg-x11 in your package.keywords file, wouldn't you get 6.8.2 installed? How'd you manage without that?
          • It's called running ~arch. It's the only way to fly. ACCEPT_KEYWORDS="amd64 ~amd64" in make.conf in my case. Lots of goodies available without having to fiddle with package.keywords including xorg 7.0 for a while now.

          • Re:Gentoo (Score:3, Informative)

            by EzInKy ( 115248 )

            Wait, if you don't even have xorg-x11 in your package.keywords file, wouldn't you get 6.8.2 installed? How'd you manage without that?


            All three of my machines have "~amd64" or "~x86" in their make.confs.
            • Ah. Well, yea, naturally that solves the problem of specifically adding ~x86 or ~amd64 to each subpackage of X.org 7.0. I guess I should have known when I saw how bare your package.keywords was; mine has at least 15 entries. Un-keyword-masking is a bit too much "new" for my taste, but it's a legitimate strategy.

              • Ah. Well, yea, naturally that solves the problem of specifically adding ~x86 or ~amd64 to each subpackage of X.org 7.0.


                It solves the problem of adding keywords for all "~arch" packages. Sure you run into gotchas every now and then but if nobody tests new software then how can it ever become stable?
                • if nobody tests new software then how can it ever become stable?

                  You're right, of course; I just don't feel that that person has to be me. ;-)

      • Have you seen the number of packages you need to add to packages.keywords to switch to X.Org 7.0 in Gentoo? There's no way any sane person will do that until they move it all to the stable branch. echo "=x11-base/xorg-x11-6.9.0-r1" >> /etc/portage/package.unmask is the way to go.

        # wc -l /etc/portage/package.keywords /etc/portage/package.unmask
        717 /etc/portage/package.keywords
        161 /etc/portage/package.unmask
        878 total

        once you get started, it's hard to stop. i consider myself moderately sane.

        m

    • Yes, but how long will it take for this new revision to be put in portage? Portage takes a while to take a architecture hard-mask off something, so I doubt it will be used by most Gentoo users for a long while. Firefox 1.5 is still hard-masked for x86 I believe...

      • Re:Gentoo (Score:4, Informative)

        by rdwald ( 831442 ) on Monday May 22, 2006 @08:40PM (#15384715)
        There's a difference between hard-masking and keyword masking. Essentially, Gentoo has three levels of packages: "stable," "masked," and "hard-masked." Masking involves just putting a tilde in front of your architecture to get the software. You can use the /etc/portage/package.keywords file to specify packages you always want the masked version of; I've done this with Firefox, for example. There's another level of masking, which is called hard-masking. To remove a hard-mask, you've got to put the package in /etc/portage/package.unmask, and you need to list a specific version of the software you want to unmask. In general, it seems reasonable to have a few masked things installed on your system, but these aren't the same as hard-masked packages.
      • ...so I doubt it will be used by most Gentoo users for a long while.


        The fewer users who test new software the longer it takes for new software to become stable. It's hard to find bugs if nobody is looking.
    • I'm a Gentoo user myself, so I know what you're talking about, but I think they are going modular to make things easier for new developers.

    • Re:Gentoo (Score:5, Funny)

      by Frogbert ( 589961 ) <{frogbert} {at} {gmail.com}> on Monday May 22, 2006 @08:41PM (#15384718)
      That would be really cool. In the meantime though I would like to suggest a system where most common large "packages" of software were compiled and posted some place on the net that Gentoo users could download them. That way everytime there was a point release they wouldn't have to spend ages recompiling. Sure there may be a slight hit to performance but given the inherrent redundancy of compiling the same packages thousands of times on every users computers to just a few times for major architecture it makes sense to me. /runs for cover.
      • So.... you mean that you want to run Ubuntu (or straight Debian, or Fedora, or Mandrake^H^H^H^Hiva, or...)?

        I'm not trying to be insulting, but if you don't want to deal with rebuilding, why do you run Gentoo? I personally don't have the kind of free time that Gentoo seems to requires, so most of the boxes I deal with are Solaris or RHEL.

        • Re:Gentoo (Score:5, Funny)

          by Frogbert ( 589961 ) <{frogbert} {at} {gmail.com}> on Monday May 22, 2006 @09:15PM (#15384824)
                 (J) <--- The joke
                 ...
                 ( )
                __|__     <--- You
                  |
                 / \

          • Re:Gentoo (Score:2, Informative)

            by buysse ( 5473 ) *
            Sorry. After work, where people do seem to be that .. unobservant, it's entirely believable. It does make it hard to spot a joke.

          • Re:Gentoo (Score:1, Insightful)

            by miro f ( 944325 )
            honestly... am I the only one who's sick of seeing this same damn ascii art over and over again?

            it was funny the first time, I think we need to start modding it overrated now

            (yes, I am aware this is slashdot, no I'm not new here, before you ask)
      • In the meantime though I would like to suggest a system where most common large "packages" of software were compiled and posted some place on the net that Gentoo users could download them.

        You're right, that's a great idea. It's called the Gentoo Linux Installer LiveCD [gentoo.org].

      • I know your joking, but it already exists. Firefox, OpenOffice, and a couple other of the large and popular software have binary packages in portage. It's just that they're not teribbly popular and harder to maintain.
        • They are popular among AMD64 users. If you want to use Flash in Firefox you have to use a 32-bit version of Firefox, which means that you either use the binary package or install a semi-separate 32-bit subsystem, having to compile stuff like X11 AGAIN just so that you have all dependencies for the damn 32-bit Firefox fulfilled. The same goes for mplayer and the win32codecs. Binary ebuilds are a godsend for AMD64 users who don't want to lug around two installations of most libraries just to be able to view m
    • I'd be happy if I could just get ATI's drivers to work with Hardened Gentoo.
      • I would have been happy getting them to work (REALLY work) in regular Gentoo. I got them up and going with 3d support, but games ran very slowly and would have oddball grahpical errors (like things missing on screen).

        I ditched the card for a cheapo $50 Nvidia card and all is fine. In the Windows world Ati and Nvidia make for good competition. In the Linux world, if you're serious about it just buy Nvidia to start with.

  • Good thing! (Score:5, Informative)

    by gweihir ( 88907 ) on Monday May 22, 2006 @08:20PM (#15384638)
    A monolithic system with poor or unstable interfaces is a maintenance nightmare. Maybe this explains why in the end XFree86 was so slow in supporting new hardware drivers. I still remember having had to patch the sources manually for my ATI Radeon 9600XT card, just because the PCI ID of that card was still not in the release quite some time after the card was on the market. Really bad.

    With a modular built, they can now change one part, like the drivers, with little fear of introducing problems in other parts. High time this happened. I am looking forward to the things to come.

    • Re:Good thing! (Score:5, Interesting)

      by r_jensen11 ( 598210 ) on Monday May 22, 2006 @08:39PM (#15384710)
      The major drivers that most users have issues with are with the proprietary video drivers, though. We can only hope that this will help us get driver updates as fast as Windows users, but we have no idea if ATI and nVidia are actually going to help the end-users any more than they currently do.

      I think the main thing that this will allow us to do is have more features added/modified, rather than more/newer drivers.

      • You're kidding right? The binary drivers, from nVidia at least, are the only ones that "just work" for anything beyond plain 2D. In the past I spent countless hours searching for a video card that could be purchased off the shelf and used for TV-output/gaming and was forced to pick nVidia simply because of their drivers.

    • The PCI identifier is not something that comes with the release, that is a number assigned to the card based on its position on your motherboard.

      • Re:-1, Wrong (Score:3, Informative)

        by realnowhereman ( 263389 )
        No it's not [wikipedia.org]. Every PCI device has a unique number assigned to it, made up of a vendor code and a product number. The pciids [sourceforge.net] project maintains a useful list of these IDs.

        In addition, each device plugged in to your system gets a PCI address, but that is entirely dependent on your particular system.

        Run "lspci -vv" one day and you can have a look at the information supplied.
      • No, that would be the slot ID, which as others have pointed out, is *completely* different from the VendorID/ProductID tuple burned into every PCI device's ROM to uniquely (or in the case of a few vendors, not so uniquely) identify just what a particular PCI device is.

  • The kernel should go the same way! (Score:3, Funny)

    by bunbuntheminilop ( 935594 ) on Monday May 22, 2006 @08:31PM (#15384681)
    Its like a fasionable thing to do nowdays.

  • X11R7.0 was already modular. (Score:5, Informative)

    by Morty ( 32057 ) on Monday May 22, 2006 @08:39PM (#15384711) Journal
    X.org has been modular for a while -- X11R7.0 was already modular in December 2005. The real news here is that X.org released X11R7.1, not that they've gone modular.

    One thing I'd like to see is an ordered list of dependencies. I still do manual builds on one system, to stay in practice. Building X11R7.0 was so painful, I stuck with X11R6.9. When using a distro that does the heavy lifting, X11R7.0 is great, but sorting out the dependencies in dozens of modules is a PITA if you're trying to build it manually. I bet the distro maintainers are cursing the X.org people.

  • But..!? (Score:5, Funny)

    by hey ( 83763 ) on Monday May 22, 2006 @08:40PM (#15384713) Journal
    So they broke it up into pieces and a we are now celebrating the
    release of the pieces rollde together into a monolithic whole!?

  • Accelerated Indirect GLX! Woowoo. (Score:5, Interesting)

    by Anonymous Coward on Monday May 22, 2006 @08:48PM (#15384743)
    Accelerated indirect GLX has been a until recently been a unattainable holy grain for a long time now in regards to X.

    What this will allow you to do would be allow users to gain some benifits from having hardware acceleration for 3d and multimedia application even when running applications remotely over a network.

    Another way to put it is that applications gain their acceleration not from the hardware directly, but from the Xserver they are running on, which then itself then uses the hardware acceleration.

    It's not going to be as fast or efficient as direct rendering, but it's much more flexible and usefull in a wider context.

    It is another stepping stone to having a fully realised opengl-based X server.

    This is probably very much due to Redhat's AIGLX specificly and xgl development in general.

  • In other words.. (Score:2, Insightful)

    by Brandybuck ( 704397 )
    ...freed from the biennial maintenance release timetable.

    This is just a fancy way of saying packages will be breaking on a weekly basis.

  • XFree86 4.6.0 [xfree86.org] has been released. I thought that project was dead but appearently it isn't completely (yet).

    • Re:In other news ... (Score:4, Informative)

      by msh104 ( 620136 ) on Tuesday May 23, 2006 @04:03AM (#15385466)
      it never died. it's just developing even slower then before. but they did already made another release after the split before this one, which didn't got any coverage on slashdot either. it looks like the open source comminity has choosen to silence it to death. :p
    • Since they managed to piss off almost everyone in the F/OSS community, the Changelog for XFree 4.6.0 has a lot of stuff like:

      3.5.2. XFree86 core server and modules

      Port of SBUS drivers to SunOS variants. This also allows for multihead using a mix of SBUS and PCI devices.

      3.6.11. twm

      Allow environment variables to be used in menu names.

      3.6.10. xclock

      Use the Xaw tooltip to display the date in xclock.

      I mean, they make Debian/stable look like the very model of cutting-edge experimentation. You w

    • The fact that it's moving is only tricking you to think it isn't dead. You'll find out different when it eats your brains.
    • I feel kinda sorry for XFree86. It was a cool project, did some great and vital work, and then the maintainer went insane. It's kinda surprising that he's continuing at all. It can't be very easy to be essentially going it alone.
  • I like to program in Xlib to do various little utilities and games.
    Does anyone know if the core Xlib API has changed going to R7?
  • The most painful thing I do often is display apps running on remote machines with a slow link. Spend 5 minutes waiting for kmail to render, switch to another desktop, switch back, and wait another 5 minutes for it to re-render.

    Does the functionality exist right now to fully buffer that window so that it doesn't have to completely redraw each time? It seems like the Composite extension would solve that problem, but it doesn't seem to be fully ready for production yet.

    • NX helps your situation in general. But to answer your specific question:

      Does the functionality exist right now to fully buffer that window so that it doesn't have to completely redraw each time?

      Yes, its been in X since as long as I can remember. Look for turning "Backingstore" and "Saveunders" on for your specific graphics card. Usually in the video device section of your X configuration file you put...

      Option "Backingstore" "yes"

      But you might have more hoops to go before getting the full save-unders.
  • I've always wanted there to be a way of connecting to X sessions via RDP.

    Yes - RDP is heavily underdocumented, and it's a Windows thing.

    BUT . . .

    There are a huge number of dumb "Citrix" terminals out there in corporate land that only use RDP. If Linux could support these dumb clients connecting, it would remove one of the large costs of migrating to Linux desktops.

    To put it into some perspective, I've been involved in 2 major projects to migrate the desktop from Windows/Citrix to Linux, only to be stopped

Slashdot Top Deals

You knew the job was dangerous when you took it, Fred. -- Superchicken

Close