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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#226792

On Mon, 7 Sep 2020 20:07:52 +0000
Andrew Cater <amacater@gmail.com> wrote:

> I've just had a quick look at the Fit-PC site - all of
> them look to be 64 bit capable.

The Fit-PC I is no longer on the Fit-PC web site. Wikipedia, however...
https://en.wikipedia.org/wiki/Fit-PC#fit-PC_1.0 The processor is:

root@freeman:~# uname -a
Linux freeman 4.19.0-6-686 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) i586 GNU/Linux
root@freeman:~#

Key to my requirements is two Ethernet ports. You can't do a very good
firewall with less than that. 100 Mbs is a reasonable minimum.

> You want something low power - 64 bit ARM?

I guess when the time comes I'll do some serious shopping.


> 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

I don't need Firefox for these. Three of the four machines I just
checked don't have libboost on them, and the fourth may not actually
need it.

For the actual firewall, I suppose I could repurpose my GL-AR750S-Ext.
https://www.gl-inet.com/products/gl-ar750s/ It currently serves as a
WiFi access point only. That's the only place where I really require
two Ethernet ports.

-- 
Does anybody read signatures any more?

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

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

#226802

Charles Curley wrote:

> I don't need Firefox for these. Three of the four machines I just
> checked don't have libboost on them, and the fourth may not actually
> need it.

but still the question is if you don't need it for building things that you
need - especially thy python that is required to get the borg backup
working here. Even in this case rsync can replace the borg - so I also
believe it is possible to keep the machines alive at latest stable ... but
there will be effort :/

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

#226819

On 9/09/20 3:12 am, Charles Curley wrote:
> Key to my requirements is two Ethernet ports. You can't do a very good
> firewall with less than that. 100 Mbs is a reasonable minimum.

Actually, you can do ok if you combine it with a VLAN-capable switch. I
believe that's how most of the consumer-grade routers work (with the
switch built-in, of course). Trunk the VLANs from the computer to the
switch.

Mind you, I'd want to go gigabit for that.

Richard

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

#226821

Richard writes:
> Actually, you can do ok if you combine it with a VLAN-capable
> switch. I believe that's how most of the consumer-grade routers work
> (with the switch built-in, of course).

Another reason not to use consumer-grade routers.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

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

#226823

Richard Hector wrote:

>  Trunk the VLANs from the computer to the
> switch.
> 

What does the original topic has to do with trunked VLAN?

It is about a firewall with two interfaces - one connected to the outside
and one to the inside network.

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

#226824

Richard Hector wrote:
>  Trunk the VLANs from the computer to the switch.

deloptes writes:
> What does the original topic has to do with trunked VLAN?

You can use it to fake a real router by faking a second NIC.  It makes
your firewall vulnerable to VLAN hopping attacks.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

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

#226838

John Hasler wrote:

> You can use it to fake a real router by faking a second NIC.  It makes
> your firewall vulnerable to VLAN hopping attacks.

Appreciated, but no - thank you! I like simple things even if they are
complicated. In this case one network port for the outside, one for the
inside and the firewall between. It is simple and clean ... well I have a
third interface which goes to a DMZ - but it is also behind the firewall.

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

#226771

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

On Mon, Sep 7, 2020, 3: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?
>

I already have one machine that runs awesomely with Ubuntu 6.06 (vintage
2006!)

I have had mixed experiences with later releases, including a persistent
Black Screen with Debian Wheezy.  Stretch "kind of works" (with slow
Graphics).  So why do I keep it?  Best Sound System of  *any*  computer I
have  *ever*  owned! So it has two, basic Partitions:  One for Stretch and
one for Ubuntu 6.  (And yes, I don't regularly put Ubuntu 6 on the open
Internet).

Kenneth Parker

>

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

#226782

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

On Lu, 07 sep 20, 12:41:07, Charles Curley wrote:
> 
> 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>

