Slashdot Mirror

Xen was a big hype last year, but more virtualization products for Linux come to light, including OpenVZ, others. It is not just about Xen or VMware anymore. In fact, kernel developers work on a common interface for paravirtualization software. That means users are going to have more choice implementing their kernel containers, whether XenSource stabilizes their product or not.

Speaker David Airlie started with a review of the current state of free graphics drivers. Intel chipsets are relatively well supported, thanks to an enlightened position being taken by that company. ATI is a "former leading light" in the free software world, but is no longer cooperating. Even so, the free R200 driver is feature-complete and, at this point, faster than the binary-only fglrx driver. ...

Why do vendors refuse to support the free software community? David noted, with amusement, that both ATI and Nvidia withdrew support at about the same time that they got Xbox contracts. Let's hope, he says, that Intel never works an Xbox deal.

Nonsense. Address scarcity already means that many users in developing countries are already hidden away behind five(!) layers of NAT.

LWN had an interesting article on ext4 not long ago.

LWN had an interesting article on ext4 not long ago.

Indeed, some of the patents in the patent commons can be withdrawn at any time. It seems to be a half-hearted effort. Why? Look at the companies on OSDL's board. They are the ones that most profit from software patenting.

If you want to understand the truth about the patent commons, start at LWN's coverage of their disclosures.

There is another project called Open Innovation Network, started by Novell, that is supposed to contain patents that really are dedicated for defensive use.

Bruce

Here's a preview of Emacs 22 from lwn.net.

Here's all the new features in Emacs since the last release (very long).

The main thing blocking the release of Emacs 22 is that RMS is bent on obsessively polishing the manuals before even starting an official pretest (which I think is not good prioritization, considering the release process has already taken three years.) But development snapshots of Emacs 22 are already widely available, and the software is in an extremely stable, usable (release-quality, really) state.

Can you give an example of such hardware lock-in? What devices that run Windows can prevent you from running another OS, say Linux? Yes, yes, we've all heard about the Trusted Computing Platform. You can run Linux on it, if you so choose.

Hell, you can even run Rockbox on an iPod instead of the proprietary Apple iPod OS, if you want a DRM free iPod.

As a developer on a gnome project, I can tell you bluntly that additional women would help.

RMS comes to the rescue. Call it "free software" and women will rush giving a hand.

nobody has the resources to check such things as recording tv or radio programs on your home pc, tape deck, etc.

LISA is of the highest quality (like being back in college for all of the best reasons.) There is also OSCON and check for items of interest on LWN's Events Page.

Please read
  http://lwn.net/Articles/178550/

"For now, at least. History suggests that Sveasoft will
continue to push the boundaries of the GPL. Recent history
also suggests, however, that Sveasoft may become less
relevant in this area; by many accounts, the fully-free
alternatives - beyond OpenWRT itself - go beyond the
Sveasoft offerings in a number of ways."

Maybe they are not violators technically, but I'd be
very irritated if I was a customer of their product.

It was a very interesting piece. It talked about the problems of locking (more locks makes deadlocks easier, but they get harder to track down) and the way the code went about finding problems. Basically it remember when any lock was taken or released, which locks were open before that, etc. Through this it can produce warnings. For example if lock B needs lock A, but there is a situation where lock B is taken without A being taken it will flag that.

The article has MUCH better descriptions. But through the use of this the software can find locking bugs that may not be triggered on a normal system under normal loads. Here is summary bit:

"So, even though a particular deadlock might only happen as the result of unfortunate timing caused by a specific combination of strange hardware, a rare set of configuration options, 220V power, a slightly flaky video controller, Mars transiting through Leo, an old version of gcc, an application which severely stresses the system (yum, say), and an especially bad Darl McBride hair day, the validator has a good chance of catching it. So this code should result in a whole class of bugs being eliminated from the kernel code base; that can only be a good thing."

It was a piece of code from Ingo Molnar, you should be able to find it on the kernel mailing-list and read about it.

Kudos, by the way, to LWN for the great article.

It was a very interesting piece. It talked about the problems of locking (more locks makes deadlocks easier, but they get harder to track down) and the way the code went about finding problems. Basically it remember when any lock was taken or released, which locks were open before that, etc. Through this it can produce warnings. For example if lock B needs lock A, but there is a situation where lock B is taken without A being taken it will flag that.

