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

Groups > linux.debian.user > #226741 > unrolled thread

32 versus 64 bit reading list suggestions

Back to article view | Back to linux.debian.user

Contents

  32 versus 64 bit reading list suggestions Richard Owlett <rowlett@cloud85.net> - 2020-09-07 15:50 +0200
    Re: 32 versus 64 bit reading list suggestions Reco <recoverym4n@enotuniq.net> - 2020-09-07 16:20 +0200
      Re: 32 versus 64 bit reading list suggestions David Wright <deblis@lionunicorn.co.uk> - 2020-09-07 16:50 +0200
      Re: 32 versus 64 bit reading list suggestions Richard Owlett <rowlett@cloud85.net> - 2020-09-07 17:10 +0200
        Re: 32 versus 64 bit reading list suggestions Reco <recoverym4n@enotuniq.net> - 2020-09-07 17:20 +0200
          Re: 32 versus 64 bit reading list suggestions Richard Owlett <rowlett@cloud85.net> - 2020-09-07 17:50 +0200
    Re: 32 versus 64 bit reading list suggestions Jonathan Dowland <jon+debian-user@dow.land> - 2020-09-07 16:30 +0200
      Re: 32 versus 64 bit reading list suggestions Richard Owlett <rowlett@cloud85.net> - 2020-09-07 17:20 +0200
        Re: 32 versus 64 bit reading list suggestions Andrew Cater <amacater@gmail.com> - 2020-09-07 17:30 +0200
          Re: 32 versus 64 bit reading list suggestions deloptes <deloptes@gmail.com> - 2020-09-07 20:00 +0200
            Re: 32 versus 64 bit reading list suggestions Andrew Cater <amacater@gmail.com> - 2020-09-07 20:10 +0200
              Re: 32 versus 64 bit reading list suggestions deloptes <deloptes@gmail.com> - 2020-09-07 20:30 +0200
            Re: 32 versus 64 bit reading list suggestions Charles Curley <charlescurley@charlescurley.com> - 2020-09-07 21:30 +0200
              Re: 32 versus 64 bit reading list suggestions deloptes <deloptes@gmail.com> - 2020-09-07 22:00 +0200
                Re: 32 versus 64 bit reading list suggestions Andrew Cater <amacater@gmail.com> - 2020-09-07 22:10 +0200
                  Re: 32 versus 64 bit reading list suggestions deloptes <deloptes@gmail.com> - 2020-09-08 07:50 +0200
                    Re: 32 versus 64 bit reading list suggestions Michael Stone <mstone@debian.org> - 2020-09-08 14:30 +0200
                      Re: 32 versus 64 bit reading list suggestions deloptes <deloptes@gmail.com> - 2020-09-08 19:30 +0200
                        Re: 32 versus 64 bit reading list suggestions Michael Stone <mstone@debian.org> - 2020-09-08 21:30 +0200
                          Re: 32 versus 64 bit reading list suggestions deloptes <deloptes@gmail.com> - 2020-09-08 22:00 +0200
                  Re: 32 versus 64 bit reading list suggestions Charles Curley <charlescurley@charlescurley.com> - 2020-09-08 17:20 +0200
                    Re: 32 versus 64 bit reading list suggestions deloptes <deloptes@gmail.com> - 2020-09-08 19:40 +0200
                    Re: 32 versus 64 bit reading list suggestions Richard Hector <richard@walnut.gen.nz> - 2020-09-09 07:50 +0200
                      Re: 32 versus 64 bit reading list suggestions John Hasler <jhasler@newsguy.com> - 2020-09-09 14:20 +0200
                      Re: 32 versus 64 bit reading list suggestions deloptes <deloptes@gmail.com> - 2020-09-09 14:30 +0200
                        Re: 32 versus 64 bit reading list suggestions John Hasler <jhasler@newsguy.com> - 2020-09-09 14:50 +0200
                          Re: 32 versus 64 bit reading list suggestions deloptes <deloptes@gmail.com> - 2020-09-09 20:50 +0200
                Re: 32 versus 64 bit reading list suggestions Kenneth Parker <sea7kenp@gmail.com> - 2020-09-08 00:00 +0200
              Re: 32 versus 64 bit reading list suggestions Andrei POPESCU <andreimpopescu@gmail.com> - 2020-09-08 10:50 +0200
                Re: 32 versus 64 bit reading list suggestions deloptes <deloptes@gmail.com> - 2020-09-08 19:40 +0200
                  Re: 32 versus 64 bit reading list suggestions Andrei POPESCU <andreimpopescu@gmail.com> - 2020-09-09 07:40 +0200
                    Re: 32 versus 64 bit reading list suggestions John Hasler <jhasler@newsguy.com> - 2020-09-09 14:20 +0200
        Re: 32 versus 64 bit reading list suggestions Joe <joe@jretrading.com> - 2020-09-07 21:00 +0200
          Re: 32 versus 64 bit reading list suggestions Richard Owlett <rowlett@cloud85.net> - 2020-09-07 22:20 +0200
          Re: 32 versus 64 bit reading list suggestions Andy Smith <andy@strugglers.net> - 2020-09-07 23:40 +0200
            Re: 32 versus 64 bit reading list suggestions Andy Smith <andy@strugglers.net> - 2020-09-08 00:10 +0200
              Re: 32 versus 64 bit reading list suggestions deloptes <deloptes@gmail.com> - 2020-09-08 08:10 +0200
        Re: 32 versus 64 bit reading list suggestions David Wright <deblis@lionunicorn.co.uk> - 2020-09-07 21:00 +0200
          Printed page vs. computer screen (was: Re: 32 versus 64 bit reading list suggestions) rhkramer@gmail.com - 2020-09-08 01:20 +0200
    Re: 32 versus 64 bit reading list suggestions Georgi Naplatanov <gosho@oles.biz> - 2020-09-07 16:30 +0200
    Re: 32 versus 64 bit reading list suggestions Felix Miata <mrmazda@earthlink.net> - 2020-09-07 17:00 +0200
      Re: 32 versus 64 bit reading list suggestions Richard Owlett <rowlett@cloud85.net> - 2020-09-07 20:00 +0200
        Re: 32 versus 64 bit reading list suggestions David Wright <deblis@lionunicorn.co.uk> - 2020-09-07 21:10 +0200
          Re: 32 versus 64 bit reading list suggestions Felix Miata <mrmazda@earthlink.net> - 2020-09-07 21:30 +0200
            Re: 32 versus 64 bit reading list suggestions Richard Owlett <rowlett@cloud85.net> - 2020-09-07 23:00 +0200
          Re: 32 versus 64 bit reading list suggestions Richard Owlett <rowlett@cloud85.net> - 2020-09-07 22:30 +0200

