Slashdot Mirror

No, it's nothing to do with virtualization, it's about interacting with pipes. vmsplice() lets you put data into a pipe without having to copy it.

I can't find a configuration option for it; it's probably a bit fine-grained even for Linux.

Even to people who don't highly value freedom, his stand on drivers isn't necessarily ridiculous. There is a pragmatic reason to be skeptical about closed drivers: unauditable/unreviewable code is a security risk.

Dear people,

Volatile does not mean what you think it does. That is all.

Sanity

And people are not very happy about it:
http://kerneltrap.org/FreeBSD/ZFS_Stability
But that doesn't stop the buzzword fanboys.

Yeah, those NVidia drivers that let you remote root were the fault of uneducated users tricked into running malicious code. http://kerneltrap.org/node/7228

It's only one of many over the years.

http://kerneltrap.org/node/515/1821 In 2.4.20-pre5 an optimisation was made to the ext3 fsync function which can very easily cause file data corruption at unmount time. This was first reported by Nick Piggin on November 29th (one day after 2.4.20 was released, and three months after the bug was merged. Unfortunate timing) This only affects filesystems which were mounted with the `data=journal' option. Or files which are operating under `chattr -j'. So most people are unaffected. The problem is not present in 2.5 kernels. The symptoms are that any file data which was written within the thirty seconds prior to the unmount may not make it to disk. A workaround is to run `sync' before nmounting. The optimisation was intended to avoid writing out and waiting on the inode's buffers when the subsequent commit would do that anyway. This optimisation was applied to both data=journal and data=ordered modes. But it is only valid for data=ordered mode. In data=journal mode the data is left dirty in memory and the unmount will silently discard it.

Yes it is.

The Linux kernel devs solved this back in 2004.

Just like a monoculture of GSM has hurt the innovation of mobile phones in Europe.

God bless the USA where competition between GSM, CDMA, & what ever sprint uses has increased innovation such that the USA always has the best cellphones out of any civilized country.

Not that I don't think in

And Theo's quote can be found here: http://kerneltrap.org/OpenBSD/Virtualization_Security

"x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))

You trolling fool. A display bug that a tiny percentage of people will ever run across (and is easily worked around) has absolutely ZERO relevance to a privilege escalation bug.

This is much more like the "if (uid=0) { dosomething; }" line that some idiot tried to toss into the Linux kernel. The difference is that thanks to Windows being a closed-source POS, they got AWAY with it for SIX YEARS. How's that closed source taste, jalekfowit? You enjoy being hacked at a moment's notice?

"If you have the ability to use chroot() you are root. If you are root you can walk happily out of any chroot by a thousand other means."

It was quite a big deal for a while. Linus himself thought it shouldn't be "fixed" or "hacked around". Here, hang on. google...google... Ah, here ya go. This may have been the issue.

http://kerneltrap.org/node/6723

2) The license issues are very serious: the BSD licenses allow developers to build on other's work and proprietize it, the GPL insists that it remain available to all customers. That's a big, big deal with the proprietary information and NDA's on new hardware.

2) The license issues are very serious: the BSD licenses allow developers to build on other's work and proprietize it, the GPL insists that it remain available to all customers. That's a big, big deal with the proprietary information and NDA's on new hardware.

Theo has strong feelings about virtualization.

That is incredibly clever, seems it should have been a part of the TCP/IP stack itself...

Heh, thanks, but I'm pretty dumb :P. It would probably work, though, especially if you handled RSTs in a similar way to fragmented packets (really it's like the oppposite of a fragment: if you get more stuff, then the RST was invalid, if you get nothing more, then the RST was valid). Scheduling the RST packet to get flushed if it is unused would be the only interesting part, but it could probably be handled similarly to fragmented packets whose other fragments never show up.

The folks at Kernel Trap were supposed to write a followup to this story about it, but I can't find the promised followup. Ohwell. Back to work.

Reid