The article has MUCH better descriptions. But through the use of this the software can find locking bugs that may not be triggered on a normal system under normal loads. Here is summary bit:

"So, even though a particular deadlock might only happen as the result of unfortunate timing caused by a specific combination of strange hardware, a rare set of configuration options, 220V power, a slightly flaky video controller, Mars transiting through Leo, an old version of gcc, an application which severely stresses the system (yum, say), and an especially bad Darl McBride hair day, the validator has a good chance of catching it. So this code should result in a whole class of bugs being eliminated from the kernel code base; that can only be a good thing."

It was a piece of code from Ingo Molnar, you should be able to find it on the kernel mailing-list and read about it.

Kudos, by the way, to LWN for the great article.

Oops, botched the LWN link.

The loss of Eldred_v._Ashcroft was bad enough. Essentially Congress now has unlimited power.

Having Supreme Court Justicies like Ruth Bader Ginsburg doesn't help. She and her mother are outspoken attorneys in favor of unlimited IP rights and unlimited congressional powers. Remember kids, if you extend a law for 50 years every 10 years, ad infinitum, that's not "unlimited"!

Now we're seeing things like the JRMI Model Train SDK project getting sued (1/2 pg. down) for $300,000.00 for infringing patents. The impact of this kind of suit on small software developers, whether free or closed, will be devastating.

And the DMCA getting new provisions that treat IP violations like drug crimes...forfiture of property! That's right, if little Bobby downloads a song from the internet, the RIAA can seize your house, car, property, etc.

Yay America! The land of freedom and liberty!

The loss of Eldred_v._Ashcroft was bad enough. Essentially Congress now has unlimited power.

Having Supreme Court Justicies like Ruth Bader Ginsburg doesn't help. She and her mother are outspoken attorneys in favor of unlimited IP rights and unlimited congressional powers. Remember kids, if you extend a law for 50 years every 10 years, ad infinitum, that's not "unlimited"!

Now we're seeing things like the JRMI Model Train SDK project getting sued (1/2 pg. down) for $300,000.00 for infringing patents. The impact of this kind of suit on small software developers, whether free or closed, will be devastating.

And the DMCA getting new provisions that treat IP violations like drug crimes...forfiture of property! That's right, if little Bobby downloads a song from the internet, the RIAA can seize your house, car, property, etc.

Yay America! The land of freedom and liberty!

"Then, once I get the system up, the network keeps getting thousands of "too many interrupts" - Even unplugged from the switch!"

http://www.google.com/search?hl=en&lr=&q=e1000+int erruptthrottlerate&btnG=Search
ftp://download.intel.com/design/network/applnots/a p450.pdf
http://lwn.net/Articles/152989/
http://sourceforge.net/projects/e1000

There's a revolution in content going on. Between Amarok and the Internet Archive, free canned music has never been easier or richer. There's already good collaboration with other free efforts like Wikipedia, I'm looking forward to more to take mass culture back from RIAA flunkies. The non free players, hobbled with DRM, will never match the performance of the free players. This alone is sufficient incentive for people to migrate to free platforms. The whole package is greater than the sum of it's parts.

and counting.
The projected release of Fedora 6 is six months, (citation).
By the time they release Vista, Fedora 7 will be almost out, and given all the exiting features listed here, many of which are already implemented in Fedora 5, along with the cost of Vista, 2007 might truly be the year of the Linux desktop.

But thats just my 2c

> I think they can and should take the desktop linux market seriously and release high-quality, closed drivers, even if it affects the OSS purity of the linux operating system.

Absolutely not!!! We need Free drivers for numerous reasons. LWN writes a good summary of the reasons here and here.

S3 and others, please understand this! We might put up with closed source drivers under some circumstances, but you cannot really call this "Linux support" and we will be underwhelmed by your offerings.

But whichever one of you makes a halfway decent (not necessarily top of the line) card with open specs and Free drivers, even if it costs more than the competition, SHOW ME WHERE TO SEND MY CREDIT CARD INFO!!!!!

> I think they can and should take the desktop linux market seriously and release high-quality, closed drivers, even if it affects the OSS purity of the linux operating system.

Absolutely not!!! We need Free drivers for numerous reasons. LWN writes a good summary of the reasons here and here.

