Also the explanation of QUIT is better. I guess I've still got the OS and Application mindset and was applying it to the example unfairly.
I think you've actually touched on the main problem of any development effort like this in your tangent. As long as there is competition for similar applications/commands/whatever you call them then the commercial companies really don't get any benefit from cooperating.
Thanks for the detailed explanation. The idea is definitely intriguing, the implementation is definitely lacking (IMHO of course).
The whole idea behind the Caps Lock key was because it is in fact awkward to hold down a key while typing for long lengths of time. (Also the shift key had the inadvertant effect of shifting numbers to symbols as well.)
As for a single command space isn't that just begging for trouble? What about the specialized commands needed for specialized tasks? Why should QUIT save the document in its current state? What's the exit without saving option then? Are you going to have to do Caps-Lock UNDO to fix a typo?
Press the Caps Lock key and while you hold it down, type "QUIT". The word "QUIT" will appear in the transparent gray overlay. Release the Caps Lock key and RCHI will close. Saving is automatic. The next time you open RCHI, your text will still be there. To open RCHI, click on run.bat in the reducks folder.
Holding down the Caps Lock key and typing. I supposed it's touch to top Ctrl+Alt+Del...
My point was that there are a multitude of variables that need to be factored into global climate models well beyond any simple "turn the burner on" scenario.
It is obviously impossible to actually perform full scale experiments due to the size and time-frame necessary (we're not multi-dimensional lab rats after all:-D ).
The debate over the "hockey puck" shows that there is disagreement over basic foundational data (which only represents a very short time period as far as the Earth is concerned) so drawing conclusions especially to the point of X degrees more and we all die is misleading at best and scientifically dishonest at worst.
We're not dealing with a static system that has only a single input. Care to speculate on the climate changes caused by the tsunami? Wide spread destruction of ocean plant life and coastal habitats will obviously affect O2 generation and CO2 processing. Did you know that the North Pole moved and that the day got shorter thanks to the earth quake that triggered the tsunami?
We do Computational Fluid Dynamics modelling here at my work and the computer models always have to be checked against physical experiments to validate their results. Additionally, due to the limitations of computers (something that is constantly improving) the detail of the models has changed over time.
As for the hockey stick you can read about it here.
I can't answer your mod questions as I didn't mod the post (can't mod and comment after all).
This of course ignores the whole fact that no one agrees that we've actually "turned the burner on" as far as Earth is concerned.
Further we don't know what would happen if we "turned the burner off". This article suggests that we'd get the ice age routine just like in Fallen Angels.
The other article about Global Dimming also would suggest that there are other changes we aren't accounting for.
It's not a binary either-or problem. It's a complex system that is "described" using things like chaos theory.
BTW, statistical analysis against the old "hockey stick" temperature data suggests that the seed data is flawed and will always create a hockey stick shaped graph no matter what data is fed in to it.
There are actually some well documented medical differences between sexes. There are also differences between races as well.
Maybe the speaker could have phrased his comments better at the time but it's terribly ironic when you say something like:
Unfortunately, by and large, the vast majority of people who promote the "men are better than A", "women are better at B" discussions are those who want to back their preference for discriminatory behaviour.
You even qualify your statement with this:
There are instances I can think of where this is not the case, but by far, they're a minority.
Have you analyzed the context of the comments? Have you looked to see if the professor indeed has a history of disriminatory behavior?
Or, are you simply disciminating against him because of behavior of a group of people?
The "Block images from servername" option is the real godsend. It's always nice to see those lovely gaps in articles where an annoying ad might be. (Yeah, I guess I'm freeloading.)
I've read some about the various stem cell stuff but my own background is a programmer so yeah, I'm not specifically knowledgeable about this stuff.
From my understanding, there are a multitude of issues when dealing with embryonic stem cells. Their very "plenepotent" nature tends to lead to uncontrolled growth with the result being tumors. Their "foreign cell" nature means that you have to deal with the whole range of rejection issues that come with any tissue transplant. I've also read that areas like the spinal chord are more sensitive to foreign tissue than other areas.
Thus, these issues add increased complexity when it comes to developing therapies that would use embryonic stem cells.
Meanwhile, more and more sources of adult stem cells are being found and used in therapies. The fact that the cells can be harvested for the person who is being treated avoids the whole rejection issue. The restricted range of cells that they can become also seems to address the uncontrolled growth problems that have been encountered with the other stem cells. This means that doctors and scientists can concentrate more on the actual application of the cells than in overcoming the tumor and rejection issues.
Thus, "walk before you run."
I may be grossly oversimplifying this, but the point was that industry is voting with their checkbooks as well. The therapies that are actually working are coming from adult stem cells so maybe we should concentrate on them and understand what we can do with those.
That was what I was raising, maybe I phrased it badly, but the issue is authentication.
You have to either trust the other party's authentication process or you have to do it yourself. In a distributed system you have to trust the other party. This means that the technology used to send the authentication information is really a minor issue in the process.
I remember back when we looked at VeriSign to be a certificate authority for our company and they talked about all of their physical security, the signing "ceremony", and all of the personnel checks they went through with their people. This was above and beyond what security was on the box that would actually be the CA host.
If you are looking at a distributed system for e-commerce then you need to address all of those issues as well. Heck, it's more critical because you're dealing with financial transactions and thus financial information needs to be exchanged as well.
So, an OSS "solution" may sound great but it doesn't really address the problem in this case.
Yeah, this may seem like flame-bait but bear with me.
The idea of a federated single-sign-on system suffers the problem of trust. I'm supposed to set up my system to trust your sign-on system that vouches for your identity and provides me with user information. Well, how do I know how to trust you? What kind of security, identity checks, and validation routines did you implement? Do you have a system for revoking id's? Do you have a system for checking for bogus id's? Etc, etc, etc.
There are two problems with any sign-on system. The first is issuing an id/account/card/whatever to a person and ensuring that it actually matches the person. The second is dealing with the associated data. Who can access what data, who can revoke and edit data?
Looked at in this light you see that the technical part of encryption and tokens and what-not is really just the beginning (or even the end) of the battle and a minor part of it at that.
So the point is that having an OSS solution for federated identity really doesn't gain you all that much.
I think part of the problem/conundrum is that you're wondering what action "greyed out" the option rather than which one activates it.
With more esoteric or complex options the rule set is usually this options is off unless...
That means that it would be difficult to provide a good answer as to why something is greyed out in most cases short of listing the times it is active which might have no relation whatsoever to what you're doing.
As for the "well why don't they just hide it then" question that's a tough one. A consistent menu list is a nice thing for comfort but possibly confusing. The same is true for options that come and go.
First, CA just approved a multi-billion dollar fund for this research as a way to attract companies.
Second, the private groups are spending their money working with adult stem cells (this includes the umbilical cord cells used in the described treatment) as they are actually producing results.
Remember that old saw: "you have to learn to walk before you can fly"? Well it may seem a bit backwards but the walking work for stem cells is to work with the adult ones first. You still have to tackle differentiation issues with them and methods of implanting and controlling but you don't have the immune system issues and you don't have the current horrible experimental track record that you do with embryonic stem cells.
This is all before we even go into the whole ethical "destroy a life to create the cells" issue.
Embyronic stem cells have more potential due to their undifferentiated nature but they pose significantly greater problems than do adult stem cells.
First is the issue of rejection. You're putting foreign genetic material into your body. Chances our your body will reject it without massive immuno-suprresants. This of course makes you more susceptible to infection.
Second is the issue of unregulated growth. Large tumors seems to be one of the main results of animal tests with embryonic stem cells.
Third is this fact. Adult stem cells work and are actively being used in therapies.
Now, repeat after me: There is no ban on embryonic stem cell research. While people love to vilify the Bush administration they seem to forget that this was the first administration to actual provide federal funding for embryonic stem cell research. The only limit was that new lines could not be created or used in federally funded work.
As for the Ronald Reagan angle you can also check the research and see that most scientists do not see any therapeutic use of stem cells for Alzheimers.
The fact that you can take ANY code snippet and put it into a "module" doesn't really get you anything.
You can create a Perl "module" that is simply one piece of code you call a ton of times. You can do the same with JavaScript too.
You can also really create a perl Module that can be invoked and used by bunches of other Perl code. The reason for the stricter Module is that it has rules for being incoporated into Perl and should provide strict type-checking, input validation, and error handling.
This is where the real Module idea comes in. It's not OO "hype" it's as you said good coding practice. It also means that you have to think of a module as a Module and have public, protected, and private sections in it and do real checking and error handling.
The "light" part of the application is the user interface. That should always be as light as possible.
The "heavy" part of the application is what does all of the back-end work. Database manipulation, messaging, legacy-system communication and integration, calculations, life cycle management, etc.
The fact is that customers hardly ever know what they want when you start developing. Development is a continuous feedback cycle where you show some, get new requirements, and show some more.
So, maybe you save a week or two of development time using one of the P's instead of good OO design and Java. What happens when they come back a month later and say can you hook in system X to this? What happens when the small system unexpectedly takes off and they need to add in 150+ more concurrent users?
Strong design should not be looked at as an extra expense. Strong design should be looked at as future proofing.
Ummm, last time I saw that I called it development.
The reason for using an OO language is to get you to work with objects and encapsulation. There's a really good reason to do any large enterprise level application using objects. That is that the app is being designed to last longer than one year. That means that during it's life back-end systems are going to change, customer requirements are going to change, and new requirements are going to be introduced.
If you haven't properly separated out all of the portions of your code then when they come back and say "can you give us these two functions running on PDA's?" you're gonna be SOL.
(I spent a year building a system and they promised to transition one of the back-end systems to a whole new platform by the end of the job. They never succeeded but we developed against the old system and the new so it didn't slow us down one bit. THAT'S why you take the time to do OO work.)
IE arrived on every computer, was installed with every Windows OS and had it's icon shoved onto the desktop whether you wanted it or not. (In fact, it was difficult to get it OFF the desktop early.)
Corporate IT groups standardized on IE because "it comes with the OS" and they didn't want to pay for and install a different browser.
Heck, MS had to threaten to revoke Compaq's OEM license (at the time they were the #1 PC seller) to get them to stop installing Netscape.
The fact is that MS "competed" by outspending Netscape, giving their product away for "free", paying bounties to ISP's and IAP's, threatening OEM's, and "leveraging the Window's asset" all in an effort to "cut off Netscape's air supply".
The main advantage of electronic voting machines is that they reduce spoilage. They can lead people through the process and verify choices and prompt for missing choices.
The problem is when you say "Yes" it goes down the rabbit hole and you have to trust it from there. (I used an older lever machine myself which gives you the same impression.)
The "solution" to electronic machines is to use a paper trail for audit/validation. A paper trail can fail for two reasons. First, it may never be followed. Second, if people don't put in their ballot then they can sell their vote and have a receipt for proof.
So wouldn't the logical step be to go back to paper ballots but filled out by machine? You use the electronic machine to do your vote and you get a printed ballot that reflects your choices. You drop that ballot in the box and THAT is what is counted for the votes.
And instead of a screen we could use a big piece of paper that you shove in and align with the levers...
The idea behind the electronic systems and touch screens is that there are a myriad of rules in each state and county about how ballots are formatted and presented. The only way to create a system that can address all of those issues is to go with touchscreens and fancy graphics.
More interesting is supporting the handicapped voters and providing enlarged text options, and voice assistance for navigating the ballot.
Slashdot Mirror
The real fun would be to stuff it into an old Mac Classic toaster and hook it up with the monitor.
Could probably use it to gut and upgrade an older iMac.
Hush MCE Fanless Media Center Edition 2005
Definitely a case designed for media center applications. Too bad about the price I guess ($2,600).
As for the SFF PC's aside from the Shuttle ones the concentration was on the tiny boxes for corporate use.
Here's a mini-ITX system that comes pretty close. info
The Palm example makes more sense to me.
Also the explanation of QUIT is better. I guess I've still got the OS and Application mindset and was applying it to the example unfairly.
I think you've actually touched on the main problem of any development effort like this in your tangent. As long as there is competition for similar applications/commands/whatever you call them then the commercial companies really don't get any benefit from cooperating.
Thanks for the detailed explanation. The idea is definitely intriguing, the implementation is definitely lacking (IMHO of course).
The whole idea behind the Caps Lock key was because it is in fact awkward to hold down a key while typing for long lengths of time. (Also the shift key had the inadvertant effect of shifting numbers to symbols as well.)
As for a single command space isn't that just begging for trouble? What about the specialized commands needed for specialized tasks? Why should QUIT save the document in its current state? What's the exit without saving option then? Are you going to have to do Caps-Lock UNDO to fix a typo?
Holding down the Caps Lock key and typing. I supposed it's touch to top Ctrl+Alt+Del...
My point was that there are a multitude of variables that need to be factored into global climate models well beyond any simple "turn the burner on" scenario.
:-D ).
It is obviously impossible to actually perform full scale experiments due to the size and time-frame necessary (we're not multi-dimensional lab rats after all
The debate over the "hockey puck" shows that there is disagreement over basic foundational data (which only represents a very short time period as far as the Earth is concerned) so drawing conclusions especially to the point of X degrees more and we all die is misleading at best and scientifically dishonest at worst.
You're still guilty of gross oversimplification.
We're not dealing with a static system that has only a single input. Care to speculate on the climate changes caused by the tsunami? Wide spread destruction of ocean plant life and coastal habitats will obviously affect O2 generation and CO2 processing. Did you know that the North Pole moved and that the day got shorter thanks to the earth quake that triggered the tsunami?
We do Computational Fluid Dynamics modelling here at my work and the computer models always have to be checked against physical experiments to validate their results. Additionally, due to the limitations of computers (something that is constantly improving) the detail of the models has changed over time.
As for the hockey stick you can read about it here.
I can't answer your mod questions as I didn't mod the post (can't mod and comment after all).
This of course ignores the whole fact that no one agrees that we've actually "turned the burner on" as far as Earth is concerned.
Further we don't know what would happen if we "turned the burner off". This article suggests that we'd get the ice age routine just like in Fallen Angels.
The other article about Global Dimming also would suggest that there are other changes we aren't accounting for.
It's not a binary either-or problem. It's a complex system that is "described" using things like chaos theory.
BTW, statistical analysis against the old "hockey stick" temperature data suggests that the seed data is flawed and will always create a hockey stick shaped graph no matter what data is fed in to it.
Maybe the speaker could have phrased his comments better at the time but it's terribly ironic when you say something like:
You even qualify your statement with this:
Have you analyzed the context of the comments? Have you looked to see if the professor indeed has a history of disriminatory behavior?
Or, are you simply disciminating against him because of behavior of a group of people?
The "Block images from servername" option is the real godsend. It's always nice to see those lovely gaps in articles where an annoying ad might be. (Yeah, I guess I'm freeloading.)
I've read some about the various stem cell stuff but my own background is a programmer so yeah, I'm not specifically knowledgeable about this stuff.
From my understanding, there are a multitude of issues when dealing with embryonic stem cells. Their very "plenepotent" nature tends to lead to uncontrolled growth with the result being tumors. Their "foreign cell" nature means that you have to deal with the whole range of rejection issues that come with any tissue transplant. I've also read that areas like the spinal chord are more sensitive to foreign tissue than other areas.
Thus, these issues add increased complexity when it comes to developing therapies that would use embryonic stem cells.
Meanwhile, more and more sources of adult stem cells are being found and used in therapies. The fact that the cells can be harvested for the person who is being treated avoids the whole rejection issue. The restricted range of cells that they can become also seems to address the uncontrolled growth problems that have been encountered with the other stem cells. This means that doctors and scientists can concentrate more on the actual application of the cells than in overcoming the tumor and rejection issues.
Thus, "walk before you run."
I may be grossly oversimplifying this, but the point was that industry is voting with their checkbooks as well. The therapies that are actually working are coming from adult stem cells so maybe we should concentrate on them and understand what we can do with those.
That was what I was raising, maybe I phrased it badly, but the issue is authentication.
You have to either trust the other party's authentication process or you have to do it yourself. In a distributed system you have to trust the other party. This means that the technology used to send the authentication information is really a minor issue in the process.
I remember back when we looked at VeriSign to be a certificate authority for our company and they talked about all of their physical security, the signing "ceremony", and all of the personnel checks they went through with their people. This was above and beyond what security was on the box that would actually be the CA host.
If you are looking at a distributed system for e-commerce then you need to address all of those issues as well. Heck, it's more critical because you're dealing with financial transactions and thus financial information needs to be exchanged as well.
So, an OSS "solution" may sound great but it doesn't really address the problem in this case.
Yeah, this may seem like flame-bait but bear with me.
The idea of a federated single-sign-on system suffers the problem of trust. I'm supposed to set up my system to trust your sign-on system that vouches for your identity and provides me with user information. Well, how do I know how to trust you? What kind of security, identity checks, and validation routines did you implement? Do you have a system for revoking id's? Do you have a system for checking for bogus id's? Etc, etc, etc.
There are two problems with any sign-on system. The first is issuing an id/account/card/whatever to a person and ensuring that it actually matches the person. The second is dealing with the associated data. Who can access what data, who can revoke and edit data?
Looked at in this light you see that the technical part of encryption and tokens and what-not is really just the beginning (or even the end) of the battle and a minor part of it at that.
So the point is that having an OSS solution for federated identity really doesn't gain you all that much.
I think part of the problem/conundrum is that you're wondering what action "greyed out" the option rather than which one activates it.
...
With more esoteric or complex options the rule set is usually this options is off unless
That means that it would be difficult to provide a good answer as to why something is greyed out in most cases short of listing the times it is active which might have no relation whatsoever to what you're doing.
As for the "well why don't they just hide it then" question that's a tough one. A consistent menu list is a nice thing for comfort but possibly confusing. The same is true for options that come and go.
First, CA just approved a multi-billion dollar fund for this research as a way to attract companies.
Second, the private groups are spending their money working with adult stem cells (this includes the umbilical cord cells used in the described treatment) as they are actually producing results.
Remember that old saw: "you have to learn to walk before you can fly"? Well it may seem a bit backwards but the walking work for stem cells is to work with the adult ones first. You still have to tackle differentiation issues with them and methods of implanting and controlling but you don't have the immune system issues and you don't have the current horrible experimental track record that you do with embryonic stem cells.
This is all before we even go into the whole ethical "destroy a life to create the cells" issue.
Embyronic stem cells have more potential due to their undifferentiated nature but they pose significantly greater problems than do adult stem cells.
First is the issue of rejection. You're putting foreign genetic material into your body. Chances our your body will reject it without massive immuno-suprresants. This of course makes you more susceptible to infection.
Second is the issue of unregulated growth. Large tumors seems to be one of the main results of animal tests with embryonic stem cells.
Third is this fact. Adult stem cells work and are actively being used in therapies.
Now, repeat after me: There is no ban on embryonic stem cell research. While people love to vilify the Bush administration they seem to forget that this was the first administration to actual provide federal funding for embryonic stem cell research. The only limit was that new lines could not be created or used in federally funded work.
As for the Ronald Reagan angle you can also check the research and see that most scientists do not see any therapeutic use of stem cells for Alzheimers.
Send them as attachments to your gmail account. :-D
The fact that you can take ANY code snippet and put it into a "module" doesn't really get you anything.
You can create a Perl "module" that is simply one piece of code you call a ton of times. You can do the same with JavaScript too.
You can also really create a perl Module that can be invoked and used by bunches of other Perl code. The reason for the stricter Module is that it has rules for being incoporated into Perl and should provide strict type-checking, input validation, and error handling.
This is where the real Module idea comes in. It's not OO "hype" it's as you said good coding practice. It also means that you have to think of a module as a Module and have public, protected, and private sections in it and do real checking and error handling.
Yeah it's more work, but it makes it work.
The "light" part of the application is the user interface. That should always be as light as possible.
The "heavy" part of the application is what does all of the back-end work. Database manipulation, messaging, legacy-system communication and integration, calculations, life cycle management, etc.
The fact is that customers hardly ever know what they want when you start developing. Development is a continuous feedback cycle where you show some, get new requirements, and show some more.
So, maybe you save a week or two of development time using one of the P's instead of good OO design and Java. What happens when they come back a month later and say can you hook in system X to this? What happens when the small system unexpectedly takes off and they need to add in 150+ more concurrent users?
Strong design should not be looked at as an extra expense. Strong design should be looked at as future proofing.
Ummm, last time I saw that I called it development.
The reason for using an OO language is to get you to work with objects and encapsulation. There's a really good reason to do any large enterprise level application using objects. That is that the app is being designed to last longer than one year. That means that during it's life back-end systems are going to change, customer requirements are going to change, and new requirements are going to be introduced.
If you haven't properly separated out all of the portions of your code then when they come back and say "can you give us these two functions running on PDA's?" you're gonna be SOL.
(I spent a year building a system and they promised to transition one of the back-end systems to a whole new platform by the end of the job. They never succeeded but we developed against the old system and the new so it didn't slow us down one bit. THAT'S why you take the time to do OO work.)
It's marketing speak. 417 mm = 16.4 in
So it's "super-slim" compared to a current huge, "fat" CRT but is a real porker compared to an LCD or Plasma screen.
Last time I got IIS and Tomcat talking was after I abandoned the jk2 and went back to the jk connector.
c at_iis6_resources.html
There are some additional steps including permission setting to get IIS to use the redirector.
More info here: http://www.rit.edu/~ack5504/tomcat-iis6-howto/tom
IE didn't compete with Netscape.
IE arrived on every computer, was installed with every Windows OS and had it's icon shoved onto the desktop whether you wanted it or not. (In fact, it was difficult to get it OFF the desktop early.)
Corporate IT groups standardized on IE because "it comes with the OS" and they didn't want to pay for and install a different browser.
Heck, MS had to threaten to revoke Compaq's OEM license (at the time they were the #1 PC seller) to get them to stop installing Netscape.
The fact is that MS "competed" by outspending Netscape, giving their product away for "free", paying bounties to ISP's and IAP's, threatening OEM's, and "leveraging the Window's asset" all in an effort to "cut off Netscape's air supply".
So no, it's not interesting at all.
The main advantage of electronic voting machines is that they reduce spoilage. They can lead people through the process and verify choices and prompt for missing choices.
The problem is when you say "Yes" it goes down the rabbit hole and you have to trust it from there. (I used an older lever machine myself which gives you the same impression.)
The "solution" to electronic machines is to use a paper trail for audit/validation. A paper trail can fail for two reasons. First, it may never be followed. Second, if people don't put in their ballot then they can sell their vote and have a receipt for proof.
So wouldn't the logical step be to go back to paper ballots but filled out by machine? You use the electronic machine to do your vote and you get a printed ballot that reflects your choices. You drop that ballot in the box and THAT is what is counted for the votes.
Instead of buttons, we could use levers.
And instead of a screen we could use a big piece of paper that you shove in and align with the levers...
The idea behind the electronic systems and touch screens is that there are a myriad of rules in each state and county about how ballots are formatted and presented. The only way to create a system that can address all of those issues is to go with touchscreens and fancy graphics.
More interesting is supporting the handicapped voters and providing enlarged text options, and voice assistance for navigating the ballot.