Linux Kernel 2.6.35 Released

3.6.35? by Lord+Byron+II · 2010-08-01 14:48 · Score: 4, Funny

Wow. The future has arrived.

Way to double-check your article, Timothy.

Re:3.6.35? by smi.james.th · 2010-08-01 15:18 · Score: 2, Informative

I suspect you may have posted this reply on the wrong thread, mate.

--
One thing I know, and that is that I am ignorant...
Re:3.6.35? by belthize · 2010-08-01 15:20 · Score: 2

This is not the thread you're looking for.
Re:3.6.35? by jd · 2010-08-01 15:28 · Score: 1

It's a plot to beat SCO's Linus 2.7 lawsuit claims.

--
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)

Still no ZFS. by 0100010001010011 · 2010-08-01 14:58 · Score: 5, Funny

I understand why, but there are a ton of people out there that think OSS is OSS. You wonder why corporations are weary of OSS it's because of this. I really hope this project goes somewhere or Debian's kFreeBSD project works as well as I'm hoping.

Reminds me of this joke:
I was walking across a bridge one day, and I saw a software developer standing on the edge, about to jump off. I immediately ran over and said "Stop! Don't do it!"

"Why shouldn't I?" he said.

I said, "Well, there's so much to live for!"

"Like what?"

"Well ... do you develop Closed Source or Open?"

"Open."

"Me too! Are you BSD or GPL?"

"GPL."

"Me too! Are you GPL v2 or GPL v3?"

"GPL v3!"

To which I said, "Die, heretic scum!" and pushed him off.

Re:Still no ZFS. by tenchikaibyaku · 2010-08-01 15:12 · Score: 3, Interesting

A ton of people out there who both think that all the Free Software/Open Source licenses are the same and are waiting impatiently for ZFS in Linux? Somehow I doubt it. And corporations are weary of OSS because the Linux developers aren't breaking Sun's(/Oracle's) purposefully GPL-incompatible license? Actually, did you have a point? I think I missed it. :-)
Re:Still no ZFS. by afabbro · 2010-08-01 15:14 · Score: 3, Informative

The original joke:
I was walking across a bridge one day, and i saw a man standing on the edge, about to jump off. so I ran over and said "Stop! don't do it!" "Why shouldn't I?" he said. I said, "Well, there's so much to live for!" He said, "Like what?" I said, "Well...are you religious or atheist?" He said, "Religious." I said, "Me too! Are you Christian or Buddhist?" He said, "Christian." I said, "Me too! Are you Catholic or Protestant?" He said, "Protestant." I said, "Me too! Are you Episcopalian or Baptist?" He said, "Baptist!" I said, "Wow! Me too! Are you Baptist Church of God or Baptist Church of the Lord?" He said, "Baptist Church of god!" I said, "Me too! Are you original Baptist Church of God, or are you reformed Baptist Church of God?" He said, "Reformed Baptist Church of God!" I said, "Me too! Are you reformed Baptist Church of God, reformation of 1879, or reformed Baptist Church of God, reformation of 1915?" He said, "Reformed Baptist Church of God, reformation of 1915!" I said, "Die, heretic scum," and pushed him off.

--
Advice: on VPS providers
Re:Still no ZFS. by retchdog · 2010-08-01 15:20 · Score: 4, Informative

Courtesy of the inimitable Emo Philips.

--
"They were pure niggers." – Noam Chomsky
Re:Still no ZFS. by smi.james.th · 2010-08-01 15:24 · Score: 1

Isn't Btrfs supposed to be similar to ZFS in its features and stuff?

--
One thing I know, and that is that I am ignorant...
Re:Still no ZFS. by afabbro · 2010-08-01 15:31 · Score: 4, Insightful

I understand why, but there are a ton of people out there that think OSS is OSS. You wonder why corporations are weary of OSS it's because of this.
I would wonder if they were, but they're clearly not. Corporations love Linux. It's less expensive and commodity. It frees them from expensive proprietary hardware vendors (Sun Sparc, HP Itanium, etc.) and lets them find the right x86/x86-64 servers for them. They can use free versions (e.g., CentOS) in some environments and paid enterprise versions (e.g., RHEL) in others. Most of the big enterprise packages (Oracle, DB/2, Websphere, JBoss, SAP, etc.) are available in Linux. The enterprise data center is a war between Linux and Windows (with the mainframe, AS/400, and other monotowers, though they are rarely growing).
The "SCO scare" is a thing of the past. I can tell you from personal experience after many years in the infrastructure world that the license headaches with Linux distros are nothing compared to the eternal headaches that I've had with companies like Veritas/Symantec, Oracle, etc.
Most of the decision-makers, technical architects, etc. in corporations do not operate at the "why ZFS is better" level. Does $LINUX_DISTRO support RAID, SAN multipath, and other common enterprise storage needs? Great. That's all we need. Frankly, while ZFS is great, it's not enough of a game changer to make someone buy Solaris over Linux.

--
Advice: on VPS providers
Re:Still no ZFS. by jd · 2010-08-01 15:39 · Score: 3, Interesting

I'm increasingly wary of BtrFS, due to claims that there are fundamental design flaws. This does not mean I believe such claims (although I observe LWN's top file-system contributing journalist is quitting her job, her entire career path and her State) but it does mean that I want to see someone do a proper systematic analysis of the methods used and algorithms chosen. I'll probably use it anyway. Radical filesystem architecturing is hard and better options are almost always likely to exist - the question I have is how much impact this actually has on performance and safety of BtrFS. A little? A lot? About average for filesystems?

--
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Re:Still no ZFS. by 0100010001010011 · 2010-08-01 15:42 · Score: 2, Informative

It got me to switch. And every single person that I've talked to about it has.
I'm not talking about the companies that just USE Linux internally. I'm talking about the companies that sell something linux.
Tivo for example (The reason for GPLv3) there are companies that may want to pick up and run with something Linux based but are afraid about what might happen if they build a product around it. So they scrap the whole idea.
Vs a BSD license that Apple's created OS X around, companies have built specialty FreeBSD distros for their high end routers, the company that took over FreeNAS uses it as the basis of their OS for the hardware they sell.
Re:Still no ZFS. by jd · 2010-08-01 16:07 · Score: 2, Insightful

