I can't say I've used it personally but I know of OpenRGB[1], which should help with lighting on those types of computer devices. Maybe that might do the trick?
I have worked at a number of jobs where it sometimes required me to use coding. I was not treated like a programmer ever. I was given very old hardware and expected to do my work. The worst computer I had was a Dell machine which had an i3 CPU and 4GB of RAM. Opening VS Code on this machine brought it to it's knees.
I solved this issue by simply using Emacs instead. It uses far less memory, didn't cripple my system, and it is after all my preferred text editing environment for the last few years. I eventually got fed up with Windows bluescreens that I switched to Linux, and then I spent more time fixing other people's older Windows machines than doing my tasks.
Emacs has me sucked in and I don't see myself going anywhere else. Now I'm using Emacs on another old Dell with Linux in another workplace, and it's fantastic to use as always.
If he does he shouldn't be posting them here. He should be giving them to his insurance company so they can go after the other driver's insurance company for compensation.
You could potentially post evidence against yourself if you posted online. It's a little shady but I don't think many people are ok with shooting themselves in the foot.
If the images contain information that is relevant to an insurance claim, they probably should not be posted in a public forum that everyone on the Internet can see.
In Factorio design this is simply increasing the buffer size. If the truck-loadings-per-hour don't increase then it's not going to matter how large you make the buffer.
Adding a secondary site for putting containers also seems like it's going to be a new challenge for the logistics company scheduling the rides (I have a friend who deals with train cargo scheduling). Truckers who are used to showing up at the port are now going to have to go to a completely different site altogether, and who knows how many IO issues the new site will also bring in.
Now's the chance for logistics companies to start hiring OpenTTD players.
I mean, I also play Factorio and came away from reading the article thinking that yeah, increasing the headroom in the chests (aka container stacks) from 2 slots to 6 slots would definitely introduce slack into the system. The short haul loop to a staging and integration area would also help because it allows you to re-sort the inputs to maximize pickup efficiency and is also something I've done in Factorio games.
It might be fun to release a Port of Los Angeles savegame that challenges folks to unhork the port.
what’s really awesome is how Google refuses to believe “unhork” could be a real word or even slang. Oh, how the mighty have fallen. This truly is representative of the emergent horkage of bureaucratic oligarchy founded on algorithms. The supply chain crisis is merely representative of the same noumenon. HHOS.
On the flip side, hackspek is becoming obscure again. Which may be desirable to those who would be secret masters of hackerdom.
There were supposedly trucks that couldn’t be loaded because they had no place to get rid of the empty container they currently had. So truck loading rate was low, not because of the speed of the workers and cranes, but because of the availability of the trucks. So this is supposed to allow the truck loading rate to go up by making it easier for trucks to become available.
I don’t know if that will happen, but this is an increased buffer size that is directly addressing a limiting factor. It might help.
Increasing a buffer size can also make it look like the problem is solved temporarily when you really have a rate issue. It seems that filled containers are coming in at a faster rate than empty containers are going out. We've increased the buffer for empty containers at the dock but did we address the outgoing rate problem?
Why wouldn't the buffer just fill again? I wonder if we've reached a point where manufacturing a new container is more economical than hauling an empty back across the ocean especially if you include opportunity cost to ship actual goods.
Your last point is being reported. It's cheaper for the Chinese to export containers (with subsidized steel) than it is for shipping them back, so they're just making new ones.
Conjecture, but policy wise, this could relate to steel tariffs, decrease Chinese steel imports to the US and finding the container market to allow you to keep pumping money into the industry
It's not that it's cheaper to make new containers. It's that the opportunity cost of waiting for the ship to be loaded with empty containers is more expensive than immediately heading back to Shanghai with an empty ship so that you can make another very lucrative journey to LA.
That's my limited understanding of the situation. I could be wrong.
The goods waiting in Shanghai are not in freshly minted containers. If they were, shipping from LA to Shanghai would be much more expensive than your graph suggests, because otherwise it would have been cheaper to ship one from LA than buy new one in Shanghai, and so people would do that instead of buying new containers.
The buffer would (maybe) not fill again, because the overflow containers were stored on chassis. The problem was that we needed buffer space and converted transport to buffer space - and then we didn't have enough transport, so we needed more buffer space. Cue ominous feedback loop music.
This should free up transportation space, so we can unload more ships, so we can load containers on them and ship them back. Is it the only problem in the supply chain? Probably not. Will it make things better? Definitely in the short term, and probably in the long term.
At the very least it buys a respite to think about further fixes.
On a long enough timeframe and nothing else changing, yes it would just fill up. Realistically, it gives them breathing room to get the rest of the rate up.
I am curious what the costs of making a new container and recycling the old instead of shipping them back is. Trade isn't symmetrical. I assume shipping them back is cheap because otherwise the ships are going back nearly empty, so it's almost free to ship them back.
I've read anecdotes that China is making new containers instead of accepting old containers. This could be because buffers aren't getting them back in time or because China needed a new market for steel
Containers have a lifespan, so China has always been making containers. When containers don't come back you can buy a new one. Shipping them back empty is a lot cheaper than buying a new one, but only if you can get them shipped back. The price to ship a container back empty is low enough that some ships decide it isn't worth it.
I'm not sure this is a "supposedly". There were tens of thousands of trucks that couldn't unload their empties because empties could only be stacked 2 high for aesthetic reasons. Longbeach has since amended that to 4 high doubling the capacity for empties, freeing up trucks to clear unloaded containers from the port. This may be enough to shift the bottleneck.
This is what I understood as well. However, I still don't understand how we got there in the first place. Last time I asked this I just got down voted.
FWIW I just looked at that previous comment of yours, and it's not obvious to me why it would get downvoted. You might want to chalk that one up to HN voting noise.
The trucks were acting as a buffer, if you believe the CEO of Flexport. So if you increase the buffer size, then the trucks can be trucks again and it's guaranteed to increase truck loadings per hour.
Truck-loadings-per-hour will increase, but that does not help shrink the buffer if every truck picking up a container also brings back an empty one.
Increasing the buffer size is a temporary relief, but clearly the underlying problem is an ever-increasing number of containers (empty or full), or we wouldn't have gotten into this situation.
If we could dispose of the empty containers somewhere then this bottleneck would cease to exist - trucks could just haul away containers at max throughput. I gather that it's become harder to ship back empty containers though, and presumably just scrapping them is not a sound solution in the long run either.
> I gather that it's become harder to ship back empty containers though, and presumably just scrapping them is not a sound solution in the long run either.
This is not obvious to me. The same ships are going back to fetch more goods, so why would they want to go empty?
Surely the cost of manufacturing a new container is (or should be) less than the cost of putting it on an empty boat.
Does the port charge container owners for storing empties? Ramp up the storage fee, and voila... empty containers go back on empty boats that would otherwise make the return trip with no load. Container owners will find that shipping them back with a reasonable premium to keep ships around long enough to pick up the empties eventually costs less than storing them at the port.
Aside, I'd love to have an empty container on my parcel out in the desert, if there's such a huge glut of empties, why does one in any condition cost $10k, without delivery? If anyone has a source for empty containers for sale at reasonable prices, I'd love to have their contact info.
Scrapping containers is a terrible idea. We need reuse those containers in 2 weeks. The supply chain is a loop. The pipeline is just stuffed up right now and we need to stash empties for a bit while we unload the ships that are backed up.
Or just make collapsible containers. Bolt the corners (where all the strength is) on right and then take them apart. Needs careful engineering work, but it seems like it should be possible to standardize then and then machines at either end can take them apart and stack into a standard container dimension.
If it's true that ships are refusing to load empties simply because it's more profitable to skip the loading times, then a requirement could actually fix things in the medium term.
You have idle trucks unable to increase the truck-loadings-per-hour because they can't complete a single job due to the lack of storage space for their empty containers.
Providing that storage space will allow the trucks to complete their circuit.
You could also look at it as putting down a storage chest so that you can run down a belt and pick up all the items that shouldn't be there, or sticking a chest next to your un-barreling factory while you work out how to get a return train back to the barreling factory, or putting down some fuel tanks to hold light/heavy oil while you research advanced oil processing (before the basic oil change).
I'm skeptical that this will fix the problem by itself, but it buys time to observe the system in action and adjust capacity on other bottlenecks to bring it back into balance.
I'm skeptical that it will increase observability. Buffering tends to hide problems, not reveal them. We know what the bottleneck is (getting empty containers off a critical location, as far as I understand.) Adding more empty containers to this critical location will not increase our ability to solve the problem, it will put off the problem into the future while simultaneously making it worse.
Buffer size is critical in the case of things like the credit crunch that seized up the global economy back in 2008. Having room to maneuver makes it possible to address long term problems. Although it can also be thoughtlessly filled in service of short term needs with moves that don't actually provide a long term benefit.
I'm a bit the same. I've been writing Racket for a number of years now and looking back at Lisp I see a lot of ugliness that I don't really think I enjoy.
Racket has a nice package manager and module system that kind of works for me, and the documentation is honestly some of the best I've ever used, if not my favorite. Comparatively, I've tried using GNU Guile and found the online documentation to be horrendous, and trying to find online documentation for what's considered to be the "standard library" in Common Lisp still confuses me.
I love seeing people use CL and other Lisp-likes in the wild, and Norvig was a big inspiration for me.
What IDE do you use for racket? In emacs, I've found SLIME and its associated debugger to be more powerful than GEISER. I never could come to like Dr. Racket due to its lack of autocomplete and things like parinfer / paredit.
Agreed. I used to use Firefox Profiles like above comments may mention, but multi-account containers are great and far easier to use than re-launching Firefox instances. Simply click "Re-open this tab in..." while being on the Discord page to open up another account.
According to the article, it seems like it was heavily based off of Apple iMessage zero-click exploits built into some platform. And even a bit of social engineering.
Past that, who knows where they get exploits from? I imagine if they're renting servers with Bitcoins to perform computer attacks, these operatives are probably familiar with darknet sites for trading secrets as well.
[1] - https://openrgb.org/