Heavy-lift ship lifts entire cruise liner out of the water [video](vimeo.com)
vimeo.com
Heavy-lift ship lifts entire cruise liner out of the water [video]
https://vimeo.com/348147095
196 comments
> Is this covered under warranty?
According to one of the links I cited earlier [1] Royal Caribbean won $65 million from Rolls Royce concerning RR's Mermaid thrusters which are very similar to Azipods, on the Celebrity Lines' 4 Millenium-class ships. And Cunard subsidiary of Carnival won $24 million for Queen Mary II's Mermaids. I think the warranty is more of a contract issue.
In newer builds the bearings may be more accessible.
[1] https://www.travelweekly.com/Cruise-Travel/Insights/Vista-ju...
According to one of the links I cited earlier [1] Royal Caribbean won $65 million from Rolls Royce concerning RR's Mermaid thrusters which are very similar to Azipods, on the Celebrity Lines' 4 Millenium-class ships. And Cunard subsidiary of Carnival won $24 million for Queen Mary II's Mermaids. I think the warranty is more of a contract issue.
In newer builds the bearings may be more accessible.
[1] https://www.travelweekly.com/Cruise-Travel/Insights/Vista-ju...
It's a hard problem. The bearings that rotate the azipods are huge, carry the entire propulsive force of the ship as an angled side load on the bearing, are below the water line, and are holding something that goes through the hull. Look at one of those things, think about the stresses, and wince.
Bearings with huge side loads are rarely used, because they wear badly. Ordinary ship screws are on a straight shaft through the stern, with a thrust bearing and seal. Far simpler, and solved a century ago. On the other hand, if you haven't solved the bearing and seal problems of propulsion pods, you shouldn't be selling propulsion pods.
"Ship early, ship often" gives you a terrible reputation in the heavy machinery business. There was once a saying in the railroad equipment business - "Never buy equipment from somebody in a better climate than yours." The good railway equipment manufacturers were in upstate New York, and over-designed everything. Which is what you want when a snowplow has to force the ice off the tracks, and devices in the trackway need to survive that. That's why you see railroad equipment packaged in half inch thick cast iron boxes.[1] That's from General Railway Signal in Rochester, NY.
[1] https://www.trainboard.com/railimages/data/541/sintonswitch....
Bearings with huge side loads are rarely used, because they wear badly. Ordinary ship screws are on a straight shaft through the stern, with a thrust bearing and seal. Far simpler, and solved a century ago. On the other hand, if you haven't solved the bearing and seal problems of propulsion pods, you shouldn't be selling propulsion pods.
"Ship early, ship often" gives you a terrible reputation in the heavy machinery business. There was once a saying in the railroad equipment business - "Never buy equipment from somebody in a better climate than yours." The good railway equipment manufacturers were in upstate New York, and over-designed everything. Which is what you want when a snowplow has to force the ice off the tracks, and devices in the trackway need to survive that. That's why you see railroad equipment packaged in half inch thick cast iron boxes.[1] That's from General Railway Signal in Rochester, NY.
[1] https://www.trainboard.com/railimages/data/541/sintonswitch....
I hadn't thought about the load on the strut that the pod hangs from.
When in working order, cruise ships can spin slowly in place so that all the passengers can see some scenery (e.g. the glacier at the head of an Alaskan fjord) from their own balconies. And they drive up to the dock without the aid of tugboats. But pods aren't the enabling technology for this maneuverability, bow thrusters, screws and rudders can do it, too.
I think the fuel efficiency is the tempting advantage of azimuth pods.
When in working order, cruise ships can spin slowly in place so that all the passengers can see some scenery (e.g. the glacier at the head of an Alaskan fjord) from their own balconies. And they drive up to the dock without the aid of tugboats. But pods aren't the enabling technology for this maneuverability, bow thrusters, screws and rudders can do it, too.
I think the fuel efficiency is the tempting advantage of azimuth pods.
It looks so low to the bottom of the dry dock. It's unusual to look at because in a normal dry-dock you're lifted so high by the blocking. I can look outside and see ddg-67 right now.
Very nice videos, thanks!
Warranty, that made me laugh.
Why? Most of the manufacturing contracts I've been involved with involve some kind of warranty.
Because in my head i heard 'and would you like to add the warranty, it's only 2 million for the 3 yr and 1.5 million for the 2 year'
Every time I see engineering projects like this semi-submersible, where massive teams work multiple years to deliver a highly complex project that has never been built before, I feel that the field of software engineering is immature and mostly a joke.
If every IT project with an equivalent number of man hours as this ship would produce a physical artifact like this, the sea would be full with abandoned Frankenstein ships, and not a many would actually function. I’m glad that software is invisible, mostly.
If every IT project with an equivalent number of man hours as this ship would produce a physical artifact like this, the sea would be full with abandoned Frankenstein ships, and not a many would actually function. I’m glad that software is invisible, mostly.
I have to remind myself that in "real" engineering there are (in theory) no surprises for the well understood physical processes at work.
There is never a new and immature "gravity library" that requires you to rework your existing designs to cope for new slightly different acceleration due to gravity, the "metal fatigue" library does not introduce new unexpected bugs randomly, there is no reason for the "corrosion library" not being able to be used at the same time as the "average human adult male height library" due to obscure dependency issues, you never have shoe-horn in the "compressive strength of concrete" functionality that was originally out of scope but sales now say is P0, you never have bugs like unexpected-yet-sufficiently loud sound waves overflowing to tiny negative values etc and causing a "negative sound area" or something weird and hard to conceptualise.
I.e. physics itself is largely unchanging. We have worked out the fundamentals and they don't really change - gravity never flips direction, bounancy always goes "up" etc - and we're not building on top of a ship that is built on top of another ship that is built on top of a hovercraft that is built in top of raft that is built on logs that is built for a fresh water environment but you are using it in salt water due to the CEO being buddies with someone, but the people building the ship only see the first turtle beneath them.
There is never a new and immature "gravity library" that requires you to rework your existing designs to cope for new slightly different acceleration due to gravity, the "metal fatigue" library does not introduce new unexpected bugs randomly, there is no reason for the "corrosion library" not being able to be used at the same time as the "average human adult male height library" due to obscure dependency issues, you never have shoe-horn in the "compressive strength of concrete" functionality that was originally out of scope but sales now say is P0, you never have bugs like unexpected-yet-sufficiently loud sound waves overflowing to tiny negative values etc and causing a "negative sound area" or something weird and hard to conceptualise.
I.e. physics itself is largely unchanging. We have worked out the fundamentals and they don't really change - gravity never flips direction, bounancy always goes "up" etc - and we're not building on top of a ship that is built on top of another ship that is built on top of a hovercraft that is built in top of raft that is built on logs that is built for a fresh water environment but you are using it in salt water due to the CEO being buddies with someone, but the people building the ship only see the first turtle beneath them.
Also, it's a different scale of importance. GPs criticisms are fair but is anyone in their right mind really willing to pay for a bulletproof blog system? Most software is simply not under the same set of requirements that these "real" engineers are. And where they are, you see more "real engineer behavior".
The standards between Blogging, Banking, and Aerospace are each drastically different and sequentially more rigid. Thinking that we as software creators are failing because we're not holding ourselves to the standards of Aerospace and beyond feels like complaining that some high school kid working at McDonalds is not holding himself to 5 Star Restaurant standards.
You get what you pay for. And you typically pay for what you (think you) need.
edit: structure
The standards between Blogging, Banking, and Aerospace are each drastically different and sequentially more rigid. Thinking that we as software creators are failing because we're not holding ourselves to the standards of Aerospace and beyond feels like complaining that some high school kid working at McDonalds is not holding himself to 5 Star Restaurant standards.
You get what you pay for. And you typically pay for what you (think you) need.
edit: structure
It's more than that. I'm a software dev, but I worked for a company that built machines for autonomous underwater titration (wtf chrome. How do you not know "titration"), and even in that nightmare of a task (moving parts, chemistry, batteries and underwater) it all ends up being way more consistent than software. When things fail, they tend to fail consistently and reliably, so building towards a reliable machine tends to be a simpler process. There is still complexity, (arctic and deep water applications), but often you can solve problems by just overbuilding the fuck out of it and not worrying.
I'll bite... what are we titrating in the arctic and deep sea?
Scientific sea water analysis. Measuring nitrates, phosphates, ammonia etc..
Oh, but there's new libraries out there: less in the physics (which remain as fundamental as the unchanging principles of computer science and mathematics) and more in the applications. For instance, right now I type this I am sitting in what is, last I checked, the tallest modular building in the world: parts assembled at factory offsite, and trucked in by crane. In other construction techniques, we can see things like 3-D printing, in variants that range from "extruding concrete in boring square shapes on the foundation" to "laser-sintering alloys into exciting new organic designs".
There are exciting new materials, as well; would you consider building with cross-laminated timber? Would you build a plane with carbon fiber? Okay, how about one with a maneuvering characteristics augmentation system?
(POSTSCRIPT: Just checked, not the tallest anymore.)
There are exciting new materials, as well; would you consider building with cross-laminated timber? Would you build a plane with carbon fiber? Okay, how about one with a maneuvering characteristics augmentation system?
(POSTSCRIPT: Just checked, not the tallest anymore.)
Was about to ask you if HN wasn't blocked in China :) . I guess you're in London then.
No, I left London for Brexit issues. I'm in the formerly-tallest one in New York.
> I have to remind myself that in "real" engineering there are (in theory) no surprises for the well understood physical processes at work.
That's not true. Tons of sht goes wrong in civil engineering projects. Like the ground moving, or it is not strong enough to support your building, or the workers bailing on you, or suppliers changing the product, or suppliers delaying a shipment, or suppliers going bankrupt, etc...
I think the difference is that it is mostly* redoing the same thing over and over again with minor challenges overall. Whereas in software development you are starting new every time for every new project.
That's not true. Tons of sht goes wrong in civil engineering projects. Like the ground moving, or it is not strong enough to support your building, or the workers bailing on you, or suppliers changing the product, or suppliers delaying a shipment, or suppliers going bankrupt, etc...
I think the difference is that it is mostly* redoing the same thing over and over again with minor challenges overall. Whereas in software development you are starting new every time for every new project.
Likewise "nuclear plant phenomenology".
I oscillate between that feeling and the realization that in software, you usually stay on a layer without never really minding the numerous layers under yours, that work flawlessly despite huge complexity.
Transistors don't misfire, CPUs don't miss an operation, firmware invisibly and reliably handle all the internal packets of the motherboard, the screen refreshes millions of pixels every 16 ms. All of this relies on the work of thousands if not millions of people who have never meet each other but whose piece of work communicate flawlessly with each other.
Transistors don't misfire, CPUs don't miss an operation, firmware invisibly and reliably handle all the internal packets of the motherboard, the screen refreshes millions of pixels every 16 ms. All of this relies on the work of thousands if not millions of people who have never meet each other but whose piece of work communicate flawlessly with each other.
As an embedded software engineer, my only response to this is that sometimes I'm surprised anything works at all. Bugs in silicon do exist. Often there's nothing a supplier can do about it. Either you find a different part or find a workaround at a higher level.
Oh yeah, or metastability[1] when crossing different clock domains. The fact that it works by raw statistics(just add more flops until the chance is under some threshold) was definitely one of those surprising moments.
[1] https://en.wikipedia.org/wiki/Metastability_(electronics)
[1] https://en.wikipedia.org/wiki/Metastability_(electronics)
In the grand scheme of things, things that work (s.a life) are an unexplainable outlier.
Even for life one wonders. If you look at life's history. Life gets created, gets to the point where we pretty much have modern bacteria, single celled organisms. That took somewhere between 100 and 300 million years. They conquered the planet and ...
And then nothing. There was variation in the cells, sure, but not really all that much (also we can't really tell). As far as we can tell no multicellular life, no great advances, nothing, other than continued existence. No spreading further. No evolution towards more complexity. Muddling along at best. Total pause at worst.
900 million years of it. Maybe more.
Why ?
And then nothing. There was variation in the cells, sure, but not really all that much (also we can't really tell). As far as we can tell no multicellular life, no great advances, nothing, other than continued existence. No spreading further. No evolution towards more complexity. Muddling along at best. Total pause at worst.
900 million years of it. Maybe more.
Why ?
The next major step in evolution was sexual reproduction. That allows different advantageous mutations to be combined into a single organism. In other words, it allows features to evolve in parallel rather than relying on a single lineage to get everything right.
Agreed. For a ~2.5 billion years project, the deliverable is not that impressive.
But the fact that you're here, conversing on something worldwide is insane.
> Bugs in silicon do exist. Often there's nothing a supplier can do about it.
I learned this the hard way with my 1U Intel Atom C2000 series server. Completely bricked due to a bug in the CPU.
I learned this the hard way with my 1U Intel Atom C2000 series server. Completely bricked due to a bug in the CPU.
Oof. That was an interesting one, too -- as best as I can tell, something was wrong with the pin driver for the LPC bus clock, and it would degrade over time as it was used.
As others have mentioned, there's a big gulf between "works well enough that you don't notice the problems very often" and "never fails". Screens work OK in the happy normal path, but as soon as you look into things like DisplayPort chaining and HDMI-CEC you find all sorts of incompatibilities.
> Transistors don't misfire, CPUs don't miss an operation
This relies on a lot of testing. We throw the misfiring ones away at the factory. This may be over half the chips: https://www.pcgamesn.com/amd/zen-2-ryzen-3000-cpu-yield-70-p... (AMD are doing well at 70% pass rate but Intel are throwing away more than half their dies!)
In aerospace or high-alpha-radiation environments, people can use "lockstep" processors (e.g. TI Hercules) that can cope with misfires.
> Transistors don't misfire, CPUs don't miss an operation
This relies on a lot of testing. We throw the misfiring ones away at the factory. This may be over half the chips: https://www.pcgamesn.com/amd/zen-2-ryzen-3000-cpu-yield-70-p... (AMD are doing well at 70% pass rate but Intel are throwing away more than half their dies!)
In aerospace or high-alpha-radiation environments, people can use "lockstep" processors (e.g. TI Hercules) that can cope with misfires.
I'm pretty sure that e.g. on such a big ship we saw in the video above there are plenty of "misfirings" on a lower level of abstraction: pipes need to be replaced, computers or electronics not working correctly, out of date life saving equipment that needs to be replaced etc.
In the end, I feel it's quite comparable to software running on layers of layers of abstraction being maintained by the respective experts in their fields (testing, CPU designers, driver implementers, OS maintainers, etc.).
In the end, I feel it's quite comparable to software running on layers of layers of abstraction being maintained by the respective experts in their fields (testing, CPU designers, driver implementers, OS maintainers, etc.).
I never said the work on every layer is easy! Quite the contrary! I know how painful it is to write realtime software so I am in awe that firmware can be written well enough so that you can rely on them as much as we do!
>Transistors don't misfire, CPUs don't miss an operation, firmware invisibly and reliably handle all the internal packets of the motherboard
Copy and manipulate any large data set on standard desktop and then on a server with ECC ram and compare the results. All that stuff happens and we go through a lot on the high end to mitigate it.
Copy and manipulate any large data set on standard desktop and then on a server with ECC ram and compare the results. All that stuff happens and we go through a lot on the high end to mitigate it.
> CPUs don't miss an operation
Unfortunately, once you deploy your software at scale you discover that some CPUs do in fact miss operations. See https://bugs.chromium.org/p/chromium/issues/detail?id=968683 for example, which has also been observed in Firefox crash telemetry (e.g. see https://bugzilla.mozilla.org/show_bug.cgi?id=1593228 and https://bugzilla.mozilla.org/show_bug.cgi?id=1553380#c2 and so forth).
Now CPUs do mostly work; we're talking about single-digit numbers of crashes per day across the thousands of people who run Firefox nightlies. But I wouldn't want to trust a plane's avionics to this particular CPU model, for sure.
Unfortunately, once you deploy your software at scale you discover that some CPUs do in fact miss operations. See https://bugs.chromium.org/p/chromium/issues/detail?id=968683 for example, which has also been observed in Firefox crash telemetry (e.g. see https://bugzilla.mozilla.org/show_bug.cgi?id=1593228 and https://bugzilla.mozilla.org/show_bug.cgi?id=1553380#c2 and so forth).
Now CPUs do mostly work; we're talking about single-digit numbers of crashes per day across the thousands of people who run Firefox nightlies. But I wouldn't want to trust a plane's avionics to this particular CPU model, for sure.
> Transistors don't misfire, CPUs don't miss an operation
(And if they do, that's usually solved by procurement, warranty or is otherwise someone else's problem.)
(And if they do, that's usually solved by procurement, warranty or is otherwise someone else's problem.)
> Transistors don't misfire, CPUs don't miss an operation, firmware invisibly and reliably handle all the internal packets of the motherboard, the screen refreshes millions of pixels every 16 ms. All of this relies on the work of thousands if not millions of people who have never meet each other but whose piece of work communicate flawlessly with each other.
I don't get it. Is this supposed to be sarcasm?
I don't get it. Is this supposed to be sarcasm?
I think it's just a slightly optimistic view of reality.
And all this wonder of technology ruined because a “developper” built a SQL injection vulnerability in the script that runs at the very top!
Don't forget the whole reason the heavy lift ship was being used was because of badly designed bearings on this cruise ship's azimuth thrusters combined with the local drydock being out of commission because of two cranes collapsing on another cruise ship undergoing repairs at the time.
So in just this story we have a maintenance failure (bearings) and two critical failure (cranes) in physical engineering.
So in just this story we have a maintenance failure (bearings) and two critical failure (cranes) in physical engineering.
> So in just this story we have a maintenance failure (bearings)
They are replacing the bearings on all the azipods, which tells us this is a design and engineering failure rather than a maintenance failure.
They are replacing the bearings on all the azipods, which tells us this is a design and engineering failure rather than a maintenance failure.
> I’m glad that software is invisible, mostly
But that also makes it somewhat intangible and the ability to analyze, test and observe a large software construct relies on the mental capacity to read and grasp units of code and its complex interactions. Once components start messaging with each other and cross-influence their state you quickly enter the realm of complexity theory and tight control of information flow is the only way to guarantee some degree of predictable outcomes.
When I see these ship assembly videos, it's very tough engineering and often novel territory but you got something in your hands, you see the parts move and can measure their forces and evaluate interactions. Every nut has a checkbox, but code lines don't.
But that also makes it somewhat intangible and the ability to analyze, test and observe a large software construct relies on the mental capacity to read and grasp units of code and its complex interactions. Once components start messaging with each other and cross-influence their state you quickly enter the realm of complexity theory and tight control of information flow is the only way to guarantee some degree of predictable outcomes.
When I see these ship assembly videos, it's very tough engineering and often novel territory but you got something in your hands, you see the parts move and can measure their forces and evaluate interactions. Every nut has a checkbox, but code lines don't.
> Every nut has a checkbox, but code lines don't.
That’s part of the problem. Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it. This is more about the process of development than the artifacts.
That’s part of the problem. Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it. This is more about the process of development than the artifacts.
> Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it
I've literally never worked in a project like this. It's always "here's some general idea of what we want, with a couple of hard constraints. Build it however it makes sense to you, and we'll change anything we don't like after we see it." The only exception I can think of is data import from a known file format or API.
I've literally never worked in a project like this. It's always "here's some general idea of what we want, with a couple of hard constraints. Build it however it makes sense to you, and we'll change anything we don't like after we see it." The only exception I can think of is data import from a known file format or API.
It's very easy to explain to someone why blowing a hole in their bedroom wall to put an extension cord through it is a bad idea. On the other hand, try explaining to your product team that building a certain feature in 2 weeks will require doing the equivalent of that, and they won't see any issues with it.
This is the problem with building software. It's intangible and non-developers have a very hard time understanding the tradeoff of doing something "hacky" vs doing it right.
This is the problem with building software. It's intangible and non-developers have a very hard time understanding the tradeoff of doing something "hacky" vs doing it right.
> Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it.
lolnope
Or at least, if there is such a specification, it's never in a single organized form but scattered around the tickets, emails, postit notes and memories of the team members. And filled with assumptions on what's expected.
Only the most complicated, expensive and safety-critical systems get that kind of treatment. At which point people start realising that the requirements engineering is actually one of the most difficult parts for business applications. Some projects have collapsed with millions spent before writing any code, simply trying to untangle the requirements.
lolnope
Or at least, if there is such a specification, it's never in a single organized form but scattered around the tickets, emails, postit notes and memories of the team members. And filled with assumptions on what's expected.
Only the most complicated, expensive and safety-critical systems get that kind of treatment. At which point people start realising that the requirements engineering is actually one of the most difficult parts for business applications. Some projects have collapsed with millions spent before writing any code, simply trying to untangle the requirements.
> ...requirements engineering is actually one of the most difficult parts for business applications. Some projects have collapsed with millions spent before writing any code, simply trying to untangle the requirements.
This gives me a terrible idea:
Put https://xkcd.com/1737/ (Scale) and continuous integration into a blender.
Stand up a whole new team to build out your Ultimate Last Widget, from first principles, every 5 years. Have maybe 5 teams running continuously.
Each team operates asynchronously from all the others and there is no blocking.
Maybe teams can freely exchange ideas, and maybe workers can switch teams at will.
Hmm. This would unfortunately result in a Super-Team™ that knows how to create a new Widget X from scratch in (eventually) record time, but not necessarily maintain it.
And there's the good question of whether squishy real-world influences would cause the last of the teams to succumb to second-system effect...
Wow this is hard
This gives me a terrible idea:
Put https://xkcd.com/1737/ (Scale) and continuous integration into a blender.
Stand up a whole new team to build out your Ultimate Last Widget, from first principles, every 5 years. Have maybe 5 teams running continuously.
Each team operates asynchronously from all the others and there is no blocking.
Maybe teams can freely exchange ideas, and maybe workers can switch teams at will.
Hmm. This would unfortunately result in a Super-Team™ that knows how to create a new Widget X from scratch in (eventually) record time, but not necessarily maintain it.
And there's the good question of whether squishy real-world influences would cause the last of the teams to succumb to second-system effect...
Wow this is hard
Some defence projects end up being run like that. Although it tends to operate in reverse: project A has been running to produce the Ultimate Fighter for 20 years, but that's taken too long, so a slightly scaled back project for Acceptable Fighter is launched. Ten years later, neither is finished, so project Desperate Stopgap fighter is launched. Another few years on and an actual war breaks out, so Obsolete Fighter With Guns Taped To It is used to do the actual fighting until the losses are unacceptable and all the preceding teams are galvanised into producing actual results.
(e.g. https://en.wikipedia.org/wiki/The_Pentagon_Wars , but also applied to a lot of early WW2 and things like the UK V-bombers)
(e.g. https://en.wikipedia.org/wiki/The_Pentagon_Wars , but also applied to a lot of early WW2 and things like the UK V-bombers)
The V bombers were more a case of missiles? Oh, we never thought of those, let's make an inspiring Pathe newsreel and pretend they are still cutting edge.
Though your tale is a pretty close summary of the political story underneath cancelling Supersonic Harrier and TSR2 for F111, and the Buccaneers and Phantoms we eventually ended up with. Though you missed the opportunity beloved of politicians to merge Acceptable Fighter with Acceptable Naval Fighter into one aircraft and end up with White Elephant that barely flies, and certainly doesn't float. :)
Though your tale is a pretty close summary of the political story underneath cancelling Supersonic Harrier and TSR2 for F111, and the Buccaneers and Phantoms we eventually ended up with. Though you missed the opportunity beloved of politicians to merge Acceptable Fighter with Acceptable Naval Fighter into one aircraft and end up with White Elephant that barely flies, and certainly doesn't float. :)
> and behavior of a program is well specified enough that we should have a checkbox (test?) for it.
Thanks, I needed a good laugh ;-)
Thanks, I needed a good laugh ;-)
So if you are able to read and understand a single page of code, then you can almost definitely understand the overall design of a system and the flow of its operations. But if you are tasked with analyzing a system of hundreds of pages of code, you are likely to struggle with some of the aspects of code, such as its semantics, its design and its behavior.
Well, that's true for the most common "vertical software" most developers create but it's not true for the inner parts like the kernel, system libraries etc, nor for the firmware or the hardware. That ship is a wonderful piece of engineering but so it is the smartphone you have in your pocket!
And to go on, software "at scale" like Google's, Facebook's etc, keeping in mind only the technical merit, is just as awesome as that ship if you think about it. For example, searching billions of documents in just a fraction of a second, wherever you are and by millions of people at the same time, isn't a wonderful piece of engineering too?
Mechanical engineering projects have thousands of parts. About equivalent to a chip with a shift register and a serial port. Or a piece of software with a small array of integer variables and a loop, compiled to assembly language.
Not so say they aren't challenging. But software is billions of parts, and its freaking incredible we can get anything to work at all.
Not so say they aren't challenging. But software is billions of parts, and its freaking incredible we can get anything to work at all.
I'm sure a lot of software was used in the design and production of the ship. CAD, FEA, CFD, and then all the logistics, and financial planning...
Iteration happens in mechanical designs too, but a lot of that is done virtually before physical parts are made. In software there is no distinction between virtual code and real code. We make a somewhat artificial distinction by having official releases that have hopefully gone through more testing.
Iteration happens in mechanical designs too, but a lot of that is done virtually before physical parts are made. In software there is no distinction between virtual code and real code. We make a somewhat artificial distinction by having official releases that have hopefully gone through more testing.
If every IT project was developed as ships and buildings are, we would celebrate the release of the first spreadsheet application and whatever was the most basic predecessor to ARPAnet about now.
Different projects have different priorities. If my app crashes, no one's going to die, but if I'll waste time on formal verification of my database layer, quite a few people will end up losing their jobs and/or investments.
Different projects have different priorities. If my app crashes, no one's going to die, but if I'll waste time on formal verification of my database layer, quite a few people will end up losing their jobs and/or investments.
But are you seeing the thousands of flaws? These physical projects dont go perfectly. A new cruise ship will have thousands of things wrong with it initially, so too with large lifting ops. Just because the massive thing moves doesnt mean the enineering was seemless. Thr skill is in accepting and working around inevitable flaws, unknown unknowns, in a manner not very different than software.
Likely in some way also to do with the amount of moving parts and it's complexity, not saying the dry dock is simple, but compared to many "invisible" and prone to break parts due to dependence on one another, code can be quite harsh.
When one section of the dock doesn't work it won't suddenly flip upside down as could be the case for code.
When one section of the dock doesn't work it won't suddenly flip upside down as could be the case for code.
> suddenly flip upside down
https://catless.ncl.ac.uk/Risks/3.44.html (1986): early F-16 software would flip the plane upside down on crossing the equator :)
https://catless.ncl.ac.uk/Risks/3.44.html (1986): early F-16 software would flip the plane upside down on crossing the equator :)
Wh..oa.
From the above page:
> From Dagens Nyheter [Stockholm], Aug. 22, 1986. My translation, abridged.
> The chairman of the governmental data- and public-access committee [offentlighetskommitt'en], Carl Axel Petri, rejects the criticisms which have recently been brought by the moderate party [conservative] and folk-party [liberal conservative] concerning sales of personal information from computer data banks.
> "It is important to quickly get a law that stops general sales. We have allowed some exceptions, nine specified computer companies, but even their sales shall, in the future, be controlled by parliament. Nobody should be allowed to earn money by [selling] personal information. Sales should have a public interest, in principle, the new law will forbid sales" said Petri. ...
I'm removing a bit of context from the above, but it's nice/interesting that this was being discussed in this way back then. Ha.
From the above page:
> From Dagens Nyheter [Stockholm], Aug. 22, 1986. My translation, abridged.
> The chairman of the governmental data- and public-access committee [offentlighetskommitt'en], Carl Axel Petri, rejects the criticisms which have recently been brought by the moderate party [conservative] and folk-party [liberal conservative] concerning sales of personal information from computer data banks.
> "It is important to quickly get a law that stops general sales. We have allowed some exceptions, nine specified computer companies, but even their sales shall, in the future, be controlled by parliament. Nobody should be allowed to earn money by [selling] personal information. Sales should have a public interest, in principle, the new law will forbid sales" said Petri. ...
I'm removing a bit of context from the above, but it's nice/interesting that this was being discussed in this way back then. Ha.
Yup, it's not a new idea: http://www.legislation.gov.uk/ukpga/1984/35/contents/enacted .. dating back to 1984, when access would have been over 300 baud modems.
The fact that this was largely ineffective against giant US multinationals that didn't respect local law is what lead to the giant international reach of GDPR.
The fact that this was largely ineffective against giant US multinationals that didn't respect local law is what lead to the giant international reach of GDPR.
Thanks for that! Now I'll have sweaty palms going past the equator in airplanes.
It's good for everyone in their career to read some of RISKS. Reduces your chance of writing a self-driving car that doesn't see pedestrians. And many of the reports have an entertaining style to them. But if you inhale too much of it you'll want to go live in a computerless cabin in a computerless wood.
I found your choice of words quite amusing because the dock really could simply flip upside down!
Would be fun to calculate what is required for the dock to actually flip, the scale of it is huge, so you would see it coming a mile away no?
I’m thinking you would see it coming a mile away, but could you pump water quickly enough to stop it once the centre of gravity got away from you?
Which actually happened in the late 19th century ships where laid down and where obsolete within 2 or 3 years.
In some cases the ship was laid down and was obsolete when launched.
An for Fankenships take a look at French pre dreadnaughts - "when hotels go to war" as some on YouTube put it
In some cases the ship was laid down and was obsolete when launched.
An for Fankenships take a look at French pre dreadnaughts - "when hotels go to war" as some on YouTube put it
[deleted]
Came to say the same thing, my only hope is that IT/Software is relatively immature compared to traditional engineering.
One thing is most of the people that worked on the gnarly parts of these large ships will have a decent engineering education behind them that teaches them the foundations.
This is missing in a lot of software developers nowadays, and we as an industry, don't really see the problem with this... I see people applying for jobs with 8 weeks education in a bootcamp and think they should get a job as a software developer... This is normal, and we are ok with this?
Rather than making our education faculties for computer students more rigorous it seems we are infantilising them.
Garbage in, garbage out. I don't see a path our industry getting better or more mature, if anything I reckon it's going to get way worse before it gets better.
This is missing in a lot of software developers nowadays, and we as an industry, don't really see the problem with this... I see people applying for jobs with 8 weeks education in a bootcamp and think they should get a job as a software developer... This is normal, and we are ok with this?
Rather than making our education faculties for computer students more rigorous it seems we are infantilising them.
Garbage in, garbage out. I don't see a path our industry getting better or more mature, if anything I reckon it's going to get way worse before it gets better.
You don't need a Rigorous Engineering Background™ to make a cute little website for every mom-and-pop business who needs something a little custom. You need to quickly assemble some off-the-shelf components that work well and probably won't collapse, because the alternative is that they cannot afford anything.
The 8-week-bootcamp graduate is not going out and working for Boeing, MCAS memes notwithstanding.
The 8-week-bootcamp graduate is not going out and working for Boeing, MCAS memes notwithstanding.
I'm a self-taught dev with a few years under my belt, but I got to apprentice as a dev to get to a hireable position.
I firmly believe apprenticeship is the solution. Software engineering is constantly evolving, so pair up a junior with a senior who knows how to /think/, and go from there
We have a model for a fully mature mission-critical software development process. https://www.fastcompany.com/28121/they-write-right-stuff
Even without considering the recent advancements in areas like autonomous marine systems or fuel consumption optimization, the amount of software required to even get ships like that of the dock is insane.
The ship is a lot simpler by many measures than something like Linux.
In software the experimentation cost is very small so it makes sense that there are a lot more prototypes and abandoned projects etc.
In software the experimentation cost is very small so it makes sense that there are a lot more prototypes and abandoned projects etc.
The current top comment mentions that the OTHER ship needs all bearings replaced after only 3 years, due to some major manufactoring fault.
So it is not only software that produce faulty products.
So it is not only software that produce faulty products.
Huh... most of them has been built by using complex software and a lot of them is using software too work. Webdev != all software engineering.
software isn't steel. It's more complex.
Think about everything that went into you posting that message.
OSI stack 1-7, your computer or phone. Keyboard, the browser you used. The php / database on ycombinator.
There's lots of successful software. And there are pleanty of bad ships that blow out budgets.
The consumer-grade industry moves too quickly to produce stuff like this. There are still mainframes running, after all.
All the software I use on a daily basis is pretty much good enough. I'd be thrilled if everybody decided to freeze development of new features and instead dedicate all their resources to fixing bugs for a few years.
This lift was due the large dry dock in Freeport, Bahamas being unavailable after an accident with Oasis Of The Seas.
Oasis Of The Seas was over the capacity of the dry dock, but was still docked. It was not lifted completely out of the water.
The dry dock broke under the ships weight causing the walls of the dry dock to collapse onto the ship. A crane collapsed onto the stern. Remarkably it didn't capsize. There where some non-life-threatening injuries.
http://www.tribune242.com/news/2019/apr/01/injuries-after-oa...
Oasis Of The Seas was over the capacity of the dry dock, but was still docked. It was not lifted completely out of the water.
The dry dock broke under the ships weight causing the walls of the dry dock to collapse onto the ship. A crane collapsed onto the stern. Remarkably it didn't capsize. There where some non-life-threatening injuries.
http://www.tribune242.com/news/2019/apr/01/injuries-after-oa...
I know it's supposed to be basic, but it still blows my mind that those two things still weigh less than the water they displace...
> weigh less than the water they displace...
Well, they weigh exactly the same as the water they displace. :)
But I know what you mean. I think the cause is that we intuitively underestimate the weight of water. Probably because we normally deal with it in small amounts only. But water is pretty heavy.
Well, they weigh exactly the same as the water they displace. :)
But I know what you mean. I think the cause is that we intuitively underestimate the weight of water. Probably because we normally deal with it in small amounts only. But water is pretty heavy.
> But water is pretty heavy.
A 20 gallon fish tank, which is a pretty small fish tank (1'x2'x1.25' or 2.5 cubic feet), weights 167 pounds - so about as much as a person.
A 20 gallon fish tank, which is a pretty small fish tank (1'x2'x1.25' or 2.5 cubic feet), weights 167 pounds - so about as much as a person.
Fun fact: thanks to a browser-addon, I read this as
>A 75,71 L fish tank [...] weights 75,75kg
:-)
>A 75,71 L fish tank [...] weights 75,75kg
:-)
Haha, cool, is it Everything Metric (Auto Unit Converter)?
https://addons.mozilla.org/es/firefox/addon/everything-metri...
https://addons.mozilla.org/es/firefox/addon/everything-metri...
In comparison, 2.5 cubic feet of steel weighs slightly more than 1200 lbs.
Or try to tip over a kid's paddling pool that's full. It's surprisingly hard.
Aren't people 70 water by mass?
Yeah. And you can approximate many common materials as weighing "close enough" to water, if you're doing back of the envelope calculations. Organisms in general, food, building materials. Oil is about 90% the density of water. Plastic and wood probably vary from 50% to 130%. Metal and rock are obviously heavier, so throw in a multiplier.
It's great because you can just convert grams to milliliters or cubic centimeters (water is 1g/mL) and fudge it as necessary.
It's great because you can just convert grams to milliliters or cubic centimeters (water is 1g/mL) and fudge it as necessary.
If you press a human into a fish tank sized box it will weigh about the same, yes.
People are surprisingly heavy too
[deleted]
The scale of this is so hard to comprehend. Seeing the people standing on the dry-dock below the ship, its just mind-blowing to see how massive both of these things are.
How strong do those pumps need to be to drain the ballast tanks and raise the ship after she’s got her new cargo on deck? I’m having trouble wrapping my head around how all this would work. Any Merchant Marines out there?
Naval architect here. As other commenters have noted the size of the pumps isn’t really the issue here - you can have as many as you want it really depends on the time you have available.
For me, the cool things about this are the size of the installed power and the stability problem in having one submerged object with multiple half empty ballast tanks lift up another object with multiple tanks.
The BOKA Vanguard has an installed power of 27000kW, split between two main diesels and two auxiliaries. This is slightly more than a Los Angeles class nuclear submarine, which goes much faster (perhaps 2x according to wiki) underwater - very much a different resistance problem. There are two 35 tonne and 65 tonne generators/engines. These are not small pieces of equipment. That’s what gets me about these ships - they are on another level of huge.
The stability problem is a significant challenge. You can see in the video that they did it on a flat day. Being able to coordinate the pumping of multiple ballast tanks to make sure that both ships remain upright is another cool thing here. Look up the “free surface effect” if you want to learn about that particular challenge.
Sources; various Wikipedia pages and Wärtsilä technical sheets.
For me, the cool things about this are the size of the installed power and the stability problem in having one submerged object with multiple half empty ballast tanks lift up another object with multiple tanks.
The BOKA Vanguard has an installed power of 27000kW, split between two main diesels and two auxiliaries. This is slightly more than a Los Angeles class nuclear submarine, which goes much faster (perhaps 2x according to wiki) underwater - very much a different resistance problem. There are two 35 tonne and 65 tonne generators/engines. These are not small pieces of equipment. That’s what gets me about these ships - they are on another level of huge.
The stability problem is a significant challenge. You can see in the video that they did it on a flat day. Being able to coordinate the pumping of multiple ballast tanks to make sure that both ships remain upright is another cool thing here. Look up the “free surface effect” if you want to learn about that particular challenge.
Sources; various Wikipedia pages and Wärtsilä technical sheets.
> “free surface effect”
I remember this from the sinking of MS Herald of Free Enterprise, a ferry which set off with its doors open: https://en.wikipedia.org/wiki/MS_Herald_of_Free_Enterprise
A fairly small amount of water washing about the car deck was enough to capsize the ship.
I remember this from the sinking of MS Herald of Free Enterprise, a ferry which set off with its doors open: https://en.wikipedia.org/wiki/MS_Herald_of_Free_Enterprise
A fairly small amount of water washing about the car deck was enough to capsize the ship.
Is this something that's similar to what you're describing? https://www.youtube.com/watch?v=7np9rhQmNTU
It's something a little bit bigger, but it gives you a good idea of what's used to propel ships.
Why do marine engines weigh so much for that power? An airplane uses ~100MW (depending on how you want to calculate it) but obviously its engines don't have a combined weight of 200 tonne.
Aircraft engines are designed to be light, and sacrifice low cost and the ability to burn cheap diesel fuel for that.
Ship engines are the way round: their weight doesn't matter much, but it matters that they use the cheapest fuel possible.
Ship engines are the way round: their weight doesn't matter much, but it matters that they use the cheapest fuel possible.
Exactly. In fact, for some applications GE are using modified aircraft turbines on ships: https://fas.org/man/dod-101/sys/ship/eng/lm2500.htm
Those are for military use, where speed matters but money is basically unlimited.
Those are for military use, where speed matters but money is basically unlimited.
Money is unlimited, but fuel efficiency isn't just about money for the military. More fuel usage means more supply lines. That's less of an issue for navies than armies but still important.
I see your point but aircraft engines can burn diesel, and many small power plants and backup power stations use aircraft engines in stationary services with diesel fuel.
> Aircraft engines are designed to be light, and sacrifice low cost and the ability to burn cheap diesel fuel for that.
Small correction: aircraft engines generally use kerosene-based fuels (Jet A-1, Jet B). Also cost-wise, aircraft-grade kerosene costs more relative to other uses of kerosene since those applications can tolerate kerosene of lower quality than aircraft-grade kero.
https://en.wikipedia.org/wiki/Aviation_fuel
Small correction: aircraft engines generally use kerosene-based fuels (Jet A-1, Jet B). Also cost-wise, aircraft-grade kerosene costs more relative to other uses of kerosene since those applications can tolerate kerosene of lower quality than aircraft-grade kero.
https://en.wikipedia.org/wiki/Aviation_fuel
The entirety of the drive train is huge. You have to turn two propellers which have to propel a ship weighing thousands of tonnes. To produce the necessary torque you need to have some big components. The supporting infrastructure you need to heat and circulate the fuel, then to supply it to the engines is another thing too.
Gas turbines are much smaller but would be unsuitable for this particular application as they have good efficiency only at high loads. The range of loads this is used for would mean they are unsuitable.
Interesting! Thanks. The stability problem does seem extreme, which is what I assumed all the tugs are around for. One of the other thoughts I had was ... what possesses someone to build something like this? It obviously has more uses than dealing with disabled cruise ships, but not many more right? What’s the ROI on something like this?
As I recall, the captain of the docking ship (the smaller ship) relinquishes control when the bow crosses the dry dock's threshold. Does that apply for these open ocean vessels as well?
I think it's going to be as soon as you lose your ability to maneuver - i.e. as soon as you moor to another vessel in this case.
The pumps are probably pretty large just so it doesn’t take that long. It’s more of a large volume of water problem than a push it forcefully problem if that makes any sense. There’s something called hydraulic head or pump head that determines how high a pump can pump. It’s sort of a trade off between height it can pump and flow rate. The pumps used are more than likely centrifugal pumps rather than positive displacement.
As an aside on pumps, on the ship I work on, we have two fire pumps that are run off 11kV motors, they have to pump a large volume of water potentially pretty high for a deluge/sprinkler system. Our normal ballast pumps are 480v and when they come on the lights flicker but we don’t do much ballasting of the same type as the heavy lifts, it’s more for trim and heel.
There are also considerations that a partially filled tank can lead to instability (free surface effect) and they have a definite sequence that they must pump out the tanks to prevent excess stress on both the vessels (on ships the bending is called hogging and sagging). Some ships if they are loaded/ballasted in a certain configuration can actually potentially break in half.
If time is no object, you could do it yourself with a straw. The pumps only needs to be powerful to drain the ballast tanks quickly.
Not strong at all theoretically speaking. All you have to do is have enough headroom to pump higher than water level for a given diameter of pipe and have an air intake to match which is higher than water level. You could take forever with a strong pond pump and achieve the same effect.
I designed full-building hydroponics systems. You get similar issues with things like vacuum pressure in tanks causing your pumps to not work properly.
I designed full-building hydroponics systems. You get similar issues with things like vacuum pressure in tanks causing your pumps to not work properly.
Keep in mind that those tanks aren't under vacuum or have any special physics at play - you could have a guy sitting in the tank bailing them out with a wooden bucket.
He would have to run up a lot of stairs though. But with prefect absence of leakage (a precondition for the bucket-weilder's success was well), proper rain protection and good ventilation it might be just as fast for all practical considerations (not fast at all) to just stand back and allow evaporation to do the job.
What I find even more impressive than the engineering dimension is that a market for those things exist, and how easily the the basic financial craftsmanship of playing through price/demand curves and ROI apparently scales. Because the business side looks so amazingly calm from the outside, entirely not like some Isambard Kingdom Brunel cable laying adventure or a 21st century version thereof (seriously, make a movie about that guy and get Musk to play him)
What I find even more impressive than the engineering dimension is that a market for those things exist, and how easily the the basic financial craftsmanship of playing through price/demand curves and ROI apparently scales. Because the business side looks so amazingly calm from the outside, entirely not like some Isambard Kingdom Brunel cable laying adventure or a 21st century version thereof (seriously, make a movie about that guy and get Musk to play him)
This ladies and gentlemen is what engineering is sometimes about - making something that seems at first look impossible, possible.
I'm also struck by the engineering that has gone into videography drones over the past decade. No one would have bothered to make this video 10 years ago, but thanks to the various technology advances (batteries, motors, flight controllers, etc) we now have an easy and "cheap" way to view stuff like this from amazing perspectives that wouldn't have been practical in the past.
[deleted]
I find it interesting that a ship can both float in the water and sit on the bottom of its hull. It has to be built for two very different patterns of mechanical stress!
If you watch a boat in rough seas they need to be far stronger than a building across a much wider range of stresses. So, it probably starts close to being able to stand up like this just by default. Ex: https://rare.us/rare-news/caught-on-video/new-footage-shows-...
PS: Less seriously, the cruise liner has lifeboats making it it a boatboat. (https://xkcd.com/2043/) Making this a boatboatboat for when you want to ship the ship shipping your boats in a boat via ship on a ship shipping. This lets you boat around on your boat on a boat on a boat.
PS: Less seriously, the cruise liner has lifeboats making it it a boatboat. (https://xkcd.com/2043/) Making this a boatboatboat for when you want to ship the ship shipping your boats in a boat via ship on a ship shipping. This lets you boat around on your boat on a boat on a boat.
Ah, but has to be built. That is done in the dry dock.
There’s something disturbing about a large underwater structure lurking in the deep. I’m happy the bed emerged. Put me at ease.
megalohydrothalassophobia
Stuff like this really puts my work into perspective. It makes my hardest problems seem like trivialities compared to lifting a cruise ship out of the ocean.
And yet your average engineer (barring oil and gas) in the marine industry will never earn as much as a software engineer.
I employee a number of high caliber software engineers (MS and PhD level folks). I'm pretty sure there's a balance between interestingness and pay. If you are an eningeer in adtech, you should reasonably expect to get paid in gold bars. We should make it expensive for companies to be in that business. If you are solving cancer, lifting giant boats, or going to Mars, then you have a much more interesting problem to work on.
Should we pay those folks more? Sure? But they like doing the work. Perhaps we should also demand far higher salaries from adtech companies. Like, $10M annual.
Should we pay those folks more? Sure? But they like doing the work. Perhaps we should also demand far higher salaries from adtech companies. Like, $10M annual.
On the other hand, engineers working at self driving cars at Waymo earn much more than engineers making CRUD apps at random non-tech companies.
The pay discrepancy has nothing to do with interestingness. It's just that total demand for software engineers is extremely high -- programming has become almost like accounting in that virtually every business that's not very small needs some -- and there are a good number of massively profitable tech and tech-oriented companies that can and must compete for strong coding talent.
The pay discrepancy has nothing to do with interestingness. It's just that total demand for software engineers is extremely high -- programming has become almost like accounting in that virtually every business that's not very small needs some -- and there are a good number of massively profitable tech and tech-oriented companies that can and must compete for strong coding talent.
High end research has always been able to attract tier one candidates to work for them at low pay as they want to do a PHD.
Unfortunately this depresses pay -when I started at a world leading hydrodynamics research in the UK in the late 70's I was paid about 1/3 of the equivalent grade in the civil service!
which is why I left technically interesting programming job and sold my soul to the commerce.
Unfortunately this depresses pay -when I started at a world leading hydrodynamics research in the UK in the late 70's I was paid about 1/3 of the equivalent grade in the civil service!
which is why I left technically interesting programming job and sold my soul to the commerce.
I think you can find interesting problems in the most mundane of subjects, not much meaning though.
> If you are an eningeer in adtech, you should reasonably expect to get paid in gold bars.
Why? It makes no sense.
Why? It makes no sense.
Because those engineers in the marine industry still use software to design those impressive ships, balance the ballast tanks, and successfully complete their jobs.
One rock star earns a lot more than one orchestra member, too. Why? Well, the orchestra member is one of several dozen people. The rock star performs for the same audience, but concentrates his compensation by being one of maybe 5 people performing.
Similarly, the one software engineer produces a lot more per capita than the marine engineer does, by working on problems that don't require so many people.
Similarly, the one software engineer produces a lot more per capita than the marine engineer does, by working on problems that don't require so many people.
Facebook employs over 30k employees.
The parent company of the company who performed this lift employs 11k employees working 900 ships.
I don’t think your analogy makes sense from a “Don’t require so many people” perspective when you look at the numbers tbqh
The parent company of the company who performed this lift employs 11k employees working 900 ships.
I don’t think your analogy makes sense from a “Don’t require so many people” perspective when you look at the numbers tbqh
But if you look at the per capita value of facebook vs this company, facebook produces a lot more revenue. In 2018 facebook made 55.8 billion[1], that same year boskalis made about 2.8691 billion usd[2]. If facebook has 30k employees that means they make 1.86 million per employee (holy crap) whereas boskalis makes just 236k. So I think the parent commenter makes a fair point.
1. https://investor.fb.com/investor-news/press-release-details/... 2. https://boskalis.com/press/press-releases-and-company-news/d...
1. https://investor.fb.com/investor-news/press-release-details/... 2. https://boskalis.com/press/press-releases-and-company-news/d...
Sure, if we move away from the analogy and into real dollars and cents we can see that certainly the numbers show that Facebook, as a company, has higher revenues both in total and per capita.
But that wasn’t the poster’s point with his analogy. His point was that the boat bro and the software engineer are equally skilled (they’re not - the boat bro is usually more educated/skilled) and the main difference for their pay is that the boat bro is just one amongst many while the software engineer is one of a few. The numbers don’t support this conclusion. In fact, the opposite appears true: software engineers appear to be entirely interchangeable cogs that are employable at scale while the boat bros are specialized tools employed to solve specific problems.
If his argument was that the market has placed a higher value on the software engineer then I wouldn’t have an issue, but that narrative doesn’t feed the Software Mythos. Even the terms selected for the analogy show this desire to self fellate (“Rock Star”).
But that wasn’t the poster’s point with his analogy. His point was that the boat bro and the software engineer are equally skilled (they’re not - the boat bro is usually more educated/skilled) and the main difference for their pay is that the boat bro is just one amongst many while the software engineer is one of a few. The numbers don’t support this conclusion. In fact, the opposite appears true: software engineers appear to be entirely interchangeable cogs that are employable at scale while the boat bros are specialized tools employed to solve specific problems.
If his argument was that the market has placed a higher value on the software engineer then I wouldn’t have an issue, but that narrative doesn’t feed the Software Mythos. Even the terms selected for the analogy show this desire to self fellate (“Rock Star”).
How many audience members does one orchestra member serve?
And how many does the rock star serve?
Now, how many users does one Facebook engineer serve?
The incredibly low ratio of workers to work done in software isn't a secret. People have been making this point for decades.
And how many does the rock star serve?
Now, how many users does one Facebook engineer serve?
The incredibly low ratio of workers to work done in software isn't a secret. People have been making this point for decades.
It makes perfect sense when you look at the business results comparing the two companies.
Facebook currently has over 43,000 employees, they don't have 43,000 engineers however. That number is likely under 10,000 based on their past statements about the company structure.
Facebook has extreme margins. Their gross profit margin last quarter was 82%, their operating profit margin was 41%.
Over the next four quarters Facebook will produce $75b-$80b in sales, with ~$30b in operating profit. They're one of the dozen most profitable companies on the planet.
$3+ million in operating profit per engineer.
Boskalis is worth $3 billion. Their sales for 2018 were about $2.7 billion and they had a tiny $75 million operating profit.
To match Facebook's operating profit per engineer figure, Boskalis can only have 25 engineers. Back in 2015 they had a far better ~$569m in operating profit, at that level they could have perhaps 190 engineers to match the Facebook ratio.
Simply put, Facebook generates enormous profit per engineer. Very few companies match it.
Facebook currently has over 43,000 employees, they don't have 43,000 engineers however. That number is likely under 10,000 based on their past statements about the company structure.
Facebook has extreme margins. Their gross profit margin last quarter was 82%, their operating profit margin was 41%.
Over the next four quarters Facebook will produce $75b-$80b in sales, with ~$30b in operating profit. They're one of the dozen most profitable companies on the planet.
$3+ million in operating profit per engineer.
Boskalis is worth $3 billion. Their sales for 2018 were about $2.7 billion and they had a tiny $75 million operating profit.
To match Facebook's operating profit per engineer figure, Boskalis can only have 25 engineers. Back in 2015 they had a far better ~$569m in operating profit, at that level they could have perhaps 190 engineers to match the Facebook ratio.
Simply put, Facebook generates enormous profit per engineer. Very few companies match it.
You left out:
... while the lifting body is also floating on the ocean.
Incredible machines. Similarly, this one lifting an oil platform;
https://youtu.be/DjD2QSJyqso?t=203
https://youtu.be/DjD2QSJyqso?t=203
This is what I call real engineering. Of course, being a mere software engineer (or so they tell me) I can't but point to the recursive version: https://cdn2.kontraband.com/uploads/image/2019/2/22/preview_...
Wow that's amazing - how do they keep the cruiseliner from toppling over? Just the weight of the hull?
The ship they're lifting? It's pretty flat bottomed so they can just build a small cradle under the ship. There's also some tall yellow support (or maybe access to the interior?) structures on one side in the video.
It sits on blocking. There is typically a line of blocks running along the keel of the ship. Then there are two additional lines of blocks off center line that are shaped to the curve of the hull. These two provide support against toppling with the keel providing center line support. [0]
Usually they're much higher off the bottom of the dry dock.
[0] https://youtu.be/UCHevTrL2Vk?t=24
Usually they're much higher off the bottom of the dry dock.
[0] https://youtu.be/UCHevTrL2Vk?t=24
In one of the cuts there is a view where these tall, yellow, ladder like structures are sitting against the side of the cruiseliner. Those appear to be the supports that prevent the 'captured' ship from toppling onto its side.
If you find this interesting, I highly recommend reading "The Taking of K-129"[1], which tells the story of a CIA project to lift a damaged Russian sub off the deep-ocean floor in the early 70's. It's a really great engineering and project management story.
[1] https://www.amazon.com/dp/B06XVHYDPR
[1] https://www.amazon.com/dp/B06XVHYDPR
>One of the assets acquired through Dockwise helped Boskalis “push back boundaries” in 2018 according to Mr Berdowski; he is referring to the technically challenging, record-setting dry transport of the floating production storage and offloading (FPSO) P-67 from China to Brasil. Weighing a record 90,000 tonnes, the FPSO was transported by the semi-submersible heavy-lift vessel Boka Vanguard, formerly Dockwise Vanguard. With a deadweight capacity of 117,000 tonnes, the Boka Vanguard has a “bowless design” to accommodate offshore structures or vessels that might overhang the bow or stern of the vessel.
https://www.rivieramm.com/opinion/opinion/after-acquisitions...
https://www.rivieramm.com/opinion/opinion/after-acquisitions...
This is great, would love to find more information on what kind of software they use on these ships. No way that was happening manually. Some kind guided software would be best suited for this. Also how long it took them to lift the cruiseliner ?
PLCs are used for most automation. The charting is usually from an ECDIS system. You can use automatic charting. What you're seeing here though is all from being guided by the tug boat.
> No way that was happening manually.
Why do you say that?
Why do you say that?
When all you have is a hammer...
That's amazing. I love watching things like this.
Any idea how much it costs to hire such a ship?
Any idea how much it costs to hire such a ship?
The image on the top is quite misleading: like an iceberg, 90% of the ship is underwater in that photo. The real thing is about as big as the cruise ship; watch the video to get an actual sense of how large it is.
So what exactly is the point of this? Is it more efficient to have the ship be tugged this way than to have it move under its own power?
the local dry-dock is no longer available, they needed to fix something broken in one of the ship's impellers
Oh that makes so much more sense, thank you!
It's a mobile dry dock.
Recently Vimeo became a number one house for me in terms of videos. Its constant ads that you cannot stop or skip that least somewhat of 45 seconds (!) steers me away from YouTube. And quality on Vimeo never disappoints, I mean has there even been low quality vid on Vimeo?
I found a very effective way of eliminating ads completely. https://www.youtube.com/premium
It turns out I can use some of the money I make in my work, to pay other people for their work.
It turns out I can use some of the money I make in my work, to pay other people for their work.
I also eliminate ads completely using ublock. Not everything is vis a vis. If youtube was a bastion of free speech and didn't demonetize controversial creators then I would consider supporting them.
[deleted]
I have YouTube premium as well (which I generally like), but just today noticed it is now showing me ads when the video is embedded on other web sites. Not cool. Have you noticed this?
I've never had this happen. Perhaps those other sites are overlaying their own ads somehow?
No they are YouTube ads, you see the indicator showing when they are going to appear, etc. Happens on all sites with embedded YouTube videos.
Youtube Music also gets you this for free. I didn't know what an Youtube add was until I realized I got this for free.
Just today, YouTube seem to have tweaked their Mobile video playback controls to make skipping forward/back within a video tediously painful.
I've been opening directly in VLC instead. Bonus: no ads.
I've been opening directly in VLC instead. Bonus: no ads.
I just tried that, not realizing that VLC could do it.
Unfortunately, it seems to play 1080p videos at 360p, which, not to be a snob or anything, isn't watchable for me. Well, I'd prefer an ad than a really blurry video.
Unfortunately, it seems to play 1080p videos at 360p, which, not to be a snob or anything, isn't watchable for me. Well, I'd prefer an ad than a really blurry video.
YouTube offers videos in multiple formats for viewing. VLC may have an option to configure your preferred resolution (min/max).
Looks as if that's available for desktop but not the Android app:
https://www.vlchelp.com/how-to-choose-youtube-video-quality/
Otherwise it should default to the best available quality.
youtube-dl, mpv, and mps-youtube are three other options, for which you can either d/l and play, or specify default viewer and/or options.
All three run under Termux on Android.
Looks as if that's available for desktop but not the Android app:
https://www.vlchelp.com/how-to-choose-youtube-video-quality/
Otherwise it should default to the best available quality.
youtube-dl, mpv, and mps-youtube are three other options, for which you can either d/l and play, or specify default viewer and/or options.
All three run under Termux on Android.
If you use Firefox on your phone, you can install uBlock Origin (blocks youtube ads without fail) and the "Video Background Play Fix" addon which allows you to play youtube videos with your screen switched off.
Since you touched the issue: I can't seem to play anything on Vimeo and for a good while (maybe this entire year?).
I think it's related to NoScript/uBlock/Firefox's privacy settings because the only way to get videos to play is to restart my browser with addons disabled.
I think it's related to NoScript/uBlock/Firefox's privacy settings because the only way to get videos to play is to restart my browser with addons disabled.
What errors do you get in the console?
Would it be foolish to use this as a safer way of docking large ships in difficult to navigate ports? You could automate everything about it. Have a series of these ship moving barges moving on a predefined virtual track.
Not foolish but costly, very costly. The infrastructure required for that level of automation is no joke, and you have to run and maintain lots of ships to ship the ships...
that's cool. what happens when the BOKA Vanguard itself requires service?? and when THAT ship requires service!?
reminds me of those super-heavy tow trucks, that tow semi trucks, busses, other max-weight vehicles. but i wonder how THAT vehicle gets towed when it breaks down. i guess they don't, i guess they get airlifted.
reminds me of those super-heavy tow trucks, that tow semi trucks, busses, other max-weight vehicles. but i wonder how THAT vehicle gets towed when it breaks down. i guess they don't, i guess they get airlifted.
Can anyone else see the waterslide up on the tower next to the bridge?
Rarely nowadays, does the jaw drop!
[deleted]
but why do they want to do this?
Its not like they can move that cruise ship anywhere it couldn't have gone on its own.
Its not like they can move that cruise ship anywhere it couldn't have gone on its own.
I am not an expert but a crane toppled in a dry dock that Royal Caribbean was using, and it took the dry dock out of action[1]. This appears to have screwed up scheduling all over the place. I had a deposit on a cruise in April 2021 that was canceled because of the butterfly effect from this. Possibly due to some sort of perceptual Bader-Meinhof effect, it seems to me that ABB Azipods are often showing up in complaints by passengers of missed ports and delays[2]. Carnival Vista needed a dry dock and was a bit impaired by its Azipod problems in reaching it and maneuvering, apparently.
As stated by others, the lift ship is acting as a dry dock rather than taking the Vista to the dry dock.
[1] https://gcaptain.com/oasis-of-the-seas-dry-dock-accident/
[2] https://www.travelweekly.com/Cruise-Travel/Insights/Vista-ju...
As stated by others, the lift ship is acting as a dry dock rather than taking the Vista to the dry dock.
[1] https://gcaptain.com/oasis-of-the-seas-dry-dock-accident/
[2] https://www.travelweekly.com/Cruise-Travel/Insights/Vista-ju...
Time is money. A cruise ship not carrying passengers is not making money.
Presumably it was more cost effective to use this than to travel to a dry dock wherever that is. The article this was switched over from did say it was fairly far from a dry dock capable of taking it in.
Presumably it was more cost effective to use this than to travel to a dry dock wherever that is. The article this was switched over from did say it was fairly far from a dry dock capable of taking it in.
> Time is money. A cruise ship not carrying passengers is not making money.
Time is especially money because money isn't free. When you are a company, you are generally expected to pay for your money: either interest on your loan, or profits to your shareholders (directly through dividends or indirectly through the higher stock price that comes from being a more valuable business).
This cruise ship probably has a mortgage.
Time is especially money because money isn't free. When you are a company, you are generally expected to pay for your money: either interest on your loan, or profits to your shareholders (directly through dividends or indirectly through the higher stock price that comes from being a more valuable business).
This cruise ship probably has a mortgage.
In this case the ships propulsion systems were semi-broken (one of the azipods wasn't working). The dry dock where it was didn't have the capabilities they needed to work on it and those cruise ships have aggressive schedules so every day its sitting they're losing money. They could have towed it somewhere but thats time there and back.
> Its not like they can move that cruise ship anywhere it couldn't have gone on its own.
It's absolutely like that, in scenarios where the cruise ship is broken.
It's absolutely like that, in scenarios where the cruise ship is broken.
Sure, but I was also asking myself what sort of problem does this solve that towing the boat doesn't - it doesn't get the boat quicker to a dry dock than towing would for example, nor does it allow it to sail to places that it couldn't otherwise. The answer is in the details - the nearest dry dock where it could moor for repairs is unavailable due to recent damage, so this entire platform serves as a kind of mobile dry dock while the repairs are carried out.
> it doesn't get the boat quicker to a dry dock than towing would for example,
But in this case, it did. The ship was located in a part of the world where the available dry dock was currently unable to take it in, so this lift ship is acting as a temporary dry dock to allow the repairs to happen to the ship.
So it did "get the boat quicker to a dry dock" because the heavy lift ship is also serving as a "dry dock" while the repairs happen to the cruise liner.
But in this case, it did. The ship was located in a part of the world where the available dry dock was currently unable to take it in, so this lift ship is acting as a temporary dry dock to allow the repairs to happen to the ship.
So it did "get the boat quicker to a dry dock" because the heavy lift ship is also serving as a "dry dock" while the repairs happen to the cruise liner.
All this is to replace four bearings in the Carnival Vista's azipods, the steerable propulsion units. The ship is only three years old, and if they have to replace all the bearings, there must be some design or manufacturing problem.
This is costing $50 million. The azipods were built by ASEA Brown Boveri.[4] Is this covered under warranty? This looks bad for ABB.
Here's what an azipod looks like during manufacture.[5] Bearing replacement is clearly a major job.
[1] https://www.youtube.com/watch?v=AalbxJtlLBE [2] https://www.youtube.com/watch?v=ixHPB8rGX9E [3] https://www.youtube.com/watch?v=abjqBV3cdAo [4] https://new.abb.com/marine/systems-and-solutions/azipod [5] https://www.youtube.com/watch?v=lvHb4XTkC0A