For a kiosk turnkey product, an extensible OS that can work for the server or desktop is probably not that useful. You're never going to want to run commodity software on it, you're never going to want to extend it, and you're never going to want to make use of the flexibility it has.
Rather, you'd be much more interested in a real-time OS that is compact (so that most of the memory can be used for double-buffering the video and buffering the network traffic and disk activity) and supports only the absolute key features you must have. In the end, it is cheaper to develop a few minor features for an OS kernel than to test a horribly large number of pathways, and for something like TiVo, users aren't going to care about the 99.999% of the time it works great, they're going to remember and whine about the 0.0001% it doesn't.
(I like Linux, I consider it to be one of the best OS' yet developed, and it would be great for a platform that was going to combine the elements of a cable box with a video recorder with a web browser, especially if it was then going to act as a central server for on-demand TV to the rest of the house. It could handle something like that with one bitmask tied behind its back. For something much more basic like decode-store-and-play, FreeRTOS is probably sufficient and the simpler code would make verification much easier.)

--
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Re:Still no ZFS. by 0123456 · 2010-08-01 16:14 · Score: 5, Interesting

Meanwhile my TV, webcam and Blu-Ray players all appear to run Linux, as did the media players and cameras I used to work on. There are a ton of embedded Linux systems in all kinds of markets even when a real-time OS might make more sense.
Re:Still no ZFS. by Lord+Kano · 2010-08-01 16:20 · Score: 4, Interesting

Don't be so sure of that. FUD is alive and well. Last summer I interviewed with a bank about a three month contract to move some data. When I asked them about the requirements for the platform/environment. I was told, flatly, that I could use anything that I wanted, as long as it wasn't open source. Open source means that anyone can see the flaws in the software and exploit them. I had two choices, I could keep my mouth shut and take the contract or I could speak the truth and blow my chances. I spoke up.
LK

--
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
Re:Still no ZFS. by vadim_t · 2010-08-01 16:40 · Score: 3, Informative

Eh. Sun intentionally chose the license to be GPL incompatible.
And it's quite likely that their explicit intention was to be Linux incompatible as well. Should it have been licensed under some other terms, the license for ZFS would likely have been chosen to be incompatible with that. For instance, if Linux was BSD licensed, Sun could have just released ZFS under the GPL. While in theory it's perfectly compatible, in practice a BSD project will refuse GPL patches.
Which really makes sense, as Linux has been replacing Solaris in lots of places, and I imagine Sun didn't want to help them with that.
Re:Still no ZFS. by Anonymous Coward · 2010-08-01 16:55 · Score: 2, Interesting

I worked a defence contract once where the same policy applied. The argument there is they wanted to have somebody to sue when the planes fell out of the sky.
Re:Still no ZFS. by cheater512 · 2010-08-01 17:59 · Score: 5, Insightful

You should only compare to what is already existing and mainstream, rather than what the theoretically best option is.
If its reliable in general use, and better than existing alternatives, its a winner in my books.
Re:Still no ZFS. by Anonymous Coward · 2010-08-01 18:12 · Score: 3, Interesting

If the OS is truly a commodity then it usually makes sense to go with the one that is the cheapest to acquire and also to maintain over the lifetime of the product. As both BSD and Linux cost the same to acquire the real question becomes:
Is it better to take advantage of the improvements others make to the OS knowing that any improvements you make have to be given up vs. the advantages of being able to keep your improvements secret knowing that your competitors can keep their improvements secret.
There is no right or wrong in business, just a balance-sheet. Different businesses will have different answers. However, philosophically... do you want to share nice or not?!
Re:Still no ZFS. by CAIMLAS · 2010-08-01 18:29 · Score: 3, Interesting

You mention the zfs github and kFreeBSD, but are you aware of Nexenta?
Honestly, I'm not sure why it's not as well acknowledged as kFreeBSD. The myopia involved there seems to be similar to what you make light of with your joke.
In the event that you really haven't heard of it, Nexenta is basically OpenSolaris kernel with Ubuntu userland.
You get apt. No, it's not debian, but if we're looking at ZFS implementations, it's a far cry better than the alternatives (FreeBSD = buggy crap and you've got to use ports; OpenSolaris = you've got to use Solaris/shoehorn useable modern tools in).
I'm not sure why we need to stick with Linux, per se, and what's wrong with OpenSolaris kernel/CDDL. Serious question here: is there something wrong I'm missing?
From where I'm sitting - user and admin of Linux for close to a decade, now - there's really not much of an advantage to using (or developing for) Linux over, say, FreeBSD other than the community of developers (including the install base, financial backing, etc.) and what that provides for you. I'm not sure if a BSD compatible license could ever get the financial support (from the likes of RedHat, IBM, Intel, etc.) Linux does because it could be 'turned against them', but for most people (administrators, developers, etc.) there's no inherent reason, one way or the other.
It just comes down to dogma.

--
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Re:Still no ZFS. by 0123456 · 2010-08-01 18:56 · Score: 4, Informative

I'm increasingly wary of BtrFS, due to claims that there are fundamental design flaws.
The only 'claims of fundamental design flaws' I'm aware of are that it has bad performance in some pathological cases. Which is true of every single filesystem ever produced and likely true of every filesystem you'll ever use in the future.
I'm certainly not aware of it having any flaws that ZFS doesn't; my main concern is that Oracle won't want to fund any more BTRFS development now they also own ZFS.
Re:Still no ZFS. by drsmithy · 2010-08-01 19:26 · Score: 3, Interesting

I'm not sure why we need to stick with Linux, per se, and what's wrong with OpenSolaris kernel/CDDL. Serious question here: is there something wrong I'm missing?
OpenSolaris was a dead platform the day Oracle bought Sun. You would be utterly insane to use it for anything important, today.
Re:Still no ZFS. by 0100010001010011 · 2010-08-01 19:52 · Score: 1

I tried Nexenta but the userland tools seemed to be VERY lacking. Plus I run my OS box as a dom0 for Windows 7, XP, 2k and Debian.
But OS is starting to get a bit long in the tooth now that Oracle doesn't know what to do with it. But that was nearly a year ago. Maybe things have developed since then.
Debian just must have everything nearly magically automated because almost every arch I've run it on has every tool available.
Re:Still no ZFS. by AHuxley · 2010-08-01 20:22 · Score: 1

I want my TRIM too :)

--
Domestic spying is now "Benign Information Gathering"
Re:Still no ZFS. by joib · 2010-08-01 20:59 · Score: 3, Informative

Presumably he meant the issue described here: http://lwn.net/Articles/393144/
From reading the mailing list thread, my impression was that it was a storm in a teacup, and the real problem was just a simple bug rather than a fundamental misdesign. Or if you want to be slightly less charitable, a case of "concern trolling".
Re:Still no ZFS. by k8to · 2010-08-01 22:25 · Score: 3, Interesting

