Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #56825 > unrolled thread

Relocating many homes in subfolders of a dedicated internal HDD

Back to article view | Back to alt.os.linux

Contents

  Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-13 20:47 +0200
    Re: Relocating many homes in subfolders of a dedicated internal HDD "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-13 17:35 -0400
      Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-14 00:01 +0200
        Re: Relocating many homes in subfolders of a dedicated internal HDD "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-13 19:28 -0400
          Re: Relocating many homes in subfolders of a dedicated internal HDD Bit Twister <BitTwister@mouse-potato.com> - 2019-06-13 19:23 -0500
        Re: Relocating many homes in subfolders of a dedicated internal HDD "Carlos E.R." <robin_listas@es.invalid> - 2019-06-14 10:29 +0200
      Re: Relocating many homes in subfolders of a dedicated internal HDD marrgol <marrgol@address.invalid> - 2019-06-14 02:13 +0200
        Re: Relocating many homes in subfolders of a dedicated internal HDD "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-13 23:45 -0400
          Re: Relocating many homes in subfolders of a dedicated internal HDD Paul <nospam@needed.invalid> - 2019-06-14 07:34 -0400
            Re: Relocating many homes in subfolders of a dedicated internal HDD "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-14 09:59 -0400
              Re: Relocating many homes in subfolders of a dedicated internal HDD "Carlos E.R." <robin_listas@es.invalid> - 2019-06-15 13:08 +0200
                Re: Relocating many homes in subfolders of a dedicated internal HDD Paul <nospam@needed.invalid> - 2019-06-15 11:58 -0400
                  Re: Relocating many homes in subfolders of a dedicated internal HDD "Carlos E.R." <robin_listas@es.invalid> - 2019-06-15 23:10 +0200
    Re: Relocating many homes in subfolders of a dedicated internal HDD Bit Twister <BitTwister@mouse-potato.com> - 2019-06-13 18:49 -0500
    Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-14 07:05 +0200
      Re: Relocating many homes in subfolders of a dedicated internal HDD "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-14 04:17 -0400
        Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-14 17:41 +0200
          Re: Relocating many homes in subfolders of a dedicated internal HDD William Unruh <unruh@invalid.ca> - 2019-06-14 15:58 +0000
          Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-14 18:04 +0200
        Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-14 17:58 +0200
          Re: Relocating many homes in subfolders of a dedicated internal HDD Aragorn <thorongil@telenet.be> - 2019-06-14 18:36 +0200
            Re: Relocating many homes in subfolders of a dedicated internal HDD Bit Twister <BitTwister@mouse-potato.com> - 2019-06-14 12:01 -0500
            Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-14 19:18 +0200
              Re: Relocating many homes in subfolders of a dedicated internal HDD Aragorn <thorongil@telenet.be> - 2019-06-14 20:11 +0200
                Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-14 21:44 +0200
                Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-18 12:50 +0200
                  Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-18 21:50 +0200
                    Re: Relocating many homes in subfolders of a dedicated internal HDD Aragorn <thorongil@telenet.be> - 2019-06-19 13:10 +0200
                      Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-19 21:57 +0200
            Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-14 19:22 +0200
              Re: Relocating many homes in subfolders of a dedicated internal HDD Aragorn <thorongil@telenet.be> - 2019-06-14 20:02 +0200
      Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-14 17:36 +0200
        Re: Relocating many homes in subfolders of a dedicated internal HDD Bit Twister <BitTwister@mouse-potato.com> - 2019-06-14 10:50 -0500
        Re: Relocating many homes in subfolders of a dedicated internal HDD William Unruh <unruh@invalid.ca> - 2019-06-14 15:55 +0000
          Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-14 22:29 +0200
            Re: Relocating many homes in subfolders of a dedicated internal HDD William Unruh <unruh@invalid.ca> - 2019-06-14 20:52 +0000
              Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-15 02:07 +0200
                Re: Relocating many homes in subfolders of a dedicated internal HDD William Unruh <unruh@invalid.ca> - 2019-06-15 01:30 +0000
            Re: Relocating many homes in subfolders of a dedicated internal HDD Aragorn <thorongil@telenet.be> - 2019-06-15 08:59 +0200
              Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-17 19:43 +0200
    Re: Relocating many homes in subfolders of a dedicated internal HDD Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-06-15 19:47 +0200
      Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-17 02:05 +0200
        Re: Relocating many homes in subfolders of a dedicated internal HDD Bit Twister <BitTwister@mouse-potato.com> - 2019-06-16 20:23 -0500
        Re: Relocating many homes in subfolders of a dedicated internal HDD Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-06-18 13:52 +0200
          Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-18 18:36 +0200
            Re: Relocating many homes in subfolders of a dedicated internal HDD Bit Twister <BitTwister@mouse-potato.com> - 2019-06-18 12:04 -0500
            Re: Relocating many homes in subfolders of a dedicated internal HDD William Unruh <unruh@invalid.ca> - 2019-06-18 21:37 +0000
            Re: Relocating many homes in subfolders of a dedicated internal HDD Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-06-20 23:31 +0200
              Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-21 10:25 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#56851

On 14.06.2019 at 17:58, J.O. Aho scribbled:

> On 14/06/2019 10.17, David W. Hodgins wrote:
> > On Fri, 14 Jun 2019 01:05:52 -0400, J.O. Aho <user@example.net>
> > wrote: 
> >> On 13/06/2019 20.47, Soviet_Mario wrote:  
> >>> I have thought of SYMLINKING.  
> >   
> >> Why? Never thought of using the correct path instead when you
> >> mount the directory?  
> > 
> > There are many applications that default to using ~/Downloads or
> > other subdirectories in /home/$USER. It's easier to use a short
> > script once after each installation, that replaces those
> > directories with the symlinks to the directories in the data
> > mounted file system, than to remember to change the locations in
> > every one of those applications, on every install.  
> 
> Why not use bind mount the directory you want to be home? The more 
> proper way of doing things.
> 
> /your/local/disk/subfolder    /home               none    bind 0 0
> 
> or
> 
> remotemachine:/path/to/share   /home/   nfs4    defaults,noatime  0  0
> 
> bind mounts will fail if the source is missing, symlink can cause
> random locks

