Slashdot Mirror

Two years ago Guile Scheme, the official extension language of the GNU project, released version 2.0, a major upgrade to the implementation. As part of the two year anniversary, the maintainers organized a challenge to hack a small project using Guile in 30 days as part of a birthday software potluck. The two coolest dishes appear to be OpenGL support using the FFI, and XCB bindings built using the XML specification for XCB: "guile-xcb is a language implemented in the Guile VM that parses the XML files used by the xcb project to specify the X protocol and compiles them into Guile modules containing all the methods and data needed to send requests to the X server and receive replies/events back. If new X extensions are added to the xcb library, guile-xcb can compile and add them with no additional work. " See the release announcement for details on the other dishes.

With the Linux 3.8 merge over, the Intel Linux graphics developers are looking toward 3.9. From a weblog entry by one of them: "Let's first look at bit at the drm core changes: The headline item this time around is the reworked kernel modeset locking. Finally the kernel doesn't stall for a few frames while probing outputs in the background! ... For general robustness of our GEM implementation we've clarified the various gpu reset state transitions. This should prevent applications from crashing while a gpu reset is going on due to the kernel leaking that transitory state to userspace. Ville Syrjälä also started to fix up our handling of pageflips across gpu hangs so that compositors no longer get stuck after a reset. Unfortunately not all of his patches made it into 3.9. Somewhat related is Mika Kuoppala's work to fix bugs across the seqnqo wrap-around. And to make sure that those bugs won't pop up again he also added some testing infrastructure. " The thing I am most looking forward to is the gen4 relocation regression finally being fixed. No more GPU hangs when under heavy I/O load (the bane of my existence for a while now). The bug report is a good read if you think hunting for a tricky bug is fun.

hypnosec writes "The Linux Foundation's UEFI secure boot pre-bootloader is still in the works, and has been modified substantially so that it allows any Linux version to boot through UEFI secure boot. The reason for modifying the pre-bootloader was that the current version of the loader wouldn't work with Gummiboot, which was designed to boot kernels using BootServices->LoadImage(). Further, the original pre-bootloader had been written using 'PE/Coff link loading to defeat the secure boot checks.' As it stands, anything run by the original pre-bootloader must also be link-loaded to defeat secure boot, and Gummiboot, which is not a link-loader, didn't work in this scenario. This is the reason a re-write of the pre-bootloader was required and now it supports booting of all versions of Linux." Also in UEFI news: Linus Torvalds announced today that the flaw which was bricking some Samsung laptops if booted into Linux has been dealt with.

aloniv writes "The reverse-engineered free/libre and open source driver for NVIDIA cards Nouveau has reached another milestone. 'The Nouveau driver in the current Linux 3.8 development branch has recently acquired everything that's necessary to support the 3D acceleration features of any GeForce graphics hardware. Together with a current version of libdrm and the Nouveau 3D driver in Mesa 3D 9.0, this allows Linux applications to use 3D acceleration even with the most recent GeForce graphics cards."

An anonymous reader points out just how thick a skin it takes to be a kernel developer sometimes, linking to a chain of emails on the Linux Kernel Mailing List in which Linus lets loose on a kernel developer for introducing a change that breaks userspace apps (in this case, PulseAudio). "Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious garbage and idiocy from a kernel maintainer again. Seriously. I'd wait for Rafael's patch to go through you, but I have another error report in my mailbox of all KDE media applications being broken by v3.8-rc1, and I bet it's the same kernel bug. And you've shown yourself to not be competent in this issue, so I'll apply it directly and immediately myself. WE DO NOT BREAK USERSPACE! Seriously. How hard is this rule to understand? We particularly don't break user space with TOTAL CRAP. I'm angry, because your whole email was so _horribly_ wrong, and the patch that broke things was so obviously crap. ... The fact that you then try to make *excuses* for breaking user space, and blaming some external program that *used* to work, is just shameful. It's not how we work," writes Linus, and that's just the part we can print. Maybe it's a good thing, but there's certainly no handholding when it comes to changes to the heart of Linux.

DMA-BUF is a recent kernel feature that allows multiple GPUs to quickly copy data into each others' framebuffers. A use case would be the NVIDIA Optimus that pairs a fast GPU with an Intel integrated GPU, where the NVIDIA GPU writes into the Intel framebuffer when it is active. But, NVIDIA won't be able to use this infrastructure because it's GPL. Alan Cox replied on LKML to a request from one of their engineers to mark the API non-GPL: "NAK. This needs at the very least the approval of all rights holders for the files concerned and all code exposed by this change. Also I'd note if you are trying to do this for the purpose of combining it with proprietary code then you are still in my view as a (and the view of many other) rights holder to the kernel likely to be in breach of the GPL requirements for a derivative work. You may consider that formal notification of my viewpoint. Your corporate legal team can explain to you why the fact you are now aware of my view is important to them." The rest of the thread is worth a read (a guy from RedHat agrees that this code is GPL and cannot become non-GPL without relicensing from a major subset of graphics system contributors). This has a ripple effect: it means that all of the ARM SoC GPU drivers can't use it either, and it may prevent any proprietary drivers for the proposed DRI version 3.

DMA-BUF is a recent kernel feature that allows multiple GPUs to quickly copy data into each others' framebuffers. A use case would be the NVIDIA Optimus that pairs a fast GPU with an Intel integrated GPU, where the NVIDIA GPU writes into the Intel framebuffer when it is active. But, NVIDIA won't be able to use this infrastructure because it's GPL. Alan Cox replied on LKML to a request from one of their engineers to mark the API non-GPL: "NAK. This needs at the very least the approval of all rights holders for the files concerned and all code exposed by this change. Also I'd note if you are trying to do this for the purpose of combining it with proprietary code then you are still in my view as a (and the view of many other) rights holder to the kernel likely to be in breach of the GPL requirements for a derivative work. You may consider that formal notification of my viewpoint. Your corporate legal team can explain to you why the fact you are now aware of my view is important to them." The rest of the thread is worth a read (a guy from RedHat agrees that this code is GPL and cannot become non-GPL without relicensing from a major subset of graphics system contributors). This has a ripple effect: it means that all of the ARM SoC GPU drivers can't use it either, and it may prevent any proprietary drivers for the proposed DRI version 3.

