| 64 bit CPU, QBasic and DOS? [message #311777] |
Sat, 13 February 2016 07:22  |
gareth
Messages: 598
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
What fun we could have should a nice, simple, easy 64-bit version
of MS-DOS be around; the only thing to my mind that would
be lacking would be a graphical Web interface.
Imagine; a single linear address space, no software bloat
(Even Linux is popping its trouser buttons), and only a few kBytes
consumed by the OS!
The downside would be that assuming that one could write one
assembler instruction per minute in a 40-hour working week
and a 46-week working year, allowing approximately 4 bytes
for each instruction, then it would take you about 9,000 man-years
to write enough code for a progran to completely fill 4GB of RAM!
(YMMV !!!! )
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311778 is a reply to message #311777] |
Sat, 13 February 2016 08:29  |
philo[1][2]
Messages: 110
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On 02/13/2016 06:22 AM, gareth wrote:
> What fun we could have should a nice, simple, easy 64-bit version
> of MS-DOS be around; the only thing to my mind that would
> be lacking would be a graphical Web interface.
>
> Imagine; a single linear address space, no software bloat
> (Even Linux is popping its trouser buttons), and only a few kBytes
> consumed by the OS!
>
> The downside would be that assuming that one could write one
> assembler instruction per minute in a 40-hour working week
> and a 46-week working year, allowing approximately 4 bytes
> for each instruction, then it would take you about 9,000 man-years
> to write enough code for a progran to completely fill 4GB of RAM!
>
> (YMMV !!!! )
>
>
>
>
>
Well, back when I worked with old machines there was a graphical web
browser for DOS called Arachne
Just Googled and saw it had a release as recently as 2013
There was even a Linux version but it was non-functional at the time
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311784 is a reply to message #311777] |
Sat, 13 February 2016 09:43 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
gareth <no.spam@thank.you.invalid> wrote:
> What fun we could have should a nice, simple, easy 64-bit version
> of MS-DOS be around; the only thing to my mind that would
> be lacking would be a graphical Web interface.
>
> Imagine; a single linear address space, no software bloat
> (Even Linux is popping its trouser buttons), and only a few kBytes
> consumed by the OS!
>
> The downside would be that assuming that one could write one
> assembler instruction per minute in a 40-hour working week
> and a 46-week working year, allowing approximately 4 bytes
> for each instruction, then it would take you about 9,000 man-years
> to write enough code for a progran to completely fill 4GB of RAM!
>
> (YMMV !!!! )
>
Or you get 9000 people to each write code for a year - the microsoft
method. I doubt that too many large software projects are written in
assembler these days.
--
Pete
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311787 is a reply to message #311777] |
Sat, 13 February 2016 11:13 |
Morten Reistad
Messages: 2108
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <n9n71i$j1f$1@dont-email.me>,
gareth <no.spam@thank.you.invalid> wrote:
> What fun we could have should a nice, simple, easy 64-bit version
> of MS-DOS be around; the only thing to my mind that would
> be lacking would be a graphical Web interface.
>
> Imagine; a single linear address space, no software bloat
> (Even Linux is popping its trouser buttons), and only a few kBytes
> consumed by the OS!
Keep dreaming.
A full-function, very basic modern OS will take around 4 megabytes
with only a handful of drivers if it handles a 64-bit address range,
around 2.5 - 3 if it is a 32 bit range. Even Tops20, VMS, Primos are
there if you let them develop far enough; tops20 at version 6,
Primos at version 23, vms at ???
Add the ~20k drivers that Linux, FreeBSD have, and add two dozen
subsystems like USB, Firewire, IPv4, Ipv6, SMB, etc; and they are
not too bad off either of them in terms of kernel and driver
space used.
The bloat is on top of the kernel, and it is reasonably easy to
get rid of the bulk of it.
Let me get to the numbers: This samsung chromebook I use as a
laptop has a bloat level I like. It has a two-processor arm7 with
2G ram. 32-bit. Thumb2.
There are 524288 4k pages. After memory map, cpu-reserved pages for
task switching, lookaside buffers, etc are allocated there are
519936. This is mostly memory map organisation use. The initial
load of linux+initramfs (a boot-time minimal ram file system that
Linux use to simplify the boot process; so it can proceed further
before actually adding any disks) takes 29334 pages.
Linux then allocate pages here and there and has a max allocation
of 36440 pages before it frees the initramfs. This means that this
particular Linux installation; not even attempted to prune the size;
has a minimum boot requirement of (524288 - 519936) + 36440 of the
initial 524288 pages; or 40792, equal to 163168 kilobytes of RAM.
The initramfs is then freed, and Linux use 10305 pages, plus it
allocates 6350 as a page cache. This is the overflow paging area
that can contain real user code, so it does not really count in
kernel use. After boot we therefore have a use of (524288 - 519936)
+ 10305; or 14657 pages, equal to 58628 kilobytes.
Linux code is around half of this, and half again of that are
drivers.
Then systemd takes over, and all memory use goes haywire. The
old systems like X are still well within reason, X itself are
the biggest one of these at ~30M plus ~8M shared libraries.
There are around 120 active processes, where the browser and
libreoffice are the hogs. The rest take around 250 megabytes
total.
This is borne out from some freebsd web servers I run in
some very remote telemetry locations (but with excellent
connectivity). They run very well in 512M of ram.
> The downside would be that assuming that one could write one
> assembler instruction per minute in a 40-hour working week
> and a 46-week working year, allowing approximately 4 bytes
> for each instruction, then it would take you about 9,000 man-years
> to write enough code for a progran to completely fill 4GB of RAM!
That makes 9600 bytes per week,
When I write some high level language code I do make around 200
loc per day on average, and that generates 8-10 k of binary
code ex variables and buffers. This bears out the around 4-5
times productivity using higher level languages. So it would
only take around 2000 man years. :-/
Or 50 men, 40.
Of course, if I am REALLY productive then I am reducing the net
loc in the project.
-- mrr
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311792 is a reply to message #311777] |
Sat, 13 February 2016 11:47 |
|
|
Originally posted by: roger.ivie
On Saturday, February 13, 2016 at 4:22:58 AM UTC-8, gareth wrote:
> What fun we could have should a nice, simple, easy 64-bit version
> of MS-DOS be around...
CP/M-68K is written in C. With a bit of work, it can be massaged enough
to go through a modern compiler; I've made it run on ARM and VAX.
Get hacking!
--
roger ivie
roger.ivie@gmail.com
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311794 is a reply to message #311787] |
Sat, 13 February 2016 12:18 |
gareth
Messages: 598
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
"Morten Reistad" <first@last.name.invalid> wrote in message
news:o914pc-pd3.ln1@sambook.reistad.name...
You seem to have been brain-washed or conditioned by the world of bloat,
whereas I was brought up on 16-bit minicomputers (PDP11) with memory
of 56K, so I know how much can be achieved in a small space.
Starting off small will also improve the quality of so-called computer
scientists who otherwise have limited exposure to the real computers
with their experience only of Linux and C.
> In article <n9n71i$j1f$1@dont-email.me>,
> gareth <no.spam@thank.you.invalid> wrote:
>> What fun we could have should a nice, simple, easy 64-bit version
>> of MS-DOS be around; the only thing to my mind that would
>> be lacking would be a graphical Web interface.
>>
>> Imagine; a single linear address space, no software bloat
>> (Even Linux is popping its trouser buttons), and only a few kBytes
>> consumed by the OS!
>
> Keep dreaming.
>
> A full-function, very basic modern OS will take around 4 megabytes
> with only a handful of drivers if it handles a 64-bit address range,
> around 2.5 - 3 if it is a 32 bit range. Even Tops20, VMS, Primos are
> there if you let them develop far enough; tops20 at version 6,
> Primos at version 23, vms at ???
>
> Add the ~20k drivers that Linux, FreeBSD have, and add two dozen
> subsystems like USB, Firewire, IPv4, Ipv6, SMB, etc; and they are
> not too bad off either of them in terms of kernel and driver
> space used.
>
> The bloat is on top of the kernel, and it is reasonably easy to
> get rid of the bulk of it.
>
> Let me get to the numbers: This samsung chromebook I use as a
> laptop has a bloat level I like. It has a two-processor arm7 with
> 2G ram. 32-bit. Thumb2.
>
> There are 524288 4k pages. After memory map, cpu-reserved pages for
> task switching, lookaside buffers, etc are allocated there are
> 519936. This is mostly memory map organisation use. The initial
> load of linux+initramfs (a boot-time minimal ram file system that
> Linux use to simplify the boot process; so it can proceed further
> before actually adding any disks) takes 29334 pages.
>
> Linux then allocate pages here and there and has a max allocation
> of 36440 pages before it frees the initramfs. This means that this
> particular Linux installation; not even attempted to prune the size;
> has a minimum boot requirement of (524288 - 519936) + 36440 of the
> initial 524288 pages; or 40792, equal to 163168 kilobytes of RAM.
>
> The initramfs is then freed, and Linux use 10305 pages, plus it
> allocates 6350 as a page cache. This is the overflow paging area
> that can contain real user code, so it does not really count in
> kernel use. After boot we therefore have a use of (524288 - 519936)
> + 10305; or 14657 pages, equal to 58628 kilobytes.
>
> Linux code is around half of this, and half again of that are
> drivers.
>
> Then systemd takes over, and all memory use goes haywire. The
> old systems like X are still well within reason, X itself are
> the biggest one of these at ~30M plus ~8M shared libraries.
> There are around 120 active processes, where the browser and
> libreoffice are the hogs. The rest take around 250 megabytes
> total.
>
> This is borne out from some freebsd web servers I run in
> some very remote telemetry locations (but with excellent
> connectivity). They run very well in 512M of ram.
>
>> The downside would be that assuming that one could write one
>> assembler instruction per minute in a 40-hour working week
>> and a 46-week working year, allowing approximately 4 bytes
>> for each instruction, then it would take you about 9,000 man-years
>> to write enough code for a progran to completely fill 4GB of RAM!
>
> That makes 9600 bytes per week,
>
> When I write some high level language code I do make around 200
> loc per day on average, and that generates 8-10 k of binary
> code ex variables and buffers. This bears out the around 4-5
> times productivity using higher level languages. So it would
> only take around 2000 man years. :-/
>
> Or 50 men, 40.
>
> Of course, if I am REALLY productive then I am reducing the net
> loc in the project.
>
> -- mrr
|
|
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311839 is a reply to message #311794] |
Sat, 13 February 2016 17:51 |
Morten Reistad
Messages: 2108
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <n9nobn$kl0$1@dont-email.me>,
gareth <no.spam@thank.you.invalid> wrote:
> "Morten Reistad" <first@last.name.invalid> wrote in message
> news:o914pc-pd3.ln1@sambook.reistad.name...
>
> You seem to have been brain-washed or conditioned by the world of bloat,
> whereas I was brought up on 16-bit minicomputers (PDP11) with memory
> of 56K, so I know how much can be achieved in a small space.
>
> Starting off small will also improve the quality of so-called computer
> scientists who otherwise have limited exposure to the real computers
> with their experience only of Linux and C.
And we know what cannot be done in small address spaces.
Just take wifi. There are complex radio protocols, and even more complex
encryption ones. And there are at least 4 of each. The code for these
are easily a few megabytes. Ditto for USB, firewire, scsi, sata; and
a lot of the daemons. But these first ones live inside the kernel, all
of them. Plus 10 different file systems.
I don't think 40 megabytes for all of this is much bloat. They all bring
useful stuff to the table, too.
That X use 30 meg is also not unreasonable. 12 of these are buffers for
the screen.
But that a browser uses 1600 (!) and a word processor use 600 are seriously
bloated. Emacs use around 8, which is way big enough for me.
In the *n*x world we have the old and the new world. The old world may use
a few tens of megabytes, and use them reasonably well. The new one use gigabytes,
and have insane bloat.
What complexity is there in html, http(s) and javascript that rivals USB
by two orders of magnitude?
-- mrr
>> In article <n9n71i$j1f$1@dont-email.me>,
>> gareth <no.spam@thank.you.invalid> wrote:
>>> What fun we could have should a nice, simple, easy 64-bit version
>>> of MS-DOS be around; the only thing to my mind that would
>>> be lacking would be a graphical Web interface.
>>>
>>> Imagine; a single linear address space, no software bloat
>>> (Even Linux is popping its trouser buttons), and only a few kBytes
>>> consumed by the OS!
>>
>> Keep dreaming.
>>
>> A full-function, very basic modern OS will take around 4 megabytes
>> with only a handful of drivers if it handles a 64-bit address range,
>> around 2.5 - 3 if it is a 32 bit range. Even Tops20, VMS, Primos are
>> there if you let them develop far enough; tops20 at version 6,
>> Primos at version 23, vms at ???
>>
>> Add the ~20k drivers that Linux, FreeBSD have, and add two dozen
>> subsystems like USB, Firewire, IPv4, Ipv6, SMB, etc; and they are
>> not too bad off either of them in terms of kernel and driver
>> space used.
>>
>> The bloat is on top of the kernel, and it is reasonably easy to
>> get rid of the bulk of it.
>>
>> Let me get to the numbers: This samsung chromebook I use as a
>> laptop has a bloat level I like. It has a two-processor arm7 with
>> 2G ram. 32-bit. Thumb2.
>>
>> There are 524288 4k pages. After memory map, cpu-reserved pages for
>> task switching, lookaside buffers, etc are allocated there are
>> 519936. This is mostly memory map organisation use. The initial
>> load of linux+initramfs (a boot-time minimal ram file system that
>> Linux use to simplify the boot process; so it can proceed further
>> before actually adding any disks) takes 29334 pages.
>>
>> Linux then allocate pages here and there and has a max allocation
>> of 36440 pages before it frees the initramfs. This means that this
>> particular Linux installation; not even attempted to prune the size;
>> has a minimum boot requirement of (524288 - 519936) + 36440 of the
>> initial 524288 pages; or 40792, equal to 163168 kilobytes of RAM.
>>
>> The initramfs is then freed, and Linux use 10305 pages, plus it
>> allocates 6350 as a page cache. This is the overflow paging area
>> that can contain real user code, so it does not really count in
>> kernel use. After boot we therefore have a use of (524288 - 519936)
>> + 10305; or 14657 pages, equal to 58628 kilobytes.
>>
>> Linux code is around half of this, and half again of that are
>> drivers.
>>
>> Then systemd takes over, and all memory use goes haywire. The
>> old systems like X are still well within reason, X itself are
>> the biggest one of these at ~30M plus ~8M shared libraries.
>> There are around 120 active processes, where the browser and
>> libreoffice are the hogs. The rest take around 250 megabytes
>> total.
>>
>> This is borne out from some freebsd web servers I run in
>> some very remote telemetry locations (but with excellent
>> connectivity). They run very well in 512M of ram.
>>
>>> The downside would be that assuming that one could write one
>>> assembler instruction per minute in a 40-hour working week
>>> and a 46-week working year, allowing approximately 4 bytes
>>> for each instruction, then it would take you about 9,000 man-years
>>> to write enough code for a progran to completely fill 4GB of RAM!
>>
>> That makes 9600 bytes per week,
>>
>> When I write some high level language code I do make around 200
>> loc per day on average, and that generates 8-10 k of binary
>> code ex variables and buffers. This bears out the around 4-5
>> times productivity using higher level languages. So it would
>> only take around 2000 man years. :-/
>>
>> Or 50 men, 40.
>>
>> Of course, if I am REALLY productive then I am reducing the net
>> loc in the project.
>>
>> -- mrr
>
>
|
|
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311845 is a reply to message #311794] |
Sat, 13 February 2016 19:31 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
gareth <no.spam@thank.you.invalid> wrote:
> "Morten Reistad" <first@last.name.invalid> wrote in message
> news:o914pc-pd3.ln1@sambook.reistad.name...
>
> You seem to have been brain-washed or conditioned by the world of bloat,
> whereas I was brought up on 16-bit minicomputers (PDP11) with memory
> of 56K, so I know how much can be achieved in a small space.
Hah! I was brought up on a 32K 360/30, and I imagine many here would think
that was extragavant.
>
> Starting off small will also improve the quality of so-called computer
> scientists who otherwise have limited exposure to the real computers
> with their experience only of Linux and C.
>
>
>
>
>
>
>> In article <n9n71i$j1f$1@dont-email.me>,
>> gareth <no.spam@thank.you.invalid> wrote:
>>> What fun we could have should a nice, simple, easy 64-bit version
>>> of MS-DOS be around; the only thing to my mind that would
>>> be lacking would be a graphical Web interface.
>>>
>>> Imagine; a single linear address space, no software bloat
>>> (Even Linux is popping its trouser buttons), and only a few kBytes
>>> consumed by the OS!
>>
>> Keep dreaming.
>>
>> A full-function, very basic modern OS will take around 4 megabytes
>> with only a handful of drivers if it handles a 64-bit address range,
>> around 2.5 - 3 if it is a 32 bit range. Even Tops20, VMS, Primos are
>> there if you let them develop far enough; tops20 at version 6,
>> Primos at version 23, vms at ???
>>
>> Add the ~20k drivers that Linux, FreeBSD have, and add two dozen
>> subsystems like USB, Firewire, IPv4, Ipv6, SMB, etc; and they are
>> not too bad off either of them in terms of kernel and driver
>> space used.
>>
>> The bloat is on top of the kernel, and it is reasonably easy to
>> get rid of the bulk of it.
>>
>> Let me get to the numbers: This samsung chromebook I use as a
>> laptop has a bloat level I like. It has a two-processor arm7 with
>> 2G ram. 32-bit. Thumb2.
>>
>> There are 524288 4k pages. After memory map, cpu-reserved pages for
>> task switching, lookaside buffers, etc are allocated there are
>> 519936. This is mostly memory map organisation use. The initial
>> load of linux+initramfs (a boot-time minimal ram file system that
>> Linux use to simplify the boot process; so it can proceed further
>> before actually adding any disks) takes 29334 pages.
>>
>> Linux then allocate pages here and there and has a max allocation
>> of 36440 pages before it frees the initramfs. This means that this
>> particular Linux installation; not even attempted to prune the size;
>> has a minimum boot requirement of (524288 - 519936) + 36440 of the
>> initial 524288 pages; or 40792, equal to 163168 kilobytes of RAM.
>>
>> The initramfs is then freed, and Linux use 10305 pages, plus it
>> allocates 6350 as a page cache. This is the overflow paging area
>> that can contain real user code, so it does not really count in
>> kernel use. After boot we therefore have a use of (524288 - 519936)
>> + 10305; or 14657 pages, equal to 58628 kilobytes.
>>
>> Linux code is around half of this, and half again of that are
>> drivers.
>>
>> Then systemd takes over, and all memory use goes haywire. The
>> old systems like X are still well within reason, X itself are
>> the biggest one of these at ~30M plus ~8M shared libraries.
>> There are around 120 active processes, where the browser and
>> libreoffice are the hogs. The rest take around 250 megabytes
>> total.
>>
>> This is borne out from some freebsd web servers I run in
>> some very remote telemetry locations (but with excellent
>> connectivity). They run very well in 512M of ram.
>>
>>> The downside would be that assuming that one could write one
>>> assembler instruction per minute in a 40-hour working week
>>> and a 46-week working year, allowing approximately 4 bytes
>>> for each instruction, then it would take you about 9,000 man-years
>>> to write enough code for a progran to completely fill 4GB of RAM!
>>
>> That makes 9600 bytes per week,
>>
>> When I write some high level language code I do make around 200
>> loc per day on average, and that generates 8-10 k of binary
>> code ex variables and buffers. This bears out the around 4-5
>> times productivity using higher level languages. So it would
>> only take around 2000 man years. :-/
>>
>> Or 50 men, 40.
>>
>> Of course, if I am REALLY productive then I am reducing the net
>> loc in the project.
>>
>> -- mrr
>
>
>
--
Pete
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311846 is a reply to message #311796] |
Sat, 13 February 2016 19:31 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Melzzzzz <mel@zzzzz.com> wrote:
> On Sat, 13 Feb 2016 17:18:14 -0000
> "gareth" <no.spam@thank.you.invalid> wrote:
>
>> "Morten Reistad" <first@last.name.invalid> wrote in message
>> news:o914pc-pd3.ln1@sambook.reistad.name...
>>
>> You seem to have been brain-washed or conditioned by the world of
>> bloat, whereas I was brought up on 16-bit minicomputers (PDP11) with
>> memory of 56K, so I know how much can be achieved in a small space.
>>
>
> Code is not big. What is big is data. Nowadays computer can process much
> more data than those small ones.
>
Not so much, unless you're looking at something monolithic, like an image.
We used to process lots of data, but in smaller chunks at one time.
--
Pete
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311847 is a reply to message #311839] |
Sat, 13 February 2016 19:31 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Morten Reistad <first@last.name.invalid> wrote:
> In article <n9nobn$kl0$1@dont-email.me>,
> gareth <no.spam@thank.you.invalid> wrote:
>> "Morten Reistad" <first@last.name.invalid> wrote in message
>> news:o914pc-pd3.ln1@sambook.reistad.name...
>>
>> You seem to have been brain-washed or conditioned by the world of bloat,
>> whereas I was brought up on 16-bit minicomputers (PDP11) with memory
>> of 56K, so I know how much can be achieved in a small space.
>>
>> Starting off small will also improve the quality of so-called computer
>> scientists who otherwise have limited exposure to the real computers
>> with their experience only of Linux and C.
>
> And we know what cannot be done in small address spaces.
>
> Just take wifi. There are complex radio protocols, and even more complex
> encryption ones. And there are at least 4 of each. The code for these
> are easily a few megabytes. Ditto for USB, firewire, scsi, sata; and
> a lot of the daemons. But these first ones live inside the kernel, all
> of them. Plus 10 different file systems.
Aren't they in DSOs? How many protocols or file systems will you use at
one time?
>
> I don't think 40 megabytes for all of this is much bloat. They all bring
> useful stuff to the table, too.
>
> That X use 30 meg is also not unreasonable. 12 of these are buffers for
> the screen.
>
> But that a browser uses 1600 (!) and a word processor use 600 are seriously
> bloated. Emacs use around 8, which is way big enough for me.
>
> In the *n*x world we have the old and the new world. The old world may use
> a few tens of megabytes, and use them reasonably well. The new one use gigabytes,
> and have insane bloat.
>
> What complexity is there in html, http(s) and javascript that rivals USB
> by two orders of magnitude?
>
> -- mrr
>
>>> In article <n9n71i$j1f$1@dont-email.me>,
>>> gareth <no.spam@thank.you.invalid> wrote:
>>>> What fun we could have should a nice, simple, easy 64-bit version
>>>> of MS-DOS be around; the only thing to my mind that would
>>>> be lacking would be a graphical Web interface.
>>>>
>>>> Imagine; a single linear address space, no software bloat
>>>> (Even Linux is popping its trouser buttons), and only a few kBytes
>>>> consumed by the OS!
>>>
>>> Keep dreaming.
>>>
>>> A full-function, very basic modern OS will take around 4 megabytes
>>> with only a handful of drivers if it handles a 64-bit address range,
>>> around 2.5 - 3 if it is a 32 bit range. Even Tops20, VMS, Primos are
>>> there if you let them develop far enough; tops20 at version 6,
>>> Primos at version 23, vms at ???
>>>
>>> Add the ~20k drivers that Linux, FreeBSD have, and add two dozen
>>> subsystems like USB, Firewire, IPv4, Ipv6, SMB, etc; and they are
>>> not too bad off either of them in terms of kernel and driver
>>> space used.
>>>
>>> The bloat is on top of the kernel, and it is reasonably easy to
>>> get rid of the bulk of it.
>>>
>>> Let me get to the numbers: This samsung chromebook I use as a
>>> laptop has a bloat level I like. It has a two-processor arm7 with
>>> 2G ram. 32-bit. Thumb2.
>>>
>>> There are 524288 4k pages. After memory map, cpu-reserved pages for
>>> task switching, lookaside buffers, etc are allocated there are
>>> 519936. This is mostly memory map organisation use. The initial
>>> load of linux+initramfs (a boot-time minimal ram file system that
>>> Linux use to simplify the boot process; so it can proceed further
>>> before actually adding any disks) takes 29334 pages.
>>>
>>> Linux then allocate pages here and there and has a max allocation
>>> of 36440 pages before it frees the initramfs. This means that this
>>> particular Linux installation; not even attempted to prune the size;
>>> has a minimum boot requirement of (524288 - 519936) + 36440 of the
>>> initial 524288 pages; or 40792, equal to 163168 kilobytes of RAM.
>>>
>>> The initramfs is then freed, and Linux use 10305 pages, plus it
>>> allocates 6350 as a page cache. This is the overflow paging area
>>> that can contain real user code, so it does not really count in
>>> kernel use. After boot we therefore have a use of (524288 - 519936)
>>> + 10305; or 14657 pages, equal to 58628 kilobytes.
>>>
>>> Linux code is around half of this, and half again of that are
>>> drivers.
>>>
>>> Then systemd takes over, and all memory use goes haywire. The
>>> old systems like X are still well within reason, X itself are
>>> the biggest one of these at ~30M plus ~8M shared libraries.
>>> There are around 120 active processes, where the browser and
>>> libreoffice are the hogs. The rest take around 250 megabytes
>>> total.
>>>
>>> This is borne out from some freebsd web servers I run in
>>> some very remote telemetry locations (but with excellent
>>> connectivity). They run very well in 512M of ram.
>>>
>>>> The downside would be that assuming that one could write one
>>>> assembler instruction per minute in a 40-hour working week
>>>> and a 46-week working year, allowing approximately 4 bytes
>>>> for each instruction, then it would take you about 9,000 man-years
>>>> to write enough code for a progran to completely fill 4GB of RAM!
>>>
>>> That makes 9600 bytes per week,
>>>
>>> When I write some high level language code I do make around 200
>>> loc per day on average, and that generates 8-10 k of binary
>>> code ex variables and buffers. This bears out the around 4-5
>>> times productivity using higher level languages. So it would
>>> only take around 2000 man years. :-/
>>>
>>> Or 50 men, 40.
>>>
>>> Of course, if I am REALLY productive then I am reducing the net
>>> loc in the project.
>>>
>>> -- mrr
>>
>>
>
>
>
--
Pete
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311851 is a reply to message #311787] |
Sat, 13 February 2016 19:53 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2016-02-13, Morten Reistad <first@last.name.invalid> wrote:
> When I write some high level language code I do make around 200
> loc per day on average, and that generates 8-10 k of binary
> code ex variables and buffers. This bears out the around 4-5
> times productivity using higher level languages. So it would
> only take around 2000 man years. :-/
>
> Or 50 men, 40.
Assuming the task can be subdivided and scales linearly -
which it usually doesn't.
"The bearing of a child takes nine months, no matter how
many women are assigned to the task." -- Fred Brooks
> Of course, if I am REALLY productive then I am reducing the net
> loc in the project.
I love that too. Drives the bean-counters nuts when their
LOC algorithms run off the rails.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311854 is a reply to message #311845] |
Sat, 13 February 2016 20:01 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2016-02-14, Peter Flass <peter_flass@yahoo.com> wrote:
> gareth <no.spam@thank.you.invalid> wrote:
>
>> "Morten Reistad" <first@last.name.invalid> wrote in message
>> news:o914pc-pd3.ln1@sambook.reistad.name...
>>
>> You seem to have been brain-washed or conditioned by the world of bloat,
>> whereas I was brought up on 16-bit minicomputers (PDP11) with memory
>> of 56K, so I know how much can be achieved in a small space.
>
> Hah! I was brought up on a 32K 360/30, and I imagine many here would think
> that was extragavant.
Yep. When we upgraded our Univac 9300 from 16K to 32K, we didn't know
what we were going to do with all that space. (We figured it out eventually.)
>> Starting off small will also improve the quality of so-called computer
>> scientists who otherwise have limited exposure to the real computers
>> with their experience only of Linux and C.
Hear, hear! Since "abundance justifies waste" seems to be a fundamental
human condition, having to work without abundance for a while is beneficial
when the time comes (and it always does) when you encounter an application
that chews up all resources.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311861 is a reply to message #311845] |
Sat, 13 February 2016 21:20 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
It's true you could do a lot with 8k words (12k bytes) on a PDP-8, but I'm willing to concede that having a 386 with 2 megabytes and Windows 3.1 makes life much more convenient.
In fact, I have nothing against the power of today's systems; my frustration is directed at the lack of opportunity to put that power to good use.
John Savard
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311866 is a reply to message #311861] |
Sat, 13 February 2016 21:48 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Saturday, February 13, 2016 at 9:20:34 PM UTC-5, Quadibloc wrote:
> In fact, I have nothing against the power of today's systems; my frustration is directed at the lack of opportunity to put that power to good use.
+1.
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311867 is a reply to message #311845] |
Sat, 13 February 2016 21:49 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Saturday, February 13, 2016 at 7:31:47 PM UTC-5, Peter Flass wrote:
> Hah! I was brought up on a 32K 360/30, and I imagine many here would think
> that was extragavant.
I suspect most people in industry who worked on an actual System/360
have retired or are close to retirement. (Obviously there are some who
worked at a place that kept their S/360 a long time, or, have chosen not
to retire and keep working.)
(Of course, I do know a former 1401 programmer, who worked on it under
emulation, who is only fifty.)
|
|
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311869 is a reply to message #311839] |
Sat, 13 February 2016 21:54 |
Stephen Sprunk
Messages: 2166
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
On 13-Feb-16 16:51, Morten Reistad wrote:
> That X use 30 meg is also not unreasonable. 12 of these are buffers
> for the screen.
>
> But that a browser uses 1600 (!) and a word processor use 600 are
> seriously bloated. Emacs use around 8, which is way big enough for
> me.
> ...
> What complexity is there in html, http(s) and javascript that rivals
> USB by two orders of magnitude?
HTTP is trivial. SSL/TLS has more complexity, as evidenced by the
constant flood of OpenSSL security bugs, but overall, it's a rounding
error compared to the rest of the browser.
HTML wasn't that complicated at first, but rendering it still required a
bunch of GUI code--and GUIs aren't known for being lightweight. CSS
increased the difficulty of rendering HTML by an order of magnitude.
Javascript needs a JIT for adequate performance, which is complex, and
it has the ability to both read and write both HTML and CSS on the fly,
which increases complexity by another order of magnitude. OTOH, they're
also mind-bogglingly powerful when used together.
In contrast, USB is a limited, static hardware protocol designed to be
cheaply implemented, with a thin driver layer on top. It's not even
remotely comparable to what a modern web browser needs to handle.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311872 is a reply to message #311868] |
Sat, 13 February 2016 22:19 |
Michael Black
Messages: 2799
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 13 Feb 2016, Lawrence Statton wrote:
> Morten Reistad <first@last.name.invalid> writes:
>> Emacs use around 8, which is way big enough for me.
>>
>
> I find it midly amusing that Emacs, which was belitted by its detractors
> for consuming "eight megs and constantly swapping" -- now that numbered
> is considered downright miserly with memory ...
>
Especially when it does everything, including the kitchen sink.
Michael
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311900 is a reply to message #311839] |
Sun, 14 February 2016 02:47 |
gareth
Messages: 598
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
"Morten Reistad" <first@last.name.invalid> wrote in message
news:8lo4pc-s45.ln1@sambook.reistad.name...
You seem to have been brain-washed or conditioned by the world of bloat,
whereas I was brought up on 16-bit minicomputers (PDP11) with memory
of 56K, so I know how much can be achieved in a small space.
Starting off small will also improve the quality of so-called computer
scientists who otherwise have limited exposure to the real computers
with their experience only of Linux and C.
>> "Morten Reistad" <first@last.name.invalid> wrote in message
>> news:o914pc-pd3.ln1@sambook.reistad.name...
>>
>
> And we know what cannot be done in small address spaces.
>
> Just take wifi. There are complex radio protocols, and even more complex
> encryption ones. And there are at least 4 of each. The code for these
> are easily a few megabytes. Ditto for USB, firewire, scsi, sata; and
> a lot of the daemons. But these first ones live inside the kernel, all
> of them. Plus 10 different file systems.
>
> I don't think 40 megabytes for all of this is much bloat. They all bring
> useful stuff to the table, too.
>
> That X use 30 meg is also not unreasonable. 12 of these are buffers for
> the screen.
>
> But that a browser uses 1600 (!) and a word processor use 600 are
> seriously
> bloated. Emacs use around 8, which is way big enough for me.
>
> In the *n*x world we have the old and the new world. The old world may use
> a few tens of megabytes, and use them reasonably well. The new one use
> gigabytes,
> and have insane bloat.
>
> What complexity is there in html, http(s) and javascript that rivals USB
> by two orders of magnitude?
>
> -- mrr
>
>>> In article <n9n71i$j1f$1@dont-email.me>,
>>> gareth <no.spam@thank.you.invalid> wrote:
>>>> What fun we could have should a nice, simple, easy 64-bit version
>>>> of MS-DOS be around; the only thing to my mind that would
>>>> be lacking would be a graphical Web interface.
>>>>
>>>> Imagine; a single linear address space, no software bloat
>>>> (Even Linux is popping its trouser buttons), and only a few kBytes
>>>> consumed by the OS!
>>>
>>> Keep dreaming.
>>>
>>> A full-function, very basic modern OS will take around 4 megabytes
>>> with only a handful of drivers if it handles a 64-bit address range,
>>> around 2.5 - 3 if it is a 32 bit range. Even Tops20, VMS, Primos are
>>> there if you let them develop far enough; tops20 at version 6,
>>> Primos at version 23, vms at ???
>>>
>>> Add the ~20k drivers that Linux, FreeBSD have, and add two dozen
>>> subsystems like USB, Firewire, IPv4, Ipv6, SMB, etc; and they are
>>> not too bad off either of them in terms of kernel and driver
>>> space used.
>>>
>>> The bloat is on top of the kernel, and it is reasonably easy to
>>> get rid of the bulk of it.
>>>
>>> Let me get to the numbers: This samsung chromebook I use as a
>>> laptop has a bloat level I like. It has a two-processor arm7 with
>>> 2G ram. 32-bit. Thumb2.
>>>
>>> There are 524288 4k pages. After memory map, cpu-reserved pages for
>>> task switching, lookaside buffers, etc are allocated there are
>>> 519936. This is mostly memory map organisation use. The initial
>>> load of linux+initramfs (a boot-time minimal ram file system that
>>> Linux use to simplify the boot process; so it can proceed further
>>> before actually adding any disks) takes 29334 pages.
>>>
>>> Linux then allocate pages here and there and has a max allocation
>>> of 36440 pages before it frees the initramfs. This means that this
>>> particular Linux installation; not even attempted to prune the size;
>>> has a minimum boot requirement of (524288 - 519936) + 36440 of the
>>> initial 524288 pages; or 40792, equal to 163168 kilobytes of RAM.
>>>
>>> The initramfs is then freed, and Linux use 10305 pages, plus it
>>> allocates 6350 as a page cache. This is the overflow paging area
>>> that can contain real user code, so it does not really count in
>>> kernel use. After boot we therefore have a use of (524288 - 519936)
>>> + 10305; or 14657 pages, equal to 58628 kilobytes.
>>>
>>> Linux code is around half of this, and half again of that are
>>> drivers.
>>>
>>> Then systemd takes over, and all memory use goes haywire. The
>>> old systems like X are still well within reason, X itself are
>>> the biggest one of these at ~30M plus ~8M shared libraries.
>>> There are around 120 active processes, where the browser and
>>> libreoffice are the hogs. The rest take around 250 megabytes
>>> total.
>>>
>>> This is borne out from some freebsd web servers I run in
>>> some very remote telemetry locations (but with excellent
>>> connectivity). They run very well in 512M of ram.
>>>
>>>> The downside would be that assuming that one could write one
>>>> assembler instruction per minute in a 40-hour working week
>>>> and a 46-week working year, allowing approximately 4 bytes
>>>> for each instruction, then it would take you about 9,000 man-years
>>>> to write enough code for a progran to completely fill 4GB of RAM!
>>>
>>> That makes 9600 bytes per week,
>>>
>>> When I write some high level language code I do make around 200
>>> loc per day on average, and that generates 8-10 k of binary
>>> code ex variables and buffers. This bears out the around 4-5
>>> times productivity using higher level languages. So it would
>>> only take around 2000 man years. :-/
>>>
>>> Or 50 men, 40.
>>>
>>> Of course, if I am REALLY productive then I am reducing the net
>>> loc in the project.
>>>
>>> -- mrr
>>
>>
>
>
|
|
|
|
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311909 is a reply to message #311777] |
Sun, 14 February 2016 04:49 |
Morten Reistad
Messages: 2108
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <diau2sF8tu9U1@mid.individual.net>,
Huge <usenet@huge.org.uk> wrote:
> On 2016-02-14, Peter Flass <peter_flass@yahoo.com> wrote:
>> gareth <no.spam@thank.you.invalid> wrote:
>>> "Morten Reistad" <first@last.name.invalid> wrote in message
>>> news:o914pc-pd3.ln1@sambook.reistad.name...
>>>
>>> You seem to have been brain-washed or conditioned by the world of bloat,
>>> whereas I was brought up on 16-bit minicomputers (PDP11) with memory
>>> of 56K, so I know how much can be achieved in a small space.
>>
>> Hah! I was brought up on a 32K 360/30, and I imagine many here would think
>> that was extragavant.
>
> [100 lines snipped]
>
> Oh, the irony. :o)
I am not at all convinced by you calling everything bigger than 64k
for "bloat". We have seen a functionality explosion in the 4 decades
since pdp11s were the hottest stuff around (and they were).
I grew up on small systems too. The Commodore PET with 32k RAM
was one I got to know intimately. I was too late for the pdp11, but
got to see the micro revolution up close.
I also saw the beauty of the DEC20 at my college, where I started
using emacs Jan 17th 1979.
The PET had an 8k OS in ROM, and 8k Basic interpreter. The DEC20
had a ~2megabyte OS. The difference in functions was very clear.
We drooled about the dec20, but we worked with the PET. I even built
memory extensions for it.
Current machines have gigabytes of memory, and terabytes of disk.
The classic systems have grown, but not to those sizes. The bloat
is extreme in the browsers, however. And the spreadsheets, wordprocessors,
and packages. The "old code", later versions of X, window managers,
shells, editors, etc. has grown, but not by that much.
I will not call the Linux kernel bloat. 40 megabytes on a 2G machine,
where around 1/3rd are buffers sized according to the memory size,
and around half of the remaining are drivers; nearly 7k for around 20k
different devices. There are around 35 subsystems like usb, sata etc;
and 15 file systems. Call this diversity explosion bloat if you like,
but don't complain when you lose USB. (which are 4 different ones,
1.0, 1.2, 2.0 and 3.0; actually). or SATA. Or SCSI. I know people
who has pruned the Linux kernel down below 10m, but then you have
to shed lots of functions.
If I total up the kernel, shell, small servers plus X plus xfce4
I get to around 12-14% of the memory of this, today quite small, laptop.
This is a functionality explosion, which I am all for. I plug in
USB devices and have programs started automatically; I enter wifi
zones and log on automatically. And lots of such stuff.
Emacs still use around 8 megabytes. Libreoffice easily use 100 times
that. I don't get 100 times the functionality, rather the contrary.
THAT is bloat.
Yes, you can dream of the PDP11, I can dream of the PET. I still have
the C64 I got as a present for some PET designs. It has heavy hardware
mods. In those days we had to work with the hardware to get some
things done. This is a lot rarer now. I still fire it up for a play
of forest. Noone ever matched that one.
I still work with small stuff. I just got going with the arduino, which
is a very nice piece of hardware. But not as a laptop/desktop. I plan
to deploy a few hundred of them holding sensors to get full 3rdparty
monitoring of a new datacentre. I will have to hack some hardware.
(adding ethernet to all of them, and hooking up sensors)
This is a different ballgame from the desktop.
I have a few scores of raspberrypis and similar machines. They can
barely make do as a desktop. Until you fire up some of the bloatware.
I got the post that a browser is more complicated than USB. But the
code size is 224 times bigger. WTF? (usb part of linux kernel vs
chromium, measured by wc -l on the source tree).
It isn't bloat because it is bigger than 64k.
-- mrr
|
|
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311919 is a reply to message #311872] |
Sun, 14 February 2016 10:19 |
jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Michael Black wrote:
> On Sat, 13 Feb 2016, Lawrence Statton wrote:
>
>> Morten Reistad <first@last.name.invalid> writes:
>>> Emacs use around 8, which is way big enough for me.
>>>
>>
>> I find it midly amusing that Emacs, which was belitted by its detractors
>> for consuming "eight megs and constantly swapping" -- now that numbered
>> is considered downright miserly with memory ...
>>
> Especially when it does everything, including the kitchen sink.
and toasters?
/BAH
|
|
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311922 is a reply to message #311868] |
Sun, 14 February 2016 10:42 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Lawrence Statton <lawrence@senguio.mx> writes:
> Morten Reistad <first@last.name.invalid> writes:
>> Emacs use around 8, which is way big enough for me.
>>
>
> I find it midly amusing that Emacs, which was belitted by its detractors
> for consuming "eight megs and constantly swapping" -- now that numbered
> is considered downright miserly with memory ...
>
> --NK1G
Emacs up for over a month:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1507 dane 20 0 1503780 97920 11232 S 0.0 4.8 23:46.08 emacs
--
Dan Espen
|
|
|
|
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311935 is a reply to message #311919] |
Sun, 14 February 2016 11:51 |
Michael Black
Messages: 2799
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 14 Feb 2016, jmfbahciv wrote:
> Michael Black wrote:
>> On Sat, 13 Feb 2016, Lawrence Statton wrote:
>>
>>> Morten Reistad <first@last.name.invalid> writes:
>>>> Emacs use around 8, which is way big enough for me.
>>>>
>>>
>>> I find it midly amusing that Emacs, which was belitted by its detractors
>>> for consuming "eight megs and constantly swapping" -- now that numbered
>>> is considered downright miserly with memory ...
>>>
>> Especially when it does everything, including the kitchen sink.
>
> and toasters?
>
If you want it to be a toaster, then yes.
Michael
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311946 is a reply to message #311919] |
Sun, 14 February 2016 14:09 |
|
|
Originally posted by: JimP
On 14 Feb 2016 15:19:53 GMT, jmfbahciv <See.above@aol.com> wrote:
> Michael Black wrote:
>> On Sat, 13 Feb 2016, Lawrence Statton wrote:
>>
>>> Morten Reistad <first@last.name.invalid> writes:
>>>> Emacs use around 8, which is way big enough for me.
>>>>
>>>
>>> I find it midly amusing that Emacs, which was belitted by its detractors
>>> for consuming "eight megs and constantly swapping" -- now that numbered
>>> is considered downright miserly with memory ...
>>>
>> Especially when it does everything, including the kitchen sink.
>
> and toasters?
>
> /BAH
As long as it was an Amiga Toaster... :-)
--
JimP.
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311959 is a reply to message #311922] |
Sun, 14 February 2016 15:36 |
|
|
Originally posted by: mrr
In article <n9q73s$b4c$2@dont-email.me>, Dan Espen <despen@verizon.net> wrote:
> Lawrence Statton <lawrence@senguio.mx> writes:
>
>> Morten Reistad <first@last.name.invalid> writes:
>>> Emacs use around 8, which is way big enough for me.
>>>
>>
>> I find it midly amusing that Emacs, which was belitted by its detractors
>> for consuming "eight megs and constantly swapping" -- now that numbered
>> is considered downright miserly with memory ...
>>
>> --NK1G
>
> Emacs up for over a month:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 1507 dane 20 0 1503780 97920 11232 S 0.0 4.8 23:46.08 emacs
Emacs up for 10 seconds :
14200 mrr 20 0 10456 6588 3588 S 0.0 0.3 0:00.30 emacs
Free memory went down by slightly more than 8 meg when I started it, so
a little more than half of the shared space is for emacs alone.
-- mrr
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311984 is a reply to message #311901] |
Sun, 14 February 2016 20:35 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Sunday, February 14, 2016 at 2:49:27 AM UTC-5, gareth wrote:
>> Hah! I was brought up on a 32K 360/30, and I imagine many here would
>> think
>> that was extragavant.
>
> 32K words, or bytes?
>
> Actually the first PDP11/20 I used had 16K bytes
On a System/360 et al, it's in bytes, which were 8 bits.
On older IBM machines, the size varied. On the 1401 series, it was
in characters, which were 6 + 1 bits long (the one bit being a word mark).
IIRC, the low end 1401 had only 1,400 characters, although that machine
was intended basically as a 'souped-up' tabulator.
On the 709x series, a word machine, I think a word was 36 bits long.
I don't know how many alpha characters could be stored in a word, or
what kind of programming was required to handle alpha strings, like
a 20 character address line. Of course, in those days, alpha fields were
often tightly abbreviated, like first initial only, and a street name like
KNICKERBOCKER might be stored as KNCKRBKR. Back then, the post office was
pretty good at dealing with tight abbreviations of long names.
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #311985 is a reply to message #311931] |
Sun, 14 February 2016 20:40 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Sunday, February 14, 2016 at 10:48:13 AM UTC-5, Peter Flass wrote:
> Bytes. The /30 could be bought with 16K, but most software needed more so
> few people bought it that way.
You also needed space for the operating system, which I think at a minimum
took up 8k. On our S/360-40, our DOS took up 14.5k. That did not include
a spooler, a tremendous boost to throughput. In 360-DOS, it was called
"POWER", but I don't recall how much memory that took up. 25K?
|
|
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #312033 is a reply to message #311923] |
Mon, 15 February 2016 16:27 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2016-02-14, Dan Espen <despen@verizon.net> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> gareth <no.spam@thank.you.invalid> wrote:
>>
>>> "Morten Reistad" <first@last.name.invalid> wrote in message
>>> news:o914pc-pd3.ln1@sambook.reistad.name...
>>>
>>> You seem to have been brain-washed or conditioned by the world of bloat,
>>> whereas I was brought up on 16-bit minicomputers (PDP11) with memory
>>> of 56K, so I know how much can be achieved in a small space.
>>
>> Hah! I was brought up on a 32K 360/30, and I imagine many here would think
>> that was extragavant.
>
> Of course.
> Lots of fun on a 1.4K 1401.
>
> But software should be written to current hardware levels.
I agree, to an extent. Certainly more powerful hardware makes different
algorithms feasible and can result in more functionality. On the other
tentacle, my old makefiles and compilers run like lightning on my new box.
That's another form of "more functionality" - one that I won't give up
for any fancy IDE.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #312041 is a reply to message #311872] |
Mon, 15 February 2016 18:58 |
Charles Richmond
Messages: 2754
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
"Michael Black" <et472@ncf.ca> wrote in message
news:alpine.LNX.2.02.1602132219260.15268@darkstar.example.org...
> On Sat, 13 Feb 2016, Lawrence Statton wrote:
>
>> Morten Reistad <first@last.name.invalid> writes:
>>> Emacs use around 8, which is way big enough for me.
>>>
>>
>> I find it midly amusing that Emacs, which was belitted by its detractors
>> for consuming "eight megs and constantly swapping" -- now that numbered
>> is considered downright miserly with memory ...
>>
> Especially when it does everything, including the kitchen sink.
>
If you like Emacs, you will love Perl. In Perl, there are at least 47 ways
to do anything. Well, it seems that way...
--
numerist at aquaporin4 dot com
|
|
|
|
| Re: 64 bit CPU, QBasic and DOS? [message #312042 is a reply to message #311935] |
Mon, 15 February 2016 19:00 |
Charles Richmond
Messages: 2754
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
"Michael Black" <et472@ncf.ca> wrote in message
news:alpine.LNX.2.02.1602141151260.17104@darkstar.example.org...
> On Sun, 14 Feb 2016, jmfbahciv wrote:
>
>> Michael Black wrote:
>>> On Sat, 13 Feb 2016, Lawrence Statton wrote:
>>>
>>>> Morten Reistad <first@last.name.invalid> writes:
>>>> > Emacs use around 8, which is way big enough for me.
>>>> >
>>>>
>>>> I find it midly amusing that Emacs, which was belitted by its
>>>> detractors
>>>> for consuming "eight megs and constantly swapping" -- now that numbered
>>>> is considered downright miserly with memory ...
>>>>
>>> Especially when it does everything, including the kitchen sink.
>>
>> and toasters?
>>
> If you want it to be a toaster, then yes.
>
Emacs does *not* stop with toast! It spreads the marmalade and makes the
coffee!!!
--
numerist at aquaporin4 dot com
|
|
|
|
|
|
Members
Search
Help
Register
Login
Home
