Go look at the literature. Pauling showed that the mechanism virii use to transport glucose also transport C and that very high doses of C (100G/d IV) kill virii and do not harm the patient.

This represented a significant threat to big pharma who then spent the rest of his life "discrediting" him by doing stupid shit like giving *oral* doses of C, finding it didn't work they calling him a quack.

You'll notice, if you look hard enough they were able to reverse polio in the 50s with this technique that supposedly works on *any* virus.

Don't even mention quackwatch.com - it's funded by big pharma.

Pauling is the only guy that ever got two nobel prizes in two different areas unshared.

Don't believe me, go look at what he did and the troubles he had and follow the money.

I agree with you. C gives a lot of insight under the hood. You can also start looking at an executables' structure, explain about memory usage and zones, and learn from your mistakes. gdb makes it easy to debug (no, printf is not a debugger).

And hey!, you really can't call yourself a programmer if you never hit your keyboard on receiving a SIGSEGV =D

Yep and they are using btrfs for the underlying filesystem which is also not at the production use stage.

For me this is quite a co-incidence, I just spent all yesterday reading up on fault taulerant distributed file systems and ceph and seemed quite promising until I realised they are also waiting on kernel 2.6.34 as it has their patches merged.

For anyone who knows more about this stuff, I was quite interested in xtreemfs as it seems to allow you to add nodes anywhere on the internet and it will deal with the fault tolerance/striping. For my purposes I don't care about having massive throughput but unfortunately xtreemfs doesn't seem to be deployed in many places so I don't know how good it is.

Opera has more than 100 million users (while Firefox has 300 something million users). You really should stop parroting this inane "Opera has no users" lie.

Too late. The FAA is already heavily involved with commercial space travel through the Office of Commercial Space Transportation. They've been doing this since 1984 under the Reagan administration, although this particular commercial spaceflight office has jumped around between several different agencies before finally getting put under the head administrator of the FAA. The FAA-AST head reports directly to the chief administrator of the FAA, who in turn reports directly to the President. That is a rather short chain of command and not bad in terms of a federal program.

For myself, I sort of like having the FAA involved here as it sort of diffuses the authority over regulating what goes one in space into many more hands and keeps the authority over who actually runs operations in space as a committee reporting to many people who have different objectives and goals in mind. Ideally I would love to see a complete elimination of any government oversight on spaceflight as well, but if you have to have something to satisfy the statists who love to control all aspects of our lives, you could do much worse than the FAA running the show.

For a government agency, at the moment they are very small and lean, as well as fiercely protective of their turf (as most agencies are). More significantly, the FAA-AST (the AST because of historical roots for that acronym) looks after the commercial interests as their number one priority and have been known to move heaven and earth to get the other branches of the federal government to go along with some commercial spaceflight project.

The other alternative is to leave this to NASA and let NASA run commercial spaceflight activities.... something NASA has a truly abysmal record of supporting and indeed can be said that repeatedly NASA has been involved with explicitly killing off commercial spaceflight ventures in the past as they have been perceived as direct competition to NASA rather than something to cooperate with. Better yet, should this be something done via the military, such as having it become part of the Air Force or worse yet the National Reconnaissance Office? By treaty (signed by all of the current and near-term potential future space faring nations on the Earth) it is the responsibility of the national governments to regulate how their citizens get into space and the consequences of interactions with other vehicles that may happen in space or what happens when the stuff starts to come back down to the ground.

Again, if not the FAA, what branch of the federal government should be involved here?

In the US, several major toll roads (NJ Turnpike, MA Turnpike, Garden State Parkway in the northeast) have been using the time stamp on the toll tickets to determine your average speed on the road in use. If the time it takes to go from one exit to another is one hour doing the speed limit and you do it in thirty minutes, you can expect to be mailed a ticket.

That system is fairly easy to implement as the roads are limited access and all vehicles will be passing through the toll booths at some point along their length. It appears the British system is geared toward using the system on roads without limited access. With increased complexity will come increased possibilities of errors creeping into the system. I agree with the conclusion in the article that the system should be watched closely before it becomes official. (And, yes, I acknowledge that such a system could be used for less-than-moral uses by a government.)

As one reader, Vanderbosch, noted above, how are they going to tell who is operating the vehicle? Well, would you entrust your car and insurance to a 'friend' who is less than responsible for other people's property? If he's a friend, he'll pony up and pay you for the ticket and the increase to your insurance. I sure as hell wouldn't be entrusting an expensive piece of property to someone I didn't trust! If you do, then consider it punishment for being a fool.

When I was growing up, the government was pushing computers into schools. The machine that they selected for the purpose was the BBC Micro. It came with a very powerful dialect of BASIC (supporting structured programming, writing directly to memory addresses for I/O, and even had a built-in assembler) in ROM and a massive array of useful ports. These included things that you could easily connect to a variety of sensors, or motors. One port, for example, was an 8-bit digital I/O port. On some modern systems, you get the same thing from GPIO, but this had two advantages:

• The pins were big and connected to a standard ribbon cable, so it was easy to build something that connected to them.
• You could read and write a byte of data from BASIC with the PEEK and POKE commands at the right address.

The most important thing about this machine was that it started up in a programming environment and leaving it required effort. My school had some education games, but if you wanted to play one then you needed to go to the headmaster's office and ask for the disk. If you just sat down at the computer (which you could do at break and lunch times if you reserved it, or after school if no one else was using it first) then you were in a programming environment by default.

Writing code was a fun way of killing some time while waiting to be collected after school. Machines of the era that people used at home typically had a cassette deck instead of a disk drive. This meant that playing a game could involve 10 minutes of waiting for it to load, while writing a program was something you could start immediately.

