Am I the only person wondering why we need 100 terminal emulators when there are only 2 or 3 solutions to using command line tools more like a REPL? (to some degree warp, some bash support in hydrogen, advanced edit mode of powershell) I don't care for using "fancy" TUIs all i want is better tooling to interact with these that does not feel like 1970 and more like the chrome console.
> I saw tradeoffs that I didn't like. I saw features that I wanted. I saw performance that I could improve. I saw stagnation. There are many fantastic terminals out there and you should use them if they work for you. But I wanted something different and thought maybe others did too.
This motivation is pretty clearly stated in the article.
Some people use "fancy TUIs" (the famous editors vim and emacs surely count) and if you don't, feel free to ignore this new option.
Unfortunately, launching a fancy TUI like lazydocker inside a fresh install of Ghostty will make the TUI exit with an error, when the same TUI runs just fine on iTerm, alacritty, etc.
Thats why bugs and chores have 0 points per default in pivotal tracker. Thats also why there was a push to force us say "as a user i..." at the beginning of story descriptions to make sure this is something creating user value. With these guards in place i don't follow the argument that productivity is not measurable, if a team builds features that solve an expressed user need and lets even say go through a final user acceptance check, this is a productive process and it is also very measurable!
Congrats! Also please note we have a community discord keeping track of all the cloning efforts and possible replacements for pivotal tracker here: https://discord.gg/4NVRXAeYVa
Welcome to the club! The race is on, i think including me at least 4 individuals / teams are on this. I made a "pivotal tracker community" discord server if anyone wants to have an ongoing conversation and keep track of the different cloning/ open sourcing efforts.
Totally agree with this article, and this is about collaborative text editing, which is something these solutions and algorithms are actually good at. Looking at everything from crdt fanboys applying this to application data and ignoring the UI/UX aspects about conflict resolution makes my neck hair stand up. This is how we end up with linear giving talks about their "sync engine" and happily deleting other users changes with last write wins.
I don't think they're ignoring it, they've just been focusing on solving the algorithmic problems before diving into UX problems. Loro, for instance, has recently shifted their focus towards conflict merging following their 1.0 release. It's simply a question of building a solid foundation before making it user friendly.
(Automatic) Conflict merging as crdts usually see it is not the same as a full meaning preserving conflict resolution. There is no way an algorithm can always solve a merge conflict without user input or at least custom application level resolution logic. You cannot add this as an afterthought to some automatic crdt. If you search loros docs there is no result for an api to tell it how to resolve a conflict and this is true for most of these systems. Automerge has something but its not fully exposed and quite usable afaik. Again this is fine for real time text collaboration but not for usage for application data.
The simple litmustest to understand what i mean is this:
You rename a todo changing its meaning and concurrently mark it as done. Can you tell the sync engine to always disregard the marking as done in case of changing the text. If there is no api for this to fully control the merge semantics, your system is not suitable for application data.
I have to say, this is perfect execution. Now, if cloudflare made an equally great Oxyd inspired game the marble game sentimentalist edge computing nerds among us would be content.
The one thing i was hoping for from civet is the trailing closure syntax from swift, which would make jsx less needed and make similar dsl usage way more convenient. There is absolutely a place to get real world experience with syntax that did not make it or is not ready yet to be moved forward in standardisation.
never heard of oxen but it looks like a super interesting alternative. would love to hear from someone who has experience with both.
my first impression: dvc is made to use with git where there are arbitrary folders handled by dvc INSIDE your git repo, where oxen is an alternative for a separate data repo. also oxen has lots of integration with dataframes and tabular, ai training and infernece data that dvc is missing. on the other hand dvc has a full DAG pipeline engine integrated as well as import/ export and pluggable backends.