btrfs solution:


 This is the entire SSD
 ————————————————————————————————————————————————————————————————————
 | /dev/sda2 | /dev/sda3 | /dev/sda4 | /dev/sda5
 |    ext4   |    ext4   |    ext4   |   btrfs @
 |           |           |           |    |_ @ubuntu-home (subvol)
 | Ubuntu /  | Mint /    | Debian /  |    |_ @mint-home   (subvol)
 |   ext4    |  ext4     |   ext4    |    |_ @debian-home (subvol)
 |           |           |           |    |_ @data-dirs   (subvol)
 |           |           |           |          |_ Documents (dir)
 |           |           |           |          |_ Downloads (dir)
 |           |           |           |          |_ other dirs
 |           |           |           |
 ————————————————————————————————————————————————————————————————————


  ° Ubuntu mounts @ubuntu-home as its /home.

  ° Mint mounts @mint-home as its /home.

  ° Debian mounts @debian-home as its /home.

  ° All distros mount @data-dirs at some mountpoint (e.g. /data) and
    have symbolic links to the directories in @data-dirs in their
    respective /home.

  ° The free space of /dev/sda5 is shared among all of the subvolumes.

Of course, he'll need a swap partition as well, but the above should be
a workable solution.  

I've also left /dev/sda1 out of the overview because of line wrap, and
because I'm assuming it to be the EFI system partition, or perhaps a
BIOS partition.  If his system has an MS-DOS MBR partition table in
combination with a legacy BIOS and he's not booting in UEFI mode, then
he needs neither an EFI system partition nor a BIOS partition.

Overview:

   GPT + UEFI boot → EFI system partition needed
   MBR + UEFI boot → EFI system partition needed
   GPT + BIOS boot → BIOS partition needed
   MBR + BIOS boot → no EFI system partition or BIOS partition needed

It might be advisable however to have a separate /boot partition as
well, which is shared among the different distributions.  That way,
updates to GRUB from within one distro will also be reflected in the
other distros.

Additional note: 

   Personally, I wouldn't do any of the above, because having multiple
   distributions on a single storage medium — or, indeed, on a single
   computer — can often lead to unpredictable situations, even for an
   experienced user.  

   And Mario is most definitely not an experienced user at all — he
   never even spends enough time on solving or researching any
   particular problem before he already endeavors on his next adventure
   without preparation. So we can with the utmost certainty expect loads
   of problems arising from his little experiments.

-- 
With respect,
= Aragorn =

[toc] | [prev] | [next] | [standalone]

#56852

On Fri, 14 Jun 2019 18:36:35 +0200, Aragorn wrote:
>
> It might be advisable however to have a separate /boot partition as
> well, which is shared among the different distributions.  That way,
> updates to GRUB from within one distro will also be reflected in the
> other distros.

I am not too sure about the above.

I have have had a few times when a grub2 update would not give me a menu.
Fix was to run grub-install.

I admit the problem is very rare. In all my installs, Cauldron and Official
it has happened maybe three or four times, couple on one node, once on
another, and never on the third node.

[toc] | [prev] | [next] | [standalone]

#56853

On 14/06/2019 18.36, Aragorn wrote:
> On 14.06.2019 at 17:58, J.O. Aho scribbled:
> 
>> On 14/06/2019 10.17, David W. Hodgins wrote:
>>> On Fri, 14 Jun 2019 01:05:52 -0400, J.O. Aho <user@example.net>
>>> wrote:
>>>> On 13/06/2019 20.47, Soviet_Mario wrote:
>>>>> I have thought of SYMLINKING.
>>>    
>>>> Why? Never thought of using the correct path instead when you
>>>> mount the directory?
>>>
>>> There are many applications that default to using ~/Downloads or
>>> other subdirectories in /home/$USER. It's easier to use a short
>>> script once after each installation, that replaces those
>>> directories with the symlinks to the directories in the data
>>> mounted file system, than to remember to change the locations in
>>> every one of those applications, on every install.
>>
>> Why not use bind mount the directory you want to be home? The more
>> proper way of doing things.
>>
>> /your/local/disk/subfolder    /home               none    bind 0 0
>>
>> or
>>
>> remotemachine:/path/to/share   /home/   nfs4    defaults,noatime  0  0
>>
>> bind mounts will fail if the source is missing, symlink can cause
>> random locks
> 
> btrfs solution:

I do use btrfs myself too, but I have encountered some distributions 
which has failed to install with btrfs on the root file system, but 
generally I have just ditched those.



> 
>     Personally, I wouldn't do any of the above, because having multiple
>     distributions on a single storage medium — or, indeed, on a single
>     computer — can often lead to unpredictable situations, even for an
>     experienced user.

There are alternative ways to solve it, I would most likely go with a 
container, then you don't have to reboot just each time you want to 
switch. btrfs comes really handy together with lxc/lxd.


-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#56857

On 14.06.2019 at 19:18, J.O. Aho scribbled:

> On 14/06/2019 18.36, Aragorn wrote:
>
>> [...]
>> 
>> btrfs solution:
>>
>> [...]
> 
> I do use btrfs myself too, but I have encountered some distributions 
> which has failed to install with btrfs on the root file system, but 
> generally I have just ditched those.

Most distributions have a problem with GRUB2 on btrfs, so it's not
specific to the root filesystem but to /boot, and it's a GRUB2 problem.

On my system here, I use btrfs for all my filesystems — they are
separate partitions, not subvolumes [*] — but I use ext4 for /boot and
of course vfat for /boot/efi.

