Linux 3.13 Released

← Back to Stories (view on slashdot.org)

Posted by timothy on Sunday January 19, 2014 @11:36PM from the lucky-numbers dept.

diegocg writes "Linux kernel 3.13 has been released. This release includes nftables (the successor of iptables); a revamp of the block layer designed for high-performance SSDs; a framework to cap power consumption in Intel RAPL devices; improved squashfs performance; AMD Radeon power management enabled by default and automatic AMD Radeon GPU switching; improved NUMA and hugepage performance; TCP Fast Open enabled by default; support for NFC payments; support for the High-Availability Seamless Redundancy protocol; new drivers; and many other small improvements. Here's the full list of changes."

28 of 141 comments (clear)

Min score:

Reason:

Sort:

nftables by Anonymous Coward · 2014-01-19 23:51 · Score: 2, Interesting

There's a compatibility wrapper, right? Right? Because nftables is an awful terrible complicated pile of needless complexity. It should be possible to set up a simple deny-inbound firewall ruleset in just a few lines, or..........I'm just not going to upgrade! Yeah. That's the idea.
1. Re:nftables by Anonymous Coward · 2014-01-20 00:13 · Score: 5, Informative
  Yes, there is.
  
  The nftables project provides a backward compatibility layer that allows you run iptables/ip6tables (using the same syntax) over the nftables infrastructure:
  ...
  iptables-nftables: the user-space utility that provides the xtables command line utility to add rule using {ip,ip6}tables syntax.
configuration languages by StripedCow · 2014-01-19 23:54 · Score: 3, Interesting

This release includes nftables (the successor of iptables)
Why does every network management tool include their own ugly, broken little programming language for configuring it?
Why not just use an existing language?
Like, when I get a packet from the network, I can just use Python:
if packet.origin == "127.0.0.1": packet.drop() elif packet.port == 80: packet.forward(port = 1024)
etcetera.

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.
1. Re:configuration languages by jones_supa · 2014-01-20 00:00 · Score: 5, Insightful
  
  Probably because of the extremely high performance requirements. There's a lot of packets going through a 10Gbit interface and if you run some Python code for each of them you're gonna choke the machine.
2. Re:configuration languages by SuricouRaven · 2014-01-20 00:00 · Score: 2
  
  Performance. On a firewall/filter for a major network there could be millions of packets per second. On a smaller scale routers running linux often use very low-power and thus low-performance hardware while still handling gigabit interfaces. No cycles to spare for running an interpreter or even parsing complex rules with variable-length fields.
3. Re:configuration languages by upuv · 2014-01-20 00:06 · Score: 5, Insightful
  
  The problem is overheads and security.
  Embedding a language at such a low level is very tricky. It has to be blinding fast and user very very little resources. python, perl, ruby are all great languages. but ill suited for the task of network management tasks. The RAM overheads are huge. This is why we are seeing a relatively constant evolution, change of embedded languages at these low levels. This is a game of resource management on the host system.
  Just imagine if this host was a web server. With thousands of socket requests per second. How would Python manage to keep up with that. Without crushing the system under load even before the traffic was passed off to a process like Ngynx to handle. Python would be a performance nightmare at this level.
  Another way to look at this is. What if you hammered the system with a DOS style attack. If each request had to go through a python execution stack you are basically making the system far more vulnerable to DOS than it ever was before.
  Now lets look at topics around these highly extensible languages. Here you have a system that in part is supposed to improve security. But by adding in a language like python you are adding in a very extensible lnaguage at a very low level. A kernel level to be precise. So higher than root. The security implications are enormous. You are basically exposing the kernel to a far higher risk. This would be a hackers dream come true.
  So there are reason for these language syntax choices. They must be managed very carefully.
4. Re:configuration languages by cupantae · 2014-01-20 00:09 · Score: 3, Insightful
  
  I think the real question (and possibly what StripedCow was asking) is why not use the syntax of existing languages, to make it easier to learn and read?
  
  --
  --
5. Re:configuration languages by StripedCow · 2014-01-20 00:11 · Score: 2
  
  Probably because of the extremely high performance requirements. There's a lot of packets going through a 10Gbit interface and if you run some Python code for each of them you're gonna choke the machine.
  That would be true if it were impossible to compile Python code to something efficient.
  And the style of code used above (and typical network configuration scripts) would compile to something very efficient. In fact, a compiler can compile that code to the current configuration language whenever possible.
  
  --
  If Pandora's box is destined to be opened, *I* want to be the one to open it.
6. Re:configuration languages by Nerdfest · 2014-01-20 00:18 · Score: 4, Insightful
  
  Which means that you could proibably come up with something to do this yourself. I'm sure quite a few people would be interested in it.
