tripflag

I've had luck ripping VCDs on Linux with vcdxrip -v -p -i /dev/sr0

Alternatively, first creating a bin+cue on windows with imgburn (ISO won't do!) and then vcdxrip -v -p -b the.bin -c the.cue

Having been such a popular format in Asia, a rich assortment of VCDs keep showing up at flea-markets in Norway; both original productions sold as VCDs, as well as "silvers", that is, exceptionally poor-quality pirated movies, often amusingly so. A popular example is "Star Wars: Backstroke of the West", with subtitles machine-translated from english to chinese, and then back to english.

VCDs, like DVDs, tend to have multiple audio tracks with different languages, even though the format doesn't actually support that technically. Take "yangtze three gorges" for example; a Chinese nature documentary with perfectly cheesy intros and outros. There was three "audio tracks"; the original Chinese, plus English and Japanese dubs. VCD only allows for a single audio track, so you find Chinese in the left channel, and English on the right. Televisions sold in Asia would have a toggle-switch on the remote to select one of the two audio channels to duplicate to both speakers.

Of course, having two dubs, the Japanese dub was made by having another copy of the whole video file, except with Chinese+Japanese.

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.

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.

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.