TOU is contract law. It falls into the same vein as “no shirts, no shoes, no service”.

It’s contract law.

We may all hate this (I still morn Apollo) - but legally, ‘I hate it” is not law.

A few things the article gets wrong - there were in fact long negotiations before ground was broken - and signed contracts. The CEO is continental was one Frank Lorenzo - and for a variety of reasons he played political games with the FAA and Denver before he was kicked out - and forbidden legally from ever running an airline again.

Part of what also happened is that united passed conditions o designed to cripple Competitors at Denver - going so far as demanding that the bridge between the main terminal and A concourse (where continental and other airlines were located) be frosted to make it less appealing for Continental customers. It’s also the reason why terminal b is physically wider then A or C.

The article doesn't talk about why they built it, really, but the big reason is that the old runways for the airport were so close together that any sort of weather dramatically reduced capacity at the airport (to the point that the old Stapleton Airport at Denver was the number one delayed airport in the nation, a really big problem when there were sometimes between three and five different carriers hubbing there).

A good example of something that the engineers got right - they replaced a heavy steel structure for a glass roof on the main terminal with a tent. (this why concoursesA,C and especially B have glass roofs while the maybe terminal has white canvas. Not only did this end up being a massive cost and weight savings - it gave the airport its iconic shape. Despite planning on a 10-year refurb cycle for the roof, they haven't had to replace it once.

the last vestiges of the old barge system are finally going away - and the tunnels are being reclaimed to provide a walkway to concourse B and c.

Why are they doing that now? Because the airport has actually been a dramatic success as a connecting and as an O&D airport. It now hubs three different airlines and is well over its original design maxes. They've been doing massive construction at the airport and are getting ready to break ground on two new concourses to continue to meet the demand.

Each of these projects are qre dramatically cheaper than competing efforts of other airport with tens of billions of dollars to refurbish extraordinarily constrained terminals and runways. Over the long run, it seems like a pretty good decision to build the airport, even if it got a rough start.

Geopolitical games like this are how real wars eventually start.

Option B: cloud mode without Developer Mode

Starting with v2.0.0 the plugin can also drive a cloud-paired printer with verification left ON — no Developer Mode. This keeps the cloud features (cloud print dispatch, print history, MakerWorld) but is meant for advanced users, because it requires private slicer credentials that this project does not distribute.

Two things are needed:

1. Bambu's slicer credentials, which you provide yourself. Put slicer_cert.pem, slicer_key.pem and slicer_crl.pem in the plugin's config directory (or point at them with slicer_cert_pem / slicer_key_pem / slicer_crl_pem in obn.conf). The plugin uses the key to sign MQTT print commands and to install its app certificate on the printer. These are private credentials. This project does not ship them and gives no instructions on obtaining them — you have to find or extract them yourself, and you alone are responsible for ensuring your use complies with the applicable terms and law.

2. Two settings in obn.conf. Set block_cloud = 0 (the default 1 blocks cloud printing outright) and client_name = BambuStudio (the honest default client name is rejected by the cloud print API with HTTP 403).

With that in place you get signed MQTT commands, on-printer app-certificate install, cloud print dispatch, print history and MakerWorld — without touching Developer Mode.

What the default cloud_print = cloud_only actually uploads. Even in this mode the model itself normally stays on your network: for a print with a cloud record the plugin sends the .3mf straight to the printer over LAN FTPS, and only the record goes to Bambu — a project entry, a task entry (mode=lan_file) and a small config .3mf that print history uses for its thumbnails. That record is exactly what buys you the cloud extras: print history in Studio and Handy, and the ability to rate models on MakerWorld. The full model is uploaded to Bambu's servers only when Studio dispatches a pure cloud print (start_print), e.g. for a printer that is not reachable on your LAN.

You can limit even that: set cloud_print = try_lan_first or lan_only to print over the LAN without writing a cloud record at all, and cloud_hide_history = 1 to hide the cloud print history in Studio.

If you run neither Developer Mode nor valid credentials, the printer rejects every print / project_file command and shows on its screen:

MQTT Command verification failed err_code: 84033543

)which is why as a percentage of GDP, Americans, European costs are remarkably similar, just distributed differently).

Comments URL: https://news.ycombinator.com/item?id=49306805

Points: 4

# Comments: 2

i think it's quite likely that the casualties where in similar scope across two different civilizations, but that the colonialists advantage (if you can call it such) of excess population and higher density of settlers, meant that the colonialists simply outlasted a far smaller population group.

Cultures coming together historically were deadly. There is a school of thought that argues that the Persian and Roman downfall was directly associated with the ability of diseases to transit roads.

Of course, this is the stuff that we have records for. It's possible that there was a undocumented mass extinction event, But I tend to be skeptical of historical claims that are based on extremely localized and limited archeological projections.

Just pointing out, there is a reason the large LLMs keep working to try to make it so their own tools can't attack their own moats, by preventing the exact behavior that you dismiss above.

Especially at larger quanitizations (Q4 is pretty crap).

Unfortunitly, as others have noted, the DGX OS experience... sucks. My hope is that the RTX Spark (which looks to be the exact same stack, sans the high capacity network interface) will help this get a bit more attention, but nVidia's long long long war with the open source community is not helping. Focusing on mainlining kernel support would go a long way to getting the community to be supportive.

Of course, a massive regression just hit Linux 7+/7.1 plus for ROCm hosts, so it's just rough everywhere.