[*] btrfs subvolumes are separate name spaces within the same
    filesystem, so in theory there is always the chance that if
    anything ever goes wrong at the level of the filesystem layer, then
    you might lose access to your subvolumes.  This is why I've chosen
    to implement the segregation at the partition table level instead.
    I do however have one big btrfs volume with subvolumes on a
    spinning rust drive that I only use for backups.

> > Personally, I wouldn't do any of the above, because having
> > multiple distributions on a single storage medium — or, indeed, on
> > a single computer — can often lead to unpredictable situations,
> > even for an experienced user.  
> 
> There are alternative ways to solve it, I would most likely go with a 
> container, then you don't have to reboot just each time you want to 
> switch. btrfs comes really handy together with lxc/lxd.

That is probably way beyond Mario's understanding and capabilities. :p

-- 
With respect,
= Aragorn =

[toc] | [prev] | [next] | [standalone]

#56859

On 14/06/2019 20.11, Aragorn wrote:
> On 14.06.2019 at 19:18, J.O. Aho scribbled:
> 
>> On 14/06/2019 18.36, Aragorn wrote:
>>
>>> [...]
>>>
>>> btrfs solution:
>>>
>>> [...]
>>
>> I do use btrfs myself too, but I have encountered some distributions
>> which has failed to install with btrfs on the root file system, but
>> generally I have just ditched those.
> 
> Most distributions have a problem with GRUB2 on btrfs, so it's not
> specific to the root filesystem but to /boot, and it's a GRUB2 problem.

I have by tradition picked to use a small ext2 partition for /boot, so 
I'm quite sure it's not that which has caused issues for me.


> [*] btrfs subvolumes are separate name spaces within the same
>      filesystem, so in theory there is always the chance that if
>      anything ever goes wrong at the level of the filesystem layer, then
>      you might lose access to your subvolumes.  This is why I've chosen
>      to implement the segregation at the partition table level instead.
>      I do however have one big btrfs volume with subvolumes on a
>      spinning rust drive that I only use for backups.

I tend to have one for system, another for storage and user data, I do 
make snapshots which I send to another machine, so the data won't 
disappear just for one machine was hit by lightning.


>>> Personally, I wouldn't do any of the above, because having
>>> multiple distributions on a single storage medium — or, indeed, on
>>> a single computer — can often lead to unpredictable situations,
>>> even for an experienced user.
>>
>> There are alternative ways to solve it, I would most likely go with a
>> container, then you don't have to reboot just each time you want to
>> switch. btrfs comes really handy together with lxc/lxd.
> 
> That is probably way beyond Mario's understanding and capabilities. :p

Maybe, just hope someone will get use of the discussion to solve their 
issue in a better way.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#56956

Il 14/06/19 20:11, Aragorn ha scritto:
> On 14.06.2019 at 19:18, J.O. Aho scribbled:
> 
>> On 14/06/2019 18.36, Aragorn wrote:
>>
>>> [...]
>>>
>>> btrfs solution:
>>>
>>> [...]
>>
>> I do use btrfs myself too, but I have encountered some distributions
>> which has failed to install with btrfs on the root file system, but
>> generally I have just ditched those.
> 
> Most distributions have a problem with GRUB2 on btrfs, so it's not
> specific to the root filesystem but to /boot, and it's a GRUB2 problem.
> 
> On my system here, I use btrfs for all my filesystems — they are
> separate partitions, not subvolumes [*] — but I use ext4 for /boot and
> of course vfat for /boot/efi.
> 
> [*] btrfs subvolumes are separate name spaces within the same
>      filesystem, so in theory there is always the chance that if
>      anything ever goes wrong at the level of the filesystem layer, then
>      you might lose access to your subvolumes.  This is why I've chosen
>      to implement the segregation at the partition table level instead.
>      I do however have one big btrfs volume with subvolumes on a
>      spinning rust drive that I only use for backups.
> 
>>> Personally, I wouldn't do any of the above, because having
>>> multiple distributions on a single storage medium — or, indeed, on
>>> a single computer — can often lead to unpredictable situations,
>>> even for an experienced user.
>>
>> There are alternative ways to solve it, I would most likely go with a
>> container, then you don't have to reboot just each time you want to
>> switch. btrfs comes really handy together with lxc/lxd.
> 
> That is probably way beyond Mario's understanding and capabilities. :p
> 

every piece of advice received so far (I'm still trying to 
understand the ones with J.O.Aho which seem rather similar 
to complete examples) are beyond my ability to turn them in 
sth usable.
For two expert is easier
Exp1 : use cme XYWZK
Exp2 : oh, tnx a lot !

for "i niubbi" like me without "complete" examples is almost 
impossible get sth out of a CLI command. The options and 
implications are simply too obscure.
And the question is not what you go saying many times (we 
don't read the man pages), the question is : they are clear 
to only those who just know and understand most of it.

If not understanding sth is a guilt, yes, I plead guilty.



-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#56968

On 18/06/2019 12.50, Soviet_Mario wrote:

>>> There are alternative ways to solve it, I would most likely go with a
>>> container, then you don't have to reboot just each time you want to
>>> switch. btrfs comes really handy together with lxc/lxd.
>>
>> That is probably way beyond Mario's understanding and capabilities. :p
>>
> 
> every piece of advice received so far (I'm still trying to understand 
> the ones with J.O.Aho which seem rather similar to complete examples) 
> are beyond my ability to turn them in sth usable.

Containers are quite basic things nowadays, there are a number of types 
that can be used out of the box on Linux

lxc, lxd, xen, docker

which one you use, depends on what you like and your skills.

A good place to start could be 
https://linuxcontainers.org/lxc/getting-started/ and I'm quite sure you 
can find a lot more howtos and beginners guides using your favorite 
search engine.



> And the question is not what you go saying many times (we don't read the 
> man pages), the question is : they are clear to only those who just know 
> and understand most of it.

They are written in quite plain English, even people with another 
language than English as mothertongue manages to understand them and if 
you don't there are translation to other languages like German too.

You can also read the info page instead, tend to have a lot more to read.


-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#56984

On 18.06.2019 at 21:50, J.O. Aho scribbled:

> Containers are quite basic things nowadays, there are a number of
> types that can be used out of the box on Linux
> 
> lxc, lxd, xen, docker

Xen isn't really a container solution, because a Xen guest — including
the dom0 — is a complete virtual machine. ;)

