Unfortunately some people need them. My son hearing loss is ascribed to under treatment of sinus infections
Few doctors use an endoscope to examine and sample the nasal passages. So they prescribe blind. That is what's ineffective. When they can see and sample the pus diagnosis and choice of an antibiotic suitable for the specific pathogen is reliable.
Pity the paper didn't point out the effective course of treatment, focusing solely on the known (but common) ineffective approach.
Why is anyone surprised that the quality of the teacher and not the technique is really the high order bit? A great teacher inspires. A good teacher facilitates. Mediocre or worse teachers bore.
Has anyone is this thread wasted the $9 to read what "good" is being held up as? Instead of the iPad native swipe it's right and left arrows. Words are split willynilly (yes it's proper typesetting it's just unpleasant to read) etc
Sure, it's nicely illustrated and some of the animation provides mild entertainment but a simple "nook" translation of the original text is a better read.
Most librarians were probably not math majors, and are unlikely to be expert in statistics. But if you can work your way through the book, you may get enough insight into your data to ask good questions from a local Math department. No doubt some graduate student(s) can get a paper out of it, or at least some applied class project credit.
But if you don't understand what it is you are looking for, you probably won't coax them into figuring out what questions you ought to be asking. So start with the book.
While a free version is on the site, support the work by buying a hardcopy for the library;>
Well put. The upside to the patent system is that innovation can be rewarded better than simple mimicry. Most of the post iphone devices ARE clearly derivative... just as all keyboards are substantially similar.
Obviously, whoever invents the first one does deserve to benefit from it.
Perhaps Nokia and Microsoft will skip the legal posturing and just balance the $10/device "tax" Apple now pays to Nokia and balance will be restored to the Force.
What I think you mean is a remote, distributed team. In a Virtual Team, everyone will report to managers other than yourself... and the challenge is to ensure that their Managers set their goals appropriately... meaning aligned with your goals;> That's an interesting set of challenges, but different than (but may/often coexist with) remote/distributed team issues.
I've been part of, or leading distributed teams on and off since the 1980's. The technical details change; but the core issues are innate.
1. Strive to have a single team; not a group of smaller teams. This has various ramifications, see below, but it's something to keep in mind in many different contexts (single manager, etc.).
2. Good written communications are vital. Even if everyone is a native speaker in the shared language, what isn't written down "didn't happen". twikis blogs, memos, what really matters is that the documents are clear, regularly updated,and located in a "central repository" where anyone on the team can find them.
3. Make everyone remote! That is avoid having clusters of offices where the intra-geo communication is "live in person" and the others are remote. If everyone is "on the same level playing field" people develop the "right reflexes" if they have a group they talk with around the whiteboard or coffee urn, those discussions will be valued differently, and some fraction may not be reflected to others.
4. Other points notwithstanding, do have periodic in person sessions (whole team is nice; but even having smaller batches visiting and having the "local" team meet in person for the event). Ideally, kick off major efforts with a whole team in person meeting. Getting everyone on "the same page" and doing the initial work partitioning collectively gives good value.
5. Openess: all work that could be observed locally, should be observable remotely!
6. Trust is vital; easy to lose, hard to regain. But without trust, subgroups will work defensively and increasingly less productively.
7. Perceptions are critical to maintaining trust. So good "traffic volume", "traffic quality" and "response time". 7.1 Be timely in your responses. IM/IRC, whatever is great and if people are timezone aligned are must have tools. However, even with email (to handle timezone skew) responded early in your shift... your remote coworkers may well be working late (or at least will notice) if you don't deign to respond early in your shift to something urgent.
8. Write minutes for all phone conferences. Watch the video "Meetings Bloody Meetings" by John Cleese.
Experience says that the specific tools are not critical... anything faster than 300baud, and virtual punch cards can work (yes, early IBM "email" was often a virtual print to someone else's virtual card reader) can be made to work. Focus on the people and their interactions... and pick tools which everyone, everywhere on your team can be comfortable with. That's far more important than all singing, dancing spiffy technology.
Folks in the pool are merely potential juriors. They may well be disqualfied for other reasons.
Yes, the DA needs to have good data security so that actual juror names aren't leaked (and one would hope they'd extend such care to potential jurors).
I don't see how the facebook angle changes that any; unless the names are leaked and the juror later updates their page to admit what trial(s) they were part of.
The point of voir dire is to discover if the potential jurors are predisposed in some fashion (e.g. is a strong advocate of drug use, and it's a drug trial).
If someone has posted repeatedly on the topic (or the person) of the defandant or some of the witnesses in a semi-public forum, shouldn't that be fair game?
Facebook isn't like inviting people into your home, it's somewhere between the newspaper and the watercooler.
Perhaps it's "in scope" or not; obviously someone has to try it, and then the judges have to sort it out (or the Legislative branch has got to get ahead of the curve for a change).
But it doesn't seem Faustian... and wifi access is sufficiently low value as to no more constitute a bribe than if the Court provides free coffee and water.
it is interesting to know that this is being done; clearly if one does have strongly held beliefs that would influence the selection one might want to actively express it in that forum (or suppress it, depending on one's beliefs about such things)
Seems like the sort of information that the Defense should have as well, so one would think that the Prosecution would have a duty to share redacted results
No doubt many sites are "lazy", or "old-fashioned" Solaris has had "Role Based Access Control" for many years. Different tasks can be farmed out/delegated to different people.
Not that anyone is likely to be reading this far down with such a silly subject line, but for grins I bought a book from the new google store, "saved to device" told the download chooser to open it with/usr/bin/calibre and it "just worked" and then downloading it into a nook "just worked".
Doesn't change the sins of DRM, etc. but google did a bang up job of integrating with existing hw.
A simple two factor solution, requiring no additional hardware for the average consumer has long existed. Leverage the existing cellphone. There's a commercial firm with a packaged solution (www.PhoneFactor.com) out there.
However, the cost of such services+customer resistance may well keep it out of wide spread usage.
Just because it's possible to be safer, doesn't necessarily make it cost effective.
However, most customers would probably be less resistant to using their phone than carrying yet another device (worse, possibly one device per security aware business).
You haven't provided anywhere near enough information to give useful advice. What are you trying to accomplish? What are the users doing? What tools are they using (releases count), etc. Who would be using Linux and why (if it's going to be low cost windows replacements, then perhaps rehink your choice of distribution...)
You need to trade off budget, vs. requirements vs. desiderata.. it's why IT is a profession not a hobby;>
As to the question you asked, if you keep things on Exchange, and CIFS everyone can share. If you migrate to IMAP based servers everyone can share, except for calendaring (outlook's Calendar features are not the same as what you get with Google Apps, so be careful what you threaten your user community with).
How do Sales and Marketing communicate? What do they need to collaborate on? If it's just PDF documents from Marketing->Sales then the question is pretty meaningless. If they need to coauthor documents you might have very different Requirements.
Personally I work in a mixed Windows/Linux environment, and sometimes use personal Macs attached. Engineering is CentOS based, my Linux laptop is Ubuntu, my Windows laptop is XP and my Windows VM inside of the Ubuntu environment is Win7u. Macs are aged PPC based devices.
Depending on just what you are trying to share and WHY makes all the difference... but it can be done. Trivially in many cases; less so in others.
As others aptly noted, taking Excel away from power users is seldom a successful strategy.
Apache to Oracle: Do what we say or we'll resign! Oracle to Apache: Sayanora
I don't know that they should stay, but if they want to have any influence working with Oracle, aligned along Oracle's self interest is the only way to have impact.
Declaring "war" and making threats is highly unlikely to cause any useful change in Oracle's direction.
Surely the OpenSolaris experience illustrates just how Oracle behaves w.r.t. threats.
I know the internet sometimes behaves like a memoryless system (odd, since google caches "everything") but this is a bit absurd.
At stake isn't Java, but Java ME. This was thrashed out days ago. People like Gosling observed that Oracle is "right" in that Google misbehaved, and did it knowingly and over Sun's objections.
If memory serves (and wikipedia can help for those who don't recall), the first systems were shipped with just an assembler. Livermore and Los Alamos pulled together the first OS for it. COS (the Cray Operating System) came a little later. The Labs stuck with their own OS for quite some time.
I haven't seen a source bundle, but since the OS shouldn't have been classified and it was paid for 100% tax dollars, someone probably could score a copy (Freedom of information request??).
Good pointer. "On the AndroidOS, most of the system facilities like Audio, Graphics, OpenGL and Telephony are not available directly to a C-based applications, they are only exposed through the Dalvik Java APIs residing in one of the Java.* namespaces or the Android.*...."
So, one would think that the result would still be subject to potential Legal questions (less kindly, attack) by Oracle.
It's nice for M$ to try to disclaim Oracle's potential rights, but while IANAL, I don't think it works that way.
Interestingly, I imagine it might be better if M$ provided the code themselves rather than via Mono... as M$ probably still has active cross licensing with Oracle via Sun.
In any event, the key point is that there isn't going to be an quick and easy workaround for Google.
If they are just "porting" then I'd have expected that.net would sit atop Dalvik... which would make the entire project just as "tainted" under the Oracle theory.
Or is this going to be "raw" bypassing anything that Google neglected to ensure rights to use?
Sadly this sort of thinking even survives into shipping products.
There are appropriate two factor authentication solutions. http://www.phonefactor.com/ as an example. I've never worked with that company, but a quick search hit them first.
There are better ways to arrange for remote access than hardcoded backdoors. It's one thing to use the technique for Grandma's wireless accesspoint and another to leave it in a production IT environment.
Except that there is absolutely no evidence that it got any incremental developers "interested in Solaris". Thinking it would in the future is probably wishful thinking.
Feel good ranting amongst ourselves isn't evidence. Yes, we like Open Source, otherwise we wouldn't be/. regulars.
Developers could, and did, get interested in Solaris from Solaris Express before it was killed to make OpenSolaris the "one way forward".
I haven't been with Sun for some years, and was never with Oracle. But the people there did have metrics, and while people may say unkind things about Larry Ellison, it is a mistake to think him (and his staff) stupid.
Nor are they purely motivated by $$/quarter, or they never would have invested in Sun.
That isn't to say profits aren't important to them; but Schwartz converse ("we lose money every quarter, but we'll make it up in future revenue") was suicidal and the eventual result is now clear even to the most optimistic.
Turning Solaris into an open project might well have worked better earlier (think SunOS 4.1.x... could have gone BSD... since it started as BSD;>). The reasons for not doing that are indubitably financial (ATT paid Sun many $$$ directly and indirectly) and it's hard to go back (even if Management had thought that a wise course).
It clearly didn't have the desired results, and if Oracle Management believes they can get effective change faster by narrowing focus, one can see why they are interested in trying.
To a first approximation... not at all. For folks with enough $$$ (and really high performance requirements) in memory databases exist now (even Oracle and SAP) as well as smaller players with clever schemes to minimize the memory impact.
SSDs are a lot faster than spinning disk, a lot slower than DRAM. I doubt we'll be looking at a third major way to organize/structure databases... the in-memory and "on disk" architectures will continue.
Whether an SSD then looks enough like one or the other to determine which one to select is an interesting question, but IMNSHO that's a relatively small delta vs. the sort of major transformation you allude to.
Even worse, if they are using wires to shore (for reasonable latency, high bandwidth) they will be hostage to just as many (and perhaps worse) failures due to network connectivity (worse than a well designed ground based facility, as few... if any... ports were designed around notions of data redundancy.
Of course, building them far in the deep ocean has benefits (Legal and practical), but then there's that darned latency issue.
Slashdot Mirror
Unfortunately some people need them. My son hearing loss is ascribed to under treatment of sinus infections
Few doctors use an endoscope to examine and sample the nasal passages. So they prescribe blind. That is what's ineffective. When they can see and sample the pus diagnosis and choice of an antibiotic suitable for the specific pathogen is reliable.
Pity the paper didn't point out the effective course of treatment, focusing solely on the known (but common) ineffective approach.
Why is anyone surprised that the quality of the teacher and not the technique is really the high order bit? A great teacher inspires. A good teacher facilitates. Mediocre or worse teachers bore.
Bored students do poorly.
No ex post facto laws eh?
Has anyone is this thread wasted the $9 to read what "good" is being held up as? Instead of the iPad native swipe it's right and left arrows. Words are split willynilly (yes it's proper typesetting it's just unpleasant to read) etc
Sure, it's nicely illustrated and some of the animation provides mild entertainment but a simple "nook" translation of the original text is a better read.
Data mining with Rattle and R .... http://rattle.togaware.com/
Most librarians were probably not math majors, and are unlikely to be expert in statistics. But if you can work your way through the book, you may get enough insight into your data to ask good questions from a local Math department. No doubt some graduate student(s) can get a paper out of it, or at least some applied class project credit.
But if you don't understand what it is you are looking for, you probably won't coax them into figuring out what questions you ought to be asking. So start with the book.
While a free version is on the site, support the work by buying a hardcopy for the library ;>
Well put. The upside to the patent system is that innovation can be rewarded better than simple mimicry. Most of the post iphone devices ARE clearly derivative ... just as all keyboards are substantially similar.
Obviously, whoever invents the first one does deserve to benefit from it.
Perhaps Nokia and Microsoft will skip the legal posturing and just balance the $10/device "tax" Apple now pays to Nokia and balance will be restored to the Force.
Too generic like "windows" ( M$); "Reality", "English" (Microdata versions of PICK OS and programming language) and McDonalds going after Mc* etc. ?
Indeed the usual Legal advise is to keep a Trademark one needs to aggressively enforce it.
So far both sides appear to be following the textbooks. So nothing newsworthy. Not that the system seems sensible but it is what is is.
What I think you mean is a remote, distributed team. In a Virtual Team, everyone will report to managers other than yourself ... and the challenge is to ensure that their Managers set their goals appropriately ... meaning aligned with your goals ;> That's an interesting set of challenges, but different than (but may/often coexist with) remote/distributed team issues.
I've been part of, or leading distributed teams on and off since the 1980's. The technical details change; but the core issues are innate.
1. Strive to have a single team; not a group of smaller teams. This has various ramifications, see below, but it's something to keep in mind in many different contexts (single manager, etc.).
2. Good written communications are vital. Even if everyone is a native speaker in the shared language, what isn't written down "didn't happen". twikis blogs, memos, what really matters is that the documents are clear, regularly updated,and located in a "central repository" where anyone on the team can find them.
3. Make everyone remote! That is avoid having clusters of offices where the intra-geo communication is "live in person" and the others are remote. If everyone is "on the same level playing field" people develop the "right reflexes" if they have a group they talk with around the whiteboard or coffee urn, those discussions will be valued differently, and some fraction may not be reflected to others.
4. Other points notwithstanding, do have periodic in person sessions (whole team is nice; but even having smaller batches visiting and having the "local" team meet in person for the event). Ideally, kick off major efforts with a whole team in person meeting. Getting everyone on "the same page" and doing the initial work partitioning collectively gives good value.
5. Openess: all work that could be observed locally, should be observable remotely!
6. Trust is vital; easy to lose, hard to regain. But without trust, subgroups will work defensively and increasingly less productively.
7. Perceptions are critical to maintaining trust. So good "traffic volume", "traffic quality" and "response time". ... your remote coworkers may well be working late (or at least will notice) if you don't deign to respond early in your shift to something urgent.
7.1 Be timely in your responses. IM/IRC, whatever is great and if people are timezone aligned are must have tools. However, even with email (to handle timezone skew) responded early in your shift
8. Write minutes for all phone conferences. Watch the video "Meetings Bloody Meetings" by John Cleese.
Experience says that the specific tools are not critical ... anything faster than 300baud, and virtual punch cards can work (yes, early IBM "email" was often a virtual print to someone else's virtual card reader) can be made to work. Focus on the people and their interactions ... and pick tools which everyone, everywhere on your team can be comfortable with. That's far more important than all singing, dancing spiffy technology.
http://en.wikipedia.org/wiki/Amdahl's_law Really, can anyone educated enough to do scientific programming NOT know what to expect?
Folks in the pool are merely potential juriors. They may well be disqualfied for other reasons.
Yes, the DA needs to have good data security so that actual juror names aren't leaked (and one would hope they'd extend such care to potential jurors).
I don't see how the facebook angle changes that any; unless the names are leaked and the juror later updates their page to admit what trial(s) they were part of.
The point of voir dire is to discover if the potential jurors are predisposed in some fashion (e.g. is a strong advocate of drug use, and it's a drug trial).
If someone has posted repeatedly on the topic (or the person) of the defandant or some of the witnesses in a semi-public forum, shouldn't that be fair game?
Facebook isn't like inviting people into your home, it's somewhere between the newspaper and the watercooler.
Perhaps it's "in scope" or not; obviously someone has to try it, and then the judges have to sort it out (or the Legislative branch has got to get ahead of the curve for a change).
But it doesn't seem Faustian ... and wifi access is sufficiently low value as to no more constitute a bribe than if the Court provides free coffee and water.
it is interesting to know that this is being done; clearly if one does have strongly held beliefs that would influence the selection one might want to actively express it in that forum (or suppress it, depending on one's beliefs about such things)
Seems like the sort of information that the Defense should have as well, so one would think that the Prosecution would have a duty to share redacted results
No doubt many sites are "lazy", or "old-fashioned" Solaris has had "Role Based Access Control" for many years. Different tasks can be farmed out/delegated to different people.
Auditing, etc. all provided.
Not that anyone is likely to be reading this far down with such a silly subject line, but for grins I bought a book from the new google store, "saved to device" told the download chooser to open it with /usr/bin/calibre and it "just worked" and then downloading it into a nook "just worked".
Doesn't change the sins of DRM, etc. but google did a bang up job of integrating with existing hw.
Nicely done.
Google books also are downloadable in EPUB; and the Google site has explicit instructions for how to work with a nook.
What am I missing?
A simple two factor solution, requiring no additional hardware for the average consumer has long existed. Leverage the existing cellphone. There's a commercial firm with a packaged solution (www.PhoneFactor.com) out there.
However, the cost of such services+customer resistance may well keep it out of wide spread usage.
Just because it's possible to be safer, doesn't necessarily make it cost effective.
However, most customers would probably be less resistant to using their phone than carrying yet another device (worse, possibly one device per security aware business).
You haven't provided anywhere near enough information to give useful advice. What are you trying to accomplish? What are the users doing? What tools are they using (releases count), etc. Who would be using Linux and why (if it's going to be low cost windows replacements, then perhaps rehink your choice of distribution...)
You need to trade off budget, vs. requirements vs. desiderata .. it's why IT is a profession not a hobby ;>
As to the question you asked, if you keep things on Exchange, and CIFS everyone can share. If you migrate to IMAP based servers everyone can share, except for calendaring (outlook's Calendar features are not the same as what you get with Google Apps, so be careful what you threaten your user community with).
How do Sales and Marketing communicate? What do they need to collaborate on? If it's just PDF documents from Marketing->Sales then the question is pretty meaningless. If they need to coauthor documents you might have very different Requirements.
Personally I work in a mixed Windows/Linux environment, and sometimes use personal Macs attached. Engineering is CentOS based, my Linux laptop is Ubuntu, my Windows laptop is XP and my Windows VM inside of the Ubuntu environment is Win7u. Macs are aged PPC based devices.
Depending on just what you are trying to share and WHY makes all the difference ... but it can be done. Trivially in many cases; less so in others.
As others aptly noted, taking Excel away from power users is seldom a successful strategy.
Apache to Oracle: Do what we say or we'll resign!
Oracle to Apache: Sayanora
I don't know that they should stay, but if they want to have any influence working with Oracle, aligned along Oracle's self interest is the only way to have impact.
Declaring "war" and making threats is highly unlikely to cause any useful change in Oracle's direction.
Surely the OpenSolaris experience illustrates just how Oracle behaves w.r.t. threats.
I know the internet sometimes behaves like a memoryless system (odd, since google caches "everything") but this is a bit absurd.
At stake isn't Java, but Java ME. This was thrashed out days ago. People like Gosling observed that Oracle is "right" in that Google misbehaved, and did it knowingly and over Sun's objections.
One summary is available at: http://www.infoworld.com/d/developer-world/why-oracle-was-right-sue-google-392-1?page=0,1
If memory serves (and wikipedia can help for those who don't recall), the first systems were shipped with just an assembler. Livermore and Los Alamos pulled together the first OS for it. COS (the Cray Operating System) came a little later. The Labs stuck with their own OS for quite some time.
I haven't seen a source bundle, but since the OS shouldn't have been classified and it was paid for 100% tax dollars, someone probably could score a copy (Freedom of information request??).
Good pointer. "On the AndroidOS, most of the system facilities like Audio, Graphics, OpenGL and Telephony are not available directly to a C-based applications, they are only exposed through the Dalvik Java APIs residing in one of the Java.* namespaces or the Android.* ...."
So, one would think that the result would still be subject to potential Legal questions (less kindly, attack) by Oracle.
It's nice for M$ to try to disclaim Oracle's potential rights, but while IANAL, I don't think it works that way.
Interestingly, I imagine it might be better if M$ provided the code themselves rather than via Mono ... as M$ probably still has active cross licensing with Oracle via Sun.
In any event, the key point is that there isn't going to be an quick and easy workaround for Google.
If they are just "porting" then I'd have expected that .net would sit atop Dalvik ... which would make the entire project just as "tainted" under the Oracle theory.
Or is this going to be "raw" bypassing anything that Google neglected to ensure rights to use?
Sadly this sort of thinking even survives into shipping products.
There are appropriate two factor authentication solutions. http://www.phonefactor.com/ as an example. I've never worked with that company, but a quick search hit them first.
There are better ways to arrange for remote access than hardcoded backdoors. It's one thing to use the technique for Grandma's wireless accesspoint and another to leave it in a production IT environment.
Except that there is absolutely no evidence that it got any incremental developers "interested in Solaris". Thinking it would in the future is probably wishful thinking.
Feel good ranting amongst ourselves isn't evidence. Yes, we like Open Source, otherwise we wouldn't be /. regulars.
Developers could, and did, get interested in Solaris from Solaris Express before it was killed to make OpenSolaris the "one way forward".
I haven't been with Sun for some years, and was never with Oracle. But the people there did have metrics, and while people may say unkind things about Larry Ellison, it is a mistake to think him (and his staff) stupid.
Nor are they purely motivated by $$/quarter, or they never would have invested in Sun.
That isn't to say profits aren't important to them; but Schwartz converse ("we lose money every quarter, but we'll make it up in future revenue") was suicidal and the eventual result is now clear even to the most optimistic.
Turning Solaris into an open project might well have worked better earlier (think SunOS 4.1.x ... could have gone BSD ... since it started as BSD ;>). The reasons for not doing that are indubitably financial (ATT paid Sun many $$$ directly and indirectly) and it's hard to go back (even if Management had thought that a wise course).
It clearly didn't have the desired results, and if Oracle Management believes they can get effective change faster by narrowing focus, one can see why they are interested in trying.
To a first approximation ... not at all. For folks with enough $$$ (and really high performance requirements) in memory databases exist now (even Oracle and SAP) as well as smaller players with clever schemes to minimize the memory impact.
SSDs are a lot faster than spinning disk, a lot slower than DRAM. I doubt we'll be looking at a third major way to organize/structure databases ... the in-memory and "on disk" architectures will continue.
Whether an SSD then looks enough like one or the other to determine which one to select is an interesting question, but IMNSHO that's a relatively small delta vs. the sort of major transformation you allude to.
Quite true.
Even worse, if they are using wires to shore (for reasonable latency, high bandwidth) they will be hostage to just as many (and perhaps worse) failures due to network connectivity (worse than a well designed ground based facility, as few... if any... ports were designed around notions of data redundancy.
Of course, building them far in the deep ocean has benefits (Legal and practical), but then there's that darned latency issue.