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."

141 comments

Min score:

Reason:

Sort:

Re: by Anonymous Coward · 2014-01-19 23:38 · Score: 0

awesome! Im looking forward to use nftables!
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.
2. Re:nftables by Anonymous Coward · 2014-01-20 02:51 · Score: 0
  
  But don't pin your hopes on it. It's neither new, shiny or exciting to work on, so will probably be low quality and maintained only for a short amount of time if history is anything to go by.
3. Re:nftables by unixisc · 2014-01-20 03:42 · Score: 1
  
  So how does nftables distinguish b/w IPv4 and IPv6?
4. Re:nftables by epyT-R · 2014-01-20 10:32 · Score: 1
  
  Yes, obsolete software is eventually abandoned. If you don't like it, use a long term support kernel.
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 Anonymous Coward · 2014-01-20 00:04 · Score: 0
  
  Why not just use an existing language?
  I suspect that one reason would be performance. A generic bytecode parser must be able to handle a lot of cases that aren't relevant for network traffic. For a regular desktop that might not be an issue because the amount of cycles wasted on network traffic is insignificant compared to everything else that is going on.
  For a dedicated router or firewall on the other hand python might not be suitable. There is also the issue of memory usage.
  Kernel updates have to work for all use cases, not just yours.
4. Re:configuration languages by Anonymous Coward · 2014-01-20 00:05 · Score: 0
  
  Do you really want programs written in C/C++ to embed python?
5. 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.
6. Re:configuration languages by RotateLeftByte · 2014-01-20 00:06 · Score: 0
  
  Because once a Python wraps its body around you, you are done for.
  
  --
  I'd rather be riding my '63 Triumph T120.
7. Re:configuration languages by allcoolnameswheretak · 2014-01-20 00:06 · Score: 1, Funny
  
  Maybe it's because Python is so flexible, simple and straightforward that it can be easily used for everything.
8. Re:configuration languages by Anonymous Coward · 2014-01-20 00:08 · Score: 1
  
  No cycles to spare for running an interpreter
  
  " nftables kernel engine adds a simple virtual machine into the Linux kernel, which is able to execute bytecode to inspect a network packet "
  Wait, what, you didn't want an interpreter in your kernel?! TOO LATE.
9. 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?
  
  --
  --
10. 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.
11. Re:configuration languages by Anonymous Coward · 2014-01-20 00:15 · Score: 0
  
  Did you say bytecode parser?
  
  Pseudo-state machine in kernel-space: the userspace utility nftables interprets the rule-set provided by the user (using a new syntax), it compiles it into the pseudo-state machine bytecode and then it transfers it to the kernel via the nftables Netlink's API.
12. 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.
13. 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.
14. Re:configuration languages by Anonymous Coward · 2014-01-20 00:29 · Score: 0
  
  No, he said "generic bytecode parser", which is an entirely different animal than what you described.
15. Re:configuration languages by gbjbaanb · 2014-01-20 00:32 · Score: 0
  
  phew. thank goodness we only have a VM interpreter instead!
  
  "nftables kernel engine adds a simple virtual machine into the Linux kernel, which is able to execute bytecode to inspect a network packet "
  I assume its using Java bytecode?
16. 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.
17. Re:configuration languages by Anonymous Coward · 2014-01-20 00:35 · Score: 0
  
  And is a nightmare for things which have to be maintained and evolve over long tomescales (decade+). Cleaning up old Python code is much harder than basically any compiled language.
18. Re:configuration languages by Anonymous Coward · 2014-01-20 00:37 · Score: 0
  
  There is no C++ code in Linux kernel.
19. Re:configuration languages by Ash+Vince · 2014-01-20 00:43 · Score: 1
  
  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.
  The only way this could work and maintain the performance needed would be if you could write a parser that took your python code (that needed some sort of python parser to run) and converted it into a set of native nftables rules or bytecode that was efficient enough to be run at the kernel level as everyone else has described. This might actually be worth someone doing though.
  I haven't played around with nftables yet but I am very familiar with ip tables (and chains) so I will just take a set of iptables rules I am familiar with and throw them through the compatibility layer to see what I end up with so your python idea is not really any use to me learning my way around nftables. It might be more useful to people just trying to get their head around kernel routing initially though so maybe it is a project worth someone starting.
  
  --
  I dont read /. to RTFA, I read /. to offend people in ignorance.
