Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

I worked on the control systems for Predators and Reapers back in the mid and late 00s, and the inefficiencies around process were enormous. Safety is extremely important, so you expect some slowness as a result, but it got pretty extreme. I remember one time having to do 6 weeks of testing around a one-line code change because a "helpful" dev fixed a small bug that had no practical impact. Yet because it changed the release build hash, we had to go through a full acceptance test. As you can imagine that incentivized only fixing important bugs, and even those we had to consider whether it was worth it or not. As a result there were a hole pile of bugs that we (and customers) ended up just living with.

On a separate note, I'm curious as to whether AI is making an inroads in that space. I would imagine very minimal, if at all, but very curious.



In Ukraine, the first place that was bombed was the red tape factory.

The drone industry was allowed to basically "do whatever as long as it works", consequences be damned. So they use civilian motors, batteries and SoCs, sketchy firmware with zero code inspection, and more. Does it work perfectly? No. It works well enough.

I wonder if anyone is going to learn a lesson about overregulation.

I'm not sure if "AI for red tape mitigation" is a thing, but "AI for killer drones" sure is. I suspect that "killer drones are insufficiently smart" is easier to fix with AI than "too much red tape". Because the amount of red tape, if unopposed, will expand to consume any capacity of dealing with it, AI or not.


> I wonder if anyone is going to learn a lesson about overregulation.

Seems unlikely. Regulation and Health & Safety are both societal luxuries, which only happen once societies are stable and prosperous enough to start valuing human life beyond its ability to perform labour.

The moment the bombs start dropping, the time for luxuries also stops, and the value of human life drops to value a person can produce defending their society. There isn’t the money or resources for anything more than that.

The US (most developed democracies) places an extremely high value on the lives of soldiers, because dead soldiers in foreign wars does terrible things to politicians in power. Paying 1000X more for the same tech as Ukraine to minimise the number of service members killed using it, is a pretty small price to pay.


No. Certainly not. The fundamentals of modern flight safety rules, Procedures and organizations were created in the Second World War when losses of aircraft and crew due to weather, environment, maintenance, poor training and so on greatly exceeded the losses inflicted by enemy action.