Suppose, for instance, one had absolutely no knowledge of the Constitution, but was well versed in philosophy; Sartre and Kant and Plato and so on. One could recite the Magna Carta from memory (which, despite being foundational to the US Constitution you fail to mention). One was versed in economics and math and biology and psychology and some parts of history - saving anything U.S. related. Let us further suppose that one is even secular. Such a person could easily exist in today's world - it's unlikely in the U.S., but there are many well-developed countries in the world for which all of that could be true.

But what you're saying is that such a person is unfit to have a say in their government, if they happened to, of a sudden, be a citizen here. Simply because even though they may have been exposed to the principles of a document, they're not familiar with that document. And it's simply not true.

>> Windows Server 2008 takes up 10 GB of hard drive space.

> 10?! What the hell's taking up all the space?!

Pfft. Microsoft can't even hit good figures.
Linux 2.6.24-rc1 goes to eleven ...

... eleven MB compressed diff, that is.

Actually I think he might argue that chroot'ing has been audited a lot more than any hypervisor and might be the more secure approach in many/most instances if it's set up correctly.

Some very well informed people might reply that "chroot is not and never has been a security tool."

Try this link: http://kerneltrap.org/Linux/Abusing_chroot#comment-273718 .

There's a cure for that. It's administered by combining CONFIG_PREEMPT and Ingo Molnar's realtime kernel patch. With a proper config, your PC will never drop audio again.

This danger was already highlighted by Vice President, FreeBSD Foundation.

Read the "Letter From the Vice President" of FreeBSD Foundation Newsletter, August 29, 2007: http://www.freebsdfoundation.org/press/2007Aug-newsletter.shtml

Some call Open system, etc. while it is actually closed. Some call Freedom, actually it is restrictions. Read this for more info: http://kerneltrap.org/mailarchive/linux-kernel/2007/9/15/260554

Ok, it may be news to all of you, but Ingo Molnar has been working on a schedular that incorporates most of Con's ideas. It's called the 'Completely Fair Scheduler' (CFS), and its slated to be released in the 2.6.23 kernel.

If you'd like to read a bit about it and see some benchmarks comparing it to Con's SD scheduler, there's some very good coverage of it all over at kerneltrap.org

As for people calling for a fork of the Kernel, they obviously don't understand the Kernel development process, or how many forks currently exist.

I don't believe OpenBSD developers want to duplicate effort, they probably feel that GCC is something they have little control over, from a security viewpoint; I was reminded of some coments Theo made in this interview:
http://kerneltrap.org/node/6550
(toward the end)

>if Theo threatened to sue Mr Moglen or anyone else over these sorts of things Jesus what a nonsense, it's about the *possibility* and hasn't anything to do with Moglen in terms of the violated license. http://kerneltrap.org/Linux/Clarifying_the_ath5k_Licensing

• The FSF's chief legal counsel, Eben Moglen, is "arrogant and unscrupulous" as well as "crafty and cowardly"
• Moglen has a "stated goal" that he's breaking the law by "stealing as much software as possible and putting it under the GPL even when doing so is illegal"
• The FSF is fighting a "war against reality"
• The only reason the FSF exists is to "keep stealing code until they get busted, go to court, and then go back to stealing as much code as possible."

Why does anyone bother reading JC Roberts' nuttery? He sounds like he's either 14 years old, off his meds, or both.

