having an "open source" product without having the ability to modify... creates a dependency on the author of the product to get a patch out.... this seems worse than MS...because if you are relying on something that has 1 main author in this model...you technically could only get a fix from him/her. At least MS has a team of maintenance developers in case one is in the hospital.
It's bad but not AS bad.
In the "read but don't touch" model you've still got the world to debug the code, diagnose any security failures, and supply proposed changes. You're just dependent on the copyright holder to apply and distribute them. In the closed-source model all the world can do is submit bug reports, which the small team must sift for REAL bugs, diagnose the probles, write and test the changes, and THEN apply and distribute them.
Not as nice as being able to apply your own changes, or those supplied by others, while you're wating. Definitely not as nice as being able to publish fixes. But it's still ahead of "peh-TI-shun-ing the LAW-ud with prah-AY-uh" and waiting for a vendor to notice that the bug is real and decide it's worth fixing before they even START to TRY to fix it.
Still I prefer Linus' model: "The OFFICIAL kernel has only what I approved and added. Hack all you want, but don't blame me if it blows up."
"Derivitive" is a nonexistent word. I hereby define it to mean "something which is not licensed under the GPL".
It does refer to derivative works.... If you have a series of adjectives all modifying the same noun, you generally do not write (or say) the noun after each one, its redundant....
You missed his point. What he posted was a spelling flame. The original misspelled "derivative" as "derivitive" and SEWilco keyed off that and declaraed that, since this was a new word, he could define it as whatever he wanted.
Of course the meaning is clear despite the misspelling, and what's important is whether a "reasonable and prudent" licensee could be expected to understand what was meant. So if the word was misspelled in this way in a license it wouldn't invalidate the license.
Solution: from now on distribute the original virgin source and a patch file. This may only transfer the issue from the developer of the fork to the installer of the fork but it does make the problem much more difficult for any lawyer to pursue as he would have to get permission from the court to examine the accused's computer.
I think you missed a point.
To create the patch file you have to do one of two things:
Create a derivative work and diff them.
Write the patch file from scratch.
Writing a patch file from scratch that even applys correctly is difficult without at least trying to apply it, which also creates a derivative work. Writing one that produces working code is virtually imposible. (Did you ever get even a single subroutine to compile and run correctly the first time? Not impossible with a small one, but extremely rare.)
Copyright is a civil matter, so the standard of proof it "preponerance of evidence". A patch file that applys correctly and produces working code with a feature added or changed in a predicted way should qualify for that test, and bring copyright's draconian penalties to bear.
(And then there's the question of whether a context diff is itself a derivative work or if the included text qualifies as "fair use".)
Still here. (I generally check my recent posts page to see if anybody has replied.)
There also was a great concern if DNA damage would be inherited, or the children would have gentic problems that were not seen in parents. They even invented a word for those second generation survivors (Nisei==second generation).
But it seems that the concensus after 56 years is that the children were not more affected than their parents.
It looks like dominant mutations tend to get weeded out by spontaneous abortion during foetal development. (A plausible function for "ontology recapitulates phylology", the tendency of a foetus to go through stages corresponding to its evolutionary history, might be to give a test-run of the currently turned-off-in-adults genes to make sure they are still intact, "crashing" the foetus if not.)
Recessive mutations (i.e. non-functional proteins that you only need one good copy of) might have to wait until the broken gene gets paired up with itself, generations later. First occurrence would be in third generation if brother married sister. With normal restrictions on intermarriage it won't occur for quite a few generations (though they could also pair with differently-damaged versions of the same gene sooner). Expected result is the same: Most of the mutant genes will produce spontaneous abortions when paired up and get weeded out.
A little sad side of this whole nisei thing was that some second generations wanted to have the same benefit as the first generation survivors who get any medical treatment for free.
I can understand it. Fortunate that they don't seem to be having excessive health problems.
But I can also understand the issue on the government side. You have to stop somewhere.
I thought that my being relatively smarter might have something to do with it:P I also wished I had some supernatural power:)
Maybe it does. I seem to be relatively smarter, too, and I got a LOT of chest x-rays as a kid.;-)
By the way, the first movie ``Godzilla'' reflected the Japanese' fear of atomic bombs. As you may all know, Godzilla was a mutant lizard.
Didn't the first Godzilla movie have the creature revived/hatched as a side-effect of nuclear bomb testing, and showing up acting really angry about it. (Sort of like the badger, which looks and acts like a weasel that had its head run over by a truck and is still mad about it. B-) )
OK, so you're saying that an exposeure to a ``CONTINUOUS, LOW LEVEL of ionizing radiation'' is good for health.
I may be a slight net gain, under some circumstances, for a well-nurished otherwise-healthy adult. But don't go out and get a daily X-ray in the hope I'm right. IANAMd B-) Just don't sweat it if you live in Denver, work in a granite building, or are an airline pilot.
(But if you were downwind of Hanford or Chernobyl when they had releases, especially if you were still inside your mother at the time, sweat it BIG time.)
I was always wondering why my father is so healthy. He is a Nagasaki survivor. I know a couple more people who are extremely healthy. I was wondering if they survived because they were extremely healthy or they were healthy because they survived.
Probably the former. There are other mechanisms that attempt to suppress or kill off cells with damaged DNA, or to abort foetuses that have too much DNA damage. But losing a bunch of cells is normally not optimal, even if you luck out and ALL the remainder are healthy.
One of the surprises of Hiroshima and Nagasaki is how thoroughly the radiation-exposed survivors recovered. (Of course they were sick as dogs while the damaged cells were dying off, essentially everybody who was pregnant aborted, and there is a higher incidence of cancer and other problems later. It's just that they was not anywhere near as much long-term health problems, or sterility, as were expected early on.)
Being atom-bombed is NOT a Good Thing.
My father told me that he has about a half of white blood cells of average. Could anyone explain this?
Probably lost a bunch of bone marrow stem cells and memory white cells (which recognized they'd been damaged and committed apoptosis - "programmed cell death", or had their surface antigens changed and were killed by their neighbors.)
The next question would be if I am a mutant...
We're all mutants. You just might have a couple more recent mutations than the rest of us. B-) If so I expect they'll get sorted out in a few generations. Figure that most of 'em were already sorted out, in the form of brothers and sisters who weren't born. B-(
... I think the offending company would still be liable if they are based or operate in the US. Those that operate entirely outside the country might not be subject to US patent law - but there is also some significant reciprocity in patent laws between nations that could produce liability under US law even if all infringing activity took place outside the US.
I think you misunderstood me.
The point I'm trying to make is that the infringing activity DIDN'T happen outside of the US. The infringing activity was not to make the magnets in a country where the patent didn't apply. It was to BRING THEM IN to the US.
They're unpatented in the other country. They're patented in the US. So building them in the other country isn't illegal (except MAYBEE if it's done by a US corporation). But IMPORTING them into the US IS an infringement if the US patent is valid and nobody along the chain from the manufacturer through the importer licensed the patent.
The only questionable aspect of this is suing the OEM end users rather than those actually infringing, although I suspect that's a practical matter since the infringers are likely in a foreign country where IP is not well-protected.
If I understand this correctly the party that infringed the US patent is the one that imported the product with the infringing tech into the US.
It's not infringing if it stays in a country where there isn't a patent on it.
"These results indicate that low doses of radiation can induce multiple changes in human germline DNA."
... the germline cells are there, packed with chemicals that prevent mutations (antioxidants for instance). Most of this is to *prevent* mutations that occur through malicious chemicals. Radiation doesn't really work that way. It will just penetrate through and nock of some basepares from the DNA...
However, most of the damage done by radiation is done by the creation of free radicals, which then damage the DNA by chemical reactions. So antioxidants are quite effective (though not perfect) at stopping radiation damage.
The antioxidants are "expensive" nutritionally, (and humans evolved with less nutrition than is available in developed countries). So there's a feedback process to adjust their levels to limit free radical damage to an acceptable level without draining sometimes-scarce resources useful elsewhere. The bulk of free radicals in a cell come from the mitochondria (the cell's own "power plants").
As evidenced by cancer rate vs. environmental radiation exposure, the location of the "thermostat" is such that if the cell is exposed to a CONTINUOUS, LOW LEVEL of ionizing radiation the free-radical scavenger production is increased so much that the net result is LESS mutation. Up to the point where free-radical scavenger production maxes out, continuous low-level ionizing radiation is actually a net gain. (The same is also true of certain free-radical producing chemicals - again with the continuous low-level caveat.)
The problem with Chernobyl is partly that the level was NOT low, but mostly because the level was not CONTINUOUS. A short-term exposure to a high level of radiation is NOT equivalent to the same amount of radiation spread over years for a number of reasons, and a very big one is that the damage takes place before the levels of protecting chemicals can be raised.
So finding damage to DNA in stem cells of people who were brought to Chernobyl to clean up, and thus suddenly exposed to a high rate of ionizing radiation for a short time, is no surprise, and has no bearing on the expected effect of long-term exposure to low levels of background radiation.
We... are interested in interesting opinions about how the law might be improved, so [a local geek who will be testifying] can propose them.
This law as written is beautiful. It's a simple, to the point, expression of the will of the legislature that the government convert to open software wherever possible, as rapidly as is convenient.
In my opinion, any changes are more likely to break it than improve it. I'd be inclined to leave it just as it is for now.
================
A rule of thumb for any system design - government law or software - is to see what would happen if a deliberate attempt to misconstrue or circumvent its intent were made by the operator or outside parties. (The only operational difference between malice and mistake is that malice usually exercises the bugs and crashes the system a little sooner - so you look for system flaws as if you were looking for a way someone could deliberately break things, without implying that malice is actually present even if the system does crash later.)
The only potential hole I see is that the timetable is left open. So if both a division head and the chief executive were opposed, or if the chief executive didn't push subordinates who dragged their feet, the timetable could slip out indefinitely.
But it's appropriate to leave the timetable to the executive, rather than to try to micro-manage from the legislature. Execution is the executive's job. And I'd bet the chief executive is also in favor of this, or at least willing to go along with the will of the legislature. So I'd leave it as it is for now and revisit it in a few years to see how the conversion is coming.
If you're really concerned that something might fall through the cracks you might have the executive branch report every few years on the progress of the conversion, including a list of what hasn't been converted and why. After five or ten years if there's anything unconverted that the legislature hasn't been convinced SHOULDN'T be converted, then it might want to make changes to the law to give them a push.
(And I'd leave military systems up to the executive branch. Which I expect will insist on having source code for everything they commission, and on reverse-engineering any turnkey weapons systems they got from their allies. B-) )
Now we have the force of the state we no longer have to make strong opinions for Free Software! Yah! Now we can all just answer the question "Why should I use Free Software?" with "Because it's the law!" (well those of us in Argentina, anyway)
You either didn't read the law or you misunderstood it.
The law doesn't say ANYTHING about whether the citizens and/or non-government-owned corporations of Argentina will use closed or "free" software.
This is just how the government of Argentina decides that the government of Argentina will use free software.
The government and the corporations it controls WILL use free software, with details, timetables, and exceptions fleshed out by the exectutive branch.
The government RECOMMENDS to its semi-autonomous units (such as universities) that they use free software.
The government places no requirements on the rest of the country at all.
When I first saw the title I thought that the law may have covered all software used in a country, not just for the government. Luckily, it was just the government changing, leaving the consumer the right to choose.
I totally agree. Run the government's IT operations on open and free software, recommend it to the autonomous government-related functions, and let the private sector - individual and corporate - make its own choices (and continue to abide by existing contracts).
Although I fully support Linux and the free software movement, I disagree with this law for one major reason: the best product cannot always be used. If a commercial product does the job better, it will end up costing more to use the "free" software.
But here I disagree strongly.
You're measuring only the immediate cost. There are additional long-term costs. Costs like:
lack of support,
future higher costs ("the first rev is free"),
lack of interoperability with other departments' or citizens' applicaions,
secondary monopolies (i.e. the citizens have to buy the expensive product or agree to a company's license to perform interactions, some mandatory, with their government's databases and functions),
use of such secondary monopolies to create further monopolies, expanding the lockin
I could go on.
The point is it might be a cheaper and more efficient solution to one immediate problem. But closing in the data with a proprietary application costs much more than any immediate monitary savings.
Actually, the behavior he is describing is what is actually implemented in most cases.
During the base class constructor, the virtual function table pointer is initialized to point to the base class table, thus when the user written ctor code is called any virtual function ref will be to the base class ctor.
When the next level of inheritance's ctor is called, the VTPTR will be initialized to the derived class VTBL, and so any virtual will go to the virtual class.
During destruction, the process is reversed.
All that is needed is to formalize this behavior.
Close.
First: Though the usual implementation is via a vtable pointer, the spec speaks in terms of what virtual function is entered, rather than in terms of when the vtable pointer is stored, so that compilers are not constrained to use a vtable implementation.
Second: The current spec defines the behavior of calls during the constructors and destructors of the classes, but leaves open the behavior during the construction and destruction, and other initialization if any, of the member objects.
In terms of "storing a vtable pointer" the current standards allow the compiler to store the derived-class vtable pointer either before or after the member object constructors are called and/or other member initialization is done (or even at some arbitrary point during such initialization). I claim it should be tightly specified to be stored AFTER all other initialization (including any other automaticly-generated code) and immediately BEFORE the execution of the first line of the body of the constructor.
Similarly, it allows the base-class vtable pointer to be stored before the member DEstructors are called, after, or during. I claim it should be stored immediately AFTER the execution of the last line of the body of the destructor, BEFORE any member destruction or other automatically-generated code.
In the general form, the reasoning is as follows:
Member constructors (and other member initialization) are peers with base class constructors: They constitute the creation of pieces of the object, which are to be finished parts before the object is constructed from them. First they are constructed and initialzed. Once that is done the class' own constructor assembles them inito a composite object and initializes that composite object.
Until the pieces of the object are completed the object is just a collection of pieces. It is only during the execution of the body of the constructor that the collection progresses from a pile of parts to a unified, operational, component.
So calling the derived-class overriding of a virtual function before the derived-class constructor is executing is a mistake. It calls a function of an object that does not yet exist, rather than the corresponding function of the component piece, which DOES exist and IS initialized.
During the execution of the constructor, the author of the derived class can take whatever care is necessary to use only the features of the object whose underpinnings are properly initialized. While the member objects are being constructed the author of the derived class has no such opportunity.
On destruction the issues are similar. While the derived-class has had a chance to initialize, some of the underpinnings for the virtual functions may need to be torn down on finzliation. Calling a virtual function after its support structure is torn down is also an error.
Writing a code generator to store the vtable pointer at the proper moment during construction is trivial. Writing one to store it at the proper moment on destruction is slightly harder: The base class and derived class might be separately compiled, so either the base class must export its vtable pointer for the derived class destructor to store or the derived class must generate its own equivalent vtable.
My definiton means that virtual function calls in initialization expressions get the base-class overriding. But that's not a problem for two reasons: It's currently not specified, and the author can specify the overriding he wants by using the:: scope-resolution operator.
Now, there is a problem related to this that I'd like to see addressed:
Consider a base class which exists to allow an object to attach to a list and have a virtual method called in response to events sent to that list. It is up to the derived class to overload a virtual function to handle those events.
This is exactly one of the reasons we wanted this definiton.
Now, ideally I'd like the base class to connect to the list in the ctor, and disconnect in the dtor. However, it is not safe to connect to the list until the object is fully constructed, as an asynchronous event may cause the virtual method to be called before the object is constructed. Equally, I want the object off the list before the dtor is called for the same reason.
What I'd like to have would be an additional two methods. The first would be called immediately after the ctor, the second immediately before the dtor. Thus, these calls have at their disposal the whole, fully constructed object, with all virtual methods intact and ready to go.
In the case of global objects or static objects, the compiler would generate a second list of function calls, to be called after the init code has iterated through all the static constructors (and another to be called before iterating over all static destructors).
With the definition I'm proposing you have a solution available, and it doesn't require two overridings of the function. Consider:
First: Create a construction-progress member variable, and initialize it to the "no progress yet" state. This variable is thus initialized before the vtable pointer is changed, and it will persist after destruction.
Second: The vtable pointer is changed - but any of your virtual functions that need construction that isn't complete can check the state variable, and do what is appropriate for the current level of construction. (This is probably making a call to the base-class version of the function and returning the restut.)
Third: As construction progresses through stages that enable various virtual member function behavior, the constructor updates the state variable, "turning on" the fully-constructed behavior, or any intermediate-step behavior, as necessary.
By the time the object is fully-constructed and the constructor exits, the full behavior of the member functions is manefest. The teardown sequence proceeds similarly, but in reverse.
If you like you can implement the "state variable" as a set of "pointer-to-function" variables, to eliminate the explicit tests at the start of the member functions. The "real" virtual member function would be something like:
foo(args) { return (*this->current_foo)(args) }
It's not quite as execution-time efficient as your double vtable pointer store, but it gives you arbitrarily fine control without extra compiler mechanism.
Having done a fair bit of multithreaded C++, I am of the opinion that, if they are going to standardize on a threading library, they are going to need this sort of hook.
Check.
Though originally intended to handle non-multithreaded cases (such as the non-polically-correct examples of garbage collector pointer-walks and error-exceptions during construction), this scheme is also adequate to support correct behavior in multithreaded code.
The C++ standards deliberately leave something open which I think should be defined in a particular way.
Suppose:
you are constructing an instance of a derived class
one of its base classes has "published" a pointer to the partially-constructed instance
the class has a virtual member funciton
the member function is overridden by this class
the class also has a member variable of a class type with construction
the constructor of the member variable (or something it calls) finds the published pointer and calls the virtual member function.
What happens?
My claim is that such a call SHOULD be legal and SHOULD call the BASE CLASS version of the member function. Similarly, during the execution of the DEsctuctors of the member variables you should also get the BASE CLASS version of the member function. You should get the derived class version exactly from the beginning of the execution of the first line of the body of the constructor through the end of the execution of the last line of the body of the desctuctor.
The reasoning is too involved to go into here. Suffice it to say that:
It's a consistent generalization of the philosophy of the C++ constructon-destructon semantics (and of the way that the C++ semantics differs from those of Objective C and Smalltalk.)
It's an compiler implementation that is allowed by all the levels of C++ standardization.
There's a LOT of neat stuff you can do with this guarantee that you can't do without it.
There are a lot more opportunities for programming error if your compiler doesn't work this way. (Not to mention the issue of code that works find with a compiler that does it one way but breaks when run through a compiler that does it a different way.)
The original C++ work didn't specify the behavior in question. The first ANSI standard explicitly left it open. The revised ANSI standard not only explicitly left it open but said "don't do that". B-(
At the time I first proposed it (about 10 years ago) we looked into a sample of the compilers on the market. There are four binary combinations of member constructor/destructor and base/derived version of member function, of which I claim one is "right" and the other three "wrong":
Cfront and the Cfront-derived C++ compilers tested (Sun, SGI) got it "wrong" one way.
The three IBM PC compilers tested got it "wrong" a second way.
Gnu G++ got it "wrong" the third way.
so standardizing on this semantics wouldn't favor any particular vendor's existing product.
IMHO this somewhat obscure issue is one of the major impediments to C++ achieving its potential as an object-oriented language, and it is unfortunate that is wasn't "fixed" in one of the previous standards.
Instead of water, why not pump mineral oil through the system?
Three reasons:
Mineral oil has a much lower specific heat than water. You need to circulate a lot more of it to get a given degree of cooling.
Mineral oil is flammable.
Mineral oil is a very good solvent. Goodbye to any plastic parts. (And to your rug if you spill any. And imagine the effect on the building.)
The Cray II was cooled with a clear liquid - a fluorocarbon, I think. They also had a debubbling gadget in the room near the computer. Looked like an enclosed fountain made of plexiglass. Very artsy. The two Cray IIs I saw had very distinct fountains, which made me wonder if they were distinct artworks - at least at first.
Couldn't this technology be used just as easily to scan the ascii character at the cursor and render it in brail, litterally at the person's fingertips?
Yes it could. Great idea. (I moderated you up with an "insightful" but made a comment elsewhere later and slashdot undid it. Sorry 'bout that.)
With the browser "hotwired" for the touchy-mouse the text would be directly available to the braile converter. Braile would be more readable using the mouse+pin-pad than images of text, and the motion would approximate that of normal braile reading so it would be very easy to learn.
For example, have the affected person wear a video camera on their head [helmet cam?]. The blind person could carry a higher resolution "pad" with maybe 640x480 pins representing the image from the camera. People could use their hands to "see" whatever the camera is pointing at. I might suggest a hands free device, such as one which can be strapped to a person's back, but I don't think there are proper nerves there to sense a high-resolution image.
In fact exactly this was tried in a lab, and worked like a charm. There are adequate nerves in the back - you just have to move the pins farther apart. (Although the resolution may be low enough that you can only do a very narrow image... The test setup only used a small number of vibrating pins. This was quite some time ago, when the equipment was big, custom, and expensive.)
An experimental accident gave an interesting insight into the rewiring abilities of the brain. The camera was on a tripod, and during one of the experiments it tipped over and fell into what it was viewing. The experimental subject, blind from birth, reflexively put his hands in front of his eyes.
That's a very strong indication that the signals from the back had been re-routed into the pathways normally used to process images, implying all that specialized neruoprocessing will be available for even the blind-from-birth to use on images converted to touch. Imagine blind baseball players, or blind drivers as safe as the run-of-the-mill driver.
Afterward the subject commented that for the first time in his life he had a referrent for the word "looming".
Geocities doesn't like links directly to images on its site. So start a new browser session and paste the URL in.
Try this instead:
Click on the link. You get the "I'm sorry..." page. Then:
Put your cursor on the location bar (which still has the URL of the image) and hit carriage return.
That tries again. But it reports the previous page as being the "I'm sorry" at the same URL, which is on their server. Thus the server thinks you're coming in from a self-link on the same page. B-)
(At least it worked for me when I tried it. I'd debug it but I'd have to flush my chache at this point - Netscape wants to serve me my local copy.)
Just because something is very good at one job (server) doesn't mean it's unsuitable for another (workstation).
BSD is a desktop OS and has been since there were desktop-sized machines that could run it. The same is true of any "server" OS that can drive a display/keyboard combination while living in a small box that is built in or nearby.
Think about it: A "server" is just a system with enough resources to handle MANY users, of the sort that once required a box too big to lug around without a fleet of trucks.
Now a [foo] server (file server, terminal server, etc.) is another matter. That's a system that has enough of one kind of resource to handle more than one user, but not necessarily all the kinds of resources you need to support a desktop. But BSD is not a [foo] server. It's a generic operating system that provides all the resources you need.
I should have defined what I meant by intrinsic. As you point out, gold has useful industrial uses. As long as that continues to be the case (which of course is also subject to change), gold has what I was referring to as intrinsic value.
But that just pushes the question further back. What is the "value" of the industrial uses? A lot, if somebody wants to run such an industry or use its products, zero if not.
"Value" is a strictly subjective labeling. The only objective measures we have of something's value are:
what someone will trade to obtain it
what someone will accept in return for giving it up
what someone will expend to defend it against loss or confiscation
And all three measures are distorted. (For instance: the third is distorted by the additional subjective negative value of having been ripped off and the positive subjective value of having successfully defended against an attack.)
Are raw potatoes really poisonous?!? I eat them all the time!!!!
It's the rest of the plant that's toxic, at least most of the time. Don't eat a potato that's sprouting or getting a green layer beneath the skin. (You may not become obviously ill with just a green layer, but it's not advisable anyhow.)
That's one reason a potato is such a useful plant: It kills off most insects that try to eat it. (Unfortunately there are other organisms that attack it, and since potatoes are reproduced mainly by cloning they have little diversity. That's why a blight led to the Irish Potato Famine.)
I hear the toxin involved is not broken down by cooking temperatures.
Terminator never came out. Monsanto got too much flack for even considering it.
But cytoplasmic sterile hybrid corn was a BIG thing for years. It had the same effect: The seed companies kept the lines that could reproduce to themselves and made "mule" crosses that couldn't reproduce to sell as seed to the farmers.
(It wasn't JUST a scam to keep selling seeds. The hybrid didn't regrow as a weed the next year, when farmers practicing crop rotation switched to another crop to keep the field fertile.)
That largely ended when a corn blight came through in the early '70s. Seems the line that was crossed-in to make the seeds sterile also carried susceptability to the blight - and almost all the corn was wiped out that year.
They were really worried about the next year, too, because the companies couldn't come up with enough seeds from other lines to supply all the farmers in one year, so there was a lot of the susceptable stuff out there. (Fortunately the blight infestation was minor and well contained the next year.)
Slashdot Mirror
having an "open source" product without having the ability to modify ... creates a dependency on the author of the product to get a patch out. ... this seems worse than MS...because if you are relying on something that has 1 main author in this model...you technically could only get a fix from him/her. At least MS has a team of maintenance developers in case one is in the hospital.
It's bad but not AS bad.
In the "read but don't touch" model you've still got the world to debug the code, diagnose any security failures, and supply proposed changes. You're just dependent on the copyright holder to apply and distribute them. In the closed-source model all the world can do is submit bug reports, which the small team must sift for REAL bugs, diagnose the probles, write and test the changes, and THEN apply and distribute them.
Not as nice as being able to apply your own changes, or those supplied by others, while you're wating. Definitely not as nice as being able to publish fixes. But it's still ahead of "peh-TI-shun-ing the LAW-ud with prah-AY-uh" and waiting for a vendor to notice that the bug is real and decide it's worth fixing before they even START to TRY to fix it.
Still I prefer Linus' model: "The OFFICIAL kernel has only what I approved and added. Hack all you want, but don't blame me if it blows up."
"...derivitive or modified works...
... If you have a series of adjectives all modifying the same noun, you generally do not write (or say) the noun after each one, its redundant. ...
"Derivitive" is a nonexistent word. I hereby define it to mean "something which is not licensed under the GPL".
It does refer to derivative works.
You missed his point. What he posted was a spelling flame. The original misspelled "derivative" as "derivitive" and SEWilco keyed off that and declaraed that, since this was a new word, he could define it as whatever he wanted.
Of course the meaning is clear despite the misspelling, and what's important is whether a "reasonable and prudent" licensee could be expected to understand what was meant. So if the word was misspelled in this way in a license it wouldn't invalidate the license.
I think you missed a point.
To create the patch file you have to do one of two things:
Create a derivative work and diff them.
Write the patch file from scratch.
Writing a patch file from scratch that even applys correctly is difficult without at least trying to apply it, which also creates a derivative work. Writing one that produces working code is virtually imposible. (Did you ever get even a single subroutine to compile and run correctly the first time? Not impossible with a small one, but extremely rare.)
Copyright is a civil matter, so the standard of proof it "preponerance of evidence". A patch file that applys correctly and produces working code with a feature added or changed in a predicted way should qualify for that test, and bring copyright's draconian penalties to bear.
(And then there's the question of whether a context diff is itself a derivative work or if the included text qualifies as "fair use".)
IANAL. But this sure makes sense to me.
After that, we marry them [forged-header spamsters] off to the Bush daughters ...
What have you got against the Bush daughters?
I don't know if you are still reading...
:P I also wished I had some supernatural power :)
;-)
Still here. (I generally check my recent posts page to see if anybody has replied.)
There also was a great concern if DNA damage would be inherited, or the children would have gentic problems that were not seen in parents. They even invented a word for those second generation survivors (Nisei==second generation).
But it seems that the concensus after 56 years is that the children were not more affected than their parents.
It looks like dominant mutations tend to get weeded out by spontaneous abortion during foetal development. (A plausible function for "ontology recapitulates phylology", the tendency of a foetus to go through stages corresponding to its evolutionary history, might be to give a test-run of the currently turned-off-in-adults genes to make sure they are still intact, "crashing" the foetus if not.)
Recessive mutations (i.e. non-functional proteins that you only need one good copy of) might have to wait until the broken gene gets paired up with itself, generations later. First occurrence would be in third generation if brother married sister. With normal restrictions on intermarriage it won't occur for quite a few generations (though they could also pair with differently-damaged versions of the same gene sooner). Expected result is the same: Most of the mutant genes will produce spontaneous abortions when paired up and get weeded out.
A little sad side of this whole nisei thing was that some second generations wanted to have the same benefit as the first generation survivors who get any medical treatment for free.
I can understand it. Fortunate that they don't seem to be having excessive health problems.
But I can also understand the issue on the government side. You have to stop somewhere.
I thought that my being relatively smarter might have something to do with it
Maybe it does. I seem to be relatively smarter, too, and I got a LOT of chest x-rays as a kid.
By the way, the first movie ``Godzilla'' reflected the Japanese' fear of atomic bombs. As you may all know, Godzilla was a mutant lizard.
Didn't the first Godzilla movie have the creature revived/hatched as a side-effect of nuclear bomb testing, and showing up acting really angry about it. (Sort of like the badger, which looks and acts like a weasel that had its head run over by a truck and is still mad about it. B-) )
OK, so you're saying that an exposeure to a ``CONTINUOUS, LOW LEVEL of ionizing radiation'' is good for health.
I may be a slight net gain, under some circumstances, for a well-nurished otherwise-healthy adult. But don't go out and get a daily X-ray in the hope I'm right. IANAMd B-) Just don't sweat it if you live in Denver, work in a granite building, or are an airline pilot.
(But if you were downwind of Hanford or Chernobyl when they had releases, especially if you were still inside your mother at the time, sweat it BIG time.)
I was always wondering why my father is so healthy. He is a Nagasaki survivor. I know a couple more people who are extremely healthy. I was wondering if they survived because they were extremely healthy or they were healthy because they survived.
Probably the former. There are other mechanisms that attempt to suppress or kill off cells with damaged DNA, or to abort foetuses that have too much DNA damage. But losing a bunch of cells is normally not optimal, even if you luck out and ALL the remainder are healthy.
One of the surprises of Hiroshima and Nagasaki is how thoroughly the radiation-exposed survivors recovered. (Of course they were sick as dogs while the damaged cells were dying off, essentially everybody who was pregnant aborted, and there is a higher incidence of cancer and other problems later. It's just that they was not anywhere near as much long-term health problems, or sterility, as were expected early on.)
Being atom-bombed is NOT a Good Thing.
My father told me that he has about a half of white blood cells of average. Could anyone explain this?
Probably lost a bunch of bone marrow stem cells and memory white cells (which recognized they'd been damaged and committed apoptosis - "programmed cell death", or had their surface antigens changed and were killed by their neighbors.)
The next question would be if I am a mutant...
We're all mutants. You just might have a couple more recent mutations than the rest of us. B-) If so I expect they'll get sorted out in a few generations. Figure that most of 'em were already sorted out, in the form of brothers and sisters who weren't born. B-(
... I think the offending company would still be liable if they are based or operate in the US. Those that operate entirely outside the country might not be subject to US patent law - but there is also some significant reciprocity in patent laws between nations that could produce liability under US law even if all infringing activity took place outside the US.
I think you misunderstood me.
The point I'm trying to make is that the infringing activity DIDN'T happen outside of the US. The infringing activity was not to make the magnets in a country where the patent didn't apply. It was to BRING THEM IN to the US.
They're unpatented in the other country. They're patented in the US. So building them in the other country isn't illegal (except MAYBEE if it's done by a US corporation). But IMPORTING them into the US IS an infringement if the US patent is valid and nobody along the chain from the manufacturer through the importer licensed the patent.
See?
(But IANAL either. B-) )
So once this is installed can I change my Name back to "Ungrounded Lightning Rod"?
The only questionable aspect of this is suing the OEM end users rather than those actually infringing, although I suspect that's a practical matter since the infringers are likely in a foreign country where IP is not well-protected.
If I understand this correctly the party that infringed the US patent is the one that imported the product with the infringing tech into the US.
It's not infringing if it stays in a country where there isn't a patent on it.
This is the important bit:
...
"These results indicate that low doses of radiation can induce multiple changes in human germline DNA."
... the germline cells are there, packed with chemicals that prevent mutations (antioxidants for instance). Most of this is to *prevent* mutations that occur through malicious chemicals. Radiation doesn't really work that way. It will just penetrate through and nock of some basepares from the DNA
However, most of the damage done by radiation is done by the creation of free radicals, which then damage the DNA by chemical reactions. So antioxidants are quite effective (though not perfect) at stopping radiation damage.
The antioxidants are "expensive" nutritionally, (and humans evolved with less nutrition than is available in developed countries). So there's a feedback process to adjust their levels to limit free radical damage to an acceptable level without draining sometimes-scarce resources useful elsewhere. The bulk of free radicals in a cell come from the mitochondria (the cell's own "power plants").
As evidenced by cancer rate vs. environmental radiation exposure, the location of the "thermostat" is such that if the cell is exposed to a CONTINUOUS, LOW LEVEL of ionizing radiation the free-radical scavenger production is increased so much that the net result is LESS mutation. Up to the point where free-radical scavenger production maxes out, continuous low-level ionizing radiation is actually a net gain. (The same is also true of certain free-radical producing chemicals - again with the continuous low-level caveat.)
The problem with Chernobyl is partly that the level was NOT low, but mostly because the level was not CONTINUOUS. A short-term exposure to a high level of radiation is NOT equivalent to the same amount of radiation spread over years for a number of reasons, and a very big one is that the damage takes place before the levels of protecting chemicals can be raised.
So finding damage to DNA in stem cells of people who were brought to Chernobyl to clean up, and thus suddenly exposed to a high rate of ionizing radiation for a short time, is no surprise, and has no bearing on the expected effect of long-term exposure to low levels of background radiation.
I thought it was the light-blue C from the cover of the original Kernighan and Ritchee language manual.
On second thought it IS a bit dark for that, at least on my current montior.
What's with the Microsoft blue in the header?
Microsoft???
I thought it was the light-blue C from the cover of the original Kernighan and Ritchee language manual.
We ... are interested in interesting opinions about how the law might be improved, so [a local geek who will be testifying] can propose them.
This law as written is beautiful. It's a simple, to the point, expression of the will of the legislature that the government convert to open software wherever possible, as rapidly as is convenient.
In my opinion, any changes are more likely to break it than improve it. I'd be inclined to leave it just as it is for now.
================
A rule of thumb for any system design - government law or software - is to see what would happen if a deliberate attempt to misconstrue or circumvent its intent were made by the operator or outside parties. (The only operational difference between malice and mistake is that malice usually exercises the bugs and crashes the system a little sooner - so you look for system flaws as if you were looking for a way someone could deliberately break things, without implying that malice is actually present even if the system does crash later.)
The only potential hole I see is that the timetable is left open. So if both a division head and the chief executive were opposed, or if the chief executive didn't push subordinates who dragged their feet, the timetable could slip out indefinitely.
But it's appropriate to leave the timetable to the executive, rather than to try to micro-manage from the legislature. Execution is the executive's job. And I'd bet the chief executive is also in favor of this, or at least willing to go along with the will of the legislature. So I'd leave it as it is for now and revisit it in a few years to see how the conversion is coming.
If you're really concerned that something might fall through the cracks you might have the executive branch report every few years on the progress of the conversion, including a list of what hasn't been converted and why. After five or ten years if there's anything unconverted that the legislature hasn't been convinced SHOULDN'T be converted, then it might want to make changes to the law to give them a push.
(And I'd leave military systems up to the executive branch. Which I expect will insist on having source code for everything they commission, and on reverse-engineering any turnkey weapons systems they got from their allies. B-) )
Now we have the force of the state we no longer have to make strong opinions for Free Software! Yah! Now we can all just answer the question "Why should I use Free Software?" with "Because it's the law!" (well those of us in Argentina, anyway)
You either didn't read the law or you misunderstood it.
The law doesn't say ANYTHING about whether the citizens and/or non-government-owned corporations of Argentina will use closed or "free" software.
This is just how the government of Argentina decides that the government of Argentina will use free software.
The government and the corporations it controls WILL use free software, with details, timetables, and exceptions fleshed out by the exectutive branch.
The government RECOMMENDS to its semi-autonomous units (such as universities) that they use free software.
The government places no requirements on the rest of the country at all.
I totally agree. Run the government's IT operations on open and free software, recommend it to the autonomous government-related functions, and let the private sector - individual and corporate - make its own choices (and continue to abide by existing contracts).
Although I fully support Linux and the free software movement, I disagree with this law for one major reason: the best product cannot always be used. If a commercial product does the job better, it will end up costing more to use the "free" software.
But here I disagree strongly.
You're measuring only the immediate cost. There are additional long-term costs. Costs like:
lack of support,
future higher costs ("the first rev is free"),
lack of interoperability with other departments' or citizens' applicaions,
secondary monopolies (i.e. the citizens have to buy the expensive product or agree to a company's license to perform interactions, some mandatory, with their government's databases and functions),
use of such secondary monopolies to create further monopolies, expanding the lockin
I could go on.
The point is it might be a cheaper and more efficient solution to one immediate problem. But closing in the data with a proprietary application costs much more than any immediate monitary savings.
Actually, the behavior he is describing is what is actually implemented in most cases.
:: scope-resolution operator.
During the base class constructor, the virtual function table pointer is initialized to point to the base class table, thus when the user written ctor code is called any virtual function ref will be to the base class ctor.
When the next level of inheritance's ctor is called, the VTPTR will be initialized to the derived class VTBL, and so any virtual will go to the virtual class.
During destruction, the process is reversed.
All that is needed is to formalize this behavior.
Close.
First: Though the usual implementation is via a vtable pointer, the spec speaks in terms of what virtual function is entered, rather than in terms of when the vtable pointer is stored, so that compilers are not constrained to use a vtable implementation.
Second: The current spec defines the behavior of calls during the constructors and destructors of the classes, but leaves open the behavior during the construction and destruction, and other initialization if any, of the member objects.
In terms of "storing a vtable pointer" the current standards allow the compiler to store the derived-class vtable pointer either before or after the member object constructors are called and/or other member initialization is done (or even at some arbitrary point during such initialization). I claim it should be tightly specified to be stored AFTER all other initialization (including any other automaticly-generated code) and immediately BEFORE the execution of the first line of the body of the constructor.
Similarly, it allows the base-class vtable pointer to be stored before the member DEstructors are called, after, or during. I claim it should be stored immediately AFTER the execution of the last line of the body of the destructor, BEFORE any member destruction or other automatically-generated code.
In the general form, the reasoning is as follows:
Member constructors (and other member initialization) are peers with base class constructors: They constitute the creation of pieces of the object, which are to be finished parts before the object is constructed from them. First they are constructed and initialzed. Once that is done the class' own constructor assembles them inito a composite object and initializes that composite object.
Until the pieces of the object are completed the object is just a collection of pieces. It is only during the execution of the body of the constructor that the collection progresses from a pile of parts to a unified, operational, component.
So calling the derived-class overriding of a virtual function before the derived-class constructor is executing is a mistake. It calls a function of an object that does not yet exist, rather than the corresponding function of the component piece, which DOES exist and IS initialized.
During the execution of the constructor, the author of the derived class can take whatever care is necessary to use only the features of the object whose underpinnings are properly initialized. While the member objects are being constructed the author of the derived class has no such opportunity.
On destruction the issues are similar. While the derived-class has had a chance to initialize, some of the underpinnings for the virtual functions may need to be torn down on finzliation. Calling a virtual function after its support structure is torn down is also an error.
Writing a code generator to store the vtable pointer at the proper moment during construction is trivial. Writing one to store it at the proper moment on destruction is slightly harder: The base class and derived class might be separately compiled, so either the base class must export its vtable pointer for the derived class destructor to store or the derived class must generate its own equivalent vtable.
My definiton means that virtual function calls in initialization expressions get the base-class overriding. But that's not a problem for two reasons: It's currently not specified, and the author can specify the overriding he wants by using the
Now, there is a problem related to this that I'd like to see addressed:
Consider a base class which exists to allow an object to attach to a list and have a virtual method called in response to events sent to that list. It is up to the derived class to overload a virtual function to handle those events.
This is exactly one of the reasons we wanted this definiton.
Now, ideally I'd like the base class to connect to the list in the ctor, and disconnect in the dtor. However, it is not safe to connect to the list until the object is fully constructed, as an asynchronous event may cause the virtual method to be called before the object is constructed. Equally, I want the object off the list before the dtor is called for the same reason.
What I'd like to have would be an additional two methods. The first would be called immediately after the ctor, the second immediately before the dtor. Thus, these calls have at their disposal the whole, fully constructed object, with all virtual methods intact and ready to go.
In the case of global objects or static objects, the compiler would generate a second list of function calls, to be called after the init code has iterated through all the static constructors (and another to be called before iterating over all static destructors).
With the definition I'm proposing you have a solution available, and it doesn't require two overridings of the function. Consider:
First: Create a construction-progress member variable, and initialize it to the "no progress yet" state. This variable is thus initialized before the vtable pointer is changed, and it will persist after destruction.
Second: The vtable pointer is changed - but any of your virtual functions that need construction that isn't complete can check the state variable, and do what is appropriate for the current level of construction. (This is probably making a call to the base-class version of the function and returning the restut.)
Third: As construction progresses through stages that enable various virtual member function behavior, the constructor updates the state variable, "turning on" the fully-constructed behavior, or any intermediate-step behavior, as necessary.
By the time the object is fully-constructed and the constructor exits, the full behavior of the member functions is manefest. The teardown sequence proceeds similarly, but in reverse.
If you like you can implement the "state variable" as a set of "pointer-to-function" variables, to eliminate the explicit tests at the start of the member functions. The "real" virtual member function would be something like:
foo(args) { return (*this->current_foo)(args) }
It's not quite as execution-time efficient as your double vtable pointer store, but it gives you arbitrarily fine control without extra compiler mechanism.
Having done a fair bit of multithreaded C++, I am of the opinion that, if they are going to standardize on a threading library, they are going to need this sort of hook.
Check.
Though originally intended to handle non-multithreaded cases (such as the non-polically-correct examples of garbage collector pointer-walks and error-exceptions during construction), this scheme is also adequate to support correct behavior in multithreaded code.
Suppose:
you are constructing an instance of a derived class
one of its base classes has "published" a pointer to the partially-constructed instance
the class has a virtual member funciton
the member function is overridden by this class
the class also has a member variable of a class type with construction
the constructor of the member variable (or something it calls) finds the published pointer and calls the virtual member function.
What happens?
My claim is that such a call SHOULD be legal and SHOULD call the BASE CLASS version of the member function. Similarly, during the execution of the DEsctuctors of the member variables you should also get the BASE CLASS version of the member function. You should get the derived class version exactly from the beginning of the execution of the first line of the body of the constructor through the end of the execution of the last line of the body of the desctuctor.
The reasoning is too involved to go into here. Suffice it to say that:
It's a consistent generalization of the philosophy of the C++ constructon-destructon semantics (and of the way that the C++ semantics differs from those of Objective C and Smalltalk.)
It's an compiler implementation that is allowed by all the levels of C++ standardization.
There's a LOT of neat stuff you can do with this guarantee that you can't do without it.
There are a lot more opportunities for programming error if your compiler doesn't work this way. (Not to mention the issue of code that works find with a compiler that does it one way but breaks when run through a compiler that does it a different way.)
The original C++ work didn't specify the behavior in question. The first ANSI standard explicitly left it open. The revised ANSI standard not only explicitly left it open but said "don't do that". B-(
At the time I first proposed it (about 10 years ago) we looked into a sample of the compilers on the market. There are four binary combinations of member constructor/destructor and base/derived version of member function, of which I claim one is "right" and the other three "wrong":
Cfront and the Cfront-derived C++ compilers tested (Sun, SGI) got it "wrong" one way.
The three IBM PC compilers tested got it "wrong" a second way.
Gnu G++ got it "wrong" the third way.
so standardizing on this semantics wouldn't favor any particular vendor's existing product.
IMHO this somewhat obscure issue is one of the major impediments to C++ achieving its potential as an object-oriented language, and it is unfortunate that is wasn't "fixed" in one of the previous standards.
Perhaps there's one more chance here.
Three reasons:
Mineral oil has a much lower specific heat than water. You need to circulate a lot more of it to get a given degree of cooling.
Mineral oil is flammable.
Mineral oil is a very good solvent. Goodbye to any plastic parts. (And to your rug if you spill any. And imagine the effect on the building.)
The Cray II was cooled with a clear liquid - a fluorocarbon, I think. They also had a debubbling gadget in the room near the computer. Looked like an enclosed fountain made of plexiglass. Very artsy. The two Cray IIs I saw had very distinct fountains, which made me wonder if they were distinct artworks - at least at first.
Couldn't this technology be used just as easily to scan the ascii character at the cursor and render it in brail, litterally at the person's fingertips?
Yes it could. Great idea. (I moderated you up with an "insightful" but made a comment elsewhere later and slashdot undid it. Sorry 'bout that.)
With the browser "hotwired" for the touchy-mouse the text would be directly available to the braile converter. Braile would be more readable using the mouse+pin-pad than images of text, and the motion would approximate that of normal braile reading so it would be very easy to learn.
For example, have the affected person wear a video camera on their head [helmet cam?]. The blind person could carry a higher resolution "pad" with maybe 640x480 pins representing the image from the camera. People could use their hands to "see" whatever the camera is pointing at. I might suggest a hands free device, such as one which can be strapped to a person's back, but I don't think there are proper nerves there to sense a high-resolution image.
In fact exactly this was tried in a lab, and worked like a charm. There are adequate nerves in the back - you just have to move the pins farther apart. (Although the resolution may be low enough that you can only do a very narrow image... The test setup only used a small number of vibrating pins. This was quite some time ago, when the equipment was big, custom, and expensive.)
An experimental accident gave an interesting insight into the rewiring abilities of the brain. The camera was on a tripod, and during one of the experiments it tipped over and fell into what it was viewing. The experimental subject, blind from birth, reflexively put his hands in front of his eyes.
That's a very strong indication that the signals from the back had been re-routed into the pathways normally used to process images, implying all that specialized neruoprocessing will be available for even the blind-from-birth to use on images converted to touch. Imagine blind baseball players, or blind drivers as safe as the run-of-the-mill driver.
Afterward the subject commented that for the first time in his life he had a referrent for the word "looming".
Try this instead:
Click on the link. You get the "I'm sorry..." page. Then:
Put your cursor on the location bar (which still has the URL of the image) and hit carriage return.
That tries again. But it reports the previous page as being the "I'm sorry" at the same URL, which is on their server. Thus the server thinks you're coming in from a self-link on the same page. B-)
(At least it worked for me when I tried it. I'd debug it but I'd have to flush my chache at this point - Netscape wants to serve me my local copy.)
Nice looking box.
Just because something is very good at one job (server) doesn't mean it's unsuitable for another (workstation).
BSD is a desktop OS and has been since there were desktop-sized machines that could run it. The same is true of any "server" OS that can drive a display/keyboard combination while living in a small box that is built in or nearby.
Think about it: A "server" is just a system with enough resources to handle MANY users, of the sort that once required a box too big to lug around without a fleet of trucks.
Now a [foo] server (file server, terminal server, etc.) is another matter. That's a system that has enough of one kind of resource to handle more than one user, but not necessarily all the kinds of resources you need to support a desktop. But BSD is not a [foo] server. It's a generic operating system that provides all the resources you need.
But that just pushes the question further back. What is the "value" of the industrial uses? A lot, if somebody wants to run such an industry or use its products, zero if not.
"Value" is a strictly subjective labeling. The only objective measures we have of something's value are:
what someone will trade to obtain it
what someone will accept in return for giving it up
what someone will expend to defend it against loss or confiscation
And all three measures are distorted. (For instance: the third is distorted by the additional subjective negative value of having been ripped off and the positive subjective value of having successfully defended against an attack.)
Are raw potatoes really poisonous?!? I eat them all the time!!!!
It's the rest of the plant that's toxic, at least most of the time. Don't eat a potato that's sprouting or getting a green layer beneath the skin. (You may not become obviously ill with just a green layer, but it's not advisable anyhow.)
That's one reason a potato is such a useful plant: It kills off most insects that try to eat it. (Unfortunately there are other organisms that attack it, and since potatoes are reproduced mainly by cloning they have little diversity. That's why a blight led to the Irish Potato Famine.)
I hear the toxin involved is not broken down by cooking temperatures.
Terminator never came out. Monsanto got too much flack for even considering it.
But cytoplasmic sterile hybrid corn was a BIG thing for years. It had the same effect: The seed companies kept the lines that could reproduce to themselves and made "mule" crosses that couldn't reproduce to sell as seed to the farmers.
(It wasn't JUST a scam to keep selling seeds. The hybrid didn't regrow as a weed the next year, when farmers practicing crop rotation switched to another crop to keep the field fertile.)
That largely ended when a corn blight came through in the early '70s. Seems the line that was crossed-in to make the seeds sterile also carried susceptability to the blight - and almost all the corn was wiped out that year.
They were really worried about the next year, too, because the companies couldn't come up with enough seeds from other lines to supply all the farmers in one year, so there was a lot of the susceptable stuff out there. (Fortunately the blight infestation was minor and well contained the next year.)