Rules and regulations on safety and health will maintain combat effectiveness and manpower where the loss -even temporary due to injuries or sickness- of well trained specialists (and don't forget that even a "simple" infantryman is a highly specialized expert in his field!) is not acceptable. Those rules were written in blood and modern western militaries can not sustain the rate of loss that Russia seems to be ok with. Western leader will be well advised to try to minimize losses to real combat casualties.

But I sure think that they will start to cut corners, at least where it comes down to documentation and purely cya.


I think I covered all that with

> the value of human life drops to value a person can produce defending their society.

OP was talking about how US munitions software needs to go through a 6 week long integration test before it can be deployed. I seriously doubt that kind of testing would last very long if the US was engaged in peer level war, and their enemy had found a flew in their munitions guidance systems that made the munitions useless.

At the end of the day, when at war time isn’t just money, it’s also lives. When you have people dying on the frontlines, the risk of equipment failures from lack of testing will be substantially smaller that loss of lives from ineffective equipment, that can only be improved every other month.


And yet the regulation actually will result in more dead soldiers or else it wouldn't be the first thing that goes out the window in a war.


The regulation crucially results in your recruits not dying for no good reason during training just because some random piece of trash equipment predictably failed.

Preventing that is much more important than the exact dollar efficiency of said equipment during peacetime.


Perhaps, but, for better or worse, it's about optics. It looks better to say a soldier died bravely in war than it does to say they died because of a friendly-fire incident with a drone with shoddy control software.


> I wonder if anyone is going to learn a lesson about overregulation.

Regulation - or more generally - formalization comes with scaling up. A skunkworks project can innovate really fast, and has no integration and scale needs. When you want to scale up any project (hardware or software), integrating and scaling become a real bitch, and you need to ensure that everyone is on the same page or face costly "silly" mistakes that history is replit with.

You can't magick away coordination challenges by labeling the process "red tape." This happens every single time any small nimble organization grows beyond certain thresholds. On a personal level, organizing a trip for 3 friend is process-free, but for 10+ people requires checklists and heavier processes, for 30 people it becomes a nightmare requiring professional assistance. Low probability events become regular occurrences when you scale, and you have to plan and/or mitigate them adding "red tape".


Yes and no. Acceptable failure level is important.

It matters if you care about 1, 2, or 10 out of the 30 people on the trip missing a flight, getting lost, or going hungry.

Of course there's a bare minimum for a product that works at all. Beyond that there are increasing levels of rigor that focus on reliability, and these can be non-linear.


I'm not an expert but I think this is an old lesson in warfare, that guerillas can triumph over larger adversaries by being more exploratory/iterative and less rules-bound. Tolstoy tells this story in the second half of War and Peace. Likewise with Iraqi militants wreaking havoc with IEDs. People repelling an invader have every incentive to move fast.


I've just read that section of War and Peace and was blown away by the descriptions of guerrilla tactics as well as Tolstoy's way of capturing the state of mind of the Russian POWs and their ever-shifting relationships with their captors.

As an aside, the word Guerrilla (little war) was coined during Napoleon's occupation of Spain to describe the resistance effort by locals and peasants against the French army.


That applies everywhere. You’re commenting on a forum for startups that compete against established players. David will always, in the long run, win against Goliath.


> David will always, in the long run, win against Goliath.

Every Goliath may, in the long run, meet a David that beats it, but this premise ignores all the thousands of Davids that don't win.


Historybooks are 90% filled with tales of exterminations, slaughter of citystates and permanent area destruction.

If you glass the villages and salt the fields, you even win against the taliban and vietkong.


> If you glass the villages and salt the fields, you even win against the taliban and vietkong.

You may win tactically, but you lose strategically - firstly by demonstrating that surrender is pointless, and secondly by creating a martyr movement across the world.

When you sow fields with salt, the only harvest you should reasonably expect is more blood.


Which binds the empire crime family together. This was how it was done allover until 1945. Its how its still done in russia, near china, how the middle east does things. That we "shall overcome" only applied to the west as a selfset achievement. And history tells us that the dead are forgotten. Nobody is out there avenging jews or armenians. Thus also the pro active paradigm of "better fuck around as a empire" then being "found out to be peace loving". Congrats to the anti western westerners, you won so much, you got the old world back.


"Some" David will always in the long run, win against Goliath. But many, many millions will be buried.


Thinking of past notable Goliaths: Ma Bell has been reconstituting herself from the split apart companies, IBM and GE are… alive, and Edison Illuminating Company and Carnegie Steel are alive in successor companies.


I'm hesitant to use 'always' language but the innovator's dilemma is indeed another application of the same principle. It's remarkable when a company like Google can pivot in a way that threatens its existing core revenue streams.


>The drone industry was allowed to basically "do whatever as long as it works", consequences be damned

Yes because Ukraine fights an existential war and at this point on both sides people just shrug when a few civilians get blown up.

The US isn't under existential threat and when they go to war their highest priority is to never risk the lives of operators and if possible, if only for PR reasons (and even then it doesn't always work) not generate news about rogue missiles or rogue killer drones. The attack on a school in Iran that killed 150 children apparently was already the result of a rushed mission that ignored procedures because this kind of thinking is starting to take hold in US defense circles.

That's not just an ethical disaster but also a political and strategic one because these events can rally enemies around a regime and the political arena is where for the US wars are won and lost, both at home and abroad.


You are making a good point but blaming the wrong thing.

Caution needn’t spiral cost. The reason US weapons cost so Much is because it’s profitable.

Building things that work 80% of the time makes sense in wartime. It doesn’t as a rule. Hence wartime production will always be cheaper.

Americas problem is that the military industrial complex is built to maximize cost and profit for private corporations, despite them being entirely dependent on government.

Until they are nationalized, and the profit margins are eliminated, you will always pay 20-50% more than you should and gains from efficient won’t be realized.

Look at the auto industry in the US. It’s protected by tariffs and still incapable of matching the Chinese and others on cost. It mainly survives because of incentives which subsidize vehicle types other countries don’t want (pickups) and Americans only buy because of incentives.

