There should be an app for this. You walk around in an area to gather data, and then you can look at where the WiFi signals are. Maybe share this with other phones nearby, so you can crowdsource a view of the WiFi landscape.
"Fighter Drawdown Dynamics: Effects on Aircrew Inventories" - a 2009 study from RAND, says "to maintain the health of fighter units, the number of new pilots entering them must be reduced, ultimately to below 200 per year by 2016." Fighter pilots are high-maintenance - they have to fly frequently to stay good. Having too many fighter pilots for the number of available aircraft results in a big pool of mediocre pilots.
The USAF seems to be having trouble balancing their personnel pipeline.
There are lots of Canonical announcements about machines coming preloaded with Unbuntu. Not many shipments.
"Canonical Partners with ASUS for Ubuntu Linux" (2011) "This is part of a new engagement and it's great to be working with such an innovative player," Chris Kenyon, vice president OEM Services at Canonical told InternetNews.com. "To put this in perspective we are now working directly with Asus, Lenovo, Dell and Acer on enabling systems."
There are other tablet and phone Ubuntu announcements, which you can find with Google. Someone is taking "pre-orders" for a Ubuntu tablet for delivery in late 2013.
Despite all their press releases, Canonical seems unable to get any manufacturer to ship a preloaded Ubuntu machine in volume.
Canonical has bullshitted too much in the past to be taken seriously about this. Several times, they've announced that new products from major vendors (Asus, Dell) would run their version of Linux. Never happened. They need to STFU until the product ships.
I have almost everything blocked, just to see what breaks.
Blocking trackers doesn't seem to cause any problems with most sites. Blocking third-party cookies occasionally causes a problem, but not often. Blocking Flash storage of 3rd party data breaks CBS video, but not NBC, ABC, Fox, Youtube, or Hulu. (Until a few months ago, if you blocked all trackers, CBS video skipped the commercials. But they "fixed" that.)
I looked at these tests and tried to figure it out for a bit but unless I actually cut those things out and folded them up there is just no way I could figure those things out.
Visualizing unfolded parts is a skill that improves with practice. Anybody who does sheet metal work sees such problems routinely. There are programs for this, such as eMachineShop or Autodesk Inventor. Rectangular sheet metal design is not that hard. Origami, though...
There's a higher level of visualization than this. I used to develop high-end animation software, so I met pro 3D animators. I've seen one draw a head by drawing a series of 2D cross sections freehand, then skinning it. I can use the 3D animation program, but I can't do that.
Sculptors have that skill, too. There's a classic line: "The story is told that the Pope visited Michelangelo in his studio one day, and on seeing him sculpting his statue of David, the Pope asked, "How do you know what to cut away?" The great artist's response was, "I simply chip away anything that doesn't look like David."'
That is not a joke. There are people whose 3D visualization is that good.
This may be inherited. I know a good artist whose drawings have hung in the Smithsonian. She has that kind of visualization ability. So do her son and daughter, although neither works as an artist.
Address space randomization is security through obscurity. It's an admission that you can't fix your buffer overflows. It slows down attackers, but there are counters, such as "spraying attacks".
Worse, it means that bugs become nonrepeatable and harder to fix. So software quality degrades. It produces more of those errors you see in bug tracker as "Closed - can't reproduce".
This is a fixable problem. Microsoft could use C#, or Java, or Go, or Python, or Javascript - languages with subscript checking. Or fix C. Or extend their static driver verifier to cover more kinds of code. Address space randomization just obscures the problem.
One of the reasons it's so hard to make changes is that nobody really knows why the internet works.
We still don't know how to deal with congestion in the middle of a pure datagram network. The Internet works because last-mile congestion is worse than backbone congestion. If you have a backbone switch today with more traffic coming in than the output links can handle, the switch is unlikely to do anything intelligent about which packets to drop. Fortunately, fiber optic links are cheap enough that the backbone can be over-provisioned.
The problem with this is video over the Internet. Netflix is a third of peak Internet traffic. Netflix plus Youtube is about half of Internet traffic during prime time. This is creating demand for more and more bandwidth to home links. Fortunately the backbone companies are keeping up. Where there's been backbone trouble, it's been more political than technical. It also helps that there are so few big sources. Those sources are handled as special cases. Most of the bandwidth used today is one-to-many. That can be handled. If everybody was making HDTV video calls, we'd have a real problem.
(I was involved with Internet congestion control from 1983-1986, and the big worry was congestion in the middle of the network. The ARPANET backbone links were 56Kb/s. Leased lines typically maxed out at 9600 baud. Backbone congestion was a big deal back then. This is partly why TCP was designed to avoid it at all costs.)
Water-cooled power plants take in water. And then they put it out again, warmer. They don't use it up. At worst some of it comes out as water vapor from cooling towers, which condenses out.
I'm surprised that humans can even do such problems. Numerical optimization by hand sucks. There are some strategy issues (should we slingshot around a planet?), but there aren't usually a vast number of options like that. So you crunch on all the plausible options. I wouldn't expect that this is a problem dominated by local minima.
The problem is that it costs too much. If they got the price down below $100, like generic Android tablets, it would be a big hit. Vast numbers of low-end tablets are pouring out of China, and some of them aren't bad. ARM tablets just aren't that expensive to make.
Let's supposed your "final" exit temperature is 90C. Also let's assume the cooling reservoir is around 10C. Let's also assume that the final stage takes steam from 200C down to 90C. That give it a theoretical Carnot limit of 110/363 ~ 30%.
Turbines have been doing much better than that for decades. Steam goes into a modern 1 gigawatt GE turbine at 260 bar and 610C. Bear in mind that the thermoelectric system gets no benefit from pressure. You don't want to use it on steam; that would be wasteful of energy stored in the compressed steam. The thermoelectric system has to work off hot water, which means < 100C.
What did you expect? It's a land development project in South Florida. There's a long, long history of scams in that industry.
Also, the location sucks. From the rather vague map on their web site, it's south of Kissamee and due east of Brandon. There's about here. That's Indian Lake Estates, which, as you can see from the aerials, was supposed to be a large development with 300 city blocks. About 5% of the lots have houses. There's one area where houses were built along small canals, but the canals all dead-end, so there's no flow and they'll stagnate.
Here's a street view. Nearby are remnants of other failed developments, a defunct Air Force base, and a a few modest farms.
It doesn't look like "regulation" was the problem. More like "reality".
Right. What we have here is another crap materials science article. Somebody did something vaguely interesting at lab scale, and then issued a bullshit press release.
Trying to get the last remnants of recoverable energy out of a heat engine is an old game, going back to the reciprocating engine era. Basic steam engines had one cylinder running off boiler pressure. Double-expansion steam engines had a second cylinder running off the output of the first. The second cylinder is bigger and runs at lower pressure. Triple expansion steam engines had a third, even bigger cylinder. Some quadruple expansion engines were built, but this is a diminishing-returns thing, and triple expansion is about as far as it's worth going economically. Marine engines were often triple-expansion.
Large steam turbines do the same thing, with a succession of rotors of increasing size. Three to twelve stages have been used. Again, this is a diminishing returns thing. At some point the steam condenses to water, which you don't want to happen inside the turbine. Existing turbines get close to that limit. Some turbine plants have a partial vacuum going into the condenser to keep the steam as a gas below 100C. 90C exit temperatures are not uncommon. Almost all of the usable energy has been extracted with an exit temperature like that.
If this new thermoelectric thing is a better way to convert heat to electricity than a steam turbine, it should replace steam turbines, not just be used on the cold end of the system.
An efficient solid-state way of converting heat to electrical energy would be valuable. All the existing thermoelectric devices have low efficiency compared to heat engines. Back around 2011, there were several startups getting Federal grants for R&D into "heat harvesting". Commercial products were supposed to appear in 2012. Didn't happen.
Honest question: how would you know if you were losing lots of talented developers? Not many people are going to speak up to let you know that your behavior is toxic. They'll just leave and take their skills elsewhere.
I know someone who did just that. He was a quiet guy from the Midwest who was a very good real-time programmer. He headed one of the groups that worked on the original iPhone. He didn't like being yelled at by Steve Jobs. He stayed until the product shipped, then quit and went to a competitor.
The problem shows up as DC current on long AC lines, because voltage at "ground" differs across points hundreds of miles apart. This can damage transformers. So they have DC current monitoring in place at some key points on their system. Corrective action is taken when "DC measurement of 10 amps or greater measured at Missouri Avenue in Atlantic City and/or Meadow Brook
Station near Winchester Virginia". Some long-distance lines have to operate at reduced capacity. Some generating plants are told to reduce output. Others have to crank up to compensate.
Medium sized disturbances of this type happen a few times a year (more at the high point of the sunspot cycle). Only one warning so far this year, on June 29th. April 11, 2010 was the most recent disturbance event that required that action be taken. The warning came in from NOAA's Space Weather Center, and people in power grid control centers (the US has seven) reconfigured the power grid to prepare for it.
You installed that plugin, it said beforehand what it's doing, so it's authorized.
Not in this case. That's the issue here. Amazon's description of what the plugin was allowed to do is inconsistent with what it actually does. That's where fraud comes in.
In the SQL world, data is stored in "tables". Each table consists of "rows" of "records". Each record has "fields". Each field has a "field name" and a fixed "type", like TEXT, INTEGER, or DATE. Tables are created with the CREATE statement, where all the field names and types have to be specified. So that's what SQL data looks like. That part is fairly simple.
Tables start out empty. Data is added to a table using the INSERT statement. Existing records can be changed with the UPDATE statement. The SELECT statement is used for searching.
What makes SQL useful is that searching is very powerful. One SELECT statement can look things up in more than one table, find matching items, sort, summarize, and extract specific fields. The key to understanding SQL is learning what SELECT can do. On the other hand, if all you need to do is find one row of a table based on one key, the SELECT statement for that is very simple.
Tables have "indexes". If you use a SELECT statement with a search request for which there is no helpful index, the entire table will be linearly searched. This is slow. So you specify which fields need an INDEX to speed things up. This is usually done when the table is created with CREATE, but it can be done later. When looking things up with SELECT, you usually don't have to mention indexes; which index to use and how to use it is figured out by the database system.
SQL databases scale up well. Gigabyte-sized tables are normal. Terabyte-sized tables are not unusual. You can have many queries and updates running on the same table at the same time. The database system handles all the locking for you. Some database systems can be run on clusters of machines, and some support multiple redundant copies.
You can do a lot of things while a database is running that you wouldn't think of as being possible. You can add a new index, or even a new field, to an existing table while the database is in use. There's a lot of heavy machinery behind the scenes to make all this work.
All the major databases try hard to maintain data integrity. A machine crash and restart will not damage any serious modern database. Program crashes are handled, too. A group of SELECT, INSERT, and UPDATE statements can be blocked together as a "transaction". The database doesn't change until a COMMIT statement is executed, and then all the changes take effect at the same time. If something goes wrong, like the program crashing or even the machine crashing before the COMMIT, the database is unchanged. If your program detects an error and needs to abort the transaction in progress, it does a ROLLBACK and the database is as it was before the transaction started. There's a lot of heavy machinery behind the scenes to make all this work.
There are security features. Access to tables can be restricted, in some cases down to the field level. Databases have user accounts, which are not necessarily tied to operating system login accounts. You can have accounts which can only read some tables, not update or delete them, or accounts which can't see some fields of some tables. This is valuable in web applications.
Database programs have libraries which allow them to be called from various programming languages. Programs in different programming languages can talk to the same database at the same time. So you're not locked to a specific programming language.
Those are the basics. Go install some SQL database on your desktop machine and play with it. MySQL, MariaDB, and Postgres are all free and will work on Linux or Windows desktops.
It's the ship's master that needs the info. Loading a container ship is complicated. There's a stability calculation that has to be performed for large container ships, and software to do it. A loading plan has to be created. You don't want the empties on the bottom, or all on one side, or all at the ends. Stability has to be maintained during loading and unloading. Here's a Maersk ship which capsized at the dock while being loaded.
Bromma, which makes the "spreaders" which grab containers at 97 of the top 100 ports, now offers a solution. Their newer spreaders weigh the container as it's being lifted on to or off of the ship. Accuracy is within 1%. The container crane knows where the container is being placed on the ship, so weight and balance information for the whole ship is collected.
It's being installed in Los Angeles now, London next, and can be retrofitted to existing Bromma spreaders. So there's a technical fix to this almost in place.
Slashdot Mirror
There should be an app for this. You walk around in an area to gather data, and then you can look at where the WiFi signals are. Maybe share this with other phones nearby, so you can crowdsource a view of the WiFi landscape.
"Fighter Drawdown Dynamics: Effects on Aircrew Inventories" - a 2009 study from RAND, says "to maintain the health of fighter units, the number of new pilots entering them must be reduced, ultimately to below 200 per year by 2016." Fighter pilots are high-maintenance - they have to fly frequently to stay good. Having too many fighter pilots for the number of available aircraft results in a big pool of mediocre pilots.
The USAF seems to be having trouble balancing their personnel pipeline.
Could you link to those announcements please?
There are lots of Canonical announcements about machines coming preloaded with Unbuntu. Not many shipments.
There are other tablet and phone Ubuntu announcements, which you can find with Google. Someone is taking "pre-orders" for a Ubuntu tablet for delivery in late 2013.
Despite all their press releases, Canonical seems unable to get any manufacturer to ship a preloaded Ubuntu machine in volume.
Canonical has bullshitted too much in the past to be taken seriously about this. Several times, they've announced that new products from major vendors (Asus, Dell) would run their version of Linux. Never happened. They need to STFU until the product ships.
Hm. Abine's DoNotTrackMe doesn't detect Janrain.
I have almost everything blocked, just to see what breaks. Blocking trackers doesn't seem to cause any problems with most sites. Blocking third-party cookies occasionally causes a problem, but not often. Blocking Flash storage of 3rd party data breaks CBS video, but not NBC, ABC, Fox, Youtube, or Hulu. (Until a few months ago, if you blocked all trackers, CBS video skipped the commercials. But they "fixed" that.)
Wow. Only 15m down, off the east coast of England, and nobody noticed before? I'm surprised someone fishing didn't notice.
Facebook's traffic, user count, revenue, and profits peaked in mid-2012. They're already on the Myspace track to decline.
The future of "social" is on phones, not the Web.
I looked at these tests and tried to figure it out for a bit but unless I actually cut those things out and folded them up there is just no way I could figure those things out.
Visualizing unfolded parts is a skill that improves with practice. Anybody who does sheet metal work sees such problems routinely. There are programs for this, such as eMachineShop or Autodesk Inventor. Rectangular sheet metal design is not that hard. Origami, though...
There's a higher level of visualization than this. I used to develop high-end animation software, so I met pro 3D animators. I've seen one draw a head by drawing a series of 2D cross sections freehand, then skinning it. I can use the 3D animation program, but I can't do that.
Sculptors have that skill, too. There's a classic line: "The story is told that the Pope visited Michelangelo in his studio one day, and on seeing him sculpting his statue of David, the Pope asked, "How do you know what to cut away?" The great artist's response was, "I simply chip away anything that doesn't look like David."'
That is not a joke. There are people whose 3D visualization is that good.
This may be inherited. I know a good artist whose drawings have hung in the Smithsonian. She has that kind of visualization ability. So do her son and daughter, although neither works as an artist.
Address space randomization is security through obscurity. It's an admission that you can't fix your buffer overflows. It slows down attackers, but there are counters, such as "spraying attacks".
Worse, it means that bugs become nonrepeatable and harder to fix. So software quality degrades. It produces more of those errors you see in bug tracker as "Closed - can't reproduce".
This is a fixable problem. Microsoft could use C#, or Java, or Go, or Python, or Javascript - languages with subscript checking. Or fix C. Or extend their static driver verifier to cover more kinds of code. Address space randomization just obscures the problem.
One of the reasons it's so hard to make changes is that nobody really knows why the internet works.
We still don't know how to deal with congestion in the middle of a pure datagram network. The Internet works because last-mile congestion is worse than backbone congestion. If you have a backbone switch today with more traffic coming in than the output links can handle, the switch is unlikely to do anything intelligent about which packets to drop. Fortunately, fiber optic links are cheap enough that the backbone can be over-provisioned.
The problem with this is video over the Internet. Netflix is a third of peak Internet traffic. Netflix plus Youtube is about half of Internet traffic during prime time. This is creating demand for more and more bandwidth to home links. Fortunately the backbone companies are keeping up. Where there's been backbone trouble, it's been more political than technical. It also helps that there are so few big sources. Those sources are handled as special cases. Most of the bandwidth used today is one-to-many. That can be handled. If everybody was making HDTV video calls, we'd have a real problem.
(I was involved with Internet congestion control from 1983-1986, and the big worry was congestion in the middle of the network. The ARPANET backbone links were 56Kb/s. Leased lines typically maxed out at 9600 baud. Backbone congestion was a big deal back then. This is partly why TCP was designed to avoid it at all costs.)
Water-cooled power plants take in water. And then they put it out again, warmer. They don't use it up. At worst some of it comes out as water vapor from cooling towers, which condenses out.
I'm surprised that humans can even do such problems. Numerical optimization by hand sucks. There are some strategy issues (should we slingshot around a planet?), but there aren't usually a vast number of options like that. So you crunch on all the plausible options. I wouldn't expect that this is a problem dominated by local minima.
The problem is that it costs too much. If they got the price down below $100, like generic Android tablets, it would be a big hit. Vast numbers of low-end tablets are pouring out of China, and some of them aren't bad. ARM tablets just aren't that expensive to make.
We're not there yet. The high-power charging infrastructure isn't widely available. That will come.
No car should have a giant touchscreen. You're supposed be looking at the road. At least until we get full automatic driving.
Let's supposed your "final" exit temperature is 90C. Also let's assume the cooling reservoir is around 10C. Let's also assume that the final stage takes steam from 200C down to 90C. That give it a theoretical Carnot limit of 110/363 ~ 30%.
Turbines have been doing much better than that for decades. Steam goes into a modern 1 gigawatt GE turbine at 260 bar and 610C. Bear in mind that the thermoelectric system gets no benefit from pressure. You don't want to use it on steam; that would be wasteful of energy stored in the compressed steam. The thermoelectric system has to work off hot water, which means < 100C.
Since there's no actual even to report, we get a Slashdot story of "musing" by the founder.
At least label these as "paid content".
What did you expect? It's a land development project in South Florida. There's a long, long history of scams in that industry.
Also, the location sucks. From the rather vague map on their web site, it's south of Kissamee and due east of Brandon. There's about here. That's Indian Lake Estates, which, as you can see from the aerials, was supposed to be a large development with 300 city blocks. About 5% of the lots have houses. There's one area where houses were built along small canals, but the canals all dead-end, so there's no flow and they'll stagnate. Here's a street view. Nearby are remnants of other failed developments, a defunct Air Force base, and a a few modest farms.
It doesn't look like "regulation" was the problem. More like "reality".
Right. What we have here is another crap materials science article. Somebody did something vaguely interesting at lab scale, and then issued a bullshit press release.
Trying to get the last remnants of recoverable energy out of a heat engine is an old game, going back to the reciprocating engine era. Basic steam engines had one cylinder running off boiler pressure. Double-expansion steam engines had a second cylinder running off the output of the first. The second cylinder is bigger and runs at lower pressure. Triple expansion steam engines had a third, even bigger cylinder. Some quadruple expansion engines were built, but this is a diminishing-returns thing, and triple expansion is about as far as it's worth going economically. Marine engines were often triple-expansion.
Large steam turbines do the same thing, with a succession of rotors of increasing size. Three to twelve stages have been used. Again, this is a diminishing returns thing. At some point the steam condenses to water, which you don't want to happen inside the turbine. Existing turbines get close to that limit. Some turbine plants have a partial vacuum going into the condenser to keep the steam as a gas below 100C. 90C exit temperatures are not uncommon. Almost all of the usable energy has been extracted with an exit temperature like that.
If this new thermoelectric thing is a better way to convert heat to electricity than a steam turbine, it should replace steam turbines, not just be used on the cold end of the system. An efficient solid-state way of converting heat to electrical energy would be valuable. All the existing thermoelectric devices have low efficiency compared to heat engines. Back around 2011, there were several startups getting Federal grants for R&D into "heat harvesting". Commercial products were supposed to appear in 2012. Didn't happen.
Honest question: how would you know if you were losing lots of talented developers? Not many people are going to speak up to let you know that your behavior is toxic. They'll just leave and take their skills elsewhere.
I know someone who did just that. He was a quiet guy from the Midwest who was a very good real-time programmer. He headed one of the groups that worked on the original iPhone. He didn't like being yelled at by Steve Jobs. He stayed until the product shipped, then quit and went to a competitor.
Mozila is looking for a "Information Technology Enterprise Architect". They need one, too; their online services are flaky.
>"Work for mankind, not for the man" - Mozilla job billboard, San Francisco.
The last time someone got wound up about this on Slashdot. And, last time around, I linked the PJM power grid training document on geo-magnetic disturbances. They know about the Carrington Event. They know all about the problem in 1989, which happened on their system and damaged some transformers.
The problem shows up as DC current on long AC lines, because voltage at "ground" differs across points hundreds of miles apart. This can damage transformers. So they have DC current monitoring in place at some key points on their system. Corrective action is taken when "DC measurement of 10 amps or greater measured at Missouri Avenue in Atlantic City and/or Meadow Brook Station near Winchester Virginia". Some long-distance lines have to operate at reduced capacity. Some generating plants are told to reduce output. Others have to crank up to compensate.
Medium sized disturbances of this type happen a few times a year (more at the high point of the sunspot cycle). Only one warning so far this year, on June 29th. April 11, 2010 was the most recent disturbance event that required that action be taken. The warning came in from NOAA's Space Weather Center, and people in power grid control centers (the US has seven) reconfigured the power grid to prepare for it.
You installed that plugin, it said beforehand what it's doing, so it's authorized.
Not in this case. That's the issue here. Amazon's description of what the plugin was allowed to do is inconsistent with what it actually does. That's where fraud comes in.
It's not that complicated.
In the SQL world, data is stored in "tables". Each table consists of "rows" of "records". Each record has "fields". Each field has a "field name" and a fixed "type", like TEXT, INTEGER, or DATE. Tables are created with the CREATE statement, where all the field names and types have to be specified. So that's what SQL data looks like. That part is fairly simple.
Tables start out empty. Data is added to a table using the INSERT statement. Existing records can be changed with the UPDATE statement. The SELECT statement is used for searching.
What makes SQL useful is that searching is very powerful. One SELECT statement can look things up in more than one table, find matching items, sort, summarize, and extract specific fields. The key to understanding SQL is learning what SELECT can do. On the other hand, if all you need to do is find one row of a table based on one key, the SELECT statement for that is very simple.
Tables have "indexes". If you use a SELECT statement with a search request for which there is no helpful index, the entire table will be linearly searched. This is slow. So you specify which fields need an INDEX to speed things up. This is usually done when the table is created with CREATE, but it can be done later. When looking things up with SELECT, you usually don't have to mention indexes; which index to use and how to use it is figured out by the database system.
SQL databases scale up well. Gigabyte-sized tables are normal. Terabyte-sized tables are not unusual. You can have many queries and updates running on the same table at the same time. The database system handles all the locking for you. Some database systems can be run on clusters of machines, and some support multiple redundant copies. You can do a lot of things while a database is running that you wouldn't think of as being possible. You can add a new index, or even a new field, to an existing table while the database is in use. There's a lot of heavy machinery behind the scenes to make all this work.
All the major databases try hard to maintain data integrity. A machine crash and restart will not damage any serious modern database. Program crashes are handled, too. A group of SELECT, INSERT, and UPDATE statements can be blocked together as a "transaction". The database doesn't change until a COMMIT statement is executed, and then all the changes take effect at the same time. If something goes wrong, like the program crashing or even the machine crashing before the COMMIT, the database is unchanged. If your program detects an error and needs to abort the transaction in progress, it does a ROLLBACK and the database is as it was before the transaction started. There's a lot of heavy machinery behind the scenes to make all this work.
There are security features. Access to tables can be restricted, in some cases down to the field level. Databases have user accounts, which are not necessarily tied to operating system login accounts. You can have accounts which can only read some tables, not update or delete them, or accounts which can't see some fields of some tables. This is valuable in web applications.
Database programs have libraries which allow them to be called from various programming languages. Programs in different programming languages can talk to the same database at the same time. So you're not locked to a specific programming language.
Those are the basics. Go install some SQL database on your desktop machine and play with it. MySQL, MariaDB, and Postgres are all free and will work on Linux or Windows desktops.
It's the ship's master that needs the info. Loading a container ship is complicated. There's a stability calculation that has to be performed for large container ships, and software to do it. A loading plan has to be created. You don't want the empties on the bottom, or all on one side, or all at the ends. Stability has to be maintained during loading and unloading. Here's a Maersk ship which capsized at the dock while being loaded.
Bromma, which makes the "spreaders" which grab containers at 97 of the top 100 ports, now offers a solution. Their newer spreaders weigh the container as it's being lifted on to or off of the ship. Accuracy is within 1%. The container crane knows where the container is being placed on the ship, so weight and balance information for the whole ship is collected.
It's being installed in Los Angeles now, London next, and can be retrofitted to existing Bromma spreaders. So there's a technical fix to this almost in place.