A Piper PA-32R aircraft equipped with a GNS-430W was reporting loss of GPS fix when the VHF comm was in use on certain frequencies. The VHF antenna is on the bottom of the fuselage, and the GPS antennas are located on the top. It was determined that the frequencies this occurred on were were between 121.0 and 122.0 MHz. This is nowhere near GPS frequencies, which are at 1.57 and 1.23 GHz. So what causes a complete loss of fix when the VHF transmits? The ELT (emergency location transponder) transmits at 121.5MHz. The ELT is off in flight and only activated when an aircraft crashes, or manually by a pilot in distress. The VHF comm transmissions *near* 121.5 energized the ELT's transmitter, which had a wire running very near the GPS antenna wires. The resultant interference on the GPS antenna wires caused the avionics to lose the fix. For a pilot shooting a GPS/WAAS approach in IMC, activating the comm would cause GPS failure, and force the pilot to execute a missed approach. Ultimately, this could make safely landing the aircraft at an airport impossible.
In the corporate world, there hasn't been a pure "web site" project since about 1998. I said in my book, "Despite lip service, companies didn't really get off the starting line for enterprise integration until they needed to create dynamic websites. Those projects were the impetus that finally forced many companies to integrate systems that have never played well together."
The place where you need to look for actual software engineering is in the whitespace on the block diagrams. Those innocent looking little arrows that connect the boxes together are the source of most failures and inefficiencies. I've seen one little "interface" arrow implemented with 20 moving parts on half a dozen servers. (Send a message to a queue, the broker picks up the message and appends a line to a file. Once an hour, another broker picks up the file and FTPs it to the "integration server", which then slices the file into lines and uses SOAP to send messages out to a third party.) Talk about failure modes!
Civil engineers consider the loading factors, material strength, and design life of their structures. Together, these constitute the "design envelope" of the system.
Software engineers need to think the same way. How long will this system last? One year? Five years? Two months? The level of demand and demand growth over that time span matters a great deal. An architecture that works well for 10,000 page views a day will bomb badly when it's asked to serve 10,000,000. That sounds like a "duh", but it's ignored surprisingly often.
I could go on and on about engineering systems for real-world survival... but I won't do it here. (Since I already have.)
Different marketing messages resonate with different people. The classic problem of "Crossing the Chasm" involves expanding a product's base from the early adopters willing to take risks to the more conservative mainstream.
The early adopters ask questions like "what advantage can I gain?"
The mainstream asks "who do I know that uses this?"
Advertising your high levels of innovation attracts the early adopters but repels the mainstream.
Advertising how many other users there are attracts the mainstream, but apparently repels some segment of the early adopters. (Other early adopters prefer to gloat about how much earlier they were on the scene.)
This is not immature, misleading, nor "fanboyism".
Yeah, I was thinking more about mining in orbit. Dropping millions of tons of rock and metal through the atmosphere strikes me as not too environmentally-friendly. It kinda makes strip-mining look like planting trees.
Anyone know where to find estimates of copper abundance in the asteroid belt? If there isn't enough of it down here, maybe we need to go find more somewhere else...
Please investigate whether your work is patentable. If it is patentable and you do not patent it, Microsoft -- or some other party -- will surely patent something close enough that they can appropriate your intellectual capital with no compensation whatsoever. In fact, they may even be able to charge you for the privilege of having your own work forever denied to you.
If you truly have invented something new and worthwhile, taking the extra step to protect it is an important act of self-defense.
I agree with the OP. At this point, it's better to devote resources to the other Great Observatories.
We're already seeing wonderful results from Spitzer, and Chandra has been producing valuable data for years. Their biggest deficiency has been a lack of comparable PR campaign to Hubble's. (That and XRay data doesn't make such beautiful pictures.)
Our next visible-light instrument needs to resolve objects two to four times fainter than Hubble, with finer resolution to answer the next round of big astrophysical questions. VLBA instruments, composed of multiple collectors in solar orbit are the right answer. Diverting scarce NASA funding to keeping a relic -- even one as significant and loved as Hubble -- working is not the right answer.
The knife's edge in performance is irrelevant for 99.9% of today's desktop applications.
But when you look at the server side, it matters. If you have a server app that takes 10% longer to generate a page, that translates almost directly (with some nonlinearity, for the nitpickers) to 10% less overall capacity. Or, conversely, it means adding about 12% more CPU/memory/disk. Since enterprise-class server units are quanitized in pretty large grains, that can mean a big chunk of change.
I'll use real numbers, but no names:
A particular app server can normally handle 1,000 concurrent sessions on one instance. One instance wants 1 CPU to itself and 2 GB RAM. So, supporting 50,000 concurrent users (the site's goal) means carrying around 60,000 concurrent sessions (sessions > users due to sessions waiting to expire).
That should have required 60 CPUs to handle requests, plus one CPU per server for the OS and one CPU per server for "auxiliary" services needed by this app server. It also means about 120GB of RAM.
That's no small chunk of change, but the picture really looks bad when you consider that inefficient application design hobbled the app server so badly that it could only handle 200 sessions per instance.
That means five times the number of CPUs and five times the amount of RAM.
There's a similar (coupled) calculation you can do with page latency and capacity. And another one you can do with page weight. A good application developer must pay attention to all of these things, because even a 1K change in page weight makes a very noticable difference to overall site capacity, bandwidth costs, and hardware costs.
A lot of the posters here seem to think the GPL-only module string and the "Tainted" message were created to make it harder to allow binary-only or non-GPL drivers.
In fact, the reverse is true. Many device vendors were hesitant to release drivers for Linux because of the binary linkage created when the driver gets loaded. Under a strict interpretation of the GPL, that would consitute enough of a linkage to make the drivers a derivative work.
Some vendors did not want their drivers to automatically fall under the GPL just because of dynamic loading.
The GPL flag was created to let non-GPL drivers clearly indicate that they were not derivatives and would not be GPL-licensed.
This is an example of a vendor that wants to eat its cake and have it too.
Seriously. Back in the days of NT 3, they were talking about the searchable database/filesystem as planned for "Cairo". Cairo eventually became NT 4, which certainly didn't add anything as spiffy as a database-filesystem.
Since then, they've talked about this feature for every single release of the NT family.
It's a mirage, receding into the distance faster than you approach it.
jethroT, I understand what you mean. It does sound that way when phrased so baldly. It's almost a politician's statement -- unarguable, because no one would ever attempt to justify doing things that have no value.
It can actually be useful, though. Consider a typical large corporation. They tend to be bloated, slow, and rigid. Why? Because people do a lot of things that are unrelated to their project.
At a corporation I consulted for, in one week, I saw a Red Cross blood drive, a foodshare program, a concert for the employees, and an "all-hands" meeting that discussed a change in management 4 layers above all the people in the room. These took an average of 6 hours from each of the team members. None of that was delivering value to the customer, but not one of the developers on the team felt they could say "No, that doesn't advance my project". (You can definitely make a case for delivering value to other stakeholders: employees, shareholders, the community, etc. XP doesn't say that these are inherently bad, it just says they don't get the project done.)
In a more directly connected vein (pun intended), most development project are encumbered by various enterprise initiatives that don't help the project: archaic coding standards, enterprise version control groups, enterprise data architecture groups, etc. Each of these crosscutting functions is, in theory, present to create an efficient enterprise through skills focus and specialization. But, when you combine a heavily matrixed organization with an extreme focus on efficiency, the result is ever-increasing lead times to get on that groups calendar.
Does an enterprise data architecture group accelerate projects? It certainly can. Does it accelerate projects if you have to wait 3 weeks to get a schema reviewed, followed by 2 weeks to get the schema created? I think not.
The wait time delivers no value to the customer. XP says to eliminate it by using a tightly integrated team, instead of a matrixed structure. That's one (windy) example.
I would say that you could construct almost any development discipline from that premise--except that most of the ones out there weren't built that way. Further, I would say that if you constructed a development discipline around that premise, it would look a lot like one of the agile methods. Not necessarily XP, but XP's not the only agile method around any more, either.
The lower your expectations of your people, the more you fear bad results, the more process you put in place.
Don't but bad drivers in Formula-1 cars.
Conversely, if you have a high caliber team, the you can get by with less process, instead focusing on aligning their programming disciplines.
Don't put champion racers in a Ford Festiva.
Now, when you really get into trouble is when you try to take the same disciplines that let talented professionals at the right-hand tail of the bell curve go really fast and apply them to the center (or left-hand) of the bell curve.
So many of the nuances of XP have gotten lost here, it's very disheartening. Any methodology applied blindly will fail. Period.
Early work on XP emphasized the human element of introspection. The review sets up a strawman argument about the rigidity of XP that may be supported by the newcomers like "Uncle Bob", but was not there in the original form.
Originally, XP placed a lot of weight on continually asking yourself "Am I delivering value to my customer?" Followed by elimination of activities where the answer was "no". In other words, do more of the things that deliver value and less of the things that do not.
Another nuance that has been lost is the idea that there are projects and teams that should not use XP. Kent's first book had a whole chapter on when not to use it.
I've used XP in partial form, and it worked. I've used XP in full form, and it worked. The common denominator is that I had a team of creative, engaged, disciplined professionals working together. Such a team does not need a huge process to force them to do the right thing. It needs a set of common disciplines to unite them. This is what XP provides.
The social pressure agaist forking a project is significant, and generally beneficial. In this case, however, forking GNOME to try all of the approaches could be exactly the right thing to do.
Consider this: each of these languages has a "cheerleader" who claims it is the most productive, fastest, most secure, etc. Evaluating these claims objectively is extremely difficult.
But, if GNOME were to fork, we would surely see that one of the forks would produce software faster than the others. If we assume that producing software is equivalent to delivering value to the users, then that fork will be delivering value faster than the others. It will win.
This is truly taking an evolutionary approach. Trying out multiple strategies, allowing them to compete, and then--most importantly--killing off the failed competitors is the essence of evolutionary theory.
As an added benefit, it would provide an amazing real-world laboratory to examine the claims of those who back Java, Mono, C#, etc.
(Naturally, this assumes roughly equal distribution of development talent and project management talent across the forks. That may be the least probably outcome.)
Stop trying to find a job and go create one. Start your own business and run it for a year or two. One good medium-term contract or three short-term ones will take care of you.
You'll find that your lifestyle will actually improve. Your income will go up. What's more, forever after, you will always have the added confidence of knowing that you are not dependent of the whims of beancounters for your survival.
That confidence will shine through in interviews.
Better still, when you show in an interview that you understand issues like cash flow, P&L, customer base, sales, etc. you will be viewed in an entirely different class. The few shorters you've got won't matter a bit.
Absolutely true. The term "IP" is really, really fuzzy too. Given that the term itself still lacks a firm legal definition, it can be construed to mean just about anything an employee of Microsoft has ever thought about.
That's certainly the definition my most recent "IP Assignment" agreement used. Abolutely everything is designated as IP.
So, everything from loose UI metaphors (icon designs, widget designs, the "start" button, the taskbar, a menu labelled "View", etc.) to whole concepts (an drag-and-drop application for business graphics drawing) could be included in that definition...
Slashdot Mirror
A Piper PA-32R aircraft equipped with a GNS-430W was reporting loss of GPS fix when the VHF comm was in use on certain frequencies. The VHF antenna is on the bottom of the fuselage, and the GPS antennas are located on the top. It was determined that the frequencies this occurred on were were between 121.0 and 122.0 MHz. This is nowhere near GPS frequencies, which are at 1.57 and 1.23 GHz. So what causes a complete loss of fix when the VHF transmits? The ELT (emergency location transponder) transmits at 121.5MHz. The ELT is off in flight and only activated when an aircraft crashes, or manually by a pilot in distress. The VHF comm transmissions *near* 121.5 energized the ELT's transmitter, which had a wire running very near the GPS antenna wires. The resultant interference on the GPS antenna wires caused the avionics to lose the fix. For a pilot shooting a GPS/WAAS approach in IMC, activating the comm would cause GPS failure, and force the pilot to execute a missed approach. Ultimately, this could make safely landing the aircraft at an airport impossible.
It's like he's trying to communicate with us.
From the description in the article, the new particle wasn't predicted, but still appears to fit with the Standard Model.
This is not an everyday occurrence. It helps point to a new family of hadrons ("exotic" hadrons), so it's an interesting discovery.
On the other hand, it all fits within known physics.
You know why this type of thing spreads? Because it works.
You know how long it will keep spreading? As long as it keeps working.
Like spam and direct-mail offers, the only thing that will stop it is for the success rate to fall.
How do you reduce the response rate? Help your friends and family upgrade or patch Windows. Help them install Linux or buy a Mac.
That will work.
Until Storm goes cross-platform, anyways.
In the corporate world, there hasn't been a pure "web site" project since about 1998. I said in my book, "Despite lip service, companies didn't really get off the starting line for enterprise integration until they needed to create dynamic websites. Those projects were the impetus that finally forced many companies to integrate systems that have never played well together."
The place where you need to look for actual software engineering is in the whitespace on the block diagrams. Those innocent looking little arrows that connect the boxes together are the source of most failures and inefficiencies. I've seen one little "interface" arrow implemented with 20 moving parts on half a dozen servers. (Send a message to a queue, the broker picks up the message and appends a line to a file. Once an hour, another broker picks up the file and FTPs it to the "integration server", which then slices the file into lines and uses SOAP to send messages out to a third party.) Talk about failure modes!
Civil engineers consider the loading factors, material strength, and design life of their structures. Together, these constitute the "design envelope" of the system.
Software engineers need to think the same way. How long will this system last? One year? Five years? Two months? The level of demand and demand growth over that time span matters a great deal. An architecture that works well for 10,000 page views a day will bomb badly when it's asked to serve 10,000,000. That sounds like a "duh", but it's ignored surprisingly often.
I could go on and on about engineering systems for real-world survival... but I won't do it here. (Since I already have.)
High-profile, cool stuff like databases and compilers. Huh.
Well, on the other hand, I suppose writing a database or a (good) compiler does have some heavy, heavy geek cred.
Different marketing messages resonate with different people. The classic problem of "Crossing the Chasm" involves expanding a product's base from the early adopters willing to take risks to the more conservative mainstream.
The early adopters ask questions like "what advantage can I gain?"
The mainstream asks "who do I know that uses this?"
Advertising your high levels of innovation attracts the early adopters but repels the mainstream.
Advertising how many other users there are attracts the mainstream, but apparently repels some segment of the early adopters. (Other early adopters prefer to gloat about how much earlier they were on the scene.)
This is not immature, misleading, nor "fanboyism".
Yeah, I was thinking more about mining in orbit. Dropping millions of tons of rock and metal through the atmosphere strikes me as not too environmentally-friendly. It kinda makes strip-mining look like planting trees.
Anyone know where to find estimates of copper abundance in the asteroid belt? If there isn't enough of it down here, maybe we need to go find more somewhere else...
IT Infrastructure Library.
Best practices for running IT Operations.
With this in your warchest, you can craft a response to virtually any problem.
People who don't have time to get enough sleep probably don't have time to exercise, either.
Hans,
Please investigate whether your work is patentable. If it is patentable and you do not patent it, Microsoft -- or some other party -- will surely patent something close enough that they can appropriate your intellectual capital with no compensation whatsoever. In fact, they may even be able to charge you for the privilege of having your own work forever denied to you.
If you truly have invented something new and worthwhile, taking the extra step to protect it is an important act of self-defense.
Small world. I did my undergrad at Caltech. Good luck with your job hunt.
Dave, that was a beautiful piece of work. Very nicely handled. It's obviously reeled in a lot of people who weren't paying close enough attention.
Bravo, man!
I agree with the OP. At this point, it's better to devote resources to the other Great Observatories.
We're already seeing wonderful results from Spitzer, and Chandra has been producing valuable data for years. Their biggest deficiency has been a lack of comparable PR campaign to Hubble's. (That and XRay data doesn't make such beautiful pictures.)
Our next visible-light instrument needs to resolve objects two to four times fainter than Hubble, with finer resolution to answer the next round of big astrophysical questions. VLBA instruments, composed of multiple collectors in solar orbit are the right answer. Diverting scarce NASA funding to keeping a relic -- even one as significant and loved as Hubble -- working is not the right answer.
The knife's edge in performance is irrelevant for 99.9% of today's desktop applications.
But when you look at the server side, it matters. If you have a server app that takes 10% longer to generate a page, that translates almost directly (with some nonlinearity, for the nitpickers) to 10% less overall capacity. Or, conversely, it means adding about 12% more CPU/memory/disk. Since enterprise-class server units are quanitized in pretty large grains, that can mean a big chunk of change.
I'll use real numbers, but no names:
A particular app server can normally handle 1,000 concurrent sessions on one instance. One instance wants 1 CPU to itself and 2 GB RAM. So, supporting 50,000 concurrent users (the site's goal) means carrying around 60,000 concurrent sessions (sessions > users due to sessions waiting to expire).
That should have required 60 CPUs to handle requests, plus one CPU per server for the OS and one CPU per server for "auxiliary" services needed by this app server. It also means about 120GB of RAM.
That's no small chunk of change, but the picture really looks bad when you consider that inefficient application design hobbled the app server so badly that it could only handle 200 sessions per instance.
That means five times the number of CPUs and five times the amount of RAM.
There's a similar (coupled) calculation you can do with page latency and capacity. And another one you can do with page weight. A good application developer must pay attention to all of these things, because even a 1K change in page weight makes a very noticable difference to overall site capacity, bandwidth costs, and hardware costs.
A lot of the posters here seem to think the GPL-only module string and the "Tainted" message were created to make it harder to allow binary-only or non-GPL drivers.
In fact, the reverse is true. Many device vendors were hesitant to release drivers for Linux because of the binary linkage created when the driver gets loaded. Under a strict interpretation of the GPL, that would consitute enough of a linkage to make the drivers a derivative work.
Some vendors did not want their drivers to automatically fall under the GPL just because of dynamic loading.
The GPL flag was created to let non-GPL drivers clearly indicate that they were not derivatives and would not be GPL-licensed.
This is an example of a vendor that wants to eat its cake and have it too.
Seriously. Back in the days of NT 3, they were talking about the searchable database/filesystem as planned for "Cairo". Cairo eventually became NT 4, which certainly didn't add anything as spiffy as a database-filesystem.
Since then, they've talked about this feature for every single release of the NT family.
It's a mirage, receding into the distance faster than you approach it.
jethroT, I understand what you mean. It does sound that way when phrased so baldly. It's almost a politician's statement -- unarguable, because no one would ever attempt to justify doing things that have no value.
It can actually be useful, though. Consider a typical large corporation. They tend to be bloated, slow, and rigid. Why? Because people do a lot of things that are unrelated to their project.
At a corporation I consulted for, in one week, I saw a Red Cross blood drive, a foodshare program, a concert for the employees, and an "all-hands" meeting that discussed a change in management 4 layers above all the people in the room. These took an average of 6 hours from each of the team members. None of that was delivering value to the customer, but not one of the developers on the team felt they could say "No, that doesn't advance my project". (You can definitely make a case for delivering value to other stakeholders: employees, shareholders, the community, etc. XP doesn't say that these are inherently bad, it just says they don't get the project done.)
In a more directly connected vein (pun intended), most development project are encumbered by various enterprise initiatives that don't help the project: archaic coding standards, enterprise version control groups, enterprise data architecture groups, etc. Each of these crosscutting functions is, in theory, present to create an efficient enterprise through skills focus and specialization. But, when you combine a heavily matrixed organization with an extreme focus on efficiency, the result is ever-increasing lead times to get on that groups calendar.
Does an enterprise data architecture group accelerate projects? It certainly can. Does it accelerate projects if you have to wait 3 weeks to get a schema reviewed, followed by 2 weeks to get the schema created? I think not.
The wait time delivers no value to the customer. XP says to eliminate it by using a tightly integrated team, instead of a matrixed structure. That's one (windy) example.
I would say that you could construct almost any development discipline from that premise--except that most of the ones out there weren't built that way. Further, I would say that if you constructed a development discipline around that premise, it would look a lot like one of the agile methods. Not necessarily XP, but XP's not the only agile method around any more, either.
sceptre1067, you must be brilliant because I agree 100% with what you just said!
Absolutely agreed. That's the point I was making.
The lower your expectations of your people, the more you fear bad results, the more process you put in place.
Don't but bad drivers in Formula-1 cars.
Conversely, if you have a high caliber team, the you can get by with less process, instead focusing on aligning their programming disciplines.
Don't put champion racers in a Ford Festiva.
Now, when you really get into trouble is when you try to take the same disciplines that let talented professionals at the right-hand tail of the bell curve go really fast and apply them to the center (or left-hand) of the bell curve.
So many of the nuances of XP have gotten lost here, it's very disheartening. Any methodology applied blindly will fail. Period.
Early work on XP emphasized the human element of introspection. The review sets up a strawman argument about the rigidity of XP that may be supported by the newcomers like "Uncle Bob", but was not there in the original form.
Originally, XP placed a lot of weight on continually asking yourself "Am I delivering value to my customer?" Followed by elimination of activities where the answer was "no". In other words, do more of the things that deliver value and less of the things that do not.
Another nuance that has been lost is the idea that there are projects and teams that should not use XP. Kent's first book had a whole chapter on when not to use it.
I've used XP in partial form, and it worked. I've used XP in full form, and it worked. The common denominator is that I had a team of creative, engaged, disciplined professionals working together. Such a team does not need a huge process to force them to do the right thing. It needs a set of common disciplines to unite them. This is what XP provides.
The social pressure agaist forking a project is significant, and generally beneficial. In this case, however, forking GNOME to try all of the approaches could be exactly the right thing to do.
Consider this: each of these languages has a "cheerleader" who claims it is the most productive, fastest, most secure, etc. Evaluating these claims objectively is extremely difficult.
But, if GNOME were to fork, we would surely see that one of the forks would produce software faster than the others. If we assume that producing software is equivalent to delivering value to the users, then that fork will be delivering value faster than the others. It will win.
This is truly taking an evolutionary approach. Trying out multiple strategies, allowing them to compete, and then--most importantly--killing off the failed competitors is the essence of evolutionary theory.
As an added benefit, it would provide an amazing real-world laboratory to examine the claims of those who back Java, Mono, C#, etc.
(Naturally, this assumes roughly equal distribution of development talent and project management talent across the forks. That may be the least probably outcome.)
Stop trying to find a job and go create one. Start your own business and run it for a year or two. One good medium-term contract or three short-term ones will take care of you.
You'll find that your lifestyle will actually improve. Your income will go up. What's more, forever after, you will always have the added confidence of knowing that you are not dependent of the whims of beancounters for your survival.
That confidence will shine through in interviews.
Better still, when you show in an interview that you understand issues like cash flow, P&L, customer base, sales, etc. you will be viewed in an entirely different class. The few shorters you've got won't matter a bit.
Absolutely true. The term "IP" is really, really fuzzy too. Given that the term itself still lacks a firm legal definition, it can be construed to mean just about anything an employee of Microsoft has ever thought about.
That's certainly the definition my most recent "IP Assignment" agreement used. Abolutely everything is designated as IP.
So, everything from loose UI metaphors (icon designs, widget designs, the "start" button, the taskbar, a menu labelled "View", etc.) to whole concepts (an drag-and-drop application for business graphics drawing) could be included in that definition...
You know, I wondered for like 5 or 6 years whether we were ever going to see them again.
I had thought that might be what "Insurrection" meant. If only.