Iran is building drones for £3k. The US clones cost 30x that for “additional features” the spec didn’t ask for.


I don’t know the details of that situation, but I have been on the other side of that debate.

People say “it’s a one line change” (once they argued it was a 1 bit change!). But lacking a fully controlled and hermetic build system with its own exhaustive test suite you can’t be sure about the relationship between the source and the binary. And that continues to every step to get the binary into production (updating existing devices, etc).


Welcome to Tradeoff Town.

Sure, your ultra paranoid checking of everything might catch an extremely rare bug caused by something like interactions between a benign code change and a build system. But is it worth slowing down the development process by that much?

Is it worth missing out on an entire generation of technology, like what happened with US and the shift from 00s drone warfare and 20s drone warfare?

Usually not.


In this case, it's probably more about preventing a foreign-compromised build system / developer from getting malicious code into lethal devices.


It depends. For a JS web front end? Go crazy.

For the consensus algorithm in your distributed database? slow down there buddy...

You have to ask: how bad could this get? How hard will it be to fix? Could we loose or corrupt user data?


"It works well enough" is a significant understatement. I think it would be more accurate (especially given the perceptions at the outset of the war) to say that it has worked significantly better than anyone expected. Ukrainian ingenuity is single handedly driving conversations about the "future of warfare" in capitals from Brussels to DC to Beijing.

> I wonder if anyone is going to learn a lesson about overregulation.

This also misses the point imo. A simpler answer is "necessity is the mother of invention". There is value in a regime for peacetime. One is also a fool if they do not recognize needs change drastically in wartime. Two things can be true. The United States, like nearly all sensible nations, has almost always understood this and acted accordingly. On the other hand, nations that govern themselves as if they were on a perpetual war path are usually far less desirable societies. The idea that we need to speed rush "AI for killer drones" because otherwise we will find ourselves on the wrong end of an existential invasion are nonsensical. Americans would be far better off if our leaders and our people stopped acting like every potential conflict was existential.

There is no Russia on our borders. The only thing American adventures overseas have accomplished in the last two decades is making our country weaker.


Correct, but it goes deeper than just the building components. In the US you have to go through an entire military procurement process within each iteration loop. So you design a weapon, then try to sell it to the military, but just the process of demonstrating it and selling it to the military takes a long time and costs money. If you fail you can go back to the drawing board, but each iteration loop is probably a year minimum. And if you are successful now you have to set up and scale production. Get ready for years of environmental reviews and lawsuits.

In Ukraine the military will take any drone they can get their hands on, so all you have to do is build a drone, give a bunch of them to the army to try out on the Russians, and within a week they will tell you if it works or not. So your design iteration loop is probably weeks. If you are successful, the time between hearing the general say "give me 1 million" and when the bulldozers start clearing the factory site is probably measured in days.


Emergency is the mother of making exceptions. During both US gulf wars, the army broke from its long tradition of over-regulating new systems before they could be fielded, especially for small semi-autonomous platforms like flying drones and robots. Entirely new systems as well as major updates to fielded system were routinely prototyped in-country / on-the-battlefield in Iraq and Afghanistan. The demand for new capabilities and fixes was simply too great not to ship ASAP.


It's interesting that the red tape is still there on the Russian side. A Ukrainian drone maker can make a new one and put it on their brave1 website straight away, Russian ones have to go through a lengthy bureaucratic procurement process. I think Russian interceptor drones still can't use explosive warheads because regulation, health and safety etc. It's quite a plus for the Ukrainians.


And the consequence of this is a total lack of the consequences when something goes wrong. Complete with a PR cover-up all over the world.


cf the other thread: https://hackertimes.com/item?id=48845442 ; Ukraine has a hugely inventive and effective drone industry because it has to work. If it doesn't succeed, there is no Ukraine, and everyone involved in making the drones is dead, fled, in a POW camp, or sucked into the internal Russian displacement system away from their family.

By comparison, if the US products fail, there's no real negative effect on the mainland United States.


> if the US products fail, there's no real negative effect on the mainland United States

It's even worse than that. Schedules slipping and cost overruns are good things for the manufacturer, because they can charge more on top of their initial contract. Cost-plus ftw.


