HN user
Yeah, that completely invalidates his point.
I looked at a couple random agentic sessions in my openrouter activity, and the input cost is 10x the output cost.
Prompt caching on openrouter is complicated and unreliable. On local hardware with llama-cpp, it's mostly free.
I'd like to point out that Qonto is a business bank. Not open to consumers. They also have a list of prohibited activities: (https://legal.qonto.com/en#template-uoa8xux5p) which, funnily enough, include "Hunting, trapping and related service activities", "mining nonrenewable natural re-sources" and "accessibility diagnosis" (??).
Consumer protection laws obviously don't apply to businesses, and banks close business accounts all the time for not following the terms of services. That sounds like a MUCH more probably cause than "I said mean things about Palantir".
The guy has a "Conspiracy theory and disinformation" section in his wikipedia page, that mentions 9/11.
Come on. That's your "totally not pro-russia" example ?
In 2015, systemd was a giant, immature and complex galaxy of tools, that came to replace a hacky-but-mostly-stable bunch of shell scripts. It was pushed fast. It came with good ideas and innovations. It also came with security issues, bugs, and lost productivity.
The fact that the main guy behind the project has a very... abrasive personality, and that the project got to widespread adoption through political moves more than through technical superiority, turned that dislike into hate.
But it's 2025 now, systemd has stabilized now, and I don't really see the point of all this anymore.
In full-cloud environments, in small/middle companies I've worked at:
Developers handle 1). Devops handle 2)/3)/5). Nobody does 4)
Youtube premium is still ad-free. There is a Youtube premium lite which is kinda-ad-free-but-not-really, but the full ad-free one still exists.
It depends how it is done. I used to think the same way, and I would never hire someone without having seen them program live.
But having experienced leetcode-style interviews on the candidate side, it's clear to me that they are no longer about figuring out and coding a solution on the spot. Interviewers expected a solution FAST, and to match that you need to have studied and learned the answer beforehand.
I blame everyone else and myself equally.
But I'll stop whining about politics when I'll stop witnessing well-behaved but incompetent people turn projects to failures.
But regardless how fast we achieve net-zero carbon dioxide, there is good reason to believe that the societal impacts of extreme heat are manageable, and across different scenarios. For instance, according to the World Health Organization, even with increasing heat waves, mortality does not have to increase.
There are two big problems with this take:
1. The author takes the "100% adaptation scenario" from the paper, and ignores the rest of the discussion. Yes, if we mitigate the effects of heat waves, there will be no effect. I could have guessed that myself.
2. The part of the paper is about the deaths directly attributable to heat waves on people aged 65+. That is a super narrow metric. Maybe the author should read the "Undernutrition" part of the paper he himself quoted, which paints a very different picture. And that's not even the full picture.
In France last summer, some plants had indeed to be shut down because of the drought but:
* a minority of plants were involved, it was only an issue because it happened on top of other issues (planned maintenances delayed due to covid, corrosion issues)
* the problem isn't actually the drought, it was the heat. The plants could keep operating, but they would have rejected water too hot, in breach of environmental regulations.
Besides, new plants can be built close to the sea instead of rivers to account for that.
At scale, you would need to factor in the durability of the media. [0] suggests that some types of bluray disks can last 20 to 50 years. Hard drives typically struggle to last 10 years. So if you need to replace hard drives 5x more than bluray disks, maybe it changes the economics.
That's a random study I found on Google, of course, I'm sure Meta has more accurate data on that.
Besides, you need to build the same kind of redundancy in both cases, so that shouldn't influence the choice.
[0] https://www.canada.ca/en/conservation-institute/services/con...
The resistance is already there, it's already happening. Car owners in Paris are furious, and bike infrastructure is already taking away space from roads. High traffic roads in the center have been downright closed and made bike-only.
It is feasible because Paris (the city itself, excluding suburbs) is a very crowded city, where owning a car has always been a luxury. People living in Paris itself who can afford a car, with the associated parking space and everything, are a minority.
People living in the suburbs are more likely to own cars and drive through Paris, but they don't elect the Paris mayor, so their opinion doesn't have much weight.
At every single org I've been where Datadog has been considered, the conclusion has been "Yes, it would be cool, but we really can't justify the price."
Yes, in theory, in the middle scale, you should outsource things, but in practice, it only works if the managed service is at the right price.
It is not an inconsequential oversight. Most people will at least have sessions open to internal/private systems, sometimes sensitive credentials. And part of the teams will go see clients with their company laptops. You absolutely do not want people to be careless about leaving their computers unlocked.
The number-based scheme is a leftover from old times. I don't think they are actually used for ordering how the migrations are applied anymore.
The migration file will contain explicit dependency information, something like:
dependencies = [
('app', '0010_alter_menuitem_absolute_url')
]
The use case is different. For the price of a cloud instance, on top of the instance itself, you are paying for:
* availability. On AWS, you can start a couple dozens or hundreds of instances on demand, for a limited time. You are paying for that spare capacity. VPS/Dedicated servers generally have much lower spare capacity, and you're booking things by the month, not by the minute.
* reliability. Most real cloud instances live on networked drives, and your risk of losing data is very low. On root servers, you have to handle data reliability yourself earlier. (you should do backups either way, but you're likely going to use your backups more often on VPS/Dedicated offerings than in the cloud)
* surroundings services. Private networking, security features, etc.
You pay a premium for all that, so for the same raw compute performance, cloud prices will be at least 2-3x the price of a basic root or dedicated server. On the other hand, vps/dedicated servers typically include bandwidth in the price. The best choice depends on your requirements, but most people will blindly go towards cloud servers..
I used the exact same stack (gitolite+cgit) in the early stages of a previous startup, and code reviews were the big missing part that made us move to something more full featured (for us, gitlab).
It's pretty easy to trigger ci runs via git hooks, and once you're used to it, checking their results in jenkins instead of in the git repository UI makes no difference. But code reviews really need a dedicated interface.
Yeah. After the .dev disaster, you'd think people would have learned their lesson...
You probably aren't alone, since commands that punish you when you mistype exist. Check out sl[0] or gti[1].
[0] https://github.com/mtoyoda/sl [1] http://r-wos.org/hacks/gti
An interesting consequence of your last question, is that if Google added .dev and .foo to the HSTS preload list, it means they don't intend to make these domains available for public registration at all. If they did let people register them, they would have no way to enforce that the sites on there honored the hsts requirements.
You're right, there is a difference.
I meant equivalent from the point of view of the user who wants to run tests, not on the way they work internally.
That's what Xvfb is for.
"xvfb-run firefox" and "firefox -headless" should be functionally equivalent. But I would still be interested in performance comparison with numbers.
The old school solutions lack any sort of javascript support (per the docs, htmldoc doesn't even support css), so they wouldn't work for a lot of real world websites. That's not really the same use case.
A better comparison would be against the likes of wkhtmltopdf[0], which uses webkit, or the pdf generation features of phantomjs.
Yeah. Comparing the legal issues that Facebook faces to the legal issues that Uber faces is complete nonsense.
It obviously depends on what work there is to do. In most of what I do, I work alone, with little need for cooperation, working through the backlog of tickets to implement. And the same goes for my coworkers. So I don't know why the morning people would have to wait for the night owls or why the night owls would need the morning people to stay around late. Everyone has their own stuff to do. If I need to talk to other people, I do it between 11AM and 5PM. Or schedule ahead of time so people can anticipate.
What he's saying, is pretty much that he doesn't want to work for people that think like you.
And it's okay. Not everyone can be a good fit for every company.
It's already the case most of the time. If you submit via a plain form (without js), you get the (old) "This page is encrypted, but the information you submitted will be sent unencrypted" message. If you submit via an XMLHttpRequest, it should be blocked as Mixed Content.
Not the author of the code, but personally, I don't see any downside to putting "set -eu" at the beginning of every script I write. These should be defaults.
A note on concourse deployment: their docs recommend bosh deployments, but they also provide standalone binaries [0] and the deployment workflow in this case is extremely simple. Run "concourse web" for the UI, "concourse worker" for a worker, and all the basic connectivity stuff is handled via command line parameters.
That being said, depending on your company habits, the fact that concourse is very opinionated on how to run the jobs (every is built around docker) and how configuration is done (yaml files, no UI) can be either a blessing or a showstopper.
Yeah, but you still have to parse the .obj. What the article is doing is .obj -> .json -> WebGL arrays. There isn't really any reason to put the .json intermediary in the middle. Especially since you will only treat it as a blackbox to pass around.
JSON is nice as a hand-editable text format. It isn't designed to be fast to parse, or to produce small files.