Linux 3.7 released
kernelnewbies.org
kernelnewbies.org
> X86 before (linux 3.6-rc4):
> # time rm -f test1
> real 0m2.710s
> user 0m0.000s
> sys 0m1.530s
> X86 after:
> # time rm -f test1
> real 0m0.644s
> user 0m0.003s
> sys 0m0.060s
The commit affects 5 lines only.
EDIT. Not sure if this optimization applies to filesystems mounted with standard journaling options...
I dug up the commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git... which seems to be a bit older than I would have expected. Of course, this being Linux, "old" means it's from September 19th.
Con: All my files are gone before I can frantically ctrl-c to save some of them.
Interesting... anyone know more about this?
[1] http://en.wikipedia.org/wiki/Slow-start [2] http://blog.benstrong.com/2010/11/google-and-microsoft-cheat...
I guess CentOS will get this in 2020, sigh, still waiting for initrwnd 10 support.
In fact, many of the security considerations are the same.
Except it's no longer SYN flooding at that point, it's full HTTP request flooding.
But in a sense isn't that really the goal of this design? To make it a bit more efficient to get requests to the application layer?
In any case, it seems like an application using this feature to have an efficient way of disabling it if it can't handle the current load. Kernels could add efficient heuristics to throttle it automatically too.
I'm more concerned that a bug in the entropy of the key generation process could turn these servers into massive reflected DoS amplifiers. E.g., the attacker sends 1 packet with the source address spoofed and the webserver replies with an entire HTTP result to the victim.
The particularly unfortunate part is, as much of the world's commercial hosting runs on RHEL, it's the world that doesn't get this until 2020. Well, except for services that roll custom kernels.
Every so often I am tempted to fiddle with debian, looks like more and more people are thinking that way:
http://w3techs.com/blog/entry/debian_is_now_the_most_popular...
In comparison, I think "sarge" was the stable Debian in 2005. "sarge" is no longer oldstable- nor is etch. oldstable is "lenny", released in 2009.
Don't get me wrong, I like Debian, but when you compare "ease of upgrading", don't forget to consider "need to upgrade"!
I'm more devops than sysadmin, so more expertise may have changed my experience, but when I did run a CentOS server, I thought, "yay, this is great"... until it came time to actually update.
Then, I realized that I had simply been accumulating up all of my upgrade pain as debt - with compound interest.
By comparison, upgrading Debian servers from version to version felt like hopping from bed to bed in a mattress store. Aside from a missed footing or two, it was usually a nice soft landing.
But everytime I want to do something slightly interesting on our linux boxes, I'm thwarted by everything being so damn out of date on RHEL.
I can't run Sublime Text2, which irritates me, but worse I was wanting to use node-webkit for an experimental project and I can't even run that.
This is a huge downside for me. I worked for a remove server management company, and every time I had to work on a new (to us) RHEL4 or RHEL5 server (or CentOS equivalent), it was like pulling teeth. In order to run half the software our clients needed, I had to compile newer versions of daemons, create our own RPM packages, patch and recompile code. RHEL5 didn't even include memcached for crying out loud!
For 'enterprise deployments' I can understand wanting to go with RHEL if you don't know much about server administration and want to make it 'easier' on yourself, but even for basic web apps, most of the software you'll want to use is absent, out-of-date, or incompatible. I can't imagine anyone working for a startup wanting to use it.
Another good reason to stick with RHEL is that they do a very good job of maintaining compatibility between minor releases. You're pretty much guaranteed to be able to install a third-party package across all minor releases. If it installed on 6.0, odds are it will install and work on 6.4 without issue. Others make no such guarantees.
RHEL has way, way better (and accurate) documentation than any other distro I've used, particularly when it comes to unattended installations and server configuration tuning. Other distributions tend to focus much more on desktop users than massive server installations and their particular needs.
It's a common complaint among people that RHEL is always too far behind the curve in terms of software packages. But really, your OS will be stale the day after you install it, much like a car loses so much of its value the day you drive off the lot. Freshness is a tempting siren, but can lead you onto the rocks.
If you're a sane implementor, you're going to stick with any distribution you choose over the course of several years. You will favor uniformity over freshness, and stability over constant (and arguably needless) work. And no matter what distribution you choose, you are very likely to roll your own packages of whatever software is critical to your business, as you'll need custom patches and so forth.
If you care about taking advantage of prompt security updates from your distro provider, you will do this as little as you possibly can. Otherwise you need to pick up that burden yourself, and since most of us aren't security pros, it is a weight that should be assumed with great reluctance. You're no doubt familiar with the dilemma: Are you going to attempt to maintain stability (which isn't at all guaranteed) by backporting patches, or annoying your ops people by forcing version upgrades?
To a certain extent, how bad this gets is a function of how out-of-date your distro is. This is where having packages that are 4 years old can bite you -- you end up rolling your own far more often than you really should. Overuse of tools like virtualenv leads to the same problem.
If you're betting your business on this software and are operating at scale significantly larger than the typical Web service, odds are you're not going to live on the distro-provided packages for very long.
6.3 still does not support initrwnd which needs a minimum kernel of 2.6.38
It's API/ABI stability, and it's meant to be a feature of RHEL.
perf trace will show the events associated with the
target, initially syscalls, but other system events like
pagefaults, task lifetime events, scheduling events, etc.
"ptrace" is the main userspace debugging API, used behind tools like "strace" or "gdb", but it's old and clumsy. Quite new "perf" tool, on the other hand, allows user to get various CPU/Kernel stats mostly useful for profiling. Before "perf" you could only try to emulate your program using "valgrind" to get, say cache misses.
The command "perf trace", seems to move "perf" more into the "ptrace" domain. This is indeed exciting.
While both are a can of worms, (1) is more so. With regards to (2), AFAIK it is generally accepted that grsec provides the easiest profiling tools here; whilst 'roll your own' is never as secure as something locked down by multiple third parties 'in the know' and to a finite extent (see: NSA SELinux), it is far better than nothing, and very frequently custom code or the latest or patched version of a certain daemon will not have publicly accredited rulesets. Therefore grsec's solution is a reasonable basis for beginning here. Docs @ http://en.wikibooks.org/wiki/Grsecurity/The_Administration_U...
Ubuntu 12.04 uses version 3.2, 12.10 is on kernel 3.5.
Android, on the other hand, will take much longer. It's sad as there are so many goodies in this for ARM, especially the multi-platform support. This will make updating Android version a lot easier (for manufacturers, hackers). Right now the one of the bigger issues is updating the kernels (and the closed drivers, to be honest).
I suppose the next Android version will use this kernel.
Cached version: http://webcache.googleusercontent.com/search?q=cache:vjkg-vG...
When i think of ARM i think of Mobile Phones, total ram isn't an issue(yet?) Are there other advantages?
http://www.anandtech.com/show/6418/amd-will-build-64bit-arm-...
Don't forget AMD's announcement about ARM64 based servers.
Maybe, but my desktop has 32GB of ram, has a 64bit CPU, and I've rarely seen a single process use 4GB of memory unless it was leaking memory. My laptop has 8GB of ram, also 64bit, and I'm pretty sure I've never had a single process use 4GB. The only exception I can think of was doing some silly data manipulation, e.g. doing the initial build of a property graph of the entire Boston area transit system. I bet some high end games or video/photo editing software would use more than 4GB. Point is, those are all pretty niche situations, I'd bet the majority of memory usage on an average person's computer comes from browser processes, few hundred MB each if that and office applications, also a few hundred MB. Those processes add up though, so having more ram is usually a really good thing even if no processes uses even close to 4GB.
I also challenge the need in server loads. I'd bet the vast majority of applications never use 4GB either on the app server or the database server. Most of what gets discussed here on HN are large high scalability applications that you wouldn't host on ARM cores anyway. We often forget that the vast majority of website are tiny and low traffic.
Database servers in particular wants as much memory as possible, and it doesn't take that big of a business support application that have a working set of data > 4Gb.
Same goes for a lot of the memory hungry Java application servers that sits around in a lot of businesses.
What I am saying is that for ever such application there are probably more than a thousand sites hosted on free with your domain or $5 a month php + mysql hosting that use no where near 4GB per process. For the companies hosting those sites a cortex a-15 with a ton of ram is an awesome solution. This isn't all or nothing, we're talking about two different markets.
> I didn't explicitly call that out, but as soon as you have more than 4GB of memory, there's going to be an application that wants to use more than 4GB. So yes, 64-bit is necessary in my opinion. Especially when you consider the server market.
I'm just saying I don't agree. There is a massive market very open to the power saving offered by arm that have no use for > 4GB process spaces. That doesn't mean there aren't markets where 64bit will be useful.
There are many games now with multi-gigabyte files; the ability to map that entire file into memory is invaluable if the system has enough memory to support it.
There's also a difference between "required" and "desirable". Many applications will happily run with less than 4GB of memory available to them, but many will also run much better when they can access more.
Don't fall into the same trap that so many did with 32-bit processes, etc. Look forward a few years and see where the industry is eventually headed anyway and just assume that it should be there now.
We don't think about it much, but the total power draw of a data center is a huge cost, and ARM servers are lower-power than x86 servers. Every step towards being able to replace x86 servers with ARM ones is saving the people who pay data center power bills lots of money.
Moterola Droid 256MB [2009]
Google Nexus One 512MB [2010]
Galaxy Nexus 1GB [2011]
Google Nexus 4 2GB [2012]
Beyond that…
The ARM 64 bit comes with 31 64 bit registers instead of 14 32 bit registers.
There are a number of instruction set differences, such that you run the same object code on previous architectures.
The NEON unit also gets twice the registers, double precision floating point, and IEEE 754 compliance.
http://www.theregister.co.uk/2011/11/01/hp_redstone_calxeda_...
http://www.hp.com/hpinfo/globalcitizenship/environment/techg...
Also think Moore's Law. Current phones are sporting 1GB of RAM. It will just be a few years before they exceed 4GB, and it's easier to get the software support ready now.
http://www.phonearena.com/news/Sonys-2013-flagships-tipped-Q...
Think of it as if the Twitter Api was the kernel and all different clients like Twiterrific or Tweebot were the distributions (Ubuntu, Fedora, etc...). Distributions are implementations of the kernel with lots of extra features and improvements.
This announcement is for the Linux kernel. The different Linux distributions (Ubuntu, Redhat, etc.) all bundle different versions of the Linux kernel and umpteen number of packages around that to create a cohesive Desktop or Server experience.
The kernel is the one core, similar piece between ALL of the distros. It is the desktops, package managers, etc. that differs between the distros.
The Linux kernel is important, but only a small part of a whole operating system - it's the lowest layer, but there are lots of layers on top of it, including all the programs that the average user uses.
Ubuntu, Red Hat, and other Linux _distributions_ bundle a Linux kernel, common software packages, and utilities to manage these together. So there are many Linux distributions, but only one Linux kernel.
Ubuntu/Fedora/Arch/etc = Linux + lots of other stuff, without which the kernel is pretty useless (command shell/interpreter, GUI, command line tools, etc.)
Some more explanations that may help:
http://stackoverflow.com/questions/2013937/what-is-an-os-ker...
> Furthermore, the server should periodically change the encryption key used to generate the TFO cookies, so as to prevent attackers harvesting many cookies over time to use in a coordinated attack against the server.
What is going to do this? I hope this is built-in somehow.
EDIT: Looks like the key is chosen at kernel module "late init" time. I think this is before any init scripts have had the opportunity to add back any entropy persisted from previous boots. So the entropy in the kernel pool is minimal. It may be plausible for a remote attacker to guess the key for a bunch of servers.
Also, if the key is not rotated by cron, it provides a single-packet method for a remote attacker to observe that a server has been rebooted since he last checked. This will give a good indication of how often security patches have been applied.
http://git.kernel.org/linus/1046716368979dee857a2b8a91c4a883... http://git.kernel.org/linus/168a8f58059a22feb9e9a2dcc1b8053d... http://git.kernel.org/linus/8336886f786fdacbc19b719c1f7ea91e...
For an attacker to learn a cookie that's valid for a given victim "source IP", he only needs to be passive observer somewhere along the route. Even if we believe that's very hard in most cases, if it's possible at all, he has the mother-of-all anonymous reflected DoS amplifiers. http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02#secti...
So, yeah, using a key that's rotated after a short amount of time -or- number of uses (whichever comes first) seems like a good idea.
An attacker who doesn't want to do a MITM attack because that might be noticed can set up sessions to all kinds of servers outside the NAT which support TFO. Then all these TFO cookies are used in spoofed SYN packets with the source IP being set to the host behind the NAT that the attacker wants to flood. Easy enough.
Of course, some will argue that if the attacker is inside your NAT, you're already pwned.
I don't think that's a very good principle for the security design of internet protocols.