Cost plus isn’t nearly as common as it used to be.

But you still run into similar issues regardless of the contract structure. Try and build a rail network without anyone in government wanting something changed from the initial design for 20 years.


Yep, because of the incentives. Few people in the government making those choices are depending on the thing actually getting built.

Most are paid to prevent projects with a given defect type from proceeding. They aren't rewarded for the number of projects that succeed without defects. Preventing CYA from running wild is a legitimately hard problem to solve.


> Ukraine has a hugely inventive and effective drone industry because it has to work.

Well yes, that and the fact that cheap drone guerilla tactics have fairly recently become a technological possibility. Remember that Ukraine is actually a bit late to the party here, with Hezbollah and ISIS having used cheap drones with cameras and/or explosives tied to them years before Ukraine or Russia did. The asymmetry in cost between those cheap drones and the existing "more hightech = more better" militaries were (and are!) used to was already established. That a party such as Ukraine faced with a more advanced and much larger opponent would lean towards such an approach makes a lot of sense. Ukraine did not (and does not really) have significant amounts of the traditional stuff.

Now given that they chose that path, they have been very effective recently, but note that the tethered fiber-optic drones were a Russian invention. So even that deeply corrupt, large dinosaur of an institution innovated significantly. It is also important to note that a significant part of the recent successes of Ukraine are due to them having Starlink access and Russia no longer having it.

I'm not saying the sheer will to survive or the inventive organisation of the Ukranians did nothing (far from it), but I do think it is a mistake to think that their success should only be viewed through that lens.


To add that Ukraine was also USSR's drone research center; not to detract from what you are saying.


They can pop out defects and if things go wrong and there's friendly fire or civilian loss, it's chalked up to scrappy efforts in war. The USA does not get the same amount of leeway, saving our people is a top priority and the media harps on any mistake.


It's an existential threat for Ukraine. The US has not faced a similar (external) existential threat in a very long time.

Ukraine fights back or they lose their sovereignty. Most of the conflicts the US gets into, it's entirely a choice to put soldiers at risk.

So yeah, the evaluation of war effort will be different, because the situations are completely different.


And it makes sense. If the choice is between getting killed by the enemy and loosing the war or risking that one in 10 000 launches results in friendly fire it might be worth it but it would not be for a country not fighting a war for survival.


Yeah, their tech development in drones is really impressive. An invading army has a way of focusing the mind and bureaucracy.


To be fair, I know plenty of people there. Drones are important, but they aren't the only reason the front is holding. Both sides rely heavily on drones.


Well there's long term impact but yea that doesn't create enough political pressure to make process efficient


Not sure if you're alluding to this but it's analogous to the same differences between startups and big tech companies.

Startups = have few resources, product has to work or company dies

Big tech = minimal cost of failure, instead minimizing risk

And yet this mechanic is also why startups are able to innovate and bring new products to market so much faster.


> As you can imagine that incentivized only fixing important bugs, and even those we had to consider whether it was worth it or not.

Or you're batching your releases into larger builds because you know it'll take 6 weeks to test regardless. This increases the duration of each development iteration because you have 100 things you want to do and you could do that in, say, 4x13 week efforts, but with the added 6 weeks between iterations (and possibly more after it leaves your shop) that takes a one year effort and turns it into about 1.5. So the program office decides you should do one big release each year, which also ups the risk because a lot of testing that would catch bugs isn't done until the end in that big 6-week test effort. Oops, now your 1 year + 6 week effort just got turned into 1 year + 6 week + (unknown rework time) + 6 weeks. Probably 2 years.


My last job was like this, a full round of QAs manually testing, along with writing up a grandiose release document, stakeholder approvals, and whatnot, for something that should just take two days of development work, and an insistence on putting configuration values into the database, supposedly because it's "safer" than deploying a new configuration file.


If you are in an environment where deploying a new configuration file is easier than adding data in a pre-existing database, you are in a bad place already.


This is one of the reasons weapons and technology development overall explodes during wartime. Desperation is the cure for risk aversion.

