The flight operations system I used to work on at a major airline came from another major airline -- we traded some gates for the source and rights to use it, and the two airlines continued to develop the software in parallel over the subsequent decade plus.
Such things are not uncommon in the mainframe world. Customers who bought multi-million-dollar packages from a commercial mainframe software vendor would often receive a copy of the source along with the rights to use the software, and many of those customers made extensive internal modifications for their own benefit.
One of the challenges as a support programmer of such software is to verify that any issues discovered by the customer were in fact problems with the standard product and not problems with code that was introduced at the customer site.:-)
On Unisys Dorado mainframes running OS2200 we tend to use Fortran, but Fortran has always been a commonly used language in the airline industry. Not COBOL so much.
FWIW, Sun doesn't make "mainframes" in the traditional sense of the word. That term is usually reserved for boxes running an IBM OS (zOS) or one of the other legacy mainframe OSes (e.g., OS2200 from the UNIVAC world, MCP from the Burroughs world, etc.).
Mainframes use a mix of compiled and interpreted languages just like any other complex platform. COBOL and Fortran tend to be compiled, not interpreted.
I wish Unisys had the foresight of IBM when it comes to running POSIX software on their mainframes. Or maybe they do and I just don't know about it. They are seemingly a stealth company, after all. But they still manage to sell some very good mainframe server hardware (Clearpath Dorado and Libra servers running OS2200 and MCP respectively), and both of those OSes run fairly old software as well (the 2200 stuff requires a recompile as of some point in the 1970's when the ABS format changed, but I'm not as sure about MCP's binary compatibility).
Man, if we could run Solaris in a partition alongside our OS2200/HVTIP stuff...
If memory serves, the craft's computers use a low frequency, low power AM signal (I forget the frequency) for receiving ground-based transmissions that give the plane's weight during taxi, wind speed and direction info, etc. That communication is susceptible to interference. While AFAIK it is unlikely that a failure would actually cause a crash, a communication failure would show up as a warning light that would cause the pilot to abort takeoff (if possible), I believe, thus delaying everyone.
Yes, the flight crew can be receiving updated WX and MGL numbers at the gate and on the taxiway, but that info is not something which would typically cause any flight delay, and it certainly isn't something automagically handled by the avionics onboard.
Background: I spent over a decade working on the Weather and MGL/Gross Weights ground systems at a major red-tailed US airline which handled most of the ACARS traffic to/from that airline's aircraft. Some of the stuff I dealt with included weather reporting and alerting (SA/METAR, FT/TAF, TWIP/Microburst Alerts, Turbulence Plot messages, NOTAMS, etc.), aircraft fuel on board (FOB) validation, takeoff and landing performance data including the optimal flap and thrust settings used for reduced thrust (FLEX) takeoffs, etc.
The ACARS terminals we used had a small text screen roughly 16 lines x 22 columns in size (the specific ACARS terminals and screen sizes tended to vary some by aircraft type), and the pilots were able to interactively request all of the above information in the event that an automatically generated message or alert was not received. They could also send and received freetext messages, and of course they also might have radio contact with their assigned flight dispatcher.
All of the operationally-related ACARS information was received and interpreted by the flight crew, and were not automagically handled by avionics. In addition, the same messages were cross-checked by both the flight crew and the flight dispatcher assigned to that flight (who received a copy in real-time of the same messages sent to the a/c via ACARS), and any issues with the data were dealt with well before the a/c started its takeoff roll. They mgiht be requesting WX and/or MGL updates while taxiing, but you can believe that they already have fairly accurate information well before that point.
ACARS messages provide additional information and advice to the flight crew, but the flight crew is ultimately responsible for doing some basic sanity checking on the numbers provided, and any changes to the a/c's takeoff or landing procedures are initiated by the flight crew, not by some automatic system.
Some automated ACARS traffic is processed, but those things are limited to things like automated Fuel reports on some aircraft (e.g., A320/A330), and various engine performance reports that can be interactively obtained by the performance engineering folks while the a/c is still in flight (they can request an engine status report enroute via ACARS, which then gets send to them via ACARS, and proactively notify the folks at the destination airport that some form of adjustment is required on landing).
Other airlines may vary. Also, my information may be somewhat out of date as I failed Axe Dodging 101 just after 9/11 and haven't worked in the flight operations area since leaving the airline. I still work on airline software, just not in flight ops.:-)
Please... IBM's 32-bit OS/2 ran circles around Windows NT in its day (as a fine example, search for YouTube video of David Barnes demonstrating OS/2 versus NT back in the early 1990's), and I'm sure the Warp 4.5x kernel will run runs around XP, Vista, and probably also Linux and *BSD kernels on similar hardware even today. The OS/2 kernel used rings 0, 2, and 3 which was very usual for x86 code, but it also was extremely good at juggling multiple tasks and threads under load and at dynamically adjusting process/thread priorities to make the entire system smooth.
I remember some magazine doing a test of OS/2 Warp Server versus NT server sometime in the 1994/1995 timeframe, and a single-CPU Warp box trashed a 4-CPU NT box running the exact same benchmarks.
Notes is a bloated hog, yes, but OS/2? The evidence suggests otherwise.
I use it heavily for discussions, and never really got into the binary side of it.
Not only do many news providers do a certain amount of filtering, but regex scorefile capable newsreaders are quite good at removing a certain amount of cruft.
I know emacs, vim, and NEdit, and I would MUCH rather use the latter.
While I agree that vi knowledge is probably needed just as a general skill (you know that some variant of vi will always be present on a modern UNIX box), I disagree that it (or emacs) is a "better" general programmers editor. For me, at least, it isn't.
Yeah, I forgot it was 6.5% (hey, it's been four years since I lived there), but I suspect the rest of those taxes would not apply to computer parts.:-)
Re:Writing hello world is not a manager job
on
Fire Your IT Boss
·
· Score: 1
I agree that simply technical acumen is not a good way to tell if a person is a good manager. It isn't that easy, and someone who might be a good manager for one team might be a poor fit for another team even in the very same organization.
It isn't rocket science. If it was that easy, everyone would be doing it. You have to fit the people involved and the context of the position. A good manager from a waterfall-driven software development shop might not fit in well at all when doing in-house development on a live system, etc. The culture differences between shops even in the same basic business can be tremendous.
Re:Writing hello world is not a manager job
on
Fire Your IT Boss
·
· Score: 1
Trust is earned in most contexts, not arbitrarily given. Someone will demonstrate trustworthiness over time.
That makes it harder for new managers because they have to make a decision at some point who is trustworthy and who isn't, but even one trustworthy advisor can make things a lot easier by pointing out other valuable resources.
There isn't a formula for this. Just like any human relationship, business relationships are complex and tend to shift over time. That's why people skills are important for anyone in a management position -- not only are they good to have from a political perspective, but they also provide many other benefits (like the ability to accurate read peers and underlings).
Sadly, business is more akin to politics than it is to technical design. Otherwise, geeks would rule the world, and IT management would tend to concentrate on making better systems rather than maximizing their stock options and parachutes...
Re:Writing hello world is not a manager job
on
Fire Your IT Boss
·
· Score: 1
My comment was a direct response to its parent.
If you have an issue with what I said, address the issue sans flamage, please.
OS/2 is better at running DOS software than either DOSBOX or DOSEMU, and there are a few native programs for OS/2 that I've not yet found good equivalents for under Linux.
Yarn (my SOUP-packet based offline reader for USENET) is one of them -- its handling of mailing lists as pseudo-newsgroups offline is unparalleled, and the wonderful OO-based Embellish bitmap image editor is another, though I can replace Embellish with GIMP and a couple of other programs. Slrn with slrnpull is a somewhat limited replacement for Yarn, and my USENET use is dropping off these days, so Yarn is becoming much less a factor.
I also vastly prefer 4OS2 to bash as a command-line, though I've found some.inputrc tricks to make bash behave a bit more intelligently for command-line history searching, etc.
Actually, it runs fairly quickly on my PPro/200 boxes here at home (200MHz 686-class boxes running with 128MB or RAM or more), and even the lightweight LiveCD versions of Linux have issues with such hardware these days. Older version of Austrumi work fine, as do Puppy and DSL, but OS/2 is far more useful on such hardware... and has more software.:-)
I remember when Mandrake 8.2 running KDE 2.2 absolutely flew on such hardware, but Linux software has gotten bloated these days just as its Windows counterparts have. It's a sad statement about modern software toolkits and a general lack of caring on the part of software authors, IMO.
Roles/titles vary too much from company to company
on
Fire Your IT Boss
·
· Score: 1
Some smaller companies have technical Directors and CIOs who likely wouldn't be qualified to be a technical team lead or lower-tier manager in a larger established company with a strong technical history. Sometimes that's fine. It depends on the company, on the nature of the people over, above, and around each key person, etc.
"Managers" in some organizations code (and are effectively Technical Team Leads with hire and fire authority), while "Managers" in other organizations simply manage. Some organizations don't have a manager level at all, while others might have three levels between "Directors" and FTEs.
Sometimes a project management layer exists which handles things like large project coordination and the like, and sometimes that fals into the lap of a manager. Or a tech lead.
Some companies allow their managers to make strategic decisions about where their area is going, others don't even give them much input into the process (being driven instead by internal user groups and organization-level processes).
I've worked for a large technology company, a large airline, a small manufacturing company, and a meduim-sized IT company, and all four of them are so different in the organization and general approach to IT that it's very very difficult to compare a position in one to a supposedly similar position in another.
That makes it hard to come up with snap judgements about "who is responsible", since a large and complex organization might even have multiple internal corpirate cultures. Look at IBM for an obvious example, but even a much smaller company like Northwest Airlines had three distinct IT cultures: IBM mainframe, Unisys mainframe, and UNIX. There are very different processes and general mindsets in each group, believe me...
Re:Writing hello world is not a manager job
on
Fire Your IT Boss
·
· Score: 4, Insightful
No, often a manager also manages resources, makes decisions as to future projects and product directions, etc.
A certain amount of technical knowledge is required. Either that, or the manager has to be willing to listen to and trust those who are knowledgeable below them.
I've seen good managers who were technical and listened, good managers who were technical and didn't listen as often, and good managers who were nontechnical but knew who to get reliable information from. However, I've never seen a good technical manager who lacked the technical background *AND* didn't listen to underlings.
Note that Linux doesn't have one, either.:-) And OS/2 does have a common dialog that most program use -- but there are exceptions to that, just as their were (and probably are) under Windows and MacOS.
That's right. If it isn't a UNIX-based or Windows-based OS, it doesn't deserve to live regardless of what it might have contributed to history or what functional/technical merit it might have for future generations. POSIX and Redmond have all of the computing answers, and are the only technologies that were ever worth anything...
I started looking at Linux before the 1.0 kernel release, but couldn't take Linux serious until I ran into some of the more mature Red Hat releases around v5.1 or so. After that point, I've used Linux pretty much in parallel with OS/2, since each still does things the other does not.
If you're under the impression that Windows NT somehow succeeds the 32-bit OS/2 clients released by IBM, then no wonder you don't understand the OS/2 community that survives -- you think we still use the old 16-bit POS that was created in the IBM+Microsoft days. Methinks not.:-)
OS/2 still has advantages in process prioritization and multithreading that neither Windows now Linux can touch, and you can feel the difference on old enough hardware. OS/2 responds quickly where WinNT 4, Win2K, and various Linux variants will hesitate and/or pause when performing tasks. With modern hardware this isn't as important, since you can throw enough hardware at the problem, but not everyone wants to trash the older hardware they have lying around...
Not quite. IBM retains what rights it originally had, and hasn't given up anything -- it's just that Serenity Systems now also has reselling rights for the OS/2 client and other related technologies.
Slashdot Mirror
The flight operations system I used to work on at a major airline came from another major airline -- we traded some gates for the source and rights to use it, and the two airlines continued to develop the software in parallel over the subsequent decade plus.
Such things are not uncommon in the mainframe world. Customers who bought multi-million-dollar packages from a commercial mainframe software vendor would often receive a copy of the source along with the rights to use the software, and many of those customers made extensive internal modifications for their own benefit.
One of the challenges as a support programmer of such software is to verify that any issues discovered by the customer were in fact problems with the standard product and not problems with code that was introduced at the customer site. :-)
Pedant. I was listing things I've heard people say, not commenting on their accuracy. :-)
...other things I've heard people say:
AIX is not UNIX.
BSD is not UNIX.
Solaris is not UNIX.
What's left? Coherent? z/OS? :-) :-)
Windows isn't the problem, it's clueless folks who decide that all solutions must run on Windows regardless of the relative merit of that platform.
They're all tools, not religions. People should choose and use platforms as appropriate for the task at hand.
On Unisys Dorado mainframes running OS2200 we tend to use Fortran, but Fortran has always been a commonly used language in the airline industry. Not COBOL so much.
FWIW, Sun doesn't make "mainframes" in the traditional sense of the word. That term is usually reserved for boxes running an IBM OS (zOS) or one of the other legacy mainframe OSes (e.g., OS2200 from the UNIVAC world, MCP from the Burroughs world, etc.).
Mainframes use a mix of compiled and interpreted languages just like any other complex platform. COBOL and Fortran tend to be compiled, not interpreted.
I wish Unisys had the foresight of IBM when it comes to running POSIX software on their mainframes. Or maybe they do and I just don't know about it. They are seemingly a stealth company, after all. But they still manage to sell some very good mainframe server hardware (Clearpath Dorado and Libra servers running OS2200 and MCP respectively), and both of those OSes run fairly old software as well (the 2200 stuff requires a recompile as of some point in the 1970's when the ABS format changed, but I'm not as sure about MCP's binary compatibility).
Man, if we could run Solaris in a partition alongside our OS2200/HVTIP stuff...
Yes, the flight crew can be receiving updated WX and MGL numbers at the gate and on the taxiway, but that info is not something which would typically cause any flight delay, and it certainly isn't something automagically handled by the avionics onboard.
Background: I spent over a decade working on the Weather and MGL/Gross Weights ground systems at a major red-tailed US airline which handled most of the ACARS traffic to/from that airline's aircraft. Some of the stuff I dealt with included weather reporting and alerting (SA/METAR, FT/TAF, TWIP/Microburst Alerts, Turbulence Plot messages, NOTAMS, etc.), aircraft fuel on board (FOB) validation, takeoff and landing performance data including the optimal flap and thrust settings used for reduced thrust (FLEX) takeoffs, etc.
The ACARS terminals we used had a small text screen roughly 16 lines x 22 columns in size (the specific ACARS terminals and screen sizes tended to vary some by aircraft type), and the pilots were able to interactively request all of the above information in the event that an automatically generated message or alert was not received. They could also send and received freetext messages, and of course they also might have radio contact with their assigned flight dispatcher.
All of the operationally-related ACARS information was received and interpreted by the flight crew, and were not automagically handled by avionics. In addition, the same messages were cross-checked by both the flight crew and the flight dispatcher assigned to that flight (who received a copy in real-time of the same messages sent to the a/c via ACARS), and any issues with the data were dealt with well before the a/c started its takeoff roll. They mgiht be requesting WX and/or MGL updates while taxiing, but you can believe that they already have fairly accurate information well before that point.
ACARS messages provide additional information and advice to the flight crew, but the flight crew is ultimately responsible for doing some basic sanity checking on the numbers provided, and any changes to the a/c's takeoff or landing procedures are initiated by the flight crew, not by some automatic system.
Some automated ACARS traffic is processed, but those things are limited to things like automated Fuel reports on some aircraft (e.g., A320/A330), and various engine performance reports that can be interactively obtained by the performance engineering folks while the a/c is still in flight (they can request an engine status report enroute via ACARS, which then gets send to them via ACARS, and proactively notify the folks at the destination airport that some form of adjustment is required on landing).
Other airlines may vary. Also, my information may be somewhat out of date as I failed Axe Dodging 101 just after 9/11 and haven't worked in the flight operations area since leaving the airline. I still work on airline software, just not in flight ops. :-)
Hope this helps...
Why aren't copyright and software licensing restrictions enough to protect Apple's dock code?
That's what those two things are INTENDED for.
Please... IBM's 32-bit OS/2 ran circles around Windows NT in its day (as a fine example, search for YouTube video of David Barnes demonstrating OS/2 versus NT back in the early 1990's), and I'm sure the Warp 4.5x kernel will run runs around XP, Vista, and probably also Linux and *BSD kernels on similar hardware even today. The OS/2 kernel used rings 0, 2, and 3 which was very usual for x86 code, but it also was extremely good at juggling multiple tasks and threads under load and at dynamically adjusting process/thread priorities to make the entire system smooth.
I remember some magazine doing a test of OS/2 Warp Server versus NT server sometime in the 1994/1995 timeframe, and a single-CPU Warp box trashed a 4-CPU NT box running the exact same benchmarks.
Notes is a bloated hog, yes, but OS/2? The evidence suggests otherwise.
Doesn't IBM still make IntelliStations? Lenovo is their consumer stuff. Blech. :-)
I use it heavily for discussions, and never really got into the binary side of it.
Not only do many news providers do a certain amount of filtering, but regex scorefile capable newsreaders are quite good at removing a certain amount of cruft.
I know emacs, vim, and NEdit, and I would MUCH rather use the latter.
While I agree that vi knowledge is probably needed just as a general skill (you know that some variant of vi will always be present on a modern UNIX box), I disagree that it (or emacs) is a "better" general programmers editor. For me, at least, it isn't.
Yeah, I forgot it was 6.5% (hey, it's been four years since I lived there), but I suspect the rest of those taxes would not apply to computer parts. :-)
I agree that simply technical acumen is not a good way to tell if a person is a good manager. It isn't that easy, and someone who might be a good manager for one team might be a poor fit for another team even in the very same organization.
It isn't rocket science. If it was that easy, everyone would be doing it. You have to fit the people involved and the context of the position. A good manager from a waterfall-driven software development shop might not fit in well at all when doing in-house development on a live system, etc. The culture differences between shops even in the same basic business can be tremendous.
Trust is earned in most contexts, not arbitrarily given. Someone will demonstrate trustworthiness over time.
That makes it harder for new managers because they have to make a decision at some point who is trustworthy and who isn't, but even one trustworthy advisor can make things a lot easier by pointing out other valuable resources.
There isn't a formula for this. Just like any human relationship, business relationships are complex and tend to shift over time. That's why people skills are important for anyone in a management position -- not only are they good to have from a political perspective, but they also provide many other benefits (like the ability to accurate read peers and underlings).
Sadly, business is more akin to politics than it is to technical design. Otherwise, geeks would rule the world, and IT management would tend to concentrate on making better systems rather than maximizing their stock options and parachutes...
My comment was a direct response to its parent.
If you have an issue with what I said, address the issue sans flamage, please.
OS/2 is better at running DOS software than either DOSBOX or DOSEMU, and there are a few native programs for OS/2 that I've not yet found good equivalents for under Linux.
Yarn (my SOUP-packet based offline reader for USENET) is one of them -- its handling of mailing lists as pseudo-newsgroups offline is unparalleled, and the wonderful OO-based Embellish bitmap image editor is another, though I can replace Embellish with GIMP and a couple of other programs. Slrn with slrnpull is a somewhat limited replacement for Yarn, and my USENET use is dropping off these days, so Yarn is becoming much less a factor.
I also vastly prefer 4OS2 to bash as a command-line, though I've found some .inputrc tricks to make bash behave a bit more intelligently for command-line history searching, etc.
A lot of it is taste, frankly.
Actually, it runs fairly quickly on my PPro/200 boxes here at home (200MHz 686-class boxes running with 128MB or RAM or more), and even the lightweight LiveCD versions of Linux have issues with such hardware these days. Older version of Austrumi work fine, as do Puppy and DSL, but OS/2 is far more useful on such hardware ... and has more software. :-)
I remember when Mandrake 8.2 running KDE 2.2 absolutely flew on such hardware, but Linux software has gotten bloated these days just as its Windows counterparts have. It's a sad statement about modern software toolkits and a general lack of caring on the part of software authors, IMO.
Some smaller companies have technical Directors and CIOs who likely wouldn't be qualified to be a technical team lead or lower-tier manager in a larger established company with a strong technical history. Sometimes that's fine. It depends on the company, on the nature of the people over, above, and around each key person, etc.
"Managers" in some organizations code (and are effectively Technical Team Leads with hire and fire authority), while "Managers" in other organizations simply manage. Some organizations don't have a manager level at all, while others might have three levels between "Directors" and FTEs.
Sometimes a project management layer exists which handles things like large project coordination and the like, and sometimes that fals into the lap of a manager. Or a tech lead.
Some companies allow their managers to make strategic decisions about where their area is going, others don't even give them much input into the process (being driven instead by internal user groups and organization-level processes).
I've worked for a large technology company, a large airline, a small manufacturing company, and a meduim-sized IT company, and all four of them are so different in the organization and general approach to IT that it's very very difficult to compare a position in one to a supposedly similar position in another.
That makes it hard to come up with snap judgements about "who is responsible", since a large and complex organization might even have multiple internal corpirate cultures. Look at IBM for an obvious example, but even a much smaller company like Northwest Airlines had three distinct IT cultures: IBM mainframe, Unisys mainframe, and UNIX. There are very different processes and general mindsets in each group, believe me...
No, often a manager also manages resources, makes decisions as to future projects and product directions, etc.
A certain amount of technical knowledge is required. Either that, or the manager has to be willing to listen to and trust those who are knowledgeable below them.
I've seen good managers who were technical and listened, good managers who were technical and didn't listen as often, and good managers who were nontechnical but knew who to get reliable information from. However, I've never seen a good technical manager who lacked the technical background *AND* didn't listen to underlings.
Note that Linux doesn't have one, either. :-) And OS/2 does have a common dialog that most program use -- but there are exceptions to that, just as their were (and probably are) under Windows and MacOS.
That's right. If it isn't a UNIX-based or Windows-based OS, it doesn't deserve to live regardless of what it might have contributed to history or what functional/technical merit it might have for future generations. POSIX and Redmond have all of the computing answers, and are the only technologies that were ever worth anything...
I started looking at Linux before the 1.0 kernel release, but couldn't take Linux serious until I ran into some of the more mature Red Hat releases around v5.1 or so. After that point, I've used Linux pretty much in parallel with OS/2, since each still does things the other does not.
If you're under the impression that Windows NT somehow succeeds the 32-bit OS/2 clients released by IBM, then no wonder you don't understand the OS/2 community that survives -- you think we still use the old 16-bit POS that was created in the IBM+Microsoft days. Methinks not. :-)
OS/2 still has advantages in process prioritization and multithreading that neither Windows now Linux can touch, and you can feel the difference on old enough hardware. OS/2 responds quickly where WinNT 4, Win2K, and various Linux variants will hesitate and/or pause when performing tasks. With modern hardware this isn't as important, since you can throw enough hardware at the problem, but not everyone wants to trash the older hardware they have lying around...
Not quite. IBM retains what rights it originally had, and hasn't given up anything -- it's just that Serenity Systems now also has reselling rights for the OS/2 client and other related technologies.