On Thu, Sep 2, 2021, 7:34 PM David Wright wrote
>
> (I use my own customisations for distinct colours on each host,
> and inverse colours for root's prompt.)
>
Good idea :-)
For some reason putting "root:" there doesn't save me 100% of the time :-)
Cheers,
> David.
>
>
On Fri 03 Sep 2021 at 03:15:13 (+0300), IL Ka wrote:
> .bashrc on bullseye contains following lines
>
> ```
> # set a fancy prompt (non-color, unless we know we "want" color)
> case "$TERM" in
> xterm-color|*-256color) color_prompt=yes;;
> esac
> ```
>
> So we only have colors in the
On 03.08.21 18:26, IL Ka wrote:
inxi shows that only 3 GB are available as the TOTAL, although it finds
the 4 GB to be physically installed:
$ sudo inxi -m -x
Memory: RAM: total: 2.88 GiB used: 2.11 GiB (73.2%)
Array-1: capacity: 4 GiB slots: 2 EC: None max module size: 2
Yup. That too.
On Tue, Aug 3, 2021 at 7:42 PM IL Ka wrote:
>
>> That cpu was normally paired with the Intel 945 chipset that can’t
>> support more than about 3.25GB whether or not it’s 32/64 OS
>>
>
> Yes, and even worse: this CPU doesn't support 64bit OS
>
>> model name : Intel(R) Atom(TM)
>
>
> That cpu was normally paired with the Intel 945 chipset that can’t support
> more than about 3.25GB whether or not it’s 32/64 OS
>
Yes, and even worse: this CPU doesn't support 64bit OS
> model name: Intel(R) Atom(TM) CPU N280 @ 1.66GHz
>> address sizes: 32 bits physical, 32
That cpu was normally paired with the Intel 945 chipset that can’t support
more than about 3.25GB whether or not it’s 32/64 OS
On Tue, Aug 3, 2021 at 7:24 PM wrote:
> Thank Andy! my cpu is 32bit
> i have thought pae can support more than 4G memory
> but in fact it can't use full 4G memory
Thank Andy! my cpu is 32bit
i have thought pae can support more than 4G memorybut in fact it can't use full
4G memory hardware
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU N280 @ 1.66GHz
>
> inxi shows that only 3 GB are available as the TOTAL, although it finds
> the 4 GB to be physically installed:
> $ sudo inxi -m -x
> Memory:RAM: total: 2.88 GiB used: 2.11 GiB (73.2%)
> Array-1: capacity: 4 GiB slots: 2 EC: None max module size: 2 GiB note:
> est.
> Device-1: M1 size: 2
On 03.08.21 00:42, IL Ka wrote:
i have 2 memory slots
memtest86+ shows each has 2G, but total is 3G
after booting linux, top shows total is 3G
why 1 G is missing? Thanks!
You probably have 32bit OS
https://en.wikipedia.org/wiki/3_GB_barrier
Hello,
On Tue, Aug 03, 2021 at 07:14:32AM +0800, loushanguan2...@sina.com wrote:
> Linux debian 4.9.0-13-686-pae #1 SMP Debian 4.9.228-1 (2020-07-05) i686
> GNU/Linux
So you are running 32-bit kernel. Will the hardware do 64-bit? What
does
$ cat /proc/cpuinfo
say?
You may be able to install
It’s bios/chipset dependent. Example: the Intel 945 will not allow more
than 3.25GB or so regardless if PAE is used. However, the Intel 965 chipset
will provide the full 4GB if used with PAE enabled and the BIOS allows it
by default or has a ‘remap’ option.
On Mon, Aug 2, 2021 at 7:15 PM wrote:
Jeremy Hendricks:Are you booting an x86 or x86_64 install? Run: “uname -a”
without quotes and post the results to us.
Linux debian 4.9.0-13-686-pae #1 SMP Debian 4.9.228-1 (2020-07-05) i686
GNU/Linux
Thanks, i thought pae can bypass 4G limit of 32-bit OS
> i have 2 memory slots
> memtest86+ shows each has 2G, but total is 3G
> after booting linux, top shows total is 3G
>
why 1 G is missing? Thanks!
>
You probably have 32bit OS
https://en.wikipedia.org/wiki/3_GB_barrier
Are you booting an x86 or x86_64 install? Run: “uname -a” without quotes
and post the results to us.
On Mon, Aug 2, 2021 at 6:12 PM wrote:
> i have 2 memory slots
> memtest86+ shows each has 2G, but total is 3G
> after booting linux, top shows total is 3G
> why 1 G is missing? Thanks!
>
David, you are right again, i'm going nowhere(making no progress)
actually i've said on
Mon, 05 Jul 2021 05:04:54 +0800that slowness has nothing to do with downloadi
open it as local file
i believe pdf format used by archive.org is cause of slownessthey are scanned
books, and allow you to select
On Wed 14 Jul 2021 at 18:43:15 (+0800), loushanguan2...@sina.com wrote:
> [Zathura] has Continuous modebut it's slow,
I think it's slower to start than xpdf, but it doesn't grind to a halt
100 pages later.
> and it lacks gui, making it difficult to use
I can see the use for a mouse to cut and
Having just heard of the Lightroom product and scratched the surface of Mr
Weaver's objections to it (he called it Lightbeam): whether my pix goto the
intelligence community or not, I wouldn't want them traveling across the
nets to be digitally processed or stored. But quoting Jello Biafra, the
David, you are right, it has Continuous modebut it's slow, and it lacks gui,
making it difficult to usei don't think gui components requires fast cpu
On Tue 13 Jul 2021 at 20:13:30 (+0800), loushanguan2...@sina.com wrote:
> riveravaldez wrote:
> Another excellent option (specially for old machines) is zathura,available in
> the official repositories, IIRC.
> i've just installed zathura, it doesn't have Continuous mode as opposed to
> Single
riveravaldez wrote:
Another excellent option (specially for old machines) is zathura,available in
the official repositories, IIRC.
Best regards!
i've just installed zathura, it doesn't have Continuous mode as opposed to
Single Page modeand it lacks gui components, you have to read manual to
On 7/4/21, loushanguan2...@sina.com wrote:
> Thanks! i've installed atril, evince and okular for buster for i386 at your
> recommendationevince for buster seems better than for stretch
> i use xosview to monitor performance4G memory is always enough, but cpu
> usage is high, meaning slow
Another
Hi,
On 2021-07-05 2:34 a.m., to...@tuxteam.de wrote:
> On Mon, Jul 05, 2021 at 06:21:40AM +, Andrew M.A. Cater wrote:
>>
>> Just a polite reminder: however annoyed you feel, insulting each other
>> on list really doesn't help get technical or other points across.
>
I totally agree with you
On Mon, Jul 05, 2021 at 06:21:40AM +, Andrew M.A. Cater wrote:
>
> Just a polite reminder: however annoyed you feel, insulting each other
> on list really doesn't help get technical or other points across.
Thanks, Andrew.
Folks: if you enjoy slinging mud at each other, fine. But please, do
Just a polite reminder: however annoyed you feel, insulting each other
on list really doesn't help get technical or other points across.
Anybody can phrase things badly: anybody can get things wrong at times:
everybody can be wrong at times or just be badly informed.
If all else fails: when
On 04/07/2021 23:43, Siard wrote:
On Sun, 04 Jul 2021 17:03 +0800, loushanguan2...@sina.com wrote:
i've found many books at archive.org in pdf formatbut reading them in
acrobat for linux is painful, it's slow
it's fast in acrobat for androidand i think it's fast in Windows
adobe has stopped
Thanks! i've installed atril, evince and okular for buster for i386 at your
recommendationevince for buster seems better than for stretch
i use xosview to monitor performance4G memory is always enough, but cpu usage
is high, meaning slow
Original Message
Subject: Re: why pdf file at archive.org is so slow to open
Date: 05-07-2021 09:48
From: Weaver
To: Polyna-Maude Racicot-Summerside
On 05-07-2021 08:59, Polyna-Maude Racicot-Summerside wrote:
> Hi,
>
>> Install Okular, with supporting pack
On 05-07-2021 08:59, Polyna-Maude Racicot-Summerside wrote:
> Hi,
>
>> Install Okular, with supporting packages.
> Good advice.
>> Why use Adobe products.
> Good question !
>> If you install Lightbeam, you will find they connect directly with the
>> CIA.
> You just lost all type of credibility
Hi,
> Install Okular, with supporting packages.
Good advice.
> Why use Adobe products.
Good question !
> If you install Lightbeam, you will find they connect directly with the
> CIA.
You just lost all type of credibility right now.
Don't take your dream for reality. If this would be true then
On 05-07-2021 07:04, loushanguan2...@sina.com wrote:
> Thanks!
> it has nothing to do with download
> i have saved it to home directory
> and then open it with acrobat for linux
> it's slow when i browse it
>
> what cpu do you use?
> my cpu is old and cheap
Install Okular, with supporting
Hi,
On 2021-07-04 5:04 p.m., loushanguan2...@sina.com wrote:
>
>
> Thanks!
> it has nothing to do with download
> i have saved it to home directory
> and then open it with acrobat for linux
> it's slow when i browse it
>
Why don't you try using one of the software included in Debian ?
xpdf
On 7/4/21, loushanguan2...@sina.com wrote:
>
> Thanks!it has nothing to do with downloadi have saved it to home
> directoryand then open it with acrobat for linuxit's slow when i browse it
> what cpu do you use?my cpu is old and cheap
Hi.. I saw some of the other of this thread where you named
On Sun 04 Jul 2021 at 17:03:26 (+0800), loushanguan2...@sina.com wrote:
> i've found many books at archive.org in pdf formatbut reading them in acrobat
> for linux is painful, it's slow
> it's fast in acrobat for androidand i think it's fast in Windowsadobe has
> stopped upgrade for linux
> i've
On Sun, 04 Jul 2021 17:03 +0800, loushanguan2...@sina.com wrote:
> i've found many books at archive.org in pdf formatbut reading them in
> acrobat for linux is painful, it's slow
> it's fast in acrobat for androidand i think it's fast in Windows
> adobe has stopped upgrade for linux
> i've tried
On Sun, Jul 04, 2021 at 05:03:26PM +0800, loushanguan2...@sina.com wrote:
i've found many books at archive.org in pdf format
but reading them in acrobat for linux is painful, it's slow
it's fast in acrobat for android
and i think it's fast in Windows
adobe has stopped upgrade for linux
i've
Hi,
On 2021-07-01 5:52 p.m., Mark Copper wrote:
> mono-vbnc is a package in stretch and sid but not buster. Why is that?
>
You can get a version that is compatible with Debian by using this repo.
https://www.mono-project.com/download/stable/
sudo apt install apt-transport-https dirmngr gnupg
Thank you.
On Thu, Jul 1, 2021 at 3:55 PM Greg Wooledge wrote:
>
> On Thu, Jul 01, 2021 at 03:52:42PM -0600, Mark Copper wrote:
> > mono-vbnc is a package in stretch and sid but not buster. Why is that?
>
> https://tracker.debian.org/pkg/mono-basic
>
> According to this, it was removed from
On Thu, Jul 01, 2021 at 03:52:42PM -0600, Mark Copper wrote:
> mono-vbnc is a package in stretch and sid but not buster. Why is that?
https://tracker.debian.org/pkg/mono-basic
According to this, it was removed from testing in 2019. You can click
the links to see why.
On Sat, 8 May 2021 Long Wind wrote:
when i open attached torrent with btdownloadcurses,
Which debian package is this "btdownloadcurses" command from? As far
as I know, it could be from either bittorrent or bittornado.
it says:
got bad file info - path ~最新最快影片每日更新.url disallowed for security
Hello,
please do not attach a (possibly corrupted) file to your post
the error you get is reported (rightly or wrongly) as bittornado
specific and the software you use seems based on bittornado
http://support.proaudiotorrents.org/knowledgebase.php?article=7
On 16/03/2021 12:20, songbird wrote:
Nicholas Geovanis wrote:
On Sun, Mar 14, 2021, 1:50 PM Stefan Monnier
wrote:
...
FWIW And MIPS was there even a bit earlier with their R4000 (tho the
software support for it only appeared some years later: they first
wanted to have an installed base to
Nicholas Geovanis wrote:
> On Sun, Mar 14, 2021, 1:50 PM Stefan Monnier
> wrote:
...
>> FWIW And MIPS was there even a bit earlier with their R4000 (tho the
>> software support for it only appeared some years later: they first
>> wanted to have an installed base to which to deploy the software),
On Tue, Mar 16, 2021 at 12:08:51AM +0200, Andrei POPESCU wrote:
> On Lu, 15 mar 21, 11:19:55, Stefan Monnier wrote:
> >
> > Last I heard Debian works on the M1 already :-), but its Emacs package
> > doesn't :-(
>
> No surprise considering Emacs is itself a full OS :p
>
> (sorry, could not
Christian Groessler wrote:
> On 3/15/21 10:47 PM, Andrei POPESCU wrote:
>> On Lu, 15 mar 21, 20:24:56, Sven Hartge wrote:
>>> (I still vividly remember using memmaker and manual ordering the drivers
>>> in config.sys and autoexec.bat to shave another 2KB from the lower
>>> memory so the IPX
Andrei POPESCU wrote:
> On Lu, 15 mar 21, 17:21:39, Dan Ritter wrote:
> >
> > At last report: normal desktop Ryzens (nothing with a G suffix
> > unless it also has a PRO marking)
>
> Do you have a reliable source for the lack of ECC support in G suffix
> processors?
>
> And why would it work
On Tue, Mar 16, 2021 at 12:08:51AM +0200, Andrei POPESCU wrote:
> On Lu, 15 mar 21, 11:19:55, Stefan Monnier wrote:
> >
> > Last I heard Debian works on the M1 already :-), but its Emacs package
> > doesn't :-(
>
> No surprise considering Emacs is itself a full OS :p
>
Yeah, but it could really
On 3/15/21 10:47 PM, Andrei POPESCU wrote:
On Lu, 15 mar 21, 20:24:56, Sven Hartge wrote:
(I still vividly remember using memmaker and manual ordering the drivers
in config.sys and autoexec.bat to shave another 2KB from the lower
memory so the IPX driver would fit so Doom would run.)
For me it
On Lu, 15 mar 21, 11:19:55, Stefan Monnier wrote:
>
> Last I heard Debian works on the M1 already :-), but its Emacs package
> doesn't :-(
No surprise considering Emacs is itself a full OS :p
(sorry, could not resist)
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
On Lu, 15 mar 21, 17:21:39, Dan Ritter wrote:
>
> At last report: normal desktop Ryzens (nothing with a G suffix
> unless it also has a PRO marking)
Do you have a reliable source for the lack of ECC support in G suffix
processors?
And why would it work for PRO processors instead?
I think
On Lu, 15 mar 21, 20:24:56, Sven Hartge wrote:
>
> (I still vividly remember using memmaker and manual ordering the drivers
> in config.sys and autoexec.bat to shave another 2KB from the lower
> memory so the IPX driver would fit so Doom would run.)
For me it was Warcraft :)
And for some game
Anssi Saari wrote:
> Dan Ritter writes:
>
> As for the ECC support in Ryzen CPUs, as I understand it it's a bit of a
> mess. Sure the CPUs support it but if it's not validated by motherboard
> manufacturers, how do you know it actually works reliably?
... by trying it out and reporting the
On Mon, Mar 15, 2021 at 03:50:56PM -0400, Stefan Monnier wrote:
In retrospect maybe DEC and SGI should have merged and then partnered
with AMD (as you note above some of DEC's processor design team indeed
ended up at AMD on the Opteron project), but I think it would have taken
a crapload of
Dan Ritter writes:
> Intel knew that their argument was bull: they owned the market
> and needed ways of subdividing their CPUs to fit every price
> point. Turning off ECC support was one of those ways.
> That strategy started with the 80486, when they brought out a
> cheap version called the
>>So it was a great move on the part of AMD: cheap to implement but with
>>an enormous marketing impact.
> It had much more than a marketing impact, because x86 was a PITA for more
> than 2GB of RAM and that was getting cheap and becoming a common problem by
> 2003. Switching to opteron for 8G or
Sven Hartge wrote:
> Stefan Monnier wrote:
>
> > From a purely technical perspective, it's hard to understand how Intel
> > managed to pour so much energy into such an obviously bad idea. The
> > only explanations seem all to be linked to market strategies.
>
> This history repeats for Intel
Stefan Monnier wrote:
> From a purely technical perspective, it's hard to understand how Intel
> managed to pour so much energy into such an obviously bad idea. The
> only explanations seem all to be linked to market strategies.
This history repeats for Intel on several fronts:
Look at the
Joe wrote:
> On Mon, 15 Mar 2021 12:34:42 +0100 Sven Hartge wrote:
>> Imagine a PC with 4GB adressable memory space in 1980.
> I can. It would have cost as much as a mainframe to make full use of it.
I don't say to put it in, only to have a flat 32bit address range.
Just like the current
>> No it wouldn't, and we had it by the late '80's with the advent of
>> 68040 abd 68060 accellerator boards for the Amiga's. But that flat
>> memory model and poor production QC doomed it. Any program could make
>> a missfire and write into another programs memory space, crashing the
>> whole
On Mon, Mar 15, 2021 at 01:35:42PM -0400, Celejar wrote:
Apparently POWER is having a bit of a resurgence lately due to its
openness and non-x86ness:
https://www.osnews.com/story/133093/review-blackbird-secure-desktop-a-fully-open-source-modern-power9-workstation-without-any-proprietary-code/
On Monday 15 March 2021 12:40:51 John Hasler wrote:
> Gene writes:
> > No it wouldn't, and we had it by the late '80's with the advent of
> > 68040 abd 68060 accellerator boards for the Amiga's. But that flat
> > memory model and poor production QC doomed it. Any program could
> > make a
I guess I misremembered. After the merger they certainly *acted* as if
Compaq management was in charge.
--
John Hasler
jhas...@newsguy.com
Elmwood, WI USA
On Mon, 15 Mar 2021 12:39:10 -0400
Michael Stone wrote:
...
> On Mon, Mar 15, 2021 at 09:15:10AM +0100, Sven Hartge wrote:
> >Stefan Monnier wrote:
> >> The IA64 architecture was a resounding success in one area tho: it
> >> killed most of the competition that was coming from "above" (at least
On Mon, Mar 15, 2021 at 11:55:40AM -0500, John Hasler wrote:
Michael Stone writes:
...HP bought Compaq.
Compaq bought HP and then renamed themselves HP. The name was all they
really wanted, of course.
That's a strange way to position it, since HP gave Compaq shareholders
HP shares
Michael Stone writes:
> ...HP bought Compaq.
Compaq bought HP and then renamed themselves HP. The name was all they
really wanted, of course. HP had already spun off their instrumentation
division (the real HP) as Agilent.
--
John Hasler
jhas...@newsguy.com
Elmwood, WI USA
On Mon, Mar 15, 2021 at 11:03:59AM -0400, Stefan Monnier wrote:
From a purely technical perspective, it's hard to understand how Intel
managed to pour so much energy into such an obviously bad idea.
The only explanations seem all to be linked to market strategies.
They just had too much easy
Gene writes:
> No it wouldn't, and we had it by the late '80's with the advent of
> 68040 abd 68060 accellerator boards for the Amiga's. But that flat
> memory model and poor production QC doomed it. Any program could make
> a missfire and write into another programs memory space, crashing the
>
On Sun, Mar 14, 2021 at 10:44:00AM -0500, John Hasler wrote:
The Wanderer wrote:
It caught on, and became so successful that Intel abandoned its ia64
approach and started making amd64 CPUs itself.
Which was unfortunate as the x86 architecture needed to die.
Moving to ia64 would have been
Stefan Monnier wrote:
> > There's already work in progress to port Linux mainline (and
> > consequently Debian) to the Apple M1 :)
>
> Since the M1 implements the ARM instruction set, I don't think there's
> much work to do here, indeed (most likely the hardest part is to fight
> Apple's
On Sun, Mar 14, 2021, 1:50 PM Stefan Monnier
wrote:
> > Well, nearly. Itanium Merced was 2001 [1] (althoug you wouldn't buy
> > /that/ as a private person), DEC Alpha was even 1992 [2];
>
> FWIW And MIPS was there even a bit earlier with their R4000 (tho the
> software support for it only
>> The original plan/claims was that the support for legacy i386
>> application would be "just as fast". This never materialized
>> (unsurprisingly: it's easy to make a CPU that can run efficiency several
>> slightly different instruction sets (ISA), like your average amd64 CPU which
>> can run
>> Indeed. Also, they wanted to move away from the i386 instruction set
>> so as not to be bothered by pre-existing licensing agreements with
>> AMD, and thus making sure there'd be no competing implementation. The
>> IA64 architecture was quite complex, and there are reasons to believe
>> that
On Mon, Mar 15, 2021 at 12:53:46PM +, Joe wrote:
On Mon, 15 Mar 2021 12:34:42 +0100 Sven Hartge wrote:
Imagine a PC with 4GB adressable memory space in 1980.
I can. It would have cost as much as a mainframe to make full use of it.
More. Memory was often the largest line item back then,
On Mon, Mar 15, 2021 at 10:45:15AM -0400, Stefan Monnier wrote:
> >> Another rumor I read was that IBM, when developing the first IBM PC in
> >> 1980, opted to use the 8086/8088 CPU instead of the also availble M68k
> >> CPU because the Intel one was less powerful so it would not be in
> >>
>> Another rumor I read was that IBM, when developing the first IBM PC in
>> 1980, opted to use the 8086/8088 CPU instead of the also availble M68k
>> CPU because the Intel one was less powerful so it would not be in
>> competition with the mainframes the PC was supposed to interface with
>>
Gene writes:
> That, IIRC was a new, super shiny, thing from zilog. No experience
> with it, but if it was as unreliable as the z-80, was, I'm not sorry
> it failed. The Z-80 had an instruction that swapped the
> foregrund/background register sets. But it only worked on odd hours
> of the day.
On Mon, Mar 15, 2021 at 10:02:12AM -0400, Gene Heskett wrote:
[...]
> Snerk. We all did that back in the day, Tomas. that and similar magazines
> were this 8th grade graduates electronics education. Do they still exist
> today? Retired now, so the subs expired.
Some of them:
On Monday 15 March 2021 09:53:40 to...@tuxteam.de wrote:
> On Mon, Mar 15, 2021 at 09:31:05AM -0400, Gene Heskett wrote:
> > On Monday 15 March 2021 07:05:02 to...@tuxteam.de wrote:
> > > On Mon, Mar 15, 2021 at 11:09:35AM +0100, Sven Hartge wrote:
> > >
> > > [...]
> > >
> > > > Another rumor I
On Mon, Mar 15, 2021 at 09:31:05AM -0400, Gene Heskett wrote:
> On Monday 15 March 2021 07:05:02 to...@tuxteam.de wrote:
>
> > On Mon, Mar 15, 2021 at 11:09:35AM +0100, Sven Hartge wrote:
> >
> > [...]
> >
> > > Another rumor I read was that IBM, when developing the first IBM PC
> > > in 1980,
On Monday 15 March 2021 08:53:46 Joe wrote:
> On Mon, 15 Mar 2021 12:34:42 +0100
>
> Sven Hartge wrote:
> > to...@tuxteam.de wrote:
> > > On Mon, Mar 15, 2021 at 11:09:35AM +0100, Sven Hartge wrote:
> > >> Another rumor I read was that IBM, when developing the first IBM
> > >> PC in 1980, opted
On Lu, 15 mar 21, 09:22:26, Susmita/Rajib wrote:
>
> Thank you very, very much for all your inputs. Please put this thread
> to rest and focus instead of helping seekers who need your support. I
> have had enough information already from the post of The Wanderer.
Lengthy, more or less offtopic
On Monday 15 March 2021 07:05:02 to...@tuxteam.de wrote:
> On Mon, Mar 15, 2021 at 11:09:35AM +0100, Sven Hartge wrote:
>
> [...]
>
> > Another rumor I read was that IBM, when developing the first IBM PC
> > in 1980, opted to use the 8086/8088 CPU instead of the also availble
> > M68k CPU because
On Mon, 15 Mar 2021 12:34:42 +0100
Sven Hartge wrote:
> to...@tuxteam.de wrote:
> > On Mon, Mar 15, 2021 at 11:09:35AM +0100, Sven Hartge wrote:
>
> >> Another rumor I read was that IBM, when developing the first IBM PC
> >> in 1980, opted to use the 8086/8088 CPU instead of the also
> >>
>
>
> No stupid memory segmentation,
>
IMHO segmentation was a good idea originally.
You could have separate segments for code and data and since 286 it is
possible to protect them (AFAIK segments were also used to separate
user-space and kernel-space)
But with the advent of virtual memory (386),
On Mon, Mar 15, 2021 at 12:34:42PM +0100, Sven Hartge wrote:
[...]
> Having had a 68k would have been awesome. No stupid memory segmentation,
So were Z8000, NS32K and many others. The horrible segmentation thing on
the '86 were the tribute to backward compatibility, which is the price
you pay
to...@tuxteam.de wrote:
> On Mon, Mar 15, 2021 at 11:09:35AM +0100, Sven Hartge wrote:
>> Another rumor I read was that IBM, when developing the first IBM PC
>> in 1980, opted to use the 8086/8088 CPU instead of the also availble
>> M68k CPU because the Intel one was less powerful so it would not
On Mon, Mar 15, 2021 at 11:09:35AM +0100, Sven Hartge wrote:
[...]
> Another rumor I read was that IBM, when developing the first IBM PC in
> 1980, opted to use the 8086/8088 CPU instead of the also availble M68k
> CPU because the Intel one was less powerful so it would not be in
> competition
Susmita/Rajib wrote:
> May be, Debian should make a summary of all the information collected
> from here and post an article on its page for a pre-emptive
> clarification on the flavours that Debian is available in, and not let
> the information accumulated here go waste.
Wikipedia has quite a
to...@tuxteam.de wrote:
> On Mon, Mar 15, 2021 at 09:15:10AM +0100, Sven Hartge wrote:
>> For the others: they where either on board from the start (like HP),
>> where already dead (like DEC/Compaq) or slipping into the embedded
>> market (like MIPS).
> MIPS had its chance to become the unified
On Mon, Mar 15, 2021 at 09:15:10AM +0100, Sven Hartge wrote:
[...]
> For the others: they where either on board from the start (like HP),
> where already dead (like DEC/Compaq) or slipping into the embedded
> market (like MIPS).
MIPS had its chance to become the unified architecture for
On Du, 14 mar 21, 15:17:39, Stefan Monnier wrote:
>
> The original plan/claims was that the support for legacy i386
> application would be "just as fast". This never materialized
> (unsurprisingly: it's easy to make a CPU that can run efficiency several
> slightly different instruction sets
Stefan Monnier wrote:
>> Note: when IA64 was designed (starting in 1994 at HP) we where nowhere
>> near the limits of the 32bit i386 architecture with RAM and frequency,
>> so it made sense, somewhat.
> Indeed. Also, they wanted to move away from the i386 instruction set
> so as not to be
2021-03-14 7:19 GMT-04:00, The Wanderer :
> On 2021-03-14 at 06:49, Susmita/Rajib wrote:
>
>> While Intel PCs are also 64bit processors?
>
> Because of the history of the processor microarchitectures involved.
>
> The x86 processor line (32-bit and older) was, to the best of my
> knowledge,
> IA64 (Itanium) was completely incompatible with the installed i386 base.
> The first CPUs had a (very slow) compatibility layer, assisted by
> software, so you could run your "legacy" 16bit/32bit applications.
The original plan/claims was that the support for legacy i386
application would be
> Well, nearly. Itanium Merced was 2001 [1] (althoug you wouldn't buy
> /that/ as a private person), DEC Alpha was even 1992 [2];
FWIW And MIPS was there even a bit earlier with their R4000 (tho the
software support for it only appeared some years later: they first
wanted to have an installed
The Wanderer wrote:
> It caught on, and became so successful that Intel abandoned its ia64
> approach and started making amd64 CPUs itself.
Which was unfortunate as the x86 architecture needed to die.
--
John Hasler
jhas...@newsguy.com
Elmwood, WI USA
Thank you, Mr. Roberto C. Sánchez, Mr. Andrei Popescu, Mr. Eduardo M
KalinovskI, Mr. Tomas and Mr. songbird, who posted their replies to
educate me. The Wanderer was so superlative in his exposition that my
rest teachers were compelled to play a supporting role. This always
occurs in any
Andrei POPESCU wrote:
> On Du, 14 mar 21, 07:19:25, The Wanderer wrote:
>> When 64-bit came along, rather than extending the x86 line, Intel
>> started from scratch and designed an entire new CPU architecture.
>> That got called ia64, and it never caught on; it eventually failed in
>> the
Susmita/Rajib wrote:
> While Intel PCs are also 64bit processors?
>
> For instance, my current laptop is Lenovo IdeaPad 320-15ISK 80XH01FKIN
> 15.6-inch Laptop (6th Gen Core i3-6006U/4GB/2TB/Integrated Graphics),
> a 64bit processor.
>
> It can't be that intellectuals, technocrats and cognitive
On Sun, Mar 14, 2021 at 04:25:38AM -0700, Peter Ehlert wrote:
[...]
> AMD was the first on the market with 64bit hardware. (I was an early
> adopter)
Well, nearly. Itanium Merced was 2001 [1] (althoug you wouldn't buy
/that/ as a private person), DEC Alpha was even 1992 [2]; it was the
first 64
On Du, 14 mar 21, 07:19:25, The Wanderer wrote:
>
> When 64-bit came along, rather than extending the x86 line, Intel
> started from scratch and designed an entire new CPU architecture. That
> got called ia64, and it never caught on; it eventually failed in the
> marketplace, except possibly in
601 - 700 of 6154 matches
Mail list logo