S3 and others, please understand this! We might put up with closed source drivers under some circumstances, but you cannot really call this "Linux support" and we will be underwhelmed by your offerings.

But whichever one of you makes a halfway decent (not necessarily top of the line) card with open specs and Free drivers, even if it costs more than the competition, SHOW ME WHERE TO SEND MY CREDIT CARD INFO!!!!!

Ok... I've been a linux fan for 10 years or so now. Haven't run anything but linux in about 7 years. But c'mon guys this is FUD.

First of all, vista won't have this activated by default. Here's how you can turn it on in Vista Beta:

http://www.microsoft.com/technet/windowsvista/libr ary/c61f2a12-8ae6-4957-b031-97b4d762cf31.mspx

And yes it will make any data encrypted in this manner unavailable to another operating system. It does this by using TPM (Trusted Platform Module) in the BIOS and can base the key on the kernel and optionally: just the bios, a user supplied key, or a USB drive supplied key.

This allows for the option of encrypting/decrypting data from the very start of the boot process. And guess what? It's being implemented in linux too!

http://lwn.net/Articles/144681/

BitLocker from windows is just a kernel based drive encryption software that takes advantage of TPMs just like the linux system. If you're concerned about cross platform compatibility then use user space encryption rather than kernel space encryptiong. If you're that concerned about secure keys then don't dual boot! If you love dual booting and don't care about encryption at all, noone is going to beat you up and make you use encryptiong.

You may remove the tinfoil hat.

--David

http://lwn.net/Articles/179597/

Back in January, Red Hat reversed a longstanding policy and allowed the Mono .NET implementation into the Fedora distribution. A set of Mono applications (Tomboy, Banshee, F-spot) also went in at that time. The move was generally welcomed, but a number of observers wondered what had changed to make the addition of Mono possible. The sticking point had been a set of patents on .NET held by Microsoft; presumably those patents were no longer seen as a threat. But no information on why that might be was released at that time.

We missed it at the time, but Fedora hacker Greg DeKoenigsberg posted an explanation in late March. The answer, as it turns out, may offer some clues of how the software patent battle might play out.

Back in November, the Open Invention Network (OIN) announced its existence. OIN is a corporation which has been set up for one express purpose: to acquire patents and use them to promote and defend free software. The OIN patent policy is this:

Patents owned by Open Invention Network will be available on a royalty-free basis to any company, institution or individual that agrees not to assert its patents against the Linux operating system or certain Linux-related applications.

The list of "certain Linux-related applications" is said to exist, though it has not, yet, been posted publicly. But Mono is apparently on that list. So anybody who files patent infringement suits against Mono users, and who is, in turn, making use of technology covered by OIN's patents is setting himself up for a countersuit. Depending on the value of the patents held by OIN, that threat could raise the risk of attacking Mono considerably.

There is a long list of JavaScript-related vulnerabilities, including problems with crypto.generateCRMFRequest() (CVD-2006-1728), a security restrictions bypass vulnerability (CVE-2006-1726), a "cloned parent" access restriction failure (CVE-2006-1734), and a regular expression memory corruption bug (apparently no CVE number at the moment).
Cascading style sheets account for a couple of problems, including an integer overflow bug (CVE-2006-1730) and an array overflow vulnerability (CVS-2006-1739).
The Extensible Binding Language (XBL) facility has an access restriction failure (CVE-2006-1733) and a privilege escalation vulnerability (CVE-2006-1735).
Other troubles include "memory corruption via a particular sequence of HTML tags" (CVE-2006-0749), a DHTML memory corruption bug (CVE-2006-1724), and "an unspecified vulnerability" in how display styles are handled.

Unfortunately, it would seem that such an exploit is bound to happen, sooner or later. A web browser is a seriously complex piece of code which is simultaneously exposed to potentially hostile input from the net and used for tasks requiring a high degree of trust - working with financial sites, for example...We must hope that the security fixes will continue to reach us ahead of the attackers.

Kernel modules have an well-known API, just like user-space programs.

The API for kernel modules is covered by the exported symbol names that the modules link against. This is no different than calling routines that exist in a shared library with a known API. These APIs are relatively stable within the same major kernel release (2.4, 2.6, etc.).

Not unless you have a pretty inclusive definition of "relatively stable". Have you looked, e.g., at LWN's list of 2.6 in-kernel API changes?

