10 ms·
Linux 4.6 is out
- known 10y agoI'm now compiling it with optimized HOSTCFLAGS
- ajdlinux 10y agoA good summary of interesting new things in this release can be found at http://kernelnewbies.org/Linux_4.6 http://kernelnewbies.org/Linux_4.6
- dominotw 10y ago>Support for cgroup namespaces This release adds support for cgroup namespaces, which provides a mechanism to virtualize the view of the /proc/$PID/cgroup file and cgroup mounts. What are the advantages and practical applications of this ? documentation here : https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d4021f6cd41f03017f831b3d40b0067bed54893d https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
- webkike 10y agoI imagine all the advantages that come with namespaces in a more advanced OS like plan 9
- zxcvcxz 10y agoHow many large companies are using plan 9 in production though?
- gh02t 10y agoTo a first approximation... zero. That is to say, I don't know any (and I've looked a bit) and the realities of the limited hardware support make it difficult to imagine. I don't know of anybody using Inferno either, but I'm less familiar with it. I'd also dispute the suggestion that Plan9 is more advanced than Linux. It's different and Plan9 definitely does some interesting things, but that doesn't automatically make it more advanced. Ignoring that "advanced" is hard to quantify, I'd more that Plan9 is simply based on different concepts. It's like comparing Windows and Linux, albeit maybe not quite so extreme as Plan9 and Linux have more in common and Plan9 is simply not as heavily developed as either OS.
- cm3 10y agoCoraid used to build and sell systems based on Plan9, but I believe they don't exist anymore, though I don't mean to imply Plan9 was at fault, quite the contrary.
- stonogo 10y agonot only is this a pretty stupid measuring stick, this non sequitur application of it comes off as needlessly defensive
- stormbrew 10y agoDon't think this has anything to do with anything plan9 can do that Linux can't already. The barriers to enabling the magic plan9 has are more along the lines of making it feasible for unprivileged users to mount and create namespaces themselves, which is complicated (afaik) largely by the way privilege escalation happens in unix systems. This just looks like it prevents some information from leaking out about the host system from inside a cgroup by inspecting the /proc/PID/cgroup file.
- wyldfire 10y agoBoy, I hope the memory constraints for cgroups are getting better. I'm stuck on an ancient platform where cgroups are relatively new-ish (SuSE Linux Enterprise 11). We hit a huge anti-feature where fs cache eviction from a cgroup-memory-constrained process happened in the foreground and caused astonishing latency. Sounds like it was the intended design. Hopefully it's evolving to no longer be limited like that.
- teraflop 10y agoI'm not sure what you're referring to as an "anti-feature". By design, if a process requests memory when it's already at its limit, the kernel will wait until more memory is available -- which could require a writeback, if the contents of the pagecache are dirty. Would you have preferred for the kernel to instead allow the process to exceed its memory limit, even if that means evicting something else outside the container? If so, why not just set the limit higher? Apologies if I'm misunderstanding something.
- wyldfire 10y agoSorry if some of this is already clear but I'll try and back up a bit and give more context. Linux uses greedy caching for filesystems and it's usually pretty awesome. But by merely opting in to be in a memory-constrained cgroup, it is (was?) no longer able to reap those pages in the background. Perhaps it's because the kernel daemons that would ordinarily do that don't have the right context. Or in order to have it they'd need to have one instance for each cgroup dir/context. Effectively what we found was that opting out of cgroups memory constraints meant that we would still cause the filesystem cache to get evicted in order to make room for our memory allocations but with significantly lower latency. I suspect that what might have been happening is that when cgroup-memory-bound, we faulted in a disk-backed page and that triggered logic that decided it needed to evict other pages in order to make room for this one. So far, so good. But then perhaps it got opportunistic and figured "since I can't know that I need to background-evict these pages I had better foreground-evict as many as I can now." This is all wild speculation on my part. But what was clear was that our process would suffer a multi-second stall while evicting pages. Disabling cgroups-memory constraints meant that we would not hit this same condition. More background: our application would read mapped files into memory, transform the data then write it out over sockets. The file-reading-task would read files whose size exceeds the total system memory. All files were opened read-only, the pages were never dirtied. There were no swap devices. I don't recall all the specifics but the gist we got from the distro was that "yeah, it works that way and it's not a bug." All I wanted to do was make it so that the greedy process could eat up no more than half of system memory with stuff like the fscache or dumb allocations. That would mean that other processes would be much less likely to stall when doing memory allocations.
- cyphar 10y agoIt also allows you to mount the cgroupfs in an unprivileged user namespace (useful for rootless containers, something I'm working on in runC). It's not entirely useful at the moment to be honest, since all it does is mask /proc/self/cgroup. But it could be extended later to also virtualise /proc/meminfo and /proc/cpuinfo to reflect the cgroup limits. I'm currently trying to get a patch merged into cgroup core to allow for processes in a cgroup namespace to manage their own cgroups (without compromising the hierarchy limits). Hopefully it gets into 4.7. This will be exceptionally useful for cgroup hierarchies.
- digi_owl 10y agoMy impression i enhancing security within containers. This because now a would be attacker can't as easily tell if they are inside a container or not after exploiting some daemon vulnerability.
- ZenoArrow 10y agoThanks for the link. I was surprised to learn that the BATMAN protocol had reached mainline Linux, and version 5 no less. I hadn't realised quite how healthy the development of this protocol was. https://en.wikipedia.org/wiki/B.A.T.M.A.N https://en.wikipedia.org/wiki/B.A.T.M.A.N. https://www.open-mesh.org/projects/open-mesh/wiki https://www.open-mesh.org/projects/open-mesh/wiki
- reactor 10y agoMay be a noob question, but is Linus himself review all these commits before merging to mainline? Or each section (for eg: networking) got its own owners?
- ianleeclark 10y agoHe has a system of trusted maintainers for different sub-sections of the kernel. There's simply too many patches for one man to review.
- meeper16 10y agoI can't access the invitation to the church of the subgenius in the README.txt's anymore. What's going on?
- gcr 10y agoWould you mind expanding upon this a little? I feel like there's a wonderful nugget of history here just waiting to be rediscovered by the broader hacker news community. Sounds like it could make a good story?
- gnoway 10y agoI don't know what parent is talking about w/ README files. But Slackware Linux (slack... get it?) includes a link to the church in their install.end file. They started scrambling it in a recent release.
- colejohnson66 10y agoNot much of a scramble if it's just ROT13... [0]: https://slackbuilds.org/mirror/slackware/slackware-current/slackware/ap/install.end https://slackbuilds.org/mirror/slackware/slackware-current/s...
- chris_wot 10y agoHence the "sub" in subgenius.
- AdieuToLogic 10y agoFor extra security, I like to employ "double ROT13" encryption... (ducks) :-)
- Qwertious 10y agoIt occurred to me recently that if you were accused of breaking someone's rot13 'encryption', you could claim double-encryption to dodge the charge. Assuming they aren't thrown out of court for calling rot13 "encryption", of course.
- meeper16 10y agoIt's actually amazing how many soft devs have no clue about the impact of the Linux, the command line, which they now call the 'CLI', true editors and fast home grown IDEs. A shift needs to take place at the core of software development. Linux made everything possible.
- karmajunkie 10y agoAhh yeah, it was all Linux. The 40 years worth of computing history and foundational operating systems before Linus came on the scene had nothing to do with it.
- imglorp 10y agoSarcasm noted, but think back to 1991. We had a half dozen mostly incompatible desktop OS's and around a dozen Unix-like variants (mac, pc, amiga, cpm, etc), mostly with proprietary hardware (hpux, aix, sun, apollo, dg, dec, etc). The internet and decent interop protocols were just getting started. Remember DCE and RCP? Bleh). Linux now runs on almost _all_ of those with a mostly compatible API and ABI, from raspi to Z-mainframe, speaks to hundreds of weird hardwares, and hundreds more network protocols built in. I'd say it was instrumental.
- karmajunkie 10y agolets be clear, the impact of linux has been great, in many ways. I compiled my first linux kernel in 1994, and I don't think I'd be the developer I am today without having had access to and experience with Linux. But come on, the tenor and tone of the parent comment is incredibly myopic, ignoring decades of legacy that Linux imitated. Its also a bit much to attribute the trend of hardware compatibility and binary independence (which is quite a bit sketchier IMO) to Linux. This was a trend that has been ongoing for years, and would have without the introduction of linux. TBH we probably have Microsoft to thank for that more than anyone, by setting expectations across the consumer market that hardware be mostly-compatible with an OS.
- 10y ago
- thought_alarm 10y agoLook at this. Hacker News beats Slashdot to the punch with a Linux kernel update thread.
- sheraz 10y agoI get this reference.
- frozenport 10y agohttp://www.phoronix.com/scan.php?page=news_item&px=Linux-4.6-Kernel-Features http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.6... For a summary of new features.
- wyldfire 10y ago> This release adds Kernel Connection Multiplexor (KCM), a facility that provides a message based interface over TCP for accelerating application layer protocols. ... a common use case is to implement a framed application layer protocol running over TCP ... This was discussed on HN a while back. Gee, it's too bad that SCTP hasn't found more popularity. Reliable datagram-based (or stream-based) messaging, with support for binding to multiple endpoints. In any case, KCM sounds like it's worth exploring.
- signa11 10y ago> In any case, KCM sounds like it's worth exploring. here is the previous (spartan !) discussion: https://news.ycombinator.com/item?id=10310090 https://news.ycombinator.com/item?id=10310090
- IgorPartola 10y agoMy thought exactly. I have always wondered why SCTP was not on the same level as UDP and TCP. It's really too bad, since it would be perfect for lots of higher level protocols, especially ones that don't require streaming (SMTP for example). KCM seems really neat, though of course now we need a library that abstracts it away and has a fallback to regular TCP so that applications don't become Linux-only.
- saurabhjha 10y agoI heard that BSD is really good with network stuff with their kqueue. See for example this comparison http://www.eecs.berkeley.edu/~sangjin/2012/12/21/epoll-vs-kqueue.html http://www.eecs.berkeley.edu/~sangjin/2012/12/21/epoll-vs-kq... In particular, epoll cannot be used with disks. Is it still the case that BSD has an edge over Linux? Is KCM addressing the problem of handling a lot of hanging connections? Please point out if my assumptions are incorrect. I am new to kernel and network programming. Edit: By BSD I mean FreeBSD
- c2279659 10y agoThat's highly doubtful, the last BSD release was 21 years ago.
- neverminder 10y agoUSB 3.1 SuperSpeedPlus (10Gbps) support - this is by far the most important feature in my opinion, considering that USB Type-C (3.1) is projected to be the most abundant socket on the planet.
- cm3 10y agoI wish they would finally find a solution that actually fixes USB storage sync lockups. Whatever USB storage you use and whether USB2 or USB3, it's very easy to lock up a machine when data is flushed and is slow to do so. Given all the asynchronicity in the kernel, it's surprising there's such a Windows-like global wait-until-I'm-finished unresponsiveness bug.
- _wmd 10y agoI've never experienced the entire machine locking up before (going back 10+ years), only IO becoming severely locked up when writeback can't keep up with new IO, and always happened on non-USB media too.
- cm3 10y agoXorg becomes totally unresponsive and I cannot switch to a VT, so I assume it's a global lock somewhere.
- fit2rule 10y agowhile sleep 10 do ; cat /proc/meminfo | grep Dirty ; done Watch the dirty cache data when this is happening, if you want to know for sure. Put a couple "sync;sync;sync"'s &&'ed on that cat, if you want to watch stimulating behaviour.. (More often than not, its the device. Linux is dealing with it fine.)
- cm3 10y agoAs I wrote above, the device is taking long to finish the flush operation, and that's nothing special, but making the machine not react to input and actually block everything else like, say, the network stack and thereby interrupt downloads, is not what I perceive as fine.
- bryanmathew 10y agoAs a Hacking learner, Linux is really complex to hack. That's why i love Linus OS.
- known 10y agoI've downloaded and compiled it; It's working fine;
- woybi 10y agoShouldn't we say "GNU/Linux" instead of "Linux" alone?