$ df -h .
Filesystem Size Used Avail Use% Mounted on
tmpfs 126G 542M 126G 1% /dev/shm

What do you think? Is it worth it to try building Linux
on a ramdisk?

6.8.7 is out now, so I thought I'd try it:

$ time -p make -j 32
[...]
real 432.09
user 11085.32
sys 2520.37

That's with a "kitchen sink" build using a .config that
originally came from Linux Mint's "lowlatency" sources.

(To set it up, I unpacked the tar file onto /dev/shm -- much
faster than if I'd tried to rsync the unpacked sources.)

After the build:
$ df -h .
Filesystem Size Used Avail Use% Mounted on
tmpfs 126G 23G 103G 19% /dev/shm

(Of course, now that I've done this stunt, I'm rsync'ing
the tree onto my NAS, so I'll have it after the reboot.)

And there you go: doing Linux stunts, so you don't have to.

--
-v

On Wed, 17 Apr 2024 23:41:37 -0000 (UTC), vallor wrote:

> (Of course, now that I've done this stunt, I'm rsync'ing the tree onto
> my NAS, so I'll have it after the reboot.)
>
> And there you go: doing Linux stunts, so you don't have to.

I wouldn’t call that a stunt--that’s just regular Linux usage. ;)

Using eatmydata to run an upgrade on your system ... now that would be a
stunt. ;);)

