Old PC 486/P1/P2 ISA slot motherboard/PC?

[Warren Chris]

Greetings,

It has been years since I last posted here...Alas, I could use some help in
regards to tracking down some older computer hardware.  I have a friend who
built a machine to punch out discs for antique music boxes back in the 90's
that was automated by a computer running Windows 95 (i know, i know).
 well, after all these years, that computer has failed, and his backup
computer has failed.  The controller that runs the machine is an ISA card,
so I am helping him track down an old P1 or PII system with ideally 2
ISA slots that we can hopefully rebuild his system with so he can continue
his work.

If you are curious, my friend is one of a handful, or the only person in
the world depending on the music box, conducting new works and providing
new discs for these music boxes.  He works out of his basement and has been
doing this for 50 years, out of Peterborough, NH.


any help would be greatly appreciated in tracking this PC hardware down.
 ideally we would like to build a system with redundant parts (power
supply, motherboard, ram, hard drive. cpu) and willing to pay
fair/reasonable cash prices.

Thanks for your help, best regards!


-- 
warren
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Have suggestions for a "roll your own file server"?

[Bruce Labitt]

I'll take a look at that.  Thanks for the link.

On Wed, Mar 10, 2021 at 8:15 PM Marc Nozell (m...@nozell.com) <
noz...@gmail.com> wrote:

