Lockheed has an opening for engineers with VAX experience for the F22
lockheedmartinjobs.com
lockheedmartinjobs.com
The real crux of the matter is that these companies don't want to pay top salaries and thus don't get top developers. As long as there are people who navigate themselves into such niches and are proud of it, the salary for these specialized jobs will stay where it is. Simple as that.
Been there and ran as fast as I could.
I don’t know COBOL though so I can’t say if this code is idiomatic or not.
If the company really needs the work done that badly and there's no qualified help willing to take it full-time, then this is a viable option. If there's no qualified help and they're not willing to go for a deal like this, then the work just doesn't get done.
I was struck by all the apartment complexes that did not live up to their name. They were not complex at all, they were... simple (simplex?).
The apartment buildings were designed like children draw houses, sort of like shoeboxes. They had pitched roofs and rows of identically spaced windows maybe 20 wide and 3 or more stories tall. Giant parking lots to match each building.
To be clear, it was probably affordable housing, and I don't know if it's still like that, but it lacked character.
Perform on-aircraft troubleshooting of the F-22 Avionics Systems in support of the F-22 flight test program at Edwards Air Force Base (AFB)
https://web.archive.org/web/20190618050109/https://www.lockh...
The binge-purge cycle at these places is not how I think things should be run, but I expect Congress is somewhat to blame for the cycling.
I'd like to say that I'm astonished that modern aircraft still use the 1553 bus, but nothing surprises me when it comes to the use of stone-age tech in military hardware. For example, the other Harrier I worked on in the early 90s (GR-7 - same as US AV8B) still used core memory.
What's wrong with 1553? It's reliable, battle-tested, and the latest revision C was published 28-Feb-2018. In contrast, the RS-232 PHY dates back to 1960, yet it's quite alive and well in modern commercial devices. As a consolation, be glad you've never had to deal with the monster that is STANAG 5516/MIL-STD-6016...if there was such a thing as a "modern" interface standard whose sheer page count (11,410 pages!) would make any sensible engineer reconsider future career prospects.
Never mind the fact that many areas of the standard don't matter because the manufacturers of equipment that use those areas made up their own way of doing things that isn't 6016 compliant. So you can comply to the standard, or you can actually work with platforms in the real world, but you can't do both.
Technically I think platforms are supposed to document the areas where they're noncompliant with 6016 and submit it for approval. The name of the process escapes me at the moment. Not sure if anybody ever does it, though.
Military gonna military I guess.
Core memory is a lot less sensitive to this than most memory types, so it makes some sense to store the most flight critical data in such a memory.
I think Eisenhower thought that this would insulate NASA from postwar budget cuts and make its funding more secure rather than less.
In retrospect, Eisenhower was a hell of an optimist.
Not the Space Force?
> https://www.buzzfeednews.com/article/briannasacks/trump-spac...
;-)
The majority of the on-board avionics were based on vacuum-tube technology, not solid-state electronics. Although they represented aging technology, vacuum tubes were more tolerant of temperature extremes, thereby removing the need for environmental controls in the avionics bays. With the use of vacuum tubes, the MiG-25P's original Smerch-A (Tornado, NATO reporting name "Foxfire") radar had enormous power – about 600 kilowatts. As with most Soviet aircraft, the MiG-25 was designed to be as robust as possible. The use of vacuum tubes also made the aircraft's systems resistant to an electromagnetic pulse, for example after a nuclear blast
Soviet gear was robust because robustness and repairability was priorities as a design criterion. It's not an automatic product of how they doled out work, or of their defense industry generally.
Not sure if this was a conscious decision wrt EMP, or was it just that they were in a hurry to develop a jet bomber for delivering nukes and they reused existing stuff as much as possible.
Flight engineer and radar operator in the seats behind would have got the fancy new (for the early 50s) electronic things.
There is absolutely noting wrong with using old technology. Being modern just for the sake of being modern is wasteful.
I will grant that there are some things that just keep working and I also would be tempted to leave them in place. But if their functioning is critical then we either need to cultivate the necessary knowledge in our organization to ensure we can manage them adequately or replace them with something that the current market of people will be somewhat familiar.
A bigger part of the hiring problem is aerospace software, specifically military aerospace software is a difficult field to hire for. Clearance requirements limits your pool. Building weapons of war limits your pool. Low salary compared to other software job limits your pool. Very high level of process / low velocity of shipping limits your pool. If you require experience in the environment, rather than training otherwise appropriate candidates, that's going to be a limit too, but if you work in a specialized environment, you really have to accept that you will need to train people.
The current hiring model of "hit-the-ground-sprinting day 1" I suspect is largely the problem here and stems across many industries complaining about hiring difficulties.
Since this "best existing skillset match" hiring model businesses have widely chosen to adopt provide little-to-no on the job training, people will inherently focus on learning the most widely adopted skills of their target market(s) to increase their odds of finding a position in the labor market. Even niche skills will typically target larger proven successful niches and not target risky niches.
As a result, your business better follow industry and technology trends as they shift or you better start investing in your employees and maintain a positive relationship so you don't lose your knowledge assets that are likely undervalued by your business.
Even if Lockheed pays me double, even triple, my current rate, it's likely not worth it for me me wasting my time investing months to years in their specific architecture and fairly non-transferable skills acquired doing so since employer/employee relationships and loyalty are dead. That's a hefty investment on my side with little investment on theirs.
No thanks. It can sit empty and their project can fail for all I care.
And re-doing all the avionics would be a probably decade-plus effort costing billions of dollars. Cheaper to hire some old VAX guys as consultants, pay them exorbitant rates, and have them train up a new generation of VAX people.
Iteration time goes down by a lot in wartime. Also, choosing technologies which have much shorter iteration times could be a disruptive game changer. I'd bet shaped charge carrying drones with a range of 4 km would be much faster to iterate on than tank guns with the same range.
I think that it's important to remember that there are both direct and indirect costs to "not changing something that's working".
If you don't keep abreast of change, then you're unable to be nimble enough to change when change is hugely advantageous.
Locking yourself into design decisions is usually cost-effective for the short term, but may be ultimately very harmful in the long-term.
Code is legacy the moment it's put into production. Keeping technical debt from piling up, and keeping on the bleeding edge to avoid costly maintenance of old systems is extremely expensive. And the costs escalate very quickly when you're talking about airplanes. The cost of dealing with legacy becomes acceptable very quickly.
Perhaps you should not fire them, then.
That said, I'm not flying airplanes over here. It's mostly business software. So there's that.
require(‘left-stick’)"We can't solve problems by using the same kind of thinking we used when we created them."
I think you're thinking of Mark Twain.
That's true, but military logistics has adapted to mitigate some of these costs.
> Parts become obsolete
There are two ways this is dealt with. The first is an activity called Diminishing Materials Suppliers (DMS). DMS is an ongoing support activity during production where the availability of parts is monitored and alternative parts are selected and evaluated if a manufacturer announces they are stopping or modifying production of a part for which they are the sole supplier.
The second is the lifetime buy. Near the end of a production run, and sometimes earlier, engineering figures out how many of a given part is needed to complete the full production run and provide spares for rework and repair. Purchasing then gets approval under the contract to purchase the entire quantity of materials and the stock goes to a warehouse until it's needed.
> engineers retire or move on
Knowledge transfer is one of the big reasons the defense industry is so big on systems engineering and mountains of documentation. Obviously that only goes so far, but generally there is less tribal knowledge within a DOD program than in most commercial engineering efforts.
> IT has to maintain archaic devices, operating systems, and tools
In general, IT doesn't go anywhere near the software and equipment used to program, test, and troubleshoot hardware and embedded software. Those pieces are owned by specific engineering teams on the program.
Within a well run DoD program. Most of the larger programs are not well run, in my personal experience. And DoD did this silly thing where it let contractors keep the rights to their engineering data until relatively recently, meaning that US taxpayer dollars are funding the purchase of hardware the government by definition can't understand, because the government isn't allowed to know about or look at much of the engineering data. So there's a HUGE amount of tribal knowledge in some of these programs because there's nothing else to reference.
What's crazy about these systems is they spend decades writing millions of lines of code, and then only put it in 200 devices.
But there's an entire industry which exists to soothsay away these concerns and get companies to upgrade, whether or not it really makes any sense. Nobody has an interest in encouraging companies to keep using their old gear and do internal training; many companies have an interest in encouraging upgrades.
In the case of war birds, newer technology does not mean faster development time. In order to qualify electronics for a weapon that needs to be stealthy and resistant to electronic warfare you need decades of operational data on all of the major electronics components. Any system that gets upgraded to newer technology has to go through risk assessments and that often requires tons of data collection before you even get started.
I think you vastly underestimate the lengths our military industrial complex goes to protect operational capabilities. The F22 is as much a beneficiary of those technologies as a platform for keeping them alive for future use.
Feel free to apply for some jobs in the defense sector to find out how much they pay. You'll make more money working at FAANG companies, and you don't have to wait years for a security clearance to be approved. Jobs in aerospace, in particular, are pretty lousy paying compared to what engineers are getting elsewhere.
You'll make more money working as an NBA player, and you don't have to wait years for a teaching certificate to be approved. Jobs in schools, in particular, are pretty lousy paying compared to what sports lovers are getting elsewhere.
The fact that FAANG companies employ about 0.1% of the software developers could have something to do with this. Practically speaking, nobody works for the NBA or for a FAANG company.
So it is a silly comparison. Defense contractors can and do beat plenty of normal companies. For example, Tesla pays software developers just $78k to $147k. Defense contractors can beat that before even adjusting for quality of life. You can work a 40-hour week, or you can have Elon Musk cracking the whip. The defense contractor positions are frequently in affordable locations, making the numbers a far better deal than they would appear.
Citation needed. That seems suspiciously low for silicon valley.
>Likewise, why wouldn't any person who loves sports work for the NBA instead of as a gym teacher?
Your argument doesn't make much sense here. You trot out this line, but then you try to make the case that defense contractors pay well (which isn't really my experience; they pay OK (except for "cyber" positions which are paying really well currently), but nothing fantastic compared to non-defense companies in other non-silicon-valley areas), so it doesn't follow. Gym teacher jobs pay close to poverty-level wages, so accordingly, the people who take those jobs are usually people who aren't good athletes themselves, or maybe people who have a spouse with a good income and can afford to have a job for the fun of it.
https://www.payscale.com/research/US/Employer=Tesla_Motors/S...
It is improper to declare that any company outside the highest paying 0.1% is somehow not up to standard.
It is also improper to ignore working conditions. If you end up working 60-hour weeks for $180,000 the pay is no better than working 40-hour weeks for $120,000.
It is also improper to ignore cost of living. House prices can differ by a factor of 20, not even counting the collapsing locations. Just the difference between San Francisco and a medium-small non-coastal southern city is that much.
This isn't correct at all; you're totally overstating the CoL differences. If a decent apartment in the Bay Area costs as much as $3k/month (I'm guessing here), there's no way in hell you're going to find a comparable place anywhere in the country for $150/month. In my experience, cost-of-living just doesn't differ as much between places as people like you claim it does. What does differ is price-per-square-foot, but no one realistically expects to live in a giant McMansion in the Bay Area or Manhattan as a middle-class person. The problem with "low cost" areas is that they typically don't have any actual inexpensive places for single people or childless couples, and your options are usually either a house that's much too large with huge utility costs, or a trailer park surrounded by opioid and meth addicts.
Basically there are two entirely different paths here. For example, the person who writes all the software to drive the cockpit displays is probably called something like a "cockpit avionics engineer" and is organizationally in the department that's responsible for building such things. These people can get paid very well.
On the other hand, a "software developer" is much more likely to be a support function. Lots of maintenance of legacy stuff more than anything, and what actual development work exists might be nothing more than taking an algorithm directly from a standard and implementing it in whatever language is required by the project. These roles are not particularly well-paid and have a lot of turnover.
It is a very different world.
I don't know how Lockheed organizes, but I assume it is similar to Raytheon. Raytheon had a matrix organization where the rows are functional groups (e.g., software engineering, digital electronics engineering, RF engineering) and the columns are program teams (e.g., radar power supply, radar antenna, radar signal processor). The title you describe would align with a program group, but your "official" title would come from your functional group (which would be software engineering in this case).
> These people can get paid very well.
In the absolute. For software engineers, it's pretty average. I was writing some pretty cutting-edge embedded signal processing software when I left Raytheon in 2012, and I was getting paid $85,000/year with 9.5 years of experience. Based on my trajectory, I would have been at around $120,000 now had I stayed. This was in Dallas, so it was good money compared to the COL, but I could have made slightly more at just about any other larg-ish employer in the area. That said, I both sucked at and hated the internal political games at Raytheon, so perhaps I could have done better if those weren't true.
But LM is actively trying to reduce its number of Level 5, 6, and 7 engineers (the highest paybands on the technical career track). You would typically find a Level 5 engineer serving as an engineering technical team lead, a Level 6 as a site deputy chief engineer, and a Level 7 as a site chief engineer. A few years ago, LM Aeronautics offered all Level 5 and above engineers an early buyout/retirement and got over 1000 engineers to leave the company that way. Those engineers were largely not replaced, either in skills (hard to replace that level of expertise), billets (those jobs were not re-filled), or promotions (the sudden vacuum at the top end of the technical career pyramid was not filled by promoting large numbers of level 4 engineers to level 5, etc).
What did Lockheed hope to accomplish by this move?
Do you know what the total realized effect was?
This was the precursor to layoffs -- LM hoped to avoid layoffs by offering buyouts to these engineers. The wisdom of all of this... I don't see it.
Their goal was to reduce total amount spent on salaries.
This came at the time that the F-35 flight test program began its long wind-down. Other companies were hiring in large numbers because they had just begun big test programs (NGC had just won the B-21 contract and was testing its Triton UAVs), the net effect was that a HUGE amount of engineering knowledge and talent went out the door within a year. I can only speak for what it did to the F-35 test forces -- basically made them start over in terms of learning how to execute their jobs.
Hence a lot of experienced Mobile engineers took the buy out and went to work with the competition and got a pay rise to boot in their new jobs
Back in the early 2000s I know of some J2EE architects that pulled $200k as defense contractors once they got a Sun certification. The certification and diploma mill market in the US is driven squarely by big federally funded institutions that value paper over experience because they don’t know how to measure ability any better than SV Leetcode questions would assess.
Of defense contractors I’ve seen pay tables for in the DC area, LM and Raytheon paid worse for senior engineers than slightly smaller, more specialized companies but they certainly had a lot more overhead and administrative positions available that were possible to reach just by having a PhD even if it’s not related to engineering or STEM in general at all (political science obviously makes sense here as valuable, for example).
But under DHS you can hit $200k+ as a contractor for anything that has “cyber” attached to its name these days. But for the most part, the high payout days for software engineers in defense are over which is what led me to leaving the DC area years ago to stick with better pay and work environment with private sector. A TS is a pain and the pay bump is a joke compared to RSUs. I’ll take leetcode grinding for months to get a stack of RSUs and marketable engineering skills over the demonstrably useless charade of the DoD security theater practices with none of the employment benefits besides some smug, self-assured sense of patriotism.
Most of the higher paid contractors in DoD aren’t engineers - they’ve usually been intelligence officer trainers and skilled and experienced warfighters (well past $400k, much of it untaxed).
1. It's typically a 40-hour week. They legally can't make you work 48 or more without paying overtime, and many will start paying overtime after 40.
2. You don't have to live in an expensive place like San Francisco, Palo Alto, Mountain View, or New York City. The worst cases are usually the DC area and San Diego, but typical locations are far cheaper. Instead of $2,000,000 for a house, you might pay $120,000 for a better house. Everything around you is cheaper too, from food to electricity. Gasoline is half the cost.
The choice is pretty clear if you hope to raise a family.
I don't know what LM is going to pay for the skillset they ask for in that job announcement, I would bet that it's 150k or less, but the person w/ the skillset to answer it may be able to command a bit more as there aren't very many of us left.
There is also the fact that finding ways to get more ads in front of people is not inherently motivating for some engineers when compared to building space systems or solving other interesting problems like deconflicting telescope laser alignment with satellite orbits.
When I worked at Raytheon (2002 - 2012) overtime had to be pre-approved (not every contract was eligible) and you had to work at least 8 extra hours in a week to get paid overtime (the 8 hours were paid if you hit the threshold; 7.5 and you didn't get anything extra). There was also an expectation, at least on my program, that you would be working overtime if it was authorized.
Amazon is a defense contractor. Google is/was a defense contractor. Apple is a defense contractor. Microsoft is a defense contractor. SpaceX is a defense contractor. IBM is a defense contractor. ...
You may believe that, the market doesn’t.
Boeing isn’t a defense contractor by most people’s metrics. None of the faangs are by almost any standard.
This is also a self asnwering question of sorts. If, let's say Lockheed would pay 'FAANG' salaries then it would be 'FLAANG' since the abbreviation is meant to encompass the top paying salaries.
A PhD with 20 years of experience = this pay band
You can pay your people whatever you want, but the gov will only pay your people what the DCMA says they are worth. If you pay higher, it comes out of profit (which is also metered by the DCMA) or some other source.
Source: A own a R&D engineering company that works for the DoD and IC.
I can pay a EE PhD $400k/year but the DoD will "only" pay me back around $175k for this person's time. I have to make up the difference.
Hence, for defense contractors, we "only" pay what the DCMA will let us charge.
In order, what matters are: tickets, experience, degrees, certs
Defense contracting is a very different vehicle from any other. Source -- I am a DOD contract software engineer.
Itanium was intel's failed attempt at a 64bit architecture and that's the platform VMS decided to port to. That made hardware expensive and as of recently obsolete (i think hp discontinued that integrity line of servers)
VMS doesn't natively support TCP/IP, because it predates it. The VMS communication protocol was called decnet. So you can imagine that porting vms-specific fortran code to work on a modern network stack was non trivial.
Also, everyone with VMS knowledge was a hacker. No real design or plan, just go in an change a thing here and a thing there and get it working.
All that being said, it was interesting to work on an OS that is so different from linux, specifically the file system had versioning.
VMS' clustering tech was also pretty great, which is the reason my late-90s employer was still on it (though on Alpha hardware at that point, not Vax).
OpenVMS x86-64 port is a work in progress: https://www.vmssoftware.com/updates_port.html
1. RE: FORTRAN. VAX FORTRAN was the most awesome implementation of FORTRAN ever. FORTRAN because these systems didn't have much RAM and CPU power was limited. FORTRAN went into the background for a while when the C fad began in the early 1980s; however, academics cringed at C for reasons that the industry would eventually learn "the hard way" and FORTRAN came back along with a government knee-jerk reaction called Ada and a pile of 4GLs starting with DATATRIEVE --up until processors and RAM allowed for more productive use of more powerful "safe" language systems (Java, C#, Python, Swift).
2. RE: ITANIUM. DEC created VAX/VMS for the break-thru 32-bit VAX-11 architecture and then ported it to its break-thru 64-bit Alpha architecture and rebranded it as OpenVMS. The Alpha chip was really powerful, but it was produced only by DEC's Hudson chip plant (which also produced the StrongARM chip whose descendants are in all of the smartphones). To address the customer need for a second supplier for that chip, DEC began to shop around the Alpha architecture to other semiconductor manufacturers. One of those was Intel --which decided not to become a second source and a little while later, announced the Pentium series that revived its ALL BUT DEAD x86 architecture using patented concepts found only in DEC's Alpha chip. There was a lawsuit and the settlement was that Intel would buy the Alpha chip and Hudson plant. This resulted in the Itanium architecture, which the then owner of DEC (HP) decided to embrace for OpenVMS and its other HP operating systems. As the Pentium chip gained momentum, Intel realized it would be more profitable to use the tech to make X86_64 architecture. Meanwhile, Microsoft, which was all but ready to dump the ALL BUT DEAD x86 architecture (in favor of MIPS and PowerPC), pivoted with Windows NT and released full support for X86_64. Considering that Windows NT was developed by the original computer scientists behind VMS and considering the dominance of Windows on the desktop and the low cost of X86_64 hardware (due to economies of scale), it was no surprise that Itanium fell out of favor, and OpenVMS along with it (though there were many heroic efforts to "rescue" OpenVMS from that dead architecture, HP had no real interest --at least not in time).
3. RE: VMS TCP/IP. This cracked me up. I wrote one of the first TCP/IP stacks for VAX/VMS on a VAX-11/780 using InterLAN hardware. You are correct that VMS pre-dates TCP/IP --but dude it was only by like 1-2 years! VMS was uses with XNS/ITP (upon which TCP/IP was based). TCP/IP is le grand garbage --as the entire planet knows now and DEC had bet heavily on something called OSI to replace DECnet. But some f'n jack head named Vincent Cerf created an async implementation for TCP/IP that allowed the bazillion Windows PC to hop on the Internet (what could go wrong) and that quickly became Microsoft RAS which destroyed the universe quickly. All of the stable and secure networking systems died. Bill Gates was interviewed at one point and responded to a question about what the biggest unexpected development had been with a dumb look saying he had failed to predict the sudden end of distance-and-time based pricing for data communications. So now, dude in St. Petersburg can show off his genetic superiority by hacking the microcode in the Intel Ethernet controllers in your laptop from 8,000 miles away at virtually no cost. Enjoy!
4. VMS knowledge are hackers. This is among the most outrageous comment I've read on the Internet. VMS was all about structure and discipline. If you weren't a computer scientist (or college student) you weren't even getting a job working on one! What you probably observed had nothing to do with VMS but just maintaining legacy code in general.
5. RE: "interesting". VMS was the most powerful operating system ever created well into the modern era. You can imagine that the guys creating Windows NT at Microsoft (who previously developed VMS for DEC back East) were not being allowed to create the true successor to VMS --the idea was to get something working on small cheap PCs that would be sold to all of the small businesses, not on continuing to perfect the product of 30 years of engineering (as VMS descended from their prior RSX11 and RT11 operating systems) as they had been doing first to the 78032 "chip" and later to the Alpha processors. I think around 2015, Windows, Linux and MacOS finally began to pull away from where VMS was (back in 1990). One can only imagine how powerful VMS would have become when run on something like the MacPro 7,1 that Apple announced.
In conclusion, true industry leaders, many of whom did not support VMS back in the day (because they were forced to embrace crummy UNIX System 3, V and BSD "hacks" for lack of access to the incredible DEC engineering resources), will tell you that VMS (and TCP/IP) are stories of lost art that severely setback the pace of mankind's development. The reasons are many: Bill Gates' well known BS, Vincent Cerf's destructive efforts to advance PPP, alleged theft of intellectual property by Intel that set off the downward spiral of DEC, skyrocketing memory prices due to market manipulation and Carly "That Face" Fiorina.
Consider yoh-self schooled.
> If you weren't a computer scientist (or college student) you weren't even getting a job working on one!
Exactly. A system whose priority is preventing people from ever using it.
Right!
> , worked well enough for most people
Well, with a mouse click, the Chinese can cause most of the self-balancing mobility devices (scooters, etc.) within a few miles of all military bases and schools to turn off while doing 10-20mph down the street (thus seriously injuring the rider). Goin' be tough to fight a war with ripped up ACL/MCLs and broken bones! 100% of the technology came from the fruit of Richard Stallman's religion.
Can't feel me? Okay, how about if you work for the federal government or have a credit file in the United States (or much of Europe) and all of your financial information is stolen so that the data can now be used to kill your family (either literally or financially) if you don't give them something they know you have and that want (or maybe even if you do!).
So I respectfully disagree with "well enough for most people" because impressionable tech kids didn't know any better ("everybody is doing it") and were convinced to give away their advanced technology over the Internet to people who can't or shouldn't handle it because they want to kill us (literally or financially), aren't trusted and/or don't have the proper education.
Fortunately the passage of time heals all wounds and much that free software movement was really just a bunch of knock-offs of truly new art that was created by companies that have been drifting "sideways" lately (since their founders left) and that's given the governments (barely) enough time to catch up. Soon, code will have to (by platform regulation and eventually federal law) be signed by a third-party before it can run on some unsuspecting user or business' computing platform. But also, there are the Amazing and Wonderful Services that are scooping up all of the millions of would-be idiot developers and subsidizing their lack of educations to ensure that they don't get into too much trouble (and to quickly identify and neutralize them if they are trouble). There's such a demand for this service that they're able to use the revenue to fund a fleet of friggin' spaceships and deep sea exploration platforms.
> his own narrow view of how it should be done
Right again! But note that narrow views coming from some people are far better than the consensus of many people. I know that breaks Star Trek or something, but it happens to be how American business works, for example.
Nostalgia is a trap. Wallowing in the idealized "good old days" blinds you to the true scope of history and cuts you off from progress.
Retrocomputing is just a hobby of mind. It's fun to play around with those old systems.
At one point, I was convinced that understanding the format of an executable file (a.out, COFF, XCOFF, Mach-O, ELF, .com, .exe, PE, etc) was important to understanding the operating system itself. I spent a fair amount of effort and some money buying books trying to find the VMS executable file format. Couldn't find a hint.
1. The codebase that I was working on was not awesome, it was a mix of Fortran (while i am a fan of and would much rather use that than C for scientific code) and DCL. Lots of stuff that was clearly a design afterthought, but with decades of momentum and an attitude of "just keep it working"
2. There's a lot of history in VMS, but unfortunately it's primarily used to support legacy projects, and with intel not making anymore itanium doesn't seem like there is a future. I couldn't even get a working version of the netbeans plugin to work with it. Basically I got the plugin with no support, despite having a service contract, because there was no engineering supporting fixes.
3. Could have been that the way we wrote out networking was a mess, but I do believe that TCP/IP was an add-on feature that was not part of the kernel.
4. That statement was exclusive to the people i worked with. They were not CS guys, they were support people that had enough experience with the system to get a spot in engineering. They knew how "that" system worked, but not how to solve problems without relying on legacy code that was based on obsolete ideas. I shit you not there were delays in the code because the network was "too fast" and the process couldn't handle it.
5. Solaris is the bomb too.
Take a chill pill, boo
Newer releases (6.0 and above, I think?) do have DEC's TCP/IP layered product included. I believe it was called "UCX"...
BTW, this will give you the warm fuzzies:
I hope they are optimizing the design to run in a VM, with drivers only for fake VM devices, one of each kind.
...which they didn't make but licensed from AMD, no?
This isn't remotely true.
You know, I should apply for that Lockheed job just to get shutdown for being in my 50s and not having touched a VAX since my 30s (because, you know, it's changed so much since then rofl)
It helped me get that job that my dad had worked at DEC for years and I had an RT-11 system sitting on my bedroom desk for years. Knew VAX ops fairly well then. Also about 30 years ago.
> The ATF Team planned to develop approximately 1.5 million source lines of code, across more than 20 software development companies located throughout the U.S., Canada, and Europe.
To get to the total 1.5M LOC, it's after decomposing the system into lower level black boxes and doing some modeling/simulation.
How many lines of code has it taken in the past to build our navigation systems, radios, weapon system A, weapon system B, etc. How much integration work is there? If its a CAN bus, the last project had X LOC for the bus architecture. Add em up, and add a big fudging factor.
It takes a lot of discipline and planning, but in the end it's the most accurate method of size and time estimation I've ever seen.
Whether that's true across widely differing parts of such a huge system I'm not convinced, but within a single more typical software project it seems believable to me.
Someone decided that the task was about 1.5 MLOC and used that to drive the total contract value.
It's possible, with highly detailed design documents. You could use something like "cyclomatic complexity" which is an older estimation methodology which is just a laundry list of small granularity features with point values attached. You add those up, while multiplying some weighted numbers together to account for interlinked complexity, then use a figure for the implementation language to come up with an estimated LOC figure. Error bars on that kind of thing are something like +/- 100%/50%. (I'm pulling numbers out of my @ss here, but I'm talking about a highly ritualized and systematized way of doing just that.)
You can get better estimates, usually by asking shops that have written the same sort of product many times before.
(https://en.wikipedia.org/wiki/Cyclomatic_complexity)
Calculating this involves working out the number of branches through the code, nothing to do with estimation. It is also very much in use today to analyse codebases, finding hotspots, etc.
https://priceonomics.com/the-typo-that-destroyed-a-space-shu...
Software saved the aerospace industry. Every other way of adding cost to an airplane also adds weight.
He spent most of his career at Lockheed and Rockwell.
In practical terms it night as well be 0 but in silly discussions on the internet terms it's a very small non-zero value.
However, you can get any number of additional bits by suspending the punch card from various locations along its perimeter, and measuring the angle at which it hangs.
Is hanging chad a 0 or a 1?
We had to maintain an old Micro VAX box in the office to periodically test that the toolset still worked on it. I seem to remember that the massive regression test suite that would run in a few hours every night on a PC would take days on this box.
Our main worry was that one day we'd turn it on and the drive would fail to spin up. I seem to remember there being a periodic reminder to just turn the damn thing on and let it boot every so often, then shut it down, just to make sure the drive was still ok.
Anyway, the processors in the F-22A are a mix of different cores. The power supply in the Gen 3 radar used a MIL-STD-1750A processor. The PICC[1] processor modules also used the MIL-STD-1750A originally, but moved to a newer processor in a refresh (if I remember correctly). I don't know what the non-Raytheon components of the plane were using.
As for the compiler, you are spot-on. We had a MicroVAX in a vault (it was a cleared computing system) just in case we needed to recompile the embedded software for the power supply controller.
[1] Unfortunately, I don't remember what this acronym expands to.
(Or does "MISRA" stand for something else?)
Is that muscle on my face twitching due to PTSD? Yes, Yes it is.
> Experience with troubleshooting equipment such as Pass1000/5000 1553 bus monitor, fiber-optic test equipment, digital storage oscilloscopes, and familiarization with the VAX/VME based computing environment.
Seems apparent to me that the context is development+ATE environment; VME is likely VXI interface to ATE instrumentation. In any case, the VMS and/or VME angle to this job post is the least of any prospect's concerns.
Oh yeah ...
• Experience in COMM and Navigation.
• Avionics experience
• Experience with aircraft operations.
• Microsoft Office
I love the MS Office req at the end. "Yes, we see you've got a BS in engineering, you're an expert at avionics and COMM control systems, but do you know anything about MS Word?"
>twitch<
Maybe 1/5 is enough for someone to apply? Makes you wonder what superhuman will get the job.
"Johnson! We're promoting you to head technical flight operations. We can't believe the level of your MS Word skills!"
"Senator, we have no idea why the F-22 inexplicably crashed. That software was designed by the best people we could find!".
The guy that designed the flight control surfaces of the F-22 did so using an elaborate Excel spreadsheet powered by 4,000 lines of uncommented VBA filled with aerodynamics equations, and he retired 3 years ago.
https://www.vice.com/en_us/article/ywq5zy/the-pentagon-has-t...
I explained to the recruiter "while working on my Masters I did some General-Purpose GPU coding using CUDA, as well as software-defined radio systems using GNU Radio". I could tell she had no clue what any of that meant. She then asked me to revise and resubmit my resume because it didn't list 6 years of experience with MS Office. -_-
EDIT: My resume had my experience as a commissioned officer on it, and any DoD recruiter worth a damn should know that all officers are Black Belts in PowerPoint Slideology.
One time, I was given an Excel doc with a bunch of numbers and totals and averages in. I updated some values, only to find none of the calculations changed. The creator simply hadn't used any formulas, or had pasted it all in as plain text from some other place!
Got to give the hiring manager some credit. Listing DOORS as a proficiency requirement is a sure way to prolong vacancy.
• Matlab and MS Excel experience is a plus.
The req has been open since July of last year.
The wiki page shows some stats of a plane that is (publicly) 22-23 years old and VAX is 42 years old. To me, that math does not add up.
Just a curious thought.
Sure, it's a meaningless phrase and no one is going to say, "I'm not a self-starter, I hate figuring out what to do with my time I wish someone would just hand me a list of things". Or maybe very few people are going to do that.
What upsets me the most about phrases like 'self-starter' or 'motivated' or all that other HR shit, is that somewhere, someone (or more likely several someones) sat in a room and decided, consciously, that if they didn't say those words, that if they didn't flat out state that they wanted a self-starter, then the outcome would logically be they would only get lazy applicants.
Phrases like that are treating the world like it is full of people who would swallow their own socks, on accident, if only we were given the chance.
I'm guessing those people went into HR and are projecting.
Self-starters are boat-rockers and troublemakers, and generate dissatisfaction among the other, obedient, personnel, and management.
This is not to say that places advertising for self-starters actually want any, or would know what to do if they ever got one.
(I write Pascal for an obsolete VAX11/780 in around 1985... I wrote COBOL in a WANG VS in the mid 1990s. No _way_ am I ever gonna let recruiters or employers know any of that...)
Lots of places were using them into the 20th century, so folks with VMS experience don't even need to be especially old. I have a friend here in Houston who works at $BigNameOilCorp, and they had VMS in production until 2005 or 2006.
It's a weird feeling when you are in your early 30s and encounter a personally familiar piece of hardware in a history museum.