20. Re:configuration languages by Anonymous Coward · 2014-01-20 00:44 · Score: 0
  
  So if you compile python code that (maybe unintentionally) does an expensive calculation for each packet, you want that to be performed in kernel space for every packet? Or do you propose to do static analysis of the program you write to ensure that something like this doesn't happen? Also, how to handle floating point calculations? Eternal loops? Etc...
  I think the "broken little programming language" is purposely designed to perform its task very well.
  Of course, nothing is stopping you from doing what you propose. I like the idea but I see problems with it.
21. Re:configuration languages by Anonymous Coward · 2014-01-20 00:49 · Score: 0
  
  The ''bytecode'' is a DFA where transition are packet matching rules and end state commands on the packets, that is the fastest way to implements a configurable ruleset ...
22. Re:configuration languages by Anonymous Coward · 2014-01-20 00:53 · Score: 0
  
  Well why don't you write a compiler that "compiles" Python to the nftable format ;)
  And while we're at it, why use Python? Why not Perl, Java, PHP, JavaScript, C or just about any other language? Because which ever you'll select for your project.... People will still complain!
23. 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.'"
24. 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.
25. Re:configuration languages by RabidReindeer · 2014-01-20 01:07 · Score: 1
  
  No cycles to spare for running an interpreter
  " nftables kernel engine adds a simple virtual machine into the Linux kernel, which is able to execute bytecode to inspect a network packet "
  Wait, what, you didn't want an interpreter in your kernel?! TOO LATE.
  There's likely more than one already.
  Some interpreters can be extremely efficient. The threaded-code interpreter used by the original FORTH language, for example.
26. Re:configuration languages by BlackHawk-666 · 2014-01-20 01:08 · Score: 1
  
  Because a general purpose language is a bit like using a sledgehammer to open a walnut. You can do it, but there's better options.
  Python / Javascript / LUA and other script languages don't have the performance needed and are needlessly more complicated than requirements.
  The developers can create their own mini language which is fit for purpose and can be expressed in 10s - 100s of lines of EBNF. That can be fed into standard tools and a bunch of c++ code pops out the other end which can be used to compile or interpret as required.
  Custom mini-languages are smaller, faster, simple to learn and fit for purpose. Can you imagine the world if Cisco used C# and .Net on all their equipment...
  
  --
  All those moments will be lost in time, like tears in rain.
27. Re:configuration languages by Anonymous Coward · 2014-01-20 01:09 · Score: 0
  
  I don't think anyone's suggesting allowing a complete implementation of (ruby|perl|python) in the kernel, just using a common syntax for the packet mangling rules. Sort of a (very limited, non-extensible) subset of python (or some other widely used language) so that people can use their fluency in $LANGUAGE to write packet mangling rules.
  I thought it would be a good idea at first, but I've unconvinced myself. The problem with a syntax that was very similar to python (even a strict subset) is that it wouldn't actually be python. There would be differences. People who could program in python would find themselves frustrated, and for people who can't well there's no benefit anyway. It's probably easier to expect people either to learn the bespoke packet rule language or use a GUI or other utility that will generate the rules for them. Mind you, given that all packet mangling engines basically need to do the same things it would be nice if a standardised syntax could be used across different implementations.
28. Re:configuration languages by Anonymous Coward · 2014-01-20 01:24 · Score: 0
  
  I'm with you.
  Question: can I choose not to use nftables and implement my firewall as a kernel module instead? At least then I would know what's going on.
29. Re:configuration languages by smash · 2014-01-20 01:33 · Score: 1
  
  Because doing JIT compilation of the configuration file when loaded would be too fucking difficult? Config file format and internal memory structure doesn't/shouldn't have anything to do with each other.
  
  --
  I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
30. Re:configuration languages by Shimbo · 2014-01-20 01:40 · Score: 1
  
  There's likely more than one already.
  bpf has used one for twenty years or so; not sure when that got merged in the Linux kernel.
31. 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.
32. Re:configuration languages by Nerdfest · 2014-01-20 02:26 · Score: 2
  
  More lines does not neccessarily mean more complexity.
33. Re: configuration languages by Anonymous Coward · 2014-01-20 02:27 · Score: 0
  
  I'm just a noob, but couldn't you just use Python syntax, and write a simple interpreter that meets the efficiency demands?
  Or you could write a utility that compiles Python code into notables code?
