> Can you tell me what is the budget necessary to supply AI tools capable of substantial research assistance to all academic staff at a university?
I think the GP meant that *if the tools provide substantial benefit* to staff, their costs can be compared to salaries and other large expenses of the university. The $100/month subscription costs less than your office space.
Why is vendoring frowned upon, really? I mean, the tooling could still know how to fetch newer version and prepare a changeset to review and commit automatically, so updating doesn't have to be any harder. In the end, your code and the libraries get combined together and executed by a computer. So why have two separate version control systems?
Vendoring doesn't entirely solve the problem with hidden malicious code as described in the article, but it gives your static analyzers (and agents) full context out of the box. Also better audit trail when diagnosing the issue.
Why would it decimate the Windows market? From my experience, there's a strong correlation between iPhone and Mac usage.
Looking at the stats, the Win:Mac ratio is 4:1 but Android:iPhone only 2:1 so it might hurt Windows. But if iPhone users are more likely to use Mac or don't use computers much already, then expanding iPhone capabilities would cannibalize Apple business.
The assumption is that a "waymo bus" would be hailed by an app and the service would plan routes on demand. In such case, bus stops would be needed only in busy areas or in places where it would be dangerous to stop.
This is based on the observation that people, including police, tolerate taxi drivers stopping at places where it's technically illegal.
Good context. They're commenting only on why are they increasing some setup fees though, not justifying their existence. The Hetzner setup fees were in place already before the RAM price hike.
Hetzner charges a fee for setting up your bare-metal machine. Often zero for their smaller machines and for those in auction. Probably they don't want someone to order a large fleet large of machines for one month and then cancel. They might not get another customer for those machines soon.
There are multiple companies doing that. I was using one a few years ago, also don't remember the name, haha.
I guess it's an obvious thing to sell, if you go through the process of PCI-DSS compliance. We were definitely considering splitting the company to a part that can handle these data and the rest of the business. The first part could then offer the service to other business, too.
> Could you split up the traffic across dozens or hundreds of IPv6 source addresses?
Yes
> I can see how this significantly increases complexity for tracking
Not really. You just track at some prefix level. In general, the ISP will hand out a /64 per consumer so that's what you can track. From there, you can build more complex and more precise grouping rules for tracking.
In fact, sometimes I open bash even from zsh. When pasting from a script and debugging why something doesn't work as expected, I don't want bash-like. For ad-hoc loops, bash-like works well for me thanks to the familiarity of syntax.
They have some headers for authentication. The payment part is for the price negotiation. The headers tell you that Cloudflare wants to charge you for this particular content and you tell CF that you're OK with being charhed up to $AMOUNT.
I'd say the spirit of open source is that others are free to modify the code and that's it. This requires a good license, the possibility to fork, some documentation and a way to build the project yourself.
But why would accepting contributions be required?
Hey I'm not saying it's always a better way or that all apps should be developed in a certain way. But it's a trend, people are doing it for a reason and I think I understand why.
You asked whether some of the reasons are technical. Not in the sense that you can't do it in a simpler way, no.
Look at it from the perspective of a company that has a product and a few developers working on it. It's successful. Now a lot of requests pops up. Some are small, some are related to an obscure integration, maybe a few custom development requests from important customers, bug fixes... The company can now either say no to a big chunk of them (a fine choice), or, if it has money, it can hire more people.
Now, with more people, for them to be somehow effective, you need to create internal APIs and narrow down the focus areas of your teams. Backend/frontend is a separation layer, you're right. But I'd argue it's not that useful for this problem. If the backend emits HTML, what's the frontend work then? Styling? On the other hand, running a thick client in the browser that consumes an API makes it possible to decouple even the release cycle of the frontend from the backend.
Mind you, there are companies that are/were successful with a small team. But most often, the success is supported by large teams at the cost of technical perfection.
You split your app into components and separate it from the backend using an API. This allows you to build a bigger development team. The result will be less efficient but more featureful, more polished, will have someone on call and a better bus factor.
What you could do is to use a heat pump to spend a little electricity and turn the waste heat to hot water usable for heating (winter).