It's also a reason to be skeptical of a military spending a bunch of money developing technology during peacetime. In reality the expensive stuff they went into the war with is always going to be less effective than the cheap stuff they came out with.


Maybe if you're in a war that actually threatens your country. In the US, the Republican Party wages wars (such as the Iran War) pretty exclusively to facilitate borrowing public money and dumping it into the pockets of the rich. What looks like waste to the taxpayer is a feature to Republicans and their paymasters (including Israel, in the case of the Iran War).


Life critical software that gets visibility by congress tends to be a very bureaucratic process. Your boss doesn't want your commit being the one that causes a worldwide diplomatic issue.

I assume that smaller/cheaper drones avoid a lot of this because the stakes aren't near as high and quite a bit of the development occurs in private industry first.


> visibility by congress tends to be a very bureaucratic process

See also SpaceX vs. NASA. No way would NASA have been allowed to blow up as many rockets as SpaceX did to finally get to their working solution.


Yeah, the anti-regulation people when NASA experiments: "look at all these failures! Cut NASA funding and give public funds to the guy who purchases elections!"

The same people when SpaceX blows up a bunch of rockets: "wow, look at the innovation, they move so fast! Cut NASA funding and give public funds to the guy who purchases elections!"


NASA's failures as of late are less "dramatic explosions" and more "delays", "cost overruns" and "lack of ambition so severe it borders on criminal".

The last time NASA caught any serious flak was what, the Starliner shitshow? And that was just splash damage from Boeing getting dunked on by everyone at once.


> lack of ambition so severe it borders on criminal

I'm not sure what timeline you're thinking about, but JWST was launched pretty recently and it's pretty ambitious. But more to the point of my earlier post, NASA's "lack of ambition" is probably directly attributable to the "small government" people who penalize ambition in the public sector and praise it in the private, government contractor sector. The incentives to be ambitious in government are perverse when every "failure" is scrutinized and condemned by people who want government to fail so that they can justify taking public money and dumping it into private bank accounts.


A big part of the reason for useless Gateway was that NASA wanted post-ISS missions, but was too afraid to roll with a permanent Moon base instead. The other big part was that Orion sucked, and somehow, neither "get Orion to suck less" nor "roll with Orion, provision for HLS to do more" was in the cards. This only changed under Isaacman.

For every Curiosity and JWST, there's ARM and Artemis. It seems like it's getting better now, but very slowly.


This is kind of an odd reply as what is going on now is exactly what one would expect from a culture that cannot take risks at all.

1. Something blows up.

2. It gets pasted all over the news.

3. People wonder why we give NASA money to blow stuff up

4. Congress people with room temperature IQs grill NASA admin for months.

5. NASA becomes risk adverse.

6. Today.


NASA had real safety issues in the past - Space Shuttle is a testament to that. But if this is the fix, they clearly overcorrected.

There's some sort of happy middle ground between flying a ship that has a very significant chance of a catastrophic failure killing all crew and can't even fly unmanned, and almost not letting Ingenuity fly because the chance of failure was deemed too great. NASA didn't find it.


I would guess that DoD procurement rules have more to do with it than Congress, but perhaps Congress defined DoD procurement rules.

Milspec is expensive and process heavy, see what a B52 replacement trash can costs, for just one example.


DoD procurement rules are largely the outcome of Congress trying to prevent executive-industry corruption through mandated process.


But aren't the politicians also corrupt? (or at least most of them) One therefore assumes that any action by congress must be corrupt. This appears borne out by the evidence over the past few decades.


If you think Milspec is expensive, you should see the cost of not having a Milspec supply chain while still being risk-averse.


That’s a damn good point, probably more costly and more of a hassle to adopt off-the-shelf products to work reliably in a military environment while minimizing risk.


We could always be less risk averse. We still seem to kill civilians at high rates and our own soldiers signed up to die. Gold-plated weapons aren't much good against peer powers anyway; it's production volume that wins those wars.


Why would those fixes not be batched up? So fix 20% of those and do one round of testing?


The obvious answer is that the more bugs you batch up, the higher the chances the next build fails - this is why CI became a thing, small iterative changes are safer and lead to greater throughput