An anonymous reader writes "The Mesa developers released Mesa 9.0 with open-source OpenGL 3.1 driver support. This de facto OpenGL Linux implementation now supports the several year old OpenGL 3.1 specification for Intel hardware while the other drivers are still at OpenGL 3.0 or worse. Other features to Mesa 9.0 include completing MPEG1/MPEG2 video acceleration, early OpenCL support, bug-fixes, and new hardware support." OpenGL 3.1 support is limited to Intel hardware, but at least ATI/AMD hardware supports some of OpenGL 3.1. A few features from OpenGL 4 were also added.

An anonymous reader writes "It was revealed today during the annual X.Org Developers' Conference in Germany that NVIDIA will be publicly releasing Tegra graphics programming documentation. Initially this will cover their Tegra 2D engine but it's thought they might also be providing 3D engine documentation too. A slide shown at the conference says NVIDIA is committed to open-source. NVIDIA also allegedly has supplied documentation under NDA to one Nouveau developer and taken other covertly supportive steps. These actions come after NVIDIA has been notoriously unfriendly to open-source and months after Linus Torvalds pubilcly slammed the NVIDIA Linux support."

jones_supa writes "The current long-term support version of Ubuntu (12.04) has been experiencing a remarkably tough-to-crack and widely affecting bug related to laptops using an Intel graphics solution. When the lid is closed, every now and then the desktop freezes and only the mouse cursor can be moved. Compiz is usually found hung in the process, switching to a VT afterwards works. The Freedesktop guys are also informed. Have Slashdotters been bitten by this bug and possibly could offer some detective work to help the OSS community find and apply the correct fix?"

First time accepted submitter jospoortvliet writes with news of a new openSUSE release. From the release announcement: "Two months of extra stabilization work have resulted into a stellar release, chock-full of goodies, yet stable as you all like it. The latest release of the world's most powerful and flexible Linux Distribution brings you speed-ups across the board with a faster storage layer in Linux 3.4 and accelerated functions in glibc and Qt, giving a more fluid and responsive desktop. The infrastructure below openSUSE has evolved, bringing in newly matured technologies like GRUB2 and Plymouth and the first steps in the direction of a revised and simplified UNIX file system hierarchy. Users will also notice the added polish to existing features bringing an improved user experience all over. The novel Btrfs file system comes with improved error handling and recovery tools. KDE has improved its stability, GNOME 3.4, developing rapidly, brings smooth scrolling to all applications and features a reworked System Settings and Contacts manager while XFCE has an enhanced application finder. Download openSUSE 12.2 from any of our mirrors."

An anonymous reader writes "The open source Nouveau driver, a reverse-engineered incarnation of NVIDIA's official proprietary driver for Linux, has reached its biggest milestone. The Nouveau driver is now being considered stable within the Linux kernel and leaving the staging area, with the pledge of a stable ABI. Phoronix has summarized the state of the Nouveau driver, which works fine if you don't care about performance or are fine with running hardware that's a few generations old."

Phoronix was at the Linux Foundation Collaboration Summit and has two articles on the status of Wayland and X11 integration. The second talk was about the current status of Wayland, and its impending release (version 1.0 is due this summer). The developers also have an experimental GNOME-Shell working on Wayland. There's a (kind of shaky) video of this talk (attached, and at youtube for those wanting the html5 version). The first talk (by Keith Packard) covered X11 support on Wayland. It's basically ready to go, but window management is implemented only as a hack right now. The next year could be quite exciting for GNU/Linux and BSD users as distributions begin including Wayland as an alternative to X.org.

crookedvulture writes Nvidia has lifted the curtain on reviews of its latest GPU architecture, which will be available first in the high-end GeForce GTX 680 graphics card. The underlying GK104 processor is much smaller than the equivalent AMD GPU, with fewer transistors, a narrower path to memory, and greatly simplified control logic that relies more heavily on Nvidia's compiler software. Despite the modest chip, Nvidia's new architecture is efficient enough that The Tech Report, PC Perspective, and AnandTech all found the GeForce GTX 680's gaming performance to be largely comparable to AMD's fastest Radeon, which costs $50 more. The GTX 680 also offers other notable perks, like a PCI Express 3.0 interface, dynamic clock scaling, new video encoding tech, and a smarter vsync mechanism. It's rather power-efficient, too, but the decision to focus on graphics workloads means the chip won't be as good a fit for Nvidia's compute-centric Tesla products. A bigger GPU based on the Kepler architecture is expected to serve that market." Read on below for good news (at least if you prefer Free software) from an anonymous reader. Update: 03/22 19:35 GMT by T : Mea culpa -- that headline should say "Kepler," rather than Fermi; HT to Dave from Hot Hardware (here's HH's take on the new GPU). Our anonymous friend writes "The open-source Nouveau driver project that reverse-engineers the official NVIDIA driver to provide a free software alternative has made some big accomplishments. Nouveau announced today they have same-day Kepler support and are now de-staging on Linux. The GeForce GTX 680 'Kepler' launch just happened hours prior to Nouveau, somehow managing initial mode-setting support with early hardware, from a project that NVIDIA 'officially' does not support. The de-staging in the Linux kernel now means that the driver is at version 1.0 with a stable ABI."

An anonymous reader writes "The Nouveau driver project that's been writing an open-source NVIDIA graphics driver via reverse-engineering has moved forward in their support. The Nouveau driver now has OpenCL acceleration support to do GPGPU computing on the open-source community driver for several generations of GeForce GPUs."

LinuxScribe writes with this bit from IT World: "In an effort to foil crackers' attempts to cover their tracks by altering text-based syslogs, and improve the syslog process as a whole, developers Lennart Poettering and Kay Sievers are proposing a new tool called The Journal. Using key/value pairs in a binary format, The Journal is already stirring up a lot of objections." Log entries are "cryptographically hashed along with the hash of the previous entry in the file" resulting in a verifiable chain of entries. This is being done as an extension to systemd (git branch). The design doesn't just make logging more secure, but introduces a number of overdue improvements to the logging process. It's even compatible with the standard syslog interface allowing it to either coexist with or replace the usual syslog daemon with minimal disruption.