-- 
With respect,
= Aragorn =

[toc] | [prev] | [next] | [standalone]

#56999

On 19/06/2019 13.10, Aragorn wrote:
> On 18.06.2019 at 21:50, J.O. Aho scribbled:
> 
>> Containers are quite basic things nowadays, there are a number of
>> types that can be used out of the box on Linux
>>
>> lxc, lxd, xen, docker
> 
> Xen isn't really a container solution, because a Xen guest — including
> the dom0 — is a complete virtual machine. ;)

Yes, that is quite right, but it's been successful used as a container 
system as in QubeOS, so I felt it should be mentioned.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#56854

On 14/06/2019 18.36, Aragorn wrote:

>   |           |           |           |    |_ @ubuntu-home (subvol)
>   | Ubuntu /  | Mint /    | Debian /  |    |_ @mint-home   (subvol)
>   |   ext4    |  ext4     |   ext4    |    |_ @debian-home (subvol)

Never really understood the point of having different /home, my ~/ is 
the one I had for SunOS back in the early 1990's, it's been used for 
multiple distributions and even multiple machines simulations without 
issues.


-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#56856

On 14.06.2019 at 19:22, J.O. Aho scribbled:

> On 14/06/2019 18.36, Aragorn wrote:
> 
> >   |           |           |           |    |_ @ubuntu-home (subvol)
> >   | Ubuntu /  | Mint /    | Debian /  |    |_ @mint-home   (subvol)
> >   |   ext4    |  ext4     |   ext4    |    |_ @debian-home
> > (subvol)  
> 
> Never really understood the point of having different /home, my ~/ is 
> the one I had for SunOS back in the early 1990's, it's been used for 
> multiple distributions and even multiple machines simulations without 
> issues.
 
Subtle differences in the version of the desktop environment or window
manager between different distributions could cause problems, though.

-- 
With respect,
= Aragorn =

[toc] | [prev] | [next] | [standalone]

#56844

Il 14/06/19 07:05, J.O. Aho ha scritto:
> On 13/06/2019 20.47, Soviet_Mario wrote:
> 
>> I'd want to leverage to f12 bios option (boot device 
>> manual selection) to make a choice.
> 
> Should work well, but you may up with a huge list of boot 
> options on each individual grub installer as many 
> distributions has setup a script to find other installed 
> OS:es on the machine.
> 
> 
>> Meanwhile, as I have a big NEW and certified hdd (non ssd, 
>> a WD-red 2 TB), I'd also be willing to move the actual 
>> data of every HOME of any distro, each in a separate 
>> subtree of "\homes" shared folder.
> 
> I would avoid using a samba share, it's slower and do not 
> support everything that is expected from a Linux file system.
> 
> NFS would be a lot better.

I surely missed the point (if NSF stands for network file 
system) : all drives are connected to the same PC, so the 
system bus would be the most simple choice i guess ...

> 
> Issue you can have with network file systems is that all the 
> lock files can exhaust the IO. So you want to keep the 
> writes and reads to a minimum, so avoid using google chrome, 
> chromium, firefox and so on.
> 
> 
>> I have thought of SYMLINKING.
> 
> Why? Never thought of using the correct path instead when 
> you mount the directory?

this sound as a very interesting point, could you please 
make an example of what you mean ?

My base problem remains I don't really understand what mount 
exactly mean internally. I remain attached willy nilly to 
the old idea of phisical partitions seen as devices where 
they are :\


> 
> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#56846

On Fri, 14 Jun 2019 17:36:24 +0200, Soviet_Mario wrote:
> Il 14/06/19 07:05, J.O. Aho ha scritto:
>>
>> I would avoid using a samba share, it's slower and do not
>> support everything that is expected from a Linux file system.
>>
>> NFS would be a lot better.
>
> I surely missed the point (if NSF stands for network file
> system) : all drives are connected to the same PC, so the

Keep in mind that your statement would be correct for a file server
with a bunch of client nodes.

But you can have a pc serving files to other nodes, and those
node could also be serving files back the to the other nodes.

[toc] | [prev] | [next] | [standalone]

#56847

On 2019-06-14, Soviet_Mario <SovietMario@CCCP.MIR> wrote:
> Il 14/06/19 07:05, J.O. Aho ha scritto:
>> On 13/06/2019 20.47, Soviet_Mario wrote:
>> 
>>> I'd want to leverage to f12 bios option (boot device 
>>> manual selection) to make a choice.
>> 
>> Should work well, but you may up with a huge list of boot 
>> options on each individual grub installer as many 
>> distributions has setup a script to find other installed 
>> OS:es on the machine.
>> 
>> 
>>> Meanwhile, as I have a big NEW and certified hdd (non ssd, 
>>> a WD-red 2 TB), I'd also be willing to move the actual 
>>> data of every HOME of any distro, each in a separate 
>>> subtree of "\homes" shared folder.
>> 
>> I would avoid using a samba share, it's slower and do not 
>> support everything that is expected from a Linux file system.
>> 
>> NFS would be a lot better.
>
> I surely missed the point (if NSF stands for network file 
                                ^^^
	No NSF stands for National Science Foundation. NFS
	stands for network file system.

> system) : all drives are connected to the same PC, so the 
> system bus would be the most simple choice i guess ...

