This is pretty hilarious. So some consultants swooped in, there was 8 weeks of training, and now everything is going to go back to how it was.
Source: seen more than one of these external “transformation” efforts.
“ Through an eight-week Red Hat Open Innovation Labs residency, Lockheed Martin Aeronautics replaced the waterfall development process it used for F-22 Raptor upgrades with an agile methodology and DevSecOps practices that are more adaptive to the needs of the U.S. Air Force.“
“Colonel, instead of requirements you’ll call them user stories.”
And don't worry there's even more mandatory meetings than before.
> So some consultants swooped in, there was 8 weeks of training, and now everything is going to go back to how it was.
I used to work for Lockheed Martin. I believe it.
I found it so hilarious I was relieved when I finally got caught up in the layoffs.
Next week: this weeks sprint is behind schedule by 8 weeks, we need to push all sprints out by 6 months. Also we found some security vulns that need hot patched, which could either take 6 weeks or 6 months. We should probably bring the consultants back for another 12 weeks to get the ball rolling. We might be able to save a few weeks if we outsource some of the work to our subs in india...
What year is this again?
"The Lockheed Martin F-22 Raptor is one of the world’s premier fighter jets, thanks to its unique combination of stealth, speed, agility, and situational awareness."
A huge understatement. It's the only true 5th gen that's tailored for performance, rather than cost savings (ala the F-35). The others are completely unproven (Chinese) or both unproven and in extremely limited quantities, while not providing true stealth (PAK FA, though if anything, the SU-35 family is the closer analogue).
I’m not a huge fan of obscene military spending, but the cancellation[0] of F-22 production must be one of the most boneheaded decisions I’ve seen in US military procurement. I must add the caveat that I have no security clearance so there may be other factors.
[0] https://en.wikipedia.org/wiki/Lockheed_Martin_F-22_Raptor
> Service officials had originally planned to buy a total of 750 ATFs. In 2009, the program was cut to 187 operational production aircraft...
I always wondered why they couldn’t have just used the F-22 for both the air superiority role it was originally designed for and the multi-purpose role the F-35 was made for. The F-22 is more capable in every way, and more survivable with dual engines. They would have needed to figure out vertical take-off/landing version of the F-22 but I’m sure that was not impossible.
It may have looked more expensive on paper with ideal assumptions to produce lots of expensive F-22s instead of a few F-22’s and lots of cheaper JSFs. But in practice I bet the costs would have equalized, due to the increased volume of F-22s and the development of extensive institutional knowledge of that airframe - from manufacturing to maintenance to piloting/operating.
The F22 was designed in the 80s. It's old. It's fast, certainly the best in some aerodynamic ways, but nothing like the capability the JSF brings in computing technology.
In addition, the threats anticipated that led to its development never materialized.
That's why it was cancelled.
>but nothing like the capability the JSF brings in computing technology.
What computing technology can't be put into the F-22? Iirc it has a much bigger radar housing, and EO DAS (fancy term for 360 IR / situational awareness) can be added to it.
To answer the parent term - the F-22 was used for air-to-ground in the middle east, so it can definitely fill that role. There was also an attack plane/bomber variant proposed.
With that said, I don't think "its old" holds.
JSF has sensors built into its skin. You don’t just retrofit sensors onto an LO platform.
Retrofitting new computing technology into an aircraft is a huge deal. Just getting a data link into it so it can talk to the rest of the DOD has taken over a decade and I’m not sure it’s even complete yet.
Yes, it’s old. That doesn’t mean it’s not useful, the F15 is far older and still in use and will be for decades, but it was more cost effective to put the money into the new platform instead.
I don't mean to get into the weeds here, but what part of EODAS can't be added by literally putting a thermal camera (from the F-35 program) in several places on the F-22 and running wiring to it?
I completely understand that it interfaces with the helmet. I also know that it took ages for the F-22 to get a simple FLIR built in, but if even a fraction of the F-35 resources were directed at the F-22, this would all be more than doable quickly.
As far as I am concerned, the selling pitch of the F-35 is the STOVL and EODAS. At that point the F-22 could be fitted for carrier operations, because no one uses VTOL (or plans to) on the F-35 anyway except for moving it around parking lots with no ordinance.
Again, this is ignoring all the political info.
Also, to get more specific, I don't know of any "sensors built into its skin" - EODAS is just a bunch of little pods with thermal cameras and fancy computing. Obviously don't tell me if it's something that's not public knowledge.
No.
The main function of the JSF is situational awareness. The F22 doesn't even have a functional data link yet. JSF has all of it built in from the beginning. Everything you add to an airframe costs millions of dollars, and there's no point in doing it.
STOVL is an important part of the JSF program. The F22 isn't capable of doing STOVL or carrier operations, you don't refit a non-CVN capable aircraft for carrier operations.
F-22 has datalinks, including the one datalink that appears to be ultimately the only one really used - Link-16.
F-35's MADL wasn't added to F-22 because Air Force deemed it "not ready to use" and cited maturity problems with the whole stack.
A lot of JSF sensors are to patch over its horrible pilot situational awareness, mostly a legacy of the STOVL variant (which is responsible for most issues) and which exists only because USMC needs it to fight against Imperial Japanese Army in Guadalcanal. Few other purchases of F-35B happened because building a proper carrier would result in political shitstorm (Japan) or because F-35B being supposed to let build carrier more cheaply and when its issues became known it was too late to refit the carrier with catapult (UK).
As for refitting a non-carrier aircraft to be a carrier aircaft - F-18 is the best known case, and its competitor was navalized F-16. As far as I know, there was carrier variant of F-22 in the works as well.
All incorrect.
The JSF was designed around sensor fusion to give the pilot situational awareness like no other aircraft.
Stovl has been used by the USMC in every conflict since they got the Harrier. They flew off of highways in OIF. Japan hasn’t purchased the B model yet, they likely will. But the B model has doubled our carrier force by giving the ARG strike capability.
You do not “refit” a non naval aircraft for carrier duty. The f18 was designed as a carrier aircraft from the ground up, and there was never a carrier variant of an F22 except in some people’s fantasies.
The F-18 is navalized YF-17 (specifically, it's based on YF-17 model 267). It's competitor was literally F-16 "navalised" by team up of General Dynamics and Vought Aerospace, with resulting model being Vought Model 1600.
You don't usually already produced units to "navalize", but making a derivative is the norm, and was the case for both.
F-22N was proposed but never went far.
As for JSF sensor fusion - the helmet itself comes form pretty bad visibility from the cockpit. Incorporating modern passive sensors was an obvious choice, though.
(I'm still waiting on reports of "sensor fusion finally works", given our local idiots in charge decided to jump on the Lockheed Welfare project)
And outside of F-35, everything talks Link-16 with possible tunnelling/subnetting, and MADL was considered "too immature" to start fitting on F-22 despite Congress "ordering" it.
The F18 has some roots in the YF-17 program, but it is not a YF-17. It was a new development effort that used some of the tech developed from the YF-17 program. And even at that, the modern F18 is a totally new aircraft that vaguely resembles the previous models and retains the name for funding and programmatic purposes.
The JSF's sensor fusion is not a result of "bad visibility". It's how the aircraft was designed.
F22 also does not talk Link 16, for obvious reasons.
STOVL can certainly be retrofitted the same way lots of things are: as an external pod.
Guide the pilot into a suitable position above the landing area. (with visual indicators, much like those for a bombing run) Once the plane is in the right spot, a computer finishes the job with full automation. The aircraft is stalled. The pods fire rockets. The aircraft is guided down and brought to a stop.
This retrofit would be particularly sensible for the F-15, which normally carries conformal fuel tanks. That would be a fine place to install the retrofit.
LOL.
Sounds like a great thing for a scifi novel, but not useful to do something like that in real life.
It's been done: https://en.wikipedia.org/wiki/JATO The primary requirement for a carrier jet is two engines, decent thrust, and enough body rigidity to take landings. The F-22 has all that. The MIG-29 had less, and had a carrier version. Same with the SU-27.
JATO is for takeoff, thrust in the aft direction is not the same as trying to rocket assist a landing. Completely different. It's also extremely hard on airframes.
The idea is not feasible.
Also your list of "carrier aircraft requirements" is incorrect, the JSF is a single engine aircraft, and landing gear is a major requirement of a carrier aircraft. The F22 is not a naval aircraft, was not designed to be, and never will be.
He is correct about carrier aircraft requirements. The navy was forced to accept the JSF.
As produced, the F-22 is obviously not a naval aircraft. The tail hook is single-use, the landing gear is not reinforced, and the more modern stuff for carrier approach is probably not installed. All of that would be easy to change, and in fact a carrier version was proposed.
The Navy spearheaded the JSF for both its CVN fleet and for the USMC. The JSF is not the first single engine Naval aircraft, and its engine is reliable enough that it's not an issue. People look at the tomcat and hornet and make up requirements that have never existed.
There is no such thing as "easy to change", you would have to redesign the aircraft from the ground up. You don't "navalize" an air force asset, you have the air force use Naval aircraft if you want dual use. The F22 is not and never will be a carrier aircraft.
This was said about recovering orbital rocket boosters, yet now SpaceX does it most of the time.
Doing that for fighter jets is actually much easier. The speeds are much slower and the distance is much lower.
Carrier decks are not drone ships. People work on them, they conduct hundreds of launch & trap cycles per day.
It's absurd, as anyone who spent 9+ years on CVNs would know...
Oh come on. You're just dismissing it, seemingly with the assumption that we'd have manned aircraft dropping into tight aircraft parking spaces with all the grace of the very first SpaceX landing attempt.
Obviously there is no reason to bother with vertical landings on a fully functional full-sized US aircraft carrier. This would be for other ships, clearings in jungles, and cleared-out parking lots.
You'd descend toward an area that has been cleared of debris and personal. It's not more absurd than flying toward a ship at 135 kts and expecting to grab a cable without crashing into things and people on deck. Compared to what we do on a CATOBAR ship, rocket-enabled descent is really tame and safe.
Vertical landing with the F-35 isn't exactly safe. This is the standard for comparison. Rockets can respond faster. This allows better stability and faster shut-down.
We have aircraft designed to do stovl and do it correctly.
Vertical landing with the F35 is exactly safe. It's the definition of safe, it's been done thousands of times with zero incidents. It was done hundreds of thousands of times in the Harrier before, and they applied the safety lessons learned from the Harrier to the JSF. How many rockets has spacex lost already?
rockets are for a completely different use case.
This is a ridiculous discussion. It's absurd.
Oh, the other argument for the JSF is that it could be exported to allies, whereas the F-22 is US-only.
Obama really really wanted to kill the F-22.
I note that the F-22 was primarily produced in Georgia. That usually isn't a swing state and it doesn't have a lot of representatives in the US House of Representatives.
The F-35 is produced in nearly every state, certainly including all the swing states. This is terribly inefficient, but probably kept the F-35 from being cancelled.
Keep in mind the military has a history of claiming they stopped production and then producing them in secret or producing a slightly modified version as a way of making our enemies think we have fewer weapons than we actually have.
Ooh, do you have any articles on this? Sounds interesting!
Stealth Blackhawks (pretty much confirmed by the Bin Laden raid) are definitely an example of the cancelled Comanche program tech going into black projects.
I assume they realized they don't need that many air superiority fighters and that they are costly to maintain. What would you even do with 750 planes that have very limited use in bombing Taliban fighters in caves?
"Cost savings" and "F-35" in the same sentence made my brain crash.
Nothing saves money like designing your airplane by saying yes to every persons idea in the conference room!
Insert Pentagon Wars Scene Here
Based on a true story too: https://www.amazon.com/Pentagon-Wars-Reformers-Challenge-Gua...
>cost savings (ala the F-35)
What.
It was supposed to be the next generation F-16. The lightweight single engine jack of all trades fighter that could be exported to other countries to help defray development costs.
There was even a notion that you could use the same plane across all branches of the military so the same supply chain could be used for all three and you could build them in higher quantities to spread the development costs over more aircraft. But then of course the aircraft got saddled with requirements from three different branches of the military at once which made it extremely difficult to design and build and thus very very expensive.
>But then of course the aircraft got saddled with requirements from three different branches of the military at once which made it extremely difficult to design and build and thus very very expensive.
Sounds rather like the Space Transportation System. During design, it went from a compact inexpensive passenger shuttle with modest payload capability, to a complete pig of a ship. And all because the Air Force contributed cash on the condition that it be capable of classified high-payload-pass missions to polar orbits.
It is nothing short of a tragedy that fully-reusable compact shuttles with flyback boosters (like the Rockwell P333) lost out to the disposable-booster design that was eventually built.
An extremely important part of project management is the ability to say "no", even if the customer is bringing extra money to the table. Extra requirements have a way of increasing costs in an exponential way and it's very easy to lose sight of your original goal.
Of course this is a problem when you have Congress breathing down your neck and looking for any excuse to cut your program. One big advantage of skunk works projects is that they keep you firewalled off from idea men.
Hue hue, but it WAS the theory. The F-35 was planned as:
A. The "light" F/A part of the heavy/light fighter model.
B. Meant to save costs by having one aircraft with shared parts (across the three models) fill virtually all roles.
Yup, that was the original goal of the F-35. The idea was that by sharing parts across multiple variants and across multiple militaries, the F-35 would be a cheaper fighter than the F-22 that could scale to a larger fleet.
It's not totally crazy on the face of it- The expensive but undefeated F-15 and the relatively cheaper F-16 successfully pulled it off in the 20th century.
I worked at Lockheed with Red Hat doing exactly what they are talking about here on the F-35. Unsurprisingly, It was a total disaster from the top down. I guarantee this will be as well. I was happy to get out after a year.
Please elaborate! You seem to have direct relevant knowledge but this tweet-length jab doesn't add much to the conversation. Even just a couple paragraphs would help us all understand.
"By knocking down walls and creating open spaces to work in its new dojo, [...] team now has a dedicated space for continued learning, thinking and problem-solving [...]"
I imagine a couple of couches and a book shelf in a corner.
Why not a crusty VBSS black belt duking it out with these agile newcomers.
Couches are so 90's ... creative thinking needs beanbags.
I'm a little bit surprised to see this.
One thing I've observed working on many different types of software projects is that there exists a continuum between waterfall and agile/scrum, and one way of thinking of it is what the length of the sprint is. Waterfall is a single sprint the length of the product, spiral development is several sprints over the length of the product, and agile/scrum is sprints of a couple of weeks to a month.
The length of the sprint is simply the length of the planning cycle. What I've observed is that systems with certain characteristics, such as safety critical systems or systems that involve hardware that doesn't yet exist or is expensive or time consuming to test typically don't work with an agile/scrum planning cycle. If you want to deliver them in a reasonable time, complex and parallel requirements mean that you must plan things far in advance so that everyone is ready at the same time.
Scrum has been a catastrophe to the software industry (argued elsewhere countless times) - I don't want to imagine the consequences it can have for jet figthers.
For such environments you definitely want to have no deadlines at all, to have a special focus on well-defined requirements, and in software quality.
That investment should be marginal compared to hardware costs.
And in fact, by going more slowly, you end up delivering faster after a couple years, when you enjoy zero tech debt and an excellent foundation.
> when you enjoy zero tech debt and an excellent foundation.
This implies that you plan exactly when and where tech debt is accumulating or found. The scrum argument is that by iterating and releasing, you find out where unexpected tech debt is more rapidly; and you go back and fix it.
One way that #AgileIsDead happens is when products disregard the tech debt for features even as it becomes apparent.
Interesting, I hadn't heard of tech debt being something so subjective/invisible that it just creeps in and you have to discover it.
(I'm open to be convinced)
Generally I have witnessed tech debt as something pretty blatant and obvious - generally it's detected in the code review process. Sometimes it's big faults being introduced, more often it's small faults leading to 'death by a thousand cuts'.
My current policy is to allow zero tech debt, following the "no broken windows" principle. https://pragprog.com/the-pragmatic-programmer/extracts/softw... That involves a greater investment in code reviews.
> My current policy is to allow zero tech debt
I was in an office that had such a policy - it didn't go well. Perhaps it's a matter of definition, because:
> I hadn't heard of tech debt being something so subjective/invisible that it just creeps in and you have to discover it.
Tech debt is _inevitable_. Any decision will eventually be debt - rot begins before the code is even finalized. Focusing on avoiding short term gains at long term cost is totally fine, and I think that's the point of your "zero tech debt" strategy, but that's not zero tech debt. And even when maximizing for the long-term, you're picking between options, which means you're picking the FORM of your tech debt, not the existence of it.
To return back to my (admittedly anecdotal) experience with "zero tech debt": What happened was a language shift. People would avoid the phrase "tech debt", but still dealt with the reality. The decisions were being made, uncovered debt (such as a paradigm shift in the industry, or a change in dependent technology, or just an anticipated business flow that turned out to play out differently) was hidden. Basically, it seemed fine for a while, but management was getting out of the loop because management had decided an unachievable purity was more important than frank and open communication. The result was what happens any time management pushes themselves out of the loop - at some point, the compound interest on the debt came due. By then, multiple devs had left because in an industry with so much choice, why choose to work somewhere that refuses to face reality?
Not selling the long term for the short term is a great approach, but if you're trying to enforce "zero tech debt", I suggest you talk with your devs to see what they think that means and make sure that you're all on the same page, because tech debt is maintenance costs, and those will never be zero. If you're being told they are zero, then there may well be a disconnect.
Great insight.
I think you are describing tech debt of the "unavoidable" kind. My efforts tend to be focused on the avoidable kind.
Definitionally, no methodology makes the unavoidable avoidable?
Now, let's say you get to that dreaded point - requirements have changed, dependencies have changed, the industry landscape has changed. Which codebase will be easier to adapt - the debty one or the zero-avoidable-debt one?
Software development is a never-ending procession of tradeoffs. In that context, tech debt and paying it is also a never ending procession. A code reviewer may say a 2 level deep if/else is more readable. But two layers abstraction while complex, may be more adaptable later on. Then again, one may never need it at all. So unless one has a crystal ball, tech debt is mostly visible after the fact. There are some areas that may qualify as "universally accepted", but in my experience that is a much smaller piece.
> Which codebase will be easier to adapt - the debty one or the zero-avoidable-debt one?
I feel this is a bit of strawman, though that may not be your intent.
As I mentioned in the above comment, wanting to avoid hurting your long term for the short term is fine and admirable. However, I think the distinction between "unavoidable" and "avoidable" debt is somewhat facile and unrealistic. It's a continuum, with points scattered throughout the center. Is this decision the best one? That is debatable, and should be debated, but the result won't be "yes debt" or "no debt".
I also said that if someone is shooting for "Zero debt" they should talk with their devs and make sure everyone is using words to mean the same thing. I continue to stand by that, because however clean and rational your personal definition may be, it's worthless if that's not the meaning anyone else is using.
Point taken.
At the same time, I'd note that anything can be debated ad nauseam, so nearly everything can be considered subjective.
So indeed I can't aim to 0.00000 tech debt, nor identify "avoidable" tech debt with 100% accuracy.
But I _can_ follow certain practices and have a given team follow them. Those practices being quite objective, benefitial, and superior to the status quo of the industry.
> because management had decided an unachievable purity was more important than frank and open communication
Can you expand on what you mean by this?
> Can you expand on what you mean by this?
"zero tech debt", when understanding that tech debt is maintenance efforts at a minimum, is unavoidable. If a workplace has a "zero tech debt" rule, that workplace (the management, assuming they're the ones putting the rules in place) is placing that unachievable purity above the frank and open communication about their very real tech debt.
Where I was at, when "zero tech debt" was the policy, we stopped talking about potential tech debt to management. Decisions were made to avoid short-term debt (good), but no discussion was had about any longer term issues (bad), because we couldn't HAVE those decisions when every choice involves some tech debt.
When tech debt issues arose, we didn't want to surface them, because we'd spend more time trying to justify why this wasn't our fault, wasn't predictable, or taking lumps when it was our decision instead of actually addressing the issue.
Management had placed the ideal above the reality, so they saw the ideal. That didn't prevent the reality, and it left the reality unmanaged. We did what we could - we all took pride in our work and tried to make the best decisions - but the company limited what could be done.
One of the reasons why I sometimes don't like the term "tech debt" is because you can take it on without knowing it. This is not true for financial debt. When you borrow money, even if you're not tracking it, the lender is 100% tracking the debt.
If you are in a team that discourages upgrading build systems, code reviews, code quality, testing etc there isn't really anyone that can point to instances where tech debt was accrued or how much there is.
> This is not true for financial debt.
It is however true with assets; The housing crisis provides a great example; housing is an asset when it is always appreciating; however, if it starts depreciating (2008), it quickly became a liability.
This translates nicely to product. Each feature is an asset for selling; until it is found to have liabilities (pii data storage, inability to scale), then the feature either needs work again (requiring reinvestment) or removed (sold).
That's a good comparison I haven't thought of before!
Iteration speed and quality are directly related, not inversely. Iterative development allows exploring software design considerations fast which means you get to actually good software instead of getting it right the first time.
Fast iteration means you can kill ugly design. Slow iteration means you get stuck with a design choice because you discovered its flaws too late.
That seems entirely subjective. People may go fast for meeting a deadline, or for iterating as you suggest.
Trying to determine what people do is likely a futile discussion.
Finally, by writing decoupled, modular software, you are always free to reassemble it later (discarding/rewriting undesired parts), no matter when it was originally assembled.
This is something that has actually been researched, so it's not accurate to say it's subjective. Higher release rates (i.e. an iterative approach) cause higher organisational performance. See Accelerate, by Forsgren et al.
You can't have no deadlines at all. The world is moving forward. Military rivals are building their own planes.
Would you rather have a bug-free fighter delivered in 2021 or a buggy fighter in 2020?
Especially considering that many codebases are expected to have a shelf life of 5-10 years.
IME working deadline-lessly doesn't mean you're suddenly knee-deep in a metaprogramming rabbithole. You just do the same stuff, stress-free.
That suggests a 2021 deadline, but many military projects have been 15+ years late. A 15 year old fighter is already in need of updates.
There's a healthy enough difference between an estimate and a deadline, I think. Obviously you want to report progress, but you can do that and work productively more effectively without a deadline, because now you're no longer feeling pressured to lie to yourself and others about what you are capable of.
No need to imagine, it's been done. Successfully. https://saabaircraftindustry.com/en/roads-to-new-capability/...
Heeey, but how would you get a selfie sub-module into F22 and real-time social media sharing from missile in-flight without Agile? Please don't be so backward, thx.
Virtually all "management methodologies" are snake oil, Scrum(tm) and Agile(tm) included. They're just ways for high priced consultants to milk deep pocketed companies and governments run by apparatchiks. Occasionally they're also used to milk over-funded startups run by people who want to be up with the latest buzzwords.
So a government contractor subcontracts another government contractor's new acquisition to do some unnecessary, yet likely expensive, consulting work that has no net benefit to the project.
Nothing to see here folks, just the mold poking through the cracks of our public sector.
I bet somewhere on Redhat's sales pitch deck there was a mention of "1 - click deploy updates" slide, somewhere, for sure.
Am I reading this correctly as Kuberetes-powered fighter jets? That's certainly not going to shoot anyone in the foot...
I was thinking more along the lines of removing features to simplify maintenance, Gnome 3 style.
"Good news, General. We've found a way to lower maintenance costs in the cockpit systems by 10% if we removed this thing here on the blueprints, so we've already gone ahead with that change."
"But that's the emergency ejection system!"
"Yes, and our data indicates that it's almost never used. It doesn't really make sense to devote manpower to keeping a system running that few people ever need. If we get rid of it, we can free up developer-hours to making the canopy opening/closing action a little smoother. Everyone uses the canopy."
“There is no need to have a system that is not needed at all if our plane is done perfectly in the first place”
Red Hat's new D-BUS service Fighter-Kit and systemd-missiled will address these shortcomings.
I agree that Kubernetes-powered fighter jets is a bad idea, bordering on catastrophically bad. That said, I assume they'll be using Kubernetes as a development and test platform -on the ground- to produce some form of binary output that would go on the plane.
If it's any k8s distro let it be openshift. Best selinux integration.
That said, how can you not wince reading, "To do this, Lockheed wanted to adopt principles and frameworks common in software lexicon like agile, scrum, minimum viable product (MVP) and DevSecOps."
Flying on MVP software must surely be exhilerating.
If you read MVP with a German pronunciation of V then you get Minimum Flyable Product.
"You guys have got a lot of nice words! Any way we can get some of those words over here?"
Avionics software on new systems is, in a way, logically similar to kubernetes actually :)
Instead of having separate computers, you now tend to have fewer "servers" which run multiple modules in isolated partitions, communicating over the common network using unidirectional messages; whether using SAE AS5643 - aka IEEE-1394 - like in F-35 and X-47, or over mutated Ethernet known as AFDX (A380, A350, B787).
However a big portion of JSF issues is also in ground software - there's a dedicated set of platforms required to operate F-35, which is also known for infamously depending on connectivity to Lockheed servers or the airplane stops working.
The system involved, ALIS, had als infamously took more time to deploy during a test squadron redeployment than the whole redeployment - which I guess they might be trying to speed up using Kubernetes.
From what I heard ALIS appears to still be done the same style as certain other logistics software from lockheed back in 2010, and that doesn't say anything good.
> ...today announced that Lockheed Martin worked with Red Hat to modernize the application development process used to bring new capabilities to the U.S. Air Force’s fleet of F-22 Raptor fighter jets.
They later talk about agile vs waterfall as well as devops. It doesn't read like this is going on a plane, probably just dev and test environments.
Omigosh! The F-22 was the example of avionics software that worked, standing in contrast to the F-35 (sometimes) flying tarpit of tens of millions of lines of C and C++. Does this mean the DoD is now acquiring assured and acceptable agile-accelerated advanced armed airborne Ada avionics assets?
Now that IBM owns Red Hat, we should get used to these hilarious/tragic "success stories".
During an "enablement session" really? This is a sales jargon AFAIK, the developer-unfriendly term for "hands-on training". Such jargon shouldn't be used in agile.
I work in embedded sw in the automotive world and I absolutely did not understand how container accelerates their development.
Could someone here with experience in this things enlighten me ? F22 raptor is still an embedded system, I cannot believe that it runs a linux with container. What I am missing to comprehend this article.
Might it be a particularly bonkers toolchain for an obscure piece of critical hardware which needs containerising so whatever nightmare of an install process only needs to be done once?
what the hell is DevSecOps?
I've been doing network security for twenty years, so I know what that is, this just sounds like some marketing and sales people started mashing buzzwords together.
DevOps is mashing development and operations together. But that ignores security, often putting security reviews after the code has been deployed or at least after it's done being written, which necessitates re-work. DevSecOps makes sure security is a part of the development and operations work.
Yes it's a re-wording of an existing concept. No, it is not a new idea. Yes, it is important enough to call it out because so many companies don't let security/operations/development work together.
You're not the target audience, your CISO or CTO is.
What is the size of the company when CISO, on average - exists as part of the company?
I know Google has security teams, but what about the smallest company that has one?
Whether a company has someone with the title "CISO" or not matters very little to how they design security into their products. The term "DevSecOps" is designed to eliminate the need for a discreet "security" workforce.
To answer the question more directly: I've worked with 10,000+ employee companies with no CISO and I've worked with <1,000 employee companies with separate CTO, CIO, and CISO roles. At the executive level, job titles are more of suggestions than strictly defined silos. It all depends on how the company is organized and what their strategic priorities are.
Common term in defense, basically just an organizational efficiency. Since the devops people kept breaking security, we made them sit next to the security people.
That IBM acquisition is starting to pay off.
Not proud that open source I contribute to help USA kills people, it really sucks.
I'm sure there are many, many others being used, that you aren't aware of. Do you really think the US Military are the only ones to use redhat, or mysql, or any other major opensource project in their weapons of war and surveillance programs? You're contributing to a lot more than you think you are, and supplying every side with the tech. It's free for anybody to use, even terrorists and nation states.
In general the world is infinitely interconnected and any tool can be used for good or evil. Don't sell powerful technologies to oppressive governments, but it's also pointless to lose sleep over nth-order relations to bad people doing bad things.
I don't think you can realistically expect anybody in the world, of any political ideology, to not use something that is GPL/BSD/LGPL/Apache/whatever licensed, if you've published the source code to the Internet.
I would be entirely unsurprised to find north korean telecoms/state government agencies using centos or debian. In fact if you google "north korea linux" you'll find that they already created their own weird custom GUI desktop distribution.
In the bigger picture, far more people use your code, whatever it is, to do useful and good things in random places in the world than people using it for purposes you find objectionable.
Thanks for lecturing me about licensing, as a contributor I already know that.
Isn’t it allowed to go further that sources access, what’s written on a piece of paper, and caring about ethics?
Does OSS contributors really needs to be so alienated?
I honestly don't know what you expect, if you want to find some way to force autocratic regimes somewhere in the world to not use source code that's published to the open internet. If you discover some way to bend north korea to your will, please let us know.
JSLint made up its own license, which was essentially the MIT license with a sentence about "use this software for good; do not use this software for evil". FWIW that was enough for lots of people to make the determination that it wasn't really open source software since evil is often in the eye of the beholder and there was a gray area for "lawful neutral" type use.