Sammy, I am beginning to come around to your way of thinking

Sammy wrote:

> I find it amusing that you think ALL software is so poorly written
> though. What software have you written lately?

Don't think he said that to be fair. There is a lot of poorly written
code. What has changed is that with the advent of more readily availble
memory/hardware has come the RAD tools.

This means that software is written quite quickly, and prototypes are
written in days rather than months. This it's good and bad points

Coming from a development background, having started a little with 6502
and then moving to C and GEM; I find VB .NET is a breeze these days.

Problem is, if you are not careful, RAD leads to programmers being lazy.
Error trapping for one! How many VB programmers lazily let their app
just crash with an error!
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

On Jun 3, 12:17 pm, Mxsmanic <mxsma... DeleteThis @gmail.com> wrote:
> IPv4 is in danger not because there are literally 4+ billion computers
> connected to the Net, but because the address space has been exponentially
> eroded by linear allocation of the address field bits. Exactly the same thing
> will happen with IPv6 (it is _already_ happening), meaning that IPv6 will
> perhaps last four times as long as IPv4, instead of 2^96 times as long.

You're using vague terms which confuse how an address space is divided
into subspaces with how it is allocated for each object. IPv4 has been
subdivided bu design in a way that means you can't use all the
addresses for one type of allocation. That doesn't mean as your words
implied that as you allocate more objects an exponential amount of
memory is used. At the very least you were being unclear.

IPv4 addressing is not the same as x86 memory architecture. You can
indeed address a 4Gb virtual memory space:
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx

"Operating systems based on Microsoft Windows NT technologies have
always provided applications with a flat 32-bit virtual address space
that describes 4 gigabytes (GB) of virtual memory."

What about 64 bit? Try here
http://www-03.ibm.com/servers/intellistation/pro/x64/faqs.html
Q7: What benefits does Windows x64 Edition offer over 32-bit Windows
for workstation applications?
A7: Applications running on 32-bit Windows have a maximum memory
capability of 4GB, and in some circumstances only 3GB can be addressed
by applications. In contrast, IntelliStation Pro 64-bit enabled
workstations can address up to 16TB of virtual memory, to handle the
voluminous datasets of modern technical applications. In addition,
large memory addressability benefits today's multitasking workflow,
with multiple complementary applications open on multiple monitors.

I really don't know what else I can do or say to debunk the rubbish
you're spouting so I'm through trying. You and anyone else who
subscribes to your bunk can just live in ignorance and that's fine
with me.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

Mike Young wrote:

> Where do you even begin trying to make use, or even sense, of something
> that size? The simplest, most elementary approach is to carve it up,
> much as they did the 32-bit IPv4 address space. The scale is different,
> of course. But at some point, somebody will look back and gawk and
> wonder at the waste. For example, loopback is an entire class-A, just so
> we can refer to localhost as 127.0.0.1. I'm sure it looked like an
> empty, unfillable wasteland at some point in the past. Just as we today
> might look at 18 billion billions as inconceivably huge and unfillable.

Not sure how we got onto IPv4 when we were talking about 64bit, because
as we know this will (or should be) replaced with IPv6 which will
actually by 128bit.

Mind you going to have to rely on DNS then for sure, anyone fancy trying
to remember their router address is we all had our own IP address - in
fact IPv6 would mean every person and machine in the world coule have
it's own IP address - and still not touch the surface:

Just so you can get used to it:

Fancy this new IP address: 2007:0db8:0001:0001:0001:0001:1428:57ab


 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

Mike Young wrote:

> I'm making it up as I go. How does it sound so far?

What you say makes perfect sense. If we have space to fill, we sure as
hell will find a way to fill it. Might take us a while at 64bit, but
then we could just simply move to 128bit

Mind you, I have lost track to how we got here

I need a proper treaded NG reader - or maybe not
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

On Jun 3, 10:33 am, "Mike Young" <boat042-s... DeleteThis @yahoo.com> wrote:
> The question isn't how the programmer will use it, linearly or
> exponentially. I don't even know where to begin thinking in those terms.
> That's probably where you're drifting, also. Bear with me for a moment for
> the relevance to IP address classes.

Linear and exponential have a very well defined meaning and are being
thrown about without any context here. What do you mean by "use it,
linearly or exponentially"? How does one use memory "exponentially".
You can subdivide the address space but doing so doesn't make it
suddenly get used up exponentially.

> The 64-bit address space is *huge*. What will you do with it? What will an
> application do with it?

Well for starters you might have HUGE data. An uncompressed video file
comes to mind.

> What application programmer can even begin to
> conceive of using even a measurable fraction of it?

I've not regularly had to manipulate large data sets but its not
uncommon for scientific work. For the home user imagine not having to
swap pieces of your 100Mb tiff in and out so you can handle multiple
images simultaneously, or retaining a large undo buffer in graphics
editing software. I already mentioned video. A terrabyte really isn't
as big as people seem to think it is. I have well over a TB on my
computers here at home.

