"folks even in the software sector a price/revenue of 1 billion to 100 million/yr is pretty rich."
You watch too much CNBC. P/E or P/R ratios in isolation are meaningless. Saying that a stock is overvalued because it has a P/R ratio of 10 (or 20...or 30...) is like saying that a stock is overvalued because the CEO is short.
For example, is a stock overvalued at a P/R of 20 if it's expected forward growth rate in revenue is 20%? How about 50%? This is why the PEG ratio was invented--it allows you to use the P/E ratio in some sort of context, which is critical...
"data is useful to only a finite number of users....there are still a finite number of lateral "hops" that a piece of data can make before it becomes irrelevant."
You're right about this, but it doesn't do anything to reduce the complexity of routing on a network like this. The addition of geographic routing to the traditional task group/hierarchical routing significantly increases the complexity of the routing decisions that must be made. And pretty much anything you do to accomodate this complexity is a trade-off in terms of bandwidth. You can't very well do hop-counting to time out messages--it's quite possible, in an ad-hoc network, that a geographically nearby node is quite distant, topologically. So you have to come up with a better way to "expire" these messages, while still assuring that the people who need them get them, and also making sure that a consistent picture of the battlefield is maintained by everyone while they're moving around from place to place.
"A division commander or his staff don't want or need information on each private anymore than a Fortune 50 CEO wants information on each employee - it's just noise. Just as a piece of information can only make so lateral hops before it becomes too distant to become useless, it can only make so many vertical hops up or down before it becomes useless."
Yes and no. The commander certainly doesn't want to see all of that data all at once, but he'll raise all kinds of hell if he can't get access to it when he does want it. So now you have to keep this data available somewhere in such a way that the commander can get it when he needs it. Further, even if you don't worry about keeping detailed information around, how exactly does the information get aggregated/summarized and resolved (e.g when N different people report on the same event, how do you filter that down?) when you're underlying network is completely dynamic? The way the military does it now is through a human-in-the-loop report cycle. This takes hours, if not days. It's one of the bottlenecks that the military wants to bypass with a network system like SAS. But it's very hard to automate.
My original point was that the things the military wants out of a system like this are significantly harder to do in an automated way than just P2P networking. Routing is just one of the concerns (though a big one), when you've got to worry about QoS, data storage and consistency. In my mind, the whole thing is less like a P2P network, and more like a gigantic, ad-hoc, distributed, intelligent database--and you've got all the same demands and expectations that you would put on a regular old Oracle database sitting behind a firewall somewhere. All in all, it's a very challenging problem.
"a squad leader in Alpha Company probably has no reason to communicate with another squad leader in Charlie company, so they can be on different networks. It also makes "searching" issues non-existent- the number of users on any given network is extremely limited. The network doesn't grow, it subdivides, so the N^2 problem doesn't kick in."
Well, not quite. First, the system needs to keep a record of friendly force positions, estimated enemy force positions, and other such battlefield information (the consistent tactical picture). This information has to get to whoever might need it--which may mean the people at the next echelon up, or all the people in close geographic proximity to a particular event, or soldiers involved in the same mission, or friendly units near a fire control line, etc.--depending on the type of information being processed. Thus, a system like this has to maintain complex routing rules at a contextual level, in addition to the routing difficulties that are specific to ad-hoc network systems. Imagine if gnutella had to know what file types had to go to particular users, based on preferences the users specify when they log on to the network--now imagine that the users can change their preferences at any time, and that gnutella is always required to give them all of the relevant files corresponding to their preferences. This gets messy, to say the least.
Second, this type of system is wireless and dynamic, yet nodes must be *guaranteed* some level of baseline communication. In a life or death situation, it is unacceptable to lose communication, or to be fed innaccurate information that may cause you to make misguided decisions. Yes, existing systems have this problem too, but if you want real soldiers to go to the effort of wearing these boxen and using the data they provide, you have to do better than the existing systems.
Third, how do you guarantee that the higher-ups always have a complete and accurate picture of the battlefield? Now, how do you do that without trashing the network (think 10,000 grunts constantly sending their positions over a low-bandwith RF link back to the commander)? Again, existing systems don't do this well either, but the idea is to do better than the existing systems.
The fact is, the total scope of the situational awareness problem is much larger than that faced by gnutella and other P2P systems. Sure, if you dumb everything down to the point where you're doing existing military communications over a computer instead of a radio, you won't run into these nasty little snags, but you also won't get anyone to use these devices (as you might suspect, these ultra-cool radio/computer things weigh more than a regular radio, and soldiers do NOT like to carry more shit around with them:-)
It's odd that this just made it into the media, as this project (known as SUO SAS) has been around for the better part of 2 years now--not counting the previous phases of development, which go back several more years.
While the article got a lot of things right, it was also a good portion of hype. I worked on the networking software for this (which is built on top of the TAO CORBA ORB, btw), and while it is conceivable that it might scale up to 10,000 nodes, it is unlikely to do so in it's current form (well, as of a few months ago, anyway). In fact, we faced more or less the same scalability problems that any ad-hoc wireless network system faces, plus the added complexities of having to guarantee consistent tactical picture maintenance (how do you keep a consistent data 'picture' of an entire battlefied among 10,000 separated nodes, with no guarantees on connectivity, or even addressing between any two particular nodes? Now, how do you tackle message-based quality-of-service on top of this mess?). So, for those of you wondering, the problem tackled by this system is a lot bigger and more complicated that than faced by peer-to-peer filesharing systems (think superset of the gnutella problem), and the algorithms we were developing weren't perfect--or even good, necessarily. The problems facing ad-hoc networking are certainly as unsolved and difficult as they were before.
Another important note is that while we ultimately got our way and were able to use Linux for development (partly because we absolutely refused to work with a platform where we didn't have access to the network stack code), it was kind of an uphill battle with DARPA to do so. Linux still isn't qualified to be running on any type of deployed military system, and believe me, we heard about it constantly (I still shudder at the thought of trying to do our development in Windows...)
All that said, the concept of the project was/is pretty cool, but, as always, reality is less dramatic than its press release. If you want more info on the project and related research, here are some links:
"Python would be used for higher level control of an application, and Java would be used for implementing the lower level that needs to run relatively efficiently."
I never thought I'd see the day when Java was mentioned in the same sentence as "lower level" and "efficient."
What is often left out of the Emily Rosa story is that her father was a PhD researcher at a university. While the work _was_ good, and it _was_ funny, it's been pretty well documented that Dad had a big hand in the discovery process.
But the News is always looking for a good headline...
I am sympathetic to the people who hate domain-squatters (I have a domain being squatted myself, and I can't afford the dispute fees), but since when did the corporate world claim a manifest destiny to future domains? What about those would-be owners who don't want to squat, yet don't own a trademark or a company in meatspace?
As long as the semantics of domain names are ignored (a for-profit company should not have rights to.org or.net), domains should be available through a competitive process. Sure, there's the risk of squatting, but IMO, the internet should stay a free, wild environment, rather than becoming another corporate sponsored and controlled media outlet.
DARPA, like anything else governmental, is inherently politcal. While they have to frame these proposals as public processes, the fact is, if you weren't working on this proposal months ago, well before it was first published, you don't have a chance. I'll guarantee you that there are already 5-10 different labs working on the problem, who have already extensively discussed the DARPA program manager's expectations (most likely with the program manager or the program manager's close colleagues).
Yes, it's a very inbred, good-ol-boys type of process, but that's life in military research...
"More generally, software (and all IP) developed with public money generally belongs to the public."
No, it doesn't. As a former contractor employee, I was frustrated many times in my attempts to get ahold of publicly-funded software. In fact, a very large percentage of publicly-funded software ends up being proprietary, since the government agrees to those conditions to get some special consideration.
Don't confuse government use with public use--while the government can (and usually does) require unlimited government use of software developed with government funds, this right does NOT automatically translate to the public at large.
"Unless it was explicitly stated in the terms of that contract that the code will remain open, (which, I assure you, it doesn't) then the DoD can do whatever they wish."
No, no, no...
The government is a contractee, just like anyone else, and they're governed by the same laws. If they didn't specify licensing in the contract, and the contractor is the rightful owner of the code, then the government is stuck. The owner gets to name the license.
"The DoD owns the code, because they paid you to develop it."
Again, no. The developer owns the code unless otherwise specified by the contract. Just because the DoD paid the contractor does not mean the DoD has property rights to the contractor's product.
"How is the 3d matrix of bone cell division, encoded in the four bit code of dna?"
Well, it's not a "four bit" code--not in the way you imply, anyway. That's a bit like saying that computers are amazing to represent the things they do, because they have only a "two bit" code.
The complexity is represented by the X^4 combinations of nucleotides. When X is large, the DNA language is quite descriptive. What I'm trying to say, ultimately, is that I don't think there's that much compression going on. In fact, it's been pretty well established that evolutionary pressures usually don't optimize for size in complex organisms.
Apparently, Mr. Hubert is a brilliant engineer, a brilliant computer scientist, a brilliant concert pianist, and a brilliant inventor. Oh yeah, and a brilliant architect too. I bet he even cleans the floors in the mathematics wing at MIT, and lives in southie with his brilliant med student girlfriend...
I know these press releases are designed to talk people up, but MIT's have to be the worst of all. Yeah, Mr. Hubert's a smart guy. No matter how smart he is, he's probably only brilliant at one of the above. There just isn't enough time in the day to be brilliant at everything.
...you reinvented a wheel. In particular, the MAPI architecture.
While much M$ software is poorly designed, MAPI is an exception. MAPI is a pretty flexible, intelligent architecture for all things messaging.
MAPI allows you to do things like substitute message stores, address books stores, etc., by treating them as abstract components. Exactly what you're claiming to have done with your "data store API"
I don't want to be too critical, but I hope you folks looked at MAPI before you went out inventing another API...
Re:Yes, Let's Keep Perspective...
on
The Challenger
·
· Score: 2
"The earthquake would have happened no matter what (I believe that reliable earthquake prediction won't happen for about 100 years, and earthquake prevention technology will take at least a thousand years from that point). The Challenger incident was a totally preventable accident."
If the majority of the world's population wasn't living in shanty-town conditions, we wouldn't see 30,000-100,000 people dead from an earthquake.
"I'm having a hard time understanding how you could have a firm grasp on C++ & OO theory yet not know Java. Why not just learn it?"
At the risk of sounding like a lawyer, define "know." At various points in the past, I've sat down and "learned" the Java syntax, core philosophies, etc. But I don't use it. Ever. So I wouldn't want to go into a job interview that demanded that I "know" Java. Sure, I know the theory of Java, and I may even know some of the syntax, but I couldn't hold a candle on a day-to-day basis with someone who used Java professionally.
It's the difference between "knowing" a language and "thinking" in a language, I believe. I know a lot about OO design and development, but switching from C++ to Java would leave me stranded on an island of inefficiency for a while--because I don't think in that language.
"Exciting Web development firm seeks creative, driven programmers with experience in Perl, C/C++, Java, XML and OO technologies. Extreme programming and OO design skills a plus."
I've been around this block more than once, and as a technical job seeker, this is an ad I'd ignore.
Why?
First off, even though the intent may have been to attract people who *aren't* language specific, the laundry-list of high-level languages is distracting at best, and intimidating at worst. For example, I am a good C++ coder, and a not a half-bad OO designer. I know a lot about OO theory, and I've probably read every classic book on OO design and development that you have. Nevertheless, I don't know Java, and I don't know XML as if I were working with it full-time. But when I read your ad, I find these skills listed up there in equal stature with C++ and "OO technologies." So what is it? Do you do C++ and OO design, or do you do Java programming, or do you do XML programming? Or do you do mostly Perl coding? Some combination of the three? What priority? From what I've just read, they're all equally important.
Second off--believe it or not--I'm shopping for you, not the other way around. You say that you want only the best. You say that you know this is a tough hiring market. But your ad doesn't do *anything* to discriminate itself from the thousands of other ads that look just like it. Furthermore, your list of "requirements" looks generic--I want to have some idea of what a company actually *does* on a day-to-day basis, before I go through the hassle-cycle of trying to contact you/submitting resume/calling for response on daily basis. So when I read your ad, I have to wonder: are you a Java house that does some Perl? Are you a hard-core C++ house? Do you develop primarily using an OO methodology, and if so, do you do it in a proper OO language, or do you try to bend other languages to your will? As a job seeker, I could try to deduce it from the subtle wording of your ad, or I could just jump one ad down the list to the company that has listed it's requirements as strong preferences, not just a laundry list of hip technologies.
Finally, even if I did decide to call you up for some reason (maybe a slow ad day in the paper), if you invited me for an interview and grilled me mercilessly (or even worse, started the grilling on the phone), I'd probably walk out (or hang up) on you. As a smart person, I am actually *less* likely to sit through a defense of my intelligence for a complete stranger. Life's too short--and there are far too many good jobs--to sit through an interview like that. I think other Smart People (tm) would agree with me here--the jobs that put you through the Microsoft-Patented-Intelligence-Test are usually a little too self-important to really bother with, unless you have some burning desire to work there to begin with (a.k.a "Rudy" syndrome: "I've always wanted to go to Notre Dame...").
So basically, if you did manage to get me to call you with your generic ad, you'd likely turn me off completely with your interview methodology. My advice to prospective employers is to place an ad like this (let's assume you're a C++-centric shop):
"Exciting software development firm seeks highly creative, independent thinkers to assist in the development of it's C++-based product line. Experience with C++ is preferred, but all candidates with relevant OO language experience will be considered. Experience with any of XML, Java or Perl a plus."
Obviously, fill in your own skills as needed, but I think the concept is clear--cast a wide net, and use the interview to filter down the candidate list to those you would like to work with. And as for trying to filter "intelligent" candidates out--well, you're going to have to rely on gut instinct here. DON'T attempt to grill a candidate on obscure principles, or language details, or even bizarre algorithms, whatever you do. Instead, talk to the candidate for a while, ask them pertinent, interested questions about their previous work...maybe even ask them to take part in a code review (your code or theirs). There are lots of different approaches to this problem that will give you an idea of their skill level, and won't require that you be a draconian interviewer.
Anyhoo...hope this helps someone. I couldn't let the above ad go "unanswered"...;)
"there's absolutely no value in forking a DTD. Unless you think there was maybe some value in all of the "modifications" Netscape and Microsoft made to the HTML DTD, for a simple example - its the same in this case."
Apples and Oranges.
HTML is controlled by the w3c--a standards body more or less independent of any particular company. Sure, M$ and Netscape had a lot of pull on HTML, but they *should* have, given that they *were* the browser market for a long time.
In this case, we have a particular bioinformatics company graciously offering up their own "public domain" DTD as a standard for the rest of the industry (how generous). And a major scientific journal latching on to it. The only problem is, that same bioinformatics company must approve any and all changes to the "standard"! It would be the same if HTML were a copyrighted property of Netscape, Inc.
It would be nice if the bioinformatics community could organize and form it's own XML standards body, a la the w3c. An agreed-upon standard is almost always better than a legislated standard.
"I would agree that bioxml servers as a much better licensing model for the community than GEML, its worth mentioning that at the current time they do not compete. GEML appears to be about gene expression, and bioxml has no DTD's addressing this."
True. I do think that bioxml's goal is the same as GEML, but they're just not as far along as GEML (yet). It's just bothersome to me that a company-owned and controlled format like GEML could become very prevalent. I would still much rather see something like bioxml succeed instead. I hope they don't give up because of this...
The GEML Format is a free, public-domain, open standard created and licensed by Rosetta Inpharmatics, Inc. ("Rosetta") in order to define a single, distinct format for handling gene expression data and avoid proliferation of incompatible variations.
...
You may not modify, lease, loan, sell, charge for, or create derivative works of the GEML Format or documentation without written permission from Rosetta.
So nobody can fork the standard without first consulting with Rosetta Inpharmatics. Wonderful. I just love their definition of "open standard."
This looks like another corporate-buddy move by a major scientific journal, much like the Science/Celera deal a few weeks back...
The bioxml project has been trying to do this very thing for quite a while now. Previous to that, there was the biomolecular sequence markup language (BSML), and I don't think it ever came close to becoming a standard. The problem that these efforts always run into is the sheer diversity of opinion on how biological data should be represented. Molecular biologists and computational biologists can't even agree on the basic things, like how to represent sequence regions, let alone more complex issues, like annotation syntax.
Why Nature chose GEML as a standard is unclear--the article doesn't present a compelling argument for it over the alternatives, and the choice seems a little arbitrary. It'll be interesting to see what impact this has on the other projects, and how open the standard will be to extension and modification.
"It's common. And it's going to get worse in all major metropolitan areas over the next 10-20 years. Get used to it.
It wasn't common until California residents decided that a deregulated power was the way to go. Nevermind that this "free market" was/is in direct conflict with Calfornia's ecological mindset (do you know how much $$ some of the new environmental compliance equipment costs?), and that basic economic theory will tell you that power costs will go up when demand exceeds supply (as it has for a long while in California).
What pisses me off, as a resident of Seattle (and former resident of Denver), is that the residents of western states who didn't make irrational decisions are paying for California's stupid mistakes. Like now, when the federal government continues to require that other electric companies sell California their "spare" electricity, even when those utilities have none to "spare" at all!
I say, SCREW 'EM. Cut 'em off. Give the residents of CA a few more days without electricity, and maybe they'll think a little more before giving their legislators the right to go off half cocked, fucking with industries that they demonstrably do NOT understand.
(Incidentally, planned "rolling blackouts" are not common in the east, and if there has been a downturn in electricity reliability there, it has been a direct result of deregulation efforts in certain eastern states...)
"Forces? Do you understand capitalism at all? The market chooses the superior product. The market will decide if they want PS2s or X-Boxes."
Capitalism? Do you understand monopolies at all? Market dumping occurs when a company can rely on it's own size to provide a product below cost. Dumping chooses products _for_ us through price alone.
SharkMail was doing the virtual folder (they called them persistent search folders) thing back in 1997. I think they were the first email client to have this feature, but I may be wrong. FYI.
Slashdot Mirror
"folks even in the software sector a price/revenue of 1 billion to 100 million/yr is pretty rich."
You watch too much CNBC. P/E or P/R ratios in isolation are meaningless. Saying that a stock is overvalued because it has a P/R ratio of 10 (or 20...or 30...) is like saying that a stock is overvalued because the CEO is short.
For example, is a stock overvalued at a P/R of 20 if it's expected forward growth rate in revenue is 20%? How about 50%? This is why the PEG ratio was invented--it allows you to use the P/E ratio in some sort of context, which is critical...
"data is useful to only a finite number of users....there are still a finite number of lateral "hops" that a piece of data can make before it becomes irrelevant."
You're right about this, but it doesn't do anything to reduce the complexity of routing on a network like this. The addition of geographic routing to the traditional task group/hierarchical routing significantly increases the complexity of the routing decisions that must be made. And pretty much anything you do to accomodate this complexity is a trade-off in terms of bandwidth. You can't very well do hop-counting to time out messages--it's quite possible, in an ad-hoc network, that a geographically nearby node is quite distant, topologically. So you have to come up with a better way to "expire" these messages, while still assuring that the people who need them get them, and also making sure that a consistent picture of the battlefield is maintained by everyone while they're moving around from place to place.
"A division commander or his staff don't want or need information on each private anymore than a Fortune 50 CEO wants information on each employee - it's just noise. Just as a piece of information can only make so lateral hops before it becomes too distant to become useless, it can only make so many vertical hops up or down before it becomes useless."
Yes and no. The commander certainly doesn't want to see all of that data all at once, but he'll raise all kinds of hell if he can't get access to it when he does want it. So now you have to keep this data available somewhere in such a way that the commander can get it when he needs it. Further, even if you don't worry about keeping detailed information around, how exactly does the information get aggregated/summarized and resolved (e.g when N different people report on the same event, how do you filter that down?) when you're underlying network is completely dynamic? The way the military does it now is through a human-in-the-loop report cycle. This takes hours, if not days. It's one of the bottlenecks that the military wants to bypass with a network system like SAS. But it's very hard to automate.
My original point was that the things the military wants out of a system like this are significantly harder to do in an automated way than just P2P networking. Routing is just one of the concerns (though a big one), when you've got to worry about QoS, data storage and consistency. In my mind, the whole thing is less like a P2P network, and more like a gigantic, ad-hoc, distributed, intelligent database--and you've got all the same demands and expectations that you would put on a regular old Oracle database sitting behind a firewall somewhere. All in all, it's a very challenging problem.
"a squad leader in Alpha Company probably has no reason to communicate with another squad leader in Charlie company, so they can be on different networks. It also makes "searching" issues non-existent- the number of users on any given network is extremely limited. The network doesn't grow, it subdivides, so the N^2 problem doesn't kick in."
:-)
Well, not quite. First, the system needs to keep a record of friendly force positions, estimated enemy force positions, and other such battlefield information (the consistent tactical picture). This information has to get to whoever might need it--which may mean the people at the next echelon up, or all the people in close geographic proximity to a particular event, or soldiers involved in the same mission, or friendly units near a fire control line, etc.--depending on the type of information being processed. Thus, a system like this has to maintain complex routing rules at a contextual level, in addition to the routing difficulties that are specific to ad-hoc network systems. Imagine if gnutella had to know what file types had to go to particular users, based on preferences the users specify when they log on to the network--now imagine that the users can change their preferences at any time, and that gnutella is always required to give them all of the relevant files corresponding to their preferences. This gets messy, to say the least.
Second, this type of system is wireless and dynamic, yet nodes must be *guaranteed* some level of baseline communication. In a life or death situation, it is unacceptable to lose communication, or to be fed innaccurate information that may cause you to make misguided decisions. Yes, existing systems have this problem too, but if you want real soldiers to go to the effort of wearing these boxen and using the data they provide, you have to do better than the existing systems.
Third, how do you guarantee that the higher-ups always have a complete and accurate picture of the battlefield? Now, how do you do that without trashing the network (think 10,000 grunts constantly sending their positions over a low-bandwith RF link back to the commander)? Again, existing systems don't do this well either, but the idea is to do better than the existing systems.
The fact is, the total scope of the situational awareness problem is much larger than that faced by gnutella and other P2P systems. Sure, if you dumb everything down to the point where you're doing existing military communications over a computer instead of a radio, you won't run into these nasty little snags, but you also won't get anyone to use these devices (as you might suspect, these ultra-cool radio/computer things weigh more than a regular radio, and soldiers do NOT like to carry more shit around with them
It's odd that this just made it into the media, as this project (known as SUO SAS) has been around for the better part of 2 years now--not counting the previous phases of development, which go back several more years.
While the article got a lot of things right, it was also a good portion of hype. I worked on the networking software for this (which is built on top of the TAO CORBA ORB, btw), and while it is conceivable that it might scale up to 10,000 nodes, it is unlikely to do so in it's current form (well, as of a few months ago, anyway). In fact, we faced more or less the same scalability problems that any ad-hoc wireless network system faces, plus the added complexities of having to guarantee consistent tactical picture maintenance (how do you keep a consistent data 'picture' of an entire battlefied among 10,000 separated nodes, with no guarantees on connectivity, or even addressing between any two particular nodes? Now, how do you tackle message-based quality-of-service on top of this mess?). So, for those of you wondering, the problem tackled by this system is a lot bigger and more complicated that than faced by peer-to-peer filesharing systems (think superset of the gnutella problem), and the algorithms we were developing weren't perfect--or even good, necessarily. The problems facing ad-hoc networking are certainly as unsolved and difficult as they were before.
Another important note is that while we ultimately got our way and were able to use Linux for development (partly because we absolutely refused to work with a platform where we didn't have access to the network stack code), it was kind of an uphill battle with DARPA to do so. Linux still isn't qualified to be running on any type of deployed military system, and believe me, we heard about it constantly (I still shudder at the thought of trying to do our development in Windows...)
All that said, the concept of the project was/is pretty cool, but, as always, reality is less dramatic than its press release. If you want more info on the project and related research, here are some links:
Info on geo-routing algorithms (directly relevant to the SUO SAS problem)
A blurb on SUO SAS by SRI
The DARPA ATO web page describing SUO SAS
"Python would be used for higher level control of an application, and Java would be used for implementing the lower level that needs to run relatively efficiently."
I never thought I'd see the day when Java was mentioned in the same sentence as "lower level" and "efficient."
*shudder*
What is often left out of the Emily Rosa story is that her father was a PhD researcher at a university. While the work _was_ good, and it _was_ funny, it's been pretty well documented that Dad had a big hand in the discovery process.
But the News is always looking for a good headline...
I am sympathetic to the people who hate domain-squatters (I have a domain being squatted myself, and I can't afford the dispute fees), but since when did the corporate world claim a manifest destiny to future domains? What about those would-be owners who don't want to squat, yet don't own a trademark or a company in meatspace?
.org or .net), domains should be available through a competitive process. Sure, there's the risk of squatting, but IMO, the internet should stay a free, wild environment, rather than becoming another corporate sponsored and controlled media outlet.
As long as the semantics of domain names are ignored (a for-profit company should not have rights to
DARPA, like anything else governmental, is inherently politcal. While they have to frame these proposals as public processes, the fact is, if you weren't working on this proposal months ago, well before it was first published, you don't have a chance. I'll guarantee you that there are already 5-10 different labs working on the problem, who have already extensively discussed the DARPA program manager's expectations (most likely with the program manager or the program manager's close colleagues).
Yes, it's a very inbred, good-ol-boys type of process, but that's life in military research...
"More generally, software (and all IP) developed with public money generally belongs to the public."
No, it doesn't. As a former contractor employee, I was frustrated many times in my attempts to get ahold of publicly-funded software. In fact, a very large percentage of publicly-funded software ends up being proprietary, since the government agrees to those conditions to get some special consideration.
Don't confuse government use with public use--while the government can (and usually does) require unlimited government use of software developed with government funds, this right does NOT automatically translate to the public at large.
"Unless it was explicitly stated in the terms of that contract that the code will remain open, (which, I assure you, it doesn't) then the DoD can do whatever they wish."
No, no, no...
The government is a contractee, just like anyone else, and they're governed by the same laws. If they didn't specify licensing in the contract, and the contractor is the rightful owner of the code, then the government is stuck. The owner gets to name the license.
"The DoD owns the code, because they paid you to develop it."
Again, no. The developer owns the code unless otherwise specified by the contract. Just because the DoD paid the contractor does not mean the DoD has property rights to the contractor's product.
"How is the 3d matrix of bone cell division, encoded in the four bit code of dna?"
Well, it's not a "four bit" code--not in the way you imply, anyway. That's a bit like saying that computers are amazing to represent the things they do, because they have only a "two bit" code.
The complexity is represented by the X^4 combinations of nucleotides. When X is large, the DNA language is quite descriptive. What I'm trying to say, ultimately, is that I don't think there's that much compression going on. In fact, it's been pretty well established that evolutionary pressures usually don't optimize for size in complex organisms.
Didja read the press release about Mr. Hubert?
Apparently, Mr. Hubert is a brilliant engineer, a brilliant computer scientist, a brilliant concert pianist, and a brilliant inventor. Oh yeah, and a brilliant architect too. I bet he even cleans the floors in the mathematics wing at MIT, and lives in southie with his brilliant med student girlfriend...
I know these press releases are designed to talk people up, but MIT's have to be the worst of all. Yeah, Mr. Hubert's a smart guy. No matter how smart he is, he's probably only brilliant at one of the above. There just isn't enough time in the day to be brilliant at everything.
Sheesh...
Same two guys, standing on a ferry below the golden gate. Camera pans out to show beetle hanging from above:
"Didn't I tell you to let out on the clutch easier?"
...you reinvented a wheel. In particular, the MAPI architecture.
While much M$ software is poorly designed, MAPI is an exception. MAPI is a pretty flexible, intelligent architecture for all things messaging.
MAPI allows you to do things like substitute message stores, address books stores, etc., by treating them as abstract components. Exactly what you're claiming to have done with your "data store API"
I don't want to be too critical, but I hope you folks looked at MAPI before you went out inventing another API...
"The earthquake would have happened no matter what (I believe that reliable earthquake prediction won't happen for about 100 years, and earthquake prevention technology will take at least a thousand years from that point). The Challenger incident was a totally preventable accident."
If the majority of the world's population wasn't living in shanty-town conditions, we wouldn't see 30,000-100,000 people dead from an earthquake.
On Friday, January 26, 2001, a 7.9 magnitude earthquake hit the Gujarat state in western India.
More than 10,000 and as many as 30,000 people are presumed dead. 125,000 people are missing.
Rescue agencies are unable to provide the type of support needed to search for survivors, due to a lack of funding.
"I'm having a hard time understanding how you could have a firm grasp on C++ & OO theory yet not know Java. Why not just learn it?"
At the risk of sounding like a lawyer, define "know." At various points in the past, I've sat down and "learned" the Java syntax, core philosophies, etc. But I don't use it. Ever. So I wouldn't want to go into a job interview that demanded that I "know" Java. Sure, I know the theory of Java, and I may even know some of the syntax, but I couldn't hold a candle on a day-to-day basis with someone who used Java professionally.
It's the difference between "knowing" a language and "thinking" in a language, I believe. I know a lot about OO design and development, but switching from C++ to Java would leave me stranded on an island of inefficiency for a while--because I don't think in that language.
"Exciting Web development firm seeks creative, driven programmers with experience in Perl, C/C++, Java, XML and OO technologies. Extreme programming and OO design skills a plus."
I've been around this block more than once, and as a technical job seeker, this is an ad I'd ignore.
Why?
First off, even though the intent may have been to attract people who *aren't* language specific, the laundry-list of high-level languages is distracting at best, and intimidating at worst. For example, I am a good C++ coder, and a not a half-bad OO designer. I know a lot about OO theory, and I've probably read every classic book on OO design and development that you have. Nevertheless, I don't know Java, and I don't know XML as if I were working with it full-time. But when I read your ad, I find these skills listed up there in equal stature with C++ and "OO technologies." So what is it? Do you do C++ and OO design, or do you do Java programming, or do you do XML programming? Or do you do mostly Perl coding? Some combination of the three? What priority? From what I've just read, they're all equally important.
Second off--believe it or not--I'm shopping for you, not the other way around. You say that you want only the best. You say that you know this is a tough hiring market. But your ad doesn't do *anything* to discriminate itself from the thousands of other ads that look just like it. Furthermore, your list of "requirements" looks generic--I want to have some idea of what a company actually *does* on a day-to-day basis, before I go through the hassle-cycle of trying to contact you/submitting resume/calling for response on daily basis. So when I read your ad, I have to wonder: are you a Java house that does some Perl? Are you a hard-core C++ house? Do you develop primarily using an OO methodology, and if so, do you do it in a proper OO language, or do you try to bend other languages to your will? As a job seeker, I could try to deduce it from the subtle wording of your ad, or I could just jump one ad down the list to the company that has listed it's requirements as strong preferences, not just a laundry list of hip technologies.
Finally, even if I did decide to call you up for some reason (maybe a slow ad day in the paper), if you invited me for an interview and grilled me mercilessly (or even worse, started the grilling on the phone), I'd probably walk out (or hang up) on you. As a smart person, I am actually *less* likely to sit through a defense of my intelligence for a complete stranger. Life's too short--and there are far too many good jobs--to sit through an interview like that. I think other Smart People (tm) would agree with me here--the jobs that put you through the Microsoft-Patented-Intelligence-Test are usually a little too self-important to really bother with, unless you have some burning desire to work there to begin with (a.k.a "Rudy" syndrome: "I've always wanted to go to Notre Dame...").
So basically, if you did manage to get me to call you with your generic ad, you'd likely turn me off completely with your interview methodology. My advice to prospective employers is to place an ad like this (let's assume you're a C++-centric shop):
"Exciting software development firm seeks highly creative, independent thinkers to assist in the development of it's C++-based product line. Experience with C++ is preferred, but all candidates with relevant OO language experience will be considered. Experience with any of XML, Java or Perl a plus."
Obviously, fill in your own skills as needed, but I think the concept is clear--cast a wide net, and use the interview to filter down the candidate list to those you would like to work with. And as for trying to filter "intelligent" candidates out--well, you're going to have to rely on gut instinct here. DON'T attempt to grill a candidate on obscure principles, or language details, or even bizarre algorithms, whatever you do. Instead, talk to the candidate for a while, ask them pertinent, interested questions about their previous work...maybe even ask them to take part in a code review (your code or theirs). There are lots of different approaches to this problem that will give you an idea of their skill level, and won't require that you be a draconian interviewer.
Anyhoo...hope this helps someone. I couldn't let the above ad go "unanswered"...;)
"there's absolutely no value in forking a DTD. Unless you think there was maybe some value in all of the "modifications" Netscape and Microsoft made to the HTML DTD, for a simple example - its the same in this case."
Apples and Oranges.
HTML is controlled by the w3c--a standards body more or less independent of any particular company. Sure, M$ and Netscape had a lot of pull on HTML, but they *should* have, given that they *were* the browser market for a long time.
In this case, we have a particular bioinformatics company graciously offering up their own "public domain" DTD as a standard for the rest of the industry (how generous). And a major scientific journal latching on to it. The only problem is, that same bioinformatics company must approve any and all changes to the "standard"! It would be the same if HTML were a copyrighted property of Netscape, Inc.
It would be nice if the bioinformatics community could organize and form it's own XML standards body, a la the w3c. An agreed-upon standard is almost always better than a legislated standard.
"I would agree that bioxml servers as a much better licensing model for the community than GEML, its worth mentioning that at the current time they do not compete. GEML appears to be about gene expression, and bioxml has no DTD's addressing this."
True. I do think that bioxml's goal is the same as GEML, but they're just not as far along as GEML (yet). It's just bothersome to me that a company-owned and controlled format like GEML could become very prevalent. I would still much rather see something like bioxml succeed instead. I hope they don't give up because of this...
From the GEML terms of use:
...
The GEML Format is a free, public-domain, open standard created and licensed by Rosetta Inpharmatics, Inc. ("Rosetta") in order to define a single, distinct format for handling gene expression data and avoid proliferation of incompatible variations.
You may not modify, lease, loan, sell, charge for, or create derivative works of the GEML Format or documentation without written permission from Rosetta.
So nobody can fork the standard without first consulting with Rosetta Inpharmatics. Wonderful. I just love their definition of "open standard."
This looks like another corporate-buddy move by a major scientific journal, much like the Science/Celera deal a few weeks back...
Go see bioxml for a truly open alternative.
The bioxml project has been trying to do this very thing for quite a while now. Previous to that, there was the biomolecular sequence markup language (BSML), and I don't think it ever came close to becoming a standard. The problem that these efforts always run into is the sheer diversity of opinion on how biological data should be represented. Molecular biologists and computational biologists can't even agree on the basic things, like how to represent sequence regions, let alone more complex issues, like annotation syntax.
Why Nature chose GEML as a standard is unclear--the article doesn't present a compelling argument for it over the alternatives, and the choice seems a little arbitrary. It'll be interesting to see what impact this has on the other projects, and how open the standard will be to extension and modification.
"It's common. And it's going to get worse in all major metropolitan areas over the next 10-20 years. Get used to it.
It wasn't common until California residents decided that a deregulated power was the way to go. Nevermind that this "free market" was/is in direct conflict with Calfornia's ecological mindset (do you know how much $$ some of the new environmental compliance equipment costs?), and that basic economic theory will tell you that power costs will go up when demand exceeds supply (as it has for a long while in California).
What pisses me off, as a resident of Seattle (and former resident of Denver), is that the residents of western states who didn't make irrational decisions are paying for California's stupid mistakes. Like now, when the federal government continues to require that other electric companies sell California their "spare" electricity, even when those utilities have none to "spare" at all!
I say, SCREW 'EM. Cut 'em off. Give the residents of CA a few more days without electricity, and maybe they'll think a little more before giving their legislators the right to go off half cocked, fucking with industries that they demonstrably do NOT understand.
(Incidentally, planned "rolling blackouts" are not common in the east, and if there has been a downturn in electricity reliability there, it has been a direct result of deregulation efforts in certain eastern states...)
SharkMail was doing the virtual folder (they called them persistent search folders) thing back in 1997. I think they were the first email client to have this feature, but I may be wrong. FYI.