Slashdot Mirror

After those 2 emails mentioned in the post he has posted various messages today (29th July) . I'm not so sure he has quit just yet,,,

http://lkml.org/lkml/2009/7/29/272
http://lkml.org/lkml/2009/7/29/290

It's easy to find. It is posted on the linux kernel mailing list as well as in several git trees from kernel.org. Where all kernel patches belong. See http://lkml.org/lkml/2009/7/20/167 .

Thanks for the link and I am aware of that. I guess I was wondering how they found themselves in compliance with Section 3 of the GPLv2 and I think this is where the article and SFLC are coming from:

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

What I'm trying to say is I'm not seeing any of this and when I actively look on their site for it, nothing comes up.

So I grab GPL code, modify it and upload it to some remote unnamed repository with a license and go about my business releasing it under my own license as a binary on my site? I don't think so.

It's easy to find. It is posted on the linux kernel mailing list as well as in several git trees from kernel.org. Where all kernel patches belong. See http://lkml.org/lkml/2009/7/20/167 .

Btrfs includes support for TRIM on SSD, but that's a secondary addition. The main purpose of Btrfs is to compete against Sun's ZFS in the area of robust fault tolerance. If you look at the original announcement, you can see SSD support wasn't on the radar at all; that's strictly been an afterthought in the design. Btrfs is absolutely designed to work on SATA drives and to compete head to head against ext3/ext4.

If anybody can point to an actual patent that Mono or Tomboy violate, please file an issue report against the Mono project;

I know it is a bit old but, we'll file one once they publish which part they're going to patent, of course, that shouldn't be long. PS: The only complaint I have of .NET is the syntax of LINQ, but what'cha going do?

Besides, anyone thinking that MS would attacking Linux using patents isn't giving Microsoft any credit. I figure that they would try to kill Linux (GNOME proper, since GNOME != Linux) via contracts with Linux vendors as opposed to patents. It just seems too obvious to go that (patents) route. Linux isn't the problem with MS, it is more like the vendors pandering Linux that is.

Also I develop on OpenJDK, I was wondering if you could provide a list of patents that the OpenJDK is infringing on? I'm sure we could work out what it is that you feel is something we may have overlooked.

Mono is way ahead of languages like Java in that regard because, unlike Java, Mono is based on an open standard

Could you clear that up? I'm not sure I follow what you are talking about. Is it because .NET is a standard through an organized body? Whereas, Java is basically a community process with Sun at the head of the community? If this is your beef with Java then what exactly is different between how Java is made versus something like, Linux or GNU HURD?

Besides, what is all this seemingly bad blood between .NET and Java? I've been to many PDCs and the people behind .NET seem pretty accepting of Java much like the Samba - Microsoft love (which granted isn't awesome but it is still pretty good). Also, the Mono devs are pretty cool people on IRC. Really? Do we need to build walls?

There's clear roadmap posted here describing features and implications of version numbers.

Are you sure that's actually still accurate? I've followed LWN and Kernel Newbies coverage of Linux releases for a while now, and have never seen any mention of a difference between even and odd third-level version numbers.

There's clear roadmap posted here describing features and implications of version numbers.

Linux is getting process checkpointing. And will likely get migration support shortly. So you can move your services that way too. Although a VM still my be more convenient.

Let's try this - Linux - Linus - Linux - Linus. Linux was created by Linux Torvalds

And after all that you still manage to get it wrong. Better luck next time.

Granted though, it's hard to get right. Linus himself has done several (rc-)releases of the Linus kernel

The filesystem relies on the device sector writes to be atomic, which generally is not the case for flash media. Therefore consistency cannot be guaranteed for ANY filesystem.

this is what I get from http://lkml.org/lkml/2009/3/24/460:

"The server is taking too long to respond; please wait a minute or 2 and try again."

Considering that there is only one comment on this slashdot thread, that means that most people will comment without actually reading TFA.

Like me... :-)

One of the reasons people stopping calling fsync was because on ext3 it was not necessary and

http://lkml.org/lkml/2007/4/27/300