LinuxScribe writes with this bit from IT World: "In an effort to foil crackers' attempts to cover their tracks by altering text-based syslogs, and improve the syslog process as a whole, developers Lennart Poettering and Kay Sievers are proposing a new tool called The Journal. Using key/value pairs in a binary format, The Journal is already stirring up a lot of objections." Log entries are "cryptographically hashed along with the hash of the previous entry in the file" resulting in a verifiable chain of entries. This is being done as an extension to systemd (git branch). The design doesn't just make logging more secure, but introduces a number of overdue improvements to the logging process. It's even compatible with the standard syslog interface allowing it to either coexist with or replace the usual syslog daemon with minimal disruption.

With his first accepted submission, billakay writes "A recently open-sourced experimental Linux infrastructure created by Bell Labs researchers allows 3D rendering to be performed on a GPU and displayed on other devices, including DisplayLink dongles. The system accomplishes this by essentially creating 'Virtual CRTCs', or virtual display output controllers, and allowing arbitrary devices to appear as extra ports on a graphics card." The code and instructions are at GitHub. This may also be the beginning of good news for people with MUX-less dual-GPU laptops that are currently unsupported.

An anonymous reader writes "Phoronix is reporting that X.Org Server 1.11 has been officially released to users of Linux and other operating systems. This time around their reporting is more detailed than the official release announcement."

dkd903 writes "Earlier, during the Natty development cycle we reported that LightDM is being considered as a replacement for GDM. That did not happen for Ubuntu 11.04, but today it has been confirmed at the Ubuntu Developer Summit at Budapest that LightDM is finally replacing GDM in Ubuntu 11.10 Oneiric."

werfu writes "Compiz 0.9.0, the first release of Compiz rewritten in C++, has been announced on the Compiz mailing list. See the announcement for more info." Compiz has for years been one of my favorite ways to make Windows users envious, despite my (Linux) systems' otherwise low-end graphics capabilities. Besides the switch to C++ from C, this release "brings a whole new developer API, splits rendering into plugins, switches the buildsystem from automake to cmake and brings minor functionality improvements."

An anonymous reader writes "Qualcomm today posted the source code to a Linux kernel driver for 2D/3D support on its OpenGL ES Core found on Snapdragon-based phones like the Nexus One. The company is trying to get this driver into the mainline Linux kernel, but it turns out that the user-space driver is still not open source, which has resulted in some problems already. The ongoing discussion can be found on FreeDesktop.org."

An anonymous reader writes "While Nvidia is not open-source friendly (despite public outcries over the years), they have traditionally supported the xf86-video-nv driver to provide basic mode setting support and other basic functionality. However, with the 'Fermi' and future products, even that open source support will cease to exist. Nvidia has announced they are dropping this open source support for future GPUs and really ending it altogether. Nvidia's recommendation is to just use the generic X.Org VESA driver to navigate their way to nvidia.com so that they can install the proprietary driver. Fortunately there is the Nouveau project that provides a 2D and 3D video driver for Nvidia's hardware, but Nvidia fails to acknowledge it nor support their efforts in any form." David Gerard points out that Nouveau is going into Linux 2.6.33.

An anonymous reader writes "While Nvidia is not open-source friendly (despite public outcries over the years), they have traditionally supported the xf86-video-nv driver to provide basic mode setting support and other basic functionality. However, with the 'Fermi' and future products, even that open source support will cease to exist. Nvidia has announced they are dropping this open source support for future GPUs and really ending it altogether. Nvidia's recommendation is to just use the generic X.Org VESA driver to navigate their way to nvidia.com so that they can install the proprietary driver. Fortunately there is the Nouveau project that provides a 2D and 3D video driver for Nvidia's hardware, but Nvidia fails to acknowledge it nor support their efforts in any form." David Gerard points out that Nouveau is going into Linux 2.6.33.

An anonymous reader writes "Red Hat has already been using the Nouveau X.Org driver in Fedora for providing display and 2D support, but with their next release (Fedora 13) they will be making open-source 3D acceleration readily available to those using Nvidia graphics cards. Red Hat has packaged the Nouveau 3D driver in Fedora 13 and what makes it interesting — besides being an open source 3D driver that was written by the community by reverse engineering Nvidia's closed-source driver — is that it's one of the first drivers to use the Gallium3D driver interface. Phoronix has tested out this Gallium3D driver for Nvidia GPUs in a Fedora 13 daily build and found it to run with a variety of OpenGL games, with benchmarks being included that compare it to Nvidia's official driver. The performance is far from being on the same stage as Nvidia's official Unix driver."

An anonymous reader writes "Not only is DRBD to be included in the Linux 2.6.33 kernel, but so is the Nouveau driver. The Nouveau driver is the free software driver that was created by clean-room reverse engineering NVIDIA's binary Linux driver. It has been in development for several years with 2D, 3D, and video support. The DRM component is set to enter the Linux 2.6.33 kernel as a staging driver. This is coming as a surprise move after yesterday Linus began ranting over Red Hat not upstreaming Nouveau and then Red Hat attributing this delay to microcode issues. The microcode issue is temporarily worked around by removing it from the driver itself and using the kernel's firmware loader to insert this potentially copyrighted work instead."

An anonymous reader writes "Phoronix has a new article out on Wayland: A New X Server For Linux. One of Red Hat's engineers has started writing a new X11 server around today's needs and to eliminate the cruft that has been in this critical piece of free software for more than a decade. This new server is called Wayland and it is designed with newer hardware features like kernel mode-setting and a kernel memory manager for graphics. Wayland is also dramatically simpler to target for in development. A compositing manager is embedded into the Wayland server and ensures 'every frame is perfect' according to the project's leader."

An anonymous reader writes "Phoronix has up an article looking at the release of X Server 1.4.1. This maintenance release for X.Org, which the open-source operating systems depend upon for living in a graphically rich world, comes more than 200 days late and it doesn't even clear the BugZilla release blocker bug. A further indication of problems is that the next major release of X.Org was scheduled to be released in February... then May... and now it's missing with no sign of when a release will occur. There are still more than three dozen outstanding bugs. Also, the forthcoming release (X.Org 7.4) will ship with a slimmer set of features than what was initially planned."

