Slashdot Mirror
Linux 3.3 Released
diegocg writes "Linux 3.3 has been released. The changes include the merge of kernel code from the Android project. There is also support for a new architecture (TI C6X), much improved balancing and the ability to restripe between different RAID profiles in Btrfs, and several network improvements: a virtual switch implementation (Open vSwitch) designed for virtualization scenarios, a faster and more scalable alternative to the 'bonding' driver, a configurable limit to the transmission queue of the network devices to fight bufferbloat, a network priority control group and per-cgroup TCP buffer limits. There are also many small features and new drivers and fixes. Here's the full changelog."
Features not marked "experimental" in the kernel config database are out of beta.
Have you got your LWN subscription yet?
Only thing I know of is Ksplice which is a private company that offered special run-time kernel patches. Oracle bought them out and no longer releases the software and the patches for free.
I don't use linux, but I remember reading a while ago that linux introduced a feature to update the kernel w/o a reboot. Does this not apply?
It's not built-in for any major distros yet. It's called ksplice, which is owned by Oracle now. (It is GPLv2)
AFAIK it has not been mainstreamed.
Arch Linux will probably support it in a few days. The packages have been marked outdated and there is already a 3.3rc7-1 ( https://aur.archlinux.org/packages.php?ID=50893 )release in the wild that will probably be the basis for the updated to 3.3.
Ksplice is just a commercial tool that makes use of kexec which has been in the kennel for years. There is absolutely no need for Ksplice yo use kexec.
Also, it's quite surprising to me since as far as I know it's necessary to use TI's compiler to generate C6X code. I found one initiative to port GCC to it, but afaik it didn't get finished. My understanding is that it is no small job to get Linux to compile on non-supported compilers, so I'm interested in the toolchain they are using.
GCC 4.7 (which will be released soonish; it's basically already done) supports the C6X architecture.
From the GCC 4.7 release notes:
We live, as we dream -- alone....
It seems pretty clear stuff is not just being shoved in willy-nilly for android. There have been many debates about including this piece or that piece, and if the implementation should be identical to the android version. Many parts are not in yet, and some may not go in at all. The android suspending solution may not ever go in, mainline may eventually get a system that serves the same purpose in a different way, android may eventually support that. LWN and the LKML posts they link to give a pretty good overview short of reading all the code commits.
Climate Progress - Hell and High Water
There isn't an easy answer to your question. In general, bufferbloat is when you get latency or jitter issues because some network device upstream of you has a large buffer, which it fills before it starts dropping your packets. The dropped packets is how software relying on TCP is notified of network congestion so it knows to throttle back. Other protocols may be affected differently (you might notice VoIP delay or bad lag on your xbox).
To combat this, the idea is to limit your traffic in buffers you control which are (typically) smaller than your ISP and modem's buffers so the ISP ones stay empty and highly interactive. In general, this means limiting your data rates to lower than your bandwidth and prioritizing packets by interactivity requirements. The linux kernel additions in 3.3 allow you to set your buffer size smaller for the entire interface with the goal being to reduce the delay induced by the linux router/bridge. It also adds the ability to prioritize traffic and limit buffers by cgroup (which is like a process categorization or pool which has certain resource limits), but this isn't particularly helpful in your forwarding situation.
For my own QoS setup, I usually use a script similar to this HTB one. It requires some tuning and getting your queue priorities right requires some understanding of the traffic going through your network. A lot of high level netfilter tools (smoothwall, dd-wrt, etc) have easier to use tools QoS tools which may better suit your purposes. Having not used one, I'm not in a position to recommend them.
Not true. Kexec replaces the whole kernel, which means the system is reset. Ksplice applies and removes patches (security updates mainly) while the kernel is running, which means all the processes keep running as if nothing happened.
"When you have 8 servers each with 2 PCI-E Quad E1 Digium Cards, handling a total of 248 inbound calls on toll free numbers,"
This one is tricky if you're trunking with the local telco correctly. Your telco should offer a redunancy and rerouting service if you actually have 64 E1s with them.
"When you have analog CCTV cameras running into 4 servers each with 16 channels of video, well, how do you cluster that?"
That one's easy. Splitter before the capture card.
If you care about it, it's capable of being made redundant.
The idea I believe is more that userspace is responsible for handling which device(s) are used for transmission and notifying the kernel, rather than being responsible for the sending of packets themselves. If you've got an active/backup bonding setup, it makes sense to perform connectivity checks from userspace which can be flexible and complex, then notify the kernel to switch or remove devices that have lost connectivity.
The libteam daemon that's in development seems to have a round robin mode planned and I'd hope 802.3ad, but I guess we'll have to wait and see how that works. I'm sure it'll still need kernel support for the bonding implementations, it's just the monitoring and management functions that are being extracted.
That's rubbish. I have a triple monitor setup and KDE will happily let me make a panel 100% of any one screen, or 100% of all three (if you wanted to do that for some insane reason) at any orientation.
-- Lattyware (www.lattyware.co.uk)
The TI C6X line of chips are not only VLIW, they are "DSP" chips, optimized for signal processing operations. Also, this chip has no MMU. Nobody is going to build a tablet computer or any other general-purpose device based on one of these.
I think for the near term at least, anyone using a TI C6X will be using the TI C compiler. TI has a whole IDE, called Code Composer Studio.
But now we have the possibility of running Linux on the chip.
The one time I worked with a TI DSP chip, I didn't really have an operating system. Just a bootstrap loader, and then my code ran on the bare metal, along with some TI-supplied library code. Now I'm working with an Analog Devices DSP chip and it's the same situation. For my current purposes I'm not using any OS at all. But Linux support could potentially be great; for example, if you were using a platform with an Ethernet interface, you could use the Linux networking code; if you were using a platform with USB, you could use Linux USB code and file system code and so on.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Bullshit. Not only does a merge of Android kernel features not mean you can play angry birds under some regular Linux distro (you'll need, oh, Dalvik and Android's windowing system which is not X11), you can already play Angry Birds in Chrome, no Wine required. The kernel is entirely irrelevant. If you don't know what you're talking about, just shut up.
Okay, so what are the kernel changes that users need? Filesystem - we currently have a choice of ext2, ext3 and ext4 - what's inadequate about any of them that couldn't be resolved in an ext5? Any reason why re-strippable RAID can't be in that?
The general notion is that btrfs will "be" ext5 (i.e. it will be the next "updated" but still stable and mainstream FS), and that there will not be a filesystem with the actual name "ext5". For those who don't need btrfs features, ext4 will suffice. This is also the intent of Theodore Ts'o, the principal developer of ext3/4.
I believe the reason for this is that the innovation going on in filesystems is centered around some big rethinks, e.g. btrfs uses a copy-on-write B-tree (a concept introduced in 2007). It would be a pain in the neck (or impossible) to innovate like this and remain backwards compatible with ext2/3/4, thus btrfs is not called ext5.
One thing they could do as far as the Linux kernel goes is work on drivers - particularly Wi-Fi drivers, and do what's possible to ensure that 3.3, or 3.4 support just about every peripheral device there is out there. Aside from that, as far as I can tell, the Linux kernel is pretty much complete.
How about you RTFS? To quote:
There are also many small features and new drivers and fixes.
for i in `facebook friends "=bday" 2>/dev/null | cut -d " " -f 3-`; do facebook wallpost $i "Happy birthday!"; done
According to my university lessons, the kernel and the drivers are the operating system, and everything else is shell and applications.
MS Windows should thus be considered a distribution (combining OS, shell and applications and an install mechanism).