On a good filesystem, when you do "fsync()" on a file, nothing at all
happens to any other files. On ext3, it seems to sync the global journal,
which means that just about *everything* that writes even a single byte
(well, at least anything journalled, which would be all the normal
directory ops etc) to disk will just *stop* dead cold!

It's horrid. And it really is ext3, not "fsync()".

Yes, officially it's "Linus 2.6.29-rc4" see http://lkml.org/lkml/2009/2/8/129 ;)

1. Be a woman. 2. ?????? 3. Profit!

Look here to see how step (1) is done in the Linux kernel. Sourceforge has more details

True, sector remapping is transparent to the OS. But this is a pathological case for arguing whether the disk cache is worth it or not. Most sectors are not remapped.

You are of course correct that if a SAN exports a LUN to an OS, its I/O layer won't know the intricate details of that block device. But this is off-topic, as pretty much all SAN devices implement their own caching layer anyway, the latter is completely independent from the disk caches.

About higher and lower LBA addresses, OSes make the assumptions I was talking about because they are virtually always true. This is why the throughput graph of a hard drive benchmark always looks like a curve that plunges for LBA addresses increasing in value. Disk caches become less and less relevant nowadays especially with NCQ as many benchmarks show.

BTW "elevator" is the name of the I/O scheduler in 2.4 kernels. Yes, in 2.6 they have 4 different scheds with other names.

Of COURSE it's their fault. They were FORCED to explain that time and time again because they deliberately chose version numbers that say the exact opposite.

At the end of the day what 4.0 means is that the kdelibs it ships will not run KDE 3 applications. It's a major incompatible release.

What we could have done instead is to forgo releasing until it was at 4.2 quality or so, pushing back the betas and RCs to that point.

Although 4.2 is a year away from 4.0, delaying 4.0 until it was 4.2 would have taken much longer than a year, since people only test releases.

We at KDE did not communicate effectively enough that 4.0 would be in many ways a step down from 3.5, but we didn't force distros to shift to it, and people able to grab theirs from source are certainly more than capable of going back to their distro's 3.5 packages.

So could we have done better? Of course. But I disagree with the notion that you can't make a release just because it's not suitable for 95% of the user population.

Besides, IMHO, 4.0 wasn't fit for developers either. Even in 4.2, they're STILL calling some of the APIs experimental.