34. Re:configuration languages by shrewdsheep · 2014-01-20 02:27 · Score: 1
  
  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.
  This does not seem to be an argument. Any language (maybe with some restriction) could be compiled to the appropriate byte code/assembly.
35. Re: configuration languages by Anonymous Coward · 2014-01-20 02:28 · Score: 0
  
  Yeah, but you could just use the Python language, and not the full interpreter with all the bells and whistles.
36. Re:configuration languages by jones_supa · 2014-01-20 02:35 · Score: 1
  
  Not necessarily. As another comment above pointed, if you want to interpret Python-like code, you will end up with a Python-like interpreter, with similar performance challenges like the original Python interpreter, just due to the semantics of the language. Of course, for sole networking purposes we could probably simplify things so that we can end up with fast machine language code. Another question is whether network administrators really want to compile their rules every time they change them.
37. Re:configuration languages by jones_supa · 2014-01-20 02:40 · Score: 1
  
  On the same note, let me add that I would love to see a real Python compiler for ordinary applications too. People have been saying that it's impossible to make a real compiler for the language due to some specific dynamic constructs it has. So you can make an .EXE of your app but you end up wrapping the interpreter there inside. A version of the language without these dynamic constructs, let's call it NativePython, with real compiler, would be quite interesting.
38. 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.'"
39. 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.
40. Re:configuration languages by twocows · 2014-01-20 03:06 · Score: 1
  
  Why? I'm honestly interested here, not disputing or anything.
41. Re:configuration languages by Anonymous Coward · 2014-01-20 03:18 · Score: 0
  
  psssst.... fwbuilder.org makes life much easier. remember to check those configs into version control.
42. Re:configuration languages by MikeBabcock · 2014-01-20 03:22 · Score: 1
  
  Because compiler compilers exist and you could roll your own compiler that turns Pythonesque commands into proper nftables rules if you really wished to.
  
  --
  - Michael T. Babcock (Yes, I blog)
43. Re:configuration languages by Chemisor · 2014-01-20 03:34 · Score: 1
  
  Because python is twice the size of the entire kernel and all its modules. In the kernel efficiency matters.
44. Re:configuration languages by unixisc · 2014-01-20 03:46 · Score: 1
  
  How does Python recognize the differences in example b/w IPv4 and IPv6? Like in your example, will
  if packet.origin == "[::1]"
  be automatically recognized as IPv6, or will it choke seeing it?
45. 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.
46. Re:configuration languages by Megol · 2014-01-20 04:08 · Score: 1
  
  Compiling to native code needn't be expensive nor complex. I guess an interpreter better fits the Unix model though, analogous with the preference of semi-readable text to binary formats+editor for configuration files.
  But to continue the basic argument: having support for native code generation could speed up many other operating system tasks that either use other interpreters (there are more of that than one could think) or cases where specialized code could be faster. Doing an infrastructure for something like this is a one time task (*number of processor platforms) but doing it right could be hard.
47. Re:configuration languages by Anonymous Coward · 2014-01-20 04:13 · Score: 0
  
  He is referring to the changes that happen from 2.4->2.5->2.6->2.7->3.x
  There have been a few changes where the code looks the same but the behavior of the libraries changes radically. In some cases opposite of what they were in the previous version. In some cases whole 'baked in' libraries disappear but reappear with a different name and slightly different logic.
  The language itself has changed little (except for 2.7->3.x). But the libraries have.
  For a prototyping language it is seriously cool. Long term work is creaky.
48. Re:configuration languages by Zero__Kelvin · 2014-01-20 04:44 · Score: 1
  
  Your problem is that you think you are using 4 lines of code when in fact you are using thousands. In order to run Python you need a Python Interpreter. That means adding a HUGE amount of code which is not even fine tuned for the task. In other words, you wouldn't do that because you don't want a Python interpreter in kernel space for about 20 different excellent reasons including ridiculously high overhead and storage requirments.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
49. 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
50. Re:configuration languages by Barsteward · 2014-01-20 05:15 · Score: 1
  
  don't forget COBOL
  
  --
  "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
51. Re:configuration languages by jafac · 2014-01-20 06:50 · Score: 1
  
  Every hipster except the Ruby on Rails hipsters. And the Java hipsters.
  
  --
  
  These are my friends, See how they glisten. See this one shine, how he smiles in the light.