So just mount them.
And you certainly do not want to use NFS or Samba.

>
>> 
>> Issue you can have with network file systems is that all the 
>> lock files can exhaust the IO. So you want to keep the 
>> writes and reads to a minimum, so avoid using google chrome, 
>> chromium, firefox and so on.
>> 
>> 
>>> I have thought of SYMLINKING.
>> 
>> Why? Never thought of using the correct path instead when 
>> you mount the directory?
>
> this sound as a very interesting point, could you please 
> make an example of what you mean ?
>
> My base problem remains I don't really understand what mount 
> exactly mean internally. I remain attached willy nilly to 
> the old idea of phisical partitions seen as devices where 
> they are :\
>
Mount means: If you have a physical partition (or a file for that
matter) make the contents of that partition available on a mountpoint in
the filesystem. 

mount /dev/sda7 /local/donaldduck
means make the contents of the partition /dev/sda7 available at
/local/donaldduck

However I have no idea what your last sentence means. If you are
thinking of the Windows idea of "mounting" where the contents of
/dev/sda7 are made available at some silly drive letter E: for example,
then that is NOT what linux does. It does not force you to remember what
in the world drive Q: contains. you just mount it at a reasoanble point
in your filesystem, with a name of the mountpoint hopefully giving you a
clue as to what is in there
/local/place/where/I/want/to/mount/mypicturebook 
for example.
>
>> 
>> 
>
>

[toc] | [prev] | [next] | [standalone]

#56860

Il 14/06/19 17:55, William Unruh ha scritto:
> On 2019-06-14, Soviet_Mario <SovietMario@CCCP.MIR> wrote:
>> Il 14/06/19 07:05, J.O. Aho ha scritto:
>>> On 13/06/2019 20.47, Soviet_Mario wrote:
>>>
>>>> I'd want to leverage to f12 bios option (boot device
>>>> manual selection) to make a choice.
>>>
>>> Should work well, but you may up with a huge list of boot
>>> options on each individual grub installer as many
>>> distributions has setup a script to find other installed
>>> OS:es on the machine.
>>>
>>>
>>>> Meanwhile, as I have a big NEW and certified hdd (non ssd,
>>>> a WD-red 2 TB), I'd also be willing to move the actual
>>>> data of every HOME of any distro, each in a separate
>>>> subtree of "\homes" shared folder.
>>>
>>> I would avoid using a samba share, it's slower and do not
>>> support everything that is expected from a Linux file system.
>>>
>>> NFS would be a lot better.
>>
>> I surely missed the point (if NSF stands for network file
>                                  ^^^
> 	No NSF stands for National Science Foundation. NFS
> 	stands for network file system.
> 
>> system) : all drives are connected to the same PC, so the
>> system bus would be the most simple choice i guess ...
> 
> So just mount them.
> And you certainly do not want to use NFS or Samba.
> 
>>
>>>
>>> Issue you can have with network file systems is that all the
>>> lock files can exhaust the IO. So you want to keep the
>>> writes and reads to a minimum, so avoid using google chrome,
>>> chromium, firefox and so on.
>>>
>>>
>>>> I have thought of SYMLINKING.
>>>
>>> Why? Never thought of using the correct path instead when
>>> you mount the directory?
>>
>> this sound as a very interesting point, could you please
>> make an example of what you mean ?
>>
>> My base problem remains I don't really understand what mount
>> exactly mean internally. I remain attached willy nilly to
>> the old idea of phisical partitions seen as devices where
>> they are :\
>>
> Mount means: If you have a physical partition (or a file for that
> matter) make the contents of that partition available on a mountpoint in
> the filesystem.
> 
> mount /dev/sda7 /local/donaldduck
> means make the contents of the partition /dev/sda7 available at
> /local/donaldduck

first of all, I apologize for my english (in the other 
branch I was not able to convey the meaning ... i'm sorry)
that said,

I still don't understand the perspective of the proposed 
solution
when I read "mount /dev/sda7 /local/donaldduck
  means make the contents of the partition /dev/sda7 
available at /local/donaldduck"

I have the impression this is THE REVERSE of what I'm asking

I don't want to state :
I'll speak vis a vis the kernel :

hey, this is a partition that makes no particular sense to 
you, expose me at the folder name I'm suggesting

the question to me seems

hey, you expect a particular folder named /home/guy then 
search it on a certain FOLDER (and not on a partition or a disk)

I'm still not understanding if the solutions proposed (also 
the one by Joaho) are actually addressing this problem. 
Likely yes, but I'm in doubt


> 
> However I have no idea what your last sentence means. If you are
> thinking of the Windows idea of "mounting" where the contents of
> /dev/sda7 are made available at some silly drive letter E: for example,
> then that is NOT what linux does. It does not force you to remember what
> in the world drive Q: contains. you just mount it at a reasoanble point
> in your filesystem, with a name of the mountpoint hopefully giving you a
> clue as to what is in there
> /local/place/where/I/want/to/mount/mypicturebook
> for example.
>>
>>>
>>>
>>
>>


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#56862