If you switched for ZFS without carefully considering whether it would meaningfully help for your particular use cases, you probably spent a lot of money and effort for no gain.
For most people, ZFS is a cpu-sink that offers slightly more convenient volume management, at a high price for hardware overhead and latency.
But you have to use it on solaris, because their UFS infrastructure is so out of date, you can't support a reasonable number of spindles (without investing even MORE money in moving that problem off the box entirely).
It has some neat whizzy bits, but those whizzy bits are not at all free, and things most people seem to not need.

--
-josh
Re:Still no ZFS. by ByOhTek · 2010-08-01 22:52 · Score: 1

Since I don't have the mod point, and parent is still only at 1, I have to say - the parent post requires some insightful mods. More rational point than I'm used to seeing in a lot of cases.

--
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
Re:Still no ZFS. by realityimpaired · 2010-08-01 22:56 · Score: 1

As with *any* experimental subsystem in the kernel, use at your own risk. If you really need the features afforded by btrfs over ext4 or reiserfs at this point in the game, then do what I do: use LVM. Reiser over a disk-spanning LVM gives you most of the advantages that btrfs has over ext4, without having the hassle of being experimental. I still plan on switching to btrfs once it's out of experimental, but for now I'm able to do everything that has me wanting btrfs for my fileserver with those two.
Yes, it does lack some of the promised functionality of btrfs. But it does give me the ability to add/remove disks to/from the array, it lets me resize the array without losing data, and it lets me pool multiple disks into a single disk, allowing me to share large amounts of space between multiple network drives without worrying about whether I allocated enough space to each of the 3 drives. When coupled with mdm, you also get to take advantage of striping/mirroring between drives, giving added reliability. This setup also has the added advantage that, when I switch to a different distro or have to reinstall, recovering my array is as simple as installing the lvm2 tools and running "pvchange -a y". There aren't a lot of distros that natively support btrfs at this time, and many of those that do have different implementations of the tools that may not be compatible. Thus it still being experimental.
If you don't need a disk exceeding 2TB then do it with a single disk with the filesystem of your choice. If you do need a disk that exceeds 2TB, then the tools have been available for some time which will allow you to do so. btrfs is simply a pooling of those tools into a single package, in a way that makes it more accessible for dummy users.
Re:Still no ZFS. by tehcyder · 2010-08-01 23:26 · Score: 1

I believe that was an Emo Phillips joke originally.

--
To have a right to do a thing is not at all the same as to be right in doing it
Re:Still no ZFS. by gbjbaanb · 2010-08-02 00:41 · Score: 2, Insightful

Its true though, we're a full-on microsoft shop and even though we use some poor products that are shown to be failing us, when I migrated some things to OSS (Visual source safe to Subversion comes immediately to mind), my bosses all insisted we evaluate all the commercial offerings first. They equate 'free' to 'crap'.
As it is, even though we migrated successfully and used it for nearly 2 years, they still went and bought the worst (IMHO) SCM I've ever had the misfortune to use (Serena Dimensions). It cost us well over £100k and we're considering moving back to SVN as soon as we can.
The problem is one of attitude and 'marketing'. Even though they were slapped in the face, then built themselves a wall and quickly walked right into it, they *still* think 'free' equals 'crap'. I don't think this is too unusual amongst the majority of business managers either.
We know better, these poor dears don't.
Re:Still no ZFS. by AvitarX · 2010-08-02 00:45 · Score: 1

Isn't that red hat's job?

--
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
Re:Still no ZFS. by rubycodez · 2010-08-02 02:40 · Score: 3, Informative

the lack of adoption of OpenSolaris compared to Linux has to do with real world considerations. The summary of the reasons really is that Sun waited too late to roll it out, should have done it in late 90s. That would have solved the issues: It doesn't support the amount of hardware Linux does, doesn't scale from embedded devices to supercomputers, doesn't have a couple tens of thousands of packages made for it, is much harder to admin (speaking as certified solaris engineer)
Re:Still no ZFS. by Thinboy00 · 2010-08-02 03:03 · Score: 1

Oh noes! Not another GPL/BSD flame war! Anything but that!

--
$ make available
Re:Still no ZFS. by raddan · 2010-08-02 04:41 · Score: 1

Well, I dunno-- "reliable in general use" might have some conditions that make it completely unreliable or otherwise unacceptable in certain use-cases. E.g., many modern filesystems cannot detect latent sector errors that are not otherwise detected by the hardware itself. Depending on how your filesystem is implemented, a latent sector error could wipe out your critical disk structures (ala ReiserFS) or do nothing at all (ala ZFS). The only meaningful way to interpret a new filesystem's capabilities is to compare it against the theoretical best performer. Otherwise, you may find that your new filesystem is "better" than your old one, but still inappropriate for your particular application.
Re:Still no ZFS. by jd · 2010-08-02 05:23 · Score: 1

To an extent, yes, which is why I said I'll probably end up using it anyway. It is better in many ways than existing alternatives (although XFS and JFS are still filesystems I like for specialist work). However, if you are planning any major migrations, it can't merely be better than existing alternatives because you have to factor in the effort and the risk of error in the migration. Also, never, ever use version 1.0 of something. Anyways, the only way to factor in the overheads in any meaningful way is to forecast. Cost:benefit ratios are all fine and good but unless you've something to compare the current cost:benefit ratio to, all you have is a number. I'll accept that BtrFS' design is not broken (and my original post I did note that I didn't entirely believe the claim), but let's say it had been and version 2.0 had fixed this. We now have something to compare to. Migrating to version 1.0 might still be worth it, if the benefit is great enough to overwhelm the cost, but if you do the forecast you can predict whether it's better to migrate or wait.
And that's the key to any migration. You've got to see if it would (overall) be cheaper to stick with what you have and migrate later OR migrate now. Things will ALWAYS be better down the road, though, so how can you tell? Because part of the cost is the cost of waiting. The longer you're on an inferior system, the greater the overheads you have to pay. Somewhere there will be a sweet spot, a point where you get the most out of the upgrade. Waiting longer will get you something better, but the cost of the wait becomes so great that it's no longer worth it. Waiting less will cut down the penalties, but will create more effort and more risk.
For most of us, especially on home systems, the effort is part of the fun and the risk is insignificant as we all keep backups.... ....right? So keeping a system fresh and current is just fine. I routinely use the staging tree rather than the actual release because the benefits to me overwhelm all other considerations. In a work environment, effort is not part of the fun and the risk is rather more than rolled eyes and grabbing the backups. Mind you, I have actually run experimental kernels in the workplace on production machines in the past, where I've decided that the benefits are worth taking that kind of chance. But as a rule, that's a bit of a no-no. For workplace servers, you want to keep as close to the sweet spots for upgrades as you can, recalculating the costs if a significant vulnerability is announced or a major bug that impacts the system is discovered.

