Not to mention the time it takes to "negociate" the link probably when you plug it and leaves you with the feeling that nothing works. I don't count the number of times I've seen people press every button on the laptop to see if it would change anything on the black display.
BTW at home I'm still running on the VGA connector at 1600x1200 on an excellent, very clear display. The secret is to use those 13W3 connector cables from Sun immediately connected after a converter plugged into the DB15. No echo, no color issues, runs fine at 90Hz (250 MHz). They contain 3 independently shielded coax cables for the colors. Yes that's the same number of pixels as full HD, at 90Hz. Unless I'm mistaken, we're not far from the original HDMI limit ?
In fact my own usage in my projects as well as at my company has justified to take it over till last summer. And since Moritz and Ben from the debian LTS team have done an incredible job at feeding me with security backports for free, when Ben told me that debian 6 would be maintained till february, I found it the least I could do to pursue its maintenance for a few extra months to return the favor. So the fact that it's been used by debian has indeed justified 6 more months, which is nice already.
Acute observers will also note that in parallel Greg has also pushed 3.10 EOL quite far. It's just an indication that LTS is more of a team than isolated individuals the kernel.org table seems to imply. People talk out of public lists. Some devote more time, some less, but everybody helps all other ones as time permits. This is a fun adventure that will go on after 2.6.32:-)
Oh BTW, 3.2 is quite close to 2.6.32, it should be an excellent, riskless replacement. Over the last year I've pulled fixes exclusively from it.
I suspect MS has tried to push WinCE on Tomtom to replace Linux, and threatened them to sue them if they refused. These days, we see windows coming on devices where we would not expect it, and it is possible that there is some back pressure from MS.
This thing usually happens when two switches are attached with 2 (or more) trunked links ("etherchannel" in cisco terminology), and one of the switches has the trunk disabled on one of the ports (or someone moved the cable to another port during a diag). Thus the attachment becomes a loop. STP could take care of this, but it's common to disable it on access switches.
In fact, USB has several issues : it is 5V while almost nothing works with 5V right now, which implies a conversion everywhere. But if we want to put converters everywhere, 5V is very low to start with, it'd be better to start with 18-19V like most notebook adapters. Also, the USB plug delivers low power which is often not enough to power a hard disk, reason why most USB/ATA adapters ship with a second wire to double the power input. Another problem with such a low voltage is that you cannot have a common rail between all plugs, because if one eats slightly too much, all others will fall below 4.5V or even 4V and will be under-spec.
Last and not least, USB is a terrible plug. You always have to try it both ways, you can't visually know if you have to plug it upwards or backwards. And even when you're in the correct direction, you have to approoach very precisely for it to plug correctly. How many of us really look at the plug when trying to insert it ?
I really think that the EIAJ connector has more future. Fit it with 13-20V and make the spec so that it should never go below 13V even when highly loaded. That way, you can design miniature power converters which will be able to provide 12V without much hassle (even 1 single component for the cheap ones). With that as a standard, you could see plugs everywhere including in airplanes, providing unregulated voltage which will fit every usage up to about 65W per plug. And that plug does not need to be looked at in order to insert it. We could even imagine a smaller version for small devices, similar to the common mini-jack found at the other end of USB plugs to bring more power to 2,5" USB/ATA adapters. This would be nice for ipods, mobile phones, etc...
The other advantage is that many equipments nowadays are already compatible with that voltage (eg: notebooks) and will not even require any additional converter.
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.
France being a socialist country, French people have to pay way more in taxes than Americans do so the government can afford to do that for their citizens.
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;-)
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.
"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.
I simply cut some pipe insulation foam in halves, and rolled both parts around the disk, one near the front side, one near the rear side. I used some electric wire around the foam to hold it in place. Now my 3"5 disk fits perfectly in a 5"25 slot in front of the case's fan, and the foam's thickness prevents it from moving. I can't hear it *at all* now, eventhough it's a SCSI 15k rpm, because the noise from the motor normally conducts through the metal and the fixations only.
It requires very little material, skills and time to do this, and the disk can be extracted at any moment without hassle.
Probably that RoHS kills hardware, but what kills hardware the most is bad design. It is impossible to find a video card which doesn't head in text mode these days. Any crappy card for a server will now still have a big burning heatsink. That's really unacceptable. I want to be able to use text mode on servers and high-res 2D on a workstation without any fan nor big heatsink.
CPU makers have understood this new trend, but GPU makers have not yet because their whole market is targetted at gamers. It's amusing to think that the PC which was initially designed to achieve some work is only seen as a gaming console these days...
Maybe they finally got tired of being wrong. This is surprisingly clueful behaviour, and should be encouraged.
They're not wrong, they have a well-established business model which works. They can't change it quickly. Don't forget that most of their customers are satisfied by this model.
But they know they can enhance their products by using existing good quality products. When those products are closed, they simply buy them, and the products lives under their name. When the products are opensource, they can't buy them so at most they can try to appear friendly to them. You have to be aware that it's not in their interest to simply steal products which are moving quickly if they can't maintain them. They'd get a dead obsolete fork their customers wouldn't want to use.
So relying on live projects is a good compromise, provided the license is compatible with their model (BSD and LGPLG are, GPL is not). Their best alternative is then to fund such projects to ensure they evolve faster, and if possible towards their needs.
I would not be surprized that they embrace more BSD and LGPL projects in the future. It's easy to use libraries under such licences, and it ensures better interoperability with other projects, without having to release their whole software under the same license. Maybe they will even slowly start to officially give back, as LGPL is not suited for secret local changes, and it's not their business to maintain opensource packages.
For such usages, LGPL is good IMHO, it guarantees that if you don't publish sources, you redistribute verbatim. So the end user knows what he uses, the distributor does not get tainted and the project still gets fixes back. It combines advantages of BSD and GPL without their downsides.
Sad; that the current crop of 10G over copper adapters do not approach 5 gig throughput; raw. Wrong, current NICs are quite able to saturate the wire, even more (I got Ingo's TuX to push 20 Gbps of data through two Myricom NICs, and HAProxy to forward 10 Gbps between two NICs). The problem is the chipset on your motherboard. I had to try a lot of motherboards to find a decent chipset which was able to saturate 10 Gbps. Right now, my best results are with intel's X38 (one NIC supports 10 Gbps in both directions, ie 20 Gbps), and two NICs can saturate the wire on output. The next good one is AMD's 790FX which can saturate 10 Gbps in either direction, but not both (limited to about 14 Gbps).
Never forget that 10 Gbps translates into 1.25 GB/s the bus to the RAM in very small parts, and that's very hard to sustain. I can assure you that my motherboard heats up when it gets 800000 packets/s at 10 Gbps:-)
If you're looking for a decent motherboard to support large network bandwidth, throw to the bin all the ones with integrated VGA, and buy one that supports 4*PCIe 8x or 3*PCIe 16x to get some margin (you only need 1*8x in both directions, but marketting it stronger than technical skills at motherboard makers).
10 gig CX4 - which uses the same copper cables as Infiniband You can't use the same cables. The terminators are in the cable plugs in Infiniband, and on the NIC on 10GE.
But I agree with your point, 15m is enough for most situations. It also has the extreme advantage of being affordable, as opposite to the fiber, where a 10 Gig XFP transceiver alone costs almost as much as a 10 Gig CX4 NIC.
The concept is even older than that. I did something like this on my 8088 about 18 years ago, and since I was a kid, I think that many other people might have done this earlier.
It was pretty simple under DOS because you could easily read one char at a time and check the elapsed time between each.
It worked very well for words that I was used to type a lot (eg: password). You don't imagine how accurate you are when you type common words. Far more reliable than voice recognition IMHO.
However, one poster reported a risk of not being able to log in after a broken finger. Maybe a complex passphrase should be used as an alternative for such situations.
If you pass the patch through the same QA that initially let the bug exist, the added value is minor. In this case, you should be able to release an emergency workaround or patch within a few days, which at least will stop the exploit, even if it may open a new breach (which is not known yet), and then work on a better patch that you will validate correctly and ship later. Leaving a customer vulnerable for 5 weeks may be totally unacceptable depending on their business.
For instance, imagine if your application manages credit card numbers. You cannot leave a trivial SQL code injection bug exploitable for weeks! At the very least, you must block it within hours.
Slashdot Mirror
Not to mention the time it takes to "negociate" the link probably when you plug it and leaves you with the feeling that nothing works. I don't count the number of times I've seen people press every button on the laptop to see if it would change anything on the black display.
BTW at home I'm still running on the VGA connector at 1600x1200 on an excellent, very clear display. The secret is to use those 13W3 connector cables from Sun immediately connected after a converter plugged into the DB15. No echo, no color issues, runs fine at 90Hz (250 MHz). They contain 3 independently shielded coax cables for the colors. Yes that's the same number of pixels as full HD, at 90Hz. Unless I'm mistaken, we're not far from the original HDMI limit ?
In fact my own usage in my projects as well as at my company has justified to take it over till last summer. And since Moritz and Ben from the debian LTS team have done an incredible job at feeding me with security backports for free, when Ben told me that debian 6 would be maintained till february, I found it the least I could do to pursue its maintenance for a few extra months to return the favor. So the fact that it's been used by debian has indeed justified 6 more months, which is nice already.
Acute observers will also note that in parallel Greg has also pushed 3.10 EOL quite far. It's just an indication that LTS is more of a team than isolated individuals the kernel.org table seems to imply. People talk out of public lists. Some devote more time, some less, but everybody helps all other ones as time permits. This is a fun adventure that will go on after 2.6.32 :-)
Oh BTW, 3.2 is quite close to 2.6.32, it should be an excellent, riskless replacement. Over the last year I've pulled fixes exclusively from it.
I suspect MS has tried to push WinCE on Tomtom to replace Linux, and threatened them to sue them if they refused. These days, we see windows coming on devices where we would not expect it, and it is possible that there is some back pressure from MS.
This thing usually happens when two switches are attached with 2 (or more) trunked links ("etherchannel" in cisco terminology), and one of the switches has the trunk disabled on one of the ports (or someone moved the cable to another port during a diag). Thus the attachment becomes a loop. STP could take care of this, but it's common to disable it on access switches.
In fact, USB has several issues : it is 5V while almost nothing works with 5V right now, which implies a conversion everywhere. But if we want to put converters everywhere, 5V is very low to start with, it'd be better to start with 18-19V like most notebook adapters. Also, the USB plug delivers low power which is often not enough to power a hard disk, reason why most USB/ATA adapters ship with a second wire to double the power input. Another problem with such a low voltage is that you cannot have a common rail between all plugs, because if one eats slightly too much, all others will fall below 4.5V or even 4V and will be under-spec.
Last and not least, USB is a terrible plug. You always have to try it both ways, you can't visually know if you have to plug it upwards or backwards. And even when you're in the correct direction, you have to approoach very precisely for it to plug correctly. How many of us really look at the plug when trying to insert it ?
I really think that the EIAJ connector has more future. Fit it with 13-20V and make the spec so that it should never go below 13V even when highly loaded. That way, you can design miniature power converters which will be able to provide 12V without much hassle (even 1 single component for the cheap ones). With that as a standard, you could see plugs everywhere including in airplanes, providing unregulated voltage which will fit every usage up to about 65W per plug. And that plug does not need to be looked at in order to insert it. We could even imagine a smaller version for small devices, similar to the common mini-jack found at the other end of USB plugs to bring more power to 2,5" USB/ATA adapters. This would be nice for ipods, mobile phones, etc...
The other advantage is that many equipments nowadays are already compatible with that voltage (eg: notebooks) and will not even require any additional converter.
echo -e 'global _start \n _start: \n mov eax, 2 \n int 80h \n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
France being a socialist country, French people have to pay way more in taxes than Americans do so the government can afford to do that for their citizens.
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.
I simply cut some pipe insulation foam in halves, and rolled both parts around the disk, one near the front side, one near the rear side. I used some electric wire around the foam to hold it in place. Now my 3"5 disk fits perfectly in a 5"25 slot in front of the case's fan, and the foam's thickness prevents it from moving. I can't hear it *at all* now, eventhough it's a SCSI 15k rpm, because the noise from the motor normally conducts through the metal and the fixations only.
It requires very little material, skills and time to do this, and the disk can be
extracted at any moment without hassle.
Probably that RoHS kills hardware, but what kills hardware the most is bad
design. It is impossible to find a video card which doesn't head in text mode
these days. Any crappy card for a server will now still have a big burning
heatsink. That's really unacceptable. I want to be able to use text mode on
servers and high-res 2D on a workstation without any fan nor big heatsink.
CPU makers have understood this new trend, but GPU makers have not yet
because their whole market is targetted at gamers. It's amusing to think
that the PC which was initially designed to achieve some work is only seen
as a gaming console these days...
Maybe they finally got tired of being wrong. This is surprisingly clueful behaviour, and should be encouraged.
They're not wrong, they have a well-established business model which works. They can't change it quickly. Don't forget that most of their customers are satisfied by this model.
But they know they can enhance their products by using existing good quality products. When those products are closed, they simply buy them, and the products lives under their name. When the products are opensource, they can't buy them so at most they can try to appear friendly to them. You have to be aware that it's not in their interest to simply steal products which are moving quickly if they can't maintain them. They'd get a dead obsolete fork their customers wouldn't want to use.
So relying on live projects is a good compromise, provided the license is compatible with their model (BSD and LGPLG are, GPL is not). Their best alternative is then to fund such projects to ensure they evolve faster, and if possible towards their needs.
I would not be surprized that they embrace more BSD and LGPL projects in the future. It's easy to use libraries under such licences, and it ensures better interoperability with other projects, without having to release their whole software under the same license. Maybe they will even slowly start to officially give back, as LGPL is not suited for secret local changes, and it's not their business to maintain opensource packages.
For such usages, LGPL is good IMHO, it guarantees that if you don't publish sources, you redistribute verbatim. So the end user knows what he uses, the distributor does not get tainted and the project still gets fixes back. It combines advantages of BSD and GPL without their downsides.
Never forget that 10 Gbps translates into 1.25 GB/s the bus to the RAM in very small parts, and that's very hard to sustain. I can assure you that my motherboard heats up when it gets 800000 packets/s at 10 Gbps
If you're looking for a decent motherboard to support large network bandwidth, throw to the bin all the ones with integrated VGA, and buy one that supports 4*PCIe 8x or 3*PCIe 16x to get some margin (you only need 1*8x in both directions, but marketting it stronger than technical skills at motherboard makers).
Willy
and on the NIC on 10GE.
But I agree with your point, 15m is enough for most situations. It also has the
extreme advantage of being affordable, as opposite to the fiber, where a 10 Gig
XFP transceiver alone costs almost as much as a 10 Gig CX4 NIC.
And damn that's fast !
Willy
The concept is even older than that. I did something like this on my 8088 about
18 years ago, and since I was a kid, I think that many other people might have
done this earlier.
It was pretty simple under DOS because you could easily read one char at a time and
check the elapsed time between each.
It worked very well for words that I was used to type a lot (eg: password). You
don't imagine how accurate you are when you type common words. Far more reliable
than voice recognition IMHO.
However, one poster reported a risk of not being able to log in after a broken
finger. Maybe a complex passphrase should be used as an alternative for such
situations.
Willy
If you pass the patch through the same QA that initially let the bug exist, the added value is minor. In this case, you should be able to release an emergency workaround or patch within a few days, which at least will stop the exploit, even if it may open a new breach (which is not known yet), and then work on a better patch that you will validate correctly and ship later. Leaving a customer vulnerable for 5 weeks may be totally unacceptable depending on their business.
For instance, imagine if your application manages credit card numbers. You cannot leave a trivial SQL code injection bug exploitable for weeks! At the very least, you must block it within hours.