On 2019-06-14, Soviet_Mario <SovietMario@CCCP.MIR> wrote:
> Il 14/06/19 17:55, William Unruh ha scritto:
>> On 2019-06-14, Soviet_Mario <SovietMario@CCCP.MIR> wrote:
>>> Il 14/06/19 07:05, J.O. Aho ha scritto:
>>>> On 13/06/2019 20.47, Soviet_Mario wrote:
>>>>
>>>>> I'd want to leverage to f12 bios option (boot device
>>>>> manual selection) to make a choice.
>>>>
>>>> Should work well, but you may up with a huge list of boot
>>>> options on each individual grub installer as many
>>>> distributions has setup a script to find other installed
>>>> OS:es on the machine.
>>>>
>>>>
>>>>> Meanwhile, as I have a big NEW and certified hdd (non ssd,
>>>>> a WD-red 2 TB), I'd also be willing to move the actual
>>>>> data of every HOME of any distro, each in a separate
>>>>> subtree of "\homes" shared folder.
>>>>
>>>> I would avoid using a samba share, it's slower and do not
>>>> support everything that is expected from a Linux file system.
>>>>
>>>> NFS would be a lot better.
>>>
>>> I surely missed the point (if NSF stands for network file
>>                                  ^^^
>> 	No NSF stands for National Science Foundation. NFS
>> 	stands for network file system.
>> 
>>> system) : all drives are connected to the same PC, so the
>>> system bus would be the most simple choice i guess ...
>> 
>> So just mount them.
>> And you certainly do not want to use NFS or Samba.
>> 
>>>
>>>>
>>>> Issue you can have with network file systems is that all the
>>>> lock files can exhaust the IO. So you want to keep the
>>>> writes and reads to a minimum, so avoid using google chrome,
>>>> chromium, firefox and so on.
>>>>
>>>>
>>>>> I have thought of SYMLINKING.
>>>>
>>>> Why? Never thought of using the correct path instead when
>>>> you mount the directory?
>>>
>>> this sound as a very interesting point, could you please
>>> make an example of what you mean ?
>>>
>>> My base problem remains I don't really understand what mount
>>> exactly mean internally. I remain attached willy nilly to
>>> the old idea of phisical partitions seen as devices where
>>> they are :\
>>>
>> Mount means: If you have a physical partition (or a file for that
>> matter) make the contents of that partition available on a mountpoint in
>> the filesystem.
>> 
>> mount /dev/sda7 /local/donaldduck
>> means make the contents of the partition /dev/sda7 available at
>> /local/donaldduck
>
> first of all, I apologize for my english (in the other 
> branch I was not able to convey the meaning ... i'm sorry)
> that said,
>
> I still don't understand the perspective of the proposed 
> solution
> when I read "mount /dev/sda7 /local/donaldduck
>   means make the contents of the partition /dev/sda7 
> available at /local/donaldduck"
>
> I have the impression this is THE REVERSE of what I'm asking

Since I have no idea what you are asking I cannot comment on this. 

>
> I don't want to state :

You don't want to state what?

> I'll speak vis a vis the kernel :

What has the kernel to do with this. 

>
> hey, this is a partition that makes no particular sense to 
> you, expose me at the folder name I'm suggesting
>
> the question to me seems
>
> hey, you expect a particular folder named /home/guy then 
> search it on a certain FOLDER (and not on a partition or a disk)

No idea what you mean by "Folder". 

The disk stores the data in partitions, and inodes are the locations on
the disk where the data is stored (very crudely speaking). . That is the
hardware which you do not want to be bothered with. You want
to look at the data. To do so you have "expose the data" by mounting 
it on the filesystem. The kernel does the job of translating your
request to look at the contents of /home/guy/secretporn to the locations
on the disk where the data is located. 

>
> I'm still not understanding if the solutions proposed (also 
> the one by Joaho) are actually addressing this problem. 
> Likely yes, but I'm in doubt

NO idea what the problem is. 

>
>
>> 
>> However I have no idea what your last sentence means. If you are
>> thinking of the Windows idea of "mounting" where the contents of
>> /dev/sda7 are made available at some silly drive letter E: for example,
>> then that is NOT what linux does. It does not force you to remember what
>> in the world drive Q: contains. you just mount it at a reasoanble point
>> in your filesystem, with a name of the mountpoint hopefully giving you a
>> clue as to what is in there
>> /local/place/where/I/want/to/mount/mypicturebook
>> for example.
>>>
>>>>
>>>>
>>>
>>>
>
>

[toc] | [prev] | [next] | [standalone]

#56866