--
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Re:Still no ZFS. by petermgreen · 2010-08-02 06:02 · Score: 1

Automation helps to some extent, I very much doubt a project like debian could support the number of ports it does without the array of software and infrastructure they have for autobuilding.
But that alone is not sufficient, a group of porters who care about bringing an architecture up to the coverage level required to become a release architecture and who have the skills to get it there is also needed.
Once a port reaches the status of release architecture things get easier for the porters because one of the requirements for getting a new version of a package into testing is that it builds successfully on all release architectures (exceptions can be made but generally only will be if there is a very good reason) it has built on before but still active porters are needed to keep an architecture viable.

--
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Re:Still no ZFS. by Lord+Kano · 2010-08-02 13:05 · Score: 1

I got another job. Jobs come and go, but my ethics are not for sale.
LK

--
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
Re:Still no ZFS. by Lord+Kano · 2010-08-02 13:27 · Score: 1

They only allow open source tools that have been "audited" by corporate security. They managed to get them to review and approve the perl executables (though they didn't tell me which ones).
LK

--
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
Re:Still no ZFS. by snadrus · 2010-08-03 05:22 · Score: 1

Phoronix.com has BtrFS (with native compression) beating Ext4 in most tests & all the SSD tests.

--
Science & open-source build trust from peer review. Learn systems you can trust.

Re:2.6.35 has not been released by MichaelSmith · 2010-08-01 15:01 · Score: 4, Informative

Linus sez

So 2.6.35 is out, go check
it out.

in the other TFA so I suppose it is out.

--
http://michaelsmith.id.au

Re:The year of... by MichaelSmith · 2010-08-01 15:04 · Score: 4, Insightful

Well its definitely the year of linux so far down in the guts of your cellphone that you don't know its there..

--
http://michaelsmith.id.au

Re:2.6.35 has not been released by belthize · 2010-08-01 15:10 · Score: 2, Informative

Looks released to me.
http://www.linux.org/news/2010/08/01/0001.html
http://www.linux.org/news/2010/08/01/index.html

Re:The year of... by uprise78 · 2010-08-01 15:11 · Score: 1

Wow. Just wow. I'm speechless. I hope you are kidding.

Re:GPL Intellectual Theft by maxume · 2010-08-01 15:22 · Score: 1

Too overt.

--
Nerd rage is the funniest rage.

Re:GPL Intellectual Theft by retchdog · 2010-08-01 15:26 · Score: 2, Informative

But it's aged fairly well for being at least six years old.

--
"They were pure niggers." – Noam Chomsky

Big Features? by Anonymous Coward · 2010-08-01 15:32 · Score: 2, Insightful

The big features to look out for include: "Transparent spreading of incoming network traffic load across CPUs, Btrfs improvements, KDB kernel debugger frontend, Memory compaction and Support for multiple multicast route tables"

I'm sure most or all of these mean nothing to 99%+ of Linux users. This isn't a big feature release; it's a small incremental improvement release.

Re:Big Features? by FauxPasIII · 2010-08-01 16:38 · Score: 4, Funny

Perhaps, in the same sense that "improved the reliability of the rear differential" means nothing to 99%+ of automobile owners.
Oh crap, did I just make a car analogy?

--
25% Funny, 25% Insightful, 25% Informative, 25% Troll
Re:Big Features? by adamofgreyskull · 2010-08-01 17:29 · Score: 1

I think the stated "big"ness of those features is in comparison to the other, "lesser" features. It doesn't say it's a "big feature realease", anywhere.
Re:Big Features? by vlm · 2010-08-01 23:28 · Score: 2, Insightful

Perhaps, in the same sense that "improved the reliability of the rear differential" means nothing to 99%+ of automobile owners.
Because we all have front wheel drive cars?

--
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Re:Big Features? by nschubach · 2010-08-02 02:31 · Score: 1

I don't... ;)

--
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
Re:Big Features? by snadrus · 2010-08-03 07:51 · Score: 1
Agreed they aren't huge, but lets review:
- More responsive loaded webservers (less "slashdotted")
- BTRFS is good enough to be an "advanced" Ubuntu install option
- Multiple Virtual Machines will run very memory efficient (making Linux the undisputed VM host of choice)
- KDB thing will help the increasing kernel improvement rates afaik.
So 3/5 affect this Linux user. One more will help increase the pace of advancement (and maybe pull me into kernel debugging). This sounds like a solid "big feature" set.
--
Science & open-source build trust from peer review. Learn systems you can trust.

Re:GPL Intellectual Theft by cjcela · 2010-08-01 15:33 · Score: 3, Informative

"Furthermore, after reviewing this GPL our lawyers advised us that any products compiled with GPL'ed tools - such as gcc - would also have to its source code released. This was simply unacceptable."

This sounds like FUD to me. I do not think the intent of your post is clean. Or maybe you have no clue and should consider getting better lawyers next time... then, if GPL still does not work for you, use some BSD flavor as OS for your next proyect.

Re:2.6.35 has not been released by jd · 2010-08-01 15:42 · Score: 2, Funny

It's 3.6.35 that's not released yet.

--
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)

Re:GPL Intellectual Theft by TangoMargarine · 2010-08-01 15:47 · Score: 1

I may reconsider if Linux switches its license to something a little more fair, such as Microsoft's "Shared Source"

AAHHAHAHAHAHAHAHAHAHAHAHA

(Junk down here to avoid the all-caps filter)

--
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF

once burned, twice shy by epine · 2010-08-01 15:49 · Score: 2, Interesting

Perhaps the people who fear Linus is going to burn out again spent too many years watching Seinfeld and deeply internalized "no hugging, no learning". Linus != George. OTOH, given his acidic tongue, he's probably not well suited to a career in stand up comedy. Anyone else think that Larry McVoy would make a good Kramer? </rimshot>

Re:once burned, twice shy by Ethanol-fueled · 2010-08-01 16:08 · Score: 1

Ballmer would make a much better Kramer.
Re:once burned, twice shy by CAIMLAS · 2010-08-01 20:25 · Score: 4, Insightful

