Completely depends on what you're doing. If you're doing a lot of sustained compute, or doing graphics, then yeah you're gonna want some cooling. But it's a useful little machine for all kinds of tasks which don't cause sustained high power consumption.
Two fried on me. One was just running a printserver without a case. It was in summer so ambient temperature was around 32C but still, you telling me you use rpi 5 without even a cooling case?
The Pi isn't great value, but honestly, I'm finding it hard to find a better trade-off between price, performance and software support right now than the compute modules for embedded projects where you can afford to spin a custom PCB. Especially for low-ish volume or prototype stuff.
I also love the compute modules for their size. Stick one on a nano base board and they’re half the size of a Pi 5. TBH the standard Pis are a bit frustrating with all of the IO. I do not believe the average purchaser is using one as a PC replacement and wants 4 USB ports and 2 HDMI ports. I’ve never seen one in use like that. They are mostly servers or driving a single display without any user input.
100% with you on the IO. I've never even wanted two display output ports with any raspberry pi.
You know what I do want though? An actual damn HDMI port! HDMI cables are everywhere, wherever I am I have unlimited options to connect an HDMI device to some kind of screen. But micro HDMI? The literal only thing in my life that uses it is the Raspberry Pi 4 and 5. There have been plenty of times where I've reached for a Pi 3b instead of a 4 or 5 just because I didn't have a micro HDMI cable.
I do not understand what has gone through their head. How could anyone look at the use case for a Raspberry Pi and decide that two micro HDMI ports is a better choice than one HDMI port? I don't understand it. Like you, my experience with the Pi is that they mostly just sit there, headless, so the only reason I need display output is that it's useful during setup (because they don't have a proper serial console port).
I can't set up a Pi 4 or 5 without going hunting for that micro HDMI cable I bought specifically for that purpose and never use for anything else. I can set up a Pi 3b anywhere, at any time.
The micro hdmi thing (which I too loath) is for digital signage and industrial machinery - we (home users) aren't the audience and haven't been for a long time.
Being able to run two sides of an advertising board, or two control panel screens on a big hunk of metal doing fabrication things in a factory was more important to Raspberry Pi as a business apparently.
Why he heck they didn't just go with 1x normal hdmi and 1x usb-c +DP for the Pi 5 is a mystery, perhaps the SOC doesn't support it or something.
Dockerfile has the flexibility to do what you want though, no? Use a base image with terraform or puppet or opentofu or whatever pre-installed, then your Dockerfile can just run the right command to apply some declarative config file from the build context.
And if you want something weird that's not supported by your particular tool of choice, you have the escape hatch of running arbitrary commands in the Dockerfile.
The loose integration between the declarative tools and the container build system drags down performance and creates a lot of footguns re: image size and inert declarative-build-system transitive deps left lying around, I’ve found.
Why would terraform leave transitive steps around? To my knowledge, Docker doesn't record a log the IO syscalls performed by a RUN directive, the layer just reflects the actual changes it makes. It uses overlayfs, doesn't it? If you create a temporary file and then delete it within the same layer, there's no trace that the temporary file ever existed in overlayfs, correct?
I'd get your worry if we were talking about splitting up a terraform config and running it across multiple RUN directives, but we're not, are we?
Random examples off the top of my head: Puppet has a ton of transitive Ruby libraries and config files/caches that it leaves around; Terraform leaves some very big provider caches on the system; plan or output files, if generated and not cleaned up, can contain secrets; even the “control group” of the status quo with RUN instructions often results in package manager indexes and caches being left in images.
Those are all technically user error (hence why I called them footguns rather than defects), but they add up and are easy mistakes to make.
Then you're committing to maintaining a package for that software.
Like all LLM boosters, you've ignored the fact that the largest time sink in many kinds of software is not initial development, but perpetual maintenance.
Is it though? If the way that I’m going to edit those files is by typing the same natural language command into Claude code, and the edit operation to maintain it takes 20 seconds instead of 10, to me that seems pretty materially the same
If the library just existed as a correct implementation of the RFC without bugs or significant missing features, that would be one thing. But leaving features and bug fixes already committed to the repository unreleased for years because the maintainer hasn't cut a new release since 2024 is a bad sign.
The data I operate on come in from the outside world, I can't operate on all of it because most of it doesn't exist yet. I can't process an event that hasn't happened yet
Most of us are not really doing detailed half-decade hardware purchasing plans, for most of us "the next few years" is really the only relevant time frame.
Right now I'm on a 2021 MacBook Pro, I'm debating whether to upgrade to the new M5 Pro laptops or to wait until next year; so that's 5-6 years. My desktop gets upgraded over time, so it's not really on a "cycle"; it's more that every few years, I may decide to get a more powerful CPU, or more RAM, or a new GPU, or more storage, or whatever else. Though I recently (as in, during the past year) upgraded from an AM4 CPU to an AM5 CPU, so that meant I replaced more than usual; everything other than the GPU, storage, power supply and peripherals. (I switched from ITX to mATX for an extra PCI slot so the case had to go; though it still lives on in the form of a lab PC of sorts, along with my old i7 6700k)
But common among all these replacements is that they're not really planned in detail years before. I may weigh up factors like "I don't really need an upgrade right now" against factors like "the market looks like it'll probably get really shitty later this year", or "I could really really use an upgrade right now" against "but the market is shitty now and we're right before a product launch which will shake things up". But I always react to my current or near-future needs/wants and current or near-future market conditions.
So hearing "the RAM market will be good again in 5 years" is completely irrelevant to me. My decisions are entirely based around how the RAM market is right now and how I believe it will look throughout the year or the next.
> (“Zed,” “we,” or “us”) and our website at www.zed.dev, along with our downloadable Zed software (the “Software”) and related subscription service (the “Service”).
Very clearly draws a distinction between the editor (the "Software") and their subscription service (the "Service")
> Customer must be at least 18 years old to use the Service.
Is very clearly referencing the subscription service (the "Service") and not the editor (the "Software")
Notice how I did not quote the "Customer must be at least 18 years old to use the Service" part. That sentence is completely non-problematic. The part that's a problem is the part I actually quoted:
By agreeing to these Terms, Customer represents and warrants to Zed that: (a) Customer is at least 18 years old
The "Terms" is earlier defined to mean:
these Terms of Service, the Data Processing Addendum (“DPA”), available upon request, and Zed’s Privacy Policy
So the Terms you have to agree to in order to download the editor, clearly state that by agreeing to the Terms, you warrant that you're 18+. ("Customer" is defined to be a synonym for "You", FWIW).
You cut it off literally just before it specified what that sentence is referring to...
> Customer must be at least 18 years old to use the Service. By agreeing to these Terms, Customer represents and warrants to Zed that: (a) Customer is at least 18 years old
THE SERVICE
> (“Zed,” “we,” or “us”) and our website at www.zed.dev, along with our downloadable Zed software (the “Software”) and related subscription service (the “Service”).
Yes, and you have to agree to the terms of that service in order to use the editor.
Those terms could've just been, "you must be 18+ years old to use the service", and everything would be just fine. But they're not.
"The Terms" is defined to include the ToS document found at https://zed.dev/terms, which are the very terms you need to agree to if you want to comply with https://zed.dev/download. If you cannot accept "the Terms", you cannot download and use Zed. And you cannot agree to "the Terms" if you're under 18 years old. This is not complicated, it should not be difficult to understand.
> (“Zed,” “we,” or “us”) and our website at www.zed.dev, along with our downloadable Zed software (the “Software”) and related subscription service (the “Service”).
Very clearly draws a distinction between the editor (the "Software") and their subscription service (the "Service")
> Customer must be at least 18 years old to use the Service.
Is very clearly referencing the subscription service (the "Service") and not the editor (the "Software")
I did not quote "Customer must be at least 18 years old to use the Service" because I, like you, don't find it to be a problem. I don't know why you're saying it back to me. I quoted a different sentence, namely "By agreeing to these Terms, Customer represents and warrants to Zed that: (a) Customer is at least 18 years old", because I think that sentence is a problem. I would appreciate if you would discuss the part of the ToS which I referenced instead of an irrelevant part which I haven't brought up.
reply