CI doesn't mean doing all the tests all the time though. The expensive tests still wait until there's a major reason to run them. I had the same question as the parent and I still don't quite see why this can't work.


I didn't work on this project, but I've been involved with similar ones.

There is a process for getting a change into version control. Each change needs to have a (virtual) paper trail: motivation, risk analysis, sign-offs &c.

If you can't get something into VC quickly, you can't really do CI.

The obvious solution would be to have an integration branch that doesn't need the process to get in, do CI testing on that branch and then make the process for merging to the real branch.

I've never seen this done personally, but I have been told some places do it, and then you end up with "Change X, which got approved had a dependency on Change Y that didn't get approved and we didn't realize it until now because Change Y was put in the integration branch before Change X"


That sounds odd. The way it was done in every place I worked, is that a set of changes were approved for a release before they were planned and implemented. We organized the work as expected: each bug/feature on its own branch, with its own set of unit tests, etc., and automated testing applied on each commit. These branches are then merged to the integration branch once they are known good. Before the release process starts, QA would get a copy of the integration branch and test that.

The dependency problem doesn't exist, because all the features were already approved to be in the release. The only way there would be a problem is if someone decided late in the game to pull a feature and that feature was a dependency to something else.


What I described was for bugfixes, not features. Features were set in stone way before this.

I also maintain that it is impossible to know which changes depend on other changes. In one case, applying a bugfix that changed the order of allocations at startup caused vtable corruption somewhere else because it changed how much padding a particular malloc() call was returning, and someone was writing past the end of their allocation.

[edit]

Also note that what you described is not CI; things are developed on their own branches and not integrated immediately.


It's may seem like a nitpick but I think it's a whole different way off looking at it to phrase it as "applying a bugfix that changed the order of allocations at startup exposed memory corruption somewhere else"

I do think there is something to be said for both perspectives, especially for code that is extremely critical. With sufficient testing and determinism maybe you can actually make sure that dormant issues stay dormant meaning there is real value in being change-averse. Still it's a very precarious situation having a known memory corruption hoping it's the testing has made sure its benign in practice.


IMO All it exposed was writing past the end of buffers.

There was no memory corruption previously due to partially to luck, and partially to heavy testing (which would have exposed most forms of memory corruption).

I think it is fare to say that the change was a cause of the vtable corruption occurring, since without the change it didn't happen.

Once this is discovered, you need to rethink your change plan for the next release; if you back out this one change, your software will return to a working state. Whether doing that, or fixing your buffer overflow is the correct thing to do depends on a lot of specific factors.


Well, approval is a different beast from passing tests. But also, that's not how I was imagining this. I was imagining maintaining separate branches on top of each release, only combining them (merge or rebase or whatever) when you have a good reason to. That keeps things independent and makes it so you can always cut a release with solely the critical fixes (and test them in isolation, etc.) whenever needed, letting you integrate the noncritical ones opportunistically.


True, but if each run of CI takes 6 weeks then you're going to vastly hamper development.


The bureaucratic development process sounds like Autosar in automotive. I am not surprised that newcomers from USA and Chinese auto companies are able to completely dominate in software because Autosar based development has been like giving a birth to a hedgehog. Slow and painful.


> one time having to do 6 weeks of testing around a one-line code change because a "helpful" dev fixed a small bug that had no practical impact

Roll back the change? Also, fix the approval process - no way that should have been approved.

Generally speaking that is risk management, an unavoidable engineering tradeoff. In lower stakes situations, for example a critical application or server for a small office, we let low-impact bugs accumulate: Imposing risks, and therefore eventual costs, to avoid minor workarounds and low-impact bugs is poor engineering and risk management.

Engineering and all risk management includes tradeoffs. It's easy to criticize the downside of the tradeoff - the same people criticize the reverse decision when the server (or drone) crashes - when someone is not responsible for both sides of it, when they are not accountable for their words when the outcome occurs.

That's speaking generally. It's also poor risk management to be overly safe. I don't know about the parents' situation. But drone crashes (risking humans), mission failure, $50 million losses, and associated downtime (including delays) and labor costs, seem like high costs that are worth some pain to avoid.


