This is not cynical. The situation is that a) there will be a team of very expensive lawyers and accountants working out how to best implement the plan that benefits the company (whom you can’t compete) and b) crucially, you have no control and prior on knowledge on what that plan would look like. It is not about the company trying to screw an individual over, it’s more the fact that the company will be very unconcerned if their plan is against your benefit, and you have no way to align your own benefits with the plan.
For the situation where the hijacker can actually control the plane, I'd imagine the US military now has a more proper response and will be able to scramble jet in time to shoot down the plane (they didn't have such plan for domestic situation in 2001).
The corporation certainly can kick you out of the stadium, but any law that can make such broadcast illegal is probably nigh unconstitutional in the US.
Washington Landlord Tenant law lists several unwaivable rights of tenants, even given specific consideration.
You can't put a clause in my lease that says "For a discount of $100/mo, I forego the relevant rights on habitability (heating, water, etc.)" - even if I am willing to agree to it.
No, that is not correct. Search for “unwaivable rights”. Obviously you can’t just limit rights with a contract. If you could, labour laws would be useless and minimum wages wouldn’t exist.
It seems (feels?) likely that demand for LLM is elastic, especially when it comes to specialized niche. Less power requirements just mean we run more of them in parallel for stuffs, so the power needs is gonna be growing anyway.
In 2024, 12-month inflation starts at 3.1% and is 2.7% last month (peak at 3.5% and bottom at 2.4%). You can't round that number in anyway to be "~2%". It is at least "~3%"
What's wrong with saying what you typed above verbatim? It is a fairy standard scenario and your wordings probably have been said in one-on-one millions of times.
You need to follow up the sentence with "what's next", since the scenario does not have a simple solution (the manager can tone down the demand, but then output and quality goes back to where is was and we have to deal with that). But now that is more about the work itself rather than communication
Yeah but you don't use the external IP for the purpose of accessing your VPN (not via a DNS record anyway). I am also unclear on the purpose of the dynamic DNS.
Your external IP is dynamic because the ISP can rotate it. You want to reach your home's external IP to VPN in. One common way is to create a public DNS record that's dynamically updated (by a cronjob or whatever) to always contain whatever IP your ISP last handed you.
That's what I do. Just a cronjob on my TrueNAS server to query my IP and update my subdomain's A record if my IP has changed. That way when a power outage happens and my IP gets rotated, it makes no difference.
Imagine, if you will, the following scenario: I have a wireguard endpoint on my home router. The home router uses a residential ISP connection and I don't want to pay $10/mo for a static IP because my ISP is cheeky and expensive. I want to have my phone connect to said wireguard endpoint to establish a secure link. I don't want to have to change my wireguard configuration on my phone every time my home IP changes.
So, I set my phone to peer with the wireguard endpoint on `home.denk.moon:1234`. Every time my home router's external IP changes, it sends a dynamic DNS update to my DNS server such that `home.denk.moon` reflects the new IP for my router. Now, whenever my phone attempts to connect to wireguard, it will resolve that domain name, get the latest IP for my router, and connect.
Handling https in the project also adds tons of complexity in the long run though: tls/ssl library versions, cert handling. Instead of having one way to deal with all of them (at the proxy layer, or sometimes at network layer), I have to deal with individual software way of managing those
Do that for a bunch of different applications and you hit interesting issues. For example the Java TLS stack, which doesn’t accept a PEM certificate on its own, but needs the full certificate chain. Kibana, however, requires the full certificate chain including the root certificate, which isn’t usually a part of the certificate itself, and Elasticsearch complains about an invalid certificate if you point it to the same one.
So even for two apps from the same vendor, which are commonly deployed together, you need bespoke TLS file variants. Scale that to more applications, and you’ll find out the hard way that you are vastly underestimating the complexity of operating a software ecosystem.
I’ve done it. What you’re describing is like an hour of work. Moving TLS outside of the application is possibly the dumbest reason to spend the resources and complexity on a side car.
For a single application, it's not too bad. When you have dozens of applications that all have different mechanisms to install a CA, rotate certs, etc. And some of those don't have a good way to automate rotating the certs, then it becomes a pain.
I don't think so. We run a horde of machines, and run plethora of services, which are custom and/or has a very narrow install base due to the niche they serve.
99% of them use system-wide PKI store for CA and their certificates, which is under /etc. All of them have configuration options for these folders, and have short certificate lives because of the operational regulations we have in place.
At worst case, we distribute them with saltstack. Otherwise we just use scp, maybe a small wrapper script. Managing them doesn't take any measurable time for us.
> 99% of them use system-wide PKI store for CA and their certificates, which is under /etc.
Consider yourself lucky then.
For self-hosted third party software, I've seen requirements to provide it in an environment variable, upload it to a web form over plain http on localhost, specify an AWS secret service secret that contains it, put it in a specific location that is bind mounted into a container, create a custom image (both VM and container), etc.
I mean, tons of "old-school" services handle these things fine for the last two decades, at least. It can't be that hard. It's just a TLS library, and some files in a specific format at the end of the day.
In my experience, most people have an extremely hard time wrapping their minds around how to configure TLS/HTTPS services and fail completely at understanding how it works.
reply