7. Re:configuration languages by Warbothong · 2014-01-20 00:26 · Score: 2
  
  Why does every network management tool include their own ugly, broken little programming language for configuring it?
  Why not just use an existing language?
  The better solution is to fix the DSL, rather than introducing a general-purpose language.
  Domain Specific Languages are really good at making code simpler, more concise and less redundant, but their most important feature is reducing bugs. A DSL can use primitives which have the possible error-modes built in; a general-purpose language would have to build that in a separate library layer, but the problems with that are 1) the general-purpose stuff is still available, which won't catch your errors 2) a decent abstraction layer *is* a DSL. In OO land, an object's interface is a DSL for controlling that object and a class library is a simulation of the components of some problem domain. In functional land it's usually even more explicit, with datatypes to represent programs, combinators for building them up and functions for interpreting them.
8. Re:configuration languages by arielCo · 2014-01-20 00:33 · Score: 4, Insightful
  
  It's faster than the scanned rule lists in iptables, and the remaining alternative is compiling to native code into a module every time you change a rule.
  I know that seeing "bloat" everywhere and griping is an honored /. tradition, but someone has to add a dash of reality.
  
  --
  This post contains no rudeness or derision of any kind. All arguments are friendly. Terms and exclusions may apply.
9. Re:configuration languages by drinkypoo · 2014-01-20 00:55 · Score: 2
  
  I think the real question (and possibly what StripedCow was asking) is why not use the syntax of existing languages, to make it easier to learn and read?
  Because it would do neither. It would turn one-liners into many-liners, which would add complexity that would only ultimately be confusing.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
10. Re:configuration languages by RabidReindeer · 2014-01-20 01:05 · Score: 3, Interesting
  
  Probably because of the extremely high performance requirements. There's a lot of packets going through a 10Gbit interface and if you run some Python code for each of them you're gonna choke the machine.
  That would be true if it were impossible to compile Python code to something efficient.
  And the style of code used above (and typical network configuration scripts) would compile to something very efficient. In fact, a compiler can compile that code to the current configuration language whenever possible.
  Systems like IPTABLES are based on declarative syntax. When you "program" by declaration, you are working with a limited syntax to perform limited functions. That also limits your flexibility, but the tradeoff is that the functions that you can do are so well-defined that you can be assured that anything you compile will operate in a way that minimizes surprises. It also means that you can optimize things more precisely because you don't have to support many possibilities, only a few. The #1 feature of declarative programming is that you don't have lots of loops and decisions to debug. Or optimize.
  The "tables" part of IPTABLES also contributes to that functionality. There are a limited set of table types pre-defined with specific uses. By compiling the rules into tables, very efficient processing can be done. After all, optimized table handling is one of the oldest and most intensively-studied disciplines of Computer Science.
  Even IPTABLES wasn't totally restricted to table-driven functions, though. As an extendable architecture, if you really wanted to, you could define your own abilities to the system, including modules incorporating user-written code. It's just that they had pre-defined and fine-tuned the most commonly-used features.
11. Re:configuration languages by Burz · 2014-01-20 02:10 · Score: 2
  
  Common syntax that results in different behaviour? That sounds more confusing to me.
12. Re:configuration languages by Nerdfest · 2014-01-20 02:26 · Score: 2
  
  More lines does not neccessarily mean more complexity.
13. Re:configuration languages by drinkypoo · 2014-01-20 02:58 · Score: 2
  
  More lines does not neccessarily mean more complexity.
  And breaking the output up into more lines and adding a bunch of characters and bullshit around it doesn't make it more understandable. If you're having problems understanding the rules, use a tool that makes the job simpler, like fwbuilder.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
14. Re:configuration languages by Bengie · 2014-01-20 03:00 · Score: 4, Insightful
  
  Common syntax that results in different behaviour? That sounds more confusing to me.
  Exactly. It seems like the only people who want firewall syntax in the form of a popular scripting language are people who should not be touching firewall rules in the first place.
15. Re:configuration languages by Nerdfest · 2014-01-20 03:47 · Score: 2
  
  It most definitely can make it more readable in many cases. Have you ever tried to debug Perl written by an 'expert'. The rules are all there, but the meaning is quite obsfuscated. Breaking it up and adding characters helps a lot. I'm not saying it would definitely herlp here as I don't know the new syntax, but it's quite conceivable.
