After you have solved the problem with ip-addresses, network masks, etc, you might also consider handling bandwidth hogs. Some PHB is bound to download as much as he can. Maybe you can use traffic shaping to limit each single PCs bandwidth to a certain ratio of the upstream bandwidth (depending on the number active PCs).
The hotel might also want to bill per megabyte download or per day. I seem to recall that you can get statistics out of ipchains.
The most important downside is that some people think that STL is the holy grail. Not so. There is
no silver bullet.
The abstraction level can also be a problem sometimes allthough this is not a problem only with STL. For instance a colleage of mine had to spend much time tracking down why 1 million elements of 48bytes each consumed 144MB. I have also seen the usual problem with someone testing if a list was empty by using size()
Another downside is that the STL is a forced standard meaning that the standard was set before the compilers were able to fullfill it. It has gotten a lot better but you can still encounter limitations in all compilers.
Non-obvious limitations is also a downside. The STL has a very clean design which (unintededly) leads to a few strange limitations, such as const_interators not having a != operator
Sometimes programs using STL is harder to debug. It is not exactly pleasant to have a core dump deep inside template-template-template.....RBtree, spending some time figuring out what that is and after a few hours discover that the problem was not the container at all but something that had scribbled on a reference-copied string:-(
The STl is subject to the usual problems with "Quality of implementation". The standard is set but the implementation has been left (third-party) vendors. Why didn't the Standard Committee provide a public-domain reference implementation which vendors could optimize?
Finally, the STL some places show signs of "Design by committe". This can lead to overly complex designs or no design at all (if the committee cannot agree). Do we really need generic character support in basic_string? Which kind of bastard is auto_ptr? Where is the hash_map?
This is not a rant. I use STL frequently. STL has a lot of advantages but the poster only asked for downsides. You just have to keep in mind that there is no silver bullet.
I agree that most people are..ahem.. narrow-minded and only interested in local stuff. I happen to read foreign newspapers and watch foreign tv channels whenever possible (and read international websites too). Mostly because it is relevant for my work but also because I am interested.
The thing I have learnt is that there are nice people all over the world. There is also morons all over the world.
Personally, I feel that tolerance has increased during the last 20 years partly due to international TV and the internet. Without international TV and internet I think if would be much easier to believe in the stereotypes of your neighbouring contries. So on a small scale it works.
On a larger scale you also become aware of something which cannot be tolerated in other parts of the world. Eg. Faked elections, no human rights, unbalanced distribution on wealth, etc.
My conclusion is that the "global village" are making us more tolerant. But also more aware. And the media likes head lines like "Election scam in Albonia" instead of "Germans are just like us!"
If your competitor optimizes his software and it makes it faster than yours, your customers will stop blaming the hardware and start blaming your software. That is your incentive - unless you compete in features.
Considering that x86-programs that use 64-bit MMX registers is not called "64-bit programs" but "32 bit programs", saying that you can run 31-bit programs on the z/Series is technically correct.
And of course nobody will image mapping this storage as a single drive (via SAN/Raid/...). Ooops I just imagined it:-)
Mapping a harddrive as memory when using a 64-bit CPU could be interesting. But don't think that it will always work.
IIRC that Multics used memory-mapped files exclusively and it was one of the things that Unix left out. It is an interesting concept but has it limits: (a) You need byte-sized granularity on order to keep track of what the size of the file is. (b) You need sector-sized granularity for tracking changed sectors. The latter does not scale well.
I have encountered errors with the built-in test with -e tests, eg::
[ -e file.foo ] && something
The problem is really hard to reproduce. It has occurred on both the bash delivered with Solaris 8 and HPUX 11i, but not under Linux. Strange.
> the vendor compilers are CONSIDERABLY faster than gcc
Not always. Last time I checked Sun's Workshop compiler wer about twice as slow as gcc. gcc was far better at allocating registers while Workshop was better at inlining functions.
non-fiction: That is a very interesting question. Most non-fiction books become obsolete. It would have to be some kind of philosopher or a topic which does not change. Maybe Steven Hawkings...
Fiction:
Arthur C. Clarke (I have read some of his oldest books, and chancer are that someone will read them 50 years in the future too)
Barbara Cartland: Based on the quantity of books she has written it will take more than 50 years to get rid of them:-)
And I guess someone will be reading the book by Leopold Sacher Masoch.
A very good idea!
I just realized what the otherwise useless CapsLock key could be used for. Imagine typing in a window. When you want to see something behind the window you just depress capslock, and the window goes 90% transparent. When done viewing, release capslock, and the window returns to solid.
Hmm.. Maybe I should start hacking KDE/Gnome/whatever:-)
DIAMETER has neared completion for the last two years:-) "real soon now". I have no knowledge of decent DIAMETER servers (performance, setup, flexibility)
If he is not going proxy requests DIAMETER offers very little over RADIUS. There are tons of RADIUS servers - both free and commercial, both closed-source and open-source.
If he is going to use a open-source server thingy then it should be easy to adapt to a DIAMETER when/if he wants to.
Overview from IBM's website
on
IBM Launches p690
·
· Score: 3, Informative
I grabbed this from IBM's website (http://www-1.ibm.com/servers/eserver/pseries/hard ware/datactr/p690.html):
- Innovative, mainframe-inspired, datacenter-class UNIX
server.
- 8- to 32-way 64 bit SMP server utilizing the first ever
POWER4 dual processor on a chip which uses IBM advanced
silicon-on-insulator (SOI) copper technology.
- Up to 256GB of memory, 160 PCI slots and over 4.6TB of
internal storage.
- Supports up to 16 logical partitions (LPAR), helping to
consolidate workloads, reduce footprints and lower cost of
ownership.
- A dedicated Hardware Management Console that provides a
graphical user interface for configuring and operating the
system including a set of functions for managing LPAR
configurations
- State-of-the-art self-managing capabilities that improve
reliability, availability and serviceability (RAS) and help lower
costs.
- Packaging in a new 24-inch rack with an integrated power
subsystem which accommodates a pSeries 690 system and up
to four I/O drawers.
- AIX clustering and future to attach to SP systems.
It looks very good. I just wonder what you would use 160 PCI slots for?
I have been seeing the timed-out requests since August 1st. Exactly August 1st. The number of 408's in my http log increased slowly from 1-2 per day to 30 around August 20th and then slowly decreasing to 1 - until today, where I so far have seen 130 timed out requests. My system is in the range 212.242.x.x, and most of the requests comes from 212.x.x.x but not all.
You are right that it depends a lot on how you implement it.
If the RAM delivers data in serial manner (on bit at a time in one wire), faster RAM would definetely cause problems because the CPU would not know how to distinguish the individual bits... unless the RAM chip generates a clock on a separate wire, which some RAM chips do.
On the other hand if the data bus is e.g. 33 wires = 32 data wires and one "handshake" wire, the protocol between the CPU and the RAM chip could be:
CPU -> "give me the contents of address 0x38762A63"
CPU then waits for the handshake wire to go high
The RAM chip sees the address, puts the contents on the data wires, and then sets the handshake wire high.
And the the CPU can read the data.
The above asynchronous protocol does not depend on the speed of the RAM chip. The RAM chip could be a future high-speed "zero-latency" chip, or a slow flash-ram chip. The CPU does not need to know.
There are problems with this too. The protocol is sort of request-reply / step-lock. And how do multiple devices share the same bus. And and and...
Noone said it was easy:-)
The article is very interesting. I though that research in asynchronous computing died in the sixties. What the article misses is that async. operations has an overhead too - the synchronization "here is the data". Synchronous computing does not have that.
I have previously read (forgotten where) that in theory async. computers will always be slower that sync. computers. It seems that that is not true anymore. I guess that the latests-and-greatest CPUs have a non-trivial percentage of idle time for instructions which takes slightly longer than an integral number of clock ticks. If an instruction takes 2.1ns and the clock runs at 1ns, everything have to assume that the instruction takes 3ns.
Also imagine a fully async. computer. No need for a new motherboard or even changing settings in the BIOS when new and faster RAM chips are available - the system will automatically adapt.
I think that we will see more and more async. parts in the year to come. But I don't know if everything is going to be asynchronous.
That is my experience too. Some uninformed managers think that because WindowsNT/2000 has a familiar user interface it is easier to manage and can be done by less competent adminstrators (or even themselves:-)
Let's face it: The major factor is the system administrator. If he/she is competent the system TCO will go down. If he/she is incompetent the TCO will go up.
Good system administators are lazy and try to automate everything so they don't have to work. *nix systems are better at that than Windows (or OS/2, DOS for that matter)
I jumped at IBMs offer for developers to try out Linux running on a z/Architecure thingy. My experience so far has been pleasant and "boring" (in a positive way). Pleasant because everything ported easily. Boring because I was expecting challenging porting problems. Everything worked.
Now for the article about TCO and stuff... I believe that it is correct. For small installations use cheap hardware to bring down initial costs. But don't be afraid of mainframes when you business grows - they are not that different.
For developers:
"Modern Operating Systems" by Andrew Tanenbaum.
"Prototyping" by Roland Vonk.
For end-users the choice is more difficult because they will probably need some less abstract, resulting in books on contemporary applications and technologies. But I recall a book called "What computers can't do" which should be general.
I see a lot of people whining about the source is not really open. That is true. There are restriction so you cannot distribute the source or reveal details. But it is not Sun's fault - they cannot make it open source because of third-party embedded source.
But if you are a Solaris developer it is worth downloading the source. I did that and have no intentions on compiling it or even fixing bugs (I leave that to Sun), but it still helped me a lot in tracking down a really tough bug in my own software.
In general conservative companies think "its free - it cannot be any good"
Which selling points do you highlight to such companies to make them at least consider using a free OS? Which selling points are unique to the use? (server / end-user, embedded,...) Do they like the thought of software running on COTS hardware and buying the real service (AKA consulting, management software, etc) from IBM?
Slashdot Mirror
After you have solved the problem with ip-addresses, network masks, etc, you might also consider handling bandwidth hogs. Some PHB is bound to download as much as he can. Maybe you can use traffic shaping to limit each single PCs bandwidth to a certain ratio of the upstream bandwidth (depending on the number active PCs).
The hotel might also want to bill per megabyte download or per day. I seem to recall that you can get statistics out of ipchains.
The most important downside is that some people think that STL is the holy grail. Not so. There is no silver bullet.
The abstraction level can also be a problem sometimes allthough this is not a problem only with STL. For instance a colleage of mine had to spend much time tracking down why 1 million elements of 48bytes each consumed 144MB. I have also seen the usual problem with someone testing if a list was empty by using size()
Another downside is that the STL is a forced standard meaning that the standard was set before the compilers were able to fullfill it. It has gotten a lot better but you can still encounter limitations in all compilers.
Non-obvious limitations is also a downside. The STL has a very clean design which (unintededly) leads to a few strange limitations, such as const_interators not having a != operator
Sometimes programs using STL is harder to debug. It is not exactly pleasant to have a core dump deep inside template-template-template.....RBtree, spending some time figuring out what that is and after a few hours discover that the problem was not the container at all but something that had scribbled on a reference-copied string :-(
The STl is subject to the usual problems with "Quality of implementation". The standard is set but the implementation has been left (third-party) vendors. Why didn't the Standard Committee provide a public-domain reference implementation which vendors could optimize?
Finally, the STL some places show signs of "Design by committe". This can lead to overly complex designs or no design at all (if the committee cannot agree). Do we really need generic character support in basic_string? Which kind of bastard is auto_ptr? Where is the hash_map?
This is not a rant. I use STL frequently. STL has a lot of advantages but the poster only asked for downsides. You just have to keep in mind that there is no silver bullet.
The thing I have learnt is that there are nice people all over the world. There is also morons all over the world.
On a larger scale you also become aware of something which cannot be tolerated in other parts of the world. Eg. Faked elections, no human rights, unbalanced distribution on wealth, etc.
My conclusion is that the "global village" are making us more tolerant. But also more aware. And the media likes head lines like "Election scam in Albonia" instead of "Germans are just like us!"
I have some numbers. I run squid locally.
$ fgrep HIT access.log|wc -l
3410
$ fgrep MISS access.log|wc -l
5850
If your competitor optimizes his software and it makes it faster than yours, your customers will stop blaming the hardware and start blaming your software. That is your incentive - unless you compete in features.
The address space is 31 bit (2GB) per process.
Considering that x86-programs that use 64-bit MMX registers is not called "64-bit programs" but "32 bit programs", saying that you can run 31-bit programs on the z/Series is technically correct.
- Yahoo - CERN Pushes the Envelope With Oracle9i Database
- Intelligent Library System manages petabytes of environmental
...
?And of course nobody will image mapping this storage as a single drive (via SAN/Raid/...). :-)
Ooops I just imagined it
Mapping a harddrive as memory when using a 64-bit CPU could be interesting. But don't think that it will always work.
IIRC that Multics used memory-mapped files exclusively and it was one of the things that Unix left out. It is an interesting concept but has it limits: (a) You need byte-sized granularity on order to keep track of what the size of the file is. (b) You need sector-sized granularity for tracking changed sectors. The latter does not scale well.
Well, it just fails as if the file does not exist.
... ] then .. fi" fails too.
And yes, the "if [
I have not seen a pattern in the behaviour. Most of the time it works, sometimes it fails. The "-f" always works.
I have encountered errors with the built-in test with -e tests, eg::
[ -e file.foo ] && something
The problem is really hard to reproduce. It has occurred on both the bash delivered with Solaris 8 and HPUX 11i, but not under Linux. Strange.
Has anyone else seen this?
> the vendor compilers are CONSIDERABLY faster than gcc
Not always. Last time I checked Sun's Workshop compiler wer about twice as slow as gcc. gcc was far better at allocating registers while Workshop was better at inlining functions.
non-fiction: That is a very interesting question. Most non-fiction books become obsolete. It would have to be some kind of philosopher or a topic which does not change. Maybe Steven Hawkings...
:-)
Fiction:
Arthur C. Clarke (I have read some of his oldest books, and chancer are that someone will read them 50 years in the future too)
Barbara Cartland: Based on the quantity of books she has written it will take more than 50 years to get rid of them
And I guess someone will be reading the book by Leopold Sacher Masoch.
A very good idea!
:-)
I just realized what the otherwise useless CapsLock key could be used for. Imagine typing in a window. When you want to see something behind the window you just depress capslock, and the window goes 90% transparent. When done viewing, release capslock, and the window returns to solid.
Hmm.. Maybe I should start hacking KDE/Gnome/whatever
DIAMETER has neared completion for the last two years :-) "real soon now". I have no knowledge of decent DIAMETER servers (performance, setup, flexibility)
If he is not going proxy requests DIAMETER offers very little over RADIUS. There are tons of RADIUS servers - both free and commercial, both closed-source and open-source.
If he is going to use a open-source server thingy then it should be easy to adapt to a DIAMETER when/if he wants to.
I grabbed this from IBM's website (http://www-1.ibm.com/servers/eserver/pseries/hard ware/datactr/p690.html):
- Innovative, mainframe-inspired, datacenter-class UNIX
server.
- 8- to 32-way 64 bit SMP server utilizing the first ever
POWER4 dual processor on a chip which uses IBM advanced
silicon-on-insulator (SOI) copper technology.
- Up to 256GB of memory, 160 PCI slots and over 4.6TB of
internal storage.
- Supports up to 16 logical partitions (LPAR), helping to
consolidate workloads, reduce footprints and lower cost of
ownership.
- A dedicated Hardware Management Console that provides a
graphical user interface for configuring and operating the
system including a set of functions for managing LPAR
configurations
- State-of-the-art self-managing capabilities that improve
reliability, availability and serviceability (RAS) and help lower
costs.
- Packaging in a new 24-inch rack with an integrated power
subsystem which accommodates a pSeries 690 system and up
to four I/O drawers.
- AIX clustering and future to attach to SP systems.
It looks very good. I just wonder what you would use 160 PCI slots for?
I have been seeing the timed-out requests since August 1st. Exactly August 1st. The number of 408's in my http log increased slowly from 1-2 per day to 30 around August 20th and then slowly decreasing to 1 - until today, where I so far have seen 130 timed out requests. My system is in the range 212.242.x.x, and most of the requests comes from 212.x.x.x but not all.
> So at the lowest levels it would start to
> resemble writing threaded code,
In case of a pipeline stall, would SMT be advantageous?
To me it looks like asynchronous non-CPU devices, pipelined CPU, and SMT would be an ideal combination.
You are right that it depends a lot on how you implement it.
... unless the RAM chip generates a clock on a separate wire, which some RAM chips do.
:-)
If the RAM delivers data in serial manner (on bit at a time in one wire), faster RAM would definetely cause problems because the CPU would not know how to distinguish the individual bits
On the other hand if the data bus is e.g. 33 wires = 32 data wires and one "handshake" wire, the protocol between the CPU and the RAM chip could be:
CPU -> "give me the contents of address 0x38762A63"
CPU then waits for the handshake wire to go high
The RAM chip sees the address, puts the contents on the data wires, and then sets the handshake wire high.
And the the CPU can read the data.
The above asynchronous protocol does not depend on the speed of the RAM chip. The RAM chip could be a future high-speed "zero-latency" chip, or a slow flash-ram chip. The CPU does not need to know.
There are problems with this too. The protocol is sort of request-reply / step-lock. And how do multiple devices share the same bus. And and and...
Noone said it was easy
The article is very interesting. I though that research in asynchronous computing died in the sixties. What the article misses is that async. operations has an overhead too - the synchronization "here is the data". Synchronous computing does not have that.
I have previously read (forgotten where) that in theory async. computers will always be slower that sync. computers. It seems that that is not true anymore. I guess that the latests-and-greatest CPUs have a non-trivial percentage of idle time for instructions which takes slightly longer than an integral number of clock ticks. If an instruction takes 2.1ns and the clock runs at 1ns, everything have to assume that the instruction takes 3ns.
Also imagine a fully async. computer. No need for a new motherboard or even changing settings in the BIOS when new and faster RAM chips are available - the system will automatically adapt.
I think that we will see more and more async. parts in the year to come. But I don't know if everything is going to be asynchronous.
That is my experience too. Some uninformed managers think that because WindowsNT/2000 has a familiar user interface it is easier to manage and can be done by less competent adminstrators (or even themselves :-)
Let's face it: The major factor is the system administrator. If he/she is competent the system TCO will go down. If he/she is incompetent the TCO will go up.
Good system administators are lazy and try to automate everything so they don't have to work. *nix systems are better at that than Windows (or OS/2, DOS for that matter)
I jumped at IBMs offer for developers to try out Linux running on a z/Architecure thingy. My experience so far has been pleasant and "boring" (in a positive way). Pleasant because everything ported easily. Boring because I was expecting challenging porting problems. Everything worked.
Now for the article about TCO and stuff... I believe that it is correct. For small installations use cheap hardware to bring down initial costs. But don't be afraid of mainframes when you business grows - they are not that different.
For developers:
"Modern Operating Systems" by Andrew Tanenbaum.
"Prototyping" by Roland Vonk.
For end-users the choice is more difficult because they will probably need some less abstract, resulting in books on contemporary applications and technologies. But I recall a book called "What computers can't do" which should be general.
Yes. And it was excellent. But note that I am using the Danish Tax Department's web site. The only requirement of your browser is SSL support.
I see a lot of people whining about the source is not really open. That is true. There are restriction so you cannot distribute the source or reveal details. But it is not Sun's fault - they cannot make it open source because of third-party embedded source. But if you are a Solaris developer it is worth downloading the source. I did that and have no intentions on compiling it or even fixing bugs (I leave that to Sun), but it still helped me a lot in tracking down a really tough bug in my own software.
In general conservative companies think "its free - it cannot be any good" Which selling points do you highlight to such companies to make them at least consider using a free OS? Which selling points are unique to the use? (server / end-user, embedded, ...) Do they like the thought of software running on COTS hardware and buying the real service (AKA consulting, management software, etc) from IBM?