it's a tradeoff; mallocng does have benefits as well -- for example it uses less than half the amount of RAM compared to mimalloc and glibc for certain Python workloads. While yes it is a bit slower, I prefer mallocng in many cases.
I imagine there is no free lunch in the allocator space, but a series of trade-offs. Pick your poison on implementation which is going to be sub-optimal for some subset of use cases.
Without a hugely compelling reason to switch, going with the default is reasonable.
ripgrep is there to be FAST. Trading any speed to improve memory efficiency over a longer period of time for a process with a short life-time doesn't make sense in this case.
It's also a development tool. If your development machine is having RAM issues because it's doing a grep, you have bigger problems to solve.
As for other workloads that might use less RAM with mallocng compared to other performant ones, I'm curious to know about the magnitudes we're talking about. From 10MB to 20MB or from 100MB to 2GB? How was the speed of the program? Was there any multithreading involved?
For context, the Python workload was a general-purpose fileserver with file indexing and image thumbnailing, largely IO-bound. Switching from mallocng to mimalloc resulted in a slight speedup (150% of baseline), but over twice the memory usage, going from 250 to 670 MiB, primarily for thumbnailing. Some pathological cases (libvips calling imagemagick to decode heif) was a 10x multiplier.
There was multithreading, and yes, mallocng visibly became a bottleneck beyond 5 threads. However already at 3 threads there was diminishing returns for both allocators, so this was not an issue in this case.
The speed gain was hardly noticeable in practice since the program was already plenty fast, but the additional memory usage was a very real inconvenience.
Is that memory increase seen in peak usage or average/idle usage?
For file servers, I could be willing to give up 350 MB of memory temporarily for large-scale indexing and thumbnailing operations if it doesn't happen often and makes the file serving/browsing more responsive.
On the other hand, plenty of NAS/file server systems are going to have paltry CPU and memory. Running slower with a more modest memory foot print might be the only way to keep the system stable.
Cool! Out of curiosity, since qr-codes can contain binary data -- rather than base64, have you tried inserting the file as-is? That way you could do away with the ASCII separator and have a binary header as well. This would spend less frames for the same amount of data, but I'm not sure if it would be computationally cheaper. The other alternative would be the alphanumeric mode of qr-codes, but then you lose lowercase.
But what if you are leaving the page because you changed your mind, and don't wish to save the changes after all? This, for me, is the common case, so i would not want the browser to suddenly commit an unfinished draft.
If you’re worried about losing the old version, it should keep a history. If you want to erase the new version, there should be an explicit action to do that.
Aside from the 256-color section, I believe all of the examples given in the article are basic sequences which are supported in ~every terminal. Are you aware of any notable terminals where that is not the case?
Maybe I've been lucky, but I've written plenty software that blindly shoots CSI's at the console and still haven't hit any snags. Especially convenient when the channel is unidirectional; curl ocv.me :)
Shelll-mode in emacs uses $TERM=dumb and doesn’t support escapes code by default. Same with compile-mode. Also there’s some tools that persist using escapes code even when piped to another program (like less).
I have read that people still use 9term. Its terminfo entry doesn't show any sign of ANSI escape code support.
If I remember correctly, ANSI-like terminal emulators in RGB mode (aka direct mode) only support 16-color and red/green/blue escape codes. Not the 256-color palette used in this article.
ANSI-compatible terminal emulators widely disagree on whether RGB values should be separated by semicolons or colons.
I have read articles (possibly on hackaday) this decade by people working on retro hardware projects, expressing frustration with command line programs that spew ANSI garbage to their non-ANSI terminals. At least one author resorted to the screen program, because it can translate some ANSI-isms to the correct codes for the active terminal.
I had genuine TeleVideo 912 glass terminals hooked up until not terribly long ago.
In any case, I don't view this as a matter of whether unusual terminals are "notable". We have an abstraction that plays nicely with them (and allows new terminal protocols to be developed). It's a POSIX standard. It's easy to use. I suggest using it.
Hence my question -- my belief was/is that all of the escape-sequences mentioned in the article will work on 99.99% of all terminals, with the exception of 256-color. Assuming this is true, IMO the remaining 0.01% does not justify introducing another dependency (ncurses -> tput).
h264 still makes sense in some applications because it is relatively computationally cheap, and has very wide adoption in both software and hardware.
in the case of HEVC/h265, one of the main reasons today is Apple using that codec for photos (heif/heifs/heic/heics); it never came close to the popularity and adoption that AVC/h264 did. AV1 is superior to h265 in most ways; there is little technical reason to use hevc.
in my case, I use zed for almost everything, and vscodium for three things:
search across all files; easier to navigate the results with the list of matching lines in the sidebar, and traversing the results with cursor up/down, giving full context
git; side-by-side diff, better handling of staging, and doesn't automatically word-wrap commit messages (I prefer doing that myself)
editing files which have a different type of indentation than what is configured in zed, since zed does not yet have autodetect
Just to clarify that the 8 security announcements are not open issues; they are announcements that a new release has been made which fixed something security-related. I'm doing my best keeping a good track-record for fixing such issues in a timely manner, and the turnaround time for severe issues has so far been <=4 hours.
As for the open issues, 140 are feature suggestions, and 36 are currently classified as bugs. I'm hoping to start popping the list of bugs soon after I'm back home from my vacation which will be soon (am typing this from the airport waiting to board!)
> I'm hoping to start popping the list of bugs soon after I'm back home from my vacation which will be soon (am typing this from the airport waiting to board!)
Don't burn yourself out. This is some really good software and we need you around to maintain it :)
Ah, a small correction regarding this... What I /meant/ to say in the video was that a lot of the INITIAL code was written this way, so the statement is mostly true for v0.2.3. Since then I've primarily been using vscodium (and recently zed) on my linux laptop, but I still tend to do quick prototyping on the phone when i get a bugreport or a sudden idea.
That part of the video was recorded at 3am as I just wanted to "get it done", which also explains the other mistakes (typos, phrasing). I tried to replace the audio-track of the video when i noticed the phonecoding part after uploading, but turns out that's not really possible, so I figured what's done is done, impractical as it is -- I've been trying to offer this correction when I see it come up.
So my workflow right now is mostly zed and pyright+black, and no AI/LLM except for localization of new strings to languages I don't speak.
Microsoft has been making it harder to run their proprietary python plugin in vscodium, which I was relying on to provide hints from pyright. That's something I didn't want to deal with, so I just jumped ship.
There are some things I miss from codium, and I still capitulate back when editing files with nonstandard indentation because zed doesn't yet have autodetect for that, and also its git-staging / diff-view isn't as good yet, but aside from those it's a mostly alright experience.
Combining copyparty with Syncthing is not something I have tested extensively, but I know people are doing this, and I have yet to hear about any related issues. It's also a usecase I want to support, so if you /do/ hit any issues, please give word! I've briefly checked how Syncthing handles the symlink-based file deduplication, and it seemed to work just fine.
The only precaution I can think of is that copyparty's .hist folder should probably not be synced between devices. So if you intend to share an entire copyparty volume, or a folder which contains a copyparty volume, then you could use the `--hist` global-option or `hist` volflag to put it somewhere else.
As for high CPU usage, this would arise from copyparty deciding to reindex a file when it detects that the file has been modified. This shouldn't be a concern unless you point it at a folder which has continuously modifying files, such as a file that is currently being downloaded or otherwise slowly written to.
