Re:Marine battery + panel + DC lighting. Done
on
DIY Solar Resources?
·
· Score: 2, Informative
My son and I built a very similar setup for a school project: A solar-powered kiosk for recharging portable electronic devices. It's been operating for over a year now without incident.
We used a deep-discharge AGM battery purchased locally. The panel we bought online from www.solardepot.com. We considered just using a series diode, but eventually opted for an inexpensive SCN-2 charge controller from www.allelectronics.com. We also picked up the AC inverter there.
(Checking, I see the price for the controller has gone up, so you might want to shop around for one that's a little cheaper.) The various other parts, like the mechanical dial timer, fuses, outlets, conduit, and assorted mounting hardware were all purchased locally.
Frankly, the hardest part of the project was coordinating the installation (which involved getting up on the roof) with the school. The electronics went together effortlessly.
Our main worry wasn't that the setup wouldn't work, but rather that it would be vandalized. But for whatever reason that hasn't happened.
Yep, while I suppose the data this study produced might be interesting/useful to neurologists, its conclusions in regard to possible policy are absurd. Not only is operating a car by mouse not exactly simulating anything useful, have you ever had an MRI? I have, and unless they some some kind of special rig I've never heard of, the machine itself is certain to be hugely distracting: Close quarters and very loud thumps while operating.
That said, at least one of the other studies cited in the article was one where driving conditions were more accurately simulated and cell phones did cause significant impairment.
The fact that he hasn't already been charged with criminal trespass or breaking into a computer system or whatever likely means the evidence they have isn't sufficient to sustain a criminal charge where the standard of proof is "beyond a reasonable doubt". So the government went after him for violating rules where the standard is far weaker - possibly the same if not weaker than the "preponderance of evidence" standard in a civil case.
Now that the judge has shot that down (I have no idea whether this was a good decision since I have no knowledge of precedent-setting cases in this general area) they'll have to try something else. My offhand guess is they'll now try for asset forfeiture, because that way once again they can get civil rather than criminal standards of proof. (For those that are unaware, the way civil forfeiture works is the government sues the property itself, not the person. In fact once the government shows probably cause that the asset should be forfeited it then up to the owner to prove under the preponderance of evidence standard that it is not.)
My first and only experience as a juror was the exact opposite. Everyone on the jury behaved
completely reasonably and deliberations went quite smoothly. (Disclaimer: I ended up as foreperson.) The judge was also very competent - sarcastic, but competent. What wasn't reasonable was the case itself or either of the lawyers.
Without getting into too much detail, the prosecution didn't even come close to proving their case.
Had the defense attorney simply said "the defense declines to present a case and sends this to
the jury without argument" we would have had no choice but to find the defendant not guilty
on all six counts he was charged with (four of them quite serious).
But rather than take this course what does the defense do? Why, they put the defendant on the
stand and he promptly proceeds to make the prosecution's case for them! He admitted everything,
claiming he acted in self-defense. Trouble is, uncontested physical evidence clearly demonstrated
that four of the six counts couldn't possibly have been self-defense. My mouth was literally hanging open as I watched this guy convict himself and I could see that most of the other jurors were just
as shocked.
The first words out of one of the other jurors' mouth when we entered the jury room were along
the lines of, "We should let this dumb bastard off and charge both the attorneys with incompetence!"
Anyway, my advice to anyone serving on a jury where the case lasts for more than a day is to try
and get to know the other jurors if at all possible. Go out to lunch together or something.
You can't talk about the case but nothing prevents you from talking about other stuff. The only
difficult part for the jury I was on was deciding the two counts where the self-defense
claim could possibly have been legitimate. A little knowledge about the other jurors really
helps when making decisions like that.
IT provides a service, it is not the raison d'etre for a company unless it's business
is providing IT services. In most cases the huge benefits provided by laptops definitely
outweigh the costs. If IT has a problem with laptops under these circumstances they need
to suck it up and deal.
There may be situations where this isn't true, although I'm guessing they're rare.
But if that's the case the case needs to be
made on the basis of rational analysis, not a bunch of one-sided whining like this.
I also question the validity of many of the claims. For example, if I had the unmitigated
gall to complain to our IT people
that I was having trouble accessing some football pool they'd laugh themselves sick
before telling me to stick it where the sun don't shine.
20 years or so ago I was in the security line just in front of a guy in overalls with a fairly large cheap red plastic toolbox. After making it through the scanner myself I looked back. This
checkpoint happened to be one where the monitor for the X-ray machine was visible to the passengers and I could see the toolbox being scanned. The scanner clearly showed some screwdrivers, needlenose pliers, and other assorted hand tools along with what was obviously a VOM along with a pair of those leads made with wire that coils up on its own. It also happened to look just like what you'd expect a cartoon bomb (think Rocky and Bullwinkle) to look like under a scanner. It was so absurd looking I started to laugh. I stopped laughing when the security people grabbed the toolbox
and opened it (confirming that it was indeed a garden variety VOM with coiled leads) and then
literally swarmed all over the poor guy and pulled him through a nearby door.
That was the day I lost all respect for security screening. I mean, come on - their training should at least cover the common sorts of things you can expect to find in a toolbox. And if there was actually good reason to believe it was a bomb, why the hell did they open it?
I was flying a lot in those days so I don't remember the airport, but it could easily have been Logan.
Fantastic post. I have one quibble: Your assertion that police are poorly paid. Of course things
vary a lot from one place to the next, but here in LA average police salaries range from $52,638 to $70,679 (source: http://www.lacity.org/PER/recruit1.htm). That's hardly a king's random but neither is it a pittance. I also note that the same site says that anyone with a college degree is likely to
start at a salary above the minimum.
There was a story a couple of years ago about a clinical trial at Cedars Sinai
of an artificial liver developed by Dr. Achilles A. Demetriou. The device uses
a bioreactor containing cells from pig livers
The people they tried this on were all in end-stage liver
failure and about to die. The
idea was to tide them over until a transplant became available.
A couple of them died from the effects of the surgery. Some others lasted long
enough to finally get a transplant. But in several others their own livers managed
to regenerate to the point where a transplant was no longer needed.
This led to a bigger study at 20 US research centers. The results were that artificial
liver reduced mortality by 44 percent:
LDAP certainly could be used for this, but not in such an obvious way.
A key element of any such service is that it has to work when the primary MX is totally
inaccessible. So a scheme where the secondary just looks up addresses using an LDAP
server operated by the primary won't work - it fails at exactly the wrong time.
What's needed is for an LDAP server at the secondary to be act as a slave to the
master server maintained by the primary. I believe LCUP (RFC 3928) provides this
capability.
Another issue is that no matter what protocol you use there has to be a defined
way in which to store address information. In the specific case of LDAP
you'd need to have not only an LDAP schema but also a specific DIT layout.
Various existing LDAP schemata define ways to represent email addresses in LDAP but AFAIK
none of them are adequate for this. An obvious deficiency is that you need ways to
say things like "the part of the address after a plus can be anything" or "ignore a
leading underscore if present" or perhaps even "if this begins with a tilde remove the
tilde and match against a different attribute".
DNS NAPTR provide what seems to me be to
be a pretty good match to what's needed here, which is one reason why I used DNS as an
example rather than LDAP. Another reason is that I'm unclear to what extent LCUP
is actually implemented by LDAP servers, whereas DNS mechanisms for this are universally
implemented. Basing this on something that's readily available seems like a really good
idea to me - perhaps even a requirement.
They absolutely do have a legitimate problem, one that needs to be addressed by appropriate standardization
and implementation activities. But unconditionally failing to generate DSNs is not the answer.
What they need is a mechanism that eliminates most of the cases where they currently
have to generate DSNs.
First, by their own admission this is only a serious problem for what they call their MailHop Backup
MX service. Their other services, MailHop relay and forward are "mostly immune" to DSN issues.
The reason for this is simple: With MailHop Backup MX they have no way to validate addresses so they
end up accepting a ton of crap to invalid addresses that end up bouncing later when they relay
it on. With the other services they can validate addresses and generate a "5yz recipient invalid"
sort of error right there in the SMTP session - no need for them to generate a DSN.
So, if the problem is that they don't have sufficient recipient information in the one case, why
not solve it by making that information available? One way this could be done is to have the
primary MX publish their list of valid addresses using DNS protocols. A zone transfer could
then be used to copy the information over so it is available when it is needed. DNS update
mechamisms will keep the information reasonably current. (Of course they cannot assume it is current
but they can handle that by issuing a "4yz" temporary error instead of a "5yz" permanent one for
unknown addresses. Various issues
such as needing to support subdomains or subaddresses can probably be dealt with by using NAPTR
records. Obviously this whole thing has to be secured and there are various issues with spoofing,
but none of these issues seem insurmountable.
Although I think a DNS-based solution could work, I'm really only using it as example. A different
mechanism might be more appropriate.
But regardless of the mechanism used, what's missing is the set of standards for how different
organizations release and consume this sort of information. Without those their customers don't
know how to publish the information and even if they did so a backup MX service provider cannot
possibly afford to build a custom address import facility for every customer.
It really is past time that people who have such issues stop going their own way and break
things when they could be working with others to actually solve the problem. I've brought
this issue up in the IETF once or twice and not seen enough interest to pursue it. That might
change if folks like DynDNS would get involved.
Fascinating - I had never heard the term "trampoline" used for these things before. One alternative
to putting them on the stack is to put them on the heap, but you're still creating code on the fly,
with all that implies.
Separate data and instruction caches were a nonissue on the original VAXen, but at some point (VAX
8600 maybe? It has been a LONG time since I thought about any of this stuff) VAXes could potentially
have problems along these lines. If memory serves, performing an REI instruction after constructing
an appropriate PC/PSL on the stack would blow the cache and make this trick safe to use. But it
really is better to find another way to get the necessary frame pointer to the inner routine.
As for BPVs, I believe they were part of the "VAX Procedure Calling Standard", which defined how
routine parameters were supposed to be passed around. The fact that all languages used the same
calling conventions made writing code in a mixture of languages fairly straightforward. There were,
however, various discrepancies, such as the fact that not all languages used BPVs. So things like
passing routines as parameters sometimes required some care. For example, in VAX Pascal you could
use the [unbound] attribute to tell the compiler not to generate a BPV.
Then along came the Alpha and all this stuff changed. I never got as involved with Alpha code as
I did with the VAX, but I think the way this worked was a trampoline-like preamble was inserted
just before each nested routine that got passed as a parameter. A direct call would go to the
normal start address for the routine but the passed address would be to this preamble that
pulled the frame pointer out of the procedure descriptor and put it in R1.
And all this even worked in VAX executables translated for use on the Alpha. Neat stuff.
Does anyone else remember this transition? We always had a reasonably current Britannica in the house
as I grew up. I remember using it for reports and such when I was a teenager and thinking that while
the coverage of science stuff could be a bit deeper the quality and consistency of the articles was
superb, certainly far superior to, say, Funk and Wagnall's, the "Reader's Digest" of encyclopedias.
But all that changed in the late 70s. My father bought a new edition and now there were two sets of
volumes, the Macropaedia and Micropaedia. We had the old and new sets side by side for a while, and it quickly became obvious that the split was at best unhelpful. Time and again I'd look something up
in one set, fail to find anything and have to go to the other. There was no apparent rhyme or reason
to it. And in quite a few cases neither new set had the information contained in the older edition.
Then one day I came home from school and found the new edition wasn't on the shelves any more. It
seems my father had looked up something - I no longer recall what it was but since he was a
cardiologist and an avid reader of history it was probably something about medicine or history -
and had been so appalled at what he found he dumped the entire thing in the trash.
We continued to use the old edition for a long time after that, but of course it got progressively
more out of date and we eventually donated to some library. Sadly, I don't think there's really
anything up-to-date that is comparable to what Britannica was before it was ruined. And I doubt
there can be: We're no longer in the 19th Century, when an educated person could actually hold a
significant fraction of human knowledge in their head. There's just too much information and not
enough financial incentive to hire the huge editorial staff you'd need to organize and present it
consistently.
My conclusion is that as our base of knowledge continues to expand the Wikipedia approach, flawed
though it may be, is the only viable path forward.
I'm not enough of a Perl expert to say anything about its implementation requirements, but there's
nothing in the either original or Extended Pascal that requires code execute on the stack, at
least not on most machines. If this technique is used it is almost always simply an implementation
choice, nothing more.
The place where this sort of trickery is useful in Pascal is when a routine passes a routine at
an "inner" lexical scope to another routine. In order for the passed routine to access variables
in its outer scope it needs a pointer to the stack frame of the containing (in the
lexical sense) routine. This cannot be assumed to have anything to do with the routine that
ends up calling the passed routine.
One way to implement this is to have the code passing the routine to another routine build a stub
on the stack that sets up the pointer properly before calling the real routine. The address of this
stub is then passed instead of the actual routine's address.
A much better way in most cases is to pass both the address of the routine and the pointer to the
stack frame, either as two separate parameters or else as a pointer to a structure that contains
both. (On OpenVMS, for example, such structures were called Bound Procedure Values or BPVs.) The
routine that ends up calling the passed routine then uses the pointer in the bound procedure value to
set things up for the actual routine before calling it.
The main problem with this approach is that it is incompatible with how most non-lexically-scoped
languages pass references to routines around. It can be done in such a way that things work as
long as the passed routine doesn't actually use any variables in the outer scope, which is usually
good enough. In any case, the risks of having the compiler always put code on the stack would seem
to me to be much greater than this small inconvenience.
I once wrote a routine (in VAX assembly) that acted as a shim between a Pascal routine passing
a procedure or functon paramter to a routine in another language. This code used the BPV to
construct a stub on the stack which it then passed along. This let me call, say, an quadrature
routine written in FORTRAN with the function being integrated coded in Pascal. I used this trick
very sparingly, however.
As for Java, I'm not sure "interesting" is the right term. I've read through some descriptions of
the tricks it uses and they frankly scare me.
As the article says, nicotine has been used for years as an off-label treatment for UC following the observation that UC sufferers are very likely to be nonsmokers.
In my own case I've often wondered if the reason why I didn't develop UC until my early 20s was due to both my parents being very heavy smokers. They both quit around that time and I came down with my first UC symptoms within a year. I was lucky as these things go - my UC was never all that severe.
The situation for a friend of mine was even more dramatic. He had been trying for years to quit smoking. Eventually he made it, but after about six months as a nonsmoker he started having fairly severe UC - the onset of which is very uncommon at age 45 - that could not be controlled with sulfasalazine, the drug of choice. Steroidal treatment was required to control his UC, but the effects of heavy steroid use forced him to have a total colectomy within a couple of years.
UC is no joke and I hope this work on nicotine leads to some better treatment options. The big problem for long term UC sufferers is that even if the drugs keep the disease in remission there's an ongoing dysplastic process that inexorably leads to colon cancer. Regular colonoscopies are required to take samples and look for dysplasia. Interestingly, the dysplasia and eventual cancer typically strike in healthy colon adjacent to the region affected by the UC and removing the part with UC has no effect on the development of cancer. This means that a total colectomy is required to deal with the problem. I had mine after 20 years of UC, 15 of those years with the disease under fairly good control.
Flagrant violations of the presidential records act aside, given this administration's cavalier attitude about the handling of classified information, I have to wonder if some of these messages contained any. And if they did, I have a hard time believing a facility operated by the RNC complied with the many rules and regulations for keeping classified information safe.
To be sure, a fair amount of classified information is so labeled more because it would be embarrassing to be revealed than because it is actually sensitive. And some of the rules for handling sensitive data are overly draconian. But there's also a lot of really important stuff these people deal with that really needs all the protection we can give it.
Of course now that so much of the email is deleted we'll probably never know...
This review was very well done overall. Nevertheless, a bit of unfairness did manage to creep in. And no, I'm not talking about the fact that her familiarity with Windoze is probably all that keeps her from seeing the Windows installation process as far more difficult than the Linux one. That's just how things are, like it or not.
Rather, I'm talking about her "no editing configuration files" rule, especially as it was invoked to prevent fixing the Gnome problem with default fonts for labels with a simple config file change. There may not be very many configuration files you need to or even can edit on Windoze, but it is unfortunately not exactly uncommon to have to piddle around with the registry on Windoze to get things working, and I fail to see a substantive difference between poking a setting in there you're not quite sure of versus editing a file and hoping you don't make a syntax error. Either way when you reboot you're sitting there with all your fingers and toes crossed hoping you haven't toasted the damn thing and that's just not an acceptable user experience.
And that's assuming you can find the right setting. Last week our support folks were engaged with a customer on Windoze who had changed some network configuration or other and managed to kill name lookups. It took quite a bit of effort to find the right places in the registry to poke for this.
Now, I'm sure there are plenty of Windoze users who have never had to do any registry hacking, but if so that's a matter of luck more than anything else.
The fact of the matter is that none of the systems in common use can really claim to be entirely free of the need to poke around under the pretty GUI hood to get things properly set up and keep them running over time. This certainly goes for Mac OS X as well, where there are plenty of settings that can only be changed through configuration files. (The one that really bugs me on Mac OS X is the media types to application mapping. This used to be configurable through Internet Config but now you have to download something like "Default Apps" to have a GUI interface for it. OTOH, at least there's a GUI available for it, which is more than I can say for some of the network settings that are only GUI-settable on Mac OS X Server.)
We currently give law enforcement officials far too much leeway. The individual officials involved, not the state, should be held responsible for situations where their failure to engage in responsible behavior leads to a miscarriages of justice.
The best example of this by far is the exclusionary rule in the United States. (I don't know how this sort of thing works in other countries.) It is rare for a police officer who obtains evidence improperly to be punished for their (sometimes outright illegal) actions. Instead what we do is make the evidence itself inadmissable, in effect punishing the one innocent party in the entire situation: The victim of the crime!
As constitutional scholar Leonard Levy argued in his wonderful 1974 book Against the Law (sadly out of print), the admissability of evidence should be determined solely by the legitimacy of that evidence. If there are indications that the evidence is bogus or fabricated, it absolutely must be inadmissable. But if the mistakes are procedural in nature and the evidence is sound it should be admissible and the police should be severely disciplined for their procedural violation in obtaining it.
The way things work right now is that the police feel free to "roll the dice", engaging in actions of dubious legitimacy with impunity. They calculate, correctly, that it's a no-lose thing for them to do: If they get caught they lose evidence they wouldn't have had in the first place and suffer no penalty, if they don't the "bad guy" (who may be nothing of the sort) gets what's coming to them. The tacit way this encourages the police to violate rules or even laws leads unavoidably to little if any respect for the truth, and it's all downhill from there - citizens are well aware that this goes on and stop trusting law enforcement.
But change this so that officers are held accountable for their actions and police will change their behavior accordingly. Firing or even jailing the officer responsible for, say, a blatently illegal search would send a nice clear message to other officials to clean up their act.
In the present case I have no idea if there were procedural violations. But there were definitely serious and ongoing errors in judgment, and the odds are good that the officers responsible were never held accountable for them. Doing so of course would not change this any less of a fiasco, but it might prevent it from happening again.
I've had a Vonage box for several years, and I've used a bunch more for phone banking activities. Service has been excellent, especially compared with my Verizon POTS experience.
I've also had occasion to call Vonage service twice, once to inquire about how many Vonage boxes could be placed on a single cable modem connection and another time when my Vonage box stopped working with a strange sort of ARP resolution failure. In the first case I received surprisingly precise and helpful information with minimal fuss. The second time was even more interesting: The technician told me that this was something they had seen before and their best guess was some sort of block based on ethernet address range. He advised either inserting some kind of router to obscure the ethernet address of the Vonage box or to upgrade to a newer model Vonage box which he offered to send me for free. I opted to insert a router - something I planned to do anyway and would be quicker - and the problem disappeared.
Vonage has definitely saved me money as well. I will be very sorry if this action by Verizon ends up forcing them out of business.
Slashdot Mirror
We used a deep-discharge AGM battery purchased locally. The panel we bought online from www.solardepot.com. We considered just using a series diode, but eventually opted for an inexpensive SCN-2 charge controller from www.allelectronics.com. We also picked up the AC inverter there. (Checking, I see the price for the controller has gone up, so you might want to shop around for one that's a little cheaper.) The various other parts, like the mechanical dial timer, fuses, outlets, conduit, and assorted mounting hardware were all purchased locally.
Frankly, the hardest part of the project was coordinating the installation (which involved getting up on the roof) with the school. The electronics went together effortlessly.
Our main worry wasn't that the setup wouldn't work, but rather that it would be vandalized. But for whatever reason that hasn't happened.
Yep, while I suppose the data this study produced might be interesting/useful to neurologists, its conclusions in regard to possible policy are absurd. Not only is operating a car by mouse not exactly simulating anything useful, have you ever had an MRI? I have, and unless they some some kind of special rig I've never heard of, the machine itself is certain to be hugely distracting: Close quarters and very loud thumps while operating.
That said, at least one of the other studies cited in the article was one where driving conditions were more accurately simulated and cell phones did cause significant impairment.
The fact that he hasn't already been charged with criminal trespass or breaking into a computer system or whatever likely means the evidence they have isn't sufficient to sustain a criminal charge where the standard of proof is "beyond a reasonable doubt". So the government went after him for violating rules where the standard is far weaker - possibly the same if not weaker than the "preponderance of evidence" standard in a civil case.
Now that the judge has shot that down (I have no idea whether this was a good decision since I have no knowledge of precedent-setting cases in this general area) they'll have to try something else. My offhand guess is they'll now try for asset forfeiture, because that way once again they can get civil rather than criminal standards of proof. (For those that are unaware, the way civil forfeiture works is the government sues the property itself, not the person. In fact once the government shows probably cause that the asset should be forfeited it then up to the owner to prove under the preponderance of evidence standard that it is not.)
My first and only experience as a juror was the exact opposite. Everyone on the jury behaved completely reasonably and deliberations went quite smoothly. (Disclaimer: I ended up as foreperson.) The judge was also very competent - sarcastic, but competent. What wasn't reasonable was the case itself or either of the lawyers.
Without getting into too much detail, the prosecution didn't even come close to proving their case. Had the defense attorney simply said "the defense declines to present a case and sends this to the jury without argument" we would have had no choice but to find the defendant not guilty on all six counts he was charged with (four of them quite serious).
But rather than take this course what does the defense do? Why, they put the defendant on the stand and he promptly proceeds to make the prosecution's case for them! He admitted everything, claiming he acted in self-defense. Trouble is, uncontested physical evidence clearly demonstrated that four of the six counts couldn't possibly have been self-defense. My mouth was literally hanging open as I watched this guy convict himself and I could see that most of the other jurors were just as shocked.
The first words out of one of the other jurors' mouth when we entered the jury room were along the lines of, "We should let this dumb bastard off and charge both the attorneys with incompetence!"
Anyway, my advice to anyone serving on a jury where the case lasts for more than a day is to try and get to know the other jurors if at all possible. Go out to lunch together or something. You can't talk about the case but nothing prevents you from talking about other stuff. The only difficult part for the jury I was on was deciding the two counts where the self-defense claim could possibly have been legitimate. A little knowledge about the other jurors really helps when making decisions like that.
IT provides a service, it is not the raison d'etre for a company unless it's business is providing IT services. In most cases the huge benefits provided by laptops definitely outweigh the costs. If IT has a problem with laptops under these circumstances they need to suck it up and deal.
There may be situations where this isn't true, although I'm guessing they're rare. But if that's the case the case needs to be made on the basis of rational analysis, not a bunch of one-sided whining like this.
I also question the validity of many of the claims. For example, if I had the unmitigated gall to complain to our IT people that I was having trouble accessing some football pool they'd laugh themselves sick before telling me to stick it where the sun don't shine.
20 years or so ago I was in the security line just in front of a guy in overalls with a fairly large cheap red plastic toolbox. After making it through the scanner myself I looked back. This checkpoint happened to be one where the monitor for the X-ray machine was visible to the passengers and I could see the toolbox being scanned. The scanner clearly showed some screwdrivers, needlenose pliers, and other assorted hand tools along with what was obviously a VOM along with a pair of those leads made with wire that coils up on its own. It also happened to look just like what you'd expect a cartoon bomb (think Rocky and Bullwinkle) to look like under a scanner. It was so absurd looking I started to laugh. I stopped laughing when the security people grabbed the toolbox and opened it (confirming that it was indeed a garden variety VOM with coiled leads) and then literally swarmed all over the poor guy and pulled him through a nearby door.
That was the day I lost all respect for security screening. I mean, come on - their training should at least cover the common sorts of things you can expect to find in a toolbox. And if there was actually good reason to believe it was a bomb, why the hell did they open it?
I was flying a lot in those days so I don't remember the airport, but it could easily have been Logan.
Fantastic post. I have one quibble: Your assertion that police are poorly paid. Of course things vary a lot from one place to the next, but here in LA average police salaries range from $52,638 to $70,679 (source: http://www.lacity.org/PER/recruit1.htm). That's hardly a king's random but neither is it a pittance. I also note that the same site says that anyone with a college degree is likely to start at a salary above the minimum.
There was a story a couple of years ago about a clinical trial at Cedars Sinai of an artificial liver developed by Dr. Achilles A. Demetriou. The device uses a bioreactor containing cells from pig livers The people they tried this on were all in end-stage liver failure and about to die. The idea was to tide them over until a transplant became available.
d izin_gesundheit/bericht-28316.html
A couple of them died from the effects of the surgery. Some others lasted long enough to finally get a transplant. But in several others their own livers managed to regenerate to the point where a transplant was no longer needed.
This led to a bigger study at 20 US research centers. The results were that artificial liver reduced mortality by 44 percent:
http://www.innovations-report.de/html/berichte/me
LDAP certainly could be used for this, but not in such an obvious way.
A key element of any such service is that it has to work when the primary MX is totally inaccessible. So a scheme where the secondary just looks up addresses using an LDAP server operated by the primary won't work - it fails at exactly the wrong time.
What's needed is for an LDAP server at the secondary to be act as a slave to the master server maintained by the primary. I believe LCUP (RFC 3928) provides this capability.
Another issue is that no matter what protocol you use there has to be a defined way in which to store address information. In the specific case of LDAP you'd need to have not only an LDAP schema but also a specific DIT layout.
Various existing LDAP schemata define ways to represent email addresses in LDAP but AFAIK none of them are adequate for this. An obvious deficiency is that you need ways to say things like "the part of the address after a plus can be anything" or "ignore a leading underscore if present" or perhaps even "if this begins with a tilde remove the tilde and match against a different attribute". DNS NAPTR provide what seems to me be to be a pretty good match to what's needed here, which is one reason why I used DNS as an example rather than LDAP. Another reason is that I'm unclear to what extent LCUP is actually implemented by LDAP servers, whereas DNS mechanisms for this are universally implemented. Basing this on something that's readily available seems like a really good idea to me - perhaps even a requirement.
They absolutely do have a legitimate problem, one that needs to be addressed by appropriate standardization and implementation activities. But unconditionally failing to generate DSNs is not the answer. What they need is a mechanism that eliminates most of the cases where they currently have to generate DSNs.
First, by their own admission this is only a serious problem for what they call their MailHop Backup MX service. Their other services, MailHop relay and forward are "mostly immune" to DSN issues.
The reason for this is simple: With MailHop Backup MX they have no way to validate addresses so they end up accepting a ton of crap to invalid addresses that end up bouncing later when they relay it on. With the other services they can validate addresses and generate a "5yz recipient invalid" sort of error right there in the SMTP session - no need for them to generate a DSN.
So, if the problem is that they don't have sufficient recipient information in the one case, why not solve it by making that information available? One way this could be done is to have the primary MX publish their list of valid addresses using DNS protocols. A zone transfer could then be used to copy the information over so it is available when it is needed. DNS update mechamisms will keep the information reasonably current. (Of course they cannot assume it is current but they can handle that by issuing a "4yz" temporary error instead of a "5yz" permanent one for unknown addresses. Various issues such as needing to support subdomains or subaddresses can probably be dealt with by using NAPTR records. Obviously this whole thing has to be secured and there are various issues with spoofing, but none of these issues seem insurmountable.
Although I think a DNS-based solution could work, I'm really only using it as example. A different mechanism might be more appropriate. But regardless of the mechanism used, what's missing is the set of standards for how different organizations release and consume this sort of information. Without those their customers don't know how to publish the information and even if they did so a backup MX service provider cannot possibly afford to build a custom address import facility for every customer.
It really is past time that people who have such issues stop going their own way and break things when they could be working with others to actually solve the problem. I've brought this issue up in the IETF once or twice and not seen enough interest to pursue it. That might change if folks like DynDNS would get involved.
Fascinating - I had never heard the term "trampoline" used for these things before. One alternative to putting them on the stack is to put them on the heap, but you're still creating code on the fly, with all that implies.
Separate data and instruction caches were a nonissue on the original VAXen, but at some point (VAX 8600 maybe? It has been a LONG time since I thought about any of this stuff) VAXes could potentially have problems along these lines. If memory serves, performing an REI instruction after constructing an appropriate PC/PSL on the stack would blow the cache and make this trick safe to use. But it really is better to find another way to get the necessary frame pointer to the inner routine.
As for BPVs, I believe they were part of the "VAX Procedure Calling Standard", which defined how routine parameters were supposed to be passed around. The fact that all languages used the same calling conventions made writing code in a mixture of languages fairly straightforward. There were, however, various discrepancies, such as the fact that not all languages used BPVs. So things like passing routines as parameters sometimes required some care. For example, in VAX Pascal you could use the [unbound] attribute to tell the compiler not to generate a BPV.
Then along came the Alpha and all this stuff changed. I never got as involved with Alpha code as I did with the VAX, but I think the way this worked was a trampoline-like preamble was inserted just before each nested routine that got passed as a parameter. A direct call would go to the normal start address for the routine but the passed address would be to this preamble that pulled the frame pointer out of the procedure descriptor and put it in R1.
And all this even worked in VAX executables translated for use on the Alpha. Neat stuff.
Does anyone else remember this transition? We always had a reasonably current Britannica in the house as I grew up. I remember using it for reports and such when I was a teenager and thinking that while the coverage of science stuff could be a bit deeper the quality and consistency of the articles was superb, certainly far superior to, say, Funk and Wagnall's, the "Reader's Digest" of encyclopedias.
But all that changed in the late 70s. My father bought a new edition and now there were two sets of volumes, the Macropaedia and Micropaedia. We had the old and new sets side by side for a while, and it quickly became obvious that the split was at best unhelpful. Time and again I'd look something up in one set, fail to find anything and have to go to the other. There was no apparent rhyme or reason to it. And in quite a few cases neither new set had the information contained in the older edition.
Then one day I came home from school and found the new edition wasn't on the shelves any more. It seems my father had looked up something - I no longer recall what it was but since he was a cardiologist and an avid reader of history it was probably something about medicine or history - and had been so appalled at what he found he dumped the entire thing in the trash.
We continued to use the old edition for a long time after that, but of course it got progressively more out of date and we eventually donated to some library. Sadly, I don't think there's really anything up-to-date that is comparable to what Britannica was before it was ruined. And I doubt there can be: We're no longer in the 19th Century, when an educated person could actually hold a significant fraction of human knowledge in their head. There's just too much information and not enough financial incentive to hire the huge editorial staff you'd need to organize and present it consistently.
My conclusion is that as our base of knowledge continues to expand the Wikipedia approach, flawed though it may be, is the only viable path forward.
I'm not enough of a Perl expert to say anything about its implementation requirements, but there's nothing in the either original or Extended Pascal that requires code execute on the stack, at least not on most machines. If this technique is used it is almost always simply an implementation choice, nothing more.
The place where this sort of trickery is useful in Pascal is when a routine passes a routine at an "inner" lexical scope to another routine. In order for the passed routine to access variables in its outer scope it needs a pointer to the stack frame of the containing (in the lexical sense) routine. This cannot be assumed to have anything to do with the routine that ends up calling the passed routine.
One way to implement this is to have the code passing the routine to another routine build a stub on the stack that sets up the pointer properly before calling the real routine. The address of this stub is then passed instead of the actual routine's address.
A much better way in most cases is to pass both the address of the routine and the pointer to the stack frame, either as two separate parameters or else as a pointer to a structure that contains both. (On OpenVMS, for example, such structures were called Bound Procedure Values or BPVs.) The routine that ends up calling the passed routine then uses the pointer in the bound procedure value to set things up for the actual routine before calling it.
The main problem with this approach is that it is incompatible with how most non-lexically-scoped languages pass references to routines around. It can be done in such a way that things work as long as the passed routine doesn't actually use any variables in the outer scope, which is usually good enough. In any case, the risks of having the compiler always put code on the stack would seem to me to be much greater than this small inconvenience.
I once wrote a routine (in VAX assembly) that acted as a shim between a Pascal routine passing a procedure or functon paramter to a routine in another language. This code used the BPV to construct a stub on the stack which it then passed along. This let me call, say, an quadrature routine written in FORTRAN with the function being integrated coded in Pascal. I used this trick very sparingly, however.
As for Java, I'm not sure "interesting" is the right term. I've read through some descriptions of the tricks it uses and they frankly scare me.
As the article says, nicotine has been used for years as an off-label treatment for UC following the observation that UC sufferers are very likely to be nonsmokers.
In my own case I've often wondered if the reason why I didn't develop UC until my early 20s was due to both my parents being very heavy smokers. They both quit around that time and I came down with my first UC symptoms within a year. I was lucky as these things go - my UC was never all that severe.
The situation for a friend of mine was even more dramatic. He had been trying for years to quit smoking. Eventually he made it, but after about six months as a nonsmoker he started having fairly severe UC - the onset of which is very uncommon at age 45 - that could not be controlled with sulfasalazine, the drug of choice. Steroidal treatment was required to control his UC, but the effects of heavy steroid use forced him to have a total colectomy within a couple of years.
UC is no joke and I hope this work on nicotine leads to some better treatment options. The big problem for long term UC sufferers is that even if the drugs keep the disease in remission there's an ongoing dysplastic process that inexorably leads to colon cancer. Regular colonoscopies are required to take samples and look for dysplasia. Interestingly, the dysplasia and eventual cancer typically strike in healthy colon adjacent to the region affected by the UC and removing the part with UC has no effect on the development of cancer. This means that a total colectomy is required to deal with the problem. I had mine after 20 years of UC, 15 of those years with the disease under fairly good control.
Flagrant violations of the presidential records act aside, given this administration's cavalier attitude about the handling of classified information, I have to wonder if some of these messages contained any. And if they did, I have a hard time believing a facility operated by the RNC complied with the many rules and regulations for keeping classified information safe.
To be sure, a fair amount of classified information is so labeled more because it would be embarrassing to be revealed than because it is actually sensitive. And some of the rules for handling sensitive data are overly draconian. But there's also a lot of really important stuff these people deal with that really needs all the protection we can give it.
Of course now that so much of the email is deleted we'll probably never know...
This review was very well done overall. Nevertheless, a bit of unfairness did manage to creep in. And no, I'm not talking about the fact that her familiarity with Windoze is probably all that keeps her from seeing the Windows installation process as far more difficult than the Linux one. That's just how things are, like it or not.
Rather, I'm talking about her "no editing configuration files" rule, especially as it was invoked to prevent fixing the Gnome problem with default fonts for labels with a simple config file change. There may not be very many configuration files you need to or even can edit on Windoze, but it is unfortunately not exactly uncommon to have to piddle around with the registry on Windoze to get things working, and I fail to see a substantive difference between poking a setting in there you're not quite sure of versus editing a file and hoping you don't make a syntax error. Either way when you reboot you're sitting there with all your fingers and toes crossed hoping you haven't toasted the damn thing and that's just not an acceptable user experience.
And that's assuming you can find the right setting. Last week our support folks were engaged with a customer on Windoze who had changed some network configuration or other and managed to kill name lookups. It took quite a bit of effort to find the right places in the registry to poke for this.
Now, I'm sure there are plenty of Windoze users who have never had to do any registry hacking, but if so that's a matter of luck more than anything else.
The fact of the matter is that none of the systems in common use can really claim to be entirely free of the need to poke around under the pretty GUI hood to get things properly set up and keep them running over time. This certainly goes for Mac OS X as well, where there are plenty of settings that can only be changed through configuration files. (The one that really bugs me on Mac OS X is the media types to application mapping. This used to be configurable through Internet Config but now you have to download something like "Default Apps" to have a GUI interface for it. OTOH, at least there's a GUI available for it, which is more than I can say for some of the network settings that are only GUI-settable on Mac OS X Server.)
We currently give law enforcement officials far too much leeway. The individual officials involved, not the state, should be held responsible for situations where their failure to engage in responsible behavior leads to a miscarriages of justice.
The best example of this by far is the exclusionary rule in the United States. (I don't know how this sort of thing works in other countries.) It is rare for a police officer who obtains evidence improperly to be punished for their (sometimes outright illegal) actions. Instead what we do is make the evidence itself inadmissable, in effect punishing the one innocent party in the entire situation: The victim of the crime!
As constitutional scholar Leonard Levy argued in his wonderful 1974 book Against the Law (sadly out of print), the admissability of evidence should be determined solely by the legitimacy of that evidence. If there are indications that the evidence is bogus or fabricated, it absolutely must be inadmissable. But if the mistakes are procedural in nature and the evidence is sound it should be admissible and the police should be severely disciplined for their procedural violation in obtaining it.
The way things work right now is that the police feel free to "roll the dice", engaging in actions of dubious legitimacy with impunity. They calculate, correctly, that it's a no-lose thing for them to do: If they get caught they lose evidence they wouldn't have had in the first place and suffer no penalty, if they don't the "bad guy" (who may be nothing of the sort) gets what's coming to them. The tacit way this encourages the police to violate rules or even laws leads unavoidably to little if any respect for the truth, and it's all downhill from there - citizens are well aware that this goes on and stop trusting law enforcement.
But change this so that officers are held accountable for their actions and police will change their behavior accordingly. Firing or even jailing the officer responsible for, say, a blatently illegal search would send a nice clear message to other officials to clean up their act.
In the present case I have no idea if there were procedural violations. But there were definitely serious and ongoing errors in judgment, and the odds are good that the officers responsible were never held accountable for them. Doing so of course would not change this any less of a fiasco, but it might prevent it from happening again.
I've had a Vonage box for several years, and I've used a bunch more for phone banking activities. Service has been excellent, especially compared with my Verizon POTS experience.
I've also had occasion to call Vonage service twice, once to inquire about how many Vonage boxes could be placed on a single cable modem connection and another time when my Vonage box stopped working with a strange sort of ARP resolution failure. In the first case I received surprisingly precise and helpful information with minimal fuss. The second time was even more interesting: The technician told me that this was something they had seen before and their best guess was some sort of block based on ethernet address range. He advised either inserting some kind of router to obscure the ethernet address of the Vonage box or to upgrade to a newer model Vonage box which he offered to send me for free. I opted to insert a router - something I planned to do anyway and would be quicker - and the problem disappeared.
Vonage has definitely saved me money as well. I will be very sorry if this action by Verizon ends up forcing them out of business.