vallor <vallor@cultnix.org> wrote at 23:41 this Wednesday (GMT):
> $ df -h .
> Filesystem Size Used Avail Use% Mounted on
> tmpfs 126G 542M 126G 1% /dev/shm
>
> What do you think? Is it worth it to try building Linux
> on a ramdisk?
>
> 6.8.7 is out now, so I thought I'd try it:
>
> $ time -p make -j 32
> [...]
> real 432.09
> user 11085.32
> sys 2520.37
>
> That's with a "kitchen sink" build using a .config that
> originally came from Linux Mint's "lowlatency" sources.
>
> (To set it up, I unpacked the tar file onto /dev/shm -- much
> faster than if I'd tried to rsync the unpacked sources.)
>
> After the build:
> $ df -h .
> Filesystem Size Used Avail Use% Mounted on
> tmpfs 126G 23G 103G 19% /dev/shm
>
> (Of course, now that I've done this stunt, I'm rsync'ing
> the tree onto my NAS, so I'll have it after the reboot.)
>
> And there you go: doing Linux stunts, so you don't have to.

Isn't /tmp usually mounted as a ramdisk?
--
user <candycane> is generated from /dev/urandom

On Thu, 18 Apr 2024 14:50:03 -0000 (UTC), candycanearter07
<candycanearter07@candycanearter07.nomail.afraid> wrote in
<uvrbur$2ae33$1@dont-email.me>:

> vallor <vallor@cultnix.org> wrote at 23:41 this Wednesday (GMT):
>> $ df -h .
>> Filesystem Size Used Avail Use% Mounted on
>> tmpfs 126G 542M 126G 1% /dev/shm
>>
>> What do you think? Is it worth it to try building Linux
>> on a ramdisk?
>>
>> 6.8.7 is out now, so I thought I'd try it:
>>
>> $ time -p make -j 32
>> [...]
>> real 432.09
>> user 11085.32
>> sys 2520.37
>>
>> That's with a "kitchen sink" build using a .config that
>> originally came from Linux Mint's "lowlatency" sources.
>>
>> (To set it up, I unpacked the tar file onto /dev/shm -- much
>> faster than if I'd tried to rsync the unpacked sources.)
>>
>> After the build:
>> $ df -h .
>> Filesystem Size Used Avail Use% Mounted on
>> tmpfs 126G 23G 103G 19% /dev/shm
>>
>> (Of course, now that I've done this stunt, I'm rsync'ing
>> the tree onto my NAS, so I'll have it after the reboot.)
>>
>> And there you go: doing Linux stunts, so you don't have to.
>
>
> Isn't /tmp usually mounted as a ramdisk?

Some distros might do that. Linux Mint doesn't, and I
don't advise it.

--
-v

On Fri, 19 Apr 2024 02:53:05 -0000 (UTC), vallor wrote:

> On Thu, 18 Apr 2024 14:50:03 -0000 (UTC), candycanearter07
> <candycanearter07@candycanearter07.nomail.afraid> wrote in
> <uvrbur$2ae33$1@dont-email.me>:
>
>> Isn't /tmp usually mounted as a ramdisk?
>
> Some distros might do that. Linux Mint doesn't, and I don't advise it.

It’s your choice. Stuff in /tmp is not expected to have a long lifetime.
/var/tmp is for things you would like to last longer, but still aren’t
that fussed about.

The whole point about temporary files is it’s not the end of the world if
they get deleted.

vallor <vallor@cultnix.org> wrote at 02:53 this Friday (GMT):
> On Thu, 18 Apr 2024 14:50:03 -0000 (UTC), candycanearter07
><candycanearter07@candycanearter07.nomail.afraid> wrote in
><uvrbur$2ae33$1@dont-email.me>:
>
>> vallor <vallor@cultnix.org> wrote at 23:41 this Wednesday (GMT):
>>> $ df -h .
>>> Filesystem Size Used Avail Use% Mounted on
>>> tmpfs 126G 542M 126G 1% /dev/shm
>>>
>>> What do you think? Is it worth it to try building Linux
>>> on a ramdisk?
>>>
>>> 6.8.7 is out now, so I thought I'd try it:
>>>
>>> $ time -p make -j 32
>>> [...]
>>> real 432.09
>>> user 11085.32
>>> sys 2520.37
>>>
>>> That's with a "kitchen sink" build using a .config that
>>> originally came from Linux Mint's "lowlatency" sources.
>>>
>>> (To set it up, I unpacked the tar file onto /dev/shm -- much
>>> faster than if I'd tried to rsync the unpacked sources.)
>>>
>>> After the build:
>>> $ df -h .
>>> Filesystem Size Used Avail Use% Mounted on
>>> tmpfs 126G 23G 103G 19% /dev/shm
>>>
>>> (Of course, now that I've done this stunt, I'm rsync'ing
>>> the tree onto my NAS, so I'll have it after the reboot.)
>>>
>>> And there you go: doing Linux stunts, so you don't have to.
>>
>>
>> Isn't /tmp usually mounted as a ramdisk?
>
> Some distros might do that. Linux Mint doesn't, and I
> don't advise it.

$ findmnt /tmp

TARGET SOURCE FSTYPE OPTIONS
/tmp tmpfs tmpfs rw,nosuid,nodev,size=8043524k,nr_inodes=1048576,inode64

Mine does at least.
--
user <candycane> is generated from /dev/urandom

On Fri, 19 Apr 2024 13:30:02 -0000 (UTC), candycanearter07
<candycanearter07@candycanearter07.nomail.afraid> wrote in
<uvtrkq$312kp$1@dont-email.me>:

> vallor <vallor@cultnix.org> wrote at 02:53 this Friday (GMT):
>> On Thu, 18 Apr 2024 14:50:03 -0000 (UTC), candycanearter07
>><candycanearter07@candycanearter07.nomail.afraid> wrote in
>><uvrbur$2ae33$1@dont-email.me>:
>>
>>> vallor <vallor@cultnix.org> wrote at 23:41 this Wednesday (GMT):
>>>> $ df -h .
>>>> Filesystem Size Used Avail Use% Mounted on tmpfs 126G
>>>> 542M 126G 1% /dev/shm
>>>>
>>>> What do you think? Is it worth it to try building Linux on a
>>>> ramdisk?
>>>>
>>>> 6.8.7 is out now, so I thought I'd try it:
>>>>
>>>> $ time -p make -j 32 [...]
>>>> real 432.09 user 11085.32 sys 2520.37
>>>>
>>>> That's with a "kitchen sink" build using a .config that originally
>>>> came from Linux Mint's "lowlatency" sources.
>>>>
>>>> (To set it up, I unpacked the tar file onto /dev/shm -- much faster
>>>> than if I'd tried to rsync the unpacked sources.)
>>>>
>>>> After the build:
>>>> $ df -h .
>>>> Filesystem Size Used Avail Use% Mounted on tmpfs 126G
>>>> 23G 103G 19% /dev/shm
>>>>
>>>> (Of course, now that I've done this stunt, I'm rsync'ing the tree
>>>> onto my NAS, so I'll have it after the reboot.)
>>>>
>>>> And there you go: doing Linux stunts, so you don't have to.
>>>
>>>
>>> Isn't /tmp usually mounted as a ramdisk?
>>
>> Some distros might do that. Linux Mint doesn't, and I don't advise it.
>
>
> $ findmnt /tmp
>
> TARGET SOURCE FSTYPE OPTIONS /tmp tmpfs tmpfs
> rw,nosuid,nodev,size=8043524k,nr_inodes=1048576,inode64
>
> Mine does at least.

Interesting. What distribution are you using?

My concern would be filling it up, but that's probably
just my "old school" thinking from back in the day when
computers had much less memory.

--
-v

vallor <vallor@cultnix.org> wrote at 13:39 this Friday (GMT):
> On Fri, 19 Apr 2024 13:30:02 -0000 (UTC), candycanearter07
><candycanearter07@candycanearter07.nomail.afraid> wrote in
><uvtrkq$312kp$1@dont-email.me>:
>
>> vallor <vallor@cultnix.org> wrote at 02:53 this Friday (GMT):
>>> On Thu, 18 Apr 2024 14:50:03 -0000 (UTC), candycanearter07
>>><candycanearter07@candycanearter07.nomail.afraid> wrote in
>>><uvrbur$2ae33$1@dont-email.me>:
>>>
>>>> vallor <vallor@cultnix.org> wrote at 23:41 this Wednesday (GMT):
>>>>> $ df -h .
>>>>> Filesystem Size Used Avail Use% Mounted on tmpfs 126G
>>>>> 542M 126G 1% /dev/shm
>>>>>
>>>>> What do you think? Is it worth it to try building Linux on a
>>>>> ramdisk?
>>>>>
>>>>> 6.8.7 is out now, so I thought I'd try it:
>>>>>
>>>>> $ time -p make -j 32 [...]
>>>>> real 432.09 user 11085.32 sys 2520.37
>>>>>
>>>>> That's with a "kitchen sink" build using a .config that originally
>>>>> came from Linux Mint's "lowlatency" sources.
>>>>>
>>>>> (To set it up, I unpacked the tar file onto /dev/shm -- much faster
>>>>> than if I'd tried to rsync the unpacked sources.)
>>>>>
>>>>> After the build:
>>>>> $ df -h .
>>>>> Filesystem Size Used Avail Use% Mounted on tmpfs 126G
>>>>> 23G 103G 19% /dev/shm
>>>>>
>>>>> (Of course, now that I've done this stunt, I'm rsync'ing the tree
>>>>> onto my NAS, so I'll have it after the reboot.)
>>>>>
>>>>> And there you go: doing Linux stunts, so you don't have to.
>>>>
>>>>
>>>> Isn't /tmp usually mounted as a ramdisk?
>>>
>>> Some distros might do that. Linux Mint doesn't, and I don't advise it.
>>
>>
>> $ findmnt /tmp
>>
>> TARGET SOURCE FSTYPE OPTIONS /tmp tmpfs tmpfs
>> rw,nosuid,nodev,size=8043524k,nr_inodes=1048576,inode64
>>
>> Mine does at least.
>
> Interesting. What distribution are you using?
>
> My concern would be filling it up, but that's probably
> just my "old school" thinking from back in the day when
> computers had much less memory.

EndeavourOS. And I have about 24G ram total (16gb + 8gb swap file) so it
shouldn't be too much of an issue.
--
user <candycane> is generated from /dev/urandom

On Fri, 19 Apr 2024 13:30:02 -0000 (UTC), candycanearter07 wrote:

> $ findmnt /tmp
>
> TARGET SOURCE FSTYPE OPTIONS /tmp tmpfs tmpfs
> rw,nosuid,nodev,size=8043524k,nr_inodes=1048576,inode64
>
> Mine does at least.

Well, that was interesting... There are a couple of tmpfs mounts but
not /tmp. However there is a load of snap stuff mounted on 'squashfs'.

The downside of easy, hands off installations is I no longer know what is
installed as long as It Just Works.

On Fri, 19 Apr 2024 03:44:12 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <uvspab$2nk0a$1@dont-email.me>:

> On Fri, 19 Apr 2024 02:53:05 -0000 (UTC), vallor wrote:
>
>> On Thu, 18 Apr 2024 14:50:03 -0000 (UTC), candycanearter07
>> <candycanearter07@candycanearter07.nomail.afraid> wrote in
>> <uvrbur$2ae33$1@dont-email.me>:
>>
>>> Isn't /tmp usually mounted as a ramdisk?
>>
>> Some distros might do that. Linux Mint doesn't, and I don't advise it.
>
> It’s your choice. Stuff in /tmp is not expected to have a long lifetime.
> /var/tmp is for things you would like to last longer, but still aren’t
> that fussed about.
>
> The whole point about temporary files is it’s not the end of the world
> if they get deleted.

ssh-agent's socket lives in a subdirectory in /tmp. Really should live in
/run somewhere. Looks like it can be steered by changing the TMPDIR
environment variable...

On our companies user-access shell server, each user has their own /tmp
in their own chroot.

--
-v

On Mon, 22 Apr 2024 02:03:57 -0000 (UTC), vallor wrote:

> ssh-agent's socket lives in a subdirectory in /tmp. Really should live
> in /run somewhere. Looks like it can be steered by changing the TMPDIR
> environment variable...

The logical place for per-user stuff would be /run/user/«userid», as per
systemd conventions.

> On our companies user-access shell server, each user has their own /tmp
> in their own chroot.

I once had to set up a file-access server for a client that had to support
both old-style insecure FTP and also SFTP (with the ultimate aim, of
course, of transitioning all their customers from the former to the
latter). Setting up a per-user chroot that would work with both was ...
quite a challenge ...

On 4/21/2024 10:03 PM, vallor wrote:

> On our companies user-access shell server, each user has their own /tmp
> in their own chroot.

company's

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 07:38 this Monday (GMT):
> On Mon, 22 Apr 2024 02:03:57 -0000 (UTC), vallor wrote:
>
>> ssh-agent's socket lives in a subdirectory in /tmp. Really should live
>> in /run somewhere. Looks like it can be steered by changing the TMPDIR
>> environment variable...
>
> The logical place for per-user stuff would be /run/user/«userid», as per
> systemd conventions.

I think that udiskie puts it in /run/media/user/disklabel

>> On our companies user-access shell server, each user has their own /tmp
>> in their own chroot.
>
> I once had to set up a file-access server for a client that had to support
> both old-style insecure FTP and also SFTP (with the ultimate aim, of
> course, of transitioning all their customers from the former to the
> latter). Setting up a per-user chroot that would work with both was ...
> quite a challenge ...

Sounds like it.
--
user <candycane> is generated from /dev/urandom