Page 1 of 3  [1] 2 3  Next page →

#226741 — 32 versus 64 bit reading list suggestions

I switched from Windows when Squeeze was current and was working with a 
mix of 32 and 64 bit machines. To simplify my life I used and continue 
to use the i386 flavor of Debian.

I have two underlying questions:
   1. As everything I currently use runs fine, what would I gain by
      switching to amd64 flavor?
   2.What 32 bit utilities are there to identify the hardware capabilities
     of a particular machine?

I'm asking for recommended reading list to discover questions I should 
be aware of that I don't recognize I should be asking.

TIA

[toc] | [next] | [standalone]

#226742

	Hi.

On Mon, Sep 07, 2020 at 08:44:28AM -0500, Richard Owlett wrote:
> I have two underlying questions:
>   1. As everything I currently use runs fine, what would I gain by switching to amd64 flavor?

Short term - you'll gain nothing. Everything will work exactly the same, barring
third-party software (if any).

Long term - Debian is one of the last major distributions that keeps
i386 supported. Sooner or later Debian will follow the current trend of
dropping i386. It won't happen in bullseye though.

>   2.What 32 bit utilities are there to identify the hardware capabilities of a particular machine?

If you mean, "how do I check if my Intel/AMD CPU has that 64-bit
capability", then it's:

lscpu | grep -w lm

Otherwise your question is too broad.

Reco

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

#226745