You have to admit, it's somewhat disconcerting that there's nobody in his coattails to take over.
Unlike Microsoft or some other big softare company/project, Linux really has one controlling hand. If Linus goes kaput tomorrow, face in his wheaties, it would take a non-trivial period of time to get someone up to speed and filling his shoes.
Sure, there are other "non-current" linux developers/maintainers, and there are many others who have been doing the job in the past. But that's an entirely different development model than the 2.6 tree has been, and there's nobody who "fills in" for Torvalds when he wants to take a break. The man is 40; he's going to have to slow down sooner than later. He's certainly not keeping up his percentage of code commits, nevermind the level of code (though the quality, quite possibly). He's got 3 daughters and a wife; the man has to sleep at SOME point.
That said, I'm really pleased to see the decrease in regressions. I was starting to think that it was all open source OSes that were going down the shitter of late, but I am pleased Linux is still improving (though I do still consider the removal of the anticipatory scheduler a regression).
It just makes me uneasy that anything as big as Linux has such a small point of failure. It's possible I'm overlooking the importance of the distro kernel teams and other people who contribute, or overlooking something else, but as it stands now, his continued pivotal position makes me uneasy.
The lack of a unified "stable" kernel for distros to pull from (given 2.6s continued march) and at the same time the lack of a "real" development/next-generation kernel makes me likewise uneasy.

--
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Re:once burned, twice shy by gmack · 2010-08-01 23:05 · Score: 5, Insightful

You have to admit, it's somewhat disconcerting that there's nobody in his coattails to take over.
There are at least a couple of good developers who could easily take over starting with the maintainer of the linux-next tree and if there were a huge disagreement then I'm sure the Linux foundation can step in if need be.

The lack of a unified "stable" kernel for distros to pull from (given 2.6s continued march) and at the same time the lack of a "real" development/next-generation kernel makes me likewise uneasy.
You would only say that if you haven't been using Linux long enough to remember when it was exactly the way you wish for. Back in the 2.4.x / 2.5.x days, people got so tired of features taking so long to be ready they started backporting the changes from 2.5.x to 2.4.x essentially making both branches unstable. For all of the whining kernel releases are a lot less buggy with fewer distro deviations from mainline. And as a bonus features actually get better testing now because fewer changes need to be tested at a time.
After having lived through that transition I never want to go back.
Re:once burned, twice shy by Anonymous Coward · 2010-08-02 03:15 · Score: 1, Interesting

I disagree. I lived through the stable 2.2, 2.4 kernel releases and I would love to go back to the stable/development branches. The 2.6 kernel has been much too flakey for my taste.
Re:once burned, twice shy by CAIMLAS · 2010-08-02 04:56 · Score: 1

I remember the 2.0 kernel days just fine. I don't remember those "features" getting back ported making things unstable.
I do remember there being a lot of custom patchlevel kernels, though. Lots of people did it, myself included. It was quite straightforward, because the base kernel didn't typically have configuration failures like it does now, and the patches were relatively simple. THese days, it's a bit of a pain in the ass to build a kernel due to the odds and sods not building (a rare but workable scenario in a point release, back then), and somewhat more complex, making the task more effort than it's worth. Now, if you need something not there, you'll be somewhat hard pressed to do it yourself.

For all of the whining kernel releases are a lot less buggy with fewer distro deviations from mainline. And as a bonus features actually get better testing now because fewer changes need to be tested at a time.
Have you looked at many of the distros out there right now? Many are way back on 2.6.18 as of recently, with custom patchlevels and backported drivers. THe ONLY reason there were significant backport issues with 2.5->2.4 was because the backports were occasionally poorly done, and there's a significant driver architecture difference. The latest 2.6 stuff is still considered "heavy development" and isn't all that stable. So we get the 'heavy development' model, to some degree, while not benefiting from having the true 'cutting edge'/redesign. We're just getting a more bloated kernel with the same basic architecture (nevermind the several-times-wrought architecture changes we've seen in 2.6 in firewire, USB, schedulers, etc.).

--
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers

Re:GPL Intellectual Theft by c0lo · 2010-08-01 16:00 · Score: 2, Funny

Hello,

As a consultant for several large companies, I'd always done my work on Windows. Recently however, a top online investment firm asked us to do some work using Linux.

... then ...

although it was tough to do, there really was no
option: We had to rewrite the code, from scratch, for Windows 2000.

Hey, David, is that you? Some times back I received an email from you (reproduced below): is the offer still available?

Dear Sir/M,
I am Mr.David Mark. an Auditor of a BANK OF THE NORTH INTERNATIONAL,ABUJA (FCT).
I have the courage to Crave indulgence for this important business believing that
you will never let me down either now or in the future.
Some years ago, an American Mining consultant/ contractor with the
Nigeria National Petroleum Corporation, made a numbered time (fixed) deposit
for twelve calendar months, valued $12M.USD (TWELVE MILLION US DOLLARS) in an account.

--
Questions raise, answers kill. Raise questions to stay alive.

Re:GPL Intellectual Theft by Grey+Ninja · 2010-08-01 16:13 · Score: 4, Funny

Troll Review:

Believability: 1/10. I would have given you a zero, except I notice one comment here that seems to think it's a legitimate point.

Humour: 6/10. The punch line was honestly not expected, and elicited a smile from me. But it would need a bit more work to truly be hilarious.

Anger response: 4/10. A fairly good natured troll. It does little to incite anger, but I think that if you worked on it a bit more and made the story more plausible, you could be a real contender, inciting hundreds of flames.

Overall: 5/10. A nice effort, but a little too obvious, and the punchline just wasn't enough, given the length of the post. The punchline could have been delivered in one simple paragraph.

Re:The year of... by 0123456 · 2010-08-01 16:17 · Score: 1

Wow. Just wow. I'm speechless. I hope you are kidding.

Indeed. I pretty much switched over to Linux on the desktop in 2009.

Re:GPL Intellectual Theft by Tuqui · 2010-08-01 16:20 · Score: 2, Informative

Furthermore, after reviewing this GPL our lawyers advised us that any
products compiled with GPL'ed tools - such as gcc - would also have to
its source code released. This was simply unacceptable.

You should hire a better lawyer, GCC does NOT restrict develop non-free programs. Check the FAQ for more info.

The man took a two week vacation twelve years ago. by ghjm · 2010-08-01 17:05 · Score: 2, Insightful

Do we still have to talk about "burnout" every time we mention kernel maintenance?

Re:The man took a two week vacation twelve years a by Tubal-Cain · 2010-08-01 17:17 · Score: 1

More than ever.

Re:Welcome... to the REAL world (NEO) by Bert64 · 2010-08-01 18:00 · Score: 4, Insightful

Were I in their shoes, I would realise that commercial software comes with no more of a warranty than open source. Despite all the money they extract from you, commercial vendors provide you no warranty whatsoever and you have to agree to these terms before they will let you use the software.

You can also buy commercially supported versions of open source, there are a huge number of such products available now.

