I don't understand WHY Google IPO'ed. It's not exactly they needed the money.
Google has investors who want to cash out. Venture capitalists tend not to be the most patient people in the world, and they need to realize gains every once in a while to keep their partners happy. That's a strong motivation for IPO.
According to the prospectus, about 25% of the IPO shares came from "selling stockholders" - people and institutions who invested in Google and employees, primarily. The $451 million from the sale of those shares go to the owners, not Google. Google gets the $1.1 billion from the sale of the other 75% of the shares in the IPO.
An analogy: no one would appreciate it if a company said their car goes from 0 to 60 in 3.2 seconds and in reality it takes 3.2 seconds just to make it up to 20.
Actually, there's a strong analogy in the automotive industry. 0-60mph time is a common benchmark for car magazines. Many sports cars have transmissions that are geared to reach 60mph in second gear. Why? Because that saves the time need to shift from 2nd to 3rd, resulting in a lower 0-60 time. Is this gearing optimal for real-world driving conditions? Probably not. But it provides the best possible time on a popular benchmark that often influences purchase decisions.
but what I wonder is: Why do they need 23 (22?) people on that plane, including Chinese-speaking Analysts, when all the data collected are send back to base in real time anyway. Just what exactly are they doing?
Chances are that the raw data are NOT being sent anywhere in real time. This is mostly conjecture, but I have some experience with a related weapons system. Some data may get processed and sent out over a tactical or theater datalink, but most of it is analyzed right on the platform. So the mission crew is analyzing the sensor data and providing that digested information to the theater commanders. This includes voice comm intercepts, radar analysis, etc. So the guys on the EP-3 can tell the commander "we have x many aircraft of y type at location z, and we just heard the flight leader say 'foo', so we know what their intentions are."
Keep in mind that the variety of sensors on an EP-3 probably greatly exceeds that on the Global Hawk. The EP-3 has all manner of RADAR and radio intercept gear. Trying to push all of that data off the aircraft in realtime would likely overwhelm the available satellite bandwidth - your average satellite channel has less throughput than a modem, remember.
Long term the goal is to replace a lot of the surveillance/airborne C2 assets (E-3, EP-3, RC-135, etc) with UAVs, but the bandwidth availability is going to have to improve before that becomes possible.
The linked article seems to have more to do with the "silver bullet" mentality than OOP specifically. Anybody worth listening to will tell you that it's just as easy to screw up a OOP project as it is a procedural project. Really, has anybody used "it's object-oriented" as a selling point since 1989 or so?
In general, the criticism contained in the article is poorly founded. The author uses some nice charts, but has no citiations for them. For instance:
The problem is that building generic abstract modules (intended for reuse in later projects) requires roughly three times the effort as a
project-dedicated (regular) module. Although no references will be given here, this figure is fairly widely accepted in the industry.
Accepted by whom? I've never heard that asserted by anyone in my academic or professional careers.
Some of the things he calls out apply equally to procedural languages, such as:
When a new language fad replaces OOP, how do you convert legacy Java objects into Zamma-2008 objects?
When Pascal replaces C, how do I convert my C functions into Pascal functions? Eh?
He makes some good points about measuring the effects of change (everybody should do that!) but I don't think this really strikes a death blow to OOP.
Cameras are cool, but I don't think they'll be all that practical for mobile use. First, if the camera is detached from the voice handset, you need two appendages to operate your phone. You'll also develop gorilla arm, not to mention looking like a dork, whilst holding your wrist in front of your face during a conversation. I suppose an alternative would be some kind of head-mounted, inward-facing cam, but I can't imagine those catching on.
And how distracting are cameras? How are people going to handle looking into a camera display while walking down the street? I predict a sharp uptick in pedestrian fatalities when this arrangement becomes popular.
Cocoon does more than just XSLT. In fact, it's Xalan that does the XSLT stuff. Cocoon is a more general publishing framework that offers some very cool features, notably eXtensible Server Pages. Cocoon provides caching and connection-pooling services but uses Xalan for XSLT.
I'm working on a cocoon-based production project right now. It's fast, it's flexible, it promotes high-level reuse. Get some!
The solution is probably in processing XML/XSL on the client
Wouldn't that be nice? I agree that would be the best solution, but I fear that would send XSLT the way of HTML and Java/ECMAscript - that is, nothing looks or works the same on two clients.
I agree that Cocoon's performance is a concern, and I have higher hopes for C2. For now, throwing hardware at the problem is not such a bad option. Even server hardware is cheap compared to developer time.
IMHO, one of the most exciting things to come out of the Apache XML project (or Apache in general) is Cocoon. Cocoon includes the eXtensible Server Pages (XSP) Processor which allows complete separation of content and presentation. XSP is what JSP wants to be when it grows up. It provides tags for the inclusion of Java logic into dynamic XML documents - other languages will be supported in the future. This, combined with the XSLT engine (Xalan) provides a very powerful content generation and formatting framework.
Anyone who has to design, implement and support large, web-based applications should check out Cocoon.
Note that the Tomcat results shouldn't be taken as representative of all JSP engines. Tomcat is merely one JSP engine of many, albeit the "reference implementation" for JSP. It also has the advantage of being free software. However, lots of other web and app servers (iPlanet, BEA WebLogic, WebSphere, blah, blah) implement their own JSP/servlet engines. Their performance will definitely vary.
Torps may be fire and forget but it's hard to tell the sheep from the goats. They can be preprogrammed before launch to run a specific search pattern but it's possible (however improbable) that the torp did a u-turn after launch and then locked onto Kursk as the choicest target. Torps (like other weapons ranging from ICBMs to bullets) don't have integral IFF (Identification, Friend or Foe) systems. It's up to the controller/launcher to identify the target. The weapon's job is just to kill the target. One sonar blip looks pretty much like another to a torpedo.
Another option would be that the torp went hot in the boat and detonated before the crew could jettison or deactivate it.
Yes, there are failsafes to prevent all of this, but sometimes the failsafes fail.
But the software, oh man was that software ahead of it's time...
Specifically: NeXT leveraged the run-time-binding in Objective-C to create InterfaceBuilder (IB). IB allowed the programmer to create a UI by dragging and dropping interface objects. Yes, a lot of tools do that, but IB was different in that it wasn't a code generator per se. IB created a "nib" file that basically "freeze dried" the UI objects and their relationships. You dragged and dropped your buttons and text fields and other widgets, then you dragged connections between them and clicked radio buttons to specify which methods the buttons would invoke. Very slick, very fast and you didn't have to tromp through a bunch of Obj-C source to make changes. (You could even hack the UIs of apps without needing the source!) A brilliant tool for constructing "mission critical custom apps," which NeXT finally determined was its true calling. I remember watching a video of the 1992 (I think) NeXTWORLD keynote where the Steve used IB to query a database and display the result (including a tiff, IIRC) without "writing any code..." Wow.
So what killed NeXT? High prices, lack of standardization with the X community, and (ultimately) the Web. Even after they killed their hardware in 1992 and went x86, the developer version of the software cost $3K-$5K/seat. IB and its integrated editor-debugger-source-manager ProjectBuilder were great for building client-server apps, but the three-tier world marginalized them. WebObjects (their middle-tier software, now offered by Apple) is supposed to be pretty good but has a pretty limited following.
I have my NeXTstation in the basement and have many fond memories of late-night hacking on it. The spirit lives on in GNUstep. The software lives on as Mac OS X Server but latest word has it that Obj-C has been deprecated in favor of Java, at least for WebObjects.
Kooki Monster wrote: And am I the only person to notice that the section covering "Information Warfare" (a stupid concept anyway) is classified?
IW is not a stupid concept. We're not talking simply about zapping the enemy's computer networks. Defensive IW is even more important. The military now depends on the Internet - and yes, I mean the commercial internet - for its operations. Military sites are subject to penetration and DoS just like everybody else, except people die and the country loses wars when.mil systems go down.
IW doctrine is still evolving, but the importance of defensive IW is evident. That paper is four years old so it's next to useless, you're not missing anything. However, defensive IW (aka "info assurance or "info protection") is a hot-button topic in the military today. Lots of stuff is classified because the military is paranoid about advertising its vulnerabilities.
After a review of the alternatives for a global space-strike system in 2025, the optimum solution appears to be combining a prompt response capability with a complementary flexible response capability. The prompt response capability is best provided by a system of Continental United States(CONUS)-based laser devices that bounce high power directed energy beams off a constellation of space-based mirrors. Inherently precise, megawatt-class, light-speed weapons can potentially act within seconds or minutes to resolve the rapidly developing crises of 2025. Flexible response is best provided with a small CONUS-based fleet of TAVs [Trans-Atmospheric Vehicles - Neutron] equipped with a variety of payloads, including kinetic-energy weapons, compact laser weapons, and special forces squads. Responding within a few hours of notification, a TAV can precisely deliver force and/or adaptable human judgment to crisis locations anywhere on earth.
So it looks like a combination of space-based energy weapons and a "space plane" based in the US that can strike anywhere on the earth in a matter of a few hours. This would be a serious improvement over the current state of the force. Given that the US doesn't have an aircraft carrier cruising near the area of interest, the best the Air Force could do is a 24-hour response to a crisis. That's the very optimistic minimum time it would take to plan and execute a B-2 "Stealth" mission from a base in the US to an arbitrary point on the globe. This would require coordination with a large number of airborne tankers. Deploying a force of any considerable size would take much longer, on the order of a week or so. Again, that's an optimistic estimate.
The TAV would take off from the US, boost itself into space (single-stage), overfly its target in a few hours, deliver its payload and then return to base. This obviates the need for a big logistics tail - tankers, maintenance, airfields close to the target, etc. The lasers could respond even faster but probably would be limited to relatively large, fixed targets. With such a system you could probably save money on carrier battle groups, but that would definitely piss the Navy off.
All they want is god like powers?! Is *that* all?!?!
When your troops' lives are on the line (and quite possibly your own), you want every advantage you can get. War is all about information. The commander who can discern the enemy's strengths, weaknesses, disposition and intentions has a distinct advantage. Orbit is the ultimate high ground (presuming you're talking about a war centered on planetary surface) and gives a commander the "God's-eye view" of the battlefield - excuse me, battlespace. If Iraq had access to real-time overhead imagery during the Gulf War, they could've seen the disposition of Coalition forces, possibly allowing them to ignore the amphibious feint and concentrate their forces in the Western desert. If they'd had GPS, they could've maneuvered more effectively to counter the allied attack. This is why the air war first concentrated on dismatling Iraq's command and control before it went after forces in the field.
The current problems are these: fusing information from multiple sources and distilling that information into a product that the battlefield commander can use. Efficient computer networks are an integral part of the solution to those two problems. Hence the recent emphasis on "information protection" and "information assurance."
[...] The resulting study is called Air Force 2025 or 2025 for short. The team's findings were briefed to General Fogleman in June 1996 and to the Secretary of the Air Force, Dr. Sheila Widnall, in July 1996.
So yes, indeed, this report is 4 years old. Gen Fogelman is no longer the Chief of Staff, hasn't been since 1997 or so. Gen Mike Ryan is the current Chief of Staff of the AF. Sheila Widnall left in 1998, F. Whitten "Whit" Peters is the current SECAF.
The Air University is responsible for a) professional military education of the Air Force non-commissioned and commissioned officer corps and b) academic development of aerospace doctrine. They're the "think tank" of the AF.
Obj-C has advantages and disadvantages with reference to C++. I used a NeXTstation as my primary development platform 1992-1995 and became intimately familiar with Obj-C. Its elegance comes from the inclusion of only a minimal set of OO features - there's no multiple inheritance, no template classes, all object access is accomplished via reference variables (pointers), there's not even a public/protected/private distinction (everything is effectively protected). This greatly simplifies the resulting code. The object syntax, while elegant, is borrowed wholesale from Smalltalk and therefore looks somewhat strange when mixed in with C syntax. C++'s object syntax is definitely more consistent with its C origins. Also, Obj-C relies heavily on "run-time magic," which Bjarne specifically sought to avoid in C++. This dependence can increase the elegance of your source code at the expense of performance.
Part of what made Obj-C so pleasant to use on the NeXTstation was the rich object class library that NeXT developed. My big indictment of C++ is its lack of such a library; the STL is nice, but it's only a small part of what we need. I think C++'s wide installed base actually hinders such an effort to a great degree. Java's JFC/Swing libs are certainly rich but somewhat strangely organized.
Here's a brief profile of Prof Higgs at the U of Edinburgh website. Includes a little bit of how hard it is to explain the Higgs boson in layman's terms.
Well, there was at least one significant failure as reported by the Washing ton Post. Naturally the Pentagon didn't advertise the fact, and the Post didn't exactly put it on the front page, but it was there.
From my front-row perspective, we put waaay too much time and money into fixing the Y2K problem. But it was a problem. If we had done nothing, things would not be so bright and cheery as they are.
Neutron
Re:mundane fiction bias
on
The Sparrow
·
· Score: 2
In the usual scifi novel (especially those that some like to call "hard" scifi) the idea takes a central place in the story. Remove nanotech from Bear's Queen of Angels, for instance, and you don't have a story. In this case, the space travel and aliens play a less critical role. The core story is about a man who pursues God, think's he's doing God's work, and gets royally screwed in the process. I think Russell could have easily told that story without having the characters leave Puerto Rico.
Also, there's not a whole lot of exploration of the alien species in this book. We aren't allowed to really know what makes them tick, and we don't get to know them too well even after the story moves to Rakhat. The whole time we're focused on the human characters. Again, somewhat unusual for a scifi novel.
In large projects (involving at least a few tens of people, on up to thousands) it's useful to have a reference for activities and processes. In projects of that scale it's actually *more* efficient to create and document a process than it is to try to individually coordinate and mentor workers. That's the environment that these methodologies are designed to work in. Communication and coordination across hundreds of people is difficult, and the constraints of the process actually help these efforts.
Smaller projects can't handle the overhead. With eight or 10 people you can't spend time on non-critical activities and documentation. Communication within the team is easy so you don't need the support.
However, almost all teams need some kind of roadmap. Having a documented process improves your chances of success because you now have a "checklist" of activities. In my experience, projects fail not becase of insufficient skill but because things don't get done. Process documentation helps ensure that things get done, and get done correctly. I like to think of them as design patters for project success.
Maybe I'm just getting old, but what's the point in stuffing the web.ballot.box? I don't think anyone takes these polls seriously, and most of them seem to be vulnerable to trivial attacks. It's a low-skill hack on a low-value asset, so I can't see anybody scoring major reputation points by doing this.
Ach, maybe it's just that I've been at work for 13 hours now and the only Y2K-related problem I've seen is that some kind soul turned off our NT domain controllers "just in case." Preventing all your users from logging on is one way to make sure they don't dork up the system...
This sounds much like the "sprial" lifecycle model, which has been around for some time. Risk management is very important, and with the spiral model you want to identify the risky-but-critical parts of the project and tackle those early. If you can't implement those critical areas, your project isn't going anywhere.
Comments about user feedback are right on the money. Frankly, if you're developing a mission-critical app and you *don't* have constant feedback from the users during development, you're asking for failure. Software engineers aren't domain experts, and we will screw it up we lock ourselves away from the users. Yes, you'll have management constraints but you must always present options to the user. "We can implement the 100% solution using X time/money, or we can give you the 80% solution in X/2 time/money and also have resources to attack Y and Z. You pick."
Slashdot Mirror
According to the prospectus, about 25% of the IPO shares came from "selling stockholders" - people and institutions who invested in Google and employees, primarily. The $451 million from the sale of those shares go to the owners, not Google. Google gets the $1.1 billion from the sale of the other 75% of the shares in the IPO.
Neutron
Actually, there's a strong analogy in the automotive industry. 0-60mph time is a common benchmark for car magazines. Many sports cars have transmissions that are geared to reach 60mph in second gear. Why? Because that saves the time need to shift from 2nd to 3rd, resulting in a lower 0-60 time. Is this gearing optimal for real-world driving conditions? Probably not. But it provides the best possible time on a popular benchmark that often influences purchase decisions.
ATI didn't do anything new here.
Neutron
I think they're going to have to rename this if they bring it to the states.
Neutron
Chances are that the raw data are NOT being sent anywhere in real time. This is mostly conjecture, but I have some experience with a related weapons system. Some data may get processed and sent out over a tactical or theater datalink, but most of it is analyzed right on the platform. So the mission crew is analyzing the sensor data and providing that digested information to the theater commanders. This includes voice comm intercepts, radar analysis, etc. So the guys on the EP-3 can tell the commander "we have x many aircraft of y type at location z, and we just heard the flight leader say 'foo', so we know what their intentions are."
Keep in mind that the variety of sensors on an EP-3 probably greatly exceeds that on the Global Hawk. The EP-3 has all manner of RADAR and radio intercept gear. Trying to push all of that data off the aircraft in realtime would likely overwhelm the available satellite bandwidth - your average satellite channel has less throughput than a modem, remember.
Long term the goal is to replace a lot of the surveillance/airborne C2 assets (E-3, EP-3, RC-135, etc) with UAVs, but the bandwidth availability is going to have to improve before that becomes possible.
Neutron
In general, the criticism contained in the article is poorly founded. The author uses some nice charts, but has no citiations for them. For instance:
Accepted by whom? I've never heard that asserted by anyone in my academic or professional careers.Some of the things he calls out apply equally to procedural languages, such as:
When Pascal replaces C, how do I convert my C functions into Pascal functions? Eh?He makes some good points about measuring the effects of change (everybody should do that!) but I don't think this really strikes a death blow to OOP.
Neutron
"We have reached our cruising altitude of 29,000 feet...you may now frag."
Neutron
And how distracting are cameras? How are people going to handle looking into a camera display while walking down the street? I predict a sharp uptick in pedestrian fatalities when this arrangement becomes popular.
Neutron
Look for my product announcement next week, ahead of Sony and Pioneer.
Neutorn
I'm working on a cocoon-based production project right now. It's fast, it's flexible, it promotes high-level reuse. Get some!
Neutron
Wouldn't that be nice? I agree that would be the best solution, but I fear that would send XSLT the way of HTML and Java/ECMAscript - that is, nothing looks or works the same on two clients.
I agree that Cocoon's performance is a concern, and I have higher hopes for C2. For now, throwing hardware at the problem is not such a bad option. Even server hardware is cheap compared to developer time.
Neutron
Anyone who has to design, implement and support large, web-based applications should check out Cocoon.
Neutron
Neutron
Another option would be that the torp went hot in the boat and detonated before the crew could jettison or deactivate it.
Yes, there are failsafes to prevent all of this, but sometimes the failsafes fail.
Neutron
Specifically: NeXT leveraged the run-time-binding in Objective-C to create InterfaceBuilder (IB). IB allowed the programmer to create a UI by dragging and dropping interface objects. Yes, a lot of tools do that, but IB was different in that it wasn't a code generator per se. IB created a "nib" file that basically "freeze dried" the UI objects and their relationships. You dragged and dropped your buttons and text fields and other widgets, then you dragged connections between them and clicked radio buttons to specify which methods the buttons would invoke. Very slick, very fast and you didn't have to tromp through a bunch of Obj-C source to make changes. (You could even hack the UIs of apps without needing the source!) A brilliant tool for constructing "mission critical custom apps," which NeXT finally determined was its true calling. I remember watching a video of the 1992 (I think) NeXTWORLD keynote where the Steve used IB to query a database and display the result (including a tiff, IIRC) without "writing any code..." Wow.
So what killed NeXT? High prices, lack of standardization with the X community, and (ultimately) the Web. Even after they killed their hardware in 1992 and went x86, the developer version of the software cost $3K-$5K/seat. IB and its integrated editor-debugger-source-manager ProjectBuilder were great for building client-server apps, but the three-tier world marginalized them. WebObjects (their middle-tier software, now offered by Apple) is supposed to be pretty good but has a pretty limited following.
I have my NeXTstation in the basement and have many fond memories of late-night hacking on it. The spirit lives on in GNUstep. The software lives on as Mac OS X Server but latest word has it that Obj-C has been deprecated in favor of Java, at least for WebObjects.
Neutron
IW is not a stupid concept. We're not talking simply about zapping the enemy's computer networks. Defensive IW is even more important. The military now depends on the Internet - and yes, I mean the commercial internet - for its operations. Military sites are subject to penetration and DoS just like everybody else, except people die and the country loses wars when .mil systems go down.
IW doctrine is still evolving, but the importance of defensive IW is evident. That paper is four years old so it's next to useless, you're not missing anything. However, defensive IW (aka "info assurance or "info protection") is a hot-button topic in the military today. Lots of stuff is classified because the military is paranoid about advertising its vulnerabilities.
Neutron
So it looks like a combination of space-based energy weapons and a "space plane" based in the US that can strike anywhere on the earth in a matter of a few hours. This would be a serious improvement over the current state of the force. Given that the US doesn't have an aircraft carrier cruising near the area of interest, the best the Air Force could do is a 24-hour response to a crisis. That's the very optimistic minimum time it would take to plan and execute a B-2 "Stealth" mission from a base in the US to an arbitrary point on the globe. This would require coordination with a large number of airborne tankers. Deploying a force of any considerable size would take much longer, on the order of a week or so. Again, that's an optimistic estimate.
The TAV would take off from the US, boost itself into space (single-stage), overfly its target in a few hours, deliver its payload and then return to base. This obviates the need for a big logistics tail - tankers, maintenance, airfields close to the target, etc. The lasers could respond even faster but probably would be limited to relatively large, fixed targets. With such a system you could probably save money on carrier battle groups, but that would definitely piss the Navy off.
Neutron
All they want is god like powers?! Is *that* all?!?!
When your troops' lives are on the line (and quite possibly your own), you want every advantage you can get. War is all about information. The commander who can discern the enemy's strengths, weaknesses, disposition and intentions has a distinct advantage. Orbit is the ultimate high ground (presuming you're talking about a war centered on planetary surface) and gives a commander the "God's-eye view" of the battlefield - excuse me, battlespace. If Iraq had access to real-time overhead imagery during the Gulf War, they could've seen the disposition of Coalition forces, possibly allowing them to ignore the amphibious feint and concentrate their forces in the Western desert. If they'd had GPS, they could've maneuvered more effectively to counter the allied attack. This is why the air war first concentrated on dismatling Iraq's command and control before it went after forces in the field.
The current problems are these: fusing information from multiple sources and distilling that information into a product that the battlefield commander can use. Efficient computer networks are an integral part of the solution to those two problems. Hence the recent emphasis on "information protection" and "information assurance."
Neutron
So yes, indeed, this report is 4 years old. Gen Fogelman is no longer the Chief of Staff, hasn't been since 1997 or so. Gen Mike Ryan is the current Chief of Staff of the AF. Sheila Widnall left in 1998, F. Whitten "Whit" Peters is the current SECAF.
The Air University is responsible for a) professional military education of the Air Force non-commissioned and commissioned officer corps and b) academic development of aerospace doctrine. They're the "think tank" of the AF.
Neutron
Part of what made Obj-C so pleasant to use on the NeXTstation was the rich object class library that NeXT developed. My big indictment of C++ is its lack of such a library; the STL is nice, but it's only a small part of what we need. I think C++'s wide installed base actually hinders such an effort to a great degree. Java's JFC/Swing libs are certainly rich but somewhat strangely organized.
Neutron
Neutron
From my front-row perspective, we put waaay too much time and money into fixing the Y2K problem. But it was a problem. If we had done nothing, things would not be so bright and cheery as they are.
Neutron
Also, there's not a whole lot of exploration of the alien species in this book. We aren't allowed to really know what makes them tick, and we don't get to know them too well even after the story moves to Rakhat. The whole time we're focused on the human characters. Again, somewhat unusual for a scifi novel.
Neutron
Smaller projects can't handle the overhead. With eight or 10 people you can't spend time on non-critical activities and documentation. Communication within the team is easy so you don't need the support.
However, almost all teams need some kind of roadmap. Having a documented process improves your chances of success because you now have a "checklist" of activities. In my experience, projects fail not becase of insufficient skill but because things don't get done. Process documentation helps ensure that things get done, and get done correctly. I like to think of them as design patters for project success.
Neutron
Ach, maybe it's just that I've been at work for 13 hours now and the only Y2K-related problem I've seen is that some kind soul turned off our NT domain controllers "just in case." Preventing all your users from logging on is one way to make sure they don't dork up the system...
Neutron
Comments about user feedback are right on the money. Frankly, if you're developing a mission-critical app and you *don't* have constant feedback from the users during development, you're asking for failure. Software engineers aren't domain experts, and we will screw it up we lock ourselves away from the users. Yes, you'll have management constraints but you must always present options to the user. "We can implement the 100% solution using X time/money, or we can give you the 80% solution in X/2 time/money and also have resources to attack Y and Z. You pick."
Neutron