Il 14/06/19 22:52, William Unruh ha scritto:
> On 2019-06-14, Soviet_Mario <SovietMario@CCCP.MIR> wrote:
>> Il 14/06/19 17:55, William Unruh ha scritto:
>>> On 2019-06-14, Soviet_Mario <SovietMario@CCCP.MIR> wrote:
>>>> Il 14/06/19 07:05, J.O. Aho ha scritto:
>>>>> On 13/06/2019 20.47, Soviet_Mario wrote:
>>>>>
>>>>>> I'd want to leverage to f12 bios option (boot device
>>>>>> manual selection) to make a choice.
>>>>>
>>>>> Should work well, but you may up with a huge list of boot
>>>>> options on each individual grub installer as many
>>>>> distributions has setup a script to find other installed
>>>>> OS:es on the machine.
>>>>>
>>>>>
>>>>>> Meanwhile, as I have a big NEW and certified hdd (non ssd,
>>>>>> a WD-red 2 TB), I'd also be willing to move the actual
>>>>>> data of every HOME of any distro, each in a separate
>>>>>> subtree of "\homes" shared folder.
>>>>>
>>>>> I would avoid using a samba share, it's slower and do not
>>>>> support everything that is expected from a Linux file system.
>>>>>
>>>>> NFS would be a lot better.
>>>>
>>>> I surely missed the point (if NSF stands for network file
>>>                                   ^^^
>>> 	No NSF stands for National Science Foundation. NFS
>>> 	stands for network file system.
>>>
>>>> system) : all drives are connected to the same PC, so the
>>>> system bus would be the most simple choice i guess ...
>>>
>>> So just mount them.
>>> And you certainly do not want to use NFS or Samba.
>>>
>>>>
>>>>>
>>>>> Issue you can have with network file systems is that all the
>>>>> lock files can exhaust the IO. So you want to keep the
>>>>> writes and reads to a minimum, so avoid using google chrome,
>>>>> chromium, firefox and so on.
>>>>>
>>>>>
>>>>>> I have thought of SYMLINKING.
>>>>>
>>>>> Why? Never thought of using the correct path instead when
>>>>> you mount the directory?
>>>>
>>>> this sound as a very interesting point, could you please
>>>> make an example of what you mean ?
>>>>
>>>> My base problem remains I don't really understand what mount
>>>> exactly mean internally. I remain attached willy nilly to
>>>> the old idea of phisical partitions seen as devices where
>>>> they are :\
>>>>
>>> Mount means: If you have a physical partition (or a file for that
>>> matter) make the contents of that partition available on a mountpoint in
>>> the filesystem.
>>>
>>> mount /dev/sda7 /local/donaldduck
>>> means make the contents of the partition /dev/sda7 available at
>>> /local/donaldduck
>>
>> first of all, I apologize for my english (in the other
>> branch I was not able to convey the meaning ... i'm sorry)
>> that said,
>>
>> I still don't understand the perspective of the proposed
>> solution
>> when I read "mount /dev/sda7 /local/donaldduck
>>    means make the contents of the partition /dev/sda7
>> available at /local/donaldduck"
>>
>> I have the impression this is THE REVERSE of what I'm asking
> 
> Since I have no idea what you are asking I cannot comment on this.
> 
>>
>> I don't want to state :
> 
> You don't want to state what?
> 
>> I'll speak vis a vis the kernel :
> 
> What has the kernel to do with this.

I meant "to the system overall" as a person

> 
>>
>> hey, this is a partition that makes no particular sense to
>> you, expose me at the folder name I'm suggesting
>>
>> the question to me seems
>>
>> hey, you expect a particular folder named /home/guy then
>> search it on a certain FOLDER (and not on a partition or a disk)
> 
> No idea what you mean by "Folder".

means DIRECTORY, that is an object of another level (a 
particular object in a file system) compared to a DEVICE

I'll have to understand if a folder/directory can be 
remounted onto another (residing in another FS) or if this 
is just another (wrong) way to call symlinking



> 
> The disk stores the data in partitions, and inodes are the locations on
> the disk where the data is stored (very crudely speaking). . That is the
> hardware which you do not want to be bothered with. You want
> to look at the data. To do so you have "expose the data" by mounting
> it on the filesystem. The kernel does the job of translating your
> request to look at the contents of /home/guy/secretporn to the locations
> on the disk where the data is located.
> 
>>
>> I'm still not understanding if the solutions proposed (also
>> the one by Joaho) are actually addressing this problem.
>> Likely yes, but I'm in doubt
> 
> NO idea what the problem is.
> 
>>
>>
>>>
>>> However I have no idea what your last sentence means. If you are
>>> thinking of the Windows idea of "mounting" where the contents of
>>> /dev/sda7 are made available at some silly drive letter E: for example,
>>> then that is NOT what linux does. It does not force you to remember what
>>> in the world drive Q: contains. you just mount it at a reasoanble point
>>> in your filesystem, with a name of the mountpoint hopefully giving you a
>>> clue as to what is in there
>>> /local/place/where/I/want/to/mount/mypicturebook
>>> for example.
>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#56868

