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.
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).
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 :)
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
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.
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!)
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.
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.
> I also miss Filerun's "Request a file" feature which worked very nicely if you just wanted someone to upload a file to you and then be done.
With the disclaimer that I've never used Filerun, I think this can be replicated with copyparty by means of the "shares" feature (--shr). That way, you can create a temporary link for other people to upload to, without granting access to browse or download existing files. It works like this: https://a.ocv.me/pub/demo/#gf-bb96d8ba&t=13:44
Yup, this is 97% just me hacking away in vscode -- I use pylance and the debugger but have everything else disabled, easier to focus that way. The only time I use any sort of AI/LLM is for translating new strings into Chinese, since it seems decently capable at that :-)
The remaining 2% is friends coming up with new usecases/features, and sometimes finding bugs.
But now that the project got way more attention than I'd anticipated, pullrequests have started appearing, so it doesn't look like those statistics will stay true for much longer! Really cool having more eyes on it spotting the things I overlooked, really enjoying that.
it's also inconvenient for Norwegians and Danes, since Ø is part of our alphabet. Slightly jealous of Sweden since they write it like Ö instead... Either way, big fan of dotted zeros for that reason.
To be fair, it has been persistently offline for the past year or so every time I checked, so I'm not surprised that other people would jump to the same assumption.
I recall towel.blinkenlights.nl mentioned you would get a different version of the video (with colors) if you connected from IPv6. I've found rips online of the plain grayscale version, but not the colored one.
if you stop sending data entirely, browsers tend to drop and reopen the connection after a few minutes, assuming something got stuck along the way. Throttling seems to prevent that nicely.
Yep, and the server bandwidth can become a bottleneck if the peers are fast enough, so true peer-to-peer is still the better choice, or something webtorrent-based if multiple people are grabbing the same file.
But there's been enough last-minute submissions of DJ material by now that I'm still happy it was added as an option :-)
> There are services which allow you to upload via CLI and download via web browser, but they host your file so you have to wait for the full upload to finish before sharing the link.
There are exceptions to this; I've been making copyparty[1], an httpd which lets you start downloading a file that is still being uploaded[2]. If you catch up with the uploader, it'll throttle the speed so the browser doesn't drop the connection. Uploads and downloads can be done through browser and/or cli.
I recall there was at least one other alternative with similar functionality somewhere on the awesome-selfhosted list, but I'm failing to find them right now... It was prominently mentioned in the project's readme, but maybe that's no longer the case.