> Just to put a plug in for a colleague's work:
> https://perfectmediaserver.com/It covers everything from disk
> purchasing strategies, burn-in, filesystems (ZFS, SnapRAID, etc).
>
> He also hosts a podcast that folks here may find interesting:
> https://selfhosted.show/
>
> -marc
>
> On Wed, Mar 10, 2021 at 8:08 PM  wrote:
>
>> OK:
>>
>> s/RPi4/some-other-cheap-computer-with-USB-3.x>/g
>>
>> Unless you build multiple Ethernet or WiFi or LTE modem connections your
>> networking will still be the slowest thing.
>>
>> You do not need huge amounts of CPU power, or huge amounts of RAM.
>>
>> My basic point is that if you stick with simple RAID (like mirroring) but
>> also set up a unit that is remote from your own home you could protect your
>> own data from fire, flood and theft to a reasonable level and even protect
>> your friend's data by backing up their data to your device.
>>
>> Add snapshots as suggested by Tom Buskey,perhaps encryption of file
>> systems and data-streams and you can have a rather simple, server where you
>> learn a lot by planning it out and setting it up rather than buying an "off
>> the shelf" solution or simply using a "web backup".
>>
>> And good catch on the USB power supply.
>>
>> md
>> > On 03/10/2021 6:53 PM Joshua Judson Rosen 
>> wrote:
>> >
>> >
>> > I'm not sure about the Raspberry Pi 4, but up thru the raspi 3+ there
>> are... problems, e.g.:
>> >
>> > Beware of USB on the raspi: there are some bugs in the silicon that
>> pretty severely
>> > cripple performance when multiple `bulk' devices are used at
>> simultaneously,
>> > sometimes to the point of making it unusable (e.g. if you want to use a
>> better Wi-Fi
>> > adapter/antenna than the one built onto the board, and connect an LTE
>> modem so that
>> > your raspi roam onto that if Wi-Fi becomes unavailable, throughput on
>> whichever of those
>> > interfaces you're actually using can become abysmal). IIRC the issue is
>> basically
>> > that the number of USB endpoints that can be assigned interrupts by the
>> raspi controller
>> > is _incredibly small_; and it's common for high-throughput devices to
>> have multiple endpoints per device--
>> > sometimes even one USB device will have more endpoints that the raspi
>> USB controller can handle.
>> >
>> > Also, `network fileserver with USB-attached hard drives' is kind of the
>> `peak unfitness'
>> > for the raspberry pi. Specifically if you've got it attached to
>> ethernet,
>> > the ethernet is attached through the same slow-ish USB bus as your HDDs.
>> >
>> > (the onboard Wi-Fi BTW is SDIO; so if you avoid using the onboard
>> Wi-Fi, I guess you might also
>> >  be able to make your µSD card faster...)
>> >
>> > ALSO: you'll really want to use an externally-powered USB hub for USB
>> devices
>> > that are not totally trivial, because the raspi's µUSB power supply is
>> already
>> > strained... (and if you're trying to power your raspi from some random
>> USB power supply,
>> > don't. Ideally you power it through the 5V pins on the expansion
>> header...).
>> >
>> >
>> > Though there is a lot of neat stuff that can be done with a Raspberry
>> Pi,
>> > it's really easy to overestimate it.
>> >
>> > But on the other hand: YMMV, and there are scenarios where the issues
>> don't matter,
>> > and might not even be noticeable. e.g., if you're dumping periodic
>> backups to your
>> > raspi asynchronously instead of (say) NFS mounting it and trying to use
>> it interactively,
>> > you might not even notice the weird bottlenecks because you're never
>> looking at them.
>> > And if you have enough of them as spares running simultaneously, you
>> may not care
>> > that every once in a while your fileystems get corrupted or your USB
>> ports stop working
>> > or whatever.
>> >
>> >
>> > On 3/8/21 9:56 PM, jonhal...@comcast.net wrote:
>> > > I will suggest something and let people rip it apart:
>> > >
>> > > Get two RPis that have at least USB 2.0  Attach two large capacity
>> disks to each one in a RAID-1 configuration (also known as "mirroring") to
>> keep it simple.  If one disk fails the other will still keep working (but
>> you should replace it as soon as possible).
>> > >
>> > > Put all of your data on both systems.
>> > >
>> > > Take one of your systems to a friends or relatives house who you
>> trust that has relatively good WiFi.  Make sure the friend is relatively
>> close, but is not in the same flood plain or fire area you are.
>> > >
>> > > Do an rsync every night to keep them in sync.
>> > >
>> > > Help your friend/relative do the same thing, keeping a copy of their
>> data in your house.   If your disks are big enough you could share systems
>> and disks.
>> > >
>> > > Use encryption as you wish.
>> > >
>> > > Disk failure?   Replace the disk and the data will be replicated.
>> > > Fire, theft, earthquake?   Take the replace

Re: Have suggestions for a "roll your own file server"?

[Bruce Labitt]

Actually, at the moment I am forced to run on a RPI4-4GB.  My laptop PS
died.  I'm aware of many of the downfalls of an RPI, I've had a few PI's
over the ages.  Mercifully, they are getting better.  One cannot run an SSD
AND and active USB3 hub both plugged directly into the 2 available USB3
ports.  The RPI4 will not boot.  The active hub's voltage backfeeds into
the Pi and the PI senses this, and prevents booting.  If however, the
active hub is buffered by a passive hub, it will work.  I discovered this
accidentally.

Anyhow, it's not too bad with two disks plugged into the active USB3 hub.
I had to rsync my laptop NVME to another NVME and it was sort of slow, but
I was transferring over 110GB.  Average transfer rate was over 90MB/sec for
all sorts of large and millions of small files.  Yeah not super fast, but
tolerable.  The file transfer was happening all the while I was using the
RPI4 for browsing with 14 active tabs.

I'm not using the SD card at the moment - that's unbearably slow.  I boot
from SSD.  (I lasted about a day using the RPI4 as a computer on an SD.  I
then ordered a $20 120GB SSD!)  Doing that, the RPI4 is tolerable,
especially with a slight overclock.  The RPI4 is a limited platform, but
it's not horrible, like it's predecessors were.  The earlier versions are
ok for print servers, sprinkler controllers and DNS filters (pihole).  I
think an RPI4 could make an ok host for a mirror array.  Don't know how to
do it yet, but it seems very approachable.

What I haven't figured out is how to have a remote offsite PI as well.
Just don't know how to secure it and be able to access it remotely.  At the
moment it's beyond my skill set.


On Wed, Mar 10, 2021 at 6:54 PM Joshua Judson Rosen 
wrote:

> I'm not sure about the Raspberry Pi 4, but up thru the raspi 3+ there
> are... problems, e.g.:
>
> Beware of USB on the raspi: there are some bugs in the silicon that pretty
> severely
> cripple performance when multiple `bulk' devices are used at
> simultaneously,
> sometimes to the point of making it unusable (e.g. if you want to use a
> better Wi-Fi
> adapter/antenna than the one built onto the board, and connect an LTE
> modem so that
> your raspi roam onto that if Wi-Fi becomes unavailable, throughput on
> whichever of those
> interfaces you're actually using can become abysmal). IIRC the issue is
> basically
> that the number of USB endpoints that can be assigned interrupts by the
> raspi controller
> is _incredibly small_; and it's common for high-throughput devices to have
> multiple endpoints per device--
> sometimes even one USB device will have more endpoints that the raspi USB
> controller can handle.
>
> Also, `network fileserver with USB-attached hard drives' is kind of the
> `peak unfitness'
> for the raspberry pi. Specifically if you've got it attached to ethernet,
> the ethernet is attached through the same slow-ish USB bus as your HDDs.
>
> (the onboard Wi-Fi BTW is SDIO; so if you avoid using the onboard Wi-Fi, I
> guess you might also
>  be able to make your µSD card faster...)
>
> ALSO: you'll really want to use an externally-powered USB hub for USB
> devices
> that are not totally trivial, because the raspi's µUSB power supply is
> already
> strained... (and if you're trying to power your raspi from some random USB
> power supply,
> don't. Ideally you power it through the 5V pins on the expansion
> header...).
>
>
> Though there is a lot of neat stuff that can be done with a Raspberry Pi,
> it's really easy to overestimate it.
>
> But on the other hand: YMMV, and there are scenarios where the issues
> don't matter,
> and might not even be noticeable. e.g., if you're dumping periodic backups
> to your
> raspi asynchronously instead of (say) NFS mounting it and trying to use it
> interactively,
> you might not even notice the weird bottlenecks because you're never
> looking at them.
> And if you have enough of them as spares running simultaneously, you may
> not care
> that every once in a while your fileystems get corrupted or your USB ports
> stop working
> or whatever.
>
>
> On 3/8/21 9:56 PM, jonhal...@comcast.net wrote:
> > I will suggest something and let people rip it apart:
> >
> > Get two RPis that have at least USB 2.0  Attach two large capacity disks
> to each one in a RAID-1 configuration (also known as "mirroring") to keep
> it simple.  If one disk fails the other will still keep working (but you
> should replace it as soon as possible).
> >
> > Put all of your data on both systems.
> >
> > Take one of your systems to a friends or relatives house who you trust
> that has relatively good WiFi.  Make sure the friend is relatively close,
> but is not in the same flood plain or fire area you are.
> >
> > Do an rsync every night to keep them in sync.
> >
> > Help your friend/relative do the same thing, keeping a copy of their
> data in your house.   If your disks are big enough you could share systems
> and disks.
> >
> > Use encryption as you wish.
> >
> > Disk failure?   R

Re: Have suggestions for a "roll your own file server"?

[Marc Nozell (m...@nozell.com)]

Just to put a plug in for a colleague's work:
https://perfectmediaserver.com/It covers everything from disk
purchasing strategies, burn-in, filesystems (ZFS, SnapRAID, etc).

He also hosts a podcast that folks here may find interesting:
https://selfhosted.show/

-marc

On Wed, Mar 10, 2021 at 8:08 PM  wrote:

> OK:
>
> s/RPi4/some-other-cheap-computer-with-USB-3.x>/g
>
> Unless you build multiple Ethernet or WiFi or LTE modem connections your
> networking will still be the slowest thing.
>
> You do not need huge amounts of CPU power, or huge amounts of RAM.
>
> My basic point is that if you stick with simple RAID (like mirroring) but
> also set up a unit that is remote from your own home you could protect your
> own data from fire, flood and theft to a reasonable level and even protect
> your friend's data by backing up their data to your device.
>
> Add snapshots as suggested by Tom Buskey,perhaps encryption of file
> systems and data-streams and you can have a rather simple, server where you
> learn a lot by planning it out and setting it up rather than buying an "off
> the shelf" solution or simply using a "web backup".
>
> And good catch on the USB power supply.
>
> md
> > On 03/10/2021 6:53 PM Joshua Judson Rosen 
> wrote:
> >
> >
> > I'm not sure about the Raspberry Pi 4, but up thru the raspi 3+ there
> are... problems, e.g.:
> >
> > Beware of USB on the raspi: there are some bugs in the silicon that
> pretty severely
> > cripple performance when multiple `bulk' devices are used at
> simultaneously,
> > sometimes to the point of making it unusable (e.g. if you want to use a
> better Wi-Fi
> > adapter/antenna than the one built onto the board, and connect an LTE
> modem so that
> > your raspi roam onto that if Wi-Fi becomes unavailable, throughput on
> whichever of those
> > interfaces you're actually using can become abysmal). IIRC the issue is
> basically
> > that the number of USB endpoints that can be assigned interrupts by the
> raspi controller
> > is _incredibly small_; and it's common for high-throughput devices to
> have multiple endpoints per device--
> > sometimes even one USB device will have more endpoints that the raspi
> USB controller can handle.
> >
> > Also, `network fileserver with USB-attached hard drives' is kind of the
> `peak unfitness'
> > for the raspberry pi. Specifically if you've got it attached to ethernet,
> > the ethernet is attached through the same slow-ish USB bus as your HDDs.
> >
> > (the onboard Wi-Fi BTW is SDIO; so if you avoid using the onboard Wi-Fi,
> I guess you might also
> >  be able to make your µSD card faster...)
> >
> > ALSO: you'll really want to use an externally-powered USB hub for USB
> devices
> > that are not totally trivial, because the raspi's µUSB power supply is
> already
> > strained... (and if you're trying to power your raspi from some random
> USB power supply,
> > don't. Ideally you power it through the 5V pins on the expansion
> header...).
> >
> >
> > Though there is a lot of neat stuff that can be done with a Raspberry Pi,
> > it's really easy to overestimate it.
> >
> > But on the other hand: YMMV, and there are scenarios where the issues
> don't matter,
> > and might not even be noticeable. e.g., if you're dumping periodic
> backups to your
> > raspi asynchronously instead of (say) NFS mounting it and trying to use
> it interactively,
> > you might not even notice the weird bottlenecks because you're never
> looking at them.
> > And if you have enough of them as spares running simultaneously, you may
> not care
> > that every once in a while your fileystems get corrupted or your USB
> ports stop working
> > or whatever.
> >
> >
> > On 3/8/21 9:56 PM, jonhal...@comcast.net wrote:
> > > I will suggest something and let people rip it apart:
> > >
> > > Get two RPis that have at least USB 2.0  Attach two large capacity
> disks to each one in a RAID-1 configuration (also known as "mirroring") to
> keep it simple.  If one disk fails the other will still keep working (but
> you should replace it as soon as possible).
> > >
> > > Put all of your data on both systems.
> > >
> > > Take one of your systems to a friends or relatives house who you trust
> that has relatively good WiFi.  Make sure the friend is relatively close,
> but is not in the same flood plain or fire area you are.
> > >
> > > Do an rsync every night to keep them in sync.
> > >
> > > Help your friend/relative do the same thing, keeping a copy of their
> data in your house.   If your disks are big enough you could share systems
> and disks.
> > >
> > > Use encryption as you wish.
> > >
> > > Disk failure?   Replace the disk and the data will be replicated.
> > > Fire, theft, earthquake?   Take the replaced system over to your
> friends/relatives and copy the data at high speed, then take the copied
> system back to your house and start using it again.
> > >
> > > You would need three disks to fail at relatively the same time to lose
> your data.   Or an asteroid crashing 

Re: Have suggestions for a "roll your own file server"?

[jonhall80]

OK:

s/RPi4/some-other-cheap-computer-with-USB-3.x>/g

Unless you build multiple Ethernet or WiFi or LTE modem connections your 
networking will still be the slowest thing.

You do not need huge amounts of CPU power, or huge amounts of RAM.

My basic point is that if you stick with simple RAID (like mirroring) but also 
set up a unit that is remote from your own home you could protect your own data 
from fire, flood and theft to a reasonable level and even protect your friend's 
data by backing up their data to your device.

Add snapshots as suggested by Tom Buskey,perhaps encryption of file systems and 
data-streams and you can have a rather simple, server where you learn a lot by 
planning it out and setting it up rather than buying an "off the shelf" 
solution or simply using a "web backup".

And good catch on the USB power supply.

md
> On 03/10/2021 6:53 PM Joshua Judson Rosen  wrote:
> 
>  
> I'm not sure about the Raspberry Pi 4, but up thru the raspi 3+ there are... 
> problems, e.g.:
> 
> Beware of USB on the raspi: there are some bugs in the silicon that pretty 
> severely
> cripple performance when multiple `bulk' devices are used at simultaneously,
> sometimes to the point of making it unusable (e.g. if you want to use a 
> better Wi-Fi
> adapter/antenna than the one built onto the board, and connect an LTE modem 
> so that
> your raspi roam onto that if Wi-Fi becomes unavailable, throughput on 
> whichever of those
> interfaces you're actually using can become abysmal). IIRC the issue is 
> basically
> that the number of USB endpoints that can be assigned interrupts by the raspi 
> controller
> is _incredibly small_; and it's common for high-throughput devices to have 
> multiple endpoints per device--
> sometimes even one USB device will have more endpoints that the raspi USB 
> controller can handle.
> 
> Also, `network fileserver with USB-attached hard drives' is kind of the `peak 
> unfitness'
> for the raspberry pi. Specifically if you've got it attached to ethernet,
> the ethernet is attached through the same slow-ish USB bus as your HDDs.
> 
> (the onboard Wi-Fi BTW is SDIO; so if you avoid using the onboard Wi-Fi, I 
> guess you might also
>  be able to make your µSD card faster...)
> 
> ALSO: you'll really want to use an externally-powered USB hub for USB devices
> that are not totally trivial, because the raspi's µUSB power supply is already
> strained... (and if you're trying to power your raspi from some random USB 
> power supply,
> don't. Ideally you power it through the 5V pins on the expansion header...).
> 
> 
> Though there is a lot of neat stuff that can be done with a Raspberry Pi,
> it's really easy to overestimate it.
> 
> But on the other hand: YMMV, and there are scenarios where the issues don't 
> matter,
> and might not even be noticeable. e.g., if you're dumping periodic backups to 
> your
> raspi asynchronously instead of (say) NFS mounting it and trying to use it 
> interactively,
> you might not even notice the weird bottlenecks because you're never looking 
> at them.
> And if you have enough of them as spares running simultaneously, you may not 
> care
> that every once in a while your fileystems get corrupted or your USB ports 
> stop working
> or whatever.
> 
> 
> On 3/8/21 9:56 PM, jonhal...@comcast.net wrote:
> > I will suggest something and let people rip it apart:
> > 
> > Get two RPis that have at least USB 2.0  Attach two large capacity disks to 
> > each one in a RAID-1 configuration (also known as "mirroring") to keep it 
> > simple.  If one disk fails the other will still keep working (but you 
> > should replace it as soon as possible).
> > 
> > Put all of your data on both systems.
> > 
> > Take one of your systems to a friends or relatives house who you trust that 
> > has relatively good WiFi.  Make sure the friend is relatively close, but is 
> > not in the same flood plain or fire area you are.
> > 
> > Do an rsync every night to keep them in sync.
> > 
> > Help your friend/relative do the same thing, keeping a copy of their data 
> > in your house.   If your disks are big enough you could share systems and 
> > disks.
> > 
> > Use encryption as you wish.
> > 
> > Disk failure?   Replace the disk and the data will be replicated.
> > Fire, theft, earthquake?   Take the replaced system over to your 
> > friends/relatives and copy the data at high speed, then take the copied 
> > system back to your house and start using it again.
> > 
> > You would need three disks to fail at relatively the same time to lose your 
> > data.   Or an asteroid crashing that wipes out all life on the planet.  
> > Unlikely.
> > 
> > Realize that nothing is forever.
> > 
> > md
> >> On 03/08/2021 7:33 PM Bruce Labitt  wrote:
> >>  
> >>  
> >> For the second time in 3 months I have had a computer failure.  Oddly, it 
> >> was a PS on the motherboard both times.  (Two different MB's.)  
> >> Fortunately the disks were ok.  I'm living on borrowed time.  Next time, I 
> >

Re: Have suggestions for a "roll your own file server"?

[Joshua Judson Rosen]

I'm not sure about the Raspberry Pi 4, but up thru the raspi 3+ there are... 
problems, e.g.:

Beware of USB on the raspi: there are some bugs in the silicon that pretty 
severely
cripple performance when multiple `bulk' devices are used at simultaneously,
sometimes to the point of making it unusable (e.g. if you want to use a better 
Wi-Fi
adapter/antenna than the one built onto the board, and connect an LTE modem so 
that
your raspi roam onto that if Wi-Fi becomes unavailable, throughput on whichever 
of those
interfaces you're actually using can become abysmal). IIRC the issue is 
basically
that the number of USB endpoints that can be assigned interrupts by the raspi 
controller
is _incredibly small_; and it's common for high-throughput devices to have 
multiple endpoints per device--
sometimes even one USB device will have more endpoints that the raspi USB 
controller can handle.

Also, `network fileserver with USB-attached hard drives' is kind of the `peak 
unfitness'
for the raspberry pi. Specifically if you've got it attached to ethernet,
the ethernet is attached through the same slow-ish USB bus as your HDDs.

(the onboard Wi-Fi BTW is SDIO; so if you avoid using the onboard Wi-Fi, I 
guess you might also
 be able to make your µSD card faster...)

ALSO: you'll really want to use an externally-powered USB hub for USB devices
that are not totally trivial, because the raspi's µUSB power supply is already
strained... (and if you're trying to power your raspi from some random USB 
power supply,
don't. Ideally you power it through the 5V pins on the expansion header...).


Though there is a lot of neat stuff that can be done with a Raspberry Pi,
it's really easy to overestimate it.

But on the other hand: YMMV, and there are scenarios where the issues don't 
matter,
and might not even be noticeable. e.g., if you're dumping periodic backups to 
your
raspi asynchronously instead of (say) NFS mounting it and trying to use it 
interactively,
you might not even notice the weird bottlenecks because you're never looking at 
them.
And if you have enough of them as spares running simultaneously, you may not 
care
that every once in a while your fileystems get corrupted or your USB ports stop 
working
or whatever.


On 3/8/21 9:56 PM, jonhal...@comcast.net wrote:
> I will suggest something and let people rip it apart:
> 
> Get two RPis that have at least USB 2.0  Attach two large capacity disks to 
> each one in a RAID-1 configuration (also known as "mirroring") to keep it 
> simple.  If one disk fails the other will still keep working (but you should 
> replace it as soon as possible).
> 
> Put all of your data on both systems.
> 
> Take one of your systems to a friends or relatives house who you trust that 
> has relatively good WiFi.  Make sure the friend is relatively close, but is 
> not in the same flood plain or fire area you are.
> 
> Do an rsync every night to keep them in sync.
> 
> Help your friend/relative do the same thing, keeping a copy of their data in 
> your house.   If your disks are big enough you could share systems and disks.
> 
> Use encryption as you wish.
> 
> Disk failure?   Replace the disk and the data will be replicated.
> Fire, theft, earthquake?   Take the replaced system over to your 
> friends/relatives and copy the data at high speed, then take the copied 
> system back to your house and start using it again.
> 
> You would need three disks to fail at relatively the same time to lose your 
> data.   Or an asteroid crashing that wipes out all life on the planet.  
> Unlikely.
> 
> Realize that nothing is forever.
> 
> md
>> On 03/08/2021 7:33 PM Bruce Labitt  wrote:
>>  
>>  
>> For the second time in 3 months I have had a computer failure.  Oddly, it 
>> was a PS on the motherboard both times.  (Two different MB's.)  Fortunately 
>> the disks were ok.  I'm living on borrowed time.  Next time, I may not be 
>> that lucky.  
>>  
>> Need a file server system with some sort of RAID redundancy.  I want to 
>> backup 2 main computers, plus photos.  Maybe this RPI4 too, since that's 
>> what I'm running on, due to the second failure.  If this SSD goes, I'm gonna 
>> be a sad puppy.  This is for home use, so we are not talking Exabytes.  I'm 
>> thinking about 2-4TB of RAID.  Unless of course, RAID is obsolete these 
>> days.  Honestly, I find some of the levels of RAID confusing.  I want 
>> something that will survive a disk
>> failure (or two) out of the array.  Have any ideas, or can you point me to 
>> some place that discusses this somewhat intelligently?
>>  
>> Are there reasonable systems that one can put together oneself these days?  
>> Can I repurpose an older PC for this purpose?  Or an RPI4?  What are the 
>> gotchas of going this way?
>>  
>> I want to be able to set up a daily rsync or equivalent so we will lose as 
>> little as possible.  At the moment, I'm not thinking about surviving fire or 
>> disaster.  Maybe I should, but I suspect the costs balloon considerably.  

Re: Kind of puzzled about timestamps

[jonhall80]

I think that "time" is a bit like "taxes".   Everyone agrees life would be 
better if it was simpler, but people can not agree on how to do that, so we 
waste a lot of effort dealing with it.

md

On 03/10/2021 4:28 PM Ray Cote  wrote:

>  
>  
> No conversation about time is complete without a nod to 'Calendrical 
> Calculations' by Reingold and Dershowitz:  
> https://www.cambridge.org/us/academic/subjects/computer-science/computing-general-interest/calendrical-calculations-ultimate-edition-4th-edition?format=HB&isbn=9781107057623
>  
> I have three editions of this on my shelf. Everytime I think I have a 
> hard problem to solve I peruse a chapter and then realize my problems aren't 
> as difficult as time...
> --Ray
> 
> On Wed, Mar 10, 2021 at 12:51 PM Jerry Feldman < gaf.li...@gmail.com 
> mailto:gaf.li...@gmail.com > wrote:
> 
> > > Actually in was the Germans in 1916 that implemented it 
> first. Almost every other country adopted it shortly after, and we adopted it 
> in 1918.
> >  
> > IMHO: it made sense back then when the world was not universally 
> > electrified. It does not make sense in the 21st century. 
> > 
> > --
> > Jerry Feldman < gaf.li...@gmail.com mailto:gaf.li...@gmail.com >
> > Boston Linux and Unix http://www.blu.org
> > PGP key id: 6F6BB6E7
> > PGP Key fingerprint: 0EDC 2FF5 53A6 8EED 84D1  3050 5715 B88D 6F6
> > B B6E7
> > 
> > On Wed, Mar 10, 2021, 12:41 PM Tom Buskey < t...@buskey.name 
> > mailto:t...@buskey.name > wrote:
> > 
> > > > >  
> > > 
> > > On Mon, Mar 8, 2021 at 2:59 PM Curt Howland < 
> > > howl...@priss.com mailto:howl...@priss.com > wrote:
> > > 
> > > > > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA256
> > > > 
> > > > On Monday 08 March 2021, Joshua Judson Rosen was heard 
> > > > to say:
> > > > > On 3/6/21 9:17 PM, Curt Howland wrote:
> > > > > > I mean, how silly can one be to object to it being 
> > > > dark when you
> > > > > > wake up, and then demanding that everyone else 
> > > > change the time on
> > > > > > their clocks so it's light at 7am the way you want 
> > > > it to be?
> > > > >
> > > > > Isn't that pretty much exactly the _opposite_ of what 
> > > > DST does?
> > > > 
> > > > Yes. That is given as a reason to change the clocks. 
> > > > Back during the
> > > > wave of "energy saving measures" in the early 1970s, 
> > > > staying on DST
> > > > through the year was objected to because, and I quote, 
> > > > "Children were
> > > > waiting for the bus in the dark."
> > > > 
> > > > 
> > > > > > >  
> > > And when they moved the dates by 3 weeks in 2007, they found 
> > > that the energy changes depended on your climate.  A study in California 
> > > found a 0.2% decrease in electricity.  A 2008 study in Indiana had a 1% 
> > > increase in consumption.
> > >  
> > > Of course that 1% in Indiana translated to ~ $9 million/yr.
> > >  
> > > FWIW, changing the clocks is not an American thing.  The UK 
> > > developed BST 1st.  So even the UK doesn't stay on GMT!
> > >  
> > > ___
> > > gnhlug-discuss mailing list
> > > gnhlug-discuss@mail.gnhlug.org 
> > > mailto:gnhlug-discuss@mail.gnhlug.org
> > > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> > > 
> > > > > ___
> > gnhlug-discuss mailing list
> > gnhlug-discuss@mail.gnhlug.org mailto:gnhlug-discuss@mail.gnhlug.org
> > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> > 
> > > 
>  
> --
> Raymond Cote, CTO
> voice: +1.603.924.6079 email: rgac...@appropriatesolutions.com skype: 
> ray.cote
> Schedule a meeting: https://calendly.com/ray_cote/60min/
>  
>  
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> 
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Ray Cote]

No conversation about time is complete without a nod to 'Calendrical
Calculations' by Reingold and Dershowitz:
https://www.cambridge.org/us/academic/subjects/computer-science/computing-general-interest/calendrical-calculations-ultimate-edition-4th-edition?format=HB&isbn=9781107057623

I have three editions of this on my shelf. Everytime I think I have a hard
problem to solve I peruse a chapter and then realize my problems aren't as
difficult as time...
--Ray

On Wed, Mar 10, 2021 at 12:51 PM Jerry Feldman  wrote:

> Actually in was the Germans in 1916 that implemented it first. Almost
> every other country adopted it shortly after, and we adopted it in 1918.
>
> IMHO: it made sense back then when the world was not universally
> electrified. It does not make sense in the 21st century.
>
> --
> Jerry Feldman 
> Boston Linux and Unix http://www.blu.org
> PGP key id: 6F6BB6E7
> PGP Key fingerprint: 0EDC 2FF5 53A6 8EED 84D1  3050 5715 B88D 6F6
> B B6E7
>
> On Wed, Mar 10, 2021, 12:41 PM Tom Buskey  wrote:
>
>>
>>
>> On Mon, Mar 8, 2021 at 2:59 PM Curt Howland  wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> On Monday 08 March 2021, Joshua Judson Rosen was heard to say:
>>> > On 3/6/21 9:17 PM, Curt Howland wrote:
>>> > > I mean, how silly can one be to object to it being dark when you
>>> > > wake up, and then demanding that everyone else change the time on
>>> > > their clocks so it's light at 7am the way you want it to be?
>>> >
>>> > Isn't that pretty much exactly the _opposite_ of what DST does?
>>>
>>> Yes. That is given as a reason to change the clocks. Back during the
>>> wave of "energy saving measures" in the early 1970s, staying on DST
>>> through the year was objected to because, and I quote, "Children were
>>> waiting for the bus in the dark."
>>>
>>>
>> And when they moved the dates by 3 weeks in 2007, they found that the
>> energy changes depended on your climate.  A study in California found a
>> 0.2% decrease in electricity.  A 2008 study in Indiana had a 1% increase in
>> consumption.
>>
>> Of course that 1% in Indiana translated to ~ $9 million/yr.
>>
>> FWIW, changing the clocks is not an American thing.  The UK developed BST
>> 1st.  So even the UK doesn't stay on GMT!
>>
>> ___
>> gnhlug-discuss mailing list
>> gnhlug-discuss@mail.gnhlug.org
>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>


-- 
Raymond Cote, CTO
voice: +1.603.924.6079 email: rgac...@appropriatesolutions.com skype:
ray.cote
Schedule a meeting: https://calendly.com/ray_cote/60min/
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Have suggestions for a "roll your own file server"?

[Tom Buskey]

And make sure you get alerts when something fails.

There are a number of commercial NAS like Synology out there if you don't
want to build it yourself.

I'd also add some kind of offsite storage.  If you have decent internet
speed, cloud storage is a good choice.

Something with error correction is also good.

What I do:
I have the OS on its own disk.  I've done RAID in the past, but I'm ok with
rebuilding the OS.  A failed drive == forced upgrade.  For home, I'm ok
with this for heat/electricity costs.

For data, I've been using ZFS on Solaris -> OpenSolaris -> Ubuntu,  I think
15+ years.  I'm very happy with it.
I've used as low as 1GB, but more is better.  Dual core with 4GB is enough
for a home system IMO
If you've ever used a NetApp, it is similar.
It has snapshots that can persist forever.  My system takes one every hour,
day, week, month and keeps them for some multiple of that time.
You can divide the pool into "partitions" with changing size limits
(quota).
RAID is part of the FS.  mirrors, stripes and a raid5 like raidz.  Also
variants that can survive the failure of 2 drives ( raidz2 ~ raid6 and
triple mirrors)
Error detection.  If there is an error, the FS stops writing to prevent
more.  It's a bad idea to run ZFS on single drives.
If you have RAID, the FS has another copy to reference and can self heal
the error.
It has compression built in with negligible performance hit.
It has dedup.  Don't use it IMO.  Maybe if you have infinite RAM.

You can't expand the pool by adding disks.  So a 3 disk RAIDZ can't be
expanded by adding a 4th.
You can replace/rebuild disks with larger disks to increase the pool size.
It works well.

I create mirrors.  When I need more space, I add another mirror with newer
drives.
Fewer spinning drives means less electricity used if that's a big issue.

The family uses samba, NFS or the web server to get to data.  SFTP also
works.  They don't have to care about the disks underneath unless they fill
up the share.  Then it's a quick quota change and ask them to pare down how
many copies of that CD they really need.

In the past I used Crashplan for offsite.  They no longer offer the
unlimited systems for personal use, but I think a single system with
unlimited space is available.

Snapshots cover: Oops!  I deleted it by accident, can I get it back?  Well,
except for deleting a "partition" or pool.
Off site covers:  Oops! The house burned down, where are the family photos.



On Mon, Mar 8, 2021 at 10:00 PM  wrote:

> I forgot one thing:
>
> Set up a shell script to do a simple diagnostic on both systems to detect
> a failed or failing system.  Run two or three times a day.
>
> md
>
> On 03/08/2021 9:56 PM jonhal...@comcast.net wrote:
>
>
> I will suggest something and let people rip it apart:
>
> Get two RPis that have at least USB 2.0  Attach two large capacity disks
> to each one in a RAID-1 configuration (also known as "mirroring") to keep
> it simple.  If one disk fails the other will still keep working (but you
> should replace it as soon as possible).
>
> Put all of your data on both systems.
>
> Take one of your systems to a friends or relatives house who you trust
> that has relatively good WiFi.  Make sure the friend is relatively close,
> but is not in the same flood plain or fire area you are.
>
> Do an rsync every night to keep them in sync.
>
> Help your friend/relative do the same thing, keeping a copy of their data
> in your house.   If your disks are big enough you could share systems and
> disks.
>
> Use encryption as you wish.
>
> Disk failure?   Replace the disk and the data will be replicated.
> Fire, theft, earthquake?   Take the replaced system over to your
> friends/relatives and copy the data at high speed, then take the copied
> system back to your house and start using it again.
>
> You would need three disks to fail at relatively the same time to lose
> your data.   Or an asteroid crashing that wipes out all life on the
> planet.  Unlikely.
>
> Realize that nothing is forever.
>
> md
>
> On 03/08/2021 7:33 PM Bruce Labitt  wrote:
>
>
> For the second time in 3 months I have had a computer failure.  Oddly, it
> was a PS on the motherboard both times.  (Two different MB's.)  Fortunately
> the disks were ok.  I'm living on borrowed time.  Next time, I may not be
> that lucky.
>
> Need a file server system with some sort of RAID redundancy.  I want to
> backup 2 main computers, plus photos.  Maybe this RPI4 too, since that's
> what I'm running on, due to the second failure.  If this SSD goes, I'm
> gonna be a sad puppy.  This is for home use, so we are not talking
> Exabytes.  I'm thinking about 2-4TB of RAID.  Unless of course, RAID is
> obsolete these days.  Honestly, I find some of the levels of RAID
> confusing.  I want something that will survive a disk failure (or two) out
> of the array.  Have any ideas, or can you point me to some place that
> discusses this somewhat intelligently?
>
> Are there reasonable systems that one can put together 

Re: Kind of puzzled about timestamps

[Jerry Feldman]

Actually in was the Germans in 1916 that implemented it first. Almost every
other country adopted it shortly after, and we adopted it in 1918.

IMHO: it made sense back then when the world was not universally
electrified. It does not make sense in the 21st century.

--
Jerry Feldman 
Boston Linux and Unix http://www.blu.org
PGP key id: 6F6BB6E7
PGP Key fingerprint: 0EDC 2FF5 53A6 8EED 84D1  3050 5715 B88D 6F6
B B6E7

On Wed, Mar 10, 2021, 12:41 PM Tom Buskey  wrote:

>
>
> On Mon, Mar 8, 2021 at 2:59 PM Curt Howland  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On Monday 08 March 2021, Joshua Judson Rosen was heard to say:
>> > On 3/6/21 9:17 PM, Curt Howland wrote:
>> > > I mean, how silly can one be to object to it being dark when you
>> > > wake up, and then demanding that everyone else change the time on
>> > > their clocks so it's light at 7am the way you want it to be?
>> >
>> > Isn't that pretty much exactly the _opposite_ of what DST does?
>>
>> Yes. That is given as a reason to change the clocks. Back during the
>> wave of "energy saving measures" in the early 1970s, staying on DST
>> through the year was objected to because, and I quote, "Children were
>> waiting for the bus in the dark."
>>
>>
> And when they moved the dates by 3 weeks in 2007, they found that the
> energy changes depended on your climate.  A study in California found a
> 0.2% decrease in electricity.  A 2008 study in Indiana had a 1% increase in
> consumption.
>
> Of course that 1% in Indiana translated to ~ $9 million/yr.
>
> FWIW, changing the clocks is not an American thing.  The UK developed BST
> 1st.  So even the UK doesn't stay on GMT!
>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Kind of puzzled about timestamps

[Tom Buskey]

On Mon, Mar 8, 2021 at 2:59 PM Curt Howland  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Monday 08 March 2021, Joshua Judson Rosen was heard to say:
> > On 3/6/21 9:17 PM, Curt Howland wrote:
> > > I mean, how silly can one be to object to it being dark when you
> > > wake up, and then demanding that everyone else change the time on
> > > their clocks so it's light at 7am the way you want it to be?
> >
> > Isn't that pretty much exactly the _opposite_ of what DST does?
>
> Yes. That is given as a reason to change the clocks. Back during the
> wave of "energy saving measures" in the early 1970s, staying on DST
> through the year was objected to because, and I quote, "Children were
> waiting for the bus in the dark."
>
>
And when they moved the dates by 3 weeks in 2007, they found that the
energy changes depended on your climate.  A study in California found a
0.2% decrease in electricity.  A 2008 study in Indiana had a 1% increase in
consumption.

Of course that 1% in Indiana translated to ~ $9 million/yr.

FWIW, changing the clocks is not an American thing.  The UK developed BST
1st.  So even the UK doesn't stay on GMT!
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/