This is why Ukraine is making equivalent tech now for 1/10th the price. It's great to see.


All the drone footage is actually pretty horrific to see.


It's always been pretty horrific. We just didn't have bodycam livestreams invented during trench warfare times.


Yeah FPV drones have massively increased the cost of invading a country. It's basically a return to WWI style trench warfare, except no man's land is the size of the range of the drones (20+ KM).


It's a million times worse than that. Drones have commoditization accuracy and precision and dramatically improved ISR, and that has produced a dramatic jump in lethality.

You used to be able to take a hit and survive a war. Those days are gone. Now you die because 1kg of C4 blew up your entire ass, or you take a less dramatic hit but you will never be dragged back to a field hospital.

Eventually the US or similar will have to get into this kind of war, and there will be a come to jesus moment for all the hoo rah americans who think your chances of surviving a war are based on anything other than sheer luck.

This is Bad, man.

Nukes already showed you can't make a weapon so crazily deadly and destructive that man would end war, so things will be bleak for the rest of humanity's reign.


the gray zone is ~200km so long as you have ISR drones able to see it

artillery, missiles, and long range drones are in the mix too. AI enabled spotting makes ISR detection rapid and effective.

some kubernetes container spots a random pixel that means hidden vehicles and a HIMARS strike is dispatched ASAP


Hopefully making the real horrors of war visible to the public/world will make war less frequent. Alas...


Has seeing the horrors of the Ukraine war made you want the west to stop it and force a surrender? More horrors don't make people want less war. If anything, it may be the opposite. People pretend to be anti-war right up until there's a war and then suddenly it turns out they're actually anti-losing-the-war.


I want less war. I'm against attacking other countries, but totally in favor of defending yourself if you get attacked. Those aren't contradictory statements.


That sounds noble until it doesn't work in reality and people always find reasons to justify wars. If it was so simple, it would be easy for most people to get on board with and most wars would end.

For example, do you agree that Britain's and France's appeasement of Germany before WWII was the right thing because an attack wouldn't have been self-defense? Or, what about attacking another country to help defend an ally who's being attacked by them? That's not defensive, so I guess it's wrong by your standard for any other country to defend Ukraine. What about defending them by supplying arms and soldiers? The line gets blurry fast.

How about re-taking some recently lost territory? Is that wrong? For example would it be wrong for Ukraine to attack Russia to regain its eastern areas that Russia took at the beginning of the war? Or for Russia to retake any other parts of the soviet union? How about either North or South Korea attacking the other? If everybody opposed such non-defensive wars, they would be severely disadvantaged to a country that incrementally takes pieces of their territory in a ratchet effect.

What about "liberating" the people of another country from a brutal dictator? I'm sure you'll oppose this because it's like Iraq or Syria, but is there really no case where it's justified? Not even Pol Pot's Cambodia where it might have saved a quarter of the population from death it somebody had intervened?


Never start a fight but always finish one.


Surrendering to an aggressor will let the aggressor get what they want, hence making war more appealing. So it's coherent for anti-war people to resist and make it as hard as possible for an aggressor. Even Gandhi justified defensive war.


Humans just adapt and normalize things too quickly, so long term seeing more violence will just desensitize people and make it more acceptable. Just look at the difference between protected kids in suburbs vs kids growing up in bad areas.


People have been saying this since Vietnam (and actually now that I think about a little more, this may actually have happened).


