It loads instantly, and memory usage is minimal <80 MB.
It does seem like vlf requires configuration and adjustment, e.g. navigation with the normal keys works differently (jumps to beginning/end of current chunk instead of the whole file). Basically it exposes the chunk concept to the user.
In Fresh it's designed into the core and should be more transparent (although there are still limitations).
And don’t hesitate to use a JRE (Java Runtime Environment) if all you need is to run java/jvm applications - assuming the application doesn’t already ship with its own runtime. A JDK is roughly 140 MB, while a JRE is about 60 MB (and can be further minimized). I’ve seen installations of the full OpenJDK just to run apps, which is unnecessary in most cases.
From the ping output, I can see HN is using m5hosting.com. This is why HN was up yesterday, even though everything on CF was down.
> Writing high-throughput web applications is easier than ever. Hosting them on the open web is harder than ever.
Writing proper high-throughput applications was never easy and will never be. It is a little bit easier because we have highly optimized tools like nginx or nodejs so we can offset critical parts. And hosting is "harder than ever" if you complicate the matter, which is a quite common pattern these days. I saw people running monstrosities to serve some html & js in the name of redundancy. You'd be surprised how much a single bare-metal (hell, even a proper VM from DigitalOcean or Vultr) can handle.
IMHO it adds, but only if you are big enough. Netflix level. At that level, you go and dine with Bezos and negotiate a massive discount. For anyone else, I’d genuinely love to see the numbers that prove otherwise.
> There's zero personal responsibility
Unfortunately, this seems to be the unspoken mantra of modern IT management. Nobody wants to be directly accountable for anything, yet everyone wants to have their fingerprints on everything. A paradox of collaboration without ownership.
Cloud providers have formalized these deals actually. If you promise to spend X amount over Y period, you get Z discounts.
And this is not reserved instances, this is an org level pricing deal. Some have been calling it anti-competitive and saying the regulators need to look at the practice.
> IMHO it adds, but only if you are big enough. Netflix level. At that level, you go and dine with Bezos and negotiate a massive discount. For anyone else, I’d genuinely love to see the numbers that prove otherwise.
It adds if you're smart about using resources efficiently, at any level. And engineer the system to spin up / spin down as customers dictate.
For situations where resources are allocated but are only being utilized a low percentage (even < 50% in some cases), it is not cost effective. All that compute / RAM / disk / network etc. is just sitting there wasted.
a16z is heavily long on AI, so this article sounds very biased.
From the article: If you live in the United States today, and you accidentally knock a hole in your wall, it’s probably cheaper to buy a flatscreen TV and stick it in front of the hole, compared to hiring a handyman to fix your drywall.
Probably because the US has been focused on services for years rather than physical goods production. Everything else in US is focused on importing cheap(er) goods or materials.
> On the other hand, I think he wants to push the narrative that AI is seeing enormous productivity gains.
That is my impression as well. I would be thrilled to see this mythical 10x productivity. Even with 2x productivity, I would be highly pleased. This should mean developers (and everyone else) are producing 2x more quality, software (and general services) are 2x better? I see none of that, except 2x more junk. Did AWS, GCP, or anything else become 2x cheaper and 2x more stable? Maybe I'm living under a rock.
Also the initial claim is just false — “if you live in the United States today, and you accidentally knock a hole in your wall, it’s probably cheaper to buy a flatscreen TV and stick it in front of the hole, compared to hiring a handyman to fix your drywall“. I can tell you that this isn’t true in San Diego. Unless they’re using flatscreen tvs that cost less than $300? Or perhaps making extremely difficult-to-patch holes somehow
I live in the UK, and it’s basically £100 to get a tradesperson to show up to my front door regardless of what I want them to do. I can buy a flat screen TV from £100 new from one of the UK high street retailers [1] , or £85 [2] if I go on Amazon
This is true in pretty much every western country sadly.
TV's are really absurdly cheap (and awful) on the low end, we're not talking about your 60" LG OLED with AI TV here, we're talking: a screen with maybe 720p and a viewing angle of: dead centre.
Hiring a handyman is, what, $100/h in most countries, then there's a minimum call-out fee and materials cost- worse "I don't have the part". You're looking at about $300~ easy.
Huh, i stand corrected, thanks! I think this brings both options to similar prices, so at the very least the spirit of the quote is true. Here’s my math:
- My handyman changes $50/hour, but if you find a new person maybe they charge $75-$100/hour
- materials are cheap, probably like $50 total for mud and drywall, or a repair kit
- with two hours labor, the total should be somewhere from $150-$250.
- if the handyman won’t accept a job less than 4 hours, the range is $250-$450.
> From the article: If you live in the United States today, and you accidentally knock a hole in your wall, it’s probably cheaper to buy a flatscreen TV and stick it in front of the hole, compared to hiring a handyman to fix your drywall.
This also isn't true?
It costs almost nothing to patch drywall. You can also do this yourself. Unless the point they're making is "TVs are so cheap, you can mount a TV inside of the drywall for less money than it would cost to fix," which also isn't true.
In America, all of that other than the paint is available at the dollar tree. You're looking at ~$7 to fix the hole (spackle, mesh tape, trowel, sandpaper, paintbrush) and $12 to buy a pint can of matched paint, as long as the hole is smaller than your fist.
Larger you would need to add in a $20 patch panel of sheetrock, a razor knife or other sheetrock saw (could probably use the bread knife in a pinch) and a hammer and nails, so closer to $50 all in.
that said, now I realized I have a door with two pictures screwed to it, because we punched a hole through it more than a decade ago during a house party, and that specific door is out of production, and it's the door to the storage room so it was (and still is) the perfect solution :)
Walmart has $22 mounts that will work for that $74 TV, and Walmart has TV installation service for $79 (basic mounting of a customer supplied TV with a customer supplied mount).
AFAIK, AGPL is no-go for EPL/Apache-licensed projects, unless the whole project is under (A)GPL, or use some "exceptions" wording. Wrt Redis community, it's the shadow of the former itself, everyone who plans to invest in Redis long-term, moved to Valkey.
> The general setup for the largest players in that space was haproxy in front of nginx in front of several PHP servers in front of a MySQL database that had one primary r/w with one read only replica.
You'd be surprised that the most stable setups today are run this way. The problem is that this way it's hard to attract investors; they'll assume you are running on old or outdated tech. Everything should be serverless, agentic and, at least on paper, hyperscalable, because that sells further.
> Today at AWS, it is easily possible for people to spend a multiple of the cost of that hardware setup every month for far less compute power and storage.
That is actually the goal of hyperscalers: they are charging you premium for way inferior results. Also, the article stated a very cold truth: "every engineer wants a fashionable CV that will help her get the next job" and you won't definitely get a job if you said: "I moved everything from AWS and put it behind haproxy on one bare-metal box for $100/mo infra bill".
> The problem is that this way it's hard to attract investors; they'll assume you are running on old or outdated tech. Everything should be serverless, agentic and, at least on paper, hyperscalable, because that sells further.
Many do. For most it's not the biggest concern (that would be quite weird). AFAIK it's mostly about reducing risk (avoiding complete garbage/duck taped setups)
Source: I know a person who does tech DD for investors, and I've also been asked this question in DD processes.
> You have to learn about what the insane move semantics are (and the syntax for move ctors/operators) to do fairly basic things with the language
That is simply not true. You can write a lot of C++ code without even touching move stuff. Hell, we've been fine without move semantics for the last 30 years :P
> Overloaded operators like operator*() and operator<<() are widely used in the standard library so you're forced to understand what craziness they're doing under the hood
Partially true. operator*() is used through the standard library a lot, because it nicely wraps pointer semantics. Still, you don't have to know about implementation details, as they depend on how the standard library implements the underlying containers.
AFAIK operator<<() is mainly (ab)used by streams. And you can freely skip that part; many C++ developers find them unnecessarily slow and complex.
> Basic standard library datatypes like std::vector use templates, so you're debugging template instantiation issues whether you write your own templated code or not.
As long as you keep things simple, errors are going to be simple. The problem with "modern C++" is that people overuse these new features without fully comprehending their pros and cons, simply because they look cool.
> operator<<() ... widely used in the standard library
Not that widely. You must be thinking of the IO streams part of the library. Yes, it's rather poor in many respects. But you don't have to use it! We have perfectly nice variadic printing functions these days!
auto number = 42;
std::println("Hello, {}! The answer is {}", "world", number);
std::println dates to C++23. This is very recent. You only have to be using Clang 18 (March 2024) or older to find the feature unsupported: https://godbolt.org/z/xPqYafhss (Clang 19 dates to September 2024, only a year ago.)
In contrast, the standard C++ stream types have used operator<< overloading for more than 25 years. glog/gtest assertions continue to use it.
I said "these days"... C++ is an evolving language. And while it doesn't throw things away, it does collect enough "stuff" that you can choose to write nicer and more straightforward code than before.
> Contributors and maintainers often have less power than even the smaller companies, and users have less power yet.
If contributors/maintainers are not happy with what the small company does, they can fork the project (assuming a liberal license) and continue in their own way. Valkey is a good example (with an interesting twist of license dynamics where Redis can use Valkey code now, but not the other way around).
> We have built a world where it is often easiest to just use whatever a cloud provider offers
And, IMHO, this is the major problem in the dev community these days - we've become lazy and focused on nonsense ("pretty"/unusable UIs, web gymnastics, llm, "productivity" etc.). We didn't have problems in the past to fork or reimplement OSes (various BSD instances), compilers (gcc versions), databases (MariaDB), and so on. There are tons of geniuses around hacking on cool stuff, but, sadly, the loudness of various hipsters and evangelists limits their visibility.
> Those providers may not contribute back to the projects they turn into services, though, upsetting the smaller companies that are,
The significant contribution that these providers (AWS, et al.) make to these projects is often overlooked - free advertisement. If I can remember correctly, ElasticSearch got popular when AWS started to offer it as a service. Additionally, cloud providers usually contribute (by employing core developers, shipping patches or testing) to the kernel, gcc or jdk, from which these small companies benefit significantly. In contrast, they themselves could do none of this.
But it is easier to blame "big scary clouds" than to rethink your business model. Be honest, start closed; no one will touch that and no one will be standing in your way.
Now try opening it in Emacs with vlf [1] ;) Great work overall — looking forward to seeing further development!
[1] https://elpa.gnu.org/packages/vlf.html
reply