Yes, you can technically read from and write to any memory area in the kernel's memory space, but this is extremely dangerous without using the supplied symbol names, especially as locations of most things will change from kernel build to kernel build.

The API includes "functions" that are just macros or otherwise inlined into the caller's code, and hence expect to know e.g. structure layouts that may change from one kernel version to the next or one .config to the next. (Try inserting a module into a kernel that was defined with different values of CONFIG_PREEMPT or CONFIG_SMP....)

Slashdot "Old" news for nerds stuff that matters.

I'm sure "nerds" would have got this news days ago

from Linux Weekly news or others

For Linux news, LWN; for general tech/sci news, Technocrat.

Slashdot has a *lot* more users than either though. Although some times it can seem otherwise, the good comments can show though... you just need to browse at +4 and ignore anything posted = 25 minutes after a story is posted. :)

LWN has a pretty decent interview of Branden, but he's kinda vague about interesting details. Link here.

> This is SOOO untrue. Linux is only as fat as you can make it.

Dam straight. Linus is not *that* fat:
http://lwn.net/Articles/66666/

Oh, you mean Linux. Never mind..... ;-)

Actually, according to LWN.net's distribution list (just updated a few days ago), it's about 500. And if you leave out the inactive ones, it's still more than 450.

"OK, let's pretend that this is indeed so, for the sake of amusement."

Why "pretend" when we can *stablish*?
There: http://www.gpl-violations.org/

"That would mean that any contributor, to any GPL code is entitled to go after any corporation which somehow internally distributes some GPL code"