Even if that's the case (and I'll admit I'm not sure as to what libraries you're referring to), are you really trying to claim that an entire desktop release should be held back because there is a library that may change? (Let's assume that we clearly announced in the API docs and such that the interface was subject to change)

Even if the library changes, it's not likely to change that much, which gives developers a leg up in getting started. And if 98% of the library API is frozen and you only use 25% that's in the frozen set, what's the issue?

This is the kind of stuff I'm talking about. Just because a release is not suitable for 100 developers doesn't mean that the other 99900 developers who want a release should have to wait.

I don't actually use git, but I've heard it's actually possible to add historical snapshots to an archive at a later date. So you could switch over with no history and start using it right away, and worry about important your old repository's history later.

moreSome folks have toyed with the idea of constructing a git tree of historical linux releases.

Linux commented:

The good news is that git would be a lot more natural to the process of
trying to create a history, because you could basically import random
trees, and tag them as just independent trees, and then re-create the
history after-the-fact by trying to stitch them all together. And if you
find a new tree, you'd just re-stitch it - something that was very hard to
do with BK (and BK generally wouldn't help you with keeping multiple
independent trees around, and wouldn't generally accept the notion of
re-doing the histories and keeping various versions of the histories
around).

To me, that suggests you can import history at a later date and still integrate it properly in your tree.

After some google searching, at least some of these issues may be attributable to a bug in the Linux code that handles the leap second. http://lkml.org/lkml/2007/7/3/103 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b

http://lkml.org/lkml/2008/12/24/105

It doesn't really matter what day it is, or what holiday (if any) you're
celebrating, because even if you sit at home, alone in your dank basement,
without any holidays or friends, I bring you a tiding of great cheer: you
can now download Linux-2.6.28, and compile it to your hearts content!

Listen to the cheerful grinding of your harddisk as you reboot into an
all-new kernel - and I'm sure that if your computer could smile, it would
have a big silly grin on its non-existent face. So as you sit there in
your basement, give your computer the holiday cheer too.

In fact, even _if_ you have friends or family, leave them to their endless
toil over that christmas ham or turkey, and during the night, when they're
asleep, you can give them that magical present of a newly updated
computer. When they wake up tomorrow morning, tell them how you saw Santa
crawl down the chimney with his USB stick in hand, updating the OS of all
good boys and girls.

Ho, ho, ho,

                Linus "almost Santa" Torvalds

For example, a desktop OS will have a scheduler optimised for latency while a server OS will have one optimised for throughput.

Linus Torvalds seems to disagree with that notion:

When it comes to schedulers, "performance" *is* pretty damn well-defined, and has effectively universal meaning.

The arguments that "servers" have a different profile than "desktop" is pure and utter garbage, and is perpetuated by people who don't know what they are talking about. The whole notion of "server" and "desktop" scheduling being different is nothing but crap.

I don't know who came up with it, or why people continue to feed the insane ideas. Why do people think that servers don't care about latency? Why do people believe that desktop doesn't have multiple processors or through-put intensive loads? Why are people continuing this *idiotic* scheduler discussion?

Indeed it's been a long time since that wasn't the case. Since the 2.6 Kernel came out basically. Here's the lkml thread on it. http://lkml.org/lkml/2005/6/29/11 and http://lkml.org/lkml/2005/7/7/326 are the two posts. The latter is more informative, the former is definitive and clearly shows Andrew Morton is the one saying that part too. This is from 2005 folks. Someone notify the submitter. That is of course unless you don't trust Andrew Morton to know what he is talking about. And just because this comes up every once in a while, googling for linux swap file performance finds that post easily.

Indeed it's been a long time since that wasn't the case. Since the 2.6 Kernel came out basically. Here's the lkml thread on it. http://lkml.org/lkml/2005/6/29/11 and http://lkml.org/lkml/2005/7/7/326 are the two posts. The latter is more informative, the former is definitive and clearly shows Andrew Morton is the one saying that part too. This is from 2005 folks. Someone notify the submitter. That is of course unless you don't trust Andrew Morton to know what he is talking about. And just because this comes up every once in a while, googling for linux swap file performance finds that post easily.

Solaris only works on Apple Mac Supercomputeres. Plus it is not for Christians who believe in God and also Jesus Christ. Because if you use Microsotf you are not a Jew or a Mohammadean infedil. Please everyone remember to cast your votes for McKaner or OBOMA. They are Christians who love Jesus and Unixes of the Holy GHOST.

Have they fixed the aacraid driver yet? The new kernel doesn't do me a bit of good if all I get on boot is a continuous stream of:

aac_srb: aac_fib_send failed with status: 8195

and my disk array is not recognized.

http://lkml.org/lkml/2008/5/12/365

https://bugzilla.redhat.com/show_bug.cgi?id=450444

http://bugs.gentoo.org/show_bug.cgi?id=233364

http://bugs.centos.org/bug_view_advanced_page.php?bug_id=2911

http://marc.info/?l=linux-kernel&m=122166454808377&w=2

http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-10/msg02493.html

This is effectively related to an earlier Slashdot story about the changes Mandriva are making to speed up boot on their distro

In an attempt to head off the inevitable here's a link straight to the existing
Interesting but how useful, really? thread (Yes! No! I have a Mac! I use suspend! I use hibernate! Suspend is broken for me! Hibernate is broken for me! Hibernate takes too long with 500Mbytes! Why do Linux people always say change your habits? Etc.)

What I really want to know is what can be done about usb-storage and pciehp (PCI Express hotplug). I have an EeePC 900 using a kernel with Arjan's fastboot patches and with USB entirely disabled and pciehp turned off the kernel mounts the root filesystem in just over one second. With USB on and pciehp in use it's over 5 seconds....

Finally here's a link to Arjan's slides from the presentation about 5 second boot in PowerPoint format and a YouTube video of the 5 second boot on an EeePC 901.

The wikipedia link is a little incorrect. In many cases a swap partition can be more efficient than a swap file at least in Linux. For one, there's an extra overhead involved in dealing with files because of the OS filesystem layer. Perhaps there's a raw file option with a swapfile, but I'm not aware of it. In most cases (i.e., desktop and moderate server use) there's probably not a lot of difference and swapfiles are ostensibly easier to use. With LVMs it doesn't really matter.

Andrew Morton disagrees with you. I'm not sure how the filesystem overhead is avoided, but presumably it is. And that link is cited right in the Wikipedia article, so unless you want to analyze the issue at a deeper level than Andrew has, I think you've got to concede this one.

Although this vendor seems definitely not trying to support Linux with it's BIOS, the hard truth is that it's not so easy even for those who try. For more information, there is currently a thread on the LKML disussing this and how to improve the situation.

In particular, latest kernels claim to be every versions of Windows at the same time, and not Linux! That's not easy to handle for the BIOS writer...

There are no legal reasons. 6 months after sending notices Linux can be GPL3, no problem.

I would like to second the parent. Non-availability of copyright holders poses no problem to a license change. If on the other hand copyright holders would refuse to relicense their code, this code would have to be rewritten in case of the kernel moving to gpl v3.
This thread on lkml seems to be pertinent.

I know it's incredibly bad form to keep replying to my own posts, but I think this is an important subject. :) Please see also http://www.fsf.org/licensing/licenses/gpl-faq.html#FSWithNFLibs and http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs. These seem to largely agree with my viewpoint that it isn't inherently prohibited, but there may be legal problems, and you should consider adding exceptions to your program's license to explicitly allow linking with required non-free libraries.

However, their arguments seem to rely on the concept of linking - including static linking - being some sort of "magic" that results in a derived work. Not everyone agrees with this concept, provided that what you're linking with isn't modified. For example, see this LKML post by Linus Torvalds: http://lkml.org/lkml/2006/12/17/79. His views basically boil down to static linking being a form of aggregation, and dynamic linking of separate works having even less bearing since it doesn't necessarily require distribution of both works. Both, however, having bearing on whether or not two works are independent.

Because these days the BKL is barely used in the kernel core, or so Linus says: the core kernel, VM and networking already don't really do BKL. And it's seldom the case that subsystems interact with other unrelated subsystems outside of the core areas. IOW, it's rare to hit BKL contention - and in those cases, you want the contention period to be as short as possible. And spinlocks are the faster locking primitive, so making the BKL a spinlock (which is not preemptable) makes the BKL contention periods faster. A mutex/spinlock brings you "preemptability" and hides a bit the fact that there's a global lock being used sometimes at the expense of performance, which may be a good thing for RT/lowlatency users, but apparently Linus prefers to choose the solution that is faster and doesn't hid the real problem.

In practice, we don't see significant performance hit in daily use because of the NTFS-3G driver architecture. All known performance problems are due to other reasons which are being already addressed.

In fact, the performance results of the hybrid space, unoptimized NTFS-3G driver is already comparable or sometimes even better than the results of several in-kernel file system drivers. If you're interested, there are some technical explanation on the kernel list at http://lkml.org/lkml/2008/4/18/136

Reasons for the most common NTFS-3G performance problems, which are often incorrectly attributed to its hybrid space nature, can be found at http://ntfs-3g.org/support.html#slow

Add to the list:

-It was slow in some cases that Hans deleted from his benchmark pages (and it's not me who says this, but a ex-namesys developer that dared to say it to hans' face when he left namesys)

1.1. Memory Resource Controller

Recommended LWN article (somewhat outdated, but still interesting): "Controlling memory use in containers"

The memory resource controller is a cgroups-based feature. Cgroups, aka "Control Groups", is a feature that was merged in 2.6.24, and its purpose is to be a generic framework where several "resource controllers" can plug in and manage different resources of the system such as process scheduling or memory allocation. It also offers a unified user interface, based on a virtual filesystem where administrators can assign arbitrary resource constraints to a group of chosen tasks. For example, in 2.6.24 they merged two resource controllers: Cpusets and Group Scheduling. The first allows to bind CPU and Memory nodes to the arbitrarily chosen group of tasks, aka cgroup, and the second allows to bind a CPU bandwidth policy to the cgroup.

The memory resource controller isolates the memory behavior of a group of tasks -cgroup- from the rest of the system. It can be used to:

* Isolate an application or a group of applications. Memory hungry applications can be isolated and limited to a smaller amount of memory.
* Create a cgroup with limited amount of memory, this can be used as a good alternative to booting with mem=XXXX.
* Virtualization solutions can control the amount of memory they want to assign to a virtual machine instance.
* A CD/DVD burner could control the amount of memory used by the rest of the system to ensure that burning does not fail due to lack of available memory.

The configuration interface, like all the cgroups, is done by mounting the cgroup filesystem with the "-o memory" option, creating a randomly-named directory (the cgroup), adding tasks to the cgroup by catting its PID to the 'task' file inside the cgroup directory, and writing values to the following files: 'memory.limit_in_bytes', 'memory.usage_in_bytes' (memory statistic for the cgroup), 'memory.stats' (more statistics: RSS, caches, inactive/active pages), 'memory.failcnt' (number of times that the cgroup exceeded the limit), and 'mem_control_type'. OOM conditions are also handled in a per-cgroup manner: when the tasks in the cgroup surpass the limits, OOM will be called to kill a task between all the tasks involved in that specific cgroup.

Code: (commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)

1.2. Real Time Group scheduling

Group scheduling is a feature introduced in 2.6.24. It allows to assign different process scheduling priorities other than nice levels. For example, given two users on a system, you may want to to assign 50% of CPU time to each one, regardless of how many processes is running each one (traditionally, if one user is running f.e. 10 cpu-bound processes and the other user only 1, this last user would get starved its CPU time), this is the "group tasks by user id" configuration option of Group Scheduling does. You may also want to create arbitrary groups of tasks and give them CPU time privileges, this is what the "group tasks by Control Groups" option does, basing its configuration interface in cgroups (feature introduced in 2.6.24 and described in the "Memory resource controller" section).

Those are the two working modes of Control Groups. Aditionally there're several types of tasks. What 2.6.25 adds to Group Scheduling is the ability to also handle real time (aka SCHED_RT) processes. This makes much easier to handle RT tasks and give them scheduling guarantees.

Documentation: sched-rt-group.txt

Code: (commit 1, 2, 3, 4)

There's serious interest in running RT tasks on enterprise-class hardware, so a large number of enhancements t

Try http://lkml.org/lkml/2006/4/26/216

The problem is you, and many other proponents of of multi-threading is that you only consider processing time as a resource. The fact is there are other problems: shared resources, caching, IO, disk access times; check out this discussion on the LKML. Notice how Alan Cox mentions that "as you add threads you generally decrease cache effectiveness."

If you are blocking on IO, it doesn't matter how many threads you are running, you're still blocked. In that case, there is no point in adding more threads, it will only add complexity to your program, without any real benefit. Given that the vast majority of real-world programs are interactive and spend the vast majority of their time waiting on IO (if you don't believe me check your processor usage right now...I'll bet it's below 10%), it is safe to say that the vast majority of real-world programs will experience no boost from being multi-threaded.

Sometimes threads just slow things down. To test this, just last month for work I wrote a server using a threaded model (because it was easier) and then the exact same server using a single threaded model (because my coworker complained that threads are too slow). My purpose was to show that threads are fast enough that if it's easier, you should program that way. I tested them both on a quad-core system, and the single threaded server was indeed faster (but the threaded model handled 10,000 simultaneous connections no problem....go Linux Pthreads!). Also, I am not the only one who has seen this effect.

Use threads when they're useful. Don't use them when they're not. But if you are still under the idea that parallel processing is the magic bullet, you need to learn more about optimization.

See posix_fadvise. Using that API, a process can have as much control over a file as it needs; too bad the kernel does basically nothing with that information.

Is it really true that the kernel does basically nothing with posix_fadvise? I was about to rewrite an app to use posix_fadvise instead of O_DIRECT to manage caching based on this post by Linus:

http://lkml.org/lkml/2007/1/10/233

but if you're right then it would be a waste of time.

Nope.

It's related on how the GCC assumes the kernel sets the state of a flag before calling a function (signal handler), and this happens for compiled applications in userland with newer GCC (4.3.0).

I don't recall the gory details, on Sid with the latest (of today) version of libc6, SBCL exposes the bug (crashes). There aren't big differences between libc 2.7-8 and 2.7-9, but the second was compiled with the newer GCC. Kudos to Aurelien Jarno, a Debian developer, who isolated the bug and pushed a patch upstream. http://lkml.org/lkml/2008/3/5/207

Check our my post to the Linux Kernel Mailing List: http://lkml.org/lkml/2007/8/23/5 It drew a lot of responses from kernel developers.

http://lkml.org/lkml/2008/3/4/300 and http://lkml.org/lkml/2008/3/4/310 do clarify the position of both Linus (right or wrong) and the maintainer of the symbols in question. *shrug*

http://lkml.org/lkml/2008/3/4/300 and http://lkml.org/lkml/2008/3/4/310 do clarify the position of both Linus (right or wrong) and the maintainer of the symbols in question. *shrug*

Quite frankly, my position on this has always been that the GPLv2 explicitly covers _derived_ works only, and that very obviously a Windows
driver isn't a derived work of the kernel. So as far as I'm concerned, ndiswrapper may be distasteful froma technical and support angle, but not against the license.

Why does that patch differ from the following one (which also, supposedly, fixes the exploit) ?

http://lkml.org/lkml/2008/2/11/25

Which is the right/better patch?

You cannot separately disable the part of the kernel that contains the hole using a config option, you need the latest stable or development kernel, or a patched kernel which you can patch yourself or get from your distributor (the patch just adds a check that was missing, two lines).

Hi, I've adapted a patch for 2.6.24.1 to correct the bug completly by following the instruccions of this mail of the lkml, you can found it here, but now the official kernel 2.6.24.2 solves the bug too. Cheers

Funny you should mention that. This bug was fixed in a commit yesterday afternoon (http://lkml.org/lkml/2008/2/10/8).

vmsplice exploit fix

I'm getting irritated by the pervasive use of the tag "suddenbreakoutofcommonsense" on anything involving giving stuff away for free. It's not common sense, many times this tag is used; it's counterintuitive and probably incorrect

"Quite frankly, the whole point of slashdot is to have this big public wanking session with people getting together and making their own "insightful" comment on any random topic, whether they know anything about it or not."

-- Linus Torvalds

(source: http://lkml.org/lkml/2005/8/20/95)

Using protocols to communicate to a program or service is NOT linking!

I understand where you're coming from, which is why I moved to Postgres for all my new applications last year. However, as it stands now, I think MySQL is within their rights to use the GPL for the client. As far as I know, there is no way to communicate with a MySQL server without linking to their client library (i.e., libmysqlclient.a). At one time there was an attempt to maintain a fork of the old LGPL MySQL 3, but it never took off. Now, merely linking to the client library doesn't automatically create a derived worked (see Linus's explanation), however, in the absence of some other compatible library you could have linked with instead, it's pretty much impossible to say your linked program is independent of MySQL. And since independence is a requirement to have a non-derived work (i.e. the ability for a program to live a separate life, do something useful without the linked library), the program ends up being derived from the MySQL client, and has to abide by the GPL.
There is still plenty of argument around this topic, but again, it can be avoided by using Postgres, which IMHO is a better database anyway.

Corrected your title.

And to provide instruction to ones who will. You see, the GPL does not offer protection. Courts can. If you don't have the 'nads to go to court, you don't get protection.
http://lkml.org/lkml/2000/8/5/75

There is patch to Linux that fixes the problem, and that looks like it will be in soon.

See http://lkml.org/lkml/2007/11/28/345 - "usb-storage: always set the allow_restart flag"