On Mon 07 Sep 2020 at 17:17:12 (+0300), Reco wrote:
> On Mon, Sep 07, 2020 at 08:44:28AM -0500, Richard Owlett wrote:
> > I have two underlying questions:
> >   1. As everything I currently use runs fine, what would I gain by switching to amd64 flavor?
> 
> Short term - you'll gain nothing. Everything will work exactly the same, barring
> third-party software (if any).
> 
> Long term - Debian is one of the last major distributions that keeps
> i386 supported. Sooner or later Debian will follow the current trend of
> dropping i386. It won't happen in bullseye though.
> 
> >   2.What 32 bit utilities are there to identify the hardware capabilities of a particular machine?
> 
> If you mean, "how do I check if my Intel/AMD CPU has that 64-bit
> capability", then it's:
> 
> lscpu | grep -w lm
> 
> Otherwise your question is too broad.

The OP is notoriouly tight on bandwidth, so they might want to
stick with i386 until their final i386-only machine expires.
(Again, assuming they aren't swayed by third-party software.)

Cheers,
David.

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

#226747

On 09/07/2020 09:17 AM, Reco wrote:
> 	Hi.
> 
> On Mon, Sep 07, 2020 at 08:44:28AM -0500, Richard Owlett wrote:
>> I have two underlying questions:
>>    1. As everything I currently use runs fine, what would I gain by switching to amd64 flavor?
> 
> Short term - you'll gain nothing. Everything will work exactly the same, barring
> third-party software (if any).
> 
> Long term - Debian is one of the last major distributions that keeps
> i386 supported. Sooner or later Debian will follow the current trend of
> dropping i386. It won't happen in bullseye though.
> 
>>    2.What 32 bit utilities are there to identify the hardware capabilities of a particular machine?
> 
> If you mean, "how do I check if my Intel/AMD CPU has that 64-bit
> capability", then it's:
> 
> lscpu | grep -w lm

Will have to look up what each of the flags mean. That accomplish much 
of what I wanted to accomplish what a "reading list" would have.

> 
> Otherwise your question is too broad.

My question is intrinsically broad. That is why my subject line 
specified a "reading list", expecting that the reading would stimulate 
asking focused [i.e. answerable questions].

> 
> Reco
> 
> 
> 

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

#226748

	Hi.

On Mon, Sep 07, 2020 at 10:01:42AM -0500, Richard Owlett wrote:
> > >    2.What 32 bit utilities are there to identify the hardware capabilities of a particular machine?
> > 
> > If you mean, "how do I check if my Intel/AMD CPU has that 64-bit
> > capability", then it's:
> > 
> > lscpu | grep -w lm
> 
> Will have to look up what each of the flags mean. That accomplish much
> of what I wanted to accomplish what a "reading list" would have.

lm means "Long Mode", i.e. 64-bit support.
For the others, [1] is your best reference, table 2-27.

Reco

[1] https://software.intel.com/file/36945

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

#226753

On 09/07/2020 10:09 AM, Reco wrote:
> 	Hi.
> 
> On Mon, Sep 07, 2020 at 10:01:42AM -0500, Richard Owlett wrote:
>>>>     2.What 32 bit utilities are there to identify the hardware capabilities of a particular machine?
>>>
>>> If you mean, "how do I check if my Intel/AMD CPU has that 64-bit
>>> capability", then it's:
>>>
>>> lscpu | grep -w lm
>>
>> Will have to look up what each of the flags mean. That accomplish much
>> of what I wanted to accomplish what a "reading list" would have.
> 
> lm means "Long Mode", i.e. 64-bit support.
> For the others, [1] is your best reference, table 2-27.
> 
> Reco
> 
> [1] https://software.intel.com/file/36945
> 

I've downloaded it. Reading the per section overviews may the most 
relevant to why I titled thread as I did. Thanks.

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

#226743

On Mon, Sep 07, 2020 at 05:22:20PM +0300, Georgi Naplatanov wrote:
>You'll be able to use more RAM, CPU's registers. On the other hand some
>software vendors do not support x86 anymore - example: Google Chrome

Expanding on this a little bit: the 64 bit architecture has more CPU
registers which could greatly improve performance for some tasks. I
think that there are certain other CPU instructions that are not
available in 32 bit mode that your programs could take advantage of.

Not only can you use more RAM (you can address >4GiB with 64 bit memory
addresses without requiring workarounds like PAE), but you will almost
certainly *use* more RAM too, since all native pointers are now twice
the size. And, since most of them will be pointing at addresses lower
than the 4GiB boundary, half of all the newly consumed RAM will be
zeroes.

-- 
Please do not CC me, I am subscribed to the list.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

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

#226749

On 09/07/2020 09:28 AM, Jonathan Dowland wrote:
> On Mon, Sep 07, 2020 at 05:22:20PM +0300, Georgi Naplatanov wrote:
>> You'll be able to use more RAM, CPU's registers. On the other hand some
>> software vendors do not support x86 anymore - example: Google Chrome
> 
> Expanding on this a little bit: the 64 bit architecture has more CPU
> registers which could greatly improve performance for some tasks. I
> think that there are certain other CPU instructions that are not
> available in 32 bit mode that your programs could take advantage of.
> 
> Not only can you use more RAM (you can address >4GiB with 64 bit memory
> addresses without requiring workarounds like PAE), but you will almost
> certainly *use* more RAM too, since all native pointers are now twice
> the size. And, since most of them will be pointing at addresses lower
> than the 4GiB boundary, half of all the newly consumed RAM will be
> zeroes.
> 

Answers I'm seem focused on too low levels. I'm interested in the 
end-user experience.

E.G. what end user observable difference would there be between 32 bit 
based browser and a 64 bit based browser?

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

#226750

[Multipart message — attachments visible in raw view] — view raw

Hi Richard,

Potentially zero difference - until the 32 bit browser just isn't there any
more / isn't patched. This is the sort of question that the debian-cd team
are also pondering: as the years go on, it is harder and harder to justify
32 bit software at least for the x86 architecture. There are already
problems with some software that just won't build well in a 32 bit
environment.

On Mon, Sep 7, 2020 at 3:12 PM Richard Owlett <rowlett@cloud85.net> wrote:

> On 09/07/2020 09:28 AM, Jonathan Dowland wrote:
> > On Mon, Sep 07, 2020 at 05:22:20PM +0300, Georgi Naplatanov wrote:
> >> You'll be able to use more RAM, CPU's registers. On the other hand some
> >> software vendors do not support x86 anymore - example: Google Chrome
> >
> > Expanding on this a little bit: the 64 bit architecture has more CPU
> > registers which could greatly improve performance for some tasks. I
> > think that there are certain other CPU instructions that are not
> > available in 32 bit mode that your programs could take advantage of.
> >
> > Not only can you use more RAM (you can address >4GiB with 64 bit memory
> > addresses without requiring workarounds like PAE), but you will almost
> > certainly *use* more RAM too, since all native pointers are now twice
> > the size. And, since most of them will be pointing at addresses lower
> > than the 4GiB boundary, half of all the newly consumed RAM will be
> > zeroes.
> >
>
> Answers I'm seem focused on too low levels. I'm interested in the
> end-user experience.
>
> E.G. what end user observable difference would there be between 32 bit
> based browser and a 64 bit based browser?
>
>
>
>

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

#226755

Andrew Cater wrote:

> Potentially zero difference - until the 32 bit browser just isn't there
> any more / isn't patched. This is the sort of question that the debian-cd
> team are also pondering: as the years go on, it is harder and harder to
> justify 32 bit software at least for the x86 architecture. There are
> already problems with some software that just won't build well in a 32 bit
> environment.

this would be unfortunate because I am sure there is enough 32bit hardware
out there still working quite well - like mine Geode based firewall - it is
running since 2008.
I am sure even if debian drops the support of 32bit something else will take
it over.

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

#226757

[Multipart message — attachments visible in raw view] — view raw

In reality - there's very little hardware newer than ten years old that's
economic to run - x86_6r4 has been around for long enough that 64 bit
hardware is cheap. The overhead of compiling _pure_ 32 bit is significant
to keep going. It's not for nothing that Debian's 32 bit target has
gradually moved from 386 to 586 to 686 - an early Geode is probably at the
very end of its support lifestyle. pretty much everything else other than
Debian has dropped full 32 bit support. It will be there for Bullseye but
that will almost certainly be the last.

Ubuntu has already dropped 32 bit support once, reintroduced very limited
support and it will probably go again. Maybe not before time - the laptop
I'm typing this on is eight years old or so, the sort of thing you'd pull
from a junk pile, has been rescued by adding a cheap SSD and ran 32 bit
Windows originally. It's equivalent can probaby be picked up off the back
shelf in any computer recycling shop.

On Mon, Sep 7, 2020 at 5:50 PM deloptes <deloptes@gmail.com> wrote:

> Andrew Cater wrote:
>
> > Potentially zero difference - until the 32 bit browser just isn't there
> > any more / isn't patched. This is the sort of question that the debian-cd
> > team are also pondering: as the years go on, it is harder and harder to
> > justify 32 bit software at least for the x86 architecture. There are
> > already problems with some software that just won't build well in a 32
> bit
> > environment.
>
> this would be unfortunate because I am sure there is enough 32bit hardware
> out there still working quite well - like mine Geode based firewall - it is
> running since 2008.
> I am sure even if debian drops the support of 32bit something else will
> take
> it over.
>
>

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

#226758

Andrew Cater wrote:

> In reality - there's very little hardware newer than ten years old that's
> economic to run - x86_6r4 has been around for long enough that 64 bit
> hardware is cheap. The overhead of compiling _pure_ 32 bit is significant
> to keep going. It's not for nothing that Debian's 32 bit target has
> gradually moved from 386 to 586 to 686 - an early Geode is probably at the
> very end of its support lifestyle. pretty much everything else other than
> Debian has dropped full 32 bit support. It will be there for Bullseye but
> that will almost certainly be the last.
> 
> Ubuntu has already dropped 32 bit support once, reintroduced very limited
> support and it will probably go again. Maybe not before time - the laptop
> I'm typing this on is eight years old or so, the sort of thing you'd pull
> from a junk pile, has been rescued by adding a cheap SSD and ran 32 bit
> Windows originally. It's equivalent can probaby be picked up off the back
> shelf in any computer recycling shop.

Not good news from you - the hardware is good it consumes ~10Watt and works
perfectly. It might be I setup a local repository. The packages I use are
not hard to compile.
I understand the explanation, but this is industry grade hardware - I doubt
that it will break in the next 10y. As for productivity I do not see what
more I could want to have.
I looked recently for replacement, but newer hardware costs too much and
consumes slightly more power. OF course it's productivity might be much
higher, but it would be an overhead in the case here.

Thank you for the information anyway. It is very appreciated.

regards

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

#226762

On Mon, 07 Sep 2020 19:50:16 +0200
deloptes <deloptes@gmail.com> wrote:

> > There are
> > already problems with some software that just won't build well in a
> > 32 bit environment.  
> 
> this would be unfortunate because I am sure there is enough 32bit
> hardware out there still working quite well - like mine Geode based
> firewall - it is running since 2008.

Hear, hear. I have a small herd of Fit-PC Is, which have been doing
yeoman duty as firewalls, servers, etc. I don't recall when I bought
them, but the release date on the BIOS is 2007.

They draw less than four watts each, except 5 watts when the hard drive
is spinning up. <rhetorical>Has anyone got a 64 bit architecture machine
that frugal?</rhetorical>


>
> I am sure even if debian drops the support of 32bit something else
> will take it over.

I hope so. All I need is console capabilities, security software
(firewall, etc.) and server software. I don't need an office suite or web browser for those machines.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#226764

Charles Curley wrote:

> I hope so. All I need is console capabilities, security software
> (firewall, etc.) and server software. I don't need an office suite or web
> browser for those machines.

Same here. So it means we have 2-4years to get ready. 
I guess one needs a bit more in order to compile the code ... you need at
least the compiler and companions. I now compile only the kernel in chroot
as it was pointed out because debian moved away from pure 586 and also
there is a kind of magic combination of features for the Geode board I use,
so that the stock kernel never worked past 2.13.

So the question is (as we are already on the topic) when debian drops the
support, what would be required to build the code.
Are compilers going to stop supporting 386 arch?
Is it going to disappear from the kernel completely?
Is it going to get fixes and how?

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

#226765

[Multipart message — attachments visible in raw view] — view raw

32 bit Intel/AMD will likely disappear from the kernel if it becomes too
hard to support. I've just had a quick look at the Fit-PC site - all of
them look to be 64 bit capable. You want something low power - 64 bit ARM?
There does come a point when 32 bit x86 really isn't viable - that's round
about now in my humble estimation, if it wasn't actually two years ago.
Crucially, the boost library is hard to build - Firefox is built on 64 bit
to work on 32 bit - and those are the obvious ones. If you want the
distributions to spend time building on 64 bit for you to run on 32 bit
hardware which is significantly old you do need to show a demonstrable need
and perhaps find sponsors for a toolchain and permanent build at this point.

On Mon, Sep 7, 2020 at 7:52 PM deloptes <deloptes@gmail.com> wrote:

> Charles Curley wrote:
>
> > I hope so. All I need is console capabilities, security software
> > (firewall, etc.) and server software. I don't need an office suite or web
> > browser for those machines.
>
> Same here. So it means we have 2-4years to get ready.
> I guess one needs a bit more in order to compile the code ... you need at
> least the compiler and companions. I now compile only the kernel in chroot
> as it was pointed out because debian moved away from pure 586 and also
> there is a kind of magic combination of features for the Geode board I use,
> so that the stock kernel never worked past 2.13.
>
> So the question is (as we are already on the topic) when debian drops the
> support, what would be required to build the code.
> Are compilers going to stop supporting 386 arch?
> Is it going to disappear from the kernel completely?
> Is it going to get fixes and how?
>
>
>
>
>
>

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

#226780

Andrew Cater wrote:

> 32 bit Intel/AMD will likely disappear from the kernel if it becomes too
> hard to support. I've just had a quick look at the Fit-PC site - all of
> them look to be 64 bit capable. You want something low power - 64 bit ARM?
> There does come a point when 32 bit x86 really isn't viable - that's round
> about now in my humble estimation, if it wasn't actually two years ago.
> Crucially, the boost library is hard to build - Firefox is built on 64 bit
> to work on 32 bit - and those are the obvious ones. If you want the
> distributions to spend time building on 64 bit for you to run on 32 bit
> hardware which is significantly old you do need to show a demonstrable
> need and perhaps find sponsors for a toolchain and permanent build at this
> point.

I alaready looked for a replacement. Surprisingly the devices with 3 or 4
network cards cost > 400,- US$ and consume more power. I do not see a
reason why I should throw away a device that is working and will be
working. There was nothing ARM based, I could find.
I checked yesterday - as Charles Curley said the demand is near to the base
system - no fancy browser or whatever 372 packages 279 of which are i386.
So indeed the question is about the toolchain. I have no experience in
finding sponsors or whatever. For me it will be sufficient if I could build
those packages locally. I'll put it on the list for the next year. 
Help and advise how to proceed is appreciated.

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

#226786

On Tue, Sep 08, 2020 at 07:48:33AM +0200, deloptes wrote:
>I alaready looked for a replacement. Surprisingly the devices with 3 or 4
>network cards cost > 400,- US$ and consume more power.

pcengines APU2 (3 nic) or APU4 (4 nic) will come in well under that, has 
2 or 4GB RAM, quad core 1GHz CPU, and draws 6-12W.

It will also have lower network latency, much higher bandwidth limit, 
and allow you to run more advanced services on the firewall.

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

#226801

Michael Stone wrote:

> pcengines APU2 (3 nic) or APU4 (4 nic) will come in well under that, has
> 2 or 4GB RAM, quad core 1GHz CPU, and draws 6-12W.
> 
> It will also have lower network latency, much higher bandwidth limit,
> and allow you to run more advanced services on the firewall.

Yes I looked at it - fully configured €250,- without shipment and there was
some reason that I dropped the idea and looked at alternatives.
Still there is the question why buy new when old is working.

regards

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

#226806

On Tue, Sep 08, 2020 at 07:26:33PM +0200, deloptes wrote:
>Yes I looked at it - fully configured €250,- without shipment and there was
>some reason that I dropped the idea and looked at alternatives.

Well, they cost a heck of a lot less to send to the US. :D

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

#226807

Michael Stone wrote:

> Well, they cost a heck of a lot less to send to the US. :D

I also think positive :) I have now one that is working fine. I'll look
forward to keep it running until it dies or I have a real reason to
upgrade :)

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

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web