gaul

https://tt-rss.org/ is a free software, self-hosted alternative and https://ttrss.info/ is a paid hosted offering.

Vaurien can do this:

https://github.com/community-libs/vaurien

clang's -Wshorten-64-to-32 can catch this:

https://clang.llvm.org/docs/DiagnosticsReference.html#wshort...

The more general-purpose -Wconversion has many false positives, often around int to char conversion. Some functions like int toupper(int) have an unexpected int return type to deal with special out-of-bound values like EOF.

This is not a NOP; it explicitly clears the upper 32 bits of EDI since the compiler does not know that they are zero in this situation. If you change cc from an int to size_t (long on x86-64) the compiler will generate:

        mov     eax, OFFSET FLAT:.LC0
        cmp     rdi, 258
        ja      .L1
        mov     rax, QWORD PTR CSWTCH.1[0+rdi*8]

Note that in some cases the compiler can do this automatically via lifetime analysis but not in this freestanding example.

Robert O'Callahan hashed some thoughts about Firefox that he revealed many years later:

https://robert.ocallahan.org/2018/01/ancient-browser-wars-hi...

HP Dynamo is similar to what you suggest:

https://www.hpl.hp.com/techreports/1999/HPL-1999-78.html

Note that CPUs and compiler optimization have improved over the last 20 years and these results may not still hold.

The article mentions 32-bit Raspbian which is moving to 64-bit to better support the Raspberry Pi 4 with 8 GB of RAM. Both the RPi 3 and 4 have 64-bit support but earlier models, including the popular and still-on-sale Zero, do not support 64-bit. This platform will likely stick around for a long time; we need to continue to fix issues like this size_t/off_t one in s3fs:

https://github.com/s3fs-fuse/s3fs-fuse/pull/1039

Thanks for testing! You may improve performance via increasing -o parallel_count (default="5"). Newer versions of s3fs have improved performance but please report any cliffs at https://github.com/s3fs-fuse/s3fs-fuse/issues .

This is great news for application developers! And probably hard work for the AWS implementors. I will try to update this over the weekend: https://github.com/gaul/are-we-consistent-yet

Could you expand on this comment? s3fs uses multiple threads for uploading and populating readdir metadata via S3fsMultiCurl::MultiPerform. Earlier versions used curl_multi_perform which may have hidden some of the parallelism from you.

This is not expected behavior. An older version had pessimized locking which preventing concurrently adding a file to a directory and listing the directory simultaneously which is the most similar symptom. I recommend upgrading to the latest version, running with debug flags `-f -d -o curldbg`, and observing what's happening. Please open an issue at https://github.com/s3fs-fuse/s3fs-fuse/issues if your symptoms persist.

I maintain mbpfan and have contributed to a few other Linux on Mac tools.

Linux on Mac is not worth the effort. I ran Ubuntu on a 2011 MacBook Air and now run Fedora on a 2014 MacBook Air. There were several papercuts even with these relatively open models where it took a while to get suspend, trackpad, fan, webcam, wifi, etc. working properly. You will need to use binary drivers for the latter two features and some strange EFI bootloader. It seems that newer MacBook compatibility is worse:

https://github.com/Dunedan/mbp-2016-linux

I use Debian on ThinkPad at work and plan to buy this or a Dell XPS for my next laptop.

Note that this laptop uses Kaby Lake based on the older Skylake design. Newer laptops use Sunny Cove based on Ice Lake and have improved single-core performance.

MacBook Air with M1 vs. XPS 13 with Tiger Lake i7-1165G7:

https://browser.geekbench.com/v5/cpu/compare/4306696?baselin...

Single core similar and multicore 50% better for MacBook.

Every talk should include a link to the slides at the beginning and end of the deck, preferably with a shortened URL. This allows live viewers random access but also improves recorded talks. I often want to evaluate the content of a talk to see if I should invest 30-60 minutes watching. This would also help users with accessibility needs.

This changed in 1.86 and I updated the README as follows:

> random writes or appends to files require rewriting the entire object, optimized with multi-part upload copy

Now changing one bit means re-uploading 5 MB, the minimum S3 part size.

Fixed; thanks for the feedback.