> I work with systems that
> are routinely in danger of exceeding their 2 GB process user virtual space.
> I can make good use of just a bit more headroom. Pun intended. Just one more
> bit doubles my virtual space. What will I do with the other 31 new bits?

I don't know what sort of software you work on, but if it's
transaction processing or you have lots of concurrent users you give
each session a whole address space to play with instead of swapping
them in and out. There's a lot of very memory hungry software out
there. I work with J2EE environments and one limitation you encounter
is a slowdown due to swapping sessions in and out of memory.

> Here's where it would benefit me. At the application level, I don't
> particularly know or care whether an address range is in RAM or paged to
> disk. I care, but the OS will do what it's gonna do regardless. If we extend
> that thought just a little, I really don't particularly *like* manipulating
> files on disk. Wouldn't it be just wonderful if some directory service would
> map what I now think of as "g:\games\fsx\fsx.exe" into my huge, flat address
> space?

What you're describing is a RAM disk and has been around for a very
long time. (You use to use them explicitly in the DOS and win 3.11
days) The trouble at the moment is that RAM is much more expensive
than disk so you have to have a pretty good reason to do this.

> Once you start down this path, there's no end to the familiar abstractions
> that can be made to go away. Applications don't care or really want to know
> about IP addresses and TCP ports. They just want to poke some data to that
> service there, wherever 'there' might be. So these aren't really
> abstractions after all; IP addresses and filenames are implementation
> artifacts.

Again there are differences between local memory to which you can
access very quickly indeed and applications that have to fetch data
across the network. You deal with the situation you're describing
easily enough by abstracting the comms layer of your software so the
application doesn't need to know about it. However the developer still
must be aware of the difference or you end up with horrendously slow
applications fetching across the network.

> A 64-bit address space is usefully large enough that I can begin to think
> about making those artifacts go away. I can begin to abstract them into the
> more familiar and comfortable flat memory space.

....but the architecture allows you to deal with it as flat.

> The question then becomes how will I carve it up?

Unless you're using a low level language you don't worry about this.
You simply allocate and deallocate from a common heap. With most
modern languages you don't manually manage memory because that is very
error prone indeed. C and C++ are still common for games programming
though and there you do have to manual memory management (and hence
you can get memory leaks). Languages like Java try to ellminate this.

> Does it make sense to carve it up? Should we
> allocate some of it to represent local disk storage? How much? What if,
> instead of poking data to a service, I just write it to an address space we
> both share? Even the concept of poking data to a service becomes an
> artifact.

How is this a linear vs exponential problem?

> I'm making it up as I go. How does it sound so far?

See above.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

On Jun 3, 2:26 pm, "C6" <copter.....DeleteThis@xxxgmail.com> wrote:
> I learned something........

Sadly so did I, but it has nothing to do with the grand scale of the
universe or computer memory.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

On Jun 3, 9:38 am, Tilly <nospample....DeleteThis@lancashirechess.org.uk> wrote:
> Problem is, if you are not careful, RAD leads to programmers being lazy.
> Error trapping for one! How many VB programmers lazily let their app
> just crash with an error!