52. Re:configuration languages by Anonymous Coward · 2014-01-20 07:01 · Score: 1
  
  No, it's a different bytecode. Very simple with a register based VM. http://www.tcpdump.org/papers/bpf-usenix93.pdf
53. Re: configuration languages by Anonymous Coward · 2014-01-20 07:42 · Score: 0
  
  You ask a very valid question, whose answer will become immediately obvious to everyone but you, once your shit code is accidently put on anything but your x-box you fucking newb.
54. Re:configuration languages by twocows · 2014-01-20 08:39 · Score: 1
  
  Ah, thanks. I think I have heard about that a bit. It seems like Python would benefit from at least maintaining consistent behavior within a major version, but I'm sure there are other considerations I'm not aware of.
55. Re:configuration languages by StripedCow · 2014-01-20 08:53 · Score: 1
  
  Embedding a language at such a low level is very tricky.
  Nobody said kernel development would be easy :)
  
  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.
  You could run it all inside a sandbox, I suppose.
  
  --
  If Pandora's box is destined to be opened, *I* want to be the one to open it.
56. Re:configuration languages by drinkypoo · 2014-01-20 09:03 · Score: 1
  
  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.
  That's not the case in firewall rules, where the rules are strict. The problem with perl is that the rules are loose, which is good for bashing out some code but bad for readability. We don't have that problem here. With firewall rules, the only problem is in understanding them. With perl, you also have the problem of distinguishing code from random keyboard-smashing or typos.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
57. Re:configuration languages by epyT-R · 2014-01-20 10:34 · Score: 1
  
  You would need to port the python interpreter to whatever VM instruction set is used. Good luck with that.
58. Re:configuration languages by Anonymous Coward · 2014-01-20 10:39 · Score: 0
  
  It is impossible.. I have yet to see a high performing python script.
59. Re:configuration languages by snizzitch · 2014-01-20 11:53 · Score: 1
  
  You should use Javascript.
60. Re:configuration languages by Mohan+S · 2014-01-20 17:29 · Score: 1
  
  For iptables, there is a preprocessor called Shorewall writen by Tom Eastap. Wonderful thing that is maintained pretty well. Such preprocessors makes life easy. This discussion for easier syntax via intepreters is like the classic debate between high level GUI and commandline. Learning commandline lets one appreciate the innards enough to us the utility well enough while GUI would present most common options.
61. Re:configuration languages by upuv · 2014-01-20 23:31 · Score: 1
  
  Good one. That's funny.
62. Re:configuration languages by upuv · 2014-01-20 23:36 · Score: 1
  
  A firewall in a sandbox?
  Do you see the issue here?
  Sandboxes are good for consuming applications. The firewall is not a consumer. It's a part of the command and control chain. It's a the heart of the system. Sandboxing the kernel is self defeating. As it's the kernel and everything spawns from it. So you can't really protect your child processes if your kernel is compromised.
63. Re:configuration languages by StripedCow · 2014-01-20 23:44 · Score: 1
  
  My idea was that the firewall merely invokes the sandbox. It is not running inside the sandbox...
  
  --
  If Pandora's box is destined to be opened, *I* want to be the one to open it.
64. Re:configuration languages by Anonymous Coward · 2014-01-21 02:07 · Score: 0
  
  Python is suitable for people who can not learn any real language?-)
65. Re:configuration languages by crutchy · 2014-01-21 23:25 · Score: 1
  
  whether network administrators really want to compile their rules every time they change them
  not really necessary since usually you have to perform some kind of action to implement changes (such as executing a bash script) it would make sense to recompile the rule script when performing a flush command (such as equivalent of iptables -F) or restarting the firewall (akin to apache2ctl restart)
  compiling would seem like a sensible idea even for the existing simplified syntax, since interpreting any script is much slower than executing compiled machine code
66. Re:configuration languages by Anonymous Coward · 2014-01-21 23:28 · Score: 0
  
  so in other words if you use python you die
67. Re: configuration languages by crutchy · 2014-01-21 23:32 · Score: 1
  
  couldn't you just use Python syntax, and write a simple interpreter that meets the efficiency demands?
  you certainly could
68. Re:configuration languages by jones_supa · 2014-01-22 06:41 · Score: 1
  
  compiling would seem like a sensible idea even for the existing simplified syntax, since interpreting any script is much slower than executing compiled machine code
  I'm quite sure the rules in the current system are stored in binary values in the kernel rather than in the script format which loads them.
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 ]
Because you would need to embed an interpreter by Anonymous Coward · 2014-01-20 00:27 · Score: 1