The first computer I had at home was a PC with a BASIC interpreter and a PL/M compiler. I later moved from PL/M to C, and still find the painfully primitive memory model irritating.

Yup - those kinds of cycles are usually based on real-world experience. They test and see how often parts fail, and then set the maintenance cycles to ensure that everything gets looked at several standard deviations before even a fluke failure would occur.

However, if you test the engines on clean air, and operate them on condensed glass particles, then you're probably not going to get favorable results.

What do you do when a truck carrying insulin or blood or even pills dies and is stranded in a desert for a week? Most likely you end up throwing everything out. Even if it is ok at the moment it makes it to the warehouse, the goods probably have months subtracted for their shelf life, which means that a year later some poor guy will suffer for it if they try taking it (some medicines degrade into harmful substances, most just become ineffective, but if you need that medication to survive ineffective can be just as bad).

The only way to safely operate in these conditions is to run a statistically meaningful set of tests - and keep repeating them over time (no guarantees that the ash thrown up today will be the same as the stuff from yesterday), and then redesign the maintenance schedule from the ground up. Chances are it will be cheaper just to ground the planes...

Can be watched here.
P.S. You may safely skip the first 6 or even 10 minutes of it.

Let's recall that tribes that life off hunting have more lactose intolerant people that those that practice livestock breeding, that certain northern tribes of Chukchas and Eskimo doesn't have ensimes to get rid of alcohol so they become alcoholics easily and so on and so on.

Indeed. Big Blue has made far more $$ off Linux consolidation on zSeries than they can possibly lose due to the few customers who move off zSeries hardware to this emulation platform. Those who would do so will do it because they simply can't afford the IBM lock in pricing any longer. Those customers aren't typically buying or leasing new mainframes anyway. They limp along forever, putting off the inevitable switch to another platform, because IBM is always willing to offer an extended full covered service contract at a "just reasonable enough" price, no matter how old the mainframe hardware in question may be.

If this Hercules emulator is such a threat, why doesn't Big Blue pull the standard maneuver of "buying" the project, people, and Hercules the company, bring it all under the roof, and fully support it? THAT is smart business, not wasting money tying to kill the competition. This Hercules solution would pick off the weak and injured mainframe customers at most. It is not a threat to IBM's healthy mainframe customers as they usually need the advanced mainframe features not available in the emulator on x86 hardware solution.

I feel they're on the path to losing more money due to FOSS backlash than what they'd save by suing this "competition" into non existence.

You'd be surprised.

Beta, for instance, ran for nearly two decades. Not in the home VHS market (which was their original target) but in the home camera market (where the smaller size made for easier handheld video cameras) and the television broadcast market (where they don't care so much about having to switch tapes after a certain time limit, but DO care very much about getting higher, more reliable video quality). Those two sectors were still using Beta tapes for a very long time, in fact some more rural TV broadcasting stations were still using them right up until the limit of HDTV broadcast conversion.

DAT was exceedingly popular in Europe and Asia, just not in the US - and Sony took their money there quite happily. It took longer to get DAT into the US because the RIAA, and their pet senators like Al Gore Senior, pushed the predecessor to the DMCA, the Digital Audio Recorder Copycode Act of 1987, with the intent of making DAT carry a "copyright flag." Sound anywhere similar to MafiAA tactics today?

Memory Stick Duo hasn't gone away. It's not used on many non-Sony devices, but Sony sells enough cameras and PSPs that they can keep it on the shelves and make a fair bit of money back from third-party manufacturers like Sandisk who license it.

I could go on, but the point is, not all of their "failures" failed spectacularly, and they have had plenty enough successes to fund everything else they have wanted to do. Had they actually been smart and come up with a "flash once" Memory Stick Duo standard rather than trying to push UMD on the PSP for their games (or alternatively, had the PSP had RCA/Composite video and audio outputs in its original incarnation so that it could simply be plugged into a TV for playing those UMD movies), it's quite possible they could have had yet another proprietary standard that did "well enough."

I believe they were meaning that the bigger of the two you can see was found to be a binary, not that the two you see were found. So in other words, Mizar A and B in the 1700s, Alcor was discovered much earlier as it is easy to see that it is there.

I'd rather they fixed Windows guest support. I've tried it (in Ubuntu Karmic), and it's horrible if you want to run Windows in it (both XP and Win7). Very slow, timer lags behind, network and disk throughput are super slow even with virtio guest drivers. Linux runs fine as a guest on the same box.

I guess it's unfair to _demand_ anything if something cost you zero dollars (gifted horse thing and all), but VMWare ESX and HyperV Server also cost zero dollars these days, and they both run Windows just fine.

I've done a poor man's benchmark by untarring the gnu glibc 2.11 tarball onto a newly formatted 2 GB usb stick under Windows. The stick was formatted with the default options for each filesystem, and was "safely removed" and reinserted between each step.

Speed: time it took to extract the tarball on the newly formatted device.
1) UDF 2m 33.171s, 2) NTFS 25m 29.718s, 3) exFAT 42m 30.390s, 4) FAT32 47m 31.640s.

Speed: time it took to delete the whole tree created at the previous step.
1) UDF 0m 34.875s, 2) NTFS 6m 28.156s, 3) FAT32 16m 10.578s, 4) exFAT 28m 18.000s

Disk usage overhead: space that was nominally reported as free just after formatting.
1) exFAT 2,047,410,176 bytes, 2) UDF 2,047,056,384 bytes, 3) FAT32 2,043,637,760 bytes, 4) NTFS 2,008,457,216 bytes

Disk usage overhead: space that was nominally reported as free ater extracting the tarball.
1) UDF 1,941,765,632 bytes, 2) FAT32 1,915,809,792 bytes, 3) NTFS 1,877,790,720 bytes, 4) exFAT 1,616,379,904 bytes.