I like this one, I'm sure there are people who try it from time to time... It's very tempting to say what syscall #2 is, but it would remove temptation :-)

OK, so you're precisely demonstrating that the laws protect the service providers and not the individuals.

If an online bank does not even require you to send officially stamped papers to prove your ID, then there's a real problem. Here it would not happen because such a bank would not be paid and would have no resort. That's why they're asking for a lot of papers.

It seems some poeple fear that it would slow the process down, but in fact it would not. How many times a week do you open a bank account ? This is typically the thing which can suffer several days latency for paper verification.

1) France is not a socialist country, re-read your books
2) In France, you actually have to pay for an ID card, so it's not everyone who pays for everyone. And even if it was, it would not really be a problem as every individual would be supposed to have one ID card. I just looked on mine and it had cost me about $20 20 years ago. That's reasonable.

If you can't get in person to the establishment you want to get in relation with, it's very common that this establishment sends you papers by snail mail, and require a lot of information in return, as well as some original papers which can only be delivered by a local office such as the town council. I can assure you that this is really not a problem. Many people here in France, Germany and I believe most of Europe have no problem subscribing to services, ordering hardware abroad, etc...

Also interestingly, all the persons I know who have got their bank account pumped without their consent had ordered things in the US. Here in the old europe, it's far less common due to the number of verifications at every stage in the process.

In fact, the buyer is protected, and the service provider has the responsibility for ensuring he will get paid. That's the reason why most companies require a lot of information to ensure you're a real person who will pay them.

The Geode may be the only x86 CPU capable of running without even a heatsink on both the CPU and the chipset. As far as I know, Atom requires a heatsink and a fan on the chipset, and the VIA nano requires a heatsink on both. The Geode is really fantastic in this regard. A typical Geode-based system has no problem being less than 1cm thick and weighing only a few tens of grams. That's important in many areas today.

It's amazing that you Americans have such problems with your identities. I think it is because you don't have an ID card. Here in France, there's no such problem. I can give my SSN to anyone, because it's not used as an authentication system, just identication for a few things. It's written in plain numbers on some non-confidential papers and it causes no problem.

The reason is that we all have an ID card which is delivered after several controls have been performed. So we all present our ID card to prove our identity when paying by cheque, when we want to take money out of the bank, etc...

I regularly read about Americans taking care of destroying any ID information they can have so that nobody can reuse it. This sounds so much prehistoric to us out there that almost nobody believes it ! And I think that you're now in a situation where it will be difficult to make people accept the concept of the ID card simply because they will fear that someone somewhere will then know their ID. It's a shame, really.

Now don't get me wrong. ID stealing also happens here but is very rare because they require that the imitator either has got your ID card and looks exactly like your photo, or that he owns a fake ID card, which happens but is very limited due to the various security items which are not trivial to reproduce for the average Joe around.

I really hope that in 10-20 years you'll have got out of this archaic system, it's really a shame !

Window scaling is disabled by default on windows, which limits TCP sessions to 64 kB, hence the per-session bandwidth on high-latency links such as DSL.

10-12 Mbps is typical of a DSL link with a 50 ms RTT (=ping time). 64 kB is 512 kbit. 512 kbit / 0.050 s = 10240 kbps = 10 Mbps.

I've already seen tuning guides on the net explaining how to enable window scaling on windows, though I'm not that much interested ;-)

Willy

In switched mode power supply units, you have a MOSFET on the input. Since a MOSFET has an on-resistance, the power losses across it follow I^2. Also, in an AC PSU, you lose 1.2V in the rectifier, which means 1.2*I W. For instance, in a 500W PSU running off 120V, you're getting about 4A, which means 5W lost in the rectifier (1%).

So by switching from 120 to 240V, you divide the rectifier losses by 2, and the MOSFET/wiring losses by 4. By going to 400V, you divide rectifier losses by 3.33 and MOSFET/wiring losses by 11. And by going to DC, you remove rectifier losses since you don't have a rectifier anymore.