If you support all the syntax of the language (so python in this case) people are going to expect to be able to interpret/run arbitrary python statements:
if packet.port in [80,443,8080]:
packet.forward(port = 1024)
Without the same semantics looking the same isn't going to be enough. It is also true that the language syntax can let you arrange for certain conditions to always hold which allows simpler backend rules to be generated (e.g. in the original example the first comparison was against an IP address and the second was against a port which might make generating skip lists where later rules do not have to be evaluated harder).
Does this mean the PMD for my Vaio Z2 will work? by Eunuchswear · 2014-01-20 00:32 · Score: 1

Automatic GPU switching
Linux 3.12 added infrastructure support for automatic GPU switching in laptops with dual GPUs. This release adds support for this feature in AMD Radeon hardware.
(It already "works" but plug/unplug needs a lot of manual fucking around.
Or does it need more work in X?

--
Watch this Heartland Institute video
Re: by Anonymous Coward · 2014-01-20 00:32 · Score: 1

To someone that has not used Linux for a while, is this just a new version of iptables or is this actually comparable with pf?
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 Anonymous Coward · 2014-01-20 01:04 · Score: 1
  
  From the newbies article:
  https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5ce3f32b5264b337bfd13a780452a17705307725
  
  NFC: netlink: SE API implementation
  Implementation of the NFC_CMD_SE_IO command for sending ISO7816 APDUs to NFC embedded secure elements. The reply is forwarded to user space through NFC_CMD_SE_IO as well.
  Userland needs an API to talk to crypto chips
3. Re:Support for NFC payments ? In the kernel ?? by ketomax · 2014-01-20 01:05 · Score: 1
  
  Hah, still behind windows! For years, I have been using NFC to deploy my frontpage based website through FTP.
4. 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!
5. Re:Support for NFC payments ? In the kernel ?? by vikingpower · 2014-01-20 02:03 · Score: 1
  
  Clear enough. Thanks for the answer !
  
  --
  Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
6. Re:Support for NFC payments ? In the kernel ?? by Anonymous Coward · 2014-01-20 02:08 · Score: 1, Funny
  
  the kernel is adopting a pay-by-nfc development model in which linus will sell the kernel kernel from a street corner stand somewhere using NFC as payment. these funds will be used to further the development of linux.
  in addition to receiving the linux kernel on a floppy disk (in order to remain competitive with bsd), you also get obscenities hurled at you when you question the form of payment or why you receive a floppy disk.
  luckily the obscenities come at no extra charge.
7. 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...
8. Re:Support for NFC payments ? In the kernel ?? by Anonymous Coward · 2014-01-20 02:38 · Score: 0
  
  Right, and you're the same person who would criticise something like MiFare for insesucre embedded crypto. Without an embedded crypto implementation, anyone (including the NSA, boo hiss) with an antenna can pick up your NFC's private key in plaintext transit to the reader (on the way to the kernel) and clone your card.
9. Re:Support for NFC payments ? In the kernel ?? by Anonymous Coward · 2014-01-20 02:49 · Score: 0
  
  In the major of the cases, this is a matter of security. You get used to it by reading more carefully anything open source, basically.
  That's why I use my own kernel and my own set of commands.I take "personal" from PC, very personal. :)
10. Re:Support for NFC payments ? In the kernel ?? by lord_rob+the+only+on · 2014-01-20 03:21 · Score: 1
  
  Why are good trolls like this one kept modded -1 ?
11. Re:Support for NFC payments ? In the kernel ?? by Zero__Kelvin · 2014-01-20 05:08 · Score: 0
  
  " Most have zero tolerance for any humor that pokes fun of GNU/Linux or FOSS in general."
  Where the hell did you get that idea? I laugh my ass off at losers like you every time you make inept attempts at poking fun of Linux and OSS. I suppose the problem is that you can't seem to figure out that you are the joke. We are all laughing, we are just not laughing at what you say, but at the actual joke, to wit, you!
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
1. Re:Just my luck... by Anonymous Coward · 2014-01-20 01:07 · Score: 0
  
  Nope.
2. Re:Just my luck... by smash · 2014-01-20 01:35 · Score: 1, Troll
  
  #justusepfinstead
  Seriously.
  
  --
  I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
3. Re:Just my luck... by upuv · 2014-01-20 01:37 · Score: 1
  
  I'm with you on that one. I have to re-teach myself iptables each time I have to setup a configuration.
4. Re:Just my luck... by diegocg · 2014-01-20 01:57 · Score: 1
  
  Fortunately the syntax for the new nft utility seems to be easier to understand http://kernelnewbies.org/nftables_examples
5. Re:Just my luck... by Anonymous Coward · 2014-01-20 05:07 · Score: 0
  
  #justusepfinstead
  Seriously.
  srsly!
6. Re:Just my luck... by Anonymous Coward · 2014-01-20 05:42 · Score: 0
  
  I FINNALY managed to wrap my head around ipchains.... Oh well
7. Re:Just my luck... by phoenix_rizzen · 2014-01-20 06:19 · Score: 1
  
  Fortunately the syntax for the new nft utility seems to be easier to understand...
  Compared to what? Learning Japanese using Russian textbooks?
  You want easy-to-understand, look at IPFW or PF. Those read like actual English sentences, not gibberish like iptables/nftables.
  About the only good thing nftables does is enforce the ordering of rules elements so that everyone's rules will be written the same; and finally get rid --of --that --annoying --CLI --syntax --that --iptables --uses.
  Here's hoping the devs actually document things correctly and accurately, though. Considering their track record, though ...
8. Re:Just my luck... by Anonymous Coward · 2014-01-20 09:46 · Score: 0
  
  I FINALLY managed to wrap my head around ipfwadm... oh well.
9. Re:Just my luck... by Anonymous Coward · 2014-01-21 12:34 · Score: 0
  
  # iptables -A INPUT -p slashdot --slashdot-uid 256998 -j REJECT
  I pity da fool!
I hope this fixes my black screen on boot by hubie · 2014-01-20 02:21 · Score: 1

I have one computer where it will not boot into graphics mode ever since the 3.10 kernel. When it switches over you just get a black screen; however, the machine still boots because I can ssh into it. A couple of other machines I upgraded don't have this problem. While looking for an answer, I've found this seems to be an issue across many distributions (Ubuntu variants, Fedora variants). Some people said they solved it by adding some kernel boot parameters, some say it is related to the Intel graphics driver, some say other drivers (none of the suggestions I've found, so far, have worked for me). Fortunately this isn't a critical resource computer and I fine with running it on the 3.2 kernel.
1. Re:I hope this fixes my black screen on boot by Anonymous Coward · 2014-01-20 05:07 · Score: 0
  
  laptop with nvidia card?
2. Re:I hope this fixes my black screen on boot by hubie · 2014-01-20 06:23 · Score: 1
  
  No, fanless PC with Intel Atom, I think N2800 processor and whatever graphics it has.
3. Re:I hope this fixes my black screen on boot by AJodock · 2014-01-20 10:53 · Score: 1
  
  While that is an Intel CPU, it isn't using an Intel GPU. Instead it uses a PowerVR which is a brand of GPU often used in ARM devices, embedded, etc.
  Long story short, there are no open source drivers in the kernel for that GPU. That means that you will have to find the PowerVR toolchain and compile your own drivers, but if it is anything like the rest of the ARM GPUs it won't work on a current kernel without a ton of patches. If you are lucky someone will have released an distro designed for your hardware otherwise it isn't hardly worth the time.
  From here https://wiki.archlinux.org/index.php/Intel_GMA3600 it sounds like their driver only supports kernel version 3.1, but there is a github repo with some patches that supposedly help only tested up to 3.7 though). However it looks like it requires xorg 1.11 so you may have to downgrade that as well.
4. Re:I hope this fixes my black screen on boot by hubie · 2014-01-20 16:43 · Score: 1
  
  Thank you very much. This is a great help to me. Worst case I'll just ssh in and do what I need to do.
5. Re:I hope this fixes my black screen on boot by sylvandb · 2014-01-21 08:51 · Score: 1
  
  On your fanless PC, if you have a keyboard you can probably to bring up a text console. Might be easier than coming via ssh from another system, and works even without a live network. Sometimes also and etc. Note that distro's can and some do disable that text console in favor of X, but most will leave at least one console on F1.
  You could also disable X from auto-starting.
Thanks, but no thanks. by Anonymous Coward · 2014-01-20 02:35 · Score: 0, Offtopic

With the revolutionary Windows 9 just around the corner, why should I care with a minor point release? In a niche operating system?
Syntax like iproute2 by Anonymous Coward · 2014-01-20 03:05 · Score: 0

I read began reading Why You Will Love nftables and reached the part where the syntax is shown. It's so very similar to iproute2. If you like iproute2, you'll love nftables too. If you hate iproute2, you'll probably hate nftables as well. But you should really try to love it, because it's really powerful. Drop the other network tools that can be replaced by iproute2 (e.g. ifconfig, route).
I'll go change my underware, 'cause I just came...
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.
no thanks by badzilla · 2014-01-20 04:17 · Score: 1

Where security is concerned I don't want New And Shiny, I want Old And Tested. I'll stick with iptables.

--
"Don't belong. Never join. Think for yourself. Peace." V.Stone, Microsoft Corporation
1. Re:no thanks by Anonymous Coward · 2014-01-20 10:26 · Score: 0
  
  ...which will steadily become Old And Unpatched. Nice.
2. Re:no thanks by Anonymous Coward · 2014-01-20 13:42 · Score: 0
  
  Considering the nftables work goes back to 2009 (though it did languish from 2010 to 2012), it's not really all that new; one of the prime drivers for nftables was to move the code that was currently duplicated in iptables for ipv4, ipv6, arp, and ethernet to a single shared implementation.
  "Replacing the current, well-tuned firewalling code with a dumb virtual machine may seem like a step backward. As it happens, there are signs that the virtual machine may be faster than the code it replaces, but there are a number of other advantages independent of performance. At the top of the list is removing all of the protocol awareness from the decision engine, allowing a single implementation to serve everywhere a packet inspection engine is required. The protocol awareness and associated intelligence can, instead, be pushed out to user space." http://lwn.net/Articles/564095/
Re:C++ Linux Kernel by Anonymous Coward · 2014-01-20 04:38 · Score: 0

NOT YET...!
Re:C++ Linux Kernel by Barsteward · 2014-01-20 05:14 · Score: 1

when is Linux++ due then?

--
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Re:C++ Linux Kernel by Anonymous Coward · 2014-01-20 07:18 · Score: 0

Pretty much never. The thing that kills it is that there is no standard C++ ABI . You have a better chance of sneaking D in.
http://iainbuclaw.wordpress.com/2010/05/22/writing-a-linux-kernel-module-in-d/
ZRAM? by Anonymous Coward · 2014-01-20 07:45 · Score: 0

Does the scalable block layer let you switch over to one ZRAM device, instead of one per core recomended to avoid IO queue bottlenecks?
Re:Nice kernel by Anonymous Coward · 2014-01-20 10:31 · Score: 0

like that's limited to linux.. have you seen what microsoft and apple have been up to lately?
Fast open to save mankind from DNS DDOS invasion by Anonymous Coward · 2014-01-20 11:31 · Score: 0

Now all we gots todo patch resolver libraries... /w MSG_FASTOPEN and disable or severely rate limit the disaster which is DNS/UDP.
Re:C++ Linux Kernel by Anonymous Coward · 2014-01-21 02:02 · Score: 0

Since when the kernel side has cared about ABI? Even the source compatibility can and will be broken any time inside the kernel, which is easily seen by people using closed source drivers for their GPU's.
Re:C++ Linux Kernel by Barsteward · 2014-01-21 02:24 · Score: 1

errr... whooosh

--
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Re:Does this mean the PMD for my Vaio Z2 will work by Eunuchswear · 2014-01-25 00:52 · Score: 1

http://xpressrazor.wordpress.com/2013/10/08/enable-and-use-open-source-radeon-drivers-in-a-muxless-hybrid-graphics-intelamd-setup/
$ xrandr --listproviders Providers: number : 2 Provider 0: id: 0x7d cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 4 associated providers: 0 name:Intel Provider 1: id: 0x57 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 6 outputs: 2 associated providers: 0 name:radeon
Then
$ xrandr --setprovideroffloadsink 0x57 0x7d
Now setting DRI_PRIME to 1 runs things on the radeon:
$ DRI_PRIME=1 glxinfo | grep render direct rendering: Yes OpenGL renderer string: Gallium 0.4 on AMD TURKS

--
Watch this Heartland Institute video