Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux 3.10 Merge Windows Closes

Posted by samzenpus on from the finishing-it-up dept.

hypnosec writes "Linus Torvalds has released the Linux 3.10-rc1 kernel marking the closure of the 3.10 merge window. The Linux 3.10-rc1 is the second biggest rc release in years and the closure of the merge windows means that the features expected out of the Linux 3.9 successor are chalked out. "So this is the biggest -rc1 in the last several years (perhaps ever) at least as far as counting commits go," Linus notes in the release announcement."

74 comments

  1. Merge Windows Closes by boshvark · · Score: 5, Funny

    So Linux is finally merging with Windows... uh, that can't be right. I guess windows will now merge when you close them? No, that doesn't make sense either, so maybe it's a new Unity feature.

    --
    There's always money in the banana stand.
    1. Re:Merge Windows Closes by Samantha+Wright · · Score: 5, Funny

      No, no, it says quite clearly that they're only merging with Windows 3.1, which is barely Windows by any useful definition. Didn't you RTFA? Jeez, the nerve of some people...

      --
      Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
    2. Re:Merge Windows Closes by i+kan+reed · · Score: 4, Informative

      This is a phenomenon known as a Garden path sentence. The phrasing leads you to believe that windows is a singular noun, when it is in fact a plural noun with a different meaning. For anyone still confused: these are the windows to merge changes into source-control before release.

    3. Re:Merge Windows Closes by Anonymous Coward · · Score: 0

      waiting for 3.11, it's gonna be waaaay better than that lame 3.1. i just know it.

    4. Re:Merge Windows Closes by Anonymous Coward · · Score: 0

      Barely windows?

      Oh, come on... Windows 3.1 has multimedia support!

    5. Re:Merge Windows Closes by Anonymous Coward · · Score: 0

      Finally, C#+ will become a reality!

    6. Re:Merge Windows Closes by Anonymous Coward · · Score: 4, Informative

      No, the problem here isn't a garden path sentence, the problem is illiterate Slashdot editorial processes as usual. The right headline was "Linux 3.10 merge window closes" but the usual brain damage morphed that into what you see now.

      If there were several "merge windows" then that would be plural, but the verb changes to agree, that's how English works. So you'd get "Linux 3.10 merge windows close".

      You can write the sentence "Linux 3.10 merge windows closes" in English, but you need "window" to be a verb and then the "merge windows" noun + verb assembly becomes a singular compound noun which you can use with the verb "closes". You would probably never want to do this, and it's not what anybody at Slashdot intended, but it's a possible English sentence. Shakespeare used to treat "window" as a verb, so you wouldn't necessarily be in the worst company, but Shakespeare was a fucking genius, the people editing Slashdot can't even compete with those monkeys Mr Burns had working on A Tale of Two Cities.

    7. Re:Merge Windows Closes by wonkey_monkey · · Score: 1

      This is a phenomenon known as a Garden path sentence [wikipedia.org].

      I'm pretty sure it's just a crappily written one.

      --
      systemd is Roko's Basilisk.
    8. Re:Merge Windows Closes by Anonymous Coward · · Score: 0

      I think I'll just wait for Linux for Workgroups 3.11.
      Wait, darn, Linus already did that joke.

    9. Re:Merge Windows Closes by Anonymous Coward · · Score: 0

      Title capitalization is to blame as well.

    10. Re:Merge windows closes by Anonymous Coward · · Score: 0

      Yes, why the heck do they do that?
      Is It Normal To Write First Letter In Each Word Uppercase Like This In English Language Or Is It Only Slashdot That Writes Like This?

      It is horrible to read that way anyway. Perhaps english typewriters didn't have minus
      so they couldn't underline it back in stone age? Here we have green background and bold font
      or whatever the H4 i stylized to so there is no reason for that anymore...

    11. Re:Merge windows closes by armanox · · Score: 1

      For being parsed by RSS readers and appearing in the title bar? And that it is still considered proper to capitalize titles?

      --
      I'm starting to think GNU is the problem with "GNU/Linux" these days.
    12. Re:Merge Windows Closes by Anonymous Coward · · Score: 0

      I can't wait to have Linux kernel 3.11 for Workgroups!

    13. Re: Merge Windows Closes by Anonymous Coward · · Score: 0

      3.14*

  2. BUT THAT IS A GOOD THING !! by Anonymous Coward · · Score: 0

    Am I right !!

  3. Wine in kernel by tepples · · Score: 0

    Or maybe they're bringing Wine into the kernel? No, that's NDISwrapper.

    1. Re:Wine in kernel by Anonymous Coward · · Score: 0

      The Windows 8 kernel was coded with wine, vast quantities.

  4. WTF at the title by kernelpanicked · · Score: 2

    You got an extra s in there, yo.

    "Linux 3.10 Merge Windows" had me getting ready to scout out a new OS.

    The merge window closing, however, is a good thing.

    --
    Ubuntu: If at first you don't succeed, blindly slap a sudo in front of it
    1. Re:WTF at the title by wonkey_monkey · · Score: 1

      Gollum writeses

      Fixed.

      --
      systemd is Roko's Basilisk.
    2. Re:WTF at the title by girlinatrainingbra · · Score: 1

      Yeah, and earlier the so-called "editors" mixed up psychiatrists (Medical Doctors) and psychologists (Ph.D. Doctors) in their article about the British Psychological Association. They titled the post "Psychiatrists Cast Doubt On Biomedical Model of Mental Illness". You'd think the name of the British Psychological Association might have given them a clue.
      .
      These editors couldn't find a clue if you put the board game "Clue" in front of their faces! (ba-dum-dum!)

  5. Yes, nice. But why is this a story? by gweihir · · Score: -1, Redundant

    Everybody concerned will already have this news from other sources. Everybody else does likely not care, also because typical users use distro-kernels and not self-compiled kernels from kernel.org. And this is not even the kernel release, but the closing of the merge-window, i.e. only of interest to kernel developers, making it even more irrelevant as a /. story.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:Yes, nice. But why is this a story? by serviscope_minor · · Score: 5, Insightful

      Everybody concerned will already have this news from other sources.

      You are mistaken.

      I care enough to RTFA, and I got the story here.

      Why? I care about kernel development because it interests me, but I don't care about it enough to require absoloutely up to the minute coverage. So, slashdot is an excellent place to get it, and there are often useful comments to boot.

      Basically, you could say the same about any story: anyone who cares enough could get the news faster from a domain specific source.

      Everybody else does likely not care, also because typical users use distro-kernels and not self-compiled kernels from kernel.org.

      Huh? These features will make it into distros soonish, and secondly since when is slashdot only the domain of typical users.

      And this is not even the kernel release, but the closing of the merge-window,

      The two are equivalent from this perspective: the actual release will have no new features.

      --
      SJW n. One who posts facts.
    2. Re:Yes, nice. But why is this a story? by Anonymous Coward · · Score: 0

      You're missing the point, which is that the next time a friendly Dice employee decides to let us know what's on their mind, and when irritable folks like you start your rabbling, this story can be pointed to as a true story for NERDS.

    3. Re:Yes, nice. But why is this a story? by Anonymous Coward · · Score: 0

      Everybody concerned will already have this news from other sources. Everybody else does likely not care, also because typical users use distro-kernels and not self-compiled kernels from kernel.org. And this is not even the kernel release, but the closing of the merge-window, i.e. only of interest to kernel developers, making it even more irrelevant as a /. story.

      It's because it has something-something-something to do with Ubuntu, you fool.

    4. Re:Yes, nice. But why is this a story? by swillden · · Score: 2

      Everybody concerned will already have this news from other sources.

      I'm interested, and I learned of it here.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    5. Re:Yes, nice. But why is this a story? by Kjella · · Score: 1

      Actually I'd argue exact the opposite, this is the earliest possible convenience where it is possible to say when and what features will be coming with reasonable certainty. Post-launch reviews are fun but most of the news are about upcoming products/services/changes and really what you just said - it won't actually be in distros on release day anyway. So you can read about it now, it'll release in two months, be in most distros this fall and in Debian in 2016.... maybe. That said, in the rush to get this story out and get page hits they forgot the part about making a decent summary of what's new and why it should matter, but hey... it would be the right time.

      --
      Live today, because you never know what tomorrow brings
    6. Re:Yes, nice. But why is this a story? by cryptizard · · Score: 1

      Nice that they included some highlights of these features in the summary then instead of saying nothing that the title wouldn't tell you just as well... oh wait.

    7. Re:Yes, nice. But why is this a story? by Anonymous Coward · · Score: 0

      Well since you can speak for EVERYBODY, I suppose I can too.

      Shut
      the
      Fuck
      Up.

    8. Re: Yes, nice. But why is this a story? by Anonymous Coward · · Score: 0

      Soonish ... Yea, it ought to make Debian by 2016, maybe.

    9. Re: Yes, nice. But why is this a story? by Anonymous Coward · · Score: 0

      3.9 is expected to be the kernel for Debian Necrosis due out sometime after 2030.

  6. NVIDIA borken again... by Anonymous Coward · · Score: 3, Informative

    They changed the kernel enough so that the NVIDIA binary blobs are börken (sic) again! Something about whether is a real 2.4 kernel and whatnot. It seems just to be a test, but its anal and börken! I understand that NVIDIA is a commercial company and as such cannot keep up to the rate of development of OSS developers.

    1. Re:NVIDIA borken again... by Anonymous Coward · · Score: 2, Informative

      Same goes for ATI's fglrx, which was broken due to removal of some deprecated procfs functions. This was the first time I got a lemon by updating kernel during merge window.

    2. Re:NVIDIA borken again... by Anonymous Coward · · Score: 1

      Get some sound advice

    3. Re:NVIDIA borken again... by smoothnorman · · Score: 1
      yep/me-too/%#$!! the best annoying dumb trick comes via dkms (Dynamic Kernel Module Support). so there's was a working graphics module (for nvidia blob 304.88) then unlucky fool (which would be me) does an update/dist-upgrade, and so dkms uninstalls the working module, attempts to install a new module, which fails to compile ("nv-i2c.c function ‘nv_i2c_del_adapter’ : error: void value not ignored as it ought to be") and now we're left with a box which will have no graphics upon reboot.

      next-up: any kernel >= 3.10.0-rc1 (yes yes... that's "-rc" so technically: no whining!) effects the transition of create_proc_entry() to proc_create() which no nvidia blob nor source seems remotely ready for.

    4. Re:NVIDIA borken again... by Anonymous Coward · · Score: 1

      I've personally found that if you get your kernel module into the baseline, the kernel devs will generally update it when the kernel interfaces change, assuming that the module itself hasn't become totally obsolescent; I wonder if nVidia has considered this?

    5. Re:NVIDIA borken again... by magic+maverick+ · · Score: 1

      So I guess you'll not buy Nvidia again? Because they obviously don't care about your Linux experience. Because if they did, they'd open source their driver, and work to get it accepted into the Linux mainline tree. So that then the kernel developers would maintain it for them. For free.

      Oohh ohh.

      Nvidia had a charming air
      All cheap and debonair
      You found so sweet
      And so you took Nvidia in
      Your sheets still warm with him
      Now filled with filth and foul disease
      As time wore on Nvidia proved
      A debt-ridden drunken mess
      Leaving you
      A poor consumptive wretch

      Or something like that.

      --
      HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
    6. Re:NVIDIA borken again... by dbIII · · Score: 1

      I don't think the current bunch at Nvidia would open their drivers until the day after software patents are abolished. There's some ex-SGI people there that got burnt by a 3D graphics software patent troll.
      So don't rant at Nvidia, rant at the stupid IP system that has made them too paranoid to release anything that a patent troll can use against them. Keep in mind that it's the sort of environment where John Carmack eventually had to pay off a troll to continue to use the algorithm that had been named after him!

    7. Re:NVIDIA borken again... by spike+hay · · Score: 1

      Has there been a time when fglrx was no broken?

      --
      If you don't understand any of my sayings, come to me in private and I shall take you in my German mouth.
    8. Re:NVIDIA borken again... by Anonymous Coward · · Score: 0

      I'm thinking of something... why not create something like ndiswrapper, but for display drivers? I know, it may sound stupid (maybe there are dependencies on directx for graphic card drivers, for example), but I'm surprised nobody seems to have thought of it

    9. Re:NVIDIA borken again... by Anonymous Coward · · Score: 0

      Yes, yes, I understand why NVIDIA isn't releasing. They have cross licensing deals with many companies, Intel has to pay *them* $1.5 billion in cross licensing fees over 5 instalments. Software licenses *should* be illegal, since its the implementation of math, but US courts don't know about math, after all math from a pencil might be different from math on a calculator, or math on a computer. While there is confusion, we have software patents, and a lucrative business for patent trolls and the lawyers they employ. I'm not asking for NVIDIA to open anything. Even if they wanted to, they don't want to get burned. I support their decision (although I support team Nouveau too). When I posed about NVIDIA drivers being börken (sic), it was merely with a sigh, and as an informative post to /.ers who build new Linux kernels and use NVIDIA hardware. Somewhere around:
      the bottom
      of nv-i2c.c something clearly isn't happy. I even added wasReleased = FALSE after where it says wasReleased = TRUE; just to change the value of wasReleased and see if that would make the driver happy (and it did not). The #if defined(KERNEL_2_4) compiler directive seems to be trying to probe the device (first with i2c_add_adapter, followed immediately by i2c_del_adapter) to see if its responding. I didn't try changing the value of ossstatus either, but that might be worth a try.

  7. list of changes by ssam · · Score: 3, Informative

    For folk who even after RTFA wonder whats new in 3.10, the best source is probably LWN
    https://lwn.net/Articles/548834/
    https://lwn.net/Articles/549477/

    1. Re:list of changes by Anonymous Coward · · Score: 0

      Why don't the kernel devs use bug numbers in reference to "what's new/fixed"?

    2. Re:list of changes by Anonymous Coward · · Score: 0

      "Subscription required"
      No thank you, link to something better next time.

    3. Re:list of changes by greg1104 · · Score: 2

      You can't have a single stream of bug numbers in a true multi-vendor open source project. RedHat can assign something a bug number, but so can the Debian team, Canonical, etc. Seeing a unique bug number for a free software project is actually a bad sign. It usually means a single person or company is behind that project. What you want instead is a developer community that can survive losing any one member.

    4. Re:list of changes by DragonWriter · · Score: 2

      You can't have a single stream of bug numbers in a true multi-vendor open source project.

      Since there are schemes for assignment of unique identifiers that allow multiple parties to generate their own identifiers without coordination except on a standard scheme, and to do so maintaining uniqueness, this isn't true.

    5. Re:list of changes by greg1104 · · Score: 2

      Of course you can add a prefix to each vendor and therefore allow them to share a larger bug address space. The simplest scheme is to make RedHat bugs RH-xxxxxx, Debian ones DE-xxxxxx, etc. The shared allocation approach taken by CVE numbering could be used too. I would call that a combined or aggregated stream of bug numbers rather than a single stream; that's a hair splitting distinction though.

      Regardless, to be effective for tracking regular bugs and features, you would also need resources to coordinate things like tagging duplicates across vendors. A Linux bug might be upstream of ten different distribution bugs. When it's fixed in the kernel, which bug number should the commit refer to?

      With a complicated enough mapping of vendor bug number to kernel bug number, you could try to capture this information too. That's another shared resource someone needs to maintain though. It's overhead with little perceived value to the individual vendors involved. Linux distributors are motivated to get bug fixes pushed upstream. There's a benefit in it for them. There's little benefit for any one vendor to having a universal bug number mapping tracker, relative to the complexity you'd need to maintain a useful one. Even if you had most of the major distributions agreeing on the shared numbering scheme, there's also time needed to coordinate the bug ids for contributions to the project outside of those vendors.

      The number of CVE incidents is low enough (and the issues serious enough) that the bug id mapping they do is not a serious drag on development. One of the reasons the Linux kernel can innovate at a high rate is because it's not burdened by this sort of management issue most of the time.

  8. So I can run Windows programs on Linux? by Anonymous Coward · · Score: 0

    So I can now run Windows programs on Linux? Well its about time! What took so long? I'm sure Emballmer must be throwing some chairs around in Redmond!

  9. Woohoo, another game of "guess the verb"! by neminem · · Score: 1

    Only a day after the last installment! Though this article only has 3 possible candidates, to that article's 4... those candidates are 3/5s of all the words in the headline, to that other article's 4/7.

  10. I'm with you on this. by Robert+Frazier · · Score: 2

    I'm happy to see the story. I regularly look at 4 or 5 websites, only 2 of which have anything to do with computing technology, and this is one of them, which I've been following for quite a while. So, although it may not be ideal, I still get most of my technology updates on slashdot. (Other than ones in which I'm professionally interested, the site I spend most time on also deals with technology, but of a different sort: mechanical watches.)

    Best wishes,
    Bob

  11. mainline flashcache and bcache by Gothmolly · · Score: 4, Informative

    Are the things I care about - and I suspect most people do too, even if they don't know about it. The eed to transparently (or not!) accelerate spinning drives with SSD is a killer feature. I'm currently running a homebrew NAS on Linux and my VMWare hosts insist on doing sync mounts - effectively killing performance. By shimming some SSD in front of that, my IO latency bottleneck essentially goes away. (Lets leave ZFS out of this). "Desktop" distros will love this too - I see a simple "wizard" that asks "I see you have an SSD installed - would you like to accelerate access to your HD? Click yes and specify a maximum cache size" Presto - an instant increase in performing most tasks.

    --
    I want to delete my account but Slashdot doesn't allow it.
    1. Re:mainline flashcache and bcache by jones_supa · · Score: 2

      "Desktop" distros will love this too - I see a simple "wizard" that asks "I see you have an SSD installed - would you like to accelerate access to your HD? Click yes and specify a maximum cache size"

      Might not happen. Currently any distro does not even turn on discard for a SSD automatically (due to TRIM implementation being a bit broken in Linux).

    2. Re:mainline flashcache and bcache by Anonymous Coward · · Score: 0

      Many SSDs considered all-zeros written to a block to be considered "free". Kind of a poor-man's TRIM.

    3. Re:mainline flashcache and bcache by Gothmolly · · Score: 1

      That's a separate problem. The basics of using fast storage to cache slow storage are what's critical here - whether you have dodge block device support is irrelevant. A few different options are marked for inclusion in 3.9 as experimental, and slated for 3.10.

      --
      I want to delete my account but Slashdot doesn't allow it.
  12. 3.1 vs 3.10!? by im_thatoneguy · · Score: 0

    Am I the only one who thinks having a version number which is subject to getting rounded off is a terrible terrible idea?

    "Oops looks like this release has a trailing 0 on there... *delete*."

    1. Re:3.1 vs 3.10!? by Anonymous Coward · · Score: 1

      Apparently yes, you are the only one.

    2. Re:3.1 vs 3.10!? by jones_supa · · Score: 3, Informative

      Am I the only one who thinks having a version number which is subject to getting rounded off is a terrible terrible idea?

      "Oops looks like this release has a trailing 0 on there... *delete*."

      Terrible idea? That's how version numbers work. They are not ordinary decimal numbers, so you cannot round them like that.

    3. Re:3.1 vs 3.10!? by Anonymous Coward · · Score: 0

      Kinda late for that, 1.1.10 was released in 1994.

    4. Re:3.1 vs 3.10!? by Anonymous Coward · · Score: 1

      Version numbers are not floating point numbers. They are a set of integers separated by punctuation. If you treat them like anything else, you're doing it wrong.

      Try your drainbead logic on IP addresses so we can continue laughing at you.

    5. Re:3.1 vs 3.10!? by Xtifr · · Score: 1

      You're probably not the only one, but that doesn't mean that the set of people who think it's a terrible idea are any less misguided or wrong. This is normal and standard and most tools for tracking versions assume version numbers work this way. Including the tools that do dynamic linking at run-time for you. In fact, for libraries, it's mandatory to do this if you have more than ten backwards-compatible releases in a series. A change in the second number of a library's version indicates that it's backwards-compatible but not forwards-compatible. (Forwards-compatible changes get a change in the third digit; incompatible changes get a change in the first.)

      The only people likely to be confused to the degree that you suggest are non-technical idiots in the commercial press, and they'll make illiterate mistakes about all sorts of things no matter what we do. Hundreds of thousands of software projects do this sort of thing regularly (as AC pointed out, linux v. 1.1.10 was released in 1994). It's "three dot ten", not "three point one zero". Version numbers aren't decimals.

      Of course, a lot of projects make sure to always list all three numbers (e.g. 3.10.0). Which I admit I prefer. But it's still the start of the 3.10 series.

    6. Re:3.1 vs 3.10!? by Anonymous Coward · · Score: 0

      intelligence doesn't exclude stupidity?

    7. Re:3.1 vs 3.10!? by Anonymous Coward · · Score: 0

      Or how about double decimal poits?

      "Hmmm 3.9.2 that's totally bogus ...*deletes all of kernel.org*

    8. Re:3.1 vs 3.10!? by sdnoob · · Score: 1

      okay.. how about apple's way:

      version 3.x

      there. much better.

    9. Re:3.1 vs 3.10!? by kernelpanicked · · Score: 1

      Do we really have to have this conversation every single time any software releases version_dot_ten? It's getting a bit old at this point.

      --
      Ubuntu: If at first you don't succeed, blindly slap a sudo in front of it
    10. Re: 3.1 vs 3.10!? by Anonymous Coward · · Score: 0

      Try your drainbead logic on IP addresses so we can continue laughing at you.

      IP addresses aren't written like that anymore. Nowadays they are separated with colons.

    11. Re: 3.1 vs 3.10!? by Blaskowicz · · Score: 1

      and you need a fucking PhD to know what they mean, and have Rain Main's abilities to remember them.

    12. Re: 3.1 vs 3.10!? by Zaelath · · Score: 1

      Yeah, cause IPv6 addresses are written, a lot, they're not just allocated by one computer to another.

    13. Re:3.1 vs 3.10!? by Anonymous Coward · · Score: 0

      Why not use 3.01 instead of 3.1?

    14. Re:3.1 vs 3.10!? by unixisc · · Score: 1

      That's what should have been done, and the reason it wasn't was that it was thought that after 3.9, they'd go to 4.0 - if they got to 3.9 at all in the first place. Remember, they went directly from 2.6 to 3.0, and even in version 1, I don't recall them going to 1.10. This new trend in KDE & Linux is pretty annoying - if you need more than 9 minor revisions, then number it exactly like you suggested.

    15. Re:3.1 vs 3.10!? by Anonymous Coward · · Score: 0

      Sure I can!


      int i = round(3.10);
      printf("%d", i);

      --> 3

      So it's linux 3 I guess then

    16. Re:3.1 vs 3.10!? by jones_supa · · Score: 2

      int major = round(3);
      int minor = round(10);
      printf("%d.%d", major, minor);

  13. Wait, what? by csumpi · · Score: 0

    Linux is merging with Windows?

  14. LOL. by Anonymous Coward · · Score: -1

    Remember back in the day when anyone actually gave a shit about Linux? LOL. How many people still give a shit about it? You could probably count them on one hand since OS X basically demolished it in every area from performance to security.

    1. Re:LOL. by Anonymous Coward · · Score: 0

      Becuse OS X has such a strong presence on servers, supercomputers, embedded, etc, etc...

      iOS can compete with Linux on tablets and smartphones, but that is the extent of apple's ability to compete with Linux.

      OS X can't even hold a candle to Linux as a development platform.

  15. Separators in IP addresses by unixisc · · Score: 1

    IPv4 addresses are very much written like that, and they are still the overwhelming majority. IPv6 is only slowly making inroads, and the vast majority of it is auto-configured, so nobody has to remember them so far, at least.