16. Re:configuration languages by Zero__Kelvin · 2014-01-20 04:59 · Score: 2
  
  "That would be true if it were impossible to compile Python code to something efficient."
  You can't compile without a compiler. Your now amended proposal is to create or fork a non-standards compliant Python compiler (You don't realize that that is your proposal, because you think "Gosh ... they already gots 'em", but read the last couple of lines at the end to see how to determine why you once again don't understand).
  
  I'm going to go out on a limb and say that you have little or no experience designing real software. Nobody is bundling a Python interpreter into the kernel or adding a complete Python compiler to the source codebase because you don't understand why you need to learn new things rather than expecting real developers to do things in a phenomenally stupid and/or inefficient manner.
  
  Now, stop. If you are thinking anything but: "Yes, I can now see that I don't really understand software and I should learn from people wherever I can" then stop and think again. Write down the question or claim you were about to make and then Google it. You already know the answer to anything you write will be some variation of "... because you don't understand how any of this works or the numerous implications all your ideas have". Figure out why that is for each of your questions yourself and you will both gain a lot of knowledge and considerably reduce the number of times you post proof of your lack of understanding of the subject. For starters, figure out why "Gosh they already gots 'em" isn't the right thought to have when hearing that they would need to create or fork a compiler.)
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Python *IS POSSIBLE* in theory by DrYak · 2014-01-20 00:25 · Score: 2

Why does every network management tool include their own ugly, broken little programming language for configuring it?
Why not just use an existing language?
Like, when I get a packet from the network, I can just use Python:
You could use Python:
You need to write your own interpreter which takes scripts written in your special subset of python, and compile them into the special bytecode that the NFTable kernel interface uses.
The thing is, the internal representation of NFTables needs to be highly efficient (as explained by other posts here) and very likely the official NFTable bytecode isn't really feature complete or maybe not even turing-complete.
The current special language will map nicely to it. But you will probably need a very narrow and specific subset of Python. Or a vast a mount of pre-processing and optimisations. You probably will never be able to use the full extent of python on current ntfables and for exemple "import" nice modules in your network filtering code.

--
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Support for NFC payments ? In the kernel ?? by vikingpower · 2014-01-20 00:34 · Score: 5, Interesting

I am a bit astounded. Why would you want to compile that into an OS kernel ?? Please enlighten me.

--
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
1. Re:Support for NFC payments ? In the kernel ?? by Anonymous Coward · 2014-01-20 00:56 · Score: 5, Informative
  
  Well, if you care to stop throwing peanuts from the gallery long enough to read about it, the patch adds driver support for interacting with a "secure element" embedded environment on the NFC hardware, from userspace, via a Netlink API. It's bascially passthrough from user space to the hardware.
2. Re:Support for NFC payments ? In the kernel ?? by Zocalo · 2014-01-20 01:09 · Score: 2
  
  I'm guessing NFC is not too dissimilar to a network interface, so why wouldn't it be in the kernel? I would assume that it compiles to a module by default, but could also be compiled directly into a stripped down kernel for a dedicated use installation, so it's not likely to be using resources unless needed.
  
  --
  UNIX? They're not even circumcised! Savages!
3. Re:Support for NFC payments ? In the kernel ?? by FalcDot · 2014-01-20 02:15 · Score: 5, Informative
  
  From TFA:
  "This release implements support for the Secure Element. A netlink API is available to enable, disable and discover NFC attached (embedded or UICC ones) secure elements. With some userspace help, this allows to support NFC payments, used to implement financial transactions. Only the pn544 driver currently supports this API."
  In other words, the kernel now contains the necessary API so the PC can correctly talk to a NFC Secure Element which is needed to be able to make payments over NFC, in tandem with userspace tools.
  So yeah, the label is a bit misleading...
nftables on LWN by smittyoneeach · 2014-01-20 00:51 · Score: 5, Informative

http://lwn.net/Articles/564095/
Absolute best technical read on the Internet. Subscribe early, subscribe often.

--
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
misnomer perhaps? by rewindustry · 2014-01-20 00:51 · Score: 3, Informative

nfc is a comms protocol, like bluetooth or ethernet, very timing sensitive, therefore best implemented on the kernel level. nfc is often used for payment systems, hen ce the conflation. am assuming - have no specific details.
Just my luck... by Anonymous Coward · 2014-01-20 00:55 · Score: 2, Interesting

I FINNALY managed to wrap my head around how iptables work... Oh well, hopefully the new one will be easier.
Dynamic Packet Filter by KonoWatakushi · 2014-01-20 03:07 · Score: 2

One of the comments points to DPF, which uses dynamic code generation to demultiplex packets. This is a very promising and surprisingly old idea. A dynamically generated classifier/filter could replace the entire network input path, and interface well with Van Jacobson's net channels. In addition to providing superior performance, it would afford far greater flexibility and modularity of code.