If you want a system so critical that it flies a plane then you typically write it in house (there aren't that many places that actually build planes). you test it extremely thoroughly (far more so than any commercial vendor does), and then you have multiple redundant backup systems too.

The reality is that many decision makers in business and government simply don't understand very much when it comes to technology, they buy into propaganda that open source is bad but will happily buy things like cisco asa firewalls without realising they run linux.

--
http://spamdecoy.net - free throwaway anonymous email - avoid spam!

World of Warcraft 3.3.5 fix made it into 2.6.35 by Anonymous Coward · 2010-08-01 18:03 · Score: 5, Informative

The fix for World of Warcraft under WINE made it into 2.6.35, though it is not mentioned in the changelist above. WoW 3.3.5 crashed under recent Linux kernels because it apparently made use of the "icebp" instruction, whatever that is; the kernel stopped sending SIGTRAP for icebp instructions in an earlier 2.6 build for whatever reason.

Diff of fix
Source code of file, showing the icebp fix merged in (search for "icebp")
WINE compat page

Re:The man took a two week vacation twelve years a by JohnBailey · 2010-08-01 18:08 · Score: 4, Funny

Do we still have to talk about "burnout" every time we mention kernel maintenance?

Yep. It isn't a meme unless it gets repeated over and over.

--
It is difficult to get a man to understand something when his job depends on not understanding it.

Re:Welcome... to the REAL world (NEO) by 0123456 · 2010-08-01 19:06 · Score: 3, Informative

I am also a professional software engineer/network engineer by trade since 1995

A young whippersnapper, then. When you have a bit more experience of the real world you might start to understand just how many critical systems already run on Linux.

BTW, I can make a safe bet that anyone writing avionics software is not running it on Windows either. Back when I was writing avionics software it all ran on custom hardware with no OS worth speaking of; and having a 'free' OS wasn't much of a benefit when our hardware was selling for the price of an expensive sports car.

Re:Poor Bert64: Reduced to name tossing by Bert64 · 2010-08-01 20:52 · Score: 1

Go and read the original post.

--
http://spamdecoy.net - free throwaway anonymous email - avoid spam!

Re:The man took a two week vacation twelve years a by maxume · 2010-08-01 23:51 · Score: 1

When did Linus get a motorcycle?

--
Nerd rage is the funniest rage.

my wishlist by StripedCow · 2010-08-02 00:22 · Score: 3, Informative

Since there seems to be no place on the internet where to post feature-requests for linux, here's four points from my list:

1. User-space scheduling. It would be nice if a process could have better control on the priority of each of its threads. For example, on a web service where multiple users are active, it is often necessary to give each user his/her share of the cpu. Right now this is rather difficult to do in a fair way, since multiple threads may belong to the same user.

2. Recursive strace: Currently it is not possible to run "strace" on a process which is already being straced. So for example: "strace -f strace -f ls" will not work (you'll get an "operation not permitted" inside the first strace. This makes it impossible for programs to use strace (or the related ptrace system call), since other programs which might also use strace, may depend on them.

3. "Nice" for bandwidth. It would be great if there was a command similar to "nice", which acts not on cpu-cycles but instead on bandwidth.

4. "Select" or "poll" with access to inter-thread synchronization structures. Select and poll are system calls which act mainly on file-descriptors. However, sometimes you'd like to wait also on a mutex or semaphore. Some support for this would be great.

This list is just from the top of my head. I could probably come up with a lot more.

Alex

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.

Re:my wishlist by sick_soul · 2010-08-02 01:39 · Score: 1

3. "Nice" for bandwidth. It would be great if there was a command similar to "nice", which acts not on cpu-cycles but instead on bandwidth.
This one is since a long time in my wishlist too.
Some tc and iptables magic can realize this (traffic shaping), but the nice/renice metaphor would be easier and make more sense.
Re:my wishlist by KiloByte · 2010-08-02 01:42 · Score: 1

"Nice" for bandwidth. It would be great if there was a command similar to "nice", which acts not on cpu-cycles but instead on bandwidth.
Do you mean network bandwidth, or IO bandwidth? That's iptables --pid-match (although you'd usually want --uid-match or --gid-match instead), or ionice.

--
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Re:my wishlist by sick_soul · 2010-08-02 01:46 · Score: 1

ionice seems as close as it gets..
seems to be only for CFQ I/O Scheduler, and still not very straightforward.
Re:my wishlist by sick_soul · 2010-08-02 01:51 · Score: 1

..and only for disk I/O. Damn.
Re:my wishlist by StripedCow · 2010-08-02 02:10 · Score: 1

Yes, and the iptables solution only works for root, if i'm correct.

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Re:my wishlist by vipw · 2010-08-02 02:16 · Score: 1

Regarding "nice" for bandwidth, there is wondershaper, but it has very coarse controls.
There is a very nice program called NetLimiter for Win32. I would love to see a clone of it for linux. Of course, all it really would be is some iptables magic and would unfortunately have to run with root privileges. Pyshaper is abandoned but seemed to be on the right track.
I would love to see user/group permissions introduced into the kernel's packet filtering to remove the need for root access in some cases. A user *should* have the ability to control the shaping of the packets that are sent from and being delivered to sockets of processes it has the permission to signal. It sounds hard to write, and could certainly introduce a few privilege escalation errors. But it would be a very sweet addition. The current system of having each application control its own bandwidth use obviously doesn't scale.
I see the issue as something like with pulseaudio and per-application volume control. By being truly uniform, it could be presented to the user in a sane way, for example as the main screen of a network activity dock applet.
These are just my thoughts. But I really think that the requirement of root access to control bandwidth of other processes is the reason why no one has implemented a quality solution.
Re:my wishlist by Sits · 2010-08-02 02:17 · Score: 1
Sounds like a lot of your wishlist won't be implemented any time soon:
1. You may be able to do some of that using cpusets and cgroups.
2. Yeah that is a pity. Some speculate that such a feature will not appear until the ptrace syscall is replaced.
3. Proportional I/O control might happen eventually (beyond what ionice offers for disks today).
4. Another good point. Apparently this can't be (easily) done today unless you can afford to miss wakeup events (in which case you could use futex_fd).
Re:my wishlist by StripedCow · 2010-08-02 02:18 · Score: 1

I think what linux needs is a way to internally associate the process id with each data-packet. Then, when a packet is routed through some bandwidth-limited channel (like your network card), the kernel could assign a priority to the packet based on the pid. But this is just an idea.
The iptables solution is just too simple, I think. Also, you have to invoke it as root.

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Re:my wishlist by StripedCow · 2010-08-02 02:26 · Score: 1

Since there seems to be no place on the internet where to post feature-requests for linux
Which suggests a fifth point:
5. A place to post Linux feature requests! Also, a roadmap would be nice!

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Re:my wishlist by Cajun+Hell · 2010-08-02 02:52 · Score: 4, Insightful

Since there seems to be no place on the internet where to post feature-requests for linux
There are tons of places on the internet for that. Try monster.com. "Wanted: Linux kernel hacker."

--
"Believe me!" -- Donald Trump
Re:my wishlist by joib · 2010-08-02 05:29 · Score: 1

1. User-space scheduling. It would be nice if a process could have better control on the priority of each of its threads. For example, on a web service where multiple users are active, it is often necessary to give each user his/her share of the cpu. Right now this is rather difficult to do in a fair way, since multiple threads may belong to the same user.
If normal priorities aren't sufficient, you can setup cgroups.

3. "Nice" for bandwidth.
For IO, ionice? Or, again, cgroups allows fair sharing IO and network BW, IIRC.

4. "Select" or "poll" with access to inter-thread synchronization structures. Select and poll are system calls which act mainly on file-descriptors. However, sometimes you'd like to wait also on a mutex or semaphore. Some support for this would be great.
Isn't this what pthreads condition variables are for? Or can you explain what you want in more detail?
Re:my wishlist by StripedCow · 2010-08-02 06:15 · Score: 2, Interesting

Isn't this what pthreads condition variables are for? Or can you explain what you want in more detail?
The main point is that it is now not easily possible to wait for both a file and a mutex, for example. A workaround could be waiting for a pipe, and writing to the pipe in a separate thread, but of course, this may become hairy.
From a user-space programmer's perspective, it would be nice to have the synchronization objects and file descriptors in the same id-space, but perhaps a simpler solution is possible.
Btw, thanks for the pointer to cgroups. I'm not sure if it entirely matches my needs, but I'll look into it.

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Re:my wishlist by Fred+Foobar · 2010-08-02 21:14 · Score: 1

2. Recursive strace: Currently it is not possible to run "strace" on a process which is already being straced. So for example: "strace -f strace -f ls" will not work (you'll get an "operation not permitted" inside the first strace. This makes it impossible for programs to use strace (or the related ptrace system call), since other programs which might also use strace, may depend on them.
Hi Alex, I think you meant strace'ing a process multiple times, rather than recursive strace'ing. You can certainly use ptrace on a process that is using ptrace on another process, but the issue is trying to ptrace a process that is already being ptrace'd. In other words:
x -> y -> z
(x, y, z are processes, -> means tracing) works, but
x -> z <- y
does not work because process "z" can be traced only once. I think the technical reason a process can be traced only once is because only one parent can receive the process's state via the wait() system call, much like only one process can receive its child's exit status via wait() in a non-ptrace situation. There may be other reasons for it as well, but I couldn't locate the POSIX standards (IEEE 1003.4 Realtime Extensions, I believe) detailing the ptrace() system call and its rationale.
If I misunderstood what you meant about recursive strace, then I do apologize.

--
It was a really good paper.
Re:my wishlist by StripedCow · 2010-08-02 21:23 · Score: 1

Thanks for the reply, but I really meant "recursive" strace.
The particular problem I have is that I want to make an installer which tracks all the write-operations of its child-processes. This can be easily done using strace. However, now imagine somebody else also writing an installer (also using strace), and using my installer as one of its child processes. On linux, this will fail.
Also imagine somebody else using strace to inspect what my installer is doing... this will also fail.

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Re:my wishlist by anon+mouse-cow-aard · 2010-08-03 00:38 · Score: 1

if all you are doing is using strace to figure out where the program is writing, then a libc shim is probably a better idea than strace. you pre-load the shim, it tells you where the child process is writing, with no extra process, and full "recursion" support. http://www.jayconrod.com/cgi/view_post.py?23 no, it doesn't work with statically built binaries... I think static binaries are stupid and should die. but as someone else mentioned, the only way around such things is kernel support for the function desired.
Re:my wishlist by StripedCow · 2010-08-03 00:56 · Score: 1

Well replacing libc with a shim would not be very robust, since libc is entirely optional, and like you said, static binaries are making this approach fail.
(Of course, I could edit theose static ELF binaries, and replace the kernel calls, etc. But this seems to be totally not the right way (tm) to do it.)
Besides, having the ability to intervene at the interface between a process and the kernel, and hence be able to totally control the I/O behavior of a process, is something that, in my opinion, should be present in a modern OS. Think of all the possibilities for debugging, sandboxing, install-software, automatic dependency checking by build-tools, etc.

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Re:my wishlist by anon+mouse-cow-aard · 2010-08-03 01:30 · Score: 1

Besides, having the ability to intervene at the interface between a process and the kernel, and hence be able to totally control the I/O behavior of a process, is something that, in my opinion, should be present in a modern OS. Think of all the possibilities for debugging, sandboxing, install-software, automatic dependency checking by build-tools, etc.
None of the functions you describe need to be in the kernel to be effective. For debugging, shims are fine, for sandboxing, you can use any of a variety of vm's, for install software, there are tools like fakeroot (again using libc shim.) used extensively in debian packaging. I think that, a decade ago, static binaries made some sense. But they don't anymore for anything but a few corner cases. In general, the arguments against static linking (binary size, memory footprint, security updates, and the current prevalence of repositories with dependency management) are now far stronger than any of the old arguments for them (essentially application developers not knowing if a particular library was present on the target... dependency management.)
There really is no excuse any more, so the libc shims works well, so there is no need to use the kernel to accomplish what you are asking. And the general rule is that anything that can be done in user space, should be done there...
Re:my wishlist by StripedCow · 2010-08-03 01:34 · Score: 1

Agree with a lot you said. But my main concern is that shims are not robust. It is just waiting for some disaster going to happen.
You give all sorts of solutions, but the best solution is still to put it in the kernel, imho.

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.

Sun and GPL by Anonymous Coward · 2010-08-02 00:24 · Score: 2, Interesting

Eh. Sun intentionally chose the license to be GPL incompatible.

This keeps being said. Do you have a source for this?

Re:Sun and GPL by GooberToo · 2010-08-02 04:49 · Score: 1

I've never read anything with Sun saying it, but that hardly matters. It was well known Sun had a dislike for Linux. Sun was losing more licenses to Linux than any other competing OS. Every market share study indicates this, and has for a very long time. Sun was also losing mind share to Linux, which is why they created their Solaris/GNU distros and added Linux compatibility. In doing so they stayed relevant and "cool". All of a sudden Sun announces/releases ZFS whereby its license is completely incompatible with Linux. Now, suddenly, Sun has a cool, enterprise technology, which isn't available on Linux but is available on Solaris, and while they are providing Linux compatibility. Hmmm...
I mean, come on, do we really have to be in denial and debate everything? Especially when its obvious, good business for Sun? To believe ZFS was not intentionally created to be Linux/GPL incompatible is literally to be nieve. Or, perhaps you believed Sun to be so inept to be incapable of such an obviously strong business play? To believe this, all that is required is to believe Sun had a desire to grow its market and mind share. Come on...no conspiracies required.

Re:Welcome... to the REAL world (NEO) by Thinboy00 · 2010-08-02 03:09 · Score: 1

So buy RHEL and stop flaming.

--
$ make available

Re:my wishlist - nice for b/w, not a kernel thing. by anon+mouse-cow-aard · 2010-08-02 03:31 · Score: 1

It would be way better to do this as a libc pre-load shim. just overload "open" to get the path names/ip addresses of what file/connection is associated with each fd, then override read and write to track i/o rates, and block when exceeded. Could also do it based on iops...(counting each read/write as an op, and giving op budget...)

Have a little config file consulted by the shim library:

~/.bwnice.conf: 199.237.54.1:80 5 MB/s /tmp/videocache.bin 5 MB/s etc...

I dunno what your use case is, you could use this for stuff you start as a user, or added to the system config, and have it apply to all users. To do system-wide stuff, tc is already plenty good enough, thought it only applies to network stuff. Dunno of anything for limiting b/w to local disk.

anyway, you don't need any kernel anything for this feature. basic rule is if it can be done in user space, it very often ought to be done there.

http://www.ibm.com/developerworks/linux/library/l-glibc.html

http://www.linuxjournal.com/article/7795

Re:my wishlist - nice for b/w, not a kernel thing. by anon+mouse-cow-aard · 2010-08-02 03:35 · Score: 1

was to good an idea not to have been thought of...

http://www.tuxradar.com/content/control-your-bandwidth-trickle

It's done! by google, no less...

Re:my wishlist - nice for b/w, not a kernel thing. by StripedCow · 2010-08-02 04:02 · Score: 1

anyway, you don't need any kernel anything for this feature. basic rule is if it can be done in user space, it very often ought to be done there.

Totally agree with you on the last part! However, this raises the rhetoric question why "nice" itself isn't totally handled inside libc :P

Also, such a feature should not be too difficult to add to the kernel. If it really would be difficult, then isn't the kernel getting just too complicated for its own good?

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.

Come on. by Tolkien · 2010-08-02 04:32 · Score: 1

Stop talking about Linus' burn-out. Why bring up pointless issues? What are you trying add to add to the conversation by saying that?

--
how is babby formed?

Re:my wishlist - nice for b/w, not a kernel thing. by anon+mouse-cow-aard · 2010-08-02 07:58 · Score: 1

man 2 nice

Nice is done in libc, at least the interface to handing the nice setting to the scheduler is. This is just an added setting into the kernel's process scheduler. You'll find that a lot of people argue a lot about how to do scheduling right. The nice setting is just one constant that it inserted into an algorithm that has to exist anyways.

For I/O, traditionally there has never really been a "scheduler". The whole idea was to use the device to it's maximum capability all the time. Devices are controlled by single drivers, and the idea of preferring some blocks over others doesn't exist. So there is no kernel level thing to hook into. You would have to add new stuff... in many places, because network and block devices don't share much below libc level.

Nowadays, there are bits and pieces such as laptop drive spinup preventers and such that perhaps do perform a bit of prioritization (stopping the spin up of drives by using cache a bit more aggresively.) But I've never seen a general mechanism.

I'm not convinced that one that worked by process is necessarily the best approach. My hunch is that it makes more sense to set a priority as a file attribute, and set i/o priorities based on what file is being accessed.

For example, A low priority job trying to write a log message might monopolize the system log for a long time because it is low priority. It makes more sense for i/o to the log to be high priority, but i/o to an application data file that is exclusively accessed by a user app be lower priority. there are a lot more cases of exclusive access locks with i/o scheduling vs. process scheduling... the benefits for i/o scheduling in the kernel probably are not that clear.

It would probably make a better case for it if someone implemented the libc case (eg. taking trickle and extending it to deal with block i/o as well, and and extending it to be system-wide, instead of per process.) to build a prototype i/o scheduler. This would give some real-world use cases. After it was thoroughly beaten upon, then folks could look at what bits of it makes sense to fold it into the kernel proper, and what is just fine in user space. fun project!

Re:my wishlist - nice for b/w, not a kernel thing. by vipw · 2010-08-02 09:36 · Score: 1

Using a libc shim for controlling network access is stupid. Libc is completely optional, so the only place to reliably control such a thing is in the network stack, which means in the kernel.

As for the rhetorical question, libc doesn't have any control of scheduling, so it's not even possible to implement features provided by nice.

And throttling (shaping) is supported by the kernel infrastructure. Incoming and outcoming packets can be processed by netfilter/iptables. I just haven't seen any user friendly program for changing them on a per process or program basis.

Re:my wishlist - nice for b/w, not a kernel thing. by anon+mouse-cow-aard · 2010-08-02 10:49 · Score: 1

why is it per process/program? I suspect the real problem is that individual files should be prioritized, not processes. kernel eventually maybe. demo in user space first

Re:my wishlist - nice for b/w, not a kernel thing. by vipw · 2010-08-02 19:08 · Score: 1

A big problem with doing it per file is that many processes run from the same file. It's not at all uncommon to have multiple processes accessing the network that are the same binary file. Think about interpreters or virtual machines like python or java.

Re:my wishlist - nice for b/w, not a kernel thing. by anon+mouse-cow-aard · 2010-08-03 00:24 · Score: 1

you don't want to set the priority on the network interface, any more than you want to set priority on access to /dev/sda. In both cases, it is meaningless. For network, you need to have the choice to do it by the remote ip&port combo, or the local one. It does not matter whether it is interpreted or not, they will all get to libc eventually.

For example, I would make DNS requests very high priority. I would have something like *.dns, assigned very high priority, and ptp stuff relatively low, which would help optimize browser responsiveness. If I have some data at a particular web site that is important to me, I could increase priority of i/o to that web site, versus ordinary i/o.

Someone would have to implement this to see if it actually makes any difference in real life. Typically, I find that an idea that is simple enough that isn't already done, probably has something wrong with it ;-)

Re:my wishlist - nice for b/w, not a kernel thing. by vipw · 2010-08-03 06:56 · Score: 1

libc is completely optional.

104 of 159 comments (clear)