That was posted last Friday. I suspect a lot of people didn't see it because slashdot had recently changed to the new format that is virtually unreadable on older browsers - or even recent Firefox versions.
I notice that things are substantially better today, at least for the older firefox 2.0.0.8. Maybe they got fixed up enough that more people will see this posting.
Even if you have a dial-up modem, what are you going to connect to?
One of my modems is set up for dialup backup to the broadband connection - which wouldn't be particularly useful in this crisis. But I have others.
I also have a UUCP connection to another old networking curmudgeon who keeps old-style mail and netnews running. (I hear these are useful for people in countries where some people don't have broadband, always-on, or even fast dialup, Internet connections.)
At the moment I have my MX records pointed to send incoming mail to his servers, where much of the spam is filtered out and the rest is stored until my own MTA machine polls for it, which it does twice an hour.
My UUCP daemon can hit him over the Internet, which it does by preference. But when something is wrong with that (like my ISPs servers being hosed) UUCP falls back on dialup. One of my modems (dedicated mostly to this) grabs the FAX line and does things the old fashioned way.
I have in the past set up my portable computers to also exchange mail with my home mail server this way - though these days I usually bring up a dialup or WiFi Internet connection and SSH to the desktop, reading the mail there.
At the moment I don't have any Netnews groups set up. But I could arrange for a feed of a small one, or set, perhaps an alt. group that had been quickly set up specifically to handle news on whatever government blockage was in progress. Netnews runs on a flooding protocol and includes big name networking sites that have open web hosting, which (when located in a "safe for net" place) can bridge it to the rest of the world.
Periodically polled UUCP didn't stop working, or even get fully retired, when most of the traffic moved over to the big-I Internet, with its direct server/client connections and one- or two-hop email handoffs. If the government in the affected area didn't manage to totally cut off ordinary phone calls, UUCP carrying netnews and email could be set up quickly. Netnews' flooding protocool would insure that the news made it out within a few hours if there was a way for it to get out. Email might need explicit route addressing (like the bang-ist system) at first, due to the security and technical issues of setting up automated routing. And you can forget about video - you'd be lucky to be able to squeeze an occasional still picture through the bandwidth bottlenecks.
But it's not something where we need to invent a new wheel. The old ones just need to be remounted and regreased.
I'm using firefox 2.0.0.8 at work. (Not under my control.)
The floating title bar obscures the left side of the window and I can't get it to go away. I can't read my own configuration page, let alone tweak it if there WERE some way to switch back to "classic" (which I DID have selected to avoid the LAST redesign.)
This is unusable. (I'm largely poking in the dark to post this comment.)
Geez, guys. Don't you at least TRY, ONCE, to view your revisions with older browsers before going live?
Vision scientist here... sorry to have to disagree with you, but actually they are linked... mostly for very near objects though, so the problems mentioned would be worst for handheld video games like the 3DS.
And virtually unnoticeable for images that don't attempt to get within about twice arm's length.
Also: For people of middle age and beyond, presbyopia drastically limits the ability of the eye to change focus depth. Older people would probably find the images very easy to view. Better than holography, in fact, because they'd stay in focus at all "distances" while a holograph would require the viewers to adjust focus when they can't. B-)
I didn't say to call me when they calculate they could do that.
Call me when there's actually a box somewhere, unconnected to a power supply, where you can feed in water or metal or whatever, and get out power.
The engineering of the remainder of a system (heat engine + generator) is sufficiently well understood (for well over a century) that I wouldn't require them to actually construct it to be convinced that they had a real device (or a VERY good fake). I'd be happy if the basic demo of a core heat generator could be run at the rated power and input long enough, with honest instruments, to demo that it's really doing something beyond oddball chemistry and would run long enough to more than pay for its construction.
If you won't be convinced unless somebody actually builds the closed-box system that's a mesaure of your personal standards of proof, trust in the instrumentation, or understanding of heat-engine physics.
"Advanced magic IS indistinguishable from a rigged demo."
On the other hand, any thermal leak is a very big energy loss. You're running a heater and throwing away heat on "charging", a cooler and then absorbing heat into the cooled gas on "discharging".
This is why compressed air is a rotten energy storage and transport medium. (In factories, however, it IS used as an energy transport medium because the inefficiency is offset by various design advantages in the devices it powers - typically linear actuators, large clutches on stamping presses, compact refrigeration and air cooling (using vortex/swirl tube refrigerators and vortex entrainment air pumps), and light but powerful hand tools.)
Of course, the better way to go about this would perhaps have been to send detailed plans and experimental records to colleagues at other universities and ask that they try to replicate it.
Then if it DOES work:
- the physicists work out the mechanism
- their competitors work out a better design
- and their business plan is toast.
If they were just scientists trying to get their names recognized and grants and tenure this would be fine. But they claim they've got a marketable product, they apparently don't understand the physics of it well enough to be sure there isn't some variation that's orders of magnitude more competitive, and the patent offices won't grant them patent protection until after the physics is worked out (and even then it wouldn't cover later improvements or unrelated designs by others).
So don't hold your breath waiting for them to destroy their own business by leaking the trade secrets to satisfy academics' curiosity. If they really DO have something and DO ship it, the market will likely reward them. Then the physicists will have the hints needed to work out the physical processes behind it eventually.
And if it's all just a scam the device will never be deployed and we can all continue hunting for something that DOES work.
Call me when they can attach a generator to it, hook the output up to the input, and keep it running by just putting in cold water and getting steam.
For the mode they claim to be demoing and intending to ship as the first model, there's enough heat at a high enough temperature that you could use considerably less than all of it to drive a heat engine and generator to get the excitation.
They also claim they can run it both much hotter and/or in a mode where the run-time excitation requirements are absent - but that they're demoing it and promising first product in this mode because it's easier to keep it under control and safe, while still beating the economics of an electrically-powered heat pump by a factor of several.
Call me when it's repeatable in more than 2 other labs please.
Unlikely any time soon (even assuming it works just fine).
They applied for a patent. The Italian patent office demanded that they provide a scientific theory to support their claimed mechanism before they'd consider granting the patent (rather than just patenting the design and claims).
To get scientists to reproduce it in the lab and (if it works) come up with a plausible theory, they'd have to disclose all the engineering (including all the ingredients of the "secret sauce"), without patent protection. And the scientists will not be interested unless they can in turn publish them with their own results. So if it does work the whole world will be racing them to market with their own design but without their development and research costs.
So (they say) they're keeping their process a trade secret - to the point of shutting it down when one of the observing scientists, in violation of the agreement, switched his gamma detector from count to energy-histogram mode (which would have given him details on what was going on inside the device.)
So maybe they're crooks. Or maybe they're just some engineers who got it to work repeatably and practically without a full and correct model of the physics. But don't hold your breath waiting for somebody in a couple labs to come out with a replication. That seems unlikely unless/until some physicists reinvent it.
And with the dominant paradigm, after the original cold fusion flap, being that "there's nothing behind the curtain", efforts on reproduction will likely be few and underfunded unless/until they DO ship a working product.
Just have 'em write options for 1/10th% of the company per person with an exercise strike cost of about %5,000 to $6,000. And serve nutritious munchies (not salt-crunchies and pop) all day and a dinner buffet on the company dime every evening - with no OBLIGATION to stay after.
Then they're in startup mode and most of the engineers will voluntarily stay for an extra 2 to 4 hours per day.
(The food is especially cheap compared to hiring enough extra employees to work the extra hours, plus the still more extra hours and extra management needed for the communication inefficiency with a bigger work force.)
But expect 'em to work that much time on a startup without options? I laugh. You can get away with it in an established company with an exceptional benefits package. But the people who would stay at a startup for that long without a cut of the pie are the ones who couldn't get a position with a startup that would cut them in.
In the garbage collection case, either 1. The parent should not have been hooked to garbage collection before its members were contstructed
That gives you the class-hierarchy doubling I described earlier. The "be collectible" flag has to be cleared by the final level of class derivation, which can not have further classes derived from it. This breaks the class paradigm by requiring you to distinguish leaf classes that can exist from their immediate all-but-collectible precursors which can be further modified.
or 2. Garbage collection should be suppressed during a constructor
Out of memory. Crash! Also all the leaf/stem problems if 1.
They both break the class paradigm another way: The garbage collectible behavior is supposed to be INHERITABLE. So it should all be encapsulated in the base class. Why are you forcing it to be moved to a derived level which has NOTHING TO DO with this behavior, just to work around an issue with the compiler's code generator?
In the exception case, a constructor that is going to throw has the responsibility of cleaning up its members before it throws. When a constructor throws, the destructor is not run. If a constructor fails and exceptions aren't available, it should still clean up its members and set a flag to let the destructor know not to do anything.
The problem is not the constructor throwing. Constructors know what they're constructing and can handle it.
The problem is a member constructor throwing. Does it have to understand everything that might contain it (including things that were written years later by a different team)? How can it do that? How can it do that without breaking the entire point of the encapsulation information-hiding paradigm?
What happens if something called by something called by something... called by a member constructor throws. Now everything that throws has to understand how to unwind every layer between it and the object that catches.
If the promotion of the object occurs in the way I described as "correct" it's trivial to solve both these problems - and others - through the activation of the appropriate levels of the virtual member functions. If it happens otherwise they aren't readily soluble - and either aren't solved at all or aren't solved in a practical way by your suggestions.
This is a circular dependency that will never make logical sense...
This is SO not true. I'll give you some examples in a bit.
If you find yourself needing to do this, there should be a way to renormalize your object model so that the member objects are not dependent on (or even aware of) the existence of the thing they are destined to be members of (at least until all the parties involved have completed their constructors, but preferably maintaining orthogonality through the entire life cycle)
Again not true. The issue is not that the members have an awareness of the eventual object. The issue is that the base class EXPORTS knowledge of and access to common behavior of all classes derived from the base class but the details of which vary depending on which derived class is in question. The promotion of the instance to the derived class "switches on" the details of the behavior - but if this occurs, and is invoked, before the derived class is able to initialize the underpinnings of the behavior, things break.
One example from the project: Garbage collection via a mark-and-sweep algorithm:
- All heap-allocated objects subject to garbage collection are members of classes derived from a base class ("Heaper") whose constructor hooks the objects into a list of all allocated Heapers and whose destructor unhooks it.
- The virtual function in question is the mark-yourself part of the pointer-following marker. (Its guts are generated by a preprocessor that parsed the class declaration.) In a Heaper-derived class it knows about the pointers to other Heaper-class objects at its level. It calls the baseward version of itself and if it returns TRUE calls the mark-yourself functions of all the objects pointed-to at its level. At Heaper itself the function marks the object itself and returns TRUE if it was unmarked.
- When garbage collection is invoked the Heapers are all unmarked. The collector first calls the mark-yourself functions pointed to by "smartpointers" that constitute the data-structure roots, then walks the list of Heapers, freeing the unmarked and unmarking the marked.
The problem arises because constructors of member objects of the derived class may cause memory allocation (either temporary or permanent) and this may invoke the garbage collector. If the class has already been promoted to the derived type (i.e. if calling its mark-yourself virtual function gets the derived class version) the garbage collector will try to follow the derived class pointers - which may not be initialized yet. Oops!
Another case: Exception handling. (This project was running before "catch" and "throw" were more than reserved words.) The similar problem occurs because destructors are such a virtual function. If an exception is thrown from a member object and the class under construction was promoted too soon, you end up running the destructor of the derived class before the constructor was run, again while some or all of the member variables are uninitialized.
These are two concrete examples from the project. The general case is "promoting/demoting at the 'wrong' stage runs behavior whose underpinnings are not constructed or already destructed". For instance: Hooking a display object into a display list that's interpreted by a periodic process running in another thread. If it's time to display while the object is under construction or destruction, and the promotion/demotion timing was "wrong", the display processing manger invokes services whose infrastructure are not yet constructed or already destructed.
With "correct" timing of promotion/demotion you can have an object that is always consistent, even if only partially formed. (Constructors and destructors, for instance, can have "stage of construction" member variable(s) that modulate(s) the behavior of other member functions depending on whether their underpinnings are ready, and this can be initialized to "nothing ready" before the object is promoted a
When:
- a base class has a virtual member function
- the base class exposes its "this" pointer externally (for instance: by linking itself into a list)
- a derived class overrides the virtual member function
- the derived class of the base class has members of object type that have constricution and/or has calls to external functions in member initializers
- the construction or other initialization of the derived class members BEFORE executing the body of the derived class constructor calls the virtual function. what version (base, derived, something breaks) of the function is executed?
Similarly for destructors.
IMHO the specification should REQUIRE that the BASE class version of the virtual function is the one that is executed at any stage prior to the execution of the first line of the body of the constructor and after the execution of the last line of the body of the destructor, while the DERIVED class version is executed during the execution of the body of the constructor, destructor, and at all times between them.
This was "broken" in 1985ish, when a project I was associated with tried to use C++ as its language. (Treating the constructor and destructor cases separately gives you four binary combinations of behavior of which one is "right" and three are "wrong". Cfront and cfront-derived compilers got it "wrong" one way, three C++ compilers available on IBM PCs got it "wrong" a second way, and gcc got it "wrong" the third way.
I tried in both ANSI standardization processes to get it "fixed", i.e. defined as I suggest above. I was rebuffed both times. It was declared explicitly undefined behavior in the first ANSI C++ standard and "don't do it" in the second.
Question: Has it been fixed, or even defined, YET?
This is NOT an academic issue. C++ (unlike, for instance, Smalltalk and Objective C) has construction semantics that promote and demote the behavior of objects of derived classes in a way that keeps the debugging of unchanged parts of base classes intact when modifications are derived from them, which is one of the things that makes C++ code more robust. And its ability for classes to have members of object type has potential to greatly reduce memory management overhead compared to webs of heap-allocated pieces in the Smalltalk style.
But this oversight in the specification of behavior on construction and destruction forced that project to the web-of-little-heap-things style regardless, and also has the potential to sucker the programmer into creating extraordinarily subtle bugs.
So didja fix it, guys? PLEASE tell me you fixed it!
If electrical discharges in a thunderstorm can concentrate energy enough to create gammas energetic enough to create electron-positron pairs (2 x 511 keV), I'd expect that (given the large concentrations of hydrogen in the cloud's water) they can also produce initiation energy for nontrivial amounts of nuclear fusion. (D D or D T at about 15 keV or P B at about 123 keV.) These reactions produce tens of MeV of output energy, some of which could appear as the gammas that produce electron-positron pairs.
It would be interesting to look for the signatures of that. Especially given that the mechanism of the dense plasma focus is a plasma instability that I'd expect to be sometimes produced in a free-air electrical discharge such as a lightning bolt or sprite.
Does this process potentially make the world more massive, in creating particle pairs - one of which escapes into space?
Nope. Makes the planet lighter by the amount of mass + (kinetic energy / csquared) that escaped.
That's because the energy that created them came from the Earth, where it had been for a while (even if it had previously come from sunlight rather than geothermal or combustion sources) and the energy itself - either as energy or as the difference of mass between two forms (before and after) of matter that liberated it - had mass itself.
Also: Traffic management (without push-out) plus RED won't cover shorter-than turn-around burst-and-die traffic sessions or long-lived flows using protocols that don't respond to packet drops as a congestion signal. That covers TCP start-up-and-die transactions (like a lot of web requests), UDP - either burst or without alternative added-on flow control, and a bunch of other stuff.
Also: Some web sites have, for a while, been "cheating" by breaking images up into separate tiles that fit into the start-up burst, so the browser launches a bunch of simultaneous requests.
Oops. Should have read your reference before replying. I missed that you were talking about weighted fair queueing "with longest queue pushout" and it had already taken RED into account.
Sorry, but what I said (RED is half the solution) still stands, for a different reason. While you might get Motorola's proposal to work at the edge, the backbone will not have the memory to identify ALL the flows and compare them - or the knowledge of what share each flow SHOULD have, without extra turnarounds to propagte it. Meanwhile it's pathetically easy for an application that wants to "cheat" to create multiple flows - both getting multiple "shares" of the division and exploding the per-flow storage and balancing computation requirements for a solution like Motorola proposes.
There's nothing inherently wrong with big in-transit buffers for TCP streams. The real question is not which packets get dropped; it's which packets get sent next. That's what "fair queuing" and some other quality of service algorithms are about.
Sorry, fair queueing is only half the solution, and if the boxes in the middle are too dumb to apply the other half of the solution, increasing the buffer sizes just increases the latency, because packets don't get dropped (signaling TCP to slow down) until the bigger buffers are full.
The basic solution to the other half is called RED (Random Early Detection/Discard/Drop), was published in 1993. One version is in a 1998 RFC (2309), and variations of it are already requirements for and implemented in the backbone and edge routers throughout the Internet.
(It may not be as widely known and deployed "off the edge" due to the limited number of queues on those machines. Nice to see that broader attention is now being given to the problem, so that open source and home router coders will implement it there, as well, when it is appropriate.)
Trick is to keep running averages of the buffer depths and use them to randomly drop a few packets when they start to grow, more as they get deeper. This signals TCP to throttle back. Dropping randomly sends the throttle-back signal fairly to all the TCP flows. The drop probability has to be very low and the time constant of the decay of the average has to be comparable to the round-trip time of the links to prevent some bad pathologies, like excessive throttle-back or synchronization of the throttling of many streams, creating an oscillation that alternates between underutilization and excessive dropping.
Do it right and your queues stay just full enough to smooth out and fully utilize your outgoing bandwidth, drastically reducing latency and leaving most of the buffer memory available to catch and handle bursts. Yet your average drop rate is no higher than if you let the queues expand until the buffers overflowed and the bandwidth is fairly distributed.
So you've been fighting for freedom of speech, equality and all those otherwise noble causes. But now you question jokes made about those very concepts?
He's welcome to continue to make them. I just wanted him to be aware of what he was doing.
"Letting other people do things you don't like is the price of freedom." - M. McClary
I must have missed those large tracts of American history 101, where they told us about the war to free the Rednecks, the Jim-Bob Crow laws, and the Redneck-only drinking fountains....
As Artifakt points out in a sibling posting to yours, look into the early days of labor unions - when machineguns were considered a necessary tool of labor relations.
The referenced article might be read to imply more attraction to those more closely related and no limit on how closely (if they were first encountered when adult, thus avoiding the Westermarck effect). But it doesn't seem have any information or references to falsify an assertion that sexual attractiveness peaks at third cousin level. Neither does it give any quantitative comparison of attractiveness versus different levels of consanguinity.
Is there perhaps something in one of the references? If so, which one?
Cut my "hacker's teeth" on some computers that were located in a WW II era bomber-plant hangar. (Built mostly of wood because the steel was being used for war machines.)
Place had issues with mice and rats getting under the raised floor and chewing on the cabling.
Slashdot Mirror
That was posted last Friday. I suspect a lot of people didn't see it because slashdot had recently changed to the new format that is virtually unreadable on older browsers - or even recent Firefox versions.
I notice that things are substantially better today, at least for the older firefox 2.0.0.8. Maybe they got fixed up enough that more people will see this posting.
Even if you have a dial-up modem, what are you going to connect to?
One of my modems is set up for dialup backup to the broadband connection - which wouldn't be particularly useful in this crisis. But I have others.
I also have a UUCP connection to another old networking curmudgeon who keeps old-style mail and netnews running. (I hear these are useful for people in countries where some people don't have broadband, always-on, or even fast dialup, Internet connections.)
At the moment I have my MX records pointed to send incoming mail to his servers, where much of the spam is filtered out and the rest is stored until my own MTA machine polls for it, which it does twice an hour.
My UUCP daemon can hit him over the Internet, which it does by preference. But when something is wrong with that (like my ISPs servers being hosed) UUCP falls back on dialup. One of my modems (dedicated mostly to this) grabs the FAX line and does things the old fashioned way.
I have in the past set up my portable computers to also exchange mail with my home mail server this way - though these days I usually bring up a dialup or WiFi Internet connection and SSH to the desktop, reading the mail there.
At the moment I don't have any Netnews groups set up. But I could arrange for a feed of a small one, or set, perhaps an alt. group that had been quickly set up specifically to handle news on whatever government blockage was in progress. Netnews runs on a flooding protocol and includes big name networking sites that have open web hosting, which (when located in a "safe for net" place) can bridge it to the rest of the world.
Periodically polled UUCP didn't stop working, or even get fully retired, when most of the traffic moved over to the big-I Internet, with its direct server/client connections and one- or two-hop email handoffs. If the government in the affected area didn't manage to totally cut off ordinary phone calls, UUCP carrying netnews and email could be set up quickly. Netnews' flooding protocool would insure that the news made it out within a few hours if there was a way for it to get out. Email might need explicit route addressing (like the bang-ist system) at first, due to the security and technical issues of setting up automated routing. And you can forget about video - you'd be lucky to be able to squeeze an occasional still picture through the bandwidth bottlenecks.
But it's not something where we need to invent a new wheel. The old ones just need to be remounted and regreased.
I'm using firefox 2.0.0.8 at work. (Not under my control.)
The floating title bar obscures the left side of the window and I can't get it to go away. I can't read my own configuration page, let alone tweak it if there WERE some way to switch back to "classic" (which I DID have selected to avoid the LAST redesign.)
This is unusable. (I'm largely poking in the dark to post this comment.)
Geez, guys. Don't you at least TRY, ONCE, to view your revisions with older browsers before going live?
Because the email spammers found other, more profitable and efficient methods to spread advertising onto the web?
You mean it WASN'T because of snipers?
Darn!
Vision scientist here ... sorry to have to disagree with you, but actually they are linked ... mostly for very near objects though, so the problems mentioned would be worst for handheld video games like the 3DS.
And virtually unnoticeable for images that don't attempt to get within about twice arm's length.
Also: For people of middle age and beyond, presbyopia drastically limits the ability of the eye to change focus depth. Older people would probably find the images very easy to view. Better than holography, in fact, because they'd stay in focus at all "distances" while a holograph would require the viewers to adjust focus when they can't. B-)
I didn't say to call me when they calculate they could do that.
Call me when there's actually a box somewhere, unconnected to a power supply, where you can feed in water or metal or whatever, and get out power.
The engineering of the remainder of a system (heat engine + generator) is sufficiently well understood (for well over a century) that I wouldn't require them to actually construct it to be convinced that they had a real device (or a VERY good fake). I'd be happy if the basic demo of a core heat generator could be run at the rated power and input long enough, with honest instruments, to demo that it's really doing something beyond oddball chemistry and would run long enough to more than pay for its construction.
If you won't be convinced unless somebody actually builds the closed-box system that's a mesaure of your personal standards of proof, trust in the instrumentation, or understanding of heat-engine physics.
"Advanced magic IS indistinguishable from a rigged demo."
On the other hand, any thermal leak is a very big energy loss. You're running a heater and throwing away heat on "charging", a cooler and then absorbing heat into the cooled gas on "discharging".
This is why compressed air is a rotten energy storage and transport medium. (In factories, however, it IS used as an energy transport medium because the inefficiency is offset by various design advantages in the devices it powers - typically linear actuators, large clutches on stamping presses, compact refrigeration and air cooling (using vortex/swirl tube refrigerators and vortex entrainment air pumps), and light but powerful hand tools.)
Of course, the better way to go about this would perhaps have been to send detailed plans and experimental records to colleagues at other universities and ask that they try to replicate it.
Then if it DOES work:
- the physicists work out the mechanism
- their competitors work out a better design
- and their business plan is toast.
If they were just scientists trying to get their names recognized and grants and tenure this would be fine. But they claim they've got a marketable product, they apparently don't understand the physics of it well enough to be sure there isn't some variation that's orders of magnitude more competitive, and the patent offices won't grant them patent protection until after the physics is worked out (and even then it wouldn't cover later improvements or unrelated designs by others).
So don't hold your breath waiting for them to destroy their own business by leaking the trade secrets to satisfy academics' curiosity. If they really DO have something and DO ship it, the market will likely reward them. Then the physicists will have the hints needed to work out the physical processes behind it eventually.
And if it's all just a scam the device will never be deployed and we can all continue hunting for something that DOES work.
Call me when they can attach a generator to it, hook the output up to the input, and keep it running by just putting in cold water and getting steam.
For the mode they claim to be demoing and intending to ship as the first model, there's enough heat at a high enough temperature that you could use considerably less than all of it to drive a heat engine and generator to get the excitation.
They also claim they can run it both much hotter and/or in a mode where the run-time excitation requirements are absent - but that they're demoing it and promising first product in this mode because it's easier to keep it under control and safe, while still beating the economics of an electrically-powered heat pump by a factor of several.
Call me when it's repeatable in more than 2 other labs please.
Unlikely any time soon (even assuming it works just fine).
They applied for a patent. The Italian patent office demanded that they provide a scientific theory to support their claimed mechanism before they'd consider granting the patent (rather than just patenting the design and claims).
To get scientists to reproduce it in the lab and (if it works) come up with a plausible theory, they'd have to disclose all the engineering (including all the ingredients of the "secret sauce"), without patent protection. And the scientists will not be interested unless they can in turn publish them with their own results. So if it does work the whole world will be racing them to market with their own design but without their development and research costs.
So (they say) they're keeping their process a trade secret - to the point of shutting it down when one of the observing scientists, in violation of the agreement, switched his gamma detector from count to energy-histogram mode (which would have given him details on what was going on inside the device.)
So maybe they're crooks. Or maybe they're just some engineers who got it to work repeatably and practically without a full and correct model of the physics. But don't hold your breath waiting for somebody in a couple labs to come out with a replication. That seems unlikely unless/until some physicists reinvent it.
And with the dominant paradigm, after the original cold fusion flap, being that "there's nothing behind the curtain", efforts on reproduction will likely be few and underfunded unless/until they DO ship a working product.
Nobody knew it was in the container. So it WAS lost.
(Although I suppose you could argue that it was really just hiding.)
Irv Hoff.
10-11 hour days? No problem.
Just have 'em write options for 1/10th% of the company per person with an exercise strike cost of about %5,000 to $6,000. And serve nutritious munchies (not salt-crunchies and pop) all day and a dinner buffet on the company dime every evening - with no OBLIGATION to stay after.
Then they're in startup mode and most of the engineers will voluntarily stay for an extra 2 to 4 hours per day.
(The food is especially cheap compared to hiring enough extra employees to work the extra hours, plus the still more extra hours and extra management needed for the communication inefficiency with a bigger work force.)
But expect 'em to work that much time on a startup without options? I laugh. You can get away with it in an established company with an exceptional benefits package. But the people who would stay at a startup for that long without a cut of the pie are the ones who couldn't get a position with a startup that would cut them in.
Pay the workers or kiss 'em goodbye.
In the garbage collection case, either
1. The parent should not have been hooked to garbage collection before its members were contstructed
That gives you the class-hierarchy doubling I described earlier. The "be collectible" flag has to be cleared by the final level of class derivation, which can not have further classes derived from it. This breaks the class paradigm by requiring you to distinguish leaf classes that can exist from their immediate all-but-collectible precursors which can be further modified.
or
2. Garbage collection should be suppressed during a constructor
Out of memory. Crash! Also all the leaf/stem problems if 1.
They both break the class paradigm another way: The garbage collectible behavior is supposed to be INHERITABLE. So it should all be encapsulated in the base class. Why are you forcing it to be moved to a derived level which has NOTHING TO DO with this behavior, just to work around an issue with the compiler's code generator?
In the exception case, a constructor that is going to throw has the responsibility of cleaning up its members before it throws. When a constructor throws, the destructor is not run. If a constructor fails and exceptions aren't available, it should still clean up its members and set a flag to let the destructor know not to do anything.
The problem is not the constructor throwing. Constructors know what they're constructing and can handle it.
The problem is a member constructor throwing. Does it have to understand everything that might contain it (including things that were written years later by a different team)? How can it do that? How can it do that without breaking the entire point of the encapsulation information-hiding paradigm?
What happens if something called by something called by something ... called by a member constructor throws. Now everything that throws has to understand how to unwind every layer between it and the object that catches.
If the promotion of the object occurs in the way I described as "correct" it's trivial to solve both these problems - and others - through the activation of the appropriate levels of the virtual member functions. If it happens otherwise they aren't readily soluble - and either aren't solved at all or aren't solved in a practical way by your suggestions.
This is a circular dependency that will never make logical sense ...
This is SO not true. I'll give you some examples in a bit.
If you find yourself needing to do this, there should be a way to renormalize your object model so that the member objects are not dependent on (or even aware of) the existence of the thing they are destined to be members of (at least until all the parties involved have completed their constructors, but preferably maintaining orthogonality through the entire life cycle)
Again not true. The issue is not that the members have an awareness of the eventual object. The issue is that the base class EXPORTS knowledge of and access to common behavior of all classes derived from the base class but the details of which vary depending on which derived class is in question. The promotion of the instance to the derived class "switches on" the details of the behavior - but if this occurs, and is invoked, before the derived class is able to initialize the underpinnings of the behavior, things break.
One example from the project: Garbage collection via a mark-and-sweep algorithm:
- All heap-allocated objects subject to garbage collection are members of classes derived from a base class ("Heaper") whose constructor hooks the objects into a list of all allocated Heapers and whose destructor unhooks it.
- The virtual function in question is the mark-yourself part of the pointer-following marker. (Its guts are generated by a preprocessor that parsed the class declaration.) In a Heaper-derived class it knows about the pointers to other Heaper-class objects at its level. It calls the baseward version of itself and if it returns TRUE calls the mark-yourself functions of all the objects pointed-to at its level. At Heaper itself the function marks the object itself and returns TRUE if it was unmarked.
- When garbage collection is invoked the Heapers are all unmarked. The collector first calls the mark-yourself functions pointed to by "smartpointers" that constitute the data-structure roots, then walks the list of Heapers, freeing the unmarked and unmarking the marked.
The problem arises because constructors of member objects of the derived class may cause memory allocation (either temporary or permanent) and this may invoke the garbage collector. If the class has already been promoted to the derived type (i.e. if calling its mark-yourself virtual function gets the derived class version) the garbage collector will try to follow the derived class pointers - which may not be initialized yet. Oops!
Another case: Exception handling. (This project was running before "catch" and "throw" were more than reserved words.) The similar problem occurs because destructors are such a virtual function. If an exception is thrown from a member object and the class under construction was promoted too soon, you end up running the destructor of the derived class before the constructor was run, again while some or all of the member variables are uninitialized.
These are two concrete examples from the project. The general case is "promoting/demoting at the 'wrong' stage runs behavior whose underpinnings are not constructed or already destructed". For instance: Hooking a display object into a display list that's interpreted by a periodic process running in another thread. If it's time to display while the object is under construction or destruction, and the promotion/demotion timing was "wrong", the display processing manger invokes services whose infrastructure are not yet constructed or already destructed.
With "correct" timing of promotion/demotion you can have an object that is always consistent, even if only partially formed. (Constructors and destructors, for instance, can have "stage of construction" member variable(s) that modulate(s) the behavior of other member functions depending on whether their underpinnings are ready, and this can be initialized to "nothing ready" before the object is promoted a
When:
- a base class has a virtual member function
- the base class exposes its "this" pointer externally (for instance: by linking itself into a list)
- a derived class overrides the virtual member function
- the derived class of the base class has members of object type that have constricution and/or has calls to external functions in member initializers
- the construction or other initialization of the derived class members BEFORE executing the body of the derived class constructor calls the virtual function.
what version (base, derived, something breaks) of the function is executed?
Similarly for destructors.
IMHO the specification should REQUIRE that the BASE class version of the virtual function is the one that is executed at any stage prior to the execution of the first line of the body of the constructor and after the execution of the last line of the body of the destructor, while the DERIVED class version is executed during the execution of the body of the constructor, destructor, and at all times between them.
This was "broken" in 1985ish, when a project I was associated with tried to use C++ as its language. (Treating the constructor and destructor cases separately gives you four binary combinations of behavior of which one is "right" and three are "wrong". Cfront and cfront-derived compilers got it "wrong" one way, three C++ compilers available on IBM PCs got it "wrong" a second way, and gcc got it "wrong" the third way.
I tried in both ANSI standardization processes to get it "fixed", i.e. defined as I suggest above. I was rebuffed both times. It was declared explicitly undefined behavior in the first ANSI C++ standard and "don't do it" in the second.
Question: Has it been fixed, or even defined, YET?
This is NOT an academic issue. C++ (unlike, for instance, Smalltalk and Objective C) has construction semantics that promote and demote the behavior of objects of derived classes in a way that keeps the debugging of unchanged parts of base classes intact when modifications are derived from them, which is one of the things that makes C++ code more robust. And its ability for classes to have members of object type has potential to greatly reduce memory management overhead compared to webs of heap-allocated pieces in the Smalltalk style.
But this oversight in the specification of behavior on construction and destruction forced that project to the web-of-little-heap-things style regardless, and also has the potential to sucker the programmer into creating extraordinarily subtle bugs.
So didja fix it, guys? PLEASE tell me you fixed it!
If electrical discharges in a thunderstorm can concentrate energy enough to create gammas energetic enough to create electron-positron pairs (2 x 511 keV), I'd expect that (given the large concentrations of hydrogen in the cloud's water) they can also produce initiation energy for nontrivial amounts of nuclear fusion. (D D or D T at about 15 keV or P B at about 123 keV.) These reactions produce tens of MeV of output energy, some of which could appear as the gammas that produce electron-positron pairs.
It would be interesting to look for the signatures of that. Especially given that the mechanism of the dense plasma focus is a plasma instability that I'd expect to be sometimes produced in a free-air electrical discharge such as a lightning bolt or sprite.
Does this process potentially make the world more massive, in creating particle pairs - one of which escapes into space?
Nope. Makes the planet lighter by the amount of mass + (kinetic energy / csquared) that escaped.
That's because the energy that created them came from the Earth, where it had been for a while (even if it had previously come from sunlight rather than geothermal or combustion sources) and the energy itself - either as energy or as the difference of mass between two forms (before and after) of matter that liberated it - had mass itself.
Also: Traffic management (without push-out) plus RED won't cover shorter-than turn-around burst-and-die traffic sessions or long-lived flows using protocols that don't respond to packet drops as a congestion signal. That covers TCP start-up-and-die transactions (like a lot of web requests), UDP - either burst or without alternative added-on flow control, and a bunch of other stuff.
Also: Some web sites have, for a while, been "cheating" by breaking images up into separate tiles that fit into the start-up burst, so the browser launches a bunch of simultaneous requests.
Oops. Should have read your reference before replying. I missed that you were talking about weighted fair queueing "with longest queue pushout" and it had already taken RED into account.
Sorry, but what I said (RED is half the solution) still stands, for a different reason. While you might get Motorola's proposal to work at the edge, the backbone will not have the memory to identify ALL the flows and compare them - or the knowledge of what share each flow SHOULD have, without extra turnarounds to propagte it. Meanwhile it's pathetically easy for an application that wants to "cheat" to create multiple flows - both getting multiple "shares" of the division and exploding the per-flow storage and balancing computation requirements for a solution like Motorola proposes.
There's nothing inherently wrong with big in-transit buffers for TCP streams. The real question is not which packets get dropped; it's which packets get sent next. That's what "fair queuing" and some other quality of service algorithms are about.
Sorry, fair queueing is only half the solution, and if the boxes in the middle are too dumb to apply the other half of the solution, increasing the buffer sizes just increases the latency, because packets don't get dropped (signaling TCP to slow down) until the bigger buffers are full.
The basic solution to the other half is called RED (Random Early Detection/Discard/Drop), was published in 1993. One version is in a 1998 RFC (2309), and variations of it are already requirements for and implemented in the backbone and edge routers throughout the Internet.
(It may not be as widely known and deployed "off the edge" due to the limited number of queues on those machines. Nice to see that broader attention is now being given to the problem, so that open source and home router coders will implement it there, as well, when it is appropriate.)
Trick is to keep running averages of the buffer depths and use them to randomly drop a few packets when they start to grow, more as they get deeper. This signals TCP to throttle back. Dropping randomly sends the throttle-back signal fairly to all the TCP flows. The drop probability has to be very low and the time constant of the decay of the average has to be comparable to the round-trip time of the links to prevent some bad pathologies, like excessive throttle-back or synchronization of the throttling of many streams, creating an oscillation that alternates between underutilization and excessive dropping.
Do it right and your queues stay just full enough to smooth out and fully utilize your outgoing bandwidth, drastically reducing latency and leaving most of the buffer memory available to catch and handle bursts. Yet your average drop rate is no higher than if you let the queues expand until the buffers overflowed and the bandwidth is fairly distributed.
It's all well documented in the literature.
So you've been fighting for freedom of speech, equality and all those otherwise noble causes. But now you question jokes made about those very concepts?
He's welcome to continue to make them. I just wanted him to be aware of what he was doing.
"Letting other people do things you don't like is the price of freedom." - M. McClary
I must have missed those large tracts of American history 101, where they told us about the war to free the Rednecks, the Jim-Bob Crow laws, and the Redneck-only drinking fountains....
As Artifakt points out in a sibling posting to yours, look into the early days of labor unions - when machineguns were considered a necessary tool of labor relations.
The referenced article might be read to imply more attraction to those more closely related and no limit on how closely (if they were first encountered when adult, thus avoiding the Westermarck effect). But it doesn't seem have any information or references to falsify an assertion that sexual attractiveness peaks at third cousin level. Neither does it give any quantitative comparison of attractiveness versus different levels of consanguinity.
Is there perhaps something in one of the references? If so, which one?
Cut my "hacker's teeth" on some computers that were located in a WW II era bomber-plant hangar. (Built mostly of wood because the steel was being used for war machines.)
Place had issues with mice and rats getting under the raised floor and chewing on the cabling.