Another common misconception. You can be just as lazy with a non-RAD
environment, it's just that it's a lot harder to get anything done so
if a programmer is successful at building software using the more
complex non-RAD environment, they're also more likely to know how to
trap an error and be disciplined about it. Unfortunately the current
trend I'm seeing has been a movement away from RAD and towards web
applications that are slower and more cumbersome to write. In the mid
to late 90s with a RAD tool I was churning out apps in a couple of
days that now take a week or two to build because you have to hand
code the screens (ie it's not WYSIWYG). However the apps today do
handle failover better and are more scalable. Still I believe we could
have both RAD/WYSIWYG and scalability if we didn't try to force
everything to be a web app. C'est la vie.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

Mike Young writes:

> Here's where it would benefit me. At the application level, I don't
> particularly know or care whether an address range is in RAM or paged to
> disk. I care, but the OS will do what it's gonna do regardless. If we extend
> that thought just a little, I really don't particularly *like* manipulating
> files on disk. Wouldn't it be just wonderful if some directory service would
> map what I now think of as "g:\games\fsx\fsx.exe" into my huge, flat address
> space?
>
> Once you start down this path, there's no end to the familiar abstractions
> that can be made to go away. Applications don't care or really want to know
> about IP addresses and TCP ports. They just want to poke some data to that
> service there, wherever 'there' might be. So these aren't really
> abstractions after all; IP addresses and filenames are implementation
> artifacts.
>
> A 64-bit address space is usefully large enough that I can begin to think
> about making those artifacts go away. I can begin to abstract them into the
> more familiar and comfortable flat memory space. The question then becomes
> how will I carve it up? Does it make sense to carve it up? Should we
> allocate some of it to represent local disk storage? How much? What if,
> instead of poking data to a service, I just write it to an address space we
> both share? Even the concept of poking data to a service becomes an
> artifact.
>
> I'm making it up as I go. How does it sound so far?

Like Multics. DEC was doing it, too, around 40 years ago.

If you assign addresses in strict sequence, you'll never run out. But nobody
ever does that. Instead, they "carve up" the address space, as you say, and
exponentially reduce its size, which means that no matter how large the
address fields are, the address space will be exhausted in nearly linear time,
instead of exponential time. And therein lies the rub.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

Tilly writes:

> Mind you going to have to rely on DNS then for sure, anyone fancy trying
> to remember their router address is we all had our own IP address - in
> fact IPv6 would mean every person and machine in the world coule have
> it's own IP address ...

If they are assigned sequentially.

IPv4 is in danger not because there are literally 4+ billion computers
connected to the Net, but because the address space has been exponentially
eroded by linear allocation of the address field bits. Exactly the same thing
will happen with IPv6 (it is _already_ happening), meaning that IPv6 will
perhaps last four times as long as IPv4, instead of 2^96 times as long.

The same mistake is made over and over and over again.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

On Jun 3, 3:46 pm, "Mike Young" <boat042-s... DeleteThis @yahoo.com> wrote:
> Same example I gave before. Some dummy carved out a whole Class A and
> assigned it to loopback. Is that linear? Stretch a little; you can get
> there.

Yes it's linear. If I cut something up, the pieces don't shrink or
expand. It may not be useful for anything but loopback because the
standards state it is only to be used for loopback, but it doesn't
disappear. It is not correct to speak of the process of cutting up
various sized chunks and allocating them to specific uses as
'exponential'.

The 32 bit address space is not cut up in the same way as the IP
address space is.

But truly at this point I no longer care. In the last week I've had
plenty to deal with on a personal level and no longer wish to give
this discussion any more time.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

"Sammy" <syousef DeleteThis @bigpond.net.au> wrote in message
news:1180819425.447464.321640@a26g2000pre.googlegroups.com...
> Have a look here if you want some actual information about IPv4.
> http://en.wikipedia.org/wiki/IPv4

I know quite a bit about IPv4. We don't really want to compare resumes.

>
> The words exponential and linear have very definite precise scientific
> meanings. It really doesn't matter how large an address space or how
> you carve it up and if you ask a programmer if they expect memory use
> to be linear or exponential, and GOOD one will tell you its a linear
> process.
>
> Also note that network addresses are NOT the same thing as memory
> addressing and there are differences you have to consider. Without
> actually establshing boundaries for what way they are the same it's
> like saying horses are like cars and expecting people to understand in
> what way. Yeah both can be used to carry people but you don't want to
> take a horse to a petrol station and fill it with unleaded.

I didn't really intend to get drawn into this, but it looks like my foot got
stuck.

The question isn't how the programmer will use it, linearly or
exponentially. I don't even know where to begin thinking in those terms.
That's probably where you're drifting, also. Bear with me for a moment for
the relevance to IP address classes.

The 64-bit address space is *huge*. What will you do with it? What will an
application do with it? What application programmer can even begin to
conceive of using even a measurable fraction of it? I work with systems that
are routinely in danger of exceeding their 2 GB process user virtual space.
I can make good use of just a bit more headroom. Pun intended. Just one more
bit doubles my virtual space. What will I do with the other 31 new bits?

Here's where it would benefit me. At the application level, I don't
particularly know or care whether an address range is in RAM or paged to
disk. I care, but the OS will do what it's gonna do regardless. If we extend
that thought just a little, I really don't particularly *like* manipulating
files on disk. Wouldn't it be just wonderful if some directory service would
map what I now think of as "g:\games\fsx\fsx.exe" into my huge, flat address
space?

Once you start down this path, there's no end to the familiar abstractions
that can be made to go away. Applications don't care or really want to know
about IP addresses and TCP ports. They just want to poke some data to that
service there, wherever 'there' might be. So these aren't really
abstractions after all; IP addresses and filenames are implementation
artifacts.

A 64-bit address space is usefully large enough that I can begin to think
about making those artifacts go away. I can begin to abstract them into the
more familiar and comfortable flat memory space. The question then becomes
how will I carve it up? Does it make sense to carve it up? Should we
allocate some of it to represent local disk storage? How much? What if,
instead of poking data to a service, I just write it to an address space we
both share? Even the concept of poking data to a service becomes an
artifact.

I'm making it up as I go. How does it sound so far?
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

Mxsmanic wrote:

> time to time, when you stridently claim to be right and vituperate anyone with
**********
Bally Hell, that's a word you do not see often

Of course, you could have simply used vilfied, but what the eck get's
everyone looking into the dictionary! Certainly one to remember for
scrabble!
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

This message is not archived
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking