Simple Systems Have Less Downtime (gkogan.co) 123
Greg Kogan, writes in a blog post: The Maersk Triple-E Class container ship is 1,300 feet long, carries over 18,000 containers across 11,000 miles between Europe and Asia, and... Its entire crew can fit inside a passenger van. As a former naval architect and a current marketing consultant to startups, I found that the same principle that lets a 13-person crew navigate the world's largest container ship to a port halfway around the world without breaking down also applies to startups working towards aggressive growth goals: Simple systems have less downtime.
Ships contain simple systems that are easy to operate and easy to understand, which makes them easy to fix, which means they have less downtime. An important quality, considering that "downtime" for a ship could mean being stranded thousands of miles from help. Take the ship's steering system, for instance. The rudder is pushed left or right by metal rods. Those rods are moved by hydraulic pressure. That pressure is controlled by a hydraulic pump. That pump is controlled by an electronic signal from the wheelhouse. That signal is controlled by the autopilot. It doesn't require a rocket scientist or a naval architect to find the cause of and solution to any problem.
Ships contain simple systems that are easy to operate and easy to understand, which makes them easy to fix, which means they have less downtime. An important quality, considering that "downtime" for a ship could mean being stranded thousands of miles from help. Take the ship's steering system, for instance. The rudder is pushed left or right by metal rods. Those rods are moved by hydraulic pressure. That pressure is controlled by a hydraulic pump. That pump is controlled by an electronic signal from the wheelhouse. That signal is controlled by the autopilot. It doesn't require a rocket scientist or a naval architect to find the cause of and solution to any problem.
Duh! (Score:5, Insightful)
Just my 2 cents
Re: (Score:3)
OK who needs to be whacked with the clue stick?
Give Greg a break, he needs this -- he writes a blog. :-)
Re: (Score:2)
Re:Duh! (Score:5, Insightful)
Apparently, way too many modern software developers. Especially the ones who use a whole framework with extra libraries when a single line of Javascript could have done the job had they actually understood the job in the first place.
Some are even worse. I have seen frameworks and javascript used to render static pages.
Those people may need more than one whack.
Re:Duh! (Score:5, Funny)
Wait you're telling me you don't need a virtual python environment inside a docker container inside a virtual machine slice?
Re: (Score:3)
Re: (Score:2)
I'd laugh.
If I wasn't right now pentesting a system that looks just like that. Just replace that python with something else and you're there.
Re: (Score:3)
"It's funny cuz it's true"
Homer J. Simpson
Re: (Score:2)
Apparently, way too many modern software developers. Especially the ones who use a whole framework with extra libraries when a single line of Javascript could have done the job had they actually understood the job in the first place.
Some are even worse. I have seen frameworks and javascript used to render static pages.
Those people may need more than one whack.
Indeed. In an academic lab were students close to getting their CS BSc had to write a small web-application in groups, one of the teachers did statistics on the number of direct and indirect dependencies and the number of people that were involved by extension. Worst case was something like 4000 dependencies and 800 people. None made it significantly below 1000 dependencies. That is not just bad engineering, that is completely insane!
We will have to scrap all of this trash eventually and I do not mean the a
Re: (Score:2)
Indeed. In an academic lab were students close to getting their CS BSc had to write a small web-application in groups, one of the teachers did statistics on the number of direct and indirect dependencies and the number of people that were involved by extension. Worst case was something like 4000 dependencies and 800 people. None made it significantly below 1000 dependencies. That is not just bad engineering, that is completely insane!
If their web app ran on Linux, then the last kernel release had 1800 contributors alone and I doubt the numbers are lower for Windows and Apple. Is that a bad thing? Probably not. Some of these things are massive toolboxes and even though all you need is a hammer it's not a big practical deal. Other times it's a framework that completely locks you into doing things their way, there's a lot of "quality" to these numbers too not just quantity.
Re: Duh! (Score:2)
The risk is proportional to the number of users. Linux has more users, and so the risk is less. On the other hand, if you depend on 2 dozen projects, each with its own author, and none with more than a handful of users, then you're likely to have a problem.
Re:Duh! (Score:5, Interesting)
I became a "software together-hacker" late in life, after being an electrical engineer before, and a hands-down electrician before that.
What really get's me is the number of times that my 9 "software only" people I work with are completely stumped by a problem that is glaringly obvious to me. And that 90% of the things I learned fixing over 50 year old electrical stuff in a farmers barn also help me find problems related to software,.
Re: (Score:2)
I became a "software together-hacker" late in life, after being an electrical engineer before, and a hands-down electrician before that.
That is an excellent fallback position if^H^H when you fed up with IT.
Ford versus Japanese cars (Score:2)
Up through the 90s, if you gave a presentaiton on anything but acetate viewgraphs you were asking for power point to lock up or windows to crash.
In the 70s and 80s a lot of people liked Fords precisely because they had carburetors, mechical ignition timing, and no computers and you could actually repair everything without a technical training course from the manufacturer.
Boeing, back when it was run by engineers instead of accountants, was the last one to switch from mechanical (cables) controls to fly by
Re: (Score:2)
But the first three of these are now cases where complexity was mastered and technology finally became reliable.
The same is true for the fourth as well. One has to wonder why, then, is it not being implemented properly or reliably?
Re: (Score:3)
The difference is that the fuel injected computer controlled engines actually do run more efficiently, with less emissions, and more reliably, so the complexity has a distinct payback. The dynamically rendered static page shows no benefit for the added complexity. Think of it as Occam's razor for engineering.
Also, much of the added complexity is well encapsulated in the ECU. Outside of the ECU things are actually simpler than the mechanical linkages you might see in the old Ford.
On the flip side, we have el
The publisher stays in business (Score:2)
The dynamically rendered static page shows no benefit for the added complexity.
The benefit of a dynamically generated static web page to a publisher is that the publisher can measure the audience, display targeted advertising, and realize enough revenue to keep paying the writing and hosting bill. The benefit to the audience is that the publication continues operating instead of shutting down due to bankruptcy liquidation.
EVoting can work (Score:2)
There is a very simple way to make eVoting reliable.
Let the person vote on the evoting machine at the polling booth and then have the machine printout a paper ballot with what they selected. They can verify thats what they wanted and then put the ballot into a ballot box.
Do the tabulation elecronically and then count 10% of the physical boxes from each polling station. if numbers are statistically out of whack then count all the boxes else just announce the electronic count.
This takes away the fear of the s
Re: (Score:2)
Re:Duh! (Score:4, Interesting)
Ah, yes. "Static Apps." The new rage.
I forget the product, if I remember I'll come back and post a link, the documentation - purely static content - is a NodeJS application deployed to Netlify. So you go to the documentation link, your browser downloads and interprets dozens of javascript files, all to render... what? Nothing that you can't do with a single HTML file and a bit of CSS to make it pretty. Two files. One, if you want to embed the CSS.
Completely unnecessary.
Re: (Score:2, Funny)
Completely unnecessary.
Au contraire!
Billable project hours, Baby!
Re: (Score:2)
Agreed.
I think the problem is how software engineering is taught.
Primarily with Object Oriented Programming. Where we are taught to build abstraction for most of the process.
Now there isn't anything wrong with OO Programing, however experience has shown me, that being too much a stickler for proper OO Form will code yourselfs in overly complex systems because you are making too many Complex objects that become difficult to debug, and often harder to fix, when it fails on one condition but works for others.
S
Re:Duh! (Score:5, Interesting)
Once, when I was someplace, I was fired. Turns out, the day after I took a look at their redundancy systems (a design, I never logged into anything or actually touched it) and pointed out an obvious single point of failure in their routing configuration (pushed there by someone who had since been promoted beyond his ability, not that he did his previous job well), the routing protocol had an error and took down their "redundant" system. I think the guy who set it up in the first place scape goated me.
There are piles of clueless people out there who think more redundancy is better, and they add so much redundancy it fails.
Re:Duh! (Score:4, Informative)
I was one of those coders that practiced the dark arts of redundancy and failovers. redundancy is a natural way of making sure failures and preventive maintenance can be done ( think hot swapping on raid's )
Failover's are duplicate system ( sometimes lighter ) to take on whatever happens when a system part fails.
Side Note : On a yacht that I and the owner are good friend, I had him install a bank of oil filters on a set 3-way valves ( from the line to the filter then from the filter to the line ). The captain at first did not like it, but then came the day when the hours on the filter had to be swapped out, the engineer moved it from 1 to the next, wrote in the log book the hour and it was done after it cooled down right when they docked. it saved time, reduced the risk of spillage and it has build in redundancy. We are exploring this if this is a good idea on the fuel system.
On topic : .. slam server 2 and then try to pull the plug connecting the sans to server 2 and see if server 3 can take over ( this was my favorite test, because I alway think of 9/11 and the loss of a complete data center )
The first goal is you need to always learn is to get a working version that is crashing about every hour or so under light to medium loads.
Now you build over the first and simple failover ( server 2 )
go back to server 1 fix the problem, test and pour yourself a beer, change back to server 1 and do the code change in server 2
back and forth with simple failovers till you have a good beta product... then the fun kicks in
Want 7 different types of redundancy... no problem, follow these steps
server 2 is the test bed, let's hit it with a super heavy load and break it.
great we broke it, fix the issue, use that code on server 1 and break server 2 again
perfect now we have a system tested to a new working level that won't break so easy.
now install server 3 with the same code on server 2
Now on server 2 install first redundancy, with it switching to server 3 as the redundant system ( or failover )
let's think of that san's
keep testing on the physical fixes code, once it works and it fails over properly, then move the code to server 1
1 redundant system at a time
test to break, and when it breaks, figure out what did it. but you can not do this in a parallel process, this is a sequential process. before you know it, you have low code bloat that is well documented. and because it's designed with failover and redundancy, you can mirror the servers to other sites ( that brings it's own latency issue problems )
in reference to the latency issues... I was called into a meeting by a friend that was having this problem ... the solution was rather simple ( it's a catalog purchase company with warehouse all over the USA ). the purchase of any item from the catalog was done almost in a static mode with few to little updates, most if not the entire web transaction was done in memory to keep the speed and the consumer happy avoiding any lag. the inventory updates were done right after the transaction processed closed ( billing ) , and was sent to order picking. worked really well until amazon, now they handle everything except the catalog.
Re: (Score:2)
Re: (Score:2)
As for the mainframe example, I've not worked on those, but something like a Cisco Catalyst 5500 is highly redundant and highly available. The chassis is wires and
Re: (Score:3)
"OK who needs to be whacked with the clue stick?"
Most people in the IT department where I work. Although this really extends to many IT functions beyond my place of employment and likely beyond the world of IT.
Re: (Score:2)
Re: (Score:2)
And sometimes you need to break out the Clue-by-four.
Re: (Score:2)
You've never worked in companies older than 5 years then? They're riddled with legacy baggage, successive managers and developers piling on more kit to solve problems no one has, no one ever stands back and says "Stop this sh*t! Let's simplify.". Simplification costs time and money, easy to just add another system and let it feed from the legacy baggage. Too many companies leave IT to it's own devices, biz and IT rarely talk to each other than for the biz to demand IT install X software.
I've worked in a pla
Re: (Score:2)
The root problem is that every single thing you need done is a slight change in the existing system that doesn't warrant scrapping the old and building something new. In combination, they would easily warrant the deployment of a new system, but each by themselves does not.
Try to get this past the beancounters. And take a camera with you, we could all use a good laugh.
Re: Duh! (Score:2)
In direct context of the op...the designers of modern US naval vessels, for one group?
Re: (Score:2)
Mod parent up, though I think a "Duh!" mod would be better than "Insightful".
Right, but... (Score:5, Insightful)
Re: (Score:2)
Just my 2 cents
Re: (Score:2)
We have replaced all the GOTO statements with our new proprietary revolutionary AI (case statements) ;)
Just my 2 cents
I imagine this involves far fewer Velociraptors [xkcd.com] ...
Re: (Score:2)
our is much more advanced. we use computed double look up tables based on exposed reference addresses.
What does 'simple' mean to you? (Score:5, Insightful)
So the rudder is a simple mechanical system? Um, not so blooming fast. Sure, fault isolation may be easy with common hand tools, but fixing some of this stuff is *not* always simple and straight forward. Hydraulic cylinders of the size needed and pumps to move the oil around are not simple to fix. So what do you do? Throw in a backup system, which just complicates the whole mess, but what ya going to do. What about the engine banging away deep in the stern? The fuel and emissions management systems are *far* from simple, and never will be.
But it's not the rudder or engine that usually has issues, it's the electronic equipment and electrical systems which are literally all over the place that concern me. IF that rudder works great, but the navigation system won't boot what are you going to do? Grab that sextant your watch and start making fixes that way? That's not simple, nor easy.
I think they need to think carefully about what they mean when they say "simple" because the navigation and communication systems are anything but simple.
Re: (Score:2)
Why wouldn't the pump be a simple fix? It was designed to be serviceable after all. How complicated can the backup system possibly be? Throw a few switches and valves and its running. I don't think ships even have emissions systems as they create incredible amounts of pollution.
Re: (Score:2)
Sadly, we don't a have a set of plan's.
But Maersk line vessels are basically the volvo's of the sea, they work and don't fail. they are as you said, well designed to be serviceable. and they do have multiple redundancy and failovers.
could you steer the ship without power on the bridge. I would not be surprised if there is a chain or cable wire link in the system down in the engine room area. might not work well, but you would be able to safely control the vessel until the tugs arrived.
Re: (Score:2)
Apparently you haven't heard about the new marine fuel sulfur limits, which are causing ships to either switch fuels or install scrubbers. https://www.eia.gov/todayinene... [eia.gov]
Ironically one of the types of fuel is called bunker fuel.
Re: (Score:2)
Why wouldn't the pump be a simple fix? It was designed to be serviceable after all. How complicated can the backup system possibly be? Throw a few switches and valves and its running. I don't think ships even have emissions systems as they create incredible amounts of pollution.
Just spitballing from the couch... But...
I imagine that the biggest problem facing sailors out at sea is not knowing what needs to be fixed, but having the equipment needed to do the work and the necessary hands to get it done. Some stuff used in ships is extremely large and heavy so it may be clear that some bearing is bad, but if you have to remove a 2 tone bearing cap and then slide the 1,000 lb bering off, wrestle the new one out of storage and into place without killing somebody.
Modern ships do have
Re: (Score:3)
The most reliable system is as complex as its required to be and no more so.
The more "plumbing" there is the more potential for the works to get gummed up; by the same token saying you don't need all those sat-com and navigation equipment means other problems; pretty easy to get lost with watch and sextant. The best design is the one that meets all the requirements without trying to go further.
Re: (Score:3)
"The best design is the one that meets all the requirements without trying to go further."
But the requirements are always being pushed further. Think of all the new technology in vehicles these days: safety, emissions, ignition systems, etc. If each one was a simple modular component with a red or green light on it (indicating "ok" or "needs replacement") you could say that might be simple as well. But weight, esthetics, cost to manufacture, size are also requirements which can complicate the design. Th
Re: (Score:2)
I don't disagree. I have a car with a lot of electronics and extras now. Its been to the dealer multiple times for various things. Including a failed map update for the GPS that left a lot of the head unit non-functional. All down time. Problems I have never had with late-80s and early-90s vintage cars I drove in highschool and college.
OOTH. Uptime is important but I don't have a specific requirement. I can always get a rental while the dealer fixes my car. I live in fairly rural area but its not exac
Re: (Score:3)
So the rudder is a simple mechanical system? Um, not so blooming fast.
I'm not a mechanical engineer and yet, I too can imagine counterarguments. In my simple head, what's going to fail on a rudder? I dunno, a blown hose, a bent rod, or a failed rudder bearing? Some of those are going to be field serviceable, other I really doubt it. Let's take the push rods. If one snaps, jams, or bends, I find it hard to believe you've got a spare and/or the winch to wrestle it into place. But maybe you do, I'm not a sailor. Maybe when you had 30 salts on the ship instead of 11, you had enou
Re: What does 'simple' mean to you? (Score:2)
Saying simple systems are in fact very complicated doesn't refute the point that simpler systems are easier to keep running.
I'm not even sure what your point is, maybe you'd welcome a DevOps team giving your ship a once over, because it's already complicated, what's a little Python going to hurt.
Re: (Score:2)
Yeah... that was a big red flag for me. A “simple” system can still optimize power from the propellers on either side to maximize forward and turning efficiency.
What a simple system cannot do is have two hydraulic pumps (plus backup), normally operating dedicated to a single direction, and then when one pump is down, operate several valves to allow the remaining pump to maintain direction control. Bonus points if you can find a redundant path for the mechanical linkages, and add in an ipad app
Gall's Law (Score:4, Informative)
https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law [wikipedia.org]
P.S. I am also a fan of a saying often attributed to Einstein:
https://quoteinvestigator.com/2011/05/13/einstein-simple/ [quoteinvestigator.com]
Re: (Score:2)
I've always liked this Sir Anthony Hoare quote from his Turing Award Lecture [fsu.edu]:
"I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
The first method is far more difficult."
No engineer needs to be told that (Score:4, Insightful)
KISS is the mantra of all good engineers for a reason.
Of course, most people writing software are neither engineers nor good at what they do. Hence what they produce is overly complicated, unreliable, insecure and often slow. Finding simple solutions is much harder than creating a complex mess.
Re: No engineer needs to be told that (Score:5, Insightful)
In the software world, at least, you have a largely untrained self-taught group of people standing on the shoulders of giants to get anything done. They seem to not only misunderstand why complexity is bad but to view it as some badge of their elite skills.
I'm a qualified hardware engineer and I can tell you even educated people who are experts in my field fall into that trap. It's so easy to design a complex system and then need to keep adding special cases for unexpected states through the system caused by unexpected inputs until the design is a complete mess, 10x over the BOM budget and only just works well enough you might be able to sell it.
Simplicity is king, and being able to identify where it is needed and how to achieve is a skill that makes it look like you're not as productive as the guy next to you who churns out volumes of complex buggy designs every day.
Re: (Score:2)
Simplicity is king, and being able to identify where it is needed and how to achieve is a skill that makes it look like you're not as productive as the guy next to you who churns out volumes of complex buggy designs every day.
And that certainly is one of the factors here. Throwing more code at a problem is easy, simple, mindless and gives you good productivity metrics. Well, at least if those metrics are completely broken and they usually are for software.
Re: (Score:2)
I'm a qualified hardware engineer and I can tell you even educated people who are experts in my field fall into that trap. It's so easy to design a complex system and then need to keep adding special cases for unexpected states through the system caused by unexpected inputs until the design is a complete mess, 10x over the BOM budget and only just works well enough you might be able to sell it.
I've worked with plenty of "qualified hardware engineers". You are all the same. "System bursts into flame occasionally? No problem, the software guys will patch the firmware to stop the fire from spreading!"
You leave your shitty design mistakes all over the place, and fully expect 'software' to fix them all... somehow. "No, we can't change the hardware, the design was already accepted. Fix it in software." Excuse me, wasn't the design of the software accepted at the same time!?
Re: (Score:2)
The fewer the pieces the better it is. Long complex chains of automation, particularly of semidigital,semianalogue systems are difficult to debug. Agreed.
Re: (Score:2)
I agree about the badge of honour thing. I've seen designs so complex that "only John knows the full story". It turns out John was also the architect of this doom, and seems fearful of the future so has built his empire to avoid getting fired. John also fails to write any of this down, and also fails to try to tidy up any of the rough edges, so things never improve and no one can ever help out.
In such places, I've also usually found the PHBs prefer systems too complex for them to understand. If they can't u
Re: No engineer needs to be told that (Score:2)
Largely because of management. Management has no patience for good design or engineering.
That's why I ignore everyone who tries to tell me what my priorities are. I know what they are. I can smile and nod with the rest, but at the end of the day our conversations have zero impact on what I work on.
I limit the amount of information I deliver up the food chain because management uses information like this to come up with more "efficient" ways of doing things. As long as I keep them in dark about details, I in
Re: (Score:2)
Simplicity is king
Indeed, but end users don't seem to understand that it's better to have an occasional minor failure that is easy to diagnose and fix rather than a gigantic hair snarl of a system that only fails once in a blue moon but which takes the whole system down and entails hours/days to fix.
I work in physical security (key cards, alarm systems, cameras, that stuff) and users complain insessently about the inflexibility of Lenel software (the 800 pound gorilla of the access control world). "It can'
Re: (Score:2)
It's funny how just about everyone will come up and offer a much more complicated solution to an already solved problem.
I've had machines that I designed that run 24/7 for years, and when they start to have issues it's amazing how everyone comes out of the woodwork to tell me how it needs to be redesigned.
"I think maybe a couple air cylinders on a hinge, and a prox switch on there will make this much more reliable, something to push it. You know what I mean? Like a flap on here, so if it gets crooked, it pu
Re: (Score:2)
Ah, yes, morons that cannot listen to instructions, that cannot read a manual, that do not understand how things work but believe otherwise and when it all goes wrong it is never their fault. You find these on all levels, unfortunately. Dunning-Kruger effect at work.
Not surprising (Score:2)
Its much more difficult to test complex systems because there are too many possible combinations of inputs and internal states. In addition the more tools that are used, the higher the chance that one of those tools will have a bug or that an interface will be misused. Debugging complex systems is much more difficult because often it is not obvious what part of the system failed.
An additional problem is that complex systems that rely on a large number of components can be very difficult to upgrade. Good
Re: (Score:2)
Its much more difficult to test complex systems because there are too many possible combinations of inputs and internal states.
It's not like Intel would test a CPU, pass the tests, then start selling it and find it had an error in the FPU. https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: Not surprising (Score:2)
Its much more difficult to test complex systems because there are too many possible combinations of inputs and internal states. In addition the more tools that are used, the higher the chance that one of those tools will have a bug or that an interface will be misused. Debugging complex systems is much more difficult because often it is not obvious what part of the system failed.
It's worse than that. Every branch doubles the number of internal states. In electronics this can lead to strange behaviours like oscillation, unexpected RF emissions, etc. In software, unexpected crashes, races, etc.
And the more complex the system the more likely that the failure reported is just the messenger for a long chain of cascading failures that passed through the system without being noticed by earlier layers.
In the boat example this might be the rudder is at full portside lock and the autopilot t
Better turn off the radar and GPS then (Score:2)
Oh, also, switch off the radios and satellite Internet with the live weather reports and super-computer forecasted weather forecasts.
And of course, the crew definitely can't have any iPads or iPhones. The "simplicity" of those is based on millions of lines of complex computer code and billions of transistors in super-complex designs. Not to mention a shitload of tiny, complex, intricate physical parts..
Luckily... (Score:2)
Re: (Score:2)
Yes and no; it might reduce end-user complexity, but it does not make things like input validation and corner cases less important.
Not a software guy, but I remember writing a perl script to take a stupid amount of data and make it less stupid so graphical tools could more easily process it. While my stupid (very stupid) script was effective at its task, it was neither an elegant (aka simple) approach, nor was it practical for actual use. It still simplified the problem...
Less Down Time for simple systems? (Score:2)
Re: (Score:2)
About 40-50 years ago, DARPA’s predecessor agency calculated the fault matrix for parallel redundant systems based on a lot of data (and math). 1+1 = 1.8, ..., 5+1 = 1.1. It is interesting how these studies and the math they established still apply today.
More secure too (Score:4, Interesting)
Simple systems are also more secure...
The operators understand how they work, and can quickly identify if something unusual is happening. An attacker has a much smaller footprint to attack.
Re: More secure too (Score:2)
System A is a database with a web front-end.
System B is based on System A, but adds authentication and transport security.
System A is simpler than System B.
System B is more secure.
Re: (Score:2)
System A has no authentication, thus unauthenticated access is "by design" and not a bug. Whoever deploys such a system does so knowing its limitations and accepts them.
System B implements authentication and transport security - additional code where bugs could be found and which could be misconfigured.
Edsger W. Dijkstra (Score:2)
"Simplicity is prerequisite for reliability [wikiquote.org]." -- Edsger W. Dijsktra (1975)
Wisdom that is lost among many of current designers, developers and engineers ...
Until ... (Score:2)
Simple AI (Score:2)
Take the ship's steering system, for instance. The rudder is pushed left or right by metal rods. Those rods are moved by hydraulic pressure. That pressure is controlled by a hydraulic pump. That pump is controlled by an electronic signal from the wheelhouse. That signal is controlled by the autopilot. It doesn't require a rocket scientist or a naval architect to find the cause of and solution to any problem.
So... it's a simple system controlled by some undefined level of AI? Yeah, that's not as simple as they claim. Does their crew contain a software engineer?
Re: (Score:2)
Traditional "autopilots" on planes and ships are nothing more than a simple negative feedback loop that maintains heading, speed, and (for boats) altitude.
Perfect? No. But certainly good enough to let you rest during the boring parts of a trip when there is nothing but blue skies or open ocean in front of you.
Re: (Score:2)
Re: (Score:2)
Bilge water
They also have less uptime! (Score:2)
Yeah, if I have less functionality, less can break ... because less can be done in the first place!
You know what? Why not go all the way?
Here, take this dead featureless cube of pure silicon as your new computer!
It will never ever stop working! Ever.
What features does it have? ... NONE!
It is your perfect ideal of simpleness that you've got wet dreams about when you are afraid of the world being too complex for you again!
Genius!
Too bad in reality, things have to do things, and that requires complexity and co
Layers of Complexity (Score:2)
Re: Layers of Complexity (Score:2)
You get better efficiency from the software developers, not from the tech.
I've not seen an efficient website since Craigslist.
Re: (Score:2)
DNS and routing tables are a lot more than 20 years old but I can't count the times that I've seen an error there take down an entire enterprise and take hours and scores of people to figure out.
Containers, containers (Score:2)
Bull shit (Score:2)
Are you listening Lennart? (Score:2)
Simple by word alone (Score:2)
"Take the ship's steering system, for instance. The rudder is pushed left or right by metal rods. Those rods are moved by hydraulic pressure. That pressure is controlled by a hydraulic pump. That pump is controlled by an electronic signal from the wheelhouse. That signal is controlled by the autopilot. It doesn't require a rocket scientist or a naval architect to find the cause of and solution to any problem."
uh, that is simple? i would call that 'complex', we're talking about a rudder. a simple rudder is w
Re: (Score:2)
For a boat the size of a container ship, yeah, that's pretty simple. TFA mentions that should all that fail, you can attach a chain to the rudder and manhandle it that way if all else fails.
You should look at the wind vane self-steering devices for sailboats. They are fascinating devices that are pretty fricking complex, but they're beloved by sailors because they are made up of relatively simple parts that could be fashioned out of bits and ends you have on hand if something breaks. Complexity and simplici
Re: (Score:2)
Autopilot on a ship is actually only one step above tieing off the wheel. Its instruction set is essentially "Keep on this bearing and speed until I turn you off."
In the words of Chief Engineer Montgomery Scot (Score:2)
The more they overthink the plumbing the easier it is to stop up the drain.
Crew of _13_?! (Score:2)
Just begging for trouble ...
Wrong end of history. (Score:2)
Granted for developing new technology, starting simple is still probably better than starting complex, but the lesson here is really 'test, test, test
Obvious to some, but not all. (Score:2)
I design and build 3D printers. One of the trends that has been gaining popularity in the hobby in the last couple years is auto tramming systems for print beds. The idea is to lift the bed using three screws and motors while a sensor on the extruder carriage checks the bed position and firmware on the controller decides which screw to turn and by how much. If you look at the popular 3D printing forums you'll find a lot of people having trouble setting up those systems and keeping them working. You can
Re: (Score:3)
In the programming way of thinking, this would mean having clearly defined inputs, outputs, and contracts for your functions and classes. You need to know what your functions do, or you will make mistakes, no matter how good your mind is at being logical.
Re: (Score:2)
" When the engineer designed the ship..."
No engineer designed the ship. Teams of engineers designed multiple systems. My old company designed systems for them and we were one of many in most cases.
Re: Complete nonsense. (Score:2)
Re: (Score:2)
I've been on triple E's and other Maersk vessels, those ships are super well designed ( look at some of the CGM's vessels, they always think outside of the box ). every item used is a well known equipment. So yes the hull can be moved from one building yard to another, but odd's are all the pieces are put into place in 1 location and 1 ship builder
I think you are talking more on another design level, maybe yachts. but even then, those guys get a refit ever 6 to 10 years.
Re: (Score:2, Insightful)
The system is this, you either maintain the vessel whilst it is underway with a larger crew or you maintain the vessel whilst it is stationary with a maintenance crew in port. Choose which way you pay for maintenance. What they are doing is capitalism, running until failure, that failure will either occur in port or whilst at sea. Failure at sea costs way, way more than a crew, but that is someone else's problem years down track.
It is the way psychopathic capitalism runs things, more profit now and failure
It's called scheduled maintenance! (Score:2)
Why do you conflate scheduled maintenance with "running until failure"? Aircraft (Phantom, Bronco, F-16 A/B/C/D) and industrial maintainer of several decades here.
Scheduled maintenance and inspection is planned around mission activities to lower the odds of failure. Aviation safety is proof it works superbly. There's no fixing birds in flight so they're maintained on the ground. Scheduled maintenance and inspection is the heart of productive fleet maintenance. Trucking fleets monitor their systems too. It's
Re: (Score:2)
one thing to consider is a ship canals 50 years. Think of the difference in tech between 1970 and 2020
Re: (Score:2)
I don't know too many people who run NMEA-0183 if they can run NMEA 2k unless they're trying to extend the life of a legacy component. NMEA 2k has been around long enough that anything still around that's 0183 is probably overdue for replacement anyway and if it gets kept they just add in a 2k converter to it so the bus stays 2k.
It's long past due for NMEA to finalize the OneNet ethernet-based standard, but as you can imagine the major marine electronics manufacturers make too much money selling proprietar
Re: (Score:2)
One form of poor design is excess complexity