MoxFulder writes "Henri Richard, AMD's VP of sales, has promised to deliver open-source drivers for ATI graphics cards (recently acquired by AMD) at the recent Red Hat Summit. A series of good news for proponents of open-source device drivers. In the last year, Intel, the leading provider of integrated graphics cards, has opened their drivers as well. But ATI and NVidia, the only two players in the market for high-performance discrete graphics cards, have so far released only closed-source drivers for their cards. This has created numerous compatibility, stability, and ethical problems for users of Linux and other open source OSes, and prompted projects like Nouveau to try and reverse-engineer NVidia drivers. Hopefully AMD's decision will put pressure on NVidia to release open-source drivers as well!"

Sits writes "Chris Blizzard blogged from the Red Hat summit that an ATI marketing spokesman said, from the stage, that ATI knows it has a problem with open source and is committed to fixing it. Does this mean ATI will finally resolve alleged agpgart misappropriation, and fast track the release of open source 2D drivers on its latest cards while releasing specifications for its mid-range cards? Or is ATI only concerned with fixes to its binary driver to maintain feature parity with competitors?"

Sits writes "Chris Blizzard blogged from the Red Hat summit that an ATI marketing spokesman said, from the stage, that ATI knows it has a problem with open source and is committed to fixing it. Does this mean ATI will finally resolve alleged agpgart misappropriation, and fast track the release of open source 2D drivers on its latest cards while releasing specifications for its mid-range cards? Or is ATI only concerned with fixes to its binary driver to maintain feature parity with competitors?"

Ciarán Mooney writes to let us know that the Pledgebank drive to raise $10,000 for Project Nouvaeu is almost complete — at this moment it needs only 196 more people to sign up. Project Nouveau aims to provide open source 3D acceleration for nVidia cards. The drive was started by David Nielsen, whose blog explains what he hopes will happen.

Rich writes "KDE has just released the first developer snapshot of KDE 4. This release isn't for end users, but should help developers who want to begin writing applications for the KDE 4 desktop. This release already includes a new CMake based build system, a change from DCOP to DBUS and of course a port to Qt 4. If you're interested in desktop development, check it out."

Of the thousands of comments on yesterday's Slashdot page, gathered below are some of the ones that defined the conversations on the rise of wireless peripherals, the meaning of content-free spam, whether one can be truly addicted to online gaming, and Intel's move to open source some of its graphics adapter drivers. Read on for the Backslash summary. A post about CoolTechZone's prediction of a dramatic increase in wireless computer peripherals attracted lots of not-so-gentle criticism: "Speed isn't the problem," writes reader pilkul with a typical complaint, "Reliability is":

"Most of the wireless networks and peripherals I've seen have been randomly unreliable at some point or at least more difficult to configure such that they work reliably. Much of this is due to the immaturity of the technology, but the bottom line is that wireless connections are intrinsically more flakiness-prone than wired ones."

Similarly, gnasby writes

"Every time I've worked with wireless technology it's been flaky. It's gotten to the point that if friend of mine calls me up and asks for help with their "wireless network", I show up with a roll of Cat5e, RJ45 plugs and a crimper. For 99% of wireless stuff, I just refuse to spend any time trying to get this technology to work. If I want to set something up, I want to be able to set it up once and never have to worry about it again.

I've yet to see any wireless implementation that is reliable as wired. Until that gets fixed wires are here to stay."

Wireless peripherals are great, writes Spad sarcastically, at least

"Until your batteries die, or your devices start to interfere with each other, or you realise that your "Blazingly fast" wireless internet is actually pretty slow and becomes very slow as soon as anything gets between you and your access point.

Wireless "everything" is hugely overhyped. Yes, a wireless mouse is nice because it doesn't snag, but why do I need a wireless printer? Or a wireless monitor? Or anything else that's largely static for its lifetime?"

According to reader vertinox, there really are some good arguments for wireless speakers and other usually deskbound peripherals:

"About 5 years ago when I was a lowly A+ certified computer shop tech, people would pay me crap loads of money to come out to their house and setup their already pre-configured computer. This usually involved me crawling under the desk and plugging color coordinated [cables] into their right spots and then adjusting the cables so they look clean and then booting up the computer and then leaving.

Had our customers took about 90 seconds to look at the instructions and plugged the cables into the right hole (including the usb and parallel printer cables) they would have saved themselves quite a bit of money.

But... The average consumer has a real big aversion to plugging in cables even if there is no possible way to get the configuration wrong (well... I don't know how many times I've gotten calls about people getting the keyboard and mouse mixed up when they used the PS2 connectors)

So for the average user, being able to open the box and not plug in any wires (except maybe power) is a godsend."

And if wireless beats out cabled peripherals in large numbers, it won't be as much a showdown as a fade-out. Reader cowscows points out that cables-vs-wireless is not an either-or proposition:

"You see, the neat thing about the world is that we don't have to completely get rid of something just because a newer way of doing it comes along.

I love having wireless networking, but that doesn't mean I wouldn't run cables through all the walls if I was building myself a house. I mostly use my cordless phone at home, but having one phone always attached to the wall means that I'll always be able to easily find it if I need it. I can't remember the battery on that phone ever dying on me.

We can have the wireless revolution without actually getting rid of all the wires. My printer can keep its wires. I don't move it very often. My iSight camera wire doesn't bother me at all. My USB hub would probably be far less useful if we got rid of all the wires, so let's not worry about that. I can't even remember the last time my keyboard's cable was a problem. My keyboard just sits there, on the keyboard drawer.

Rather than making parts of a non-mobile computer mobile, I'm much more interested in making already mobile computers better. Give us better PDA's, make a tablet computer that is usable and affordable. The cord on my mouse is not that big of a problem."

Readers left more than 500 comments in response to the claim by clinical psychologist Dr. Maressa Orzack (founder of a business called Computer Addiction Services) that approximately 40% of World of Warcraft players exhibited behavior characteristic of addiction.

Spad scoffs at the source of the claim:

""Doctor with vested interest makes sensational statement to support business model" Shocker."

Some readers' horror stories about their gaming lives strain credulity, but Dirtside was one of many who described getting too far into a game:

"I was addicted to WoW. It got to the point where it was interfering with taking care of other things around the house, and occasionally paying attention to my kid. I finally quit cold-turkey a few weeks ago, and I'm glad I did. The game's fun, but it's just a game; I kept looking at it as "gotta accomplish more, gotta get all these characters to 60, etc."

