Forgot your password?
typodupeerror

Comment: Re:We get cancer because we have linear DNA (Score 1) 151

by jd (#47726213) Attached to: New Research Suggests Cancer May Be an Intrinsic Property of Cells

That's easy to fix. If a cell has not just the existing error correction codes but also digital ones as well, then mutagenic substances (of which there are a lot) and telemere shortening can be fixed. Well, once we've figured out how to modify the DNA in-situ. Nanotech should have that sorted soonish.

The existing error correction is neither very good nor very reliable. This is a good thing, because it allows evolution. You don't want good error correction between generations. You just want it in a single person over their lifespan, and you want it restricted so that it doesn't clash with retrotranspons and other similar mechanisms. So, basically, one whole inter-gene gap/one whole gene protected by one code. Doable. You still need cell death - intercept the signal and use a guaranteed method.

Comment: Exploit that which you cannot defeat (Score 1) 151

by jd (#47726171) Attached to: New Research Suggests Cancer May Be an Intrinsic Property of Cells

Here, in the year Lemon Meringue, we decided to solve the problem once and for all.

Instead of trying to kill cancer, we hijack its techniques. We start by having nanocomputers in the vaccuelles of each brain cell. These keep a continuous backup copy of the state of the brain up to death. Cancers disable the hard limit on cell duplication that cannot otherwise be avoided. By using the techniques of cell-devouring microphages, the cancer "consumes" the old cells and replaces them with new ones. They can't spread anywhere else, because that's how the cancer is designed to spread. Once the body has been fully replaced, the cancer is disabled. The brain is then programmed by the nanocomputers and the remaining cells are specialized by means of chemical signal.

This does result in oddly-shaped livers and three-handed software developers, but so far this has boosted productivity.

Comment: Re:It's not a kernel problem (Score 1) 661

by jd (#47726057) Attached to: Linus Torvalds: 'I Still Want the Desktop'

The free market didn't provide alternatives. The free market created Microsoft and the other monopolies. Adam Smith warned against a free market.

The majority do not create alternatives, either. The majority like things to not change. The familiar will always better the superior in the marketplace.

Alternatives are created by small groups of people being disreputable, commercially unproductive and at total odds with the consumer. These alternatives will typically take 7-14 years to develop. Adoption will typically reach peak after another 7-14 years. By the 30th year after first concept, the idea will be "obvious" and its destiny an "inevitable consequence" of how things are done.

In reality, it takes exceptional courage and a total disregard for "how things are done". 7-14 years with guaranteed losses is not how the marketplace works. Even thinking along those lines is often met with derision and calls of "Socialism!" by the market. No, real inventors are the enemy of the free market.

If you want a Linux desktop, you must forgo all dreams of wealth. You must subject yourself to the abject poverty that is the lot of an inventor in a market economy, or move to somewhere that supports the real achievers.

Comment: The problem isn't X. (Score 1) 661

by jd (#47725933) Attached to: Linus Torvalds: 'I Still Want the Desktop'

The problem is corruption. OSDL were working on a Linux desktop environment, but a key (financial) figure in the organization worked hard to kill off success and left around the time the unit went bankrupt. Several organizations they've been linked to have either gone belly up or have suffered catastrophic failure.

I won't name names, no point. What is the point is that such people exist in the Linux community at all, parasites that destroy good engineering and good work for some personal benefit of their own.

X is not great, but it's just a specification. People have developed Postscript-based GUIs using it. It's merely an API that you can implement as you like (someone ported it to Java) and extend as you like (Sun did that all the time). The reference implementation is just that. Interoperability of just that set of functions used by Glib/Gtk and Qt would give you almost all the key software.

Alternatively, write a GUI that has a port of those three libraries. You could use Berlin as a starting point, or build off Linux framebuffers, or perhaps use SDL, or write something unique. If it supports software needing those libraries, then almost everything in actual use will be usable and almost everything written around X in the future will also be usable. If what you write is better than X, people will switch.

Comment: Re:Nobody else seems to want it (Score 1) 661

by jd (#47725801) Attached to: Linus Torvalds: 'I Still Want the Desktop'

Binary drivers exist and are loadable so long as they are properly versioned.

Block drivers can always use FUSE.

Automatic builders can recompile a shim layer with new kernels (or even the git tree version), automatic test harnesses or a repurposed Linux Test Project can validate the shim. You don't need to validate the driver for everykernel, if it's totally isolated from the OS and worked before then it'll remain working.

Automated distributors can then place the binaries in a corporate yum/apt repository.

What has an ABI got to do with it? Only gets in the way of writing clean code.

Comment: Why? (Score 1) 661

by jd (#47725719) Attached to: Linus Torvalds: 'I Still Want the Desktop'

The commands to the bus don't change.
The commands sent to the hardware don't change.
The internal logic won't change.

That leaves the specific hooks to the OS and the externally visible structures.

Nobody is insane enough to use globals directly and structures are subject to change without notice. So external stuff will already be isolated.

If the hardware is available for any two of HyperTransport, PCI Express 2.x, VME/VXI or one of the low-power busses used on mobile hand-warmers, err, smart devices, then the actual calls to the bus hardware will be compartmentalized or go through an OS-based abstraction layer.

So 95% of a well-written driver is OS-agnostic and the remaining 5% is already is isolated.

So either drivers are very badly written (which is a crime against sanity) or the hardware vendor could place the OS-dependent code in its own DLL at bugger-all cost to them. Since the OS-dependent code has nothing trade secret in it, they can publish the source for the shim at no risk. Since the shim isn't the driver, there's no implication of support for OS' they don't know or understand. It's not their problem what the shim is used for.

Everyone's happy. Well, happier. The companies don't get harassed, the Linux users get their drivers, Microsoft gets fewer complaints about badly-written drivers killing their software. It's not open, it's not supported, but it's good enough.

Comment: Re:Growing pains. (Score 2, Insightful) 210

A lot of people who complain about government are people who would like to terminate most, if not all, labor protections. They bury that desire in ideological ruminations, and have convinced vast legions of rubes that the only good government is a non existent government, and somehow the magic of market forces will protect workers.

Comment: Light but reactive element = high energy density (Score 1) 138

by Ungrounded Lightning (#47718377) Attached to: How Argonne National Lab Will Make Electric Cars Cheaper

"lithium is in the upper left-hand corner of the periodic table. Only hydrogen and helium are lighter on an atomic basis."

  I'm wondering if this is a non sequitur for electric batteries.

Not a non sequitur at all.

An important factor for batteries is energy density: How much energy is stored per unit mass. This is particularly important for electric cars: The higher the energy density, the less mass you havce to haul around for a given amount of "fuel", which means the less "fuel" is spent hauling your "fuel" around, so it's a more-than-linear improvement.

Lithium is both extremely light and a very reactive nonmetal. So you're talking about a lot of energy per unit mass for the lithium-based electrode's contribution to the reaction.

Comment: Re:No difference (Score 0) 104

by MightyMartian (#47715819) Attached to: Do Readers Absorb Less On Kindles Than On Paper? Not Necessarily

I agree completely. When I first started using an dreaded (an old LG keyboard phone with a JavaME spun reader I had hacked on to it) I found reading a bit of a chore. It took me a few days to get really comfortable with the seemingly small and yet ultimately pricing differences. Now I regularly read books on my smartphone and tablet without a hitch, and have noticed no recall problems.

It is better to give than to lend, and it costs about the same.

Working...