At IgniteNYC, after... a half-hour of drink-refilling and chatting, 16 speakers made PowerPoint presentations.
I've been to evening events like that, with presentations by people who want funding. Listening to people present bad business ideas is entertaining maybe twice. Then it gets really boring.
What was that info doing on a laptop? That in itself is very suspicious. Nobody should have a full list of the "approved people" outside of an database where each access is logged. That's info a terrorist group would want. It gives them a list of people who won't be searched. Those are the ones to exploit to get something past security.
The laptop disappeared from a locked room at an airport. This wasn't an ordinary laptop theft.
TSA has to assume that the database is now in hostile hands. So now everyone with a "Clear" card should be subjected to extra searches.
Let's check out the "Clear" privacy policy. "Clear and its subcontractors, pursuant to legal agreements, have a comprehensive information security program to ensure the privacy of Clear applicants and members as well as the integrity of our systems. We apply ID's and passwords to insure that access to systems and data is only on a need-to-know basis. We use encryption (a strong data coding process) for all program sensitive data communications."... "In the highly unlikely event that a member is the victim of identity theft (defined as the taking of a member's personal information so that fraudulent transactions are made in the member's name) that is the result of any unauthorized dissemination by Clear or its subcontractors, or theft from Clear or its subcontractors, of the member's personal data collected by Clear, we will reimburse the member for any otherwise unreimbursable monetary costs directly resulting from such Identity Theft. In addition, Clear will, at its own expense, offer any such member assistance in restoring the integrity of the member's financial or other accounts."... "Clear has appointed an independent, outside Privacy Ombudsman, Law Professor Paul Schwartz, noted privacy expert and advocate. He will be identified to members as the person to contact if a member has a privacy complaint or privacy problem with administration of the Clear system or fidelity to our published Privacy Policies. The Independent Privacy Ombudsman is empowered to investigate all privacy complaints, gather the facts, and respond to members, as well as to post responses publicly and prominently on our website."
Yet there's no announcement of the security breach on the Clear web site.
Candid CAMERA THAT WAS FUNNY BECAUSE IN THE END THE PARTICIPANTS WERE LAUGHING TO. HERE THAT IS NOT THE CASE
(Ignoring the caps lock problem) Even Candid Camera (a forgotten TV show) ran into legal problems. Once they had a setup in a hat store in NYC, and when a customer came in and put down his hat, they tried to sell it back to him. While the customer was arguing with the actor behind the counter, a NYPD cop walks by, notices the argument, and comes in. The cop looks at the hat, sees that it's obviously used, arrests the actor behind the counter and cuffs him. The show's director comes out and tells the cop it's a TV show with a hidden camera. The cop says "we'll let the judge sort this out", and gets on his radio to call the wagon to take away the whole crew.
It's a reasonable, but narrow, decision. The decision turns on a section of the Copyright Act that says a government employee "shall have a right of action against the Government under this subsection except where he was in a position to order, influence, or induce use of the copyrighted work by the Government." That's what happened here. Davenport used his job in the USAF to introduce his manpower-management software into USAF use. He wasn't an outside supplier.
The DMCA issue is one of jurisdiction. This case was filed with the Court of Federal Claims, which handles copyright claims against the Government. But the DMCA specifies that DMCA anti-circumvention claims must be brought in federal district courts. It's a narrow ruling; it's not clear what would happen if a DMCA case was brought in a district court. Especially if it was brought against the company that did the cracking, SAIC.
I have yet to really understand why it is better than using tables. Tables are pretty logical things to understand and seem to work the same in all browsers.
Actually, you're right. It's not CSS itself that's the problem, it's the DIV/FLOAT/CLEAR approach to layout. DIV/FLOAT/CLEAR is a one-dimensional layout approach. Trying to bash it into doing a 2D cell-like layout is difficult and ugly. Doing three columns in DIV/FLOAT/CLEAR is a classic hard problem. The DIV mechanism just doesn't have adequate alignment tools. If DIVs could be arbitrarily constrained relative to other DIVs ("Left edge of B must align with left edge of A, above"), DIVs would have more power than tables. But, as currently designed, they have less expressive power than tables.
The limitations of DIV/FLOAT/CLEAR layout lead web 'designers' to use absolute positioning. This leads to pages that look wrong if resized, or worse, text on top of text. Then there are Javascript hacks to put positioning logic onto the web page, which rapidly gets complicated and tends to be buggy.
WYSIWYG tools work much better for tables than for DIV/FLOAT/CLEAR layout. Try Dreamweaver in both modes.
Shared memory requires that both sides cooperate on locking. If one side doesn't obey the locking rules, the data can change while the other side is reading it.
(There have been schemes where only one side at a time had write permission; I think Mach supported that. The idea was to speed
up bulk interprocess communication by using the MMU, thereby eliminating a copy. In practice,
the additional fooling around to eliminate the copy wasn't a big win over the copy.)
If there's linking and allocation within the shared memory, one side can screw up the other side. This happens.
Search for "shared memory" and "bug".
First.NET, now this. Why Microsoft's mania for virtual machines, considering they only support x86 targets? Microsoft at one point supported NT for PowerPC, MIPS, Alpha, and x86, and that was with hard-compiled code. So it's not about portability. It seemed to be more like Microsoft's answer to Java - if Sun was succeeding in that market, Microsoft had to go there too.
Rather than trying to use software-separated processes, it would be more useful to improve message passing so that hardware-separated processes could talk to each other better. This, by the way, is one of the big weaknesses of the UNIX/Linux world. In UNIX/Linux, interprocess communication sucks. What you usually want is an interprocess subroutine call, or "synchronous message-oriented interprocess communication". What UNIX and Linux give you are pipes (one way, stream-oriented, asynchronous), sockets (two way, stream oriented, excessive overhead, asynchronous), System V IPC (used by nobody, message oriented, two way, asynchronous), and shared memory (unsafe, one process can crash another). There's no safe, synchronous message passing system. You can build one atop the existing mechanism, but there's a big performance penalty. The result is huge, monolithic applications, or systems that use "plug-ins" that can crash the entire application (i.e. Apache).
Fast message passing has a bad history in the UNIX world, due to the Mach debacle, but it works fine in QNX, IBM VM, and hypervisors like Xen. (Windows has fast message passing, although for historical reasons in the 16-bit era it's somewhat clunky and too tied to the windowing system.)
Windows at least has a standardized approach to message passing. The UNIX/Linux world does not.
This leads to a proliferation of mechanisms for doing the same thing.
Both KDE and OpenOffice use CORBA for message passing, but they don't use compatible versions of it.
The
Pantheon, in Rome, was built as a temple to the Roman gods, but was taken over by the Catholic church in 609 AD. It's time to return it to its original purpose, and restore the statutes of Mars, Venus, Apollo, Jupiter, and Diana.
If people really want your "opt-in newsletter", offer an RSS feed. People can subscribe if they want. And if they tell their RSS reader to unsubscribe, they get unsubscribed, regardless of what the sender does.
Of course, that's why "newsletter" distributors don't like RSS. It's too easy to get off the list.
That's right. Mod parent up. Any tool that only looks at the SELECT statement, without knowing about the indices or what the optimizer is doing, is nearly useless.
A Notice of Allowance was issued on July 8.
Examination is over. Nobody objected during the objection period. So Dell owns "CLOUD COMPUTING" as a trademark. The remaining processing is just paperwork - publication in the Official Gazette, and printing and mailing the trademark certificate to Dell.
The Viking lander checked for microscopic life on Mars back in 1971. It wasn't a very sensitive test; the lander shot out some "sticky strings" and wound them back in. The lander had a unit which tested whether anything collected assimilated any of a few simple compounds. It didn't.
This established that Mars isn't teeming with microorganisms, like Earth. That doesn't eliminate all possibility of life, or something like it, but it did establish that there's no pervasive ecosystem there.
Apache, in a way, is Microsoft's kind of software. It has lots of cruft, features that have been added over time and don't interact well. So it's hard to clone or replace. Lots of things plug into it using its API, so it has slave projects. That's the kind of lock-in Microsoft likes.
(Technically, all an Apache-type web server really needs to do is support serving of plain pages, and FCGI. With that, you can do anything, because there's an efficient way to pass off work to other programs. Interprocess communication is a good thing. But that's not the way Apache grew.)
That's normal stuff. I used to work for a company that built satellites. One of their test fixtures was a shake table connected to a water-cooled voice-coil actuator with a megawatt amplifier driving it. They had accelerometer data from actual launches, and they'd use that to drive the shake table.
The USAF had a reliability program that ran from the mid-1960s to the mid-1980s which did quite a bit to make electronics more reliable in the field. About 1% of the USAF's "black boxes" were marked with stickers that said something like "USAF Reliability Program Unit - If unit breaks, replace entire unit and send broken unit to... for analysis".
When broken units came into the analysis shop, a considerable effort was made to find out exactly which component had failed and how it had failed. This went way beyond normal repair. When a bad part was located, the part was opened up and examined with an electron microscope or X-rayed, as appropriate, to see exactly what had gone wrong.
The USAF would frequently publish pictures from this program in Aviation Week. You'd see pictures of bad lead joints inside an IC package, too-long internal leads that had failed
under high G loads, and bad on-chip etching. Manufacturers of bad parts were named. Inspectors were sent to plants to figure out what had gone wrong with the manufacturing process. The problem got fixed or the supplier stopped getting military contracts.
This worked well when the military bought most electronic components. By the 1980s, consumer electronics were using electronics at least as sophisticated as the military, and the military had to start using "commercial, off the shelf" components. Today, the USAF has trouble getting any special attention from parts suppliers.
Auto manufacturers still do things like this. Because they have to pay for recalls, they need to find out why things break and fix the production process, even if it's at a supplier.
Lead-free solders have higher melting points than lead-based solders.
As a result, soldering now requires tighter temperature and time control.
You're operating much closer to the limits at which the parts will be damaged by
soldering heat. Considerable effort has gone into working out ways to do lead-free soldering
reliably, and it can be done. But it's not easy. There are conferences and much discussion of how to do this right.
There's also a problem with tin leads used with lead-free solders growing "whiskers", a big enough problem that the aerospace community is demanding lead-based solders in some systems.
Usenet is doing quite well. The programming-related newsgroups are in fine shape. "comp.lang.python", "comp.lang.javascript", and "comp.databases.mysql" have heavy traffic from knowledgeable people, including developers of the underlying systems.
It's much faster to see the day's updates on Usenet than to page through the inflated dreck
on a half dozen PHP-based forum systems.
I was a bit disappointed when the C++ standards committee moved their discussions off USENET, but that committee isn't getting anywhere anyway.
Cuil isn't overspending. I've been over there. They only have about 30 employees. They didn't overdo the server hardware, either.
Bringing in lunch makes sense. They're on a quiet suburban street with only one modest, overcrowded restaurant nearby. Cuil is too small for a cafeteria. Bringing in food saves considerable staff time compared to sending everyone out for lunch.
That's not the problem. The search results are the problem, of course.
As someone else mentioned, it's a deuterium fluoride chemical laser. It's the Tactical High Energy Laser demo system from 2000 mounted on three semitrailer-sized trucks. It isn't a fieldable system; it's just a semi-mobile demo unit.
Israel has considerable interest in this thing, because they have fixed locations to defend against hostile neighbors who use unguided rockets, and they're in a desert with clear air.
So they have the special case where this is a useful technology.
The US military isn't that interested because, in its current form, it doesn't solve any problem the US military faces. When the technology is shrunk to where one vehicle can carry it, the US military will be more interested.
Where the code is available, it looks like those buffer overflows are in C code of the Java implementation. Glue code between Java and some C component usually seems to be the problem.
Visiting NASA, a retro experience.
on
NASA Turns 50
·
· Score: 3, Interesting
I went to a meeting at a NASA facility a few weeks ago, not something I usually do. It felt very 1960s. A conference room with a large fake-wood table, plaques on the walls commemorating events of long ago, and frosted-glass windows for security. On the wall hung three calendars, for the previous, current, and next month, an ancient Government custom. Almost everyone in the room was over 50; many were older.
The meeting was about airspace deconfliction for UAVs, a bureaucratic problem involving the FAA, NASA, and some other agencies. It was all about who to call, what forms to fill out, and what to do when your application wasn't being processed fast enough. The overall feeling was that this was a hard problem, wasn't going to be solved soon, and nobody really cared that much because their budgets were being cut.
Driving across the facility, it seemed a monument to the past. Many buildings, and most of the parking lots, were empty. Here and there an aircraft was set out as a display. The place has an operational airport, but it wasn't used while I was there. A few flyable planes were parked on the ramp, but nothing was going on around them.
Slashdot Mirror
At IgniteNYC, after ... a half-hour of drink-refilling and chatting, 16 speakers made PowerPoint presentations.
I've been to evening events like that, with presentations by people who want funding. Listening to people present bad business ideas is entertaining maybe twice. Then it gets really boring.
What was that info doing on a laptop? That in itself is very suspicious. Nobody should have a full list of the "approved people" outside of an database where each access is logged. That's info a terrorist group would want. It gives them a list of people who won't be searched. Those are the ones to exploit to get something past security.
The laptop disappeared from a locked room at an airport. This wasn't an ordinary laptop theft. TSA has to assume that the database is now in hostile hands. So now everyone with a "Clear" card should be subjected to extra searches.
Let's check out the "Clear" privacy policy. "Clear and its subcontractors, pursuant to legal agreements, have a comprehensive information security program to ensure the privacy of Clear applicants and members as well as the integrity of our systems. We apply ID's and passwords to insure that access to systems and data is only on a need-to-know basis. We use encryption (a strong data coding process) for all program sensitive data communications." ... "In the highly unlikely event that a member is the victim of identity theft (defined as the taking of a member's personal information so that fraudulent transactions are made in the member's name) that is the result of any unauthorized dissemination by Clear or its subcontractors, or theft from Clear or its subcontractors, of the member's personal data collected by Clear, we will reimburse the member for any otherwise unreimbursable monetary costs directly resulting from such Identity Theft. In addition, Clear will, at its own expense, offer any such member assistance in restoring the integrity of the member's financial or other accounts." ... "Clear has appointed an independent, outside Privacy Ombudsman, Law Professor Paul Schwartz, noted privacy expert and advocate. He will be identified to members as the person to contact if a member has a privacy complaint or privacy problem with administration of the Clear system or fidelity to our published Privacy Policies. The Independent Privacy Ombudsman is empowered to investigate all privacy complaints, gather the facts, and respond to members, as well as to post responses publicly and prominently on our website."
Yet there's no announcement of the security breach on the Clear web site.
Candid CAMERA THAT WAS FUNNY BECAUSE IN THE END THE PARTICIPANTS WERE LAUGHING TO. HERE THAT IS NOT THE CASE
(Ignoring the caps lock problem) Even Candid Camera (a forgotten TV show) ran into legal problems. Once they had a setup in a hat store in NYC, and when a customer came in and put down his hat, they tried to sell it back to him. While the customer was arguing with the actor behind the counter, a NYPD cop walks by, notices the argument, and comes in. The cop looks at the hat, sees that it's obviously used, arrests the actor behind the counter and cuffs him. The show's director comes out and tells the cop it's a TV show with a hidden camera. The cop says "we'll let the judge sort this out", and gets on his radio to call the wagon to take away the whole crew.
It's a reasonable, but narrow, decision. The decision turns on a section of the Copyright Act that says a government employee "shall have a right of action against the Government under this subsection except where he was in a position to order, influence, or induce use of the copyrighted work by the Government." That's what happened here. Davenport used his job in the USAF to introduce his manpower-management software into USAF use. He wasn't an outside supplier.
The DMCA issue is one of jurisdiction. This case was filed with the Court of Federal Claims, which handles copyright claims against the Government. But the DMCA specifies that DMCA anti-circumvention claims must be brought in federal district courts. It's a narrow ruling; it's not clear what would happen if a DMCA case was brought in a district court. Especially if it was brought against the company that did the cracking, SAIC.
I have yet to really understand why it is better than using tables. Tables are pretty logical things to understand and seem to work the same in all browsers.
Actually, you're right. It's not CSS itself that's the problem, it's the DIV/FLOAT/CLEAR approach to layout. DIV/FLOAT/CLEAR is a one-dimensional layout approach. Trying to bash it into doing a 2D cell-like layout is difficult and ugly. Doing three columns in DIV/FLOAT/CLEAR is a classic hard problem. The DIV mechanism just doesn't have adequate alignment tools. If DIVs could be arbitrarily constrained relative to other DIVs ("Left edge of B must align with left edge of A, above"), DIVs would have more power than tables. But, as currently designed, they have less expressive power than tables.
The limitations of DIV/FLOAT/CLEAR layout lead web 'designers' to use absolute positioning. This leads to pages that look wrong if resized, or worse, text on top of text. Then there are Javascript hacks to put positioning logic onto the web page, which rapidly gets complicated and tends to be buggy.
WYSIWYG tools work much better for tables than for DIV/FLOAT/CLEAR layout. Try Dreamweaver in both modes.
Shared memory is very fast, easy to use, and very safe (as long as the programmer isn't an idiot).
The problem is that the programmers on either side of the interface can't be idiots. Or hostile. You probably don't want to talk to a secure database via shared memory.
Shared memory requires that both sides cooperate on locking. If one side doesn't obey the locking rules, the data can change while the other side is reading it. (There have been schemes where only one side at a time had write permission; I think Mach supported that. The idea was to speed up bulk interprocess communication by using the MMU, thereby eliminating a copy. In practice, the additional fooling around to eliminate the copy wasn't a big win over the copy.)
If there's linking and allocation within the shared memory, one side can screw up the other side. This happens. Search for "shared memory" and "bug".
First .NET, now this. Why Microsoft's mania for virtual machines, considering they only support x86 targets? Microsoft at one point supported NT for PowerPC, MIPS, Alpha, and x86, and that was with hard-compiled code. So it's not about portability. It seemed to be more like Microsoft's answer to Java - if Sun was succeeding in that market, Microsoft had to go there too.
Rather than trying to use software-separated processes, it would be more useful to improve message passing so that hardware-separated processes could talk to each other better. This, by the way, is one of the big weaknesses of the UNIX/Linux world. In UNIX/Linux, interprocess communication sucks. What you usually want is an interprocess subroutine call, or "synchronous message-oriented interprocess communication". What UNIX and Linux give you are pipes (one way, stream-oriented, asynchronous), sockets (two way, stream oriented, excessive overhead, asynchronous), System V IPC (used by nobody, message oriented, two way, asynchronous), and shared memory (unsafe, one process can crash another). There's no safe, synchronous message passing system. You can build one atop the existing mechanism, but there's a big performance penalty. The result is huge, monolithic applications, or systems that use "plug-ins" that can crash the entire application (i.e. Apache). Fast message passing has a bad history in the UNIX world, due to the Mach debacle, but it works fine in QNX, IBM VM, and hypervisors like Xen. (Windows has fast message passing, although for historical reasons in the 16-bit era it's somewhat clunky and too tied to the windowing system.)
Windows at least has a standardized approach to message passing. The UNIX/Linux world does not. This leads to a proliferation of mechanisms for doing the same thing. Both KDE and OpenOffice use CORBA for message passing, but they don't use compatible versions of it.
The Pantheon, in Rome, was built as a temple to the Roman gods, but was taken over by the Catholic church in 609 AD. It's time to return it to its original purpose, and restore the statutes of Mars, Venus, Apollo, Jupiter, and Diana.
If people really want your "opt-in newsletter", offer an RSS feed. People can subscribe if they want. And if they tell their RSS reader to unsubscribe, they get unsubscribed, regardless of what the sender does.
Of course, that's why "newsletter" distributors don't like RSS. It's too easy to get off the list.
That's right. Mod parent up. Any tool that only looks at the SELECT statement, without knowing about the indices or what the optimizer is doing, is nearly useless.
A Notice of Allowance was issued on July 8. Examination is over. Nobody objected during the objection period. So Dell owns "CLOUD COMPUTING" as a trademark. The remaining processing is just paperwork - publication in the Official Gazette, and printing and mailing the trademark certificate to Dell.
The Viking lander checked for microscopic life on Mars back in 1971. It wasn't a very sensitive test; the lander shot out some "sticky strings" and wound them back in. The lander had a unit which tested whether anything collected assimilated any of a few simple compounds. It didn't.
This established that Mars isn't teeming with microorganisms, like Earth. That doesn't eliminate all possibility of life, or something like it, but it did establish that there's no pervasive ecosystem there.
Apache, in a way, is Microsoft's kind of software. It has lots of cruft, features that have been added over time and don't interact well. So it's hard to clone or replace. Lots of things plug into it using its API, so it has slave projects. That's the kind of lock-in Microsoft likes.
(Technically, all an Apache-type web server really needs to do is support serving of plain pages, and FCGI. With that, you can do anything, because there's an efficient way to pass off work to other programs. Interprocess communication is a good thing. But that's not the way Apache grew.)
That's normal stuff. I used to work for a company that built satellites. One of their test fixtures was a shake table connected to a water-cooled voice-coil actuator with a megawatt amplifier driving it. They had accelerometer data from actual launches, and they'd use that to drive the shake table.
The USAF had a reliability program that ran from the mid-1960s to the mid-1980s which did quite a bit to make electronics more reliable in the field. About 1% of the USAF's "black boxes" were marked with stickers that said something like "USAF Reliability Program Unit - If unit breaks, replace entire unit and send broken unit to ... for analysis".
When broken units came into the analysis shop, a considerable effort was made to find out exactly which component had failed and how it had failed. This went way beyond normal repair. When a bad part was located, the part was opened up and examined with an electron microscope or X-rayed, as appropriate, to see exactly what had gone wrong.
The USAF would frequently publish pictures from this program in Aviation Week. You'd see pictures of bad lead joints inside an IC package, too-long internal leads that had failed under high G loads, and bad on-chip etching. Manufacturers of bad parts were named. Inspectors were sent to plants to figure out what had gone wrong with the manufacturing process. The problem got fixed or the supplier stopped getting military contracts.
This worked well when the military bought most electronic components. By the 1980s, consumer electronics were using electronics at least as sophisticated as the military, and the military had to start using "commercial, off the shelf" components. Today, the USAF has trouble getting any special attention from parts suppliers.
Auto manufacturers still do things like this. Because they have to pay for recalls, they need to find out why things break and fix the production process, even if it's at a supplier.
Lead-free solders have higher melting points than lead-based solders. As a result, soldering now requires tighter temperature and time control. You're operating much closer to the limits at which the parts will be damaged by soldering heat. Considerable effort has gone into working out ways to do lead-free soldering reliably, and it can be done. But it's not easy. There are conferences and much discussion of how to do this right.
There's also a problem with tin leads used with lead-free solders growing "whiskers", a big enough problem that the aerospace community is demanding lead-based solders in some systems.
Usenet is doing quite well. The programming-related newsgroups are in fine shape. "comp.lang.python", "comp.lang.javascript", and "comp.databases.mysql" have heavy traffic from knowledgeable people, including developers of the underlying systems. It's much faster to see the day's updates on Usenet than to page through the inflated dreck on a half dozen PHP-based forum systems.
I was a bit disappointed when the C++ standards committee moved their discussions off USENET, but that committee isn't getting anywhere anyway.
Cuil isn't overspending. I've been over there. They only have about 30 employees. They didn't overdo the server hardware, either.
Bringing in lunch makes sense. They're on a quiet suburban street with only one modest, overcrowded restaurant nearby. Cuil is too small for a cafeteria. Bringing in food saves considerable staff time compared to sending everyone out for lunch.
That's not the problem. The search results are the problem, of course.
It's not the Death Star with Ballmer walking around, periodically strangling people with his mind just to show who's boss.
That's what Apple is like.
As someone else mentioned, it's a deuterium fluoride chemical laser. It's the Tactical High Energy Laser demo system from 2000 mounted on three semitrailer-sized trucks. It isn't a fieldable system; it's just a semi-mobile demo unit.
Israel has considerable interest in this thing, because they have fixed locations to defend against hostile neighbors who use unguided rockets, and they're in a desert with clear air. So they have the special case where this is a useful technology. The US military isn't that interested because, in its current form, it doesn't solve any problem the US military faces. When the technology is shrunk to where one vehicle can carry it, the US military will be more interested.
You're right. Google hasn't done Seattle. Fear of Microsoft?
Transmeta still has a live trademark on it, too. In category "Goods and Services: Computer Operating Systems".
Where the code is available, it looks like those buffer overflows are in C code of the Java implementation. Glue code between Java and some C component usually seems to be the problem.
I went to a meeting at a NASA facility a few weeks ago, not something I usually do. It felt very 1960s. A conference room with a large fake-wood table, plaques on the walls commemorating events of long ago, and frosted-glass windows for security. On the wall hung three calendars, for the previous, current, and next month, an ancient Government custom. Almost everyone in the room was over 50; many were older.
The meeting was about airspace deconfliction for UAVs, a bureaucratic problem involving the FAA, NASA, and some other agencies. It was all about who to call, what forms to fill out, and what to do when your application wasn't being processed fast enough. The overall feeling was that this was a hard problem, wasn't going to be solved soon, and nobody really cared that much because their budgets were being cut.
Driving across the facility, it seemed a monument to the past. Many buildings, and most of the parking lots, were empty. Here and there an aircraft was set out as a display. The place has an operational airport, but it wasn't used while I was there. A few flyable planes were parked on the ramp, but nothing was going on around them.
The C/C++ defect that the compiler has no idea of the size of an array claims another victim.