I wonder what happens if the summary is longer than the original text. Negative percentages? Stack underflow?

and log files eating up storage space was a common culprit.

Another classic symptom of poorly maintained software. Constant announcements of trivial nonsense, like [INFO]: Sum(1, 1) - got result 2! filling up disks.

I don’t know if the systems you’re talking about are like this, but it wouldn’t surprise me!

this is software speciifcally for assembly line management?

You got approval for new SSDs because the manglement recognised threat identified by you as critical?

Right?

Literally sent that email this morning. It’s not that we don’t have the space, it’s that I can’t get a maintenance window to migrate the data to the new storage platform.

Can’t you just add a few external USB drives? (heard this more than once at an NGO think tank.)

Sometimes that person is very silly though. We had a vendor call us saying we needed to clear our logs ASAP!!! due to their size. The log file was no joke, 20 years old. At the current rate, our disk would be full in another 20 years. We cleared it but like, calm down dude.

Or you could be fired because technically you’re the one that caused the outage.

Except then they’ll decide you fixed it, so nothing more needs to be done. I’ve seen this happen more than once.

C:\Homework\System Files\Win32\Windows files\Do not Open\Virus\Please don’t open

Toyota was the carmaker best positioned for the COVID chip shortage because they recognized it as a bottleneck. They were pumping out cars a few months longer than the others (even if they eventually hit the same wall everyone else did).

It wasn’t just Fukushima. There was a massive flood in Thailand at the same time that shut down a load of suppliers. It was a really bad bit of luck but they did learn from that.

It not going to bring the service online, but it will prevent a full disk from letting you do other things. In some cases SSH won’t work with a full disk.

It’s nothing for my homework folder.

Sends a message and gets the services ready for potential shutdown. Or implements a rate limit to keep the service available but degraded.

Also, if space starts decreasing much more rapidly than normal.

At that point just set the limit a few gig higher and don’t have the decoy file at all

Why not both? Alerting to find issues quickly, a bit of extra storage so you have more options available in case of an outage, and maybe some redundancy for good measure.

A lot of companies have minimal alerting or no alerting at all. It’s kind of wild. I literally have better alerting in my home setup than many companies do lol

Yes, alert me when disk space is about to run out so I can ask for a massive raise and quit my job when they dont give it to me.

Then when TSHTF they pay me to come back.

There’s cases where disk fills up quicker than one can reasonably react, even if alerts are in place. And sometimes culprit is something you can’t just go and kill.

Ctrl+z?

The problem is that leadership doesn’t interpret it that way and just sees “minimizing inventory increases profit!”

Yep. Managers prioritize short-term gains (often personal gains, too) over the overall health of a business.

There’s also industries where the “lean” strategy is inappropriate because the given industry is one that booms in times of crisis when logistics to get “just in time” supplies go kaput due to the same catastrophe that’s causing the industry to boom. Hospitals and clinics can end up in trouble like this.

But there’s other industries too–I haven’t looked for it, but I’m sure there’s a plethora of analysis already on what Covid did to companies and their supply chains.

In my own impression from the side of software engineering (i.e. the whole discipline rather than just “coding”) this kind of thing is pretty common:

• Start with ad-hoc software development with lots of confusion, redundancy, inneficient “we’ll figure it out as when we get there” and so on.
• To improve on this somebody really thinks things through and eventually a software development process emerges, something like Agile.
• There are lots of good reasons for every part of this processes but naturally sometimes the conditions are not met and certain parts are not suitable for use: the whole process is not and can never be a one size fits all silver bullet because it’s way to complex and vast a discipline for that (if it wasn’t you wouldn’t need a process to do it with even the minimum of efficency).
• However most people using it aren’t the “grand thinkers” of software engineering - software architect level types with tons of experience and who thus have seen quite a lot and know why certain elements of a process are as they are, and hence when to use them and when not to use them - and instead they’re run-of-the-mill, far more junior software designers and developers, as well as people from the management side of things trying to organise a tech-heavy process.

So you end up with what is an excellent process when used by people who know that each part tries to achieve, what’s the point of that and when is it actually applicable, being used by people who have no such experience and understanding of software development processes and just use it as one big recipe, blindly following it with no real understanding and hence often using it incorrectly.

For example, you see tons of situations where the short development cycles of Agile (aka sprints) and use cases are used without the crucial element which is actually envolving the end-users or stakeholders in the definition of the use cases, evaluation of results and even prioritization of what to do in the next sprint, so one of the crucial objectives of use cases - the discovery of the requirement details by interactive cycles with end-users where they quickly see some results and you use their feedback to fine-tune what gets done to match what they actually need (rather than the vague very high level idea they themselves have at the start of the project) is not at all achieve and instead they’re little more than small project milestones that in the old days would just be entries in Microsoft Manager or some tool like that.

This is IMHO the “problem” with any advanced systematic process in a complex domain: it’s excellent in the hands of those who have enough experience and understanding of concerns at all levels to use it but they’re generally either used by people without that experience (often because managers don’t even recognize the value of that experience until things unexpectedly blow up) or by actual managers whose experience might be vast but is actuallly in a parallel track that’s not really about dealing with the kinds of technical concerns that the process is designed to account for.

Cool story, but a once every 150 years pandemic is hardly a good reason to keep wasting money on storing stuff. A fire or a flood was much more likely to wipe it all out in 50 years.

Even in your anecdote the owner never actually benefited from the extra costs.

Depending on what you’re producing costs to maintain extra inventory of raw materials can be massive and for the company the size of Toyota, multiply that by million.

Oh man. I work for an OEM and have almost the same story except the CEO didn’t retire so our shelves were never bare. A large part of our sales last year was because our competition couldn’t source parts and we could. Also since they have a skeleton engineering crew they couldn’t figure out how to improvise (at least this is what our salespeople are claiming).

2022 I spent 3 hours a day, every single working day, just making ECNs for parts out of stock.

Lean JIT is such fucking crap. When a customer line goes down they are bleeding who knows how many millions a day. They want a solution right freaken now. So they call the OEM and we tell them that part that died we have right here on the shelf and we can overnight it.

But you know how you really know that JIT Evengelical types are full of it? Talk to any of them now and they won’t say something like “look, normally it works but no one could have predicted this” they will double down on it and say it works but was implement incorrectly. It isnt “true” JIT.

Many years ago I read a sentence that I use every single week of my life “all ideology can do is reassert itself endlessly”. When I hear crap like that, how X works if and only if it is true-X I know I am dealing with ideology. When I hear that X works under very specific situations and only gives specific results I know I am dealing with facts. Yes if the customer is never in a rush, there isn’t a world shaking event, and you are running out of capacity for storage JIT might be an answer.

Yea, fair point regarding the single point of failure. I guess it was one of those scenarios that should just never happen.

I am sure it won’t happen again though.

As I said it can just happen even though you have redundant systems and everything. Sometimes you don’t think about that one unlikely scenario and boom.

The IT people that want to implement that disaster recovery plan do not make the purchasing decisions. It takes an event like this to get the retards in the C-suite listen to IT staff.

Yes, 4 spaces are 3 more bytes than a tab.

But if you compress the source files there would be no difference.