IIRC, the Centon K-100 is what happened when Pentax sold the K-1000 production line to them. It's not exactly the same camera, the shutter has changed plane, and is now electronic, but it is still quite similar. It also takes the same PK lenses as the K-1000 etc.
Huh? Rugby jargon isn't something you need to know to function in society. I guess you've never visited New Zealand...;-)
The original poster was talking about rugby league, not rugby union so unless New Zealand has been moved to Yorkshire you are unlikeley to need it even there.
She's saying that not enough thought has been given to what it means to be white in Australia, and you are all going to end up neurotic if you don't come to terms with the fact that you aren't aboriginal.
SGI's attitude that XFS is unbreakable, therefore they don't need to make tools to fix it is a pain in the arse. XFS does go wrong, it does stuff itself up, and can't always recover at mount.
They tried the "it can't possibly go wrong" stunt with Irix. A few versions later the repair tools turned up... Until they include some decent repair tools with the Linux utilities, I have no intention of letting it anywhere near my data, I've been burned by that one before.
It would appear that "cursive" as referred to here is a uniquely American style. Certainly the descriptions that I have seen in the posts here don't refer to what I would call any normal form of cursive. But since cursive is just writing composed from a single line, it is certainly not invalid. I normally write in cursive script, but I doubt that anyone who was taught "cursive" in an American school would recognise it.
Since metric is the standard, there is no conversion needed. It's those damn silly imperial measurements that the Americans still use that causes the problems. Put it this way, we (the British) invented them, if we were willing to bin them decades ago in favour of something the French invented, they must have been really bad.
While it has very good Word im-/export, it's not yet faultless (and won't be any time soon, because of inherent limitations of OpenOffice). And you NEED that import, because otherwise you can't exchange documents outside of your department.
I'm guessing you are American, or at least have never dealt with British councils. The inability to talk to other departments would be considered a benefit. Remember, whilst it is usually permitted to provide a good service, if anyone in authority finds out then your department will be buried somewhere under an obscure name and removed from any and all directory listings in the hope that the public wont find out. (This is not humour.)
However, you know that the world is working just like normal when someone on Slashdot doesn't know their geography well enough to sanity check their quotes. The Americas Cup is held by landlocked Switzerland. Sweden on the other hand has plenty of coastline.
Using parent companies, holding companies, investment compainies, etc. allows them to morph pretty quickly too. "No, you Honour, that wasn't Microsoft, that was Microsoft West Nebraska, a completely seperate two-person company registered in Texas.", "No, you Honour, those hundred thousand licenses sold in France were actually sold by Microsoft Asia Pacific in Singapore and therefore aren't European revenue."...
So, it wasn't so much management saying "fuck the cold," with engineers saying "they could be too cold and could leak," but instead was engineers saying "we think it could be too cold," management saying "prove it," and engineers trying to do so but not being able to present a convincing argument.
And getting that fundamental principle wrong was the problem. The default status of a mission is on hold, it is "good to go" when the entire team is sure it is safe. Unless the whole team can in good faith claim that all systems are OK, it doesn't (in theory) launch. The burden of proof should be with those who claim that it is safe.
If nobody requests it, then it will eventually drop off the network. However nobody can force it off the network -- if people are requesting it then there is no way to get rid of it short of destroying the entire network.
It dates back to the days when disks were synced to the mains. 60Hz is 3600 cycles per minute. 5400 = 3600 * 1.5, 7200 = 3600 * 2. Note that they are using normalised speeds nowdays, look at the 10krpm and 15krpm disks.
Sort of... SCSI uses less CPU time to do the same as IDE, but this is not because of asynchronous IO, rather it is because much of the work is offloaded to processors on the cards and disks. This can be quite noticeable since SCSI usually used DMA, where the card drops the data into addressable memory whilst up until recently, IDE tended to use PIO which is far slower and far more CPU hungry. However modern IDE systems, using DMA on a single user system with a single disk can easily match SCSI for speed, and almost efficiency. The non-blocking reads that you are referring to are usually known as Asynchronous IO (AIO). This can be achieved several ways -- with background threads that manage the IO, or with Kernel AIO (KAIO) where the kernel takes requests and signals the program when the data has been loaded into memory. The sluggishness you are referring to is probably due to the scenes being assembled in memory, rather than the bulk loads. Whether it is CPU bound processing them, or bus bound, uploading the data to the graphics card is up for question however.
The point is not that the JVM uses multiple processes, rather that the JVM may run multiple processes. ie. the ability for the same JVM to run (say) jbash and jls simultaneously. Thus you need one JVM per user, or per system. The apple shared memory approach goes a long way towards this, but externalises the memory and process isolation whereas a pure multi-process JVM would internalise them.
The atom is not a point charge, it is polarisable with suitably large magnetic fields. We aren't talking about household magnets here -- containment fields make NMR look wussy.
Mostly. Things like Unicenter TNG sound nice in theory, but aren't really much cop when every box does something different. Sun's GridEngine shows some promise - set up all the boxes identically and allow tasks to migrate. In the real world however, this doesn't really happen. Often for political reasons managers want boxes for "Their project" and wont share with another project since the server cost came out of their budget and if the other project turns into a resource hog then their project gets screwed and they get in the shit for providing a bad service. With one big machine you don't get this sort or territory war since it is one big pot of resource and everybody has to cooperate.
It is not so much that the state has to be held in one's head, it is the fact that the state has to be consistent across all the people working on the system - it is very similar to ccNUMA if you are familliar with computer architecture. If you have a dozen people working on the systems, and only one person knows that a system has moved, they may, for instance, change the hosts map to reflect the change, but unless this information is communicated to the others someone may see that the hosts map is "wrong" and change it back to fix some other problem. If there is only one person working, all the state can be held in the head. If there are two people working on it, then talking in the office keeps everyone informed. When you have several dozen staff working 24x7 in different countries over several timezones this can get very difficult, traditional communications scales as n factorial with the number of servers. Aggregating servers doesn't reduce the number of problems, but it reduces the number of nodes to which information must be communicated as it allows you to localise problems and fixes in conjunction with a decent change management system.
It's not the maintenance that is the problem, things like configuration management and data integrity are more important. If you have a hundred servers, then you have a hundred places to check that everything is in sync. If you are running a small shop with a dozen or so machines and one administrator then they can keep all the state in their heads. When you get up to hundreds then the state is larger than one person can easily cope with and you start having to communicate state to others. With hundreds of boxes, it is easy to overlook things, with fewer boxes, the communication is easier, and cheaper.
The other thing is CPU residency. Lots of small boxes wastes CPU power because they tend to be devoted to one task and are only capable of that task. The problem is, they are so small that you can't add other tasks to them so you need a new box... Generally, CPU residency on small boxes runs about 10%, with mainframes, this can rise to 90%. Take two tasks - one runs during the day, one runs during the night. Conventional wisdom would allocate two small boxes, one per task wasting them for most or their life. Mainframe usage would run them both on the mainframe - this gives each process more power when they run and doesn't waste the box when they don't. Most traffic tends to be peaky but only for a short period of time so if the box is large enough to hold them both, you get a saving whilst still making all the tasks faster.
Small boxes are good when you need maximum cycles per buck and the task is easily partitionable with minimal interprocess communication and the tasks are continuous. When the tasks are not easily partitionable, need lots of IPC or are peaky then larger boxes make sense.
The thing to remember is that where the scale is large, you need to make use of that scale to get maximum performance. You don't see chemical plants using hundreds of small vats, they use a few really big ones. With these systems they are used at a scale where communications and simply keeping track of what is going on is a major exercise and hence a major expense.
My Experience? Well - put it this way, the SunFire 6800 turned up a few weeks ago, the 4800 turns up on wednesday as part of a plan to replace a Tandem mainframe and they will be sitting next to quite a few racks holding Sun E3500s, E450s, E250s, t1s, HP netservers, IBM RS6000s and SGI Origin 2000s and indeed a MacOS server or twenty. A lot of our comms talk to Stratus mainframes and the machine room cooling plants are a more pressing problem than CPU speed.
Re:Ten Reasons Why TeX/LaTeX is Better than Word
on
Writing Documentation
·
· Score: 1
Unless you count the liveware virus that makes you want to escape every period\. I'd call that pretty macro\.
I hope they get the virus definitions sorted for that soon, I've got a similar one from vi.
Although it hides as the "What's Related" feature, Mozilla does exactly the same thing. Every URL you visit is sent to xslt.alexa.com. Just try it: add "127.0.0.1 xslt.alexa.com" to your/etc/hosts, fire up apache and Mozilla and tail the logfile...
Buying something in a store is not a debt. When you take things to the couter, they are not yours, you take them there to make a offer to purchase. When you try to pay, you are negociating a contract of sale in which you and the cashier agree on an acceptable form of payment. The goods are not yours until you have both completed the contract. You are never in their debt, and so the Legal Tender statutes do not apply, and in any event, legal tender only applies where acceptable forms of payment haven't been specified in the contract.
Slashdot Mirror
You would probably be better learning from Apple than Microsoft in this case.
IIRC, the Centon K-100 is what happened when Pentax sold the K-1000 production line to them. It's not exactly the same camera, the shutter has changed plane, and is now electronic, but it is still quite similar. It also takes the same PK lenses as the K-1000 etc.
Huh? Rugby jargon isn't something you need to know to function in society. ;-)
I guess you've never visited New Zealand...
The original poster was talking about rugby league, not rugby union so unless New Zealand has been moved to Yorkshire you are unlikeley to need it even there.
She's saying that not enough thought has been given to what it means to be white in Australia, and you are all going to end up neurotic if you don't come to terms with the fact that you aren't aboriginal.
SGI's attitude that XFS is unbreakable, therefore they don't need to make tools to fix it is a pain in the arse. XFS does go wrong, it does stuff itself up, and can't always recover at mount.
They tried the "it can't possibly go wrong" stunt with Irix. A few versions later the repair tools turned up... Until they include some decent repair tools with the Linux utilities, I have no intention of letting it anywhere near my data, I've been burned by that one before.
It would appear that "cursive" as referred to here is a uniquely American style. Certainly the descriptions that I have seen in the posts here don't refer to what I would call any normal form of cursive. But since cursive is just writing composed from a single line, it is certainly not invalid. I normally write in cursive script, but I doubt that anyone who was taught "cursive" in an American school would recognise it.
Since metric is the standard, there is no conversion needed. It's those damn silly imperial measurements that the Americans still use that causes the problems. Put it this way, we (the British) invented them, if we were willing to bin them decades ago in favour of something the French invented, they must have been really bad.
While it has very good Word im-/export, it's not yet faultless (and won't be any time soon, because of inherent limitations of OpenOffice). And you NEED that import, because otherwise you can't exchange documents outside of your department.
I'm guessing you are American, or at least have never dealt with British councils. The inability to talk to other departments would be considered a benefit. Remember, whilst it is usually permitted to provide a good service, if anyone in authority finds out then your department will be buried somewhere under an obscure name and removed from any and all directory listings in the hope that the public wont find out.
(This is not humour.)
It would appear that vi command are not known by Anonymous Cowards either.
:dw )
(^W in Bourne deletes words, in vi you would use
I suspect you may want to take a look at mmap, most *NIX variants seem to implement it using the virtual memory system.
However, you know that the world is working just like normal when someone on Slashdot doesn't know their geography well enough to sanity check their quotes. The Americas Cup is held by landlocked Switzerland. Sweden on the other hand has plenty of coastline.
Using parent companies, holding companies, investment compainies, etc. allows them to morph pretty quickly too.
"No, you Honour, that wasn't Microsoft, that was Microsoft West Nebraska, a completely seperate two-person company registered in Texas.", "No, you Honour, those hundred thousand licenses sold in France were actually sold by Microsoft Asia Pacific in Singapore and therefore aren't European revenue."...
So, it wasn't so much management saying "fuck the cold," with engineers saying "they could be too cold and could leak," but instead was engineers saying "we think it could be too cold," management saying "prove it," and engineers trying to do so but not being able to present a convincing argument.
And getting that fundamental principle wrong was the problem. The default status of a mission is on hold, it is "good to go" when the entire team is sure it is safe. Unless the whole team can in good faith claim that all systems are OK, it doesn't (in theory) launch.
The burden of proof should be with those who claim that it is safe.
Does it go all the way to eleven?
If nobody requests it, then it will eventually drop off the network. However nobody can force it off the network -- if people are requesting it then there is no way to get rid of it short of destroying the entire network.
It dates back to the days when disks were synced to the mains. 60Hz is 3600 cycles per minute. 5400 = 3600 * 1.5, 7200 = 3600 * 2.
Note that they are using normalised speeds nowdays, look at the 10krpm and 15krpm disks.
Sort of...
SCSI uses less CPU time to do the same as IDE, but this is not because of asynchronous IO, rather it is because much of the work is offloaded to processors on the cards and disks. This can be quite noticeable since SCSI usually used DMA, where the card drops the data into addressable memory whilst up until recently, IDE tended to use PIO which is far slower and far more CPU hungry. However modern IDE systems, using DMA on a single user system with a single disk can easily match SCSI for speed, and almost efficiency.
The non-blocking reads that you are referring to are usually known as Asynchronous IO (AIO). This can be achieved several ways -- with background threads that manage the IO, or with Kernel AIO (KAIO) where the kernel takes requests and signals the program when the data has been loaded into memory.
The sluggishness you are referring to is probably due to the scenes being assembled in memory, rather than the bulk loads. Whether it is CPU bound processing them, or bus bound, uploading the data to the graphics card is up for question however.
The point is not that the JVM uses multiple processes, rather that the JVM may run multiple processes. ie. the ability for the same JVM to run (say) jbash and jls simultaneously. Thus you need one JVM per user, or per system. The apple shared memory approach goes a long way towards this, but externalises the memory and process isolation whereas a pure multi-process JVM would internalise them.
The atom is not a point charge, it is polarisable
with suitably large magnetic fields. We aren't talking about household magnets here -- containment fields make NMR look wussy.
Mostly. Things like Unicenter TNG sound nice in theory, but aren't really much cop when every box does something different. Sun's GridEngine shows some promise - set up all the boxes identically and allow tasks to migrate. In the real world however, this doesn't really happen. Often for political reasons managers want boxes for "Their project" and wont share with another project since the server cost came out of their budget and if the other project turns into a resource hog then their project gets screwed and they get in the shit for providing a bad service. With one big machine you don't get this sort or territory war since it is one big pot of resource and everybody has to cooperate.
It is not so much that the state has to be held in one's head, it is the fact that the state has to be consistent across all the people working on the system - it is very similar to ccNUMA if you are familliar with computer architecture. If you have a dozen people working on the systems, and only one person knows that a system has moved, they may, for instance, change the hosts map to reflect the change, but unless this information is communicated to the others someone may see that the hosts map is "wrong" and change it back to fix some other problem. If there is only one person working, all the state can be held in the head. If there are two people working on it, then talking in the office keeps everyone informed. When you have several dozen staff working 24x7 in different countries over several timezones this can get very difficult, traditional communications scales as n factorial with the number of servers. Aggregating servers doesn't reduce the number of problems, but it reduces the number of nodes to which information must be communicated as it allows you to localise problems and fixes in conjunction with a decent change management system.
Designed from scratch, to do it right and drop all the backwards compatible cruft. They had their clean break and blew it.
It's not the maintenance that is the problem, things like configuration management and data integrity are more important. If you have a hundred servers, then you have a hundred places to check that everything is in sync. If you are running a small shop with a dozen or so machines and one administrator then they can keep all the state in their heads. When you get up to hundreds then the state is larger than one person can easily cope with and you start having to communicate state to others. With hundreds of boxes, it is easy to overlook things, with fewer boxes, the communication is easier, and cheaper.
The other thing is CPU residency. Lots of small boxes wastes CPU power because they tend to be devoted to one task and are only capable of that task. The problem is, they are so small that you can't add other tasks to them so you need a new box... Generally, CPU residency on small boxes runs about 10%, with mainframes, this can rise to 90%. Take two tasks - one runs during the day, one runs during the night. Conventional wisdom would allocate two small boxes, one per task wasting them for most or their life. Mainframe usage would run them both on the mainframe - this gives each process more power when they run and doesn't waste the box when they don't. Most traffic tends to be peaky but only for a short period of time so if the box is large enough to hold them both, you get a saving whilst still making all the tasks faster.
Small boxes are good when you need maximum cycles per buck and the task is easily partitionable with minimal interprocess communication and the tasks are continuous. When the tasks are not easily partitionable, need lots of IPC or are peaky then larger boxes make sense.
The thing to remember is that where the scale is large, you need to make use of that scale to get maximum performance. You don't see chemical plants using hundreds of small vats, they use a few really big ones. With these systems they are used at a scale where communications and simply keeping track of what is going on is a major exercise and hence a major expense.
My Experience? Well - put it this way, the SunFire 6800 turned up a few weeks ago, the 4800 turns up on wednesday as part of a plan to replace a Tandem mainframe and they will be sitting next to quite a few racks holding Sun E3500s, E450s, E250s, t1s, HP netservers, IBM RS6000s and SGI Origin 2000s and indeed a MacOS server or twenty. A lot of our comms talk to Stratus mainframes and the machine room cooling plants are a more pressing problem than CPU speed.
Unless you count the liveware virus that makes you want to escape every period\. I'd call that pretty macro\.
I hope they get the virus definitions sorted for that soon, I've got a similar one from vi.
^[:wq
Although it hides as the "What's Related" feature, Mozilla does exactly the same thing. Every URL you visit is sent to xslt.alexa.com. Just try it: add "127.0.0.1 xslt.alexa.com" to your /etc/hosts, fire up apache and Mozilla and tail the logfile...
127.0.0.1 - - [06/Jan/2002:10:58:03 +0000] "GET /data?cli=17&dat=nsacdt=t%3D1%26pane%3Dnswr6%26wid %3D4832&url=http://www.google.com HTTP/1.1" 404 276 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012" /data?cli=17&dat=nsacdt=t%3D0%26pane%3Dnswr6%26wid %3D4832&url=http://www.google.com/search HTTP/1.1" 404 276 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012"
127.0.0.1 - - [06/Jan/2002:10:58:08 +0000] "GET
Buying something in a store is not a debt. When you take things to the couter, they are not yours, you take them there to make a offer to purchase. When you try to pay, you are negociating a contract of sale in which you and the cashier agree on an acceptable form of payment. The goods are not yours until you have both completed the contract. You are never in their debt, and so the Legal Tender statutes do not apply, and in any event, legal tender only applies where acceptable forms of payment haven't been specified in the contract.