On 2019-06-15, Soviet_Mario <SovietMario@CCCP.MIR> wrote:
> Il 14/06/19 22:52, William Unruh ha scritto:
>> On 2019-06-14, Soviet_Mario <SovietMario@CCCP.MIR> wrote:
>>> Il 14/06/19 17:55, William Unruh ha scritto:
>>>> On 2019-06-14, Soviet_Mario <SovietMario@CCCP.MIR> wrote:
>>>>> Il 14/06/19 07:05, J.O. Aho ha scritto:
>>>>>> On 13/06/2019 20.47, Soviet_Mario wrote:
>>>>>>
>>>>>>> I'd want to leverage to f12 bios option (boot device
>>>>>>> manual selection) to make a choice.
>>>>>>
>>>>>> Should work well, but you may up with a huge list of boot
>>>>>> options on each individual grub installer as many
>>>>>> distributions has setup a script to find other installed
>>>>>> OS:es on the machine.
>>>>>>
>>>>>>
>>>>>>> Meanwhile, as I have a big NEW and certified hdd (non ssd,
>>>>>>> a WD-red 2 TB), I'd also be willing to move the actual
>>>>>>> data of every HOME of any distro, each in a separate
>>>>>>> subtree of "\homes" shared folder.
>>>>>>
>>>>>> I would avoid using a samba share, it's slower and do not
>>>>>> support everything that is expected from a Linux file system.
>>>>>>
>>>>>> NFS would be a lot better.
>>>>>
>>>>> I surely missed the point (if NSF stands for network file
>>>>                                   ^^^
>>>> 	No NSF stands for National Science Foundation. NFS
>>>> 	stands for network file system.
>>>>
>>>>> system) : all drives are connected to the same PC, so the
>>>>> system bus would be the most simple choice i guess ...
>>>>
>>>> So just mount them.
>>>> And you certainly do not want to use NFS or Samba.
>>>>
>>>>>
>>>>>>
>>>>>> Issue you can have with network file systems is that all the
>>>>>> lock files can exhaust the IO. So you want to keep the
>>>>>> writes and reads to a minimum, so avoid using google chrome,
>>>>>> chromium, firefox and so on.
>>>>>>
>>>>>>
>>>>>>> I have thought of SYMLINKING.
>>>>>>
>>>>>> Why? Never thought of using the correct path instead when
>>>>>> you mount the directory?
>>>>>
>>>>> this sound as a very interesting point, could you please
>>>>> make an example of what you mean ?
>>>>>
>>>>> My base problem remains I don't really understand what mount
>>>>> exactly mean internally. I remain attached willy nilly to
>>>>> the old idea of phisical partitions seen as devices where
>>>>> they are :\
>>>>>
>>>> Mount means: If you have a physical partition (or a file for that
>>>> matter) make the contents of that partition available on a mountpoint in
>>>> the filesystem.
>>>>
>>>> mount /dev/sda7 /local/donaldduck
>>>> means make the contents of the partition /dev/sda7 available at
>>>> /local/donaldduck
>>>
>>> first of all, I apologize for my english (in the other
>>> branch I was not able to convey the meaning ... i'm sorry)
>>> that said,
>>>
>>> I still don't understand the perspective of the proposed
>>> solution
>>> when I read "mount /dev/sda7 /local/donaldduck
>>>    means make the contents of the partition /dev/sda7
>>> available at /local/donaldduck"
>>>
>>> I have the impression this is THE REVERSE of what I'm asking
>> 
>> Since I have no idea what you are asking I cannot comment on this.
>> 
>>>
>>> I don't want to state :
>> 
>> You don't want to state what?
>> 
>>> I'll speak vis a vis the kernel :
>> 
>> What has the kernel to do with this.
>
> I meant "to the system overall" as a person
>
>> 
>>>
>>> hey, this is a partition that makes no particular sense to
>>> you, expose me at the folder name I'm suggesting
>>>
>>> the question to me seems
>>>
>>> hey, you expect a particular folder named /home/guy then
>>> search it on a certain FOLDER (and not on a partition or a disk)
>> 
>> No idea what you mean by "Folder".
>
> means DIRECTORY, that is an object of another level (a 
> particular object in a file system) compared to a DEVICE
>
> I'll have to understand if a folder/directory can be 
> remounted onto another (residing in another FS) or if this 
> is just another (wrong) way to call symlinking

Data is on partitions on a disk. It cannot (well it can but usualy is
not) be read directly. You mount the partition into the filesystem, so
that the directory you mounted it on is where you access the data. 
Yes, you can remount a directory or a file onto another location in the
filesystem (called a bind mount). You can also use soft links to go via
an alternate directory, or file name. 

To soft link
If /local/daffy is a soft link to /alt/daisy, then you can refer to a
file say /alt/daisy/pluto also as /local/daffy/pluto.
The system will go through the path, and when it gets to daffy, it will
read that directory's entry in the filesystem and see that it should go
to /alt/daisy, and finally find /local/daffy/pluto as /alt/daisy/pluto.


>
>
>
>> 
>> The disk stores the data in partitions, and inodes are the locations on
>> the disk where the data is stored (very crudely speaking). . That is the
>> hardware which you do not want to be bothered with. You want
>> to look at the data. To do so you have "expose the data" by mounting
>> it on the filesystem. The kernel does the job of translating your
>> request to look at the contents of /home/guy/secretporn to the locations
>> on the disk where the data is located.
>> 
>>>
>>> I'm still not understanding if the solutions proposed (also
>>> the one by Joaho) are actually addressing this problem.
>>> Likely yes, but I'm in doubt
>> 
>> NO idea what the problem is.
>> 
>>>
>>>
>>>>
>>>> However I have no idea what your last sentence means. If you are
>>>> thinking of the Windows idea of "mounting" where the contents of
>>>> /dev/sda7 are made available at some silly drive letter E: for example,
>>>> then that is NOT what linux does. It does not force you to remember what
>>>> in the world drive Q: contains. you just mount it at a reasoanble point
>>>> in your filesystem, with a name of the mountpoint hopefully giving you a
>>>> clue as to what is in there
>>>> /local/place/where/I/want/to/mount/mypicturebook
>>>> for example.
>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

[toc] | [prev] | [next] | [standalone]

#56873

On 14.06.2019 at 22:29, Soviet_Mario scribbled:

> [...]
>
> I still don't understand the perspective of the proposed 
> solution
> when I read "mount /dev/sda7 /local/donaldduck
>   means make the contents of the partition /dev/sda7 
> available at /local/donaldduck"

Yes.

> I have the impression this is THE REVERSE of what I'm asking
> 
> I don't want to state :
> I'll speak vis a vis the kernel :
> 
> hey, this is a partition that makes no particular sense to 
> you, expose me at the folder name I'm suggesting
> 
> the question to me seems
> 
> hey, you expect a particular folder named /home/guy then 
> search it on a certain FOLDER (and not on a partition or a disk)

Yes, those are bind-mounts.  You can bind-mount a directory onto
another directory.  

It is similar to symlinking in terms of your ability to access the
data, but the difference is that it is done without using a symlink, so
that the same data becomes accessible at two different directories or
mountpoints.

See...

  $ man mount

... for details.

-- 
With respect,
= Aragorn =

[toc] | [prev] | [next] | [standalone]

#56947

Il 15/06/19 08:59, Aragorn ha scritto:
> On 14.06.2019 at 22:29, Soviet_Mario scribbled:
> 
>> [...]
>>
>> I still don't understand the perspective of the proposed
>> solution
>> when I read "mount /dev/sda7 /local/donaldduck
>>    means make the contents of the partition /dev/sda7
>> available at /local/donaldduck"
> 
> Yes.
> 
>> I have the impression this is THE REVERSE of what I'm asking
>>
>> I don't want to state :
>> I'll speak vis a vis the kernel :
>>
>> hey, this is a partition that makes no particular sense to
>> you, expose me at the folder name I'm suggesting
>>
>> the question to me seems
>>
>> hey, you expect a particular folder named /home/guy then
>> search it on a certain FOLDER (and not on a partition or a disk)
> 
> Yes, those are bind-mounts.  You can bind-mount a directory onto
> another directory.
> 
> It is similar to symlinking in terms of your ability to access the
> data, but the difference is that it is done without using a symlink, so
> that the same data becomes accessible at two different directories or
> mountpoints.
> 
> See...
> 
>    $ man mount

just done, but I do not understand almost anything, as there 
are not practical examples.
I very often find all manual pages too theoretical and poor 
of examples (in general), for me to actually exploit them



> 
> ... for details.
> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | alt.os.linux

csiph-web