Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #159225 > unrolled thread
| Started by | "gareth" <no.spam@thank.you.invalid> |
|---|---|
| First post | 2016-02-13 12:22 +0000 |
| Last post | 2016-02-13 08:47 -0800 |
| Articles | 20 on this page of 82 — 24 participants |
Back to article view | Back to alt.folklore.computers
64 bit CPU, QBasic and DOS? "gareth" <no.spam@thank.you.invalid> - 2016-02-13 12:22 +0000
Re: 64 bit CPU, QBasic and DOS? philo <philo@privacy.net> - 2016-02-13 07:29 -0600
Re: 64 bit CPU, QBasic and DOS? Peter Flass <peter_flass@yahoo.com> - 2016-02-13 07:43 -0700
Re: 64 bit CPU, QBasic and DOS? Morten Reistad <first@last.name.invalid> - 2016-02-13 17:13 +0100
Re: 64 bit CPU, QBasic and DOS? "gareth" <no.spam@thank.you.invalid> - 2016-02-13 17:18 +0000
Re: 64 bit CPU, QBasic and DOS? Melzzzzz <mel@zzzzz.com> - 2016-02-13 18:29 +0100
Re: 64 bit CPU, QBasic and DOS? Peter Flass <peter_flass@yahoo.com> - 2016-02-13 17:31 -0700
Re: 64 bit CPU, QBasic and DOS? Morten Reistad <first@last.name.invalid> - 2016-02-13 23:51 +0100
Re: 64 bit CPU, QBasic and DOS? roger.ivie@gmail.com - 2016-02-13 15:52 -0800
Re: 64 bit CPU, QBasic and DOS? Peter Flass <peter_flass@yahoo.com> - 2016-02-13 17:31 -0700
Re: 64 bit CPU, QBasic and DOS? Lawrence Statton <lawrence@senguio.mx> - 2016-02-13 20:51 -0600
Re: 64 bit CPU, QBasic and DOS? Michael Black <et472@ncf.ca> - 2016-02-13 22:19 -0500
Re: 64 bit CPU, QBasic and DOS? jmfbahciv <See.above@aol.com> - 2016-02-14 15:19 +0000
Re: 64 bit CPU, QBasic and DOS? Michael Black <et472@ncf.ca> - 2016-02-14 11:51 -0500
Re: 64 bit CPU, QBasic and DOS? "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-15 18:00 -0600
Re: 64 bit CPU, QBasic and DOS? JimP <solosam90@gmail.com> - 2016-02-14 13:09 -0600
Re: 64 bit CPU, QBasic and DOS? "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-15 17:58 -0600
Re: 64 bit CPU, QBasic and DOS? Huge <Huge@nowhere.much.invalid> - 2016-02-16 09:00 +0000
Re: 64 bit CPU, QBasic and DOS? Dan Espen <despen@verizon.net> - 2016-02-14 10:42 -0500
Re: 64 bit CPU, QBasic and DOS? mrr@sambook.reistad.name (Morten Reistad) - 2016-02-14 21:36 +0100
Re: 64 bit CPU, QBasic and DOS? Stephen Sprunk <stephen@sprunk.org> - 2016-02-13 20:54 -0600
Re: 64 bit CPU, QBasic and DOS? "gareth" <no.spam@thank.you.invalid> - 2016-02-14 07:47 +0000
Re: 64 bit CPU, QBasic and DOS? Peter Flass <peter_flass@yahoo.com> - 2016-02-13 17:31 -0700
Re: 64 bit CPU, QBasic and DOS? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-14 01:01 +0000
Re: 64 bit CPU, QBasic and DOS? "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-15 18:04 -0600
Re: 64 bit CPU, QBasic and DOS? Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 18:20 -0800
Re: 64 bit CPU, QBasic and DOS? hancock4@bbs.cpcn.com - 2016-02-13 18:48 -0800
Re: 64 bit CPU, QBasic and DOS? Walter Bushell <proto@panix.com> - 2016-02-16 09:32 -0500
Re: 64 bit CPU, QBasic and DOS? Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-16 15:58 +0000
Re: 64 bit CPU, QBasic and DOS? Morten Reistad <first@last.name.invalid> - 2016-02-16 18:04 +0100
Re: 64 bit CPU, QBasic and DOS? hancock4@bbs.cpcn.com - 2016-02-16 10:03 -0800
Re: 64 bit CPU, QBasic and DOS? "hgww" <hgww@gmail.com> - 2016-02-17 14:09 +1100
Re: 64 bit CPU, QBasic and DOS? Quadibloc <jsavard@ecn.ab.ca> - 2016-02-19 06:34 -0800
Re: 64 bit CPU, QBasic and DOS? "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-16 15:14 -0600
Re: 64 bit CPU, QBasic and DOS? hancock4@bbs.cpcn.com - 2016-02-13 18:49 -0800
Re: 64 bit CPU, QBasic and DOS? "gareth" <no.spam@thank.you.invalid> - 2016-02-14 07:49 +0000
Re: 64 bit CPU, QBasic and DOS? "hgww" <hgww@gmail.com> - 2016-02-14 19:20 +1100
Re: 64 bit CPU, QBasic and DOS? "gareth" <no.spam@thank.you.invalid> - 2016-02-14 14:47 +0000
Re: 64 bit CPU, QBasic and DOS? jmfbahciv <See.above@aol.com> - 2016-02-15 14:10 +0000
Re: 64 bit CPU, QBasic and DOS? Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: 64 bit CPU, QBasic and DOS? hancock4@bbs.cpcn.com - 2016-02-14 17:40 -0800
Re: 64 bit CPU, QBasic and DOS? Peter Flass <peter_flass@yahoo.com> - 2016-02-17 06:56 -0700
Re: 64 bit CPU, QBasic and DOS? hancock4@bbs.cpcn.com - 2016-02-17 20:56 -0800
Re: 64 bit CPU, QBasic and DOS? David Wade <dave.g4ugm@gmail.com> - 2016-02-18 09:48 +0000
Re: 64 bit CPU, QBasic and DOS? "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-18 11:55 -0600
Re: 64 bit CPU, QBasic and DOS? "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-18 11:51 -0600
Re: 64 bit CPU, QBasic and DOS? Huge <Huge@nowhere.much.invalid> - 2016-02-19 09:47 +0000
Re: 64 bit CPU, QBasic and DOS? Peter Flass <peter_flass@yahoo.com> - 2016-02-19 06:54 -0700
Re: 64 bit CPU, QBasic and DOS? Quadibloc <jsavard@ecn.ab.ca> - 2016-02-19 06:36 -0800
Re: 64 bit CPU, QBasic and DOS? Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-19 15:13 +0000
Re: 64 bit CPU, QBasic and DOS? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-19 19:48 +0000
Re: 64 bit CPU, QBasic and DOS? "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-19 20:39 -0600
Re: 64 bit CPU, QBasic and DOS? "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-19 20:38 -0600
Re: 64 bit CPU, QBasic and DOS? Huge <Huge@nowhere.much.invalid> - 2016-02-20 09:47 +0000
Re: 64 bit CPU, QBasic and DOS? "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-19 20:35 -0600
Re: 64 bit CPU, QBasic and DOS? "gareth" <no.spam@thank.you.invalid> - 2016-02-20 11:12 +0000
Re: 64 bit CPU, QBasic and DOS? Peter Flass <peter_flass@yahoo.com> - 2016-02-20 07:30 -0700
Re: 64 bit CPU, QBasic and DOS? "Osmium" <r124c4u102@comcast.net> - 2016-02-20 09:37 -0600
Re: 64 bit CPU, QBasic and DOS? JimP <solosam90@gmail.com> - 2016-02-20 10:46 -0600
Re: 64 bit CPU, QBasic and DOS? "hgww" <hgww@gmail.com> - 2016-02-21 04:22 +1100
Re: 64 bit CPU, QBasic and DOS? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-20 19:56 +0000
Re: 64 bit CPU, QBasic and DOS? "gareth" <no.spam@thank.you.invalid> - 2016-02-20 23:02 +0000
Re: 64 bit CPU, QBasic and DOS? "hgww" <hgww@gmail.com> - 2016-02-21 04:02 +1100
Re: 64 bit CPU, QBasic and DOS? hancock4@bbs.cpcn.com - 2016-02-20 12:34 -0800
Re: 64 bit CPU, QBasic and DOS? hancock4@bbs.cpcn.com - 2016-02-14 17:35 -0800
Re: 64 bit CPU, QBasic and DOS? Huge <Huge@nowhere.much.invalid> - 2016-02-14 09:01 +0000
Re: 64 bit CPU, QBasic and DOS? Morten Reistad <first@last.name.invalid> - 2016-02-14 10:49 +0100
Re: 64 bit CPU, QBasic and DOS? Huge <Huge@nowhere.much.invalid> - 2016-02-14 16:24 +0000
Re: 64 bit CPU, QBasic and DOS? jmfbahciv <See.above@aol.com> - 2016-02-14 15:19 +0000
Re: 64 bit CPU, QBasic and DOS? Dan Espen <despen@verizon.net> - 2016-02-14 10:45 -0500
Re: 64 bit CPU, QBasic and DOS? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-15 21:27 +0000
Re: 64 bit CPU, QBasic and DOS? Dan Espen <despen@verizon.net> - 2016-02-15 23:50 -0500
Re: 64 bit CPU, QBasic and DOS? Morten Reistad <first@last.name.invalid> - 2016-02-16 00:40 +0100
Re: 64 bit CPU, QBasic and DOS? hancock4@bbs.cpcn.com - 2016-02-16 09:58 -0800
Re: 64 bit CPU, QBasic and DOS? Dan Espen <despen@verizon.net> - 2016-02-16 13:54 -0500
Re: 64 bit CPU, QBasic and DOS? Peter Flass <peter_flass@yahoo.com> - 2016-02-17 06:56 -0700
Re: 64 bit CPU, QBasic and DOS? "hgww" <hgww@gmail.com> - 2016-02-17 14:05 +1100
Re: 64 bit CPU, QBasic and DOS? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-14 00:53 +0000
Re: 64 bit CPU, QBasic and DOS? scott@slp53.sl.home (Scott Lurndal) - 2016-02-16 16:11 +0000
Re: 64 bit CPU, QBasic and DOS? "gareth" <no.spam@thank.you.invalid> - 2016-02-16 17:04 +0000
Re: 64 bit CPU, QBasic and DOS? Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-16 17:44 +0000
Re: 64 bit CPU, QBasic and DOS? roger.ivie@gmail.com - 2016-02-13 08:47 -0800
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | "gareth" <no.spam@thank.you.invalid> |
|---|---|
| Date | 2016-02-13 12:22 +0000 |
| Subject | 64 bit CPU, QBasic and DOS? |
| Message-ID | <n9n71i$j1f$1@dont-email.me> |
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 !!!! )
[toc] | [next] | [standalone]
| From | philo <philo@privacy.net> |
|---|---|
| Date | 2016-02-13 07:29 -0600 |
| Message-ID | <n9nauh$kt$1@dont-email.me> |
| In reply to | #159225 |
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
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-02-13 07:43 -0700 |
| Message-ID | <636909245.477067287.752352.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #159225 |
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
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name.invalid> |
|---|---|
| Date | 2016-02-13 17:13 +0100 |
| Message-ID | <o914pc-pd3.ln1@sambook.reistad.name> |
| In reply to | #159225 |
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
[toc] | [prev] | [next] | [standalone]
| From | "gareth" <no.spam@thank.you.invalid> |
|---|---|
| Date | 2016-02-13 17:18 +0000 |
| Message-ID | <n9nobn$kl0$1@dont-email.me> |
| In reply to | #159234 |
"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
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-02-13 18:29 +0100 |
| Message-ID | <20160213182950.689ff7c5@maxa-pc> |
| In reply to | #159240 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-02-13 17:31 -0700 |
| Message-ID | <1046630780.477102514.917627.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #159242 |
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
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name.invalid> |
|---|---|
| Date | 2016-02-13 23:51 +0100 |
| Message-ID | <8lo4pc-s45.ln1@sambook.reistad.name> |
| In reply to | #159240 |
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 > >
[toc] | [prev] | [next] | [standalone]
| From | roger.ivie@gmail.com |
|---|---|
| Date | 2016-02-13 15:52 -0800 |
| Message-ID | <11e50536-5217-4bbf-9f25-965d6830d55a@googlegroups.com> |
| In reply to | #159282 |
On Saturday, February 13, 2016 at 2:56:08 PM UTC-8, Morten Reistad wrote: > 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. MicroEMACS for CP/M-ARM takes about 12K. Just sayin' -- roger ivie roger.ivie@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-02-13 17:31 -0700 |
| Message-ID | <1062643734.477102626.425837.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #159282 |
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
[toc] | [prev] | [next] | [standalone]
| From | Lawrence Statton <lawrence@senguio.mx> |
|---|---|
| Date | 2016-02-13 20:51 -0600 |
| Message-ID | <87pow0huma.fsf@redbull.i-did-not-set--mail-host-address--so-tickle-me> |
| In reply to | #159282 |
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
[toc] | [prev] | [next] | [standalone]
| From | Michael Black <et472@ncf.ca> |
|---|---|
| Date | 2016-02-13 22:19 -0500 |
| Message-ID | <alpine.LNX.2.02.1602132219260.15268@darkstar.example.org> |
| In reply to | #159308 |
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
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-02-14 15:19 +0000 |
| Message-ID | <PM00052BBC77E8DCC5@aca446d4.ipt.aol.com> |
| In reply to | #159312 |
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
[toc] | [prev] | [next] | [standalone]
| From | Michael Black <et472@ncf.ca> |
|---|---|
| Date | 2016-02-14 11:51 -0500 |
| Message-ID | <alpine.LNX.2.02.1602141151260.17104@darkstar.example.org> |
| In reply to | #159348 |
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
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2016-02-15 18:00 -0600 |
| Message-ID | <n9tol6$7jp$1@dont-email.me> |
| In reply to | #159365 |
"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
[toc] | [prev] | [next] | [standalone]
| From | JimP <solosam90@gmail.com> |
|---|---|
| Date | 2016-02-14 13:09 -0600 |
| Message-ID | <66k1cbh7elrl1fde0c6d4j2qnj84ngh493@4ax.com> |
| In reply to | #159348 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2016-02-15 17:58 -0600 |
| Message-ID | <n9toih$77v$1@dont-email.me> |
| In reply to | #159312 |
"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
[toc] | [prev] | [next] | [standalone]
| From | Huge <Huge@nowhere.much.invalid> |
|---|---|
| Date | 2016-02-16 09:00 +0000 |
| Message-ID | <dig6ojFjsiqU2@mid.individual.net> |
| In reply to | #159455 |
On 2016-02-15, Charles Richmond <numerist@aquaporin4.com> wrote:
> "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...
"There's More Than One Way To Do It" is a perl adage.
--
I don't have an attitude problem. If you have a problem with my
attitude, that's your problem.
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2016-02-14 10:42 -0500 |
| Message-ID | <n9q73s$b4c$2@dont-email.me> |
| In reply to | #159308 |
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
[toc] | [prev] | [next] | [standalone]
| From | mrr@sambook.reistad.name (Morten Reistad) |
|---|---|
| Date | 2016-02-14 21:36 +0100 |
| Message-ID | <h257pc-r3f.ln1@sambook.reistad.name> |
| In reply to | #159350 |
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
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web