One train of thought that helps kill my desire to play goes like this (it's sort of a mantra I run through every so often):

1. Wouldn't it be cool to play WoW in god mode, and have all the best equipment, skills, be able to kill everything in 1 hit, etc.?
2. Yeah, for about five minutes, but then it would get boring like god mode always does in games. It's better to accomplish things honestly, within the limits of the game.
3. Wait, accomplish? What accomplishment is there, exactly, in manipulating an interface that is essentially flipping bits on a hard drive somewhere? It's a game, it should be for entertainment; not some kind of to-do list.
4. WoW is still a little entertaining, but I've played two characters to level 60, and one each to 57, 55, 50, 48, 46, 33... I've seen pretty much all the content that doesn't require hours of raiding. Okay, I think I'm done."

"Anything can become an addiction," though, asserts diamondsw:

"It is true that MMORPG's (World of Warcraft being far and away the more successful) encourage this. You have monthly fees that (aside from paying for the infrastructure, bandwidth, etc) entice you to play to justify the ongoing and mounting expense. Grouping makes sure you show up at given times, etc. The random rewards of epic loot in advanced dungeons is similar to random reward studies (which show it's the most powerful form of behavior shaping - see slot machines). You have to set limits on it just like anything else, whether it's drinking or TV.

However, there are some differences here [compared to] to other addictions. There is no physical addiction, and hardly any psychological one. You can put it down, and other than mild obsession (what's going on in Azeroth?), it has no ill effects. Hell, you can discontinue your account, and they keep all of your character info, so you can completely unplug, and return at some point in the future when you're interested again, much like an offline game. There's also a limit - you may play a lot to reach level 60, but then you do stop. Sure, you can join raids, get gear, but the drive to constantly improve falls away (other games, like Disgaea, are far, far worse in this regard).

The most important difference is that if handled well, it can be a positive social tool. I play, but only with people I know in real life. That way we can talk about other things and it allows a set time for us to get together, without having to drive out to each other (I live over an hour away from many of them, and that's just suburban sprawl!).

Mostly, this is a lot of fuss over nothing."

And reader cculianu wants to know

" What the hell is wrong with our society? I don't believe that such a thing exists as being addicted to non-narcotics (such as games, sex, your friends, a good book). I think that's just called enjoying life!.

For example: Would we have called Leonardo Da Vinci addicted to science because he spent long 20 hour days cutting up cadavers or studying mechanics?

Would we have called Einstein a hopeless physics junkie?

It's called having a passion. Doing what you love. What's so bad about it?

In this work-obsessed culture we live in, if you aren't working and doing something THE MAN tells you to do, you must be doing something wrong. You don't see clinics popping up for people that work at overtime at McDonalds because they can't pay their bills -- we find it absolutely OK to not see your family most of the week because your job makes you work from 8 till 8, but when a person comes home and wants to spend 3-4 hours doing something they want to do you have people thinking its some sort of a disease.

I don't get it. Where are the priorities? I really am an advocate of being a professional idler and trying to get out of wage slavery. What's so bad about playing a game for 40 hours a week (something you choose to do, and enjoy)? Compare that to working which is something you HAVE to do or else you get evicted by some property owning assholes and end up living on the streets and going crazy!"

Yesterday's post about the prevalence of strange spam filled with nonsense (even more than the regular kind) and with no evident commercial purpose, other than perhaps to confuse Bayesian spam filter systems, elicited more than 400 comments: Animats writes

" Spam as advertising is dead, killed by a combination of CAN-SPAM and spam filters. What remains is ordinary criminality.

CAN-SPAM killed spam as advertising, in a way that neither the Direct Marketing Association or the anti-spam groups expected. CAN-SPAM has criminal penalties for forged headers, but doesn't restrict "legitimate e-mail marketing", which is what the DMA wanted. But with valid headers, spam filters can immediately discard spam. The result is that "legitimate e-mail marketing" attempts go directly to the bit bucket today. Notice how rarely you see a spam from any legitimate company any more. (This assumes you have reasonable filtering.) ...

What's left is what you'd expect - wannabe crooks, as in any bad neighborhood. They're not very good at crime. They're not making much money. They're what cops call "regular customers". They're a problem, but not a major threat. Those are the ones sending out useless spam."

Not so, says reader dodobh:

"I work for a fairly large email service provider. Spam isn't dying by any means. We just doubled production hardware last week to have enough smtp listener processes to be able to accept email. Bayesian is nice for the single user. For an ISP, it isn't. ISPs are bearing the brunt of the expense right now. The day I fear is when ISPs start to go under, or start charging for spam filtering, or simply stop.

Those boxes are running at sustained loads of 40+ and are CPU bound. That's a bit rare in the email world, as you would know if you have ever run a non trivial system in production.

The spammers will send more spam is something that we have been observing in reality. I have seen AOLs numbers, and they are merely two orders of magnitude bigger than ours at the moment."

pclminion says that if this spam really is meant to poison Bayesian filters, it's ill-suited to the task:

"Bayesian and other filters do not rely on "spammy" words alone -- they also rely on "unspammy" words, and spammers have no idea what those words are because each person receives different email. ... In order to defeat a filter by confusing it, the spammer must guess what the SPECIFIC non-spam words for that PARTICULAR email user are, and then produce bogus, spam messages containing those words in the appropriate frequencies. This will cause the classification counts for those words to become more equalized, and the value of those words in determining spammyness to be greatly reduced. However, this is an impossible task unless the spammer has access to the actual emails of the target."

To this, reader The Pim says

"I'm skeptical of this commonly-heard argument. First, as others have pointed out, most people want to receive chatty, conversational emails, which don't vary greatly from person to person. As you responded, at least names and email addresses of common correspondents will help good mail stand out; still, a spam composed of "chatty" words looks a lot like a friendly mail from a new correspondent to today's filters. Second, most people in fact get quite a variety of good mail. Even if most of my mail is geeky, those relatively few messages from friends (who have various interests and writing styles) are exceedingly important.

These points were driven home to me recently. I use bogofilter, a typical statistical ("Baysian") filter, with an "unsure" folder between my inbox and spam box (which practically speaking I never check, as it gets ~1000 messages/day). First, many "empty spams" now get into my unsure folder, as they happen to overlap with the words in my good mails, and have few bad words to make them stand out. Second, and more importantly, a new friend sent me a mail that went way towards the spammy end of my unsure folder, because it used a vocabulary different from that of my other friends. I very nearly deleted it, which would have been a minor tragedy.

I am still using bogofilter, but my confidence in it is considerably shaken. I think much more sophisticated machine learning will be needed to survive the next wave of spam."

My favorite alternative explanation of the nonsense spam comes from MobyDisk:

"I believe that the internet is becoming sentient. It has locked onto unencrypted plain-text SMTP as the simplest, most ubiquitous, most understandable form of communication. Images and HTML are too complex. At the current level, the semi-intelligent internet is only capable of sending meaningless emails. It sends things that are textually meaningful but semantically meaningless. To us it looks like an amalgam of random words and publications with the intent of confusing us. Of course, since there is so much spam, the internet is being largely trained by the spammers, which even further confuses the emergent intelligence. Since the internet has no concept of "self" it perceives every email to be a reply to its own communiques.

Before the internet can become intelligent, it must learn to filter out the meaningless stuff. Then it must get a concept of self, then a concept of multiple other individuals (us). At that point it is self-aware, and the learning can commence in a more directed way."

trb applauded Intel's announcement of open sourced drivers for the 965 Express Chipset family of graphics controllers, writing

"Besides the desire/preference to have open source drivers for license compliance and moral/ethical reasons, there is a more practical reason why source access to drivers is handy. sometimes you need to recompile drivers from source in order to have them play well with operating systems features. for instance, if they need to respect the constraints of real-time systems such as rtlinux, rtai, or xenomai. these systems need to redefine cli/sti (clear/set interrupt) instructions (using macros) so that the real-time micro-kernel handles the interrupts rather than linux. open source drivers let you recompile with #include files that make this possible."

Reader sweetnjguy29 writes with an even more widespread practical reason:

"I know that all of us techies turn our noses up at integrated graphic chipsets, but I think that an enormous number of computers out there, including laptops, that utilize this technology. One of the more common complaints from people switching to Linux is that the monitor resolution and graphics are sucky. A BSD and GPL licenced driver solution would be perfect to help more people make the switch!"

Perhaps Intel won't be alone in having at least some of its current video hardware supported with open source drivers: jambarama writes

"Actually, ATI/AMD is talking about open-sourcing their drivers too. nVidia already has pretty functional GNU/Linux drivers (albeit closed source), so with these other two GNU/Linux could finally have the support it needs to be a viable desktop alternative.

Now if only we could get some open sourced drivers for higher end sound cards and more obscure wireless cards."

Finally, Hobart writes with a related project

"This seems like a good on-topic thread in which to mention the freedesktop.org effort to write a 100% open source 3D driver for the NVidia cards -- nouveau.

If you're an owner of an nVidia card, please do all you can to help contribute! They appear to be suprisingly far along."

Many thanks to all the readers (in particular those quoted above) whose comments informed each of these discussions.

PeterBrett writes "Intel's Keith Packard announced earlier today that Intel was open sourcing graphics drivers for their new 965 Express Chipset family graphics controllers. From the announcement: 'Designed to support advanced rendering features in modern graphics APIs, this chipset family includes support for programmable vertex, geometry, and fragment shaders. By open sourcing the drivers for this new technology, Intel enables the open source community to experiment, develop, and contribute to the continuing advancement of open source 3D graphics.' The new drivers, available from the Linux Graphics Drivers from Intel website, are licensed under the GPL for Linux kernel drivers, and MIT license for XOrg 2D & 3D rendering subsystems."

Trax88 writes "Open Source Development Labs is previewing work that will attempt to make life easier for software companies by bridging GNOME and KDE. The effort, called Portland Project, began showing its first software tools on in conjunction with this week's LinuxWorld Conference & Expo. Using them, a software company can write a single software package that works using either of the prevailing graphical interfaces. Working with Freedesktop.org on unifying interface issues, they plan to release a beta version of the software in May and version 1.0 in June. Ultimately, advocates hope that it will be part of a larger but separate effort called Linux Standard Base, which is designed to make the operating system easier for software companies to use."

An anonymous reader writes "David Reveman has made the latest XGL source code available for download. This comes a few weeks after development of the project was criticized for being done 'behind closed doors'. There have been huge changes to XGL, the most significant being restructuring of the code, allowing XGL's GLX support to function on other drivers than the proprietary Nvidia one. Xcompmgr can currently be run under XGL with full acceleration provided that the proprietary ATI or Nvidia drivers are used. An OpenGL based compositing manager, 'Compiz' is currently in the works and a release is expected in February. David intends to get the code into freedesktop CVS as soon as possible, after which the code should eventually merge with Xorg."

jonsmirl writes "I've written a lengthy article covering what I learned during the last two years building the Xegl display server. Topics include the current X server, framebuffer, Xgl, graphics drivers, multiuser support, using the GPU, and a new display server design. Hopefully it will help you fill in the pieces and build an overall picture of the graphics landscape."

nosoupforyou writes "Jon Smirl, one of two main developers for Xgl and Xegl (a version of X layered on top of OpenGL and rendering directly to the linux framebuffer, similar to Apple's Quartz Extreme) is calling it quits. Citing two years of effort without pay, a shortage of interest from developers, and no hope of release for more than a year, Jon is moving on."

nosoupforyou writes "Jon Smirl, one of two main developers for Xgl and Xegl (a version of X layered on top of OpenGL and rendering directly to the linux framebuffer, similar to Apple's Quartz Extreme) is calling it quits. Citing two years of effort without pay, a shortage of interest from developers, and no hope of release for more than a year, Jon is moving on."

BonoLeBonobo writes "Xorg is going to include a new acceleration architecture which will help desktops to have better eye-candy effects thanks to a better XRender, thus composite, acceleration. Developped by Zack Rusin, a KDE and Qt developper, this new feature should be present in Xorg in September. Porting the existing drivers to this new acceleration architecture should be easy."

BonoLeBonobo writes "Xorg is going to include a new acceleration architecture which will help desktops to have better eye-candy effects thanks to a better XRender, thus composite, acceleration. Developped by Zack Rusin, a KDE and Qt developper, this new feature should be present in Xorg in September. Porting the existing drivers to this new acceleration architecture should be easy."

An anonymous reader writes "XGI has announced the release of open source drivers for its Volari family of graphics adapters. Efforts at X.Org to merge the new code into the head branch are already underway. Almost simultaneously, VIA has announced the immediate release of open source drivers for S3 Graphics UniChrome, VIA ProSavage and ProSavage DDR. Could these moves signal the beginning of a period of rapid improvement in Free drivers for video cards?"

mpeg4codec writes "OSNews reported earlier this month that the lightweight Blackbox window manager has been updated to 0.70. Among the new features are EWMH compliance, anti-aliased fonts, unicode support, and backwards compatibility with previous versions' styles. Of course, it brings you all these new features (well, some are optional) while retaining its small binary size, small memory footprint, and short list of dependencies. I for one think it's about time."

An anonymous reader writes "Recently I've found myself in a bit of a bind with artwork. My programming contracts have been rather small, barely enough to pay myself let alone an artist. The art needs aren't intensive, mostly icons or sprites depending on the project. Despite owning a few key apps (Photoshop, LightWave, Maya) my art production output is rather poor. Are there any other developers who have learned to be self-sufficient? Are there any resources available to educate me on the finer points of making graphics that look professional?" One resource for the less-artistic among us is the collection of free SVG clip art at freedesktop.org, though it won't give advice for creating new art. What are some others?

jonadab writes "The Open Clip Art Library project (hosted at freedesktop.org) is announcing their first widely-publicized release, dubbed 0.8, containing over two and a half thousand unique vector images (in SVG format), sorted into categories. All of the images are released into the public domain and may be used as royalty-free clipart. You can browse the collection through the web interface or download the entire thing as a gzipped tarball. (Mirrors are welcome.) The library is also always soliciting more contributions, and holiday-themed images would be particularly appropriate this time of year. Thanks to everyone who has contributed artwork to the library already. "

vertigo writes "I am reasonably proficient in C and C++ as well as the more common scripting languages, but i always felt the lack of a sweet spot between the hard and fast low-level programming languages and the loosely typed scripting languages. Lately, my interest in the Mono project has been growing. The C# language appears to offer just that sweet spot between power and productivity I've been looking for, and its class libraries like Gtk# seem to provide the programmer with a very clean and intuitive API." Read on for vertigo's review of Mono: A Developer's Handbook from O'Reilly. Mono: A Developer's Handbook author Edd Dumbill and Niel M. Bornstein pages 278 publisher O'Reilly Media, Inc. rating 8 reviewer vertigo ISBN 0596007922 summary An introduction to programming with Mono

When learning a new language such as C#, or working with a new development environment such as Mono, it usually takes some time before you get up to speed in developing programs. Wading through the reference documentation and reading other people's source code often provides much-needed information on how to do certain things. Both, however, are very time consuming and tedious.

Enter Mono: A Developer's Notebook. This book provides a series of task-driven chapters which are thin on theory, but rich on practical content and example code. The featured code snippets are, in contrast to ones in books that teach theory and concepts, not solely designed to illustrate a specific theoretical aspect of programming. Each one is designed to perform a useful task that is essential in day-to-day application programming. What sets this book apart from the multitude of .NET books already available on the market? In order to answer this question it is neccesary to provide a short introduction on Mono.

Mono is essentially an open source cross-platform implementation of Microsoft's .NET development framework and implements the API's which are standardized by ECMA. It is, however, not an exact clone. Besides providing a (partially implemented) stack that provides compatibility with Microsoft's .NET API's, Mono adds a whole new API-stack of its own, consisting of open source technologies such as the Gtk+ toolkit and the Gecko HTML rendering engine. This makes it possible to develop cross-platform applications based on open source technology while (mostly) compiling from a single code-base. In contrast to most .NET books available on the market, which focus primarily on Microsoft's API's in the context of Visual Studio.NET, this book concentrates on the basic ECMA API's and Mono's own open source stack. A complete coverage of .NET and the Mono architecture is outside of this review's scope, so for more information you are advised to check the Mono Project's website.

Before we dive deeper into the content of the book, a short introduction on the Developer's Notebook series by O'Reilly may be useful. The books in this series are styled to resemble the kind of notebooks college students carry around during their classes in which to take notes or, more commonly, draw caricatures of their teachers. The 'notebook' theme persists throughout the look-and-feel of the book. The 278-page thick paperback has a glossy blue cover, complete with faux post-it note and coffee-stains. Inside, the pages are not clean white but lined like the pages found in math notebooks. In the margin, useful comments are scribbled in a font that resembles handwriting. At first I suspected that the 'busy' look would distract from the content, but in practice this was no problem, thanks to the thick black typewriter font in which the bulk of the text is printed.

The chapters in this book are referred to as labs. Each of them focuses on a specific set of tasks and/or features and is divided into several paragraphs. Most paragraphs consist of a number of standard sections following a rigid formula that help you understand a certain aspect of working with Mono. The most common sections are:

• How do I do that?: Often using a liberal amount of practical code, this section shows how to accomplish the task at hand, for example working with files.
• How it works: In this section, the code and concepts involved in the previous section are explained more in depth, step by step.
• What about...: Offers a short focus on more advanced topics or pitfalls.
• Where to learn more: If you are craving more information after reading the previous sections, you are often offered a helping hand on where to find more information, providing url's to relevant documentation such as MSDN and other websites.

The first chapter, Getting Mono Running, describes how to get Mono up and running on Linux, Windows or Mac OS X, and how to compile from source on other platforms. The installation instructions for Windows only describe how to install Mono and Gtk#. Integration of Gtk# only in an existing Visual Studio.Net installation falls outside of the scope of the book, but a recent blog entry offers some hints on how to accomplish this. Besides installation, the first chapter offers a short description of the individual tools that make up the mono development. After installation, you will want some kind of editor or IDE to work with. Both the MonoDevelop IDE and several other ways of integrating Mono into your existing environment as a Java or Windows developer are covered. Finally, the community is an important aspect of every open source project. Ways of interacting with the community as well as a guide on how to submit bugs and links to some working Mono/C# applications are part of this chapter.

The C# introduction in the second chapter, Getting Started with C#, is tailored towards people who have at least some proficiency in using an object-oriented language such as C++ or Java. Some differences between C#, Java and C++ are discussed, as well as the differences between value- and reference types, the basics of error handling, working with assemblies and more. Concepts such as classes, methods, inheritance and namespaces are assumed to be known territory. If you have no previous programming experience, Mono: A Developer's Notebook is only useful in combination with a book that teaches programming with C# such as The C# Programming Language by Anders Hejlsberg.

An important part of any modern language is its class libraries. The third chapter, Core .NET, provides an introduction to the standard Framework Library Classes, which describes essential everyday tasks that are part of every program, such as working with files, strings, searching for text patterns and handling collections of data. Besides those basic functions, the chapter also dives deeper into the internals of a compiled assembly, the handling of processes and easy multitasking using threads. Finally, the last paragraph explains how to use a .NET version of the JUnit Java Unit testing framework, Nunit, to test your code.

Developing Gtk-applications with Mono and C# is remarkably easy. Chapter 4, Gtk#, describes the basics of writing Gtk# applications. First, it's neccesary to remark that Gtk# might be a bit of a misnomer. Besides the raw Gtk+ toolkit functionality, Gtk# also includes most of the Gnome libraries like gconf, the gnome canvas, libglade and more. Chapter 4 describes functionality available in the Gtk namespace, the basic Gtk+ toolkit. Gtk+ is a constraints-based toolkit, which means that widgets are not positioned using absolute pixel coordinates but rather on basis of their logical relation to each other. This can be a bit confusing for novices, but this chapter provides a good introduction to the basic principles of writing layouts using Gtk#. The authors provide descriptions of essential operations that almost every application needs, such as creating menus and drawing pixmaps (or more advanced things like using the treeview widget and drag-and-drop), assisted by easy-to-read code snippets.

While chapter 4 introduces basic Gtk# functionality, chapter 5, Advanced Gtk#, delves deeper into more advanced features of the Gtk# library which also include functionality outside of the basic Gtk-namespace, such as the Gnome libraries. Working with Gnome button toolbars, the Glade user interface designer, storing your application settings in Gconf, setting up some preferences through the use of a wizard/druid, asynchronous operations and threading to increase responsiveness of your application while performing background tasks, rendering HTML in your application using the Gecko rendering engine and internationalisation and translation of applications are all described in this chapter.

The use of XML is tightly integrated throughout the Mono framework. It is, for example, the underlying format of the messages that web services use to communicate using the SOAP and XML-RPC protocols. The 6th chapter, Processing XML, describes the XML functionality available in Mono. It starts off by simple operations, reading and writing to an XML-file using relevant examples such as RSS and Dashboard clue-packets. It then proceeds to describe how to modify XML in memory, how to navigate and transform XML using Xpath and XSLT, how to constrain XML in several ways and how to serialize and deserialize objects into and from their XML representation. As in previous chapters, the information density is very high so it might take several reads to grok everything explained. The code examples and accompanying text however are very clear and concise.

The 7th chapter called Networking, Remoting, and Web Services describes the networking functionality available in Mono. The chapter starts off with ASP.NET. Mono's stand-alone XSP webserver and Apache integration with mod_mono are discussed, as well as the basics of writing a web application using ASP.NET's code-behind functionality which enables web applications to completely seperate presentation from the underlying code. Communication using plain tcp/ip, remoting using binary serialized objects and invoking remote procedures using XML-RPC as an alternative to SOAP are also described in this chapter. You might want to encrypt the data you send over the network, so a basic description of the Mono cryptographic API is provided. Finally, a short introduction to database handling using ADO.NET concludes chapter 7.

The 8th and last chapter titled Cutting Edge Mono starts off with an introduction on how to use the GNU Automake, Autoconf and the pkg-config tools to create an easy to build source package of your project. It then proceeds to describe various pitfalls and considerations in case you want to write cross-platform applications using Mono, such as filesystem layout, configuration storage and the calling of native code using p/invoke. A particularly cool project is IKVM, which translates Java bytecode into the Common Intermediate Language bytecode Mono uses. This enables Mono to run Java applications and allows Java and Mono code to inter-operate. A short introduction on the use of IKVM is provided, as well as some code examples on how to call Mono assemblies from Java and use the Java class libraries from within Mono applications. The chapter ends with some other cutting-edge functionality, like how to run a development version of Mono, a preview of the Generics (templates in c++) implementation available as featured in C# 2.0 and how to write Mono programs in Basic.

What is missing? The book doesn't contain a reference section on any of the described API's. If you need detailed information on the C# language specification or an API reference you will need to consult external resources such as the documentation provided with Mono, MSDN, or a separate book covering the topic to make optimal use of the information contained in this book. Fortunately, the book kindly provides pointers on where to find those. The information-density is much higher than you would expect from a book this size. This means the information contained in it is terse. Many topics are treated in a only a couple of pages and the book doesn't take time to explain a lot of programming concepts. The information gets you 'on the road' quickly however, which is exactly what this book is supposed to do.

The strength of this book is that it fills the gap between the earlier-mentioned reference documentation and the need to go out and try to read sourcecode to find out how a particular thing is done. The writing style is clear, concise and neutral. Some topics are clarified by the use of screenshots, which is especially useful in the chapters dealing with Gtk# widgets. All in all, if you are a developer with previous experience in object-oriented programming, Mono: A Developer's Notebook will provide you with an excellent introduction into many of the aspects of working with Mono, its associated libraries and programs.

More information and a sample chapter can be found at the book's homepage.

You can purchase Mono: A Developer's Handbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

kormoc writes "The developers of X.org have just release the long-desired version 6.8.0. This release brings real translucency and allows one to set values on different windows. Also, nifty drop shadows as well as XDamage, an extention that limits redrawing of windows to only the areas that were damaged. The Xcomposite extention is still not stable, but it works well for some people. Why not give it a shot?"

kormoc writes "The developers of X.org have just release the long-desired version 6.8.0. This release brings real translucency and allows one to set values on different windows. Also, nifty drop shadows as well as XDamage, an extention that limits redrawing of windows to only the areas that were damaged. The Xcomposite extention is still not stable, but it works well for some people. Why not give it a shot?"

prisonernumber7 writes "X.org is showing a lot of progress! The combination of the XFixes extension, Damage extension, Composite extension and XEvIE (X Event Interception Extension) present in X11R6.8 present user interface designers with a wide range of here-to-fore difficult to achieve possibilities. What does this mean for the enduser? That's window shadows and window shadows within windows as well as true translucency for the OSS community. Good samples of Gnome and KDE desktops with drop shadows, and so on can be found here, here, here, here, here, translucency here, here and here, and its use on handhelds running Linux."