PINE A64 (not sure if that's a + or not)
http://wiki.pine64.org/images/1/1d/Power_Consumption.jpg


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#226803

Andrei POPESCU wrote:

> PINE A64 (not sure if that's a + or not)
> http://wiki.pine64.org/images/1/1d/Power_Consumption.jpg
> 

you missed that we need at least 2 network adapters

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

#226818

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

On Ma, 08 sep 20, 19:32:54, deloptes wrote:
> Andrei POPESCU wrote:
> 
> > PINE A64 (not sure if that's a + or not)
> > http://wiki.pine64.org/images/1/1d/Power_Consumption.jpg
> > 
> 
> you missed that we need at least 2 network adapters

The question was about a 64bit capable machine running on max 4 Watts, 
the two network interfaces were mentioned only later.

Anyway, there are boards like the ESPRESSObin[1]. I can't find 
information on power consumption on a quick search though I expect it to 
be quite similar since it's a dual A53 where the A64 is a quad A53.

[1] http://espressobin.net/tech-spec/
 
Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#226822

Andrei writes:
> Anyway, there are boards like the ESPRESSObin[1].

I've got one of those that I intended for a router.  Can't keep it
running.  Seems to be a power supply problem.  I tried two different
boards.  When I tried to troubleshoot it I found that the available
schematics are wrong and that the support is useless.  This was last
year: perhaps they've improved.

I'm sure it uses more than 4 watts.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

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

#226759

On Mon, 7 Sep 2020 10:12:11 -0500
Richard Owlett <rowlett@cloud85.net> wrote:

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

One practical point: it isn't possible to upgrade from a 32-bit
installation to a 64-bit one, it's a reinstall job. I did actually have
a go once, but quickly got bogged down with 'do A before B, and do B
before A'.

-- 
Joe

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

#226766

On 09/07/2020 01:57 PM, Joe wrote:
> On Mon, 7 Sep 2020 10:12:11 -0500
> Richard Owlett <rowlett@cloud85.net> wrote:
> 
>>
>>
>> Answers I'm seem focused on too low levels. I'm interested in the
>> end-user experience.
>>
> 
> One practical point: it isn't possible to upgrade from a 32-bit
> installation to a 64-bit one, it's a reinstall job. I did actually have
> a go once, but quickly got bogged down with 'do A before B, and do B
> before A'.
> 

For miscellaneous personal reasons I always do a full install when 
moving to a new version. Essentially it means I have a known fully 
functional install on its own partition to fall back on. /home is on a 
separate partition available to any release.

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

#226770

Hello,

On Mon, Sep 07, 2020 at 07:57:18PM +0100, Joe wrote:
> One practical point: it isn't possible to upgrade from a 32-bit
> installation to a 64-bit one, it's a reinstall job. I did actually have
> a go once, but quickly got bogged down with 'do A before B, and do B
> before A'.

I've done it successfully more than 10 times, but:

- It isn't officially supported

- I did it on virtual machines which by their nature had fewer
  packages installed and are much simpler than the typical desktop
  or "server that does everything" in a small office.

It is not for the faint of heart and on any moderately complex
install it is faster and certainly easier to just reinstall.

Basic process:

    https://wiki.debian.org/CrossGrading

Do not do this if you aren't willing to possibly render your system
unbootable requiring a lengthy repair session before you get
frustrated and just reinstall anyway.

So far in this thread people have pointed out that upstream software
vendors are increasingly moving away from 32-bit x86 for various
reasons. What hasn't been mentioned yet is that one of the upstream
projects where 32-bit support is sub-optimal and getting worse is
the Linux kernel itself.

Basically there are already fewer upstream kernel developers that
care about and understand 32-bit x86, and bug and even security
fixes specific to 32-bit x86 lag behind those for amd64. KPTI fixes
to address Meltdown and Spectre took an extra 6 months to reach
32-bit x86.

    https://lwn.net/Articles/743265/
    https://www.phoronix.com/scan.php?page=news_item&px=Linux-32-Bit-KPTI-Bug-Fix

If your hardware supports it then you are best off planning to move
to it sooner rather than later. X86_32 is already in the critical
care ward.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

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

#226772

On Mon, Sep 07, 2020 at 09:37:47PM +0000, Andy Smith wrote:
> Basically there are already fewer upstream kernel developers that
> care about and understand 32-bit x86, and bug and even security
> fixes specific to 32-bit x86 lag behind those for amd64. KPTI fixes
> to address Meltdown and Spectre took an extra 6 months to reach
> 32-bit x86.
> 
>     https://lwn.net/Articles/743265/
>     https://www.phoronix.com/scan.php?page=news_item&px=Linux-32-Bit-KPTI-Bug-Fix

Oh, and:

    https://lwn.net/ml/oss-security/CALCETrW1z0gCLFJz-1Jwj_wcT3+axXkP_wOCxY8JkbSLzV80GA@mail.gmail.com/

    "To those of you who actually support x86_32: please either
    consider stopping supporting it or finding and paying someone to
    give it serious upstream attention.  We need real CI resources
    and we need developers to test things for real, fix what's
    broken, and generally keep it up to date. And the developers in
    question should have an appropriate degree of nostalgic
    adoration of segments, gates, and other delights from the i386
    era."

Kind of suggests to me that changes specific to x86_32 aren't being
made, and when they are being made they aren't being tested except
by users in the wild. If you never upgrade your kernel and it's in a
more secure environment (e.g. device with only one user, not exposed
to public Internet, etc.) then it's obviously less of a worry, but…

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

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

#226781

Andy Smith wrote:

> Kind of suggests to me that changes specific to x86_32 aren't being
> made, and when they are being made they aren't being tested except
> by users in the wild. If you never upgrade your kernel and it's in a
> more secure environment (e.g. device with only one user, not exposed
> to public Internet, etc.) then it's obviously less of a worry, but…

People often say things without thinking too much about consequences.
I upgrade the kernel regularly after building it in an upto date chroot.
I bet there are many people still using i386 or similar x86_32 that will be
upset. 
It is simply a sad story going on. I did not mind throwing away older PC
because of inefficiency compared to new, but in the case the machines are
very efficient. - it will be a pity. 

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

#226760

On Mon 07 Sep 2020 at 09:33:15 (-0600), D. R. Evans wrote:
> Richard Owlett wrote on 9/7/20 9:12 AM:
> > 
> > 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?

As your bandwidth considerations seem to have taken a back seat (with
at least stretch, plus buster in two architectures), you'll be able
to form your own judgment in buster. You've brought up browsers,
and that's one area where the speed will show, because they're
highly interactive. Hopefully, you're not short on installed memory.

> The short version:
>   what Reco said.
> 
> The longer version:
> 
> 64-bit will be faster... not because 64-bit is intrinsically faster (although,
> depending on the optimisation settings in the compilation, it almost certainly
> will be faster, as has been pointed out, because of the additional CPU
> instructions available on 64-bit machines), but basically because the 64-bit
> CPU is likely to be newer and run at a higher clock rate, and hence faster for
> that reason alone.
> 
> I recently retired a debian stable 32-bit machine in favour of a debian stable
> 64-bit machine. All ordinary pre-built officially supported programs simply
> worked exactly the same (but /far/ faster: for example, a 10-minute code
> compile became less than 20 seconds).

That may be an unfair comparison as the OP has a 64-bit machine
running the 32-bit software, rather than two machines of different
generations.

> [I did have trouble with low-level sound in my own code, but that was entirely
> related to the fact that the sound hardware on the new machine supported only
> CD-quality sound, and it took quite a bit of digging, learning and a lot of
> print statements finally to get it to do what happened naturally on the old
> 32-bit machine when I needed low-quality sampling.]
> 
> The biggest reason to switch, if everything runs sufficiently quickly on the
> 32-bit machine, is probably that at some point 32 bits will stop being
> supported (I vaguely seem to remember that the decision to do that has already
> been taken by the debian project once, but was revoked).

If there's a bullseye LTS, then that deadline might be several years
away yet.

Cheers,
David.

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

#226773 — Printed page vs. computer screen (was: Re: 32 versus 64 bit reading list suggestions)

On Monday, September 07, 2020 03:46:39 PM D. R. Evans wrote:
> Sorry; I missed that. (I find it too easy to skim instead of actually
> /read/ on a computer screen.)

That's interesting, I'll say it this way first, then elaborate a little.

I tend to skim more on the printed page than on the computer screen.  (But, 
even then, I tend to skim somewhat, especially in long texts.

The elaboration : I also tend to read too fast, not catching the exact nuance 
of some of the words used on the computer screen (and on printed pages).

The computer screen has the advantage for me of being able to adjust (usually 
increase) the font size.

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

#226744

On 9/7/20 4:44 PM, Richard Owlett wrote:
> 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?

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


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

lscpu
lspci
lsusb
lshw

HTH

Kind regards
Georgi

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

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

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

csiph-web