In the late 1960s daily TV news coverage revealed the horrors of war to the American public as never before (just as Brady's photos had done in the Civil War). That palpable gruesomeness was instrumental in the rising tide of unpopularity enjoyed by the war (and Johnson) by the elections of 1968.


A month ago Sternenko had a crowdfunding campaign for the secret drones. Recently he showed the fruits of that campaign: new drones have better connection and now you can watch kills in 4k!

Also recent advances in battery tech brought increased energy density: the same drones which had range 20km now have 40km.


Yes, but it's not necessarily more horrific than the unseen effect of the 155mm shells. It's just that those don't come with killcams.

(The killcam is a WW2 invention, starting with linking cine cameras to the machine guns of fighter aircraft)


Most of us who build weapons of war live with some awful dilemmas. One of them is:

We want to perform our work skillfully, effectively, and professionally. But we never want our tools to actually be needed.

(Another is that we can't effectively create a shield without the risk of it being used as a sword.)


Well then don't make weapons of war.

If you make a hammer, it can always be used to murder someone, but if you make an AK-47, there's only one way it can be used. So if you don't want what you make to be used for killing, don't make an AK-47. If you 're good at toolmaking, choose to make tools that are not weapons.


Or as my dad, a CSAR pilot, used to say, "I'd be happy to be out of a job."


Depends on who's on the receiving end.


Actually nothing cheers me up more than seeing Russians being hunted down and killed by drones. Fuck them.


You must be British.


I agree. Nightmare fuel.


In contrast I read that Ukraine is approving 4+ new weapons systems PER DAY !!

Even when it comes to more expensive things like cruise missiles it seems the planning has to be that some high percentage of them may be shot down (and much higher for slower moving drones), so you really want them cheap and in high volume, with reliability somewhat of a secondary concern.


> Safety is extremely important, so you expect some slowness as a result, but it got pretty extreme. I remember one time having to do 6 weeks of testing around a one-line code change because a "helpful" dev fixed a small bug that had no practical impact.

Not to bring Tesla into this, but the contrast here is stunning. From a component manufacturer about the mindset of Tesla:

"Hey, we sent you over the new firmware for the component, check it out." (The test suite for this component takes approximately 36 hours to execute.)

Three hours later:

"This is working so much better, thanks a lot!"

"???"

"Oh, we just flashed a car we have here and took it out for a drive."

"?!?"

Oof.


This just seems like poor planning. If it were planned better, you could group a bunch of smaller bug fixes under the same acceptance test. The full acceptance test is a good practice for safety critical systems. Project management just has to get better at doing smaller unit/int testing on each bug and then grouping those changes under the full acceptance test.


This only makes sense if you have to test each fix in complete isolation which seems silly even for government employees and contractor body shops. You can't batch 80 real bug fixes and 20 "silly bug with no practical impact" fixes together?


Surely the dev wasn't able to merge that one-line code fix causing 6 weeks of testing without any other eyes on it and without someone else's PR-like approval...right?


a "hole pile" of ...?!

I'm surprised that someone who uses such a phrase was working on classified hardware in the "mid and late 00s".


for sure, no way even an intelligent person could possibly make a text-to-speech typo when writing a comment on an informal internet forum. Definitely a lying liar who lies


>> On a separate note, I'm curious as to whether AI is making an inroads in that space. I would imagine very minimal, if at all, but very curious.

tl;dr, not in practice. Far as I can tell this is still the SOTA in FPOV drone autonomy:

https://spectrum.ieee.org/ai-drone-racing

Basically, those guys trained a drone to beat human FPOV racers but they had access to the race course layout before the race and trained extensively on it. Can't do that on a battlefield.

Also: no shooting at enemy drones during FPOV races. Makes surviving to the end of the race simpler.


"Software saved the aerospace industry. Every other way of adding cost to an aircraft also adds weight."


If safety is extremely important, why there were bugs in the first place? Surely these should have been caught before code would get into main, no?


I don't really understand how any of this contributes to "defense". Sounds like "offense" to me. Just patrolling the skies over non-white countries and launching missiles at weddings. The reason the Pentagon invests so heavily in this kind of technology is our wars are so indefensible, they can't convince Americans to sacrifice blood in any quantity for other people's natural resources.


Drones can be used for both offense and defense. For example the usage of drones in Ukraine can be classified as defense.



Drones fly over Gaza all the time, scaring the shit out of people and sometimes murdering them senselessly. They have done this over many countries.


They certainly look white to me.

Are Spanish people white or Hispanic according to those definitions?

'Original peoples' is an interesting phrase. Neanderthals? Beaker people?

A single category for everyone from Pakistanis to Japanese is weird.



> Introduced in the 1780s by members of the Göttingen school of history, the term denoted one of three purported major races of humans: Caucasoid, Mongoloid, and Negroid

Sounds totally legit.


Caucasian includes South Asians and some East Africans according to that definition.


The best defense...




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: