From Newsgroup: comp.os.linux.advocacy

On Mon, 19 Oct 2026 10:21:53 -0400, Tom Elam wrote:

I never saw Windows free space behave like this. Looks to me like
MacOS is very aggressively using SSD space to speed up operations
then cleaning out temp data as free space is needed.

On Unix-type systems, there are commands you can use to narrow down
where the disk space is going. I don’t suppose Apple has anything like
this ...
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 2026-10-19 19:09, Lawrence D’Oliveiro wrote:

On Mon, 19 Oct 2026 10:21:53 -0400, Tom Elam wrote:

I never saw Windows free space behave like this. Looks to me like
MacOS is very aggressively using SSD space to speed up operations
then cleaning out temp data as free space is needed.

On Unix-type systems, there are commands you can use to narrow down
where the disk space is going. I don’t suppose Apple has anything like
this ...

As usual, you have no clue.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Oct 19, 2026 at 7:09:29 PM MST, "Lawrence D´Oliveiro" wrote <11b6igp$2k9iq$[email protected]>:

On Mon, 19 Oct 2026 10:21:53 -0400, Tom Elam wrote:

I never saw Windows free space behave like this. Looks to me like
MacOS is very aggressively using SSD space to speed up operations
then cleaning out temp data as free space is needed.

On Unix-type systems, there are commands you can use to narrow down
where the disk space is going. I don’t suppose Apple has anything like
this ...

I know you post stuff like that just for attention, but macOS has du, tmutil, etc. But you knew that and are just pushing your schtick.
--
It's impossible for someone who is at war with themselves to be at peace with you.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Oct 19, 2026 at 7:16 PM, Alan wrote in 11b6it3$2ke6k$[email protected]:

On 2026-10-19 19:09, Lawrence D’Oliveiro wrote:

On Mon, 19 Oct 2026 10:21:53 -0400, Tom Elam wrote:

I never saw Windows free space behave like this. Looks to me like
MacOS is very aggressively using SSD space to speed up operations
then cleaning out temp data as free space is needed.

On Unix-type systems, there are commands you can use to narrow down
where the disk space is going. I don’t suppose Apple has anything
like this ...

As usual, you have no clue.

See, on a lot of stuff we agree.
--
It's impossible for someone who is at war with themselves to be at
peace with you.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 20/10/2026 04:09, Lawrence D’Oliveiro wrote:

On Mon, 19 Oct 2026 10:21:53 -0400, Tom Elam wrote:

I never saw Windows free space behave like this. Looks to me like
MacOS is very aggressively using SSD space to speed up operations
then cleaning out temp data as free space is needed.

On Unix-type systems, there are commands you can use to narrow down
where the disk space is going. I don’t suppose Apple has anything like
this ...

Which command would you like to use? I can check ;-)
--
Static tumblelog generator: https://github.com/john-bokma/tumblelog/
Available as Python or Perl. Example tumblelog: https://plurrrr.com/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 2026-10-19 10:09 p.m., Lawrence D’Oliveiro wrote:

On Mon, 19 Oct 2026 10:21:53 -0400, Tom Elam wrote:

I never saw Windows free space behave like this. Looks to me like
MacOS is very aggressively using SSD space to speed up operations
then cleaning out temp data as free space is needed.

On Unix-type systems, there are commands you can use to narrow down
where the disk space is going. I don’t suppose Apple has anything like
this ...

Such a thing would be useless considering that most of the Macs come
with a single storage device.
--
CrudeSausage
MacBook Air M4 Sky Blue
iPhone 13
Friendly Apple zealot
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 20/10/2026 15:48, CrudeSausage wrote:

On 2026-10-19 10:09 p.m., Lawrence D’Oliveiro wrote:

On Mon, 19 Oct 2026 10:21:53 -0400, Tom Elam wrote:

I never saw Windows free space behave like this. Looks to me like
MacOS is very aggressively using SSD space to speed up operations
then cleaning out temp data as free space is needed.

On Unix-type systems, there are commands you can use to narrow down
where the disk space is going. I don’t suppose Apple has anything like
this ...

Such a thing would be useless considering that most of the Macs come
with a single storage device.

But one still wants to know where the space is going on a single disk,
right?
--
Static tumblelog generator: https://github.com/john-bokma/tumblelog/
Available as Python or Perl. Example tumblelog: https://plurrrr.com/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 10/20/26 9:59 AM, John Bokma wrote:

Such a thing would be useless considering that most of the Macs come
with a single storage device.

But one still wants to know where the space is going on a single disk, right?

Absolutely. I bought this MacBook with "only" 512 GB knowing that I
would need to use my 4 TB external to keep my YouTube content long term.
It's about 400 GB of video files alone.

However, I was amazed to see how fast free space was disappearing when
editing my latest content. I was working with 2 large video files where
all I needed was the first and last few minutes on each. Those plus some stills, smaller video clips and several voiceover tracks. As I put them
in the video/audio tracks and edited it all my free space went away in
big chunks. About 100 GB free vanished in under an hour. With those
large video files uploaded I had about 160 to start, but close to 200 is normal.

It became a hot mess to sync it all as a single end product so
eventually I divided it all up into 4 short segments that were stitched together into the final 12 minute version. That was uploaded direct to
YouTube from the video editing app.

Once the entire folder was offloaded to the external drive within a few minutes reported free space popped up to over 200 GB. At this moment
it's 257 GB free.

Lesson? If you want to create any video content involving large files on
a Mac go for at least a 1 TB drive. Maybe more. Editing eats disk space
like crazy! At least with VideoPad.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 2026-10-20 9:59 a.m., John Bokma wrote:

On 20/10/2026 15:48, CrudeSausage wrote:

On 2026-10-19 10:09 p.m., Lawrence D’Oliveiro wrote:

On Mon, 19 Oct 2026 10:21:53 -0400, Tom Elam wrote:

I never saw Windows free space behave like this. Looks to me like
MacOS is very aggressively using SSD space to speed up operations
then cleaning out temp data as free space is needed.

On Unix-type systems, there are commands you can use to narrow down
where the disk space is going. I don’t suppose Apple has anything like >>> this ...

Such a thing would be useless considering that most of the Macs come
with a single storage device.

But one still wants to know where the space is going on a single disk, right?

Sure. I would be surprised if this wasn't already going in a specific
area. I never looked into it, but Apple generally doesn't throw things
all over the place the way Windows does.
--
CrudeSausage
MacBook Air M4 Sky Blue
iPhone 13
Friendly Apple zealot
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Tue, 20 Oct 2026 15:59:29 +0200, John Bokma wrote:

Such a thing would be useless considering that most of the Macs
come with a single storage device.

But one still wants to know where the space is going on a single
disk, right?

Correct. I suspect the person you are replying to is thinking of a
command like “df”, which only shows information for entire volumes,
whereas I am thinking of “du”, which lets you drill down into
individual directories.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 20/10/2026 22:05, Lawrence D’Oliveiro wrote:

On Tue, 20 Oct 2026 15:59:29 +0200, John Bokma wrote:

Such a thing would be useless considering that most of the Macs
come with a single storage device.

But one still wants to know where the space is going on a single
disk, right?

Correct. I suspect the person you are replying to is thinking of a
command like “df”, which only shows information for entire volumes, whereas I am thinking of “du”, which lets you drill down into
individual directories.

Clear. The command du comes with macOS:

❯ which du
/usr/bin/du

tumblelog on  master via 🐪 v5.34.3 via 🐍 v3.14.8
❯ du -hs *
16K CHANGELOG.md
4.0K LICENSE
12K README.md
52K __pycache__
0B htdocs
4.0K perl.Dockerfile
4.0K python.Dockerfile
4.0K requirements.txt
4.0K sass.Dockerfile
8.0M screenshots
68K styles
4.0K tumblelog-tags.html
4.0K tumblelog-tags.md
4.0K tumblelog.html
4.0K tumblelog.md
48K tumblelog.pl
44K tumblelog.py

Quite handy.
--
Static tumblelog generator: https://github.com/john-bokma/tumblelog/
Available as Python or Perl. Example tumblelog: https://plurrrr.com/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Tue, 20 Oct 2026 22:17:33 +0200, John Bokma wrote:

On 20/10/2026 22:05, Lawrence D’Oliveiro wrote:

... whereas I am thinking of “du”, which lets you drill down into
individual directories.

Clear. The command du comes with macOS:

❯ which du
/usr/bin/du

tumblelog on  master via 🐪 v5.34.3 via 🐍 v3.14.8
❯ du -hs *
16K CHANGELOG.md
4.0K LICENSE
12K README.md
52K __pycache__
0B htdocs
4.0K perl.Dockerfile
4.0K python.Dockerfile
4.0K requirements.txt
4.0K sass.Dockerfile
8.0M screenshots
68K styles
4.0K tumblelog-tags.html
4.0K tumblelog-tags.md
4.0K tumblelog.html
4.0K tumblelog.md
48K tumblelog.pl
44K tumblelog.py

Quite handy.

The GNU coreutils version has this handy feature:

ldo@hypatia:projects> du -ks blender
6012192 blender
ldo@hypatia:projects> du -ks blender/.git blender
4782896 blender/.git
1229296 blender

If a directory contains subdirectories which have already been summed,
it excludes them from the sum.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 20/10/2026 22:26, Lawrence D’Oliveiro wrote:

The GNU coreutils version has this handy feature:

ldo@hypatia:projects> du -ks blender
6012192 blender
ldo@hypatia:projects> du -ks blender/.git blender
4782896 blender/.git
1229296 blender

If a directory contains subdirectories which have already been summed,
it excludes them from the sum.

Nice, I was not aware of that feature and the du that comes with macOS
doesn't seem to have it. It's available via coreutils, which can be
installed using either Mac Ports or homebrew.
--
Static tumblelog generator: https://github.com/john-bokma/tumblelog/
Available as Python or Perl. Example tumblelog: https://plurrrr.com/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 10/20/26 10:58, Tom Elam wrote:

On 10/20/26 9:59 AM, John Bokma wrote:

Such a thing would be useless considering that most of the Macs come
with a single storage device.

But one still wants to know where the space is going on a single disk,
right?

Absolutely. I bought this MacBook with "only" 512 GB knowing that I
would need to use my 4 TB external to keep my YouTube content long term. It's about 400 GB of video files alone.

Saw that one coming from a lightyear away. No different than someone
who awhile back how they could put 2TB of content onto a 256GB drive,
because the base level laptop was too cheap to resist buying.

However, I was amazed to see how fast free space was disappearing when editing ...

Amazed, because that's been the state of the industry for decades?

Once the entire folder was offloaded to the external drive within a few minutes reported free space popped up to over 200 GB. At this moment
it's 257 GB free.

OS automatically recovered the temporary scratch space allocation; nice.

Lesson? If you want to create any video content involving large files on
a Mac go for at least a 1 TB drive. Maybe more. Editing eats disk space
like crazy! At least with VideoPad.

Nah, the need for Scratch has always been a thing with digital media
editing, and has ~nothing to do with the OS which happens to be in use.

About the only thing you've pointed out is actually a feature: one
doesn't have to explicitly allocate the Scratch in advance, nor take
steps to de-allocate it (to free it up for other uses) afterwords.

-hh
--- Synchronet 3.22a-Linux NewsLink 1.2