> Ghostty 1.3 will continue the focus of making Ghostty the "best existing terminal emulator" by shipping the last remaining major missing features to achieve parity with other popular terminal emulators. Namely, we plan on shipping scrollback search and scrollbars for 1.3, at a minimum.
Are scrollback and scrollbars that hard to implement? Or do people just don't care that much about them that they are only added in 1.3?
I tried using various terminal emulators which don't support scrollback and scrollbars with tmux (which apparently most people do as a substitute). However for me that falls apart as soon as you SSH to a remote host and need to use tmux there as well. Maybe I'm just a console-noob...
There's no scrollbar but scrollback works with alt+page_up or scrolling with the mouse wheel or touchpad. They do mention they'll implement scrollback search and scrollbars in 1.3.
It’s enabled in Firefox (pref security.OCSP.enabled defaults to 1¹), but not forced (pref security.OCSP.require defaults to false²). I believe Safari behaves the same way.
—though I’m not sure how this fits in with https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co... which said “we will be disabling OCSP for domain validated certificates in Firefox 142”. This is a stunningly fuzzy area where the true and accurate information is difficult to come by.
> “we will be disabling OCSP for domain validated certificates in Firefox 142”. This is a stunningly fuzzy area where the true and accurate information is difficult to come by.
Doesn't seem all that fuzzy to me? Domain validated certificates are certificates where only domain name ownership is verified (like ACME does for Let's Encrypt). So it seems starting with Firefox 142 OCSP would be disabled by default for Let's Encrypt certificates.
The pref defaults don’t match that narrative. The blog post could be wrong, the prefs could have been repurposed without being renamed, something else… and the whole thing is very difficult to inspect.
I agree with most of what your saying but could you clarify what you mean with:
> by deliberately not choosing to do some things that made the 2012/2016 XCOM games fun out of a sense that they were too "dumbed down".
Because the way I experienced it, is that it was quite clear Phoenix Point was also meant to be playable on a console. For example compared to the original X-com's inventory management was dumbed down.
I wouldn't say it was rubbish, but I will say I was disappointed with it (as a life long XCOM fan). Primarily because the microgame (tactical squad based combat) was good but the macro game (the strategical game in the world overview) was weak. Base building was basically non-existent compared to the original XCOM games. Instead you stumbled across existing bases and "build" on of 3 facilities in them. The research tree was weak. A DLC introduced the "shooting down UFO's"-mechanic but overall all of the DLC was just focused on more different enemies and story lines and did very little to improve the worldview game.
Also Oxide just raised a $100 million series B with their illumos based product [1].
While I respect Brendan I think the arguments he makes are kinda weak. For example take OpenZFS. OpenZFS on Linux or FreeBSD isn't that great;
OpenZFS on Linux is only an option if you want to support the compatibility. As long as OpenZFS can't have (parts) inside the main Linux kernel source tree there is going to be breakage on updates. Which means manually testing and maintaining updates. Or you have to confine yourself to Ubuntu because they are of the opinion you can combine the CDDL and GPL. Don't think Ubuntu indemnifies you against an Oracle lawsuit though.
You could use FreeBSD as an alternative. FreeBSD is great, but lacks a lot of functionality. For example a good I/O scheduler is missing in FreeBSD. The FreeBSD I/O scheduler will basically just do what is most advantageous for it. If you have competing I/O workloads which you want to serve "fairly" there is no way to do that on FreeBSD. Basically the load which "pulls the hardest gets the most".
This is really good for them, and I do hope they do succeed, but if it's a matter of an individual developer deciding on their optimal area of systems expertise, this is still putting too many eggs in a single basket.
The reality is that even Oxide.Computer clients would still be running Linux on their machines.
So, as an engineer, you're literally shooting yourself in the foot by NOT moving to Linux, when everyone else has.
I think it's a standard sunk cost fallacy here. Some of us continue using BSD, but others switch to Linux and go work at Google, Meta, Amazon and even Oracle and Netflix, at 2x to 4x+ the income we get as BSD and Solaris devs.
> Adding in a stick of metal that can be trivially bypassed does nothing to make the car more secure.
Everyone can use a flipper zero to unlock a car. Not everyone can hotwire a car. Keyless ignition means criminals have a vastly larger recruitment pool of people they can offer money to do something stupid (like stealing a car for them).
> Everyone can use a flipper zero to unlock a car. Not everyone can hotwire a car.
You live in a tech bubble if you really think this is the case. Attacking a lock cylinder is a lot lower-skill of an attack than a cryptographic attack. Recent car theft epidemics have shown this, e.g. #kiaboys
> You live in a tech bubble if you really think this is the case
Everyone can operate a flipper zero with a custom firmware which provides a three step process:
* Select car make.
* Press button A to unlock doors.
* Press button B to start car.
> Attacking a lock cylinder is a lot lower-skill
All "recent" cars (as in everything from about 2000 and up) have an immobiliser. It's even mandatory in some countries since about 2000 [1]. Meaning the key "talks" to the car when you turn it in the lock cylinder. Locking picking the lock or hot-wiring the car isn't going to start the car. And that's not even taking into account the car alarm will go off if you just lock pick a lock on it.
In the grand scheme of things, very few people have flipper zeros. Few even know what they are.
Meanwhile, I think a pretty high percentage of households have a screwdriver.
> All "recent" cars (as in everything from about 2000 and up) have an immobiliser
You mean some kind of wireless communication protocol that can be hacked with some kind of handheld SDR device? Why is a keyless entry trivially bypassed but an immobilizer transponder, gee, that's just impossible to hack.
Everyone can operate a flipper zero with a cusom firmware which could bypass a transponder. So then all you need is the flipper zero and a screwdriver. Wow such better security for the hassle of having to actually stick the key in the hole every time.
I'll still take the keyless option. If someone really wants in my car, they're getting in. If they really want to steal it, they'll steal it. Requiring the thief to have an RF hacking tool and a screwdriver just isn't that much higher security in the end IMO.
You’ve missed the point by leaning into your pedantry. The point is that from the perspective of vendor/platform risk (things like account closure, billing disputes, etc), all of AWS is the same basket, even if you use multiple regions and services.
I dismissed the claim that they share a single control panel across services because it is false.
I dismissed that claim alone and talked about nothing else. The comment I replied to added nothing to the conversation except an unsubstantiated and plainly false remark.
> Wild that people don't realize that these "separate" systems in AWS all share things like the same control plane.
This comment does not say anything about all being in one basket. It only claims that all services run the same control plane which is so far from truth it must have been made from somebody utterly unaware of how big cloud teams operate.
Seems that this community has lost the ability to reason and converse and would rather be outraged.
Do all these cells and control planes run different software built by different teams?
I mean, sure every Ford Pinto is strictly it's own vehicle, but each will predictably burst into flames when you impinge its fuel tank and I don't wanna travel on a company operating an all Pinto fleet.
If you're not sure why someone is being downvoted, there's a good chance there is a misunderstanding somewhere, and a good way for you to understand is to wait for people to comment, and then read those comments.
Alternatively (and in a more general sense), if you want to take a more active role in your learning, a good way to learn is to ask questions, and then read the answers.
Oh I love it, I drew some inspiration for rotary encoder options from here actually. It reminds me of the older Senic Nuimo from about 10 years ago with a similar goal.
Reusing the Nest is about keeping bill of materials cost very low by reusing old hardware, and not complicating the supply chain with PCB manufacturing plus 3d printing plus metal CNC.
I get why they want that. Otherwise every time they want to do something "out of the box" with Minecraft they have to go through corporate and IP lawyers first.
The only thing they couldn't do with C418's music, was to publish "Minecraft: the official soundtrack" and take all the royalties themselves. Nor could they claim YouTube videos for having Minecraft's original music in it (they did it several times "accidentally" when the movie came out, and stole a couple of million from YouTube makers).
So no, I don't buy the "they'd have to go through lawyers" excuse. They could still have had blanket licenses for using the music in all sorts of ways, they just wouldn't own it.
Are scrollback and scrollbars that hard to implement? Or do people just don't care that much about them that they are only added in 1.3?
I tried using various terminal emulators which don't support scrollback and scrollbars with tmux (which apparently most people do as a substitute). However for me that falls apart as soon as you SSH to a remote host and need to use tmux there as well. Maybe I'm just a console-noob...
reply