I'm no expert I'm afraid but I'll let I'll share with you what I know. The Linux I/O scheduler (which I believe turned up some time in the 2.6 era) is somewhat separate from the CPU scheduler (although there is a link in priority and timeslices). Thus it was always possible to drag a process doing I/O down by having something else perform enough disk I/O, especially if you are the root user. If you can make a system swap that will hurt things even more (and that's a form of I/O).

The thing to remember is that servicing certain types of I/O need not necessarily use up much CPU time. If a device is capable of doing DMA it will need comparatively little time from the CPU to be serviced (bigger transfers can happen while the CPU is off doing other things as opposed to have the device generating interrupts all the time that the CPU has to service before any more data is transferred because some temporary buffer is full and needs moving). Additionally, certain network drivers are able to do NAPI which can reduce CPU load during heavy transfers. The way that Linux handles interrupts (which have a top and bottom "half") allows the bottom half to happen in a process context (so the heavier part of the processing counts towards a process's timeslice). This is touched upon in on Robert Love's MMCSS entry. However, if you have an important process's I/O queued up behind something less important (and the low priority task is able to generate enough a big enough request for I/O on its timeslice) then the important processes may appear to go slower (effectively its latency will go up due to having to be passed over because its I/O isn't ready) despite having more CPU time assuming the hardware can't satisfy all the requests for I/O quickly enough (imagine big writes to a slow disk with deep queues and the task needing acknowledgement all the data made it to disk).

Depending on which I/O scheduler you picked and your hardware you may be able to alleviate this problem but that's not to say that things can't be improved (or that no one is complaining about the problem).

In short I would imagine the new CPU scheduler impact would be marginal improvement on I/O performance or latency under I/O load. If it was OK before it should still be OK (but bear in mind in memory virus scanning is a special case that I would imagine would make any OS go slower).

The discussion is not as bad as it sounds (almost normal for LKML!), it's just that Roman wants to talk about the maths and Ingo works with patches... as Willy Tarreau pointed out "I know for sure that the common language here on LKML is patches".

Beyond the heated discussion with Roman Zippel, there are still a few workloads which can trigger regressions, one of which I found running some unit tests.

This is covered in this thread, and although there is now a version of CFS which does not exhibit the problem (see graph of combo3-yield patch) it is not the one that is meant to be merged in 2.6.23 (these patches are 2.6.24 material) so Ingo is getting me to test patches until this regression can be solved.

One slightly annoying thing is that the current fix involves using sysctl to switch back (at least partially) to the old scheduler mechanism!

"In a June of 1992 posting to the linux-activists mailing list, Linus Torvalds described the original Linux scheduler noting, 'the scheduler in linux is pretty simple, but does a reasonably good job at giving good IO response while not being too unfair against cpu-bound processes.' A year later, Linus posted a more detailed description of the scheduler noting, 'the linux scheduling algorithm is one of the simplest ones possible'. Comments in the original 254 line sched.c file read, '"schedule()" is the scheduler function. This is GOOD CODE! There probably won't be any reason to change this, as it should work well in all circumstances (ie gives IO-bound processes good response etc). The one thing you might take a look at is the signal-handler code here.'

"Comments in the current 6,709 line sched.c file show the first changes being made in 1996 by Dave Grothe, 'to fix bugs in semaphores and make semaphores SMP safe'. Two years later Andrea Arcangeli is credited with implementing 'schedule_timeout() and related stuff'. It was not until 2002, ten years after Linus' original code was written, that the scheduler received a complete rewrite, 'new ultra-scalable O(1) scheduler by Ingo Molnar: hybrid priority-list and round-robin design with an array-switch method of distributing timeslices and per-CPU runqueues.' Con Kolivas is credited with 'interactivity tuning' in 2003, and Nick Piggin added 'scheduler domains' in 2004. A more recent rewrite of the scheduler happened in April, again by Ingo Molnar, this time with his Completely Fair Scheduler."

2.6.22-ck1 2.6.22-cfs-v19
quake + 0 loops 41 fps quake + 0 loops 41 fps
quake + 1 loop 3 fps quake + 1 loop 41 fps
quake + 2 loops 2 fps quake + 2 loops 32 fps
quake + 3 loops 1 fps quake + 3 loops 24 fps
quake + 4 loops 0 fps quake + 4 loops 20 fps
quake + 5 loops 0 fps quake + 5 loops 16 fps

The code in question is dual licensed

• The open-source HAL, the work of Reyk Floeter, was *never* dual licensed; he has only released it under the ISC license.
• There *are* some dual-licensed files in the driver, but that is not what the OpenBSD people have a problem with.
• The code *has* been published with the GPL fully replacing the ISC license; for example, see the madwifi repository. It was also published elsewhere, but since removed. For sure, not just a diff proposed on a mailing list.
• It is still being published (madwifi again) with GPL wrapped around the ISC license and with added copyright authors
• It is still being published, now under the ISC license and with added copyright authors
• The changes in these versions which are still published are mostly for adaptation, there doesn't seem enough original work to claim joint copyright (I guess, unless the original author agrees)

I recognize that writeup about the Atheros / Linux / SFLC story is a bit complex, so I wrote a very simple explanation to someone, and they liked it's clarity so much that they asked me to post it for everyone. Here it is (with a few more changes)
-----
starting premise:

you can already use the code as it is

1. pester developer for a year to get it under another license.

- get told no, repeatedly

2. climb over ethical fence

3. remove his license

- get caught, look a bit stupid

4. wrap his license with your own

- get caught, look really stupid

5. assert copyright under author's license, without original work

- get caught, look even more stupid

Right now the wireless linux developers -- aided by an entire team of evidently unskilled lawyers -- are at step 5, and we don't know what will happen next. We wait, to see what will happen.

Reyk can take them to court over this, but he must do it before the year 2047.

And that's a shame, because people probably really ought to keep their hats on.

The license they use does NOT enforce sharing. But they believe that people OUGHT to share. So, when someone doesn't share (for example by adding GPL components) they try to use insults, blackmail and bad PR to force them to share. It is exactly like Theo did over openSSH. Does no-one remember the bullying that Theo tried to get money and equipment out of users of openSSH? http://kerneltrap.org/node/6550 They were low on funds, so he decided that anyone who uses the FREE software they made OUGHT to donate to openBSD. This behaviour is very like the behaviour of those who own MP3 patents - let it go out and become the standard THEN hit everyone up for cash. The only difference is that the BSD license means no-one is FORCED to pay, they just get slagged off by Theo.

Ignore the more relevant discussions from technical people. Like at Kerneltrap. And answer by replying blindly what I called you. - Hey, you farted, it's disgusting - No I didn't, you did! - Right

This was very quick googling, of the type "I think I remember reading something like...", typing "linus git kernel import", and clicking until I found something similar to my memory, total time 20 seconds:
http://kerneltrap.org/node/5014

Just because I'm the type of person who uses version control and often have access to high-speed internet and large hard drives doesn't mean I'm /ALWAYS/ in a situation where I have a lot of bandwidth and hard disk space at my disposal. When I'm in a resource-limited situation, I still like to be able to check in/out, do other "what went wrong?" type of things without using a second system.

As for "give it a try", I did, but very early in its history so I don't think enough niceties were there at the time.
Mostly, it comes down to: sometimes my SVN repository grows very quickly due to all the sometimes unneeded history. There's no "svn obliterate", so we just put up with it. This causes (actual, not hypothetical) storage issues even with centralized version control. I wouldn't want to multiply this problem by the number of developers, while adding bandwidth issues previously not dealt with because some things they just didn't care about, just to allow them access to histories /when they wanted it/.

No Linus wrote Linux as a reimplementation of BSD, during the period that AT&T sued to stop the distribution of BSD. Had BSD not been held up in court, there would have been no need to rewrite BSD from scratch using inferior networking code.

No Linus wrote Linux as a reimplementation of BSD, during the period that AT&T sued to stop the distribution of BSD. Had BSD not been held up in court, there would have been no need to rewrite BSD from scratch using inferior networking code.

No Linus wrote Linux as a reimplementation of BSD, during the period that AT&T sued to stop the distribution of BSD. Had BSD not been held up in court, there would have been no need to rewrite BSD from scratch using inferior networking code.

Linus has already explained why he doesn't like the idea of a pluggable scheduler system. See http://kerneltrap.org/node/14019

Try again.