The idea is, the botnets are in control of someone else. Who "owns" them. And some of those will rent "their property" for money, like they would legitimately own them.
Yeah I assume there's the initial startup cost of successfully managing to infect a large network of devices, and then the cost for any given use is likely "what customers will pay for it". If they are selecting out big money targets and focusing on gaming, I'm guessing the price isn't that high, but they also presumably know interesting a state actor in taking them down either by changing targets or bringing in enough money is bad for business.
I see. It sounds like it would be a source of countless headaches, and I don’t think I’d ever want to do something that risks breaking the program like that, but I guess that’s why I’m not a game programmer.
Picture the scene: you have a 102KiB executable game that you want to enter into the 96KiB-or-less game competition at a demoparty in 2 weeks time. You and your friends have been working on this for months. This amazing thing you have is currently 6KiB too large to qualify for the competition at all. What do you do?
Kkrieger specifically is a demo scene app with the goal of being as small as possible. It’s not indicative of overall game development practices as a whole.
No, you may have certain inheritance mechanisms that can only last for one or two generations. This is typically related to the fact that female mammals are born with all of the egg cells that they will ever have. So, any direct stressor applied to the mother during her life could affect her children & grandchildren (intergenerational), but it won't affect subsequent generations (transgenerational).
The way this can work is that stressors to the mother's organism can affect the development of children, especially stressors to a pregnant mother - so transmission to the next generation is clear (e.g. a starving pregnant mother may have more sickly children). Then, for daughters, their eggs may be directly impacted by this stressor, so that their own children, which come from those egged, may be impacted. However, these children won't carry any trace of that stressor, unless it is genetic in nature.
> AWS CloudFront pricing seems pretty competitive with other CDNs
Sure, but it's unlikely you actually have to place a CDN in front of your manual, it's mostly text with few images. People default to using CDNs way too quickly today.
Because caddy/nginx/apache (any web server really) can serve that content as well as any other? Better question is; why default to using more things before you actually need them?
Personally, software engineering for me is mostly about trying to avoid accidental complexity. People obsessing about "web scale" and "distributed architecture" before they even figured out if people actually want to use the platform/product/tool they've used tends to add a lot of complexity.
> Because caddy/nginx/apache (any web server really) can serve that content as well as any other?
That's not really true if you care about reliability. You need 2 nodes in case one goes down/gets rebooted/etc, and then you need a way to direct traffic away from bad nodes (via DNS or a load balancer or etc).
You'll end up building half of a crappy CDN to try to make that work, and it's way more complicated than chucking CloudFlare in front of static assets.
I would be with you if this was something complicated to cache where you're server-side templating responses and can't just globally cache things, but for static HTML/CSS/JS/images it's basically 0 configuration.
> That's not really true if you care about reliability
While reliability is always some concern, we are talking about a website containing docs for a nerdy tool used by a minuscule percentage of developers. No one will complain if it goes down for 1h daily.
With the uptime guarantees AWS, GCS, DO, etc. provide - it will probably 1h per 365 days accumulative (@ 99.99% uptime). 2 nodes for a simple static site is just overkill.
But, honestly, for this: just use github pages. It's OSS and GitHub is already used. They can use a separate repository to host the docs if repo size from assets are a concern (e.g. videos).
How is setting up a web server not using more things than you need when you could just drag and drop a folder using one of many different CDN providers? (Or of course set up integrations as you want)
Just because you're using a UI doesn't mean it isn't more complicated. I'm thinking "complexity" in terms of things intertwined, rather than "difficult for someone used to use GUIs".
It's really a tradeoff of saving time by paying more money. A lot of people chose it when they'd rather not pay more money and end up unhappy
A lot of other people also pick it for very narrow use cases where it wouldn't have been that much more time to learn and do it themselves and end up paying a lot of money and also aren't happy
It's pretty nice for mid-size startups to completely ignore performance and capacity planning and be able to quickly churn out features while accumulating tech debt and hoping they make it long enough to pay the tech debt back
A year ago I researched this topic for a static website of my own. All providers I looked at were $5 and I want to say the cheapest I found was slightly lower. By comparison, I am still within free tier limits of AWS S3 and cloudfront (CDN) since I am not getting much traffic. So my website is on edge locations all over the world as part of their CDN for free, but if I host on a single server in Ohio it costs $5/month.
An idle site that receives no hits still costs around $1.50/month with NearlyFreeSpeech.net since the change that limits the number of "non-production" sites that was instituted from around the time when Cloudflare decided to kick out the white supremacists.
> From the point of view of an 18th- or 19th-century person, for whom the purpose of the mint was to certify the value of the precious metal in the coin by stamping it
Was that the purpose of the mint? That would imply that the relative value of silver vs. copper was static.
It was, yes. The varying relative values of metals was in fact a huge problem for mints for many centuries. The problem was sometimes resolved by refusing to mint any but the priciest metal, and at other times by the values of different coins such as shillings and sovereigns varying relative to one another.
Yes, this was one of the major political controversies around the US mint in the 19th century and even the early 20th century: https://en.wikipedia.org/wiki/Free_silver
im talking about developers for example, that may need specific/old versions of php or node or whatever, which then get deprecated and uninstallable via brew as soon as they officially reach EOL. Or once installed, get forcefully and inadvertently updated by brew.
On the other side is some consumer who uses brew to install youtube downloader and doesnt care about versions/upgrades, etc...
If you are a developer who needs a specific old version of PHP or Node or whatever and you're not using Docker then I have great news for you on how you can solve your problem.
yes, docker is a great solution nowadays for this problem, but it wasnt always like that.
In PHP land there is a tool called Laravel Valet, which relies heavily on homebrew and lets you switch PHP versions on the fly directly your system.
I just remember how much of a pain it was to set up because of homebrew's unnecessary restrictions and deprecations.
But once done it worked quite well.
I personally use and enjoy Homebrew for most of my development tasks. The thing I would not use it for is to exactly simulate a specific combination of tool versions.
Yes. The package manager's job is to give you some sensible version of some useful common standardized thing(s) you want to use. There might well be some legacy/current/edge options, but overall you are putting your trust in their judgement and assuming that they'll do something at least vaguely sensible.
If you want something specific than that: the package manager cannot help you here. This is no longer some random thing that you just use; it's one of your product's honest-to-goodness dependencies. You can't outsource this any more. You need to make your own arrangements to ensure that the specific version required is in use.
It works until PHP officially EOLs the version. Then brew stops supporting it and you have to install some finicky 3rd party taps/repos to get the older versions. A huge pain...
In the real world there are still apps running PHP 7.4 and even older!
Homebrew not allowing users to install EOL versions of software with no security patches or updates is a _good_ idea. Just because a fraction of a tiny minority needs some ancient version of PHP doesn't make it a good idea.
yea, that's why it's not "pro" grade, and that's my point.
"pro" users need EOL version support because sometimes some client still didn't want to update his age old web app the newest node or python or whatever. sometimes it's not up to the dev himself, and he needs to make money either way.
so in the end brew makes decisions for the most common denominator, and that will be the user that uses it to install youtube-dl and nothing more.
“Pro” users are using containers, venvs, version managers (nvm, rvm, etc.). They definitely aren’t installing project-specific stuff directly to the system.
* Every Youtube video is playable on the Youtube music app.
* There is a liked videos playlist
Yes, I read your comment above.
Regarding the other two points, it is of course understandable why you'd want to download and have your own solution. But that is also obviously not an issue with Google engineers/PMs neglecting to think of a feature.
These passive aggressive posts are a far worse violation of the HN Guidelines than what they're in reply to almost all of the time - and this is no exception.
No, no they're not. I would much rather people are warned about the guidelines and adhere to them going forward than the opposite and we then just let violations run rampant.
That's confusing basic arithmetic as a user feature and as an implementation requirement.
I guarantee that computer vision and email clients both use basic arithmetic in implementation. And it would be trivially easy to bolt a calculator into an email app, because the languages used to write email apps include math features.
That's not true of LLMs. There's math at the bottom of the stack. But LLMs run as a separate closed and opaque application of a unique and self-contained type, which isn't easily extensible.
They don't include hooks into math features on the GPUs, and there's no easy way to add hooks.
If you want math, you need a separate tool call to conventional code.
IMO testing LLMs as if they "should" be able to do arithmetic is bizarre. They can't. They're not designed to. And even if they did, they'd be ridiculously inefficient at it.
> Pretty sure the only thing computer vision does is math.
That is only marginally less pedantic than saying that the only thing computer vision does is run discrete electrical signals through billions of transistors.
Yes, everything that a computer does, it does using math. This does not imply that things running on the computer can do basic arithmetic tasks for the user.
I'd imagine the pricing is quite disconnected from the price of "legitimate" bandwidth. But I don't know in what direction.
reply