It is already interesting with Sun's T1000 ("Coolthreads") servers. They have 8 cores per chip. Each core supports 4 threads. Oracle is already scratching its head trying to figure out how the set a fair price on the license for that.
I have found the posters at o2chart very useful. The IMS poster in particular gives a good overview and is much nicer than the diagram in 3gpp's TS 23.234 + 29.228
The X protocol directly supports 5 buttons. Additional buttons can be supported by X Input Extension (XIE). The scroll wheel is usually handled via XIE.
Initially the specifications for CORBA (object model, servers, language mapping,...) were not free. Whenever I tried digging for details I ended up at a page which basically said "buy the expensive book". Of course they needed funding, but the lack of a free specification hindered adaption. I was also turned off by the continued references to UML (which was a new-fangled thing back then). When looking for hard details a floffy box does not help.
It also seems that the vendors had a lot of problems agreeing. AFAIK it wasn't until version 2 that the on-the-wire format was specified. I can only speculate why.
But I must say that the IDL (interface definition language) is close to ideal. Looks a lot like Sun RPC, and way better than WSDL. It only lacks the versioning as the article also mentions.
I am one of the few people that have read the CUA guidelines, and they make at lot of sense, although many of the specific details are now outdated. The CUA guidelines say that you have to first decie if the UI is going to be a standard UI where it has the conform to system defaults and in general user's expectations; or if the UI is a so-called walk-up-and-use UI (such as ATM interfaces). The difference is that the standard UIs have to conform to standards but can contain many features, while the walk-up-and-use UI has to be simplistic and require absolutely no learning, but can break any standard as long as it makes it simpler to use.
So the guideline should be:
Know your users: Don't assume your users have no expertise, but neither assume that they have. Find out. This impacts not only the program UI but also the documentation. If you do not know your users (or the intended target group) then the program is always too simple and to complex at the same time.
The difference between format and presentation. Eg. the difference between a.doc file and a.jpg file. You would be amazed of the people who rescale a.bmp picture inside word. They should know/try at least to programs for handling each major file type. Some people do not even know that they have a choice.
I once gave up having a T-shirt made with a picture on it because the shop could not handle.jpg or.bmp pictures - they only knew how to handle.doc
A few weeks back I were amused at the local national telco announcing that they had absolutely no plans for offering VoIP because the quality was poor, problems with connectivity, immature technology, etc. The same week their internet division started offering VoIP over ADSL.
It's ECC memmory, but thanks for the suggestion anyway.
The funny thing is that when it locks up, xinetd still works, but presumably cannot spawn child processes or somesuch. No log at all.
The hangs mostly (but not always) happen when there is some light graphic acticity (firefox/openoffice). It cannot be reproduced on demand. Weeks can go by with no hangs, then 4 hangs in a day.
So 10% performance hit would be cheap for avoiding problems like this or at least getting a way of pinpoiting the culprit.
I am one of the silly people who would gladly trade in 10% of the performance for increased reliability on my desktop.
The OS? Linux. And for more than a year I still haven't found the cause for partial hangs. (Could be the X server. Could be the SMP code. Could be something entirely different)
"every time a packet gets sent to the NIC, the kernel must be interrupted to at least look at the packet header to determine of the data is destined for that NIC"
Uhm.. no. That is only the case if the NIC has been set into promiscuous mode, or if it has joined too many multicast groups.
"...because the packets are not TCP, they are not routable across Ethernet"
Uhm. If they were IP they would still be routable. I suspect he meant "not IP".
I also get irritated by the spelling out of "Sixty-four-bit PCI"
But the article still has a lot of good reviews and a load of links to other sides with interesting info.
From my limited knowledge of GPFS my guess is that GPFS is slow at metadata operations (opening files, listing directories, updating last-changed-date,..) but lightening fast for I/O once you have the file open.
I don't know if you missed something - I didn't RTFA.
Heartbeats are optional. Some real-time applications probably want to use heartbeats every 10 seconds, while other can disable them completely.
The multihoming has nothing to do with routing table size. The multihoming feature is used for providing better connectivity. Imagine your laptop with WiFi. If the application (say, FTP download) used SCTP instead of TCP then the download would not break when your laptop moves from one access point to another and switches ip-address. SCTP survives that.
What keeps someone from joining the pool and giving out the wrong time?
Nothing.
However, NTP clients uses multiple servers and uses some fairly advanced correlation algorithms to detect outlyers and bad servers. The client configuration is your responsibility. So configure it to use a set of servers that you believe you can trust.
There are some nifty bits of nastiness that can be delivered when a machine is privy to having its clock changed from afar.
Configure different MTUs on the machines. It is quite difficult to troubleshot because simple pings, telnet, etc. works just fine. Any larger transfer that uses full-size ethernet packets will not work. The symptoms are.. interesting and erratic. "ls" on NFS drives works unless there is too many files. telnet usually works until something sends more than 1500 bytes in one go. ping works fine. arp works fine. nslookup works fine.
... no single country should have total control of anything which is used globally.
I agree completely. The latest policical intervention about the.xxx TLD proves that we do not want politicians deciding technical stuff. Should the decisions regarding root servers be controlled by the USA? No. Should the decisions regarding root servers be controlled by the UN? No. The UN is also a political organization.
One approach would be multiple groups. Example: One group setting the high-level policies (eg. "root servers must be highly available and have synchronized content"). Another group decide what these policies means in terms of technical requirements ("minimum two network links, load balancing and failover, no tampering, automated updates, no censorship, no default domains"). Then it implements it purely based on the technical requirements. So if the Evil Country Elbonia can meet these requirements then they can have a root server, no matter how evil they are.
In other areas another posibility is a standard-setting organization with no power. IETF comes to mind. Its working groups can decide on standards (RFCs), but they cannot force anyone to implement them. There are politics in IETF, but not too much due to the lack of power.
One other interesting example is ITU (formerly CCITT). 3GPP was formed because ITU was too slow for the rapid deployment of 2G and 3G. The politics game in ITU has mostly been absent in 3GPP because 3GPP does not have consider legacy technology that ITU deals with. I have no idea what the future holds for ITU and 3GPP.
Back up the.xxx domain. Should it be implemented? I have no idea. What are the technical reasons?
If you are using an off-the-shelf inventory/billing system they you should probably consider letting someone else handle the integration and format-translation.
I have implemented an EDI system from scratch at my previous company. It was based on EDIFACT and email, and had extensive tracking&tracing, status feedback, error handling. The major challenge in implementing and EDI system is the integration with your EDI partners. It took 3 months from start of testing to the first real EDI message getting through, and almost a year before the workflow was right. Another challenge is that touches on legal responsibility - who said what, why, when.
I believe that ROI was good. No more manually entering 5 batches of 100 items every day. And the deadlines were improved so the final information set could be imported half an hour before work was initiated.
As far as I know the system is still chugging along 5 years after I left the company.
Use all four (preferably six) mounting screws. The installation guide to my old ST3283A explicitly mentioned using only three mounting screws. I guess it was to prevent the drive being warped.
The change to dayligt saving is first effective 2007. From the bill:...subsection (a) shall take effect 1 year after the date of enactment of this Act or March 1, 2007, whicever is later.
Slashdot Mirror
It is already interesting with Sun's T1000 ("Coolthreads") servers. They have 8 cores per chip. Each core supports 4 threads. Oracle is already scratching its head trying to figure out how the set a fair price on the license for that.
I have found the posters at o2chart very useful. The IMS poster in particular gives a good overview and is much nicer than the diagram in 3gpp's TS 23.234 + 29.228
The X protocol directly supports 5 buttons. Additional buttons can be supported by X Input Extension (XIE). The scroll wheel is usually handled via XIE.
Initially the specifications for CORBA (object model, servers, language mapping, ...) were not free. Whenever I tried digging for details I ended up at a page which basically said "buy the expensive book". Of course they needed funding, but the lack of a free specification hindered adaption. I was also turned off by the continued references to UML (which was a new-fangled thing back then). When looking for hard details a floffy box does not help.
It also seems that the vendors had a lot of problems agreeing. AFAIK it wasn't until version 2 that the on-the-wire format was specified. I can only speculate why.
But I must say that the IDL (interface definition language) is close to ideal. Looks a lot like Sun RPC, and way better than WSDL. It only lacks the versioning as the article also mentions.
I am one of the few people that have read the CUA guidelines, and they make at lot of sense, although many of the specific details are now outdated. The CUA guidelines say that you have to first decie if the UI is going to be a standard UI where it has the conform to system defaults and in general user's expectations; or if the UI is a so-called walk-up-and-use UI (such as ATM interfaces). The difference is that the standard UIs have to conform to standards but can contain many features, while the walk-up-and-use UI has to be simplistic and require absolutely no learning, but can break any standard as long as it makes it simpler to use.
So the guideline should be:
vs. hanging indent.
The difference between format and presentation. Eg. the difference between a .doc file and a .jpg file. You would be amazed of the people who rescale a .bmp picture inside word. They should know /try at least to programs for handling each major file type. Some people do not even know that they have a choice.
I once gave up having a T-shirt made with a picture on it because the shop could not handle .jpg or .bmp pictures - they only knew how to handle .doc
No Telco will offer VoIP or IMs.
A few weeks back I were amused at the local national telco announcing that they had absolutely no plans for offering VoIP because the quality was poor, problems with connectivity, immature technology, etc. The same week their internet division started offering VoIP over ADSL.
It's ECC memmory, but thanks for the suggestion anyway.
The funny thing is that when it locks up, xinetd still works, but presumably cannot spawn child processes or somesuch. No log at all.
The hangs mostly (but not always) happen when there is some light graphic acticity (firefox/openoffice). It cannot be reproduced on demand. Weeks can go by with no hangs, then 4 hangs in a day.
So 10% performance hit would be cheap for avoiding problems like this or at least getting a way of pinpoiting the culprit.
And I think that is A. Tanenbaum's point.
I am one of the silly people who would gladly trade in 10% of the performance for increased reliability on my desktop.
The OS? Linux. And for more than a year I still haven't found the cause for partial hangs. (Could be the X server. Could be the SMP code. Could be something entirely different)
"every time a packet gets sent to the NIC, the kernel must be interrupted to at least look at the packet header to determine of the data is destined for that NIC"
Uhm.. no. That is only the case if the NIC has been set into promiscuous mode, or if it has joined too many multicast groups.
"...because the packets are not TCP, they are not routable across Ethernet"
Uhm. If they were IP they would still be routable. I suspect he meant "not IP".
I also get irritated by the spelling out of "Sixty-four-bit PCI"
But the article still has a lot of good reviews and a load of links to other sides with interesting info.
I can just decrypt it using the data from http://it.slashdot.org/article.pl?sid=06/03/30/011 5216 :-)
From my limited knowledge of GPFS my guess is that GPFS is slow at metadata operations (opening files, listing directories, updating last-changed-date, ..) but lightening fast for I/O once you have the file open.
Only if you find the Protocols of Mass Destruction.
I don't know if you missed something - I didn't RTFA.
Heartbeats are optional. Some real-time applications probably want to use heartbeats every 10 seconds, while other can disable them completely.
The multihoming has nothing to do with routing table size. The multihoming feature is used for providing better connectivity.
Imagine your laptop with WiFi. If the application (say, FTP download) used SCTP instead of TCP then the download would not break when your laptop moves from one access point to another and switches ip-address. SCTP survives that.
What keeps someone from joining the pool and giving out the wrong time?
Nothing.
However, NTP clients uses multiple servers and uses some fairly advanced correlation algorithms to detect outlyers and bad servers. The client configuration is your responsibility. So configure it to use a set of servers that you believe you can trust.
There are some nifty bits of nastiness that can be delivered when a machine is privy to having its clock changed from afar.
Then use the secure protocols.
What's the battery life of a goldfish?
Inquiring minds want to know.
Ok, but which editor is he using? :-)
Configure different MTUs on the machines.
It is quite difficult to troubleshot because simple pings, telnet, etc. works just fine. Any larger transfer that uses full-size ethernet packets will not work. The symptoms are.. interesting and erratic. "ls" on NFS drives works unless there is too many files. telnet usually works until something sends more than 1500 bytes in one go. ping works fine. arp works fine. nslookup works fine.
... no single country should have total control of anything which is used globally.
.xxx TLD proves that we do not want politicians deciding technical stuff.
.xxx domain. Should it be implemented? I have no idea. What are the technical reasons?
I agree completely. The latest policical intervention about the
Should the decisions regarding root servers be controlled by the USA? No.
Should the decisions regarding root servers be controlled by the UN? No. The UN is also a political organization.
One approach would be multiple groups. Example: One group setting the high-level policies (eg. "root servers must be highly available and have synchronized content"). Another group decide what these policies means in terms of technical requirements ("minimum two network links, load balancing and failover, no tampering, automated updates, no censorship, no default domains"). Then it implements it purely based on the technical requirements. So if the Evil Country Elbonia can meet these requirements then they can have a root server, no matter how evil they are.
In other areas another posibility is a standard-setting organization with no power. IETF comes to mind. Its working groups can decide on standards (RFCs), but they cannot force anyone to implement them. There are politics in IETF, but not too much due to the lack of power.
One other interesting example is ITU (formerly CCITT). 3GPP was formed because ITU was too slow for the rapid deployment of 2G and 3G. The politics game in ITU has mostly been absent in 3GPP because 3GPP does not have consider legacy technology that ITU deals with. I have no idea what the future holds for ITU and 3GPP.
Back up the
Knowing what to search for brings up these relevant links:
EDIFACT
X12
How Radio Frequency Identification Affects EDI
Integration for Logistics: RFID, EDI, XML, and Beyond
If you are using an off-the-shelf inventory/billing system they you should probably consider letting someone else handle the integration and format-translation.
I have implemented an EDI system from scratch at my previous company. It was based on EDIFACT and email, and had extensive tracking&tracing, status feedback, error handling. The major challenge in implementing and EDI system is the integration with your EDI partners. It took 3 months from start of testing to the first real EDI message getting through, and almost a year before the workflow was right. Another challenge is that touches on legal responsibility - who said what, why, when.
I believe that ROI was good. No more manually entering 5 batches of 100 items every day. And the deadlines were improved so the final information set could be imported half an hour before work was initiated.
As far as I know the system is still chugging along 5 years after I left the company.
Use all four (preferably six) mounting screws.
The installation guide to my old ST3283A explicitly mentioned using only three mounting screws.
I guess it was to prevent the drive being warped.
OS/2 Bootmanager can do that :-)
The OP had problems with running SuSE 9.3 as guest OS. You need Vmware 5 for that (SuSE 9.2 had no problem)
The change to dayligt saving is first effective 2007. From the bill: ...subsection (a) shall take effect 1 year after the date of enactment of this Act or March 1, 2007, whicever is later.
You need Vmware 5.x. Vmware 4.x does not support SuSE 9.x