So running off high-voltage DC really makes sense. You can save a few percent of efficiency, which is not bad considering how much a server consumes nowadays.

Atom is just plain x86 with HT. Nothing fancy, nothing new. Drivers for rare hardware might cause problems though, but that's true with any kernel. I would have worried if the guy wanted to switch to an exotic architecture but that's definitely not the case here.

Well, it's not wise to change both the hardware and the software at the same time. You think it will reduce your time to market but it might increase it instead due to the numerous changes that will have to happen in your toolchain before getting anything barely working again.

From what I understand, you have a big experience in 2.4 and Xscale. 2.4 Also works on x86, so you'll not have to re-learn everything from scratch by just changing the architecture. All your toolchains, boot scripts, packaging scripts, etc... will still work as they did before. Then, only once you get familiar with your new architecture and the minor changes you might observe in the boot sequence, build process etc... it will be the right time to evaluate a migration to 2.6. Once you put your finger there, you'll quickly discover that you need to upgrade your gcc, glibc, replace modutils with module-init-tools, experiment with hotplug and sysfs, maybe switch to udev, etc... Step by step you'll notice a big number of changes, but you will be able to proceed one at a time, which is not possible if you change the soft at the same time as the hardware.

Also there are other aspects to consider. 2.4 has been maintained for a very long time, and you're probably used to backport some mainline fixes to your own kernel from time to time. 2.6 is not maintained that long (avg 6 months), and changes so fast that you will not be able to backport fixes for many years. I'd strongly recommend to start with 2.6.27, because Adrian Bunk will maintain it for a long time, as he did with 2.6.16. Once 2.6.27 is not maintained anymore (in about 2 years) you'll have to decide whether you stick to 2.6.27 and try to backport fixes yourself or switch to 2.6.36 (just a guess).

Also, 2.4 accepts almost no new hardware nowadays. If your new platform works well, that's fine, but how can you be sure that next year your GigE NIC will not change to something not supported anymore ?

I would say that the only case where 2.4 would make sense for a long term starting from now is if you don't have the time to revalidate 2.6 or to wait for 2.6.27 to stabilize, and need to quickly release something which will sit at your customer's in a place where it cannot be upgraded. Something like "install and forget". But I don't feel like it's what you're looking for.

So, to summarize :
      1) switch your architecture
      2) switch your kernel

Whether an official release of your product exists between 1 and 2 is just a matter of your time constraints and customer demand.

Last, to show you you're not alone, I'm too considering switching our products to 2.6, but next release will still be 2.4. Too many changes for a short-term release, and 2.6.27 not ready yet to reach years of uptime (but it's getting better though). 2.6.25 was particularly good but not maintained anymore.

Hoping this helps,
Willy

Yes, 2.4.37 runs fine on an Asus EEE-Box (Atom, PCI-E, SATA, USB2, ...)

Willy

"Java is slow" is a stupid old myth. Does it not occur to you that JIT compilers compile to native code?

Ahah ? You should tell that to people who develop applications delivering only 1000 pages per second on a 8-core machine where equivalent plain-old C easily delivers more than 10000 pages per second on a single core of the same machine. Surely the GC is at fault, everything related to object management is at fault, the memory footprint voiding all cache efficiency is at fault, in summary, the language is at fault.

An yes, that's what I see in enterprises.

I think the real problem with Java developers is that they have been told that what they did was fast, and they believe it. But let's face it : when processing an HTTP request burns ONE JOULE there is definitely a problem. No wonder why datacenters are filling that fast...

Everytime a Java developer tried to prove me wrong, he showed me he was able to reach performance levels I was able to reach 10 years ago on an obsolete machine. "Look: 500 pages per second on this small 4-core xeon !". Well, I do 2000 on my 2.5W, battery-powered Geode computer, and that is small.

So please stop spreading bullshit about efficiency of such things, there are people who believe you and now we find their crap sucking all the power of datacenters.

The need for store-and-forward seems obvious to me due to the high latencies, and I thought it had always been working like this. Maybe it's hard to evolve in that area due to the long time needed to prepare each project and the risk of failure.