Slashdot Mirror


Linux Kernel 2.6.35 Released

eldavojohn writes "Linus has announced the release of 2.6.35 for people to download and test after he found not a lot of changes between this week and last. 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' as well as various performance and graphics improvements. Linus also praised the community saying that 'regression changes only' after rc1 improved this time around and gave numbers to back it up saying 'in the 2.6.34 release, there were 3800 commits after -rc1, but in the current 35 release cycle we had less than 2000.' Good to see the process is becoming more refined and controlled after the first release candidate — hopefully there's no impending burnout."

159 comments

  1. 3.6.35? by Lord+Byron+II · · Score: 4, Funny

    Wow. The future has arrived.

    Way to double-check your article, Timothy.

    1. Re:3.6.35? by Anonymous Coward · · Score: 0

      Yeah, I thought I was *really* behind the curve when I read that.

    2. Re:3.6.35? by smi.james.th · · 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...
    3. Re:3.6.35? by belthize · · Score: 2

      This is not the thread you're looking for.

    4. Re:3.6.35? by jd · · 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)
    5. Re:3.6.35? by Lucky75 · · Score: 0, Offtopic

      I believe you forgot to wave your hand before your post. *Waves hand* "This is not the droid...err...thread you're looking for" Sorry, couldn't resist ;)

      --
      DNA -- National Dyslexic Association
    6. Re:3.6.35? by Anonymous Coward · · Score: 0

      Choke and joke if you like, but I *JUST* finished building 2.6.35-rc6-git6. Just. I have a whole bunch of modules and with a quad core hyperthreaded cpu (CoreI7-920) it still takes about 35 minutes to build a kernel. Damn!

  2. 2.6.35 has not been released by KermodeBear · · Score: 0

    It says so, with big Caution images all over the linked page.

    --
    Love sees no species.
    1. Re:2.6.35 has not been released by MichaelSmith · · 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.

    2. Re:2.6.35 has not been released by belthize · · Score: 2, Informative
    3. Re:2.6.35 has not been released by jd · · 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)
  3. Still no ZFS. by 0100010001010011 · · 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.

    1. Re:Still no ZFS. by tenchikaibyaku · · 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. :-)

    2. Re:Still no ZFS. by afabbro · · 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
    3. Re:Still no ZFS. by retchdog · · Score: 4, Informative

      Courtesy of the inimitable Emo Philips.

      --
      "They were pure niggers." – Noam Chomsky
    4. Re:Still no ZFS. by smi.james.th · · 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...
    5. Re:Still no ZFS. by afabbro · · 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
    6. Re:Still no ZFS. by jd · · 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)
    7. Re:Still no ZFS. by 0100010001010011 · · 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.

    8. Re:Still no ZFS. by TangoMargarine · · Score: 0, Offtopic

      "Christian or Buddhist"? Kind of sounds like an odd dichotomy...

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    9. Re:Still no ZFS. by jd · · 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)
    10. Re:Still no ZFS. by 0123456 · · 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.

    11. Re:Still no ZFS. by Lord+Kano · · 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
    12. Re:Still no ZFS. by vadim_t · · 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.

    13. Re:Still no ZFS. by Anonymous Coward · · 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.

    14. Re:Still no ZFS. by cheater512 · · 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.

    15. Re:Still no ZFS. by Anonymous Coward · · 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?!

    16. Re:Still no ZFS. by RMS+Eats+Toejam · · Score: 0, Insightful

      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.

      Sure, you could have used the money, but being able to brag about your sense of morality later on Slashdot makes up for it. A little sad in the long run though.

      --
      Turning to a Linux advocate for thoughts on Microsoft is like asking Hitler how he felt about the Jews.
    17. Re:Still no ZFS. by CAIMLAS · · 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
    18. Re:Still no ZFS. by 0123456 · · 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.

    19. Re:Still no ZFS. by drsmithy · · 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.

    20. Re:Still no ZFS. by Anonymous Coward · · Score: 0

      Do they use Microsoft ? Otherwise most common programming language are open source (java, ruby, groovy, python, etc...) or rely on open source libraries.

    21. Re:Still no ZFS. by 0100010001010011 · · 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.

    22. Re:Still no ZFS. by AHuxley · · Score: 1

      I want my TRIM too :)

      --
      Domestic spying is now "Benign Information Gathering"
    23. Re:Still no ZFS. by Anonymous Coward · · Score: 0

      companies have built specialty FreeBSD distros for their high end routers

      Companies have likewise built speciality Linux distros for their high end routers. Juniper is a fine example.

    24. Re:Still no ZFS. by joib · · 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".

    25. Re:Still no ZFS. by k8to · · 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
    26. Re:Still no ZFS. by Anonymous Coward · · Score: 0

      They don't have someone to sue in either case. Don't they read the contracts and licenses?

    27. Re:Still no ZFS. by ByOhTek · · 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).
    28. Re:Still no ZFS. by realityimpaired · · 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.

    29. Re:Still no ZFS. by tehcyder · · 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
    30. Re:Still no ZFS. by gbjbaanb · · 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.

    31. Re:Still no ZFS. by AvitarX · · 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
    32. Re:Still no ZFS. by Anonymous Coward · · Score: 0

      We all want to get some trim.

    33. Re:Still no ZFS. by rubycodez · · 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)

    34. Re:Still no ZFS. by Thinboy00 · · Score: 1

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

      --
      $ make available
    35. Re:Still no ZFS. by raddan · · 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.

    36. Re:Still no ZFS. by Anonymous Coward · · Score: 0

      How is it a dead platform now? Oracle just recently announced they'd be working with OEMs (I recall Dell and HP specifically, may be wrong on that) to sell Solaris boxes. Why would OpenSolaris get killed, given the push for putting Solaris out there? The free/closed with support model works very well, it'd be foolish to kill it.

    37. Re:Still no ZFS. by jd · · 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)
    38. Re:Still no ZFS. by petermgreen · · 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
    39. Re:Still no ZFS. by Lord+Kano · · 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
    40. Re:Still no ZFS. by Lord+Kano · · 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
    41. Re:Still no ZFS. by snadrus · · 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.
    42. Re:Still no ZFS. by Anonymous Coward · · Score: 0

      Jobs come and go? No shit? Such radical genious is surely their loss. Oh well. I'm sure cleaning the ball pit at Chucky Cheeses's doesn't pay as well, but at least it's an ethical job that helps keep children healthy.

      No one is looking to buy your ethics. A job needed to be done. Rejecting that job because you believe in some software holy-crusade cooked up by a fat-ass computer geek from the 1960s who probably hasn't even smelled a vagina in his life and they don't is nothing short of pure fucking stupidity. Some here will surely look at you as some kind of folk hero, but that's no more impressive than a gang of retards watching a tether-ball in action.

  4. Re:The year of... by MichaelSmith · · 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..

  5. Re:The year of... by uprise78 · · Score: 1

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

  6. Re:GPL Intellectual Theft by maxume · · Score: 1

    Too overt.

    --
    Nerd rage is the funniest rage.
  7. Re:GPL Intellectual Theft by retchdog · · Score: 2, Informative

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

    --
    "They were pure niggers." – Noam Chomsky
  8. Big Features? by Anonymous Coward · · 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.

    1. Re:Big Features? by FauxPasIII · · 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
    2. Re:Big Features? by adamofgreyskull · · 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.

    3. Re:Big Features? by Anonymous Coward · · Score: 0

      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?

      Don't worry, it was just a hatchback-sized one.

    4. Re:Big Features? by vlm · · 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
    5. Re:Big Features? by nschubach · · 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.
    6. Re:Big Features? by snadrus · · 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.
  9. Re:GPL Intellectual Theft by cjcela · · 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.

  10. Re:GPL Intellectual Theft by jd · · Score: 0, Offtopic

    There's champagne that's drinkable after 200 years. Until the troll passes the century mark, I'm not going to consider it as even coming close to having been aged.

    --
    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)
  11. Re:GPL Intellectual Theft by TangoMargarine · · 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
  12. once burned, twice shy by epine · · 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>

    1. Re:once burned, twice shy by Ethanol-fueled · · Score: 1

      Ballmer would make a much better Kramer.

    2. Re:once burned, twice shy by CAIMLAS · · 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
    3. Re:once burned, twice shy by gmack · · 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.

    4. Re:once burned, twice shy by Anonymous Coward · · Score: 0

      It just makes me uneasy that anything as big as Linux has such a small point of failure.

      actually, having seen the bloat in Linus over the years, he's now a pretty big point of failure

    5. Re:once burned, twice shy by Anonymous Coward · · 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.

    6. Re:once burned, twice shy by CAIMLAS · · 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
  13. Re:GPL Intellectual Theft by c0lo · · 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.
  14. Re:GPL Intellectual Theft by Grey+Ninja · · 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.

  15. Re:The year of... by 0123456 · · 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.

  16. Re:GPL Intellectual Theft by Tuqui · · 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.

  17. Re:GPL Intellectual Theft by retchdog · · Score: 0, Offtopic

    Ah, a taste for the classics.

    --
    "They were pure niggers." – Noam Chomsky
  18. Re:GPL Intellectual Theft by Anonymous Coward · · Score: 0

    This is an ancient, ancient troll. How do people keep falling for it?

  19. Re:The year of... by Anonymous Coward · · Score: 0

    lol

  20. I suppose by Anonymous Coward · · Score: 0

    I suppose if you're a linux fanbois such a minimal increment in kernel nomenclature is a very big deal. Maybe even warrants a slashdot article. (And people say it's Apple's Kool-aid...)

  21. The man took a two week vacation twelve years ago. by ghjm · · Score: 2, Insightful

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

  22. Re:The man took a two week vacation twelve years a by Tubal-Cain · · Score: 1

    More than ever.

  23. Welcome... to the REAL world (NEO) by Anonymous Coward · · Score: 0

    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. by Anonymous Coward on Monday August 02, @12:55AM (#33107066)

    Whether you like it or not? See my subject-line above. That IS how the real world really is and especially in business... and, were YOU in their shoes, would you blame them?? I mean, for example, you probably have a vehicle of somekind. Let's say it has a KNOWN defect that demands recall because it is costing lives. Wouldn't you want some form of remuneration/compensation and care for such an issue?? You certainly would. The same rules apply to the world of software as well. People being people, they definitey do, especially those who do not have the skills to do the work themselves (as in the case of say, cars/vehicles, not everyone is a mechanic... and in the case of softwares & OS' also?? Well, face it: Not everyone is a software engineer or network engineer/techie even, either). So, yes, the person you replied to as well as yourself in both cases?? Guys, it's the real world, and we all know it and also demand the same (as in the case of other products you buy such as cars/vehicles as I noted above (yes, I know - another "Car Analogy", but it does fit here)). People want somekind of "plan B" to fall back on when things matter with tools they use, period. By the way? I am also a professional software engineer/network engineer by trade since 1995 also, and though you or I may not LIKE this scenario, we also may be hypocrites sounding off on it being "wrong" etc., because again, in the case of other products we use, we often demand this ourselves (again, cars serve as an example for many here, or even our computer hardware, if when found faulty? We want remuneration/compensations via warranties, etc./et al).

    1. Re:Welcome... to the REAL world (NEO) by Bert64 · · 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!
    2. Re:Welcome... to the REAL world (NEO) by 0123456 · · 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.

    3. Re:Welcome... to the REAL world (NEO) by Thinboy00 · · Score: 1

      So buy RHEL and stop flaming.

      --
      $ make available
    4. Re:Welcome... to the REAL world (NEO) by Anonymous Coward · · Score: 0

      I would trust my plane and therefor my life to linux. I would feel much safer than the sailors who's ships run windows, that is including the fact that boats don't generally fall out of the sky when the BSOD.

  24. World of Warcraft 3.3.5 fix made it into 2.6.35 by Anonymous Coward · · 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

  25. Re:The man took a two week vacation twelve years a by JohnBailey · · 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.
  26. Re:The year of... by dbIII · · Score: 0, Flamebait

    Probably as it should be. At least then RMS and others purely in it for the politics won't notice it, claim credit for the work of others, try to take control and try to mess things up for everyone.

  27. Troll, give us a break, ok? Thanks! by Anonymous Coward · · Score: 0, Troll

    "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." - by 0123456 (636235) on Monday August 02, @03:06AM (#33107656)

    LMAO - Oh, really? You'd be surprised at how many MORE run on say, Microsoft's Windows NT-based OS' as well as those from the likes of IBM for instance... & as to "young whippersnapper"?? LMAO, again, because I've actually been around these systems for over 28++ yrs. now, & for nearly 16 professionally as both a dev using multiple languages, tools, & OS' + as a network administrator as well (in addition to having done quite well in publication & technical contests for my works in commercial wares, such as MS' Tech Ed, 2yrs. in a row no less & in its hardest category). I also possess multiple degrees around this science... have you done the same to ALL of the above? Somehow, despite your attempted ad hominem attack upon myself, rather than disputing points I made (which is the last resort of trolls on both accounts mind you on your part), and attempting to act as if YOU were my "senior" in this art & science? I doubt it. As to wares written for defence contractors? Check with Raytheon and their artillery control wares written for the IRAQ conflict, because the poster I replied to mentioned working for defense contractors. Soldiers lives depend on it, and yes, it works, and it's written on the Windows platform, so... Better luck next time, troll.

    1. Re:Troll, give us a break, ok? Thanks! by Anonymous Coward · · Score: 0

      I'm 12 and what is this?

  28. Re:OpenSores support contracts CO$T Bert by Bert64 · · Score: 0, Offtopic

    Support contracts for *ANYTHING* cost money...

    I even mentioned that you can buy commercially supported versions of open source software, i suggest you read the post again. Hint: it's the second paragraph.

    The difference is that open source gives you the choice, you can get the software free and self support, you can pay for support, you can even pay for the software if you choose, and there are often multiple sources you can buy support from. Proprietary software takes away these choices, you have to pay for the software, in most cases you then have to pay *AGAIN* for support, and only the original supplier has the source code so only they can provide an adequate level of support.

    Use of the term "open sores" is laughable, and no better than those who refer to Microsoft as M$.

    Also, your use of "you're" makes no sense, did you mean to write "your" instead? As it stands, what you wrote reads as "You are stuff is no longer really free....", print yourself a t-shirt and you can earn a place on engrish.com.

    The word "cost" is spelled "c o s t", the "$" symbol is not a letter, it represents a form of currency, or denotes variables in some kinds of programming. And i can see that your "s" key is not broken because you've used the letter "s" in other places.

    Over all, a very poor troll. I feel insulted to be trolled by you.

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  29. Re:Poor Bert64: Reduced to name tossing by Bert64 · · Score: 1

    Go and read the original post.

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  30. funny ha haaa :o by Anonymous Coward · · Score: 0

    > As a consultant for several large companies

    Could you name some ?

    > a top online investment firm asked us to do some work using Linux

    What was the name of this investment firm?

    > The concept of having access to source code was very appealing to us, as we'd be able to modify the kernel to meet our exacting standards

    What projects do you work on that require recompiling the kernel :

    > Although we met several technical challenges along the way
    (specifically, Linux's lack of Token Ring support

    Who still uses Token Ring ?

    > and the fact that we were unable to defrag its ext2 file system)

    Enough of this bullshit already ...

  31. Re:The man took a two week vacation twelve years a by maxume · · Score: 1

    When did Linus get a motorcycle?

    --
    Nerd rage is the funniest rage.
  32. Re:LOL, Insightful? SUPPORT CO$T$ though! by Anonymous Coward · · Score: 0

    Maybe the moderation is a hint that everyone else thinks you're stupid?

  33. my wishlist by StripedCow · · 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.
    1. Re:my wishlist by sick_soul · · 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.

    2. Re:my wishlist by KiloByte · · 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.
    3. Re:my wishlist by sick_soul · · Score: 1

      ionice seems as close as it gets..

      seems to be only for CFQ I/O Scheduler, and still not very straightforward.

    4. Re:my wishlist by sick_soul · · Score: 1

      ..and only for disk I/O. Damn.

    5. Re:my wishlist by StripedCow · · 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.
    6. Re:my wishlist by vipw · · 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.

    7. Re:my wishlist by Sits · · 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).
    8. Re:my wishlist by StripedCow · · 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.
    9. Re:my wishlist by StripedCow · · 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.
    10. Re:my wishlist by Cajun+Hell · · 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
    11. Re:my wishlist by joib · · 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?

    12. Re:my wishlist by StripedCow · · 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.
    13. Re:my wishlist by Anonymous Coward · · Score: 0

      Write your code. Send it in. Be a hero.

    14. Re:my wishlist by Anonymous Coward · · Score: 0

      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.

      Check out this script from the tor project. It sets up the kernel routing/queuein/prioritizing capabilities to quickly set up prioritizations for user or virtual interfaces.

      I use it for giving a lower priority to torrent upload traffic. Unfortunately it's only upload, since it's the router that drops download packages.

    15. Re:my wishlist by Anonymous Coward · · Score: 0

      pthread mutexes are implemented on Linux using futexes, which are select'able and poll'able objects. So it is easily possible. Just because the pthreads library doesn't give you a direct way of doing it doesn't mean it isn't possible.

    16. Re:my wishlist by Fred+Foobar · · 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.
    17. Re:my wishlist by StripedCow · · 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.
    18. Re:my wishlist by anon+mouse-cow-aard · · 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.

    19. Re:my wishlist by StripedCow · · 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.
    20. Re:my wishlist by anon+mouse-cow-aard · · 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...

    21. Re:my wishlist by StripedCow · · 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.
  34. Sun and GPL by Anonymous Coward · · Score: 2, Interesting

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

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

    1. Re:Sun and GPL by GooberToo · · 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.

  35. Re:my wishlist - nice for b/w, not a kernel thing. by anon+mouse-cow-aard · · 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

  36. Re:my wishlist - nice for b/w, not a kernel thing. by anon+mouse-cow-aard · · 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...

  37. Re:my wishlist - nice for b/w, not a kernel thing. by StripedCow · · 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.
  38. Come on. by Tolkien · · 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?

  39. Ahem: Another BULLSHIT excuse? See inside by Anonymous Coward · · Score: 0

    Maybe the moderation is a hint that everyone else thinks you're stupid? - by Anonymous Coward

    on Monday August 02, @07:56AM (#33108650)

    Yea, see subject-line above: Says it ALL about the "moderation" here, & especially since ALL YOU'VE GOT ARE YOUR AD-HOMINEM ATTACKS instead of attacking the points I made (which are, indisputable, because they're simply the truth is all (and you KNOW it)).

    You & they may THINK I am stupid, but to tell you the truth, based on your lack of being able to dispute the 2-3 points I made here? Well, I KNOW you are stupid, period.

  40. Re:GPL Intellectual Theft by Anonymous Coward · · Score: 0

    This sounds like FUD to me.

    It is also older than the internet.

  41. Re:my wishlist - nice for b/w, not a kernel thing. by anon+mouse-cow-aard · · 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!

  42. Re:my wishlist - nice for b/w, not a kernel thing. by vipw · · 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.

  43. Re:my wishlist - nice for b/w, not a kernel thing. by anon+mouse-cow-aard · · 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

  44. Re:my wishlist - nice for b/w, not a kernel thing. by vipw · · 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.

  45. LINUX KERNEL PANICS Bert64? by Anonymous Coward · · Score: 0

    Linux NEVER, EVER screws up or crashes (same with its apps too), Bert64? Tell us about KERNEL PANICS then please, won't you, Bert64? See below:

    ----

    Reboot Linux box after a kernel panic:

    http://www.cyberciti.biz/tips/reboot-linux-box-after-a-kernel-panic.html

    ----

    (Gotta love the Linux fanboys'/zealots' "straight-outta-pravda" BULLSHIT around here - Especially Bert64's)

    He & his multiple registered user accounts usage to mod up his posts and to mod down the posts of others here when they show him up as the deceptive 1/2 truth spewing old fool he really is.

    Example? Ok, see here:

    http://linux.slashdot.org/comments.pl?sid=1739756&cid=33108472

    (That's where Bert64 "conveniently omits" that LINUX SUPPORT CONTRACTS CO$T MONEY... so that really means that Linux isn't TRULY "free" and that their deceptive advertising policy is along the lines of "BEER IS FREE: $1,000 DOLLAR BOTTLE DEPOSIT FEE THOUGH")

  46. Keep blowing your mod points Linux dolts! by Anonymous Coward · · Score: 0

    http://linux.slashdot.org/comments.pl?sid=1739756&cid=33120408 It's merely truths, just like this URL above is, along with others which were down modded in this exchange, vs. the BULLSHIT propoganda the Linux fanboys can't handle. See that URL above where just some of the negative truths about LINUX are mentioned, and then witness the technically unjustified mod downs you get around here. Do the Linux dimwits with their effete mod downs fool anyone? Answer = NO. They merely show they're full of it and all they are left with is their unjustified effete mod downs of others posts.

  47. Re:my wishlist - nice for b/w, not a kernel thing. by anon+mouse-cow-aard · · 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 ;-)

  48. Trying to mod the truth away LINUX dolts? LOL! by Anonymous Coward · · Score: 0

    See subject-line above and realize 1 thing Linux dolts: You may effetely mod down posts' points you cannot dispute, but you cannot destroy the truths they contain!

    Truths, such as:

    1.) Linux support contracts costing money, meaning it's not free. It's more like it's deceptive advertising like "FREE BEER, $1,000 DOLLAR BOTTLE DEPOSIT FEE"

    and

    2.) That Linux being "Open SORES" is just that - since it's code is freely available, the hacker/cracker types can find security holes TO USE AGAINST IT, quicker (quicker than can be done to closed source because that demands more time consuming methods such as fuzzers &/or debuggers-disassemblers).

    So, please: KEEP BLOWING YOUR MOD POINTS AND DOING YOUR UNJUSTIFIED MOD DOWNS WITH NO TECHNICAL SUBSTANCE BEHIND THEM - Because by doing so, You're really only showing the rest of us you are "on the ropes" because all you have are your unjustified mod downs!

  49. Trying to mod the truth away LINUX dolts? LOL! by Anonymous Coward · · Score: 0

    See subject-line above and realize 1 thing Linux dolts: You may effetely mod down posts' points you cannot dispute, but you cannot destroy the truths they contain!

    Truths, such as:

    1.) Linux support contracts costing money, meaning it's not free. It's more like it's deceptive advertising like "FREE BEER, $1,000 DOLLAR BOTTLE DEPOSIT FEE"

    and

    2.) That Linux being "Open SORES" is just that - since it's code is freely available, the hacker/cracker types can find security holes TO USE AGAINST IT, quicker (quicker than can be done to closed source because that demands more time consuming methods such as fuzzers &/or debuggers-disassemblers).

    So, please: KEEP BLOWING YOUR MOD POINTS AND DOING YOUR UNJUSTIFIED MOD DOWNS WITH NO TECHNICAL SUBSTANCE BEHIND THEM - Because by doing so, You're really only showing the rest of us you are "on the ropes" because all you have are your unjustified mod downs...

  50. Trying to mod the truth away LINUX dolts? LOL! by Anonymous Coward · · Score: 0

    See subject-line above and realize 1 thing Linux dolts: You may effetely mod down posts' points in this exchange that you cannot dispute, but you cannot destroy the truths they contain!

    Truths, such as:

    1.) Linux support contracts costing money, meaning it's not free. It's more like it's deceptive advertising like "FREE BEER, $1,000 DOLLAR BOTTLE DEPOSIT FEE"

    and

    2.) That Linux being "Open SORES" is just that - since it's code is freely available, the hacker/cracker types can find security holes TO USE AGAINST IT, quicker (quicker than can be done to closed source because that demands more time consuming methods such as fuzzers &/or debuggers-disassemblers).

    as well as

    3.) LINUX KERNEL PANICS DO HAPPEN, as well as apps on it crashing or malfunctioning (despite the Linux fanboys b.s. they do not)

    In fact, on the last note? See here, as proof thereof:

    ----

    Reboot Linux box after a kernel panic:

    http://www.cyberciti.biz/tips/reboot-linux-box-after-a-kernel-panic.html

    ----

    So, that all said & aside?

    Please: DO KEEP BLOWING YOUR MOD POINTS AND DOING YOUR UNJUSTIFIED MOD DOWNS WITH NO TECHNICAL SUBSTANCE BEHIND THEM - Because by doing so, You're really only showing the rest of us you are "on the ropes" because all you have are your unjustified mod downs!

  51. FACE FACTS BOY (INSIDE) by Anonymous Coward · · Score: 0

    So buy RHEL and stop flaming. - by Thinboy00 (1190815) writes: > on Monday August 02, @11:09AM (#33110536) Journal

    I run these OS' here @ home and on the job:

    A.) KUbuntu 10.4 latest stable

    B.) FreeBSD 8.1

    C.) Windows 7

    (Each is 64 bit, and each has its hassles... not a single one is "Crash-Proof" either, given enough of a load and time...)

    Also, see subject-line above, and realize 1 thing Linux dolts: You may effetely mod down posts' points in this exchange that you cannot dispute, but you cannot destroy the truths they contain!

    Truths, such as:

    1.) Linux support contracts costing money, meaning it's not free. It's more like it's deceptive advertising like "FREE BEER, $1,000 DOLLAR BOTTLE DEPOSIT FEE"

    and

    2.) That Linux being "Open SORES" is just that - since it's code is freely available, the hacker/cracker types can find security holes TO USE AGAINST IT, quicker (quicker than can be done to closed source because that demands more time consuming methods such as fuzzers &/or debuggers-disassemblers).

    as well as

    3.) LINUX KERNEL PANICS DO HAPPEN, as well as apps on it crashing or malfunctioning (despite the Linux fanboys b.s. they do not)

    In fact, on the last note? See here, as proof thereof:

    ----

    Reboot Linux box after a kernel panic:

    http://www.cyberciti.biz/tips/reboot-linux-box-after-a-kernel-panic.html

    ----

    So, that all said & aside?

    Please: DO KEEP BLOWING YOUR MOD POINTS AND DOING YOUR UNJUSTIFIED MOD DOWNS WITH NO TECHNICAL SUBSTANCE BEHIND THEM - Because by doing so, You're really only showing the rest of us you are "on the ropes" because all you have are your unjustified mod downs!

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

    libc is completely optional.