Linux 3.13 Released 141
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."
Re:configuration languages (Score:5, Insightful)
Re:configuration languages (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.
Re:configuration languages (Score:4, 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?
Re:configuration languages (Score:5, 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.
Re:configuration languages (Score:5, 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.
Re:configuration languages (Score:5, 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.