(http://gnu.teleglobe.net/licenses/why-assign.html )
"only the copyright holder or someone having assignment of the copyright can enforce the license. If there are multiple authors of a copyrighted work, successful enforcement depends on having the cooperation of all authors.
by Professor Eben Moglen, Columbia University Law School"

"...as it is unknown what GPL code is being used, until fully disclosed"

(http://lwn.net/Articles/73848/)
[the FSF way of enforcing GPL]
"First, they (the bad guys) release an infringing product. Second, SOMEBODY HAS TO FIND OUT THAT THY USE GPL LICENSED CODE. Then, one of the original authors has to push for license compliance.
[Editor's note: the following article was sent to us by Harald Welte, the leader of the Netfilter project.]"

(http://www.gnu.org/philosophy/enforcing-gpl.html)
"So what happens when the GPL is violated? With software FOR WHICH THE FREE SOFTWARE FOUNDATION HOLDS THE COPYRIGHT (either because we wrote the programs in the first place, or because free software authors have assigned us the copyright, in order to take advantage of our expertise in protecting their software's freedom), the first step is a report, usually received by email to . We ask the reporters of violations to help us establish necessary facts, and then we conduct whatever further investigation is required.
by Eben Moglen"

(http://www.gnu.org/licenses/gpl-violation.html)
"...But, WE CANNOT ACT ON OUR OWN IF WE DO NO HOLD COPYRIGHT. Thus, be sure to find out who the copyright holders of the software are before reporting a violation"

It is fair to note he also had the HD3000 card working as well. Ultimately, he went with Fedora Core 4 because of the great documentation.

These guys must have read the parable about the Out of Memory Killer!

It appears as though FC5 contains a bug which prevents none GPL modules (read nVidia) from being used.
Has this been fixed in this one yet, or is it worth waiting a few more days for the fix to be rolled out?

(It was identified too late to be pushed to the mirrors)

Info about it is here.

Hmmm, maybe I should RTFA occasionally...

This week's Linux Weekly News had an article on MythTV that also covered Knoppmyth. Apparently it's not as easy as it seems (or at least the LWN editor didn't find it so).

It isn't GPL it is a proprietary product. Refer to http://lwn.net/Articles/72894/

The correct answer is that the kernel needs to do this, not userland (per suspend1), because of all the layers that need their information preserved. Having any kind of userland help doesn't work, because suddenly you've broken the "every process is equal" approach to the scheduler. But it's also not correct to throw in a huge, complicated interface (suspend2).

The correct answer is something like outlined here: " If you want my cheerfully uninformed opinion, we should toss both of them out and implement suspend3, which is based on the exec/kdump infrastructure. There's so much duplication of intent here that it's not funny."

You just have to reserve memory for a dump kernel. It's a much better trade off than making the scheduler stupid (suspend1), and keeps your kernel conceptually much simpler than a fancy kernel internal API (suspend2).

TCP/IP offload NICs (TOE) are becoming increasingly more popular. [...] This technology is being adopted by both the MS and Linux camps so it seems to have a good shot.

Err, no. TSO (TCP Segmentation Offload -- DMA IO for the network) has been adopted by the Linux people, TOE (TCP Offload Engine -- half the TCP stack is now in hardware) has been completely rejected by the Linux people, multiple times ... and has basically zero chance of ever happening.

The good thing, is that it doesn't help ... so noone will care.

Somehow I think Van Jacobsen would disagree with you...

See http://lwn.net/Articles/169961/

In fact the Linux TCP stack does most of its processing in process context by default (using VJ style prequeuing), although there is an option to change this for latency sensitive workloads.

For those who miss kerneltraffic, there is an alternative: LWN. It also has a summary of what happended on LKML.

The thing is, with the competition (from a legal standpoint) of DRM, trusted computing, and etc, the GPL must make changes to counter these new ideas.
Some people are afraid that the changes in gpl3 will keep people from embracing open source, but it is essential to have a licence that will be of use in the years to come.
RMS has liberal views, but at this point he's the only one addressing the problem.

I believe they pushed FC5 a bit to accomodate the new GNOME.

and many of those things like GLX (what allows to use opengl in X environments) was done by SGI. There's a list of OSS projects at the SGI site

There's a LOT of SGI people around the linux kernel (and not just for XFS) for example. Things like the numa-aware slab allocator, cpusets, or the swap migration (new in 2.6.16) or other tons of scalability improvements that I can't remember habe been done by SGI people. If SGI loses, Linux loses a bit of horsepower.

but if they CAN at some point they WILL

Yes, and then it's all a different matter, especially if it's for non-Google ad purposes. I don't mind them searching such content in order to determine which ads to display, like I don't worry about Gmail's such feature "reading" my mail. As long as it's an algorith, I don't see the problem. If they extract and sell information about you, there's problems ahead, but until then, what's the problem?

To take an MS comparison; they've released applications in the past that silently "phone home" to them without offering clear options on how to disable it, or even what their application is doing when needing to do it. Don't you see the difference? We already know what Google does and what that feature does; it's clearly documented and optional, no network scanning needed.

1. The Grumpy Editor's guide to personal finance managers (Part I)
2. The Grumpy Editor's Guide to Personal Finance Managers, Part 2

Courtasy of the always great LWN. They are from September of last year.

1. The Grumpy Editor's guide to personal finance managers (Part I)
2. The Grumpy Editor's Guide to Personal Finance Managers, Part 2

Courtasy of the always great LWN. They are from September of last year.

1. The Grumpy Editor's guide to personal finance managers (Part I)
2. The Grumpy Editor's Guide to Personal Finance Managers, Part 2

Courtasy of the always great LWN. They are from September of last year.

There is a good article on LWN.net, but it's subscriber-only until Feb 9th: http://lwn.net/Articles/169797/

Here's an excerpt:

==BEGIN EXCERPT===

Another thing to keep in mind is that Linus can change his mind, even after seemingly painting himself into a corner with an absolute statement. One of your editor's favorite Linus pronouncements was issued almost exactly seven years ago. In response to a query on how to set up an i386 box with 4GB of memory, Linus stated:

Oh, the answer is very simple: it's not going to happen.

EVER.

You need more that 32 bits of address space to handle that kind of memory. This is not something I'm going to discuss further... This is not negotiable.

Less than one year later, Ingo Molnar's high memory patch was merged for 2.3.23.

===END EXCERPT---

There are a few things to keep in mind about DRM that have not been explained in a lot of the articles.

1. GPLv3 allows DRM that is controlled by the user, it only negates non-user-controlled-DRM.
2. non-user-controlled-DRM can take away the freedoms that the GPL is there to protect. GPL would not be doing it's job if it didn't prohibit non-user-controlled-DRM.

This was debated on ILUG yesterday. Here's the mail that started it: http://www.linux.ie/lists/pipermail/ilug/2006-Febr uary/086087.html

So it's worth keeping in mind that what Linus calls the GPLv3 is actually only the first discussion draft - but also, due to point #2 above, while changes may be made, I'd be pretty sure there will be DRM-combatting provisions in GPLv3.