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. Is this covered under warranty? This looks bad for ABB.
Here's what an azipod looks like during manufacture. Bearing replacement is clearly a major job.
According to one of the links I cited earlier  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.
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. That's from General Railway Signal in Rochester, NY.
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.
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.
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.
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.
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.)
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.
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.
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.
I learned this the hard way with my 1U Intel Atom C2000 series server. Completely bricked due to a bug in the CPU.
> 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.
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.).
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.
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.
(And if they do, that's usually solved by procurement, warranty or is otherwise someone else's problem.)
I don't get it. Is this supposed to be sarcasm?
So in just this story we have a maintenance failure (bearings) and two critical failure (cranes) in physical engineering.
They are replacing the bearings on all the azipods, which tells us this is a design and engineering failure rather than a maintenance failure.
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.
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.
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.
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.
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.
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
(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)
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. :)
Thanks, I needed a good laugh ;-)
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.
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.
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.
When one section of the dock doesn't work it won't suddenly flip upside down as could be the case for code.
https://catless.ncl.ac.uk/Risks/3.44.html (1986): early F-16 software would flip the plane upside down on crossing the equator :)
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.
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.
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
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.
The 8-week-bootcamp graduate is not going out and working for Boeing, MCAS memes notwithstanding.
In software the experimentation cost is very small so it makes sense that there are a lot more prototypes and abandoned projects etc.
So it is not only software that produce faulty products.
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.
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.
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 75,71 L fish tank [...] weights 75,75kg
It's great because you can just convert grams to milliliters or cubic centimeters (water is 1g/mL) and fudge it as necessary.
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.
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.
Ship engines are the way round: their weight doesn't matter much, but it matters that they use the cheapest fuel possible.
Those are for military use, where speed matters but money is basically unlimited.
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.
I designed full-building hydroponics systems. You get similar issues with things like vacuum pressure in tanks causing your pumps to not work properly.
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)
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.
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.
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.
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.
Why? It makes no sense.
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.
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 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”).
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.
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.
... while the lifting body is also floating on the ocean.
Usually they're much higher off the bottom of the dry dock.
Why do you say that?
Any idea how much it costs to hire such a ship?
It turns out I can use some of the money I make in my work, to pay other people for their work.
I've been opening directly in VLC instead. Bonus: no ads.
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.
Looks as if that's available for desktop but not the Android app:
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.
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.
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.
Its not like they can move that cruise ship anywhere it couldn't have gone on its own.
As stated by others, the lift ship is acting as a dry dock rather than taking the Vista to the dry dock.
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 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.
It's absolutely like that, in scenarios where the cruise ship is broken.
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.