OTOH, I heard that the thumb cam (a CCD on a stick)was used to setup shots from models, and the battlefield landscapes were digitised in with the hand-held 3D scanners.
The scaling was through the use of scale-foubles and perspective rather than digital effects. However the battles were humans (sometimes masked, depending on their role) blue screened on a digitally generated background with in the battle of Helm's Deep was about 95% of the force.
I like your suggestions but the current RHN model won't really hack the multiple systems model. Each system that you have registered with RHN ultimately costs RedHat bandwidth. I would suggest that if a system is designated as a local cache and only that pulls updates, then the additional system costs should be waived (or be nominal, say $5 for registering the profile). If I have ten systems, then I'm likely to call RH Support more often than with one system, so they can make their money on the calls.
I'm not sure whether three years ongoing support for the small bsuiness version is doable, but I reckon two is.
Love it. You should have oferred to do a presentation for their auditors.
Its like when I heard an android describing the security requirements for an electronic financial derivatives exchange:
"Its not like we're dealing with money"
No, just a government bond worth about $100000.
Another one at a bank, there is a story about the international payments system. It is split into two parts, the payment transmission system and the ledger. Great idea. Then why save money by having one guy to support both with admin status (he was an external too)? Apparently he siphoned off about $1mill when he was caught. The rumour says he was only caught because he got nervous after 9/11 and wanted to move his ill-gotten gains again. They were already offshore, but the bank queried the transaction and the scheme collapsed.
The thing is that the SWIFT system is designed around the four-eyes principle. You need two authenticators per transaction, but the number of organisatons that make procedurally easy to avoid these checks is frightening.
The whols SSL thing is based around certificates. We have seen problems with certificate handling, and certainly with the user acceptance of certificates. I prefer the "Web-of-Trust" method of PGP where certificates may be multiply signed and you may indicate your own trust in the certification authority.
Yes, they have some advantages, but not a lot really. The problem is that they are a hierachical organisation that produce and manage cryptographic systems for hierarchies.
The big difference between what the NSA have done and what the world of commerce needs and does is rather different. They really missed out on public-key cryptography, although it was arguably ffirst develped by GCHQ (the British variant of the NSA), it's significance was ignored.
The NSA are great cryptographers, as are GCHQ and whatever their equivalents are around the world. Unfortunately the cloak of secrecy hampers the rapid progress that can be made outside. Can the NSA get Russian mathematicians to look at their algorithms? I don't think so.
OTOH, if you have a good idea in the open you can post to sci.crypt and have it shot down by some of the best cryptographers in the world.
The RH version of 2.4.18 is with a few extras (especially with some AC flavour patches) and it is mainstream, which appeals to a lot of people. My systems usually run RH, simply because it is mainstream and it is probably what my clients have.
I was given an old Celeron based Deskpro, so I have built 2.5.64 on top of a 2.4.21pre5 kernel (in turn sitting on RH 8.0) but despite the usual modutils, bintutils, e2fs and so upgrades, I can't get past the decompressing of the kernel during boot. I want to get it sorted, but we'll see. The trouble is that this is the first unstable that I have run since 2.3 days so I have either forgotten half the tricks or they are out of date.
High Latency.....
pop along to kernel.org and get a 2.5 kernel
You don't even need that particular headache (I haven't had enough time to get my 2.5 Kernel up), but Redhat 8.0's 2.4.18 kernel supports low-latency (enabled via the/proc filesystem) and the ALSA drivers (0.9) drop in quite easily.
Word gets as useful as it's going to get for about 95% of the users, and then it "jumps the shark" -- becomes more bloated, cumbersome, and expensive
You are right, I was happy with the functionality of MS Word about a couple of releases ago, probably before that. What made me upgrade to Word 2K is the stability. Unfortunately, the free bloatware functionality has increased its footprint so it is painfully slow to use. There are still bugs, but at least it doesn't crash so often.
I thought that IBM went a little longer with AIX on the x86 (until 2.x), but it was a long time ago that I saw it on the PS/2. It was big and slow and seemed to run much better on the PowerPC architecture (+when you had enough memory).
However from the headers at least, it seems that they didn't forget the x86, and I can't see them removing the support altogether.
Sorry, what I was trying to say is that AIX has some small relation to BSD if anything but ehwn not much. It has very little from S5. As you say the BSD bits are covered and as for the rest, I would say it is probably clean. The problem is that as IBM is a source code licensee of S5, they would have to prove that they were not violating SCO's IP. Of course, they can counter-sue, but whatever happens, this will get some corporate types nervous about Linux until it is settled.
I guess the SCO/Caldera boss has been using the Palantir too often in communication with Seattle.
I was an early user of SCO's ODT. All I can say is that they should have patented the kernel trap through segmentation fault, because SCO were faster to crash than NT.
If one goes back in history, a lot of MS's own hatred of Unix comes from their internal systems running on SCO Unix in the early days. Mind you, SCO were using MS compilers then.
isn't just a quantum effect, it is a risk factor when considering the technology of a company. Venture Capitalists loathe it because it particularly because it puts a large legal question mark over a potential investment.
My feeling is that this is an MS-inspired shot over the bows to scare VCs and IT chiefs away from Linux. In one case it really doesn;t matter whether SCO/Caldera wins or loses, it just hast to leave a suspicion in these people's minds.
This mean's that not only must IBM win, but they should win 'loudly', i.e., so those people who may be worried about Linux realise that they shouldn't be.
Um, bot only Unix, but also BSD was floating around the unis.
Having done a *lot* of work on AIX back in the early days, I can say that it borrowed some bits from BSD (who didn't then), but didn't from S5 Unix and their kernel was theirs. I didn't have their source code, but I was always cursing them for their incompatabilities which is why I can say they were different.
Also, AIX had a PS/2 distribution in the eary days, so they certianly had x86 architecture since way back when.
When RH starts the GUI, the system is completely up. Even the PPP links have started (if you configured them to autostart).
With Windows, they have no virtual console so they start the GUI early (presumably so you can fix broken services), but the system may not be fully ready for some time after that. I have logged in and found even basics like RPC still waiting to start, let alone stuff like PPPoE and routing.
With Linux, service startup goes a lot easier and you don't need X to be running to fix things.
Actually, the Soviet's main problem in the space program was a scewed sense of priorities. The most important things were to prove your superior's right and to CYA. Safety came a poor third. Everytime something went wrong, someone would whisper "Sabotage" and the best answer that anyone could say was "We were following orders".
Doesn't sound a million miles from the direction a certain other space agency seems to be taking, does it?
I have an Omnicube 2-port with Win and Linux machines as well as a 4-port with Win+2*Linux machines. The two port has a logitech wheel mouse whilst the 4-port has an MS mouse.
The main issue is that if the Linux system isn't selected during a reboot then sometimes anaconda (it is a Red-Hat Distro) barfs during the hardware recognition of my mouse and monitor.
Your idea is quite good for minimalistic databases like MySQL but not so good for the Oracles or whatever that do their own I/O management. They are aware of the diffeernce between tables and values and attempt to logical about the way that they manage them. Frequently they have their own LRU cache and read-ahead strategies independent of the underlying OS.
The thing that I understand from this paper is that the system is assuming that a future read will be in the proximity of the previous read so stalling for a short time in case a subsequent read comes through in the vicinity.
The things is that since we got rid of DOS, a pc is now capable of multiprogramming. It is quite normal to run two or more activities, say listening to music and writing something in an IDE. The trouble is when I want to start something new.
Normally the disks are using an elevator scan which when the disks are well used, it works quite well at sharing the disk out. The problem is that the svan works between the lowest and highest cylinder numbers in any request during the current scan. So if I scan from Cyl 10 to Cyl 100, fine but the next request is for Cyl 11 so I change direction, but the immediately following request is for 101. Sorry, I'm already headed towards 11 so 101 must wait for my scan to complete and reverse direction.
My feeling is that it would be better to wait only at the end of a cylinder scan to check for new requests. Elevator seeking is good, but only if you are within the range of the current scan.
One of the issues we were talking about earlier was opening a calculator in the middle of a task, say Xcalc. I had the privilege in my younger days to see a toploader which took 60MB removable hard disk packs (not washing) that were about 70cm or more in diameter. The thing that always was a killer was linking a program image, moving the heads in a very visible but fairly random way.
With shareable libraries, we have delayed part of the linking until image activation. Even if the shareable library is already in memory, it still must be linked to the image before it can be started. With X11, there is a lot of stuff there and usually a burst of disk activity to bring it all in and to complete the linkage process, which is one reason why calc is always faster to start than Xcalc.
The long term solution when we have 64-bits of address space is to use based shareable libraries. This allows the image to be truely static-linked but to share code, which is a necessity for X.
I would end by saying that a large sequential read or write doesn't usualy cause scheduling problems. Especially with the higher speed disks, the main delays are cylinder to cylinder, settle time and to a lesser degree now, rotational latency. You can only read a track at a time in a cylinder, as the heads are preloaded, switching tracks within a cylinder is fast. If you hear your drive, you are usually just hearing the heads starting and stopping moving.
Your last point about backups is interesting. Some of the better backup programs will attempt to minimise head movement by sorting the data according to location. The disadvantage is that the volume shouldn't change during the backup.
Thius sound like something that would be a great help. I follow kernel traffic but not in detail as I don't have spare capacity for a 2.5 series kernel at the moment.
I have used fadvise type calls before and they are very useful, but are best when they can be left in binary code with the kernel ignoring the call if it isn't supported.
Yes, but it doesn't seem to be getting it right hence the problem requiring adaptive I/O scheduling. Certainly ext2 should automatically determine that, for example, our html web page read by Apache is sequential and the data should be read-ahead buffered. However, this doesn't seem to be helping.
At the same time I'm not quite sure where a solution like adaptive I/O scheduling would help on a real system because, in our example of an Apache server, whilst it is stalled writing a web page to you over TCP, it can be reading another page off disk for me. In a true server load, there is little think time because the next request comes in.
It seems that the main problem is that the file I/O primitives in Linux are a little too primitive. On some operating systems, there is another layer sitting between the file system and the user which provides record and block management. If I open a file for sequential read or write then the record/block manager knows that it could use read-ahead or write-behind.
The problem is that such I/O layers need to be implemented at least partially outside user-space in the case where the file is being simultaneously accessed to allow interprocess coordination. Also, to get best use, everything should use it.
I wondered about that too, especially if a Windows system is running with rsh or ssh then it is very easy to have a single Windows system as a compile engine rceiving requests from other systems.
Cygwin is great for this and even allows you to run your own makes and build scripts from Linux. The GPL restrictions only apply if you link to GPL code, which you won't if you are running Visual C.
You lose the IDE though, but generally you just want to spend most of your time developing on one platform and just checking that you can compile on the second, leaving the debugging on that platform until later.
I don't think there is a single 'HOWTO' on the subject, but essentially an FPGA is a chip with a large array of simple logic gates that may be interconnected in a programmable way. Tools exist to simulate and compile logic expressions into a form where they can be downloaded into an FPGA as a gate interconnection matrix. Once the FPGA has been programmed, it then will execute the logic function.
As with software, a lot of modules exist (mostly quite expensive) for logic blocks up to and including microprocessor cores. Rather than having a chip with a single function, it is possible to squeeze multiple functions upto the limits imposed by the gate count.
FPGAs can be reprogrammable, or programmable once only. There is a often fusable link inside that once blown prevents reprogramming or designs to be read out.
If you are producing quantity, then you can go from an FPGA component to a gate array which is programmed by a photographic mask during manufacture. The mask is prepared from the same program that created the FPGA. The setup costs are high, but once you talk about big numbers of chips, the component becomes significantly cheaper than an FPGA and often better performing.
It is impossible to know if any application may be vulnerable on any kind of box, but on Linux, we have a chroot 'jail' to run apps in (very good for servers they may serve too much) and iptables which can strictly limit the allowable ports.
If you really want to be paranoid, you can run a server inside a User Mode Linux VM which is only a little slower than a real box (only the system calls are emulated, not the instructions) and iptables on all IP connections into and out of the box.
It wouldn't solve every problem, but it would reduce the ill-effects of most worms.
Slashdot Mirror
The scaling was through the use of scale-foubles and perspective rather than digital effects. However the battles were humans (sometimes masked, depending on their role) blue screened on a digitally generated background with in the battle of Helm's Deep was about 95% of the force.
I'm not sure whether three years ongoing support for the small bsuiness version is doable, but I reckon two is.
Its like when I heard an android describing the security requirements for an electronic financial derivatives exchange:
"Its not like we're dealing with money"
No, just a government bond worth about $100000.
Another one at a bank, there is a story about the international payments system. It is split into two parts, the payment transmission system and the ledger. Great idea. Then why save money by having one guy to support both with admin status (he was an external too)? Apparently he siphoned off about $1mill when he was caught. The rumour says he was only caught because he got nervous after 9/11 and wanted to move his ill-gotten gains again. They were already offshore, but the bank queried the transaction and the scheme collapsed.
The thing is that the SWIFT system is designed around the four-eyes principle. You need two authenticators per transaction, but the number of organisatons that make procedurally easy to avoid these checks is frightening.
The whols SSL thing is based around certificates. We have seen problems with certificate handling, and certainly with the user acceptance of certificates. I prefer the "Web-of-Trust" method of PGP where certificates may be multiply signed and you may indicate your own trust in the certification authority.
The big difference between what the NSA have done and what the world of commerce needs and does is rather different. They really missed out on public-key cryptography, although it was arguably ffirst develped by GCHQ (the British variant of the NSA), it's significance was ignored.
The NSA are great cryptographers, as are GCHQ and whatever their equivalents are around the world. Unfortunately the cloak of secrecy hampers the rapid progress that can be made outside. Can the NSA get Russian mathematicians to look at their algorithms? I don't think so.
OTOH, if you have a good idea in the open you can post to sci.crypt and have it shot down by some of the best cryptographers in the world.
I was given an old Celeron based Deskpro, so I have built 2.5.64 on top of a 2.4.21pre5 kernel (in turn sitting on RH 8.0) but despite the usual modutils, bintutils, e2fs and so upgrades, I can't get past the decompressing of the kernel during boot. I want to get it sorted, but we'll see. The trouble is that this is the first unstable that I have run since 2.3 days so I have either forgotten half the tricks or they are out of date.
You don't even need that particular headache (I haven't had enough time to get my 2.5 Kernel up), but Redhat 8.0's 2.4.18 kernel supports low-latency (enabled via the /proc filesystem) and the ALSA drivers (0.9) drop in quite easily.
However from the headers at least, it seems that they didn't forget the x86, and I can't see them removing the support altogether.
I guess the SCO/Caldera boss has been using the Palantir too often in communication with Seattle.
If one goes back in history, a lot of MS's own hatred of Unix comes from their internal systems running on SCO Unix in the early days. Mind you, SCO were using MS compilers then.
My feeling is that this is an MS-inspired shot over the bows to scare VCs and IT chiefs away from Linux. In one case it really doesn;t matter whether SCO/Caldera wins or loses, it just hast to leave a suspicion in these people's minds.
This mean's that not only must IBM win, but they should win 'loudly', i.e., so those people who may be worried about Linux realise that they shouldn't be.
Having done a *lot* of work on AIX back in the early days, I can say that it borrowed some bits from BSD (who didn't then), but didn't from S5 Unix and their kernel was theirs. I didn't have their source code, but I was always cursing them for their incompatabilities which is why I can say they were different.
Also, AIX had a PS/2 distribution in the eary days, so they certianly had x86 architecture since way back when.
With Windows, they have no virtual console so they start the GUI early (presumably so you can fix broken services), but the system may not be fully ready for some time after that. I have logged in and found even basics like RPC still waiting to start, let alone stuff like PPPoE and routing.
With Linux, service startup goes a lot easier and you don't need X to be running to fix things.
Doesn't sound a million miles from the direction a certain other space agency seems to be taking, does it?
The main issue is that if the Linux system isn't selected during a reboot then sometimes anaconda (it is a Red-Hat Distro) barfs during the hardware recognition of my mouse and monitor.
Your idea is quite good for minimalistic databases like MySQL but not so good for the Oracles or whatever that do their own I/O management. They are aware of the diffeernce between tables and values and attempt to logical about the way that they manage them. Frequently they have their own LRU cache and read-ahead strategies independent of the underlying OS.
The things is that since we got rid of DOS, a pc is now capable of multiprogramming. It is quite normal to run two or more activities, say listening to music and writing something in an IDE. The trouble is when I want to start something new.
Normally the disks are using an elevator scan which when the disks are well used, it works quite well at sharing the disk out. The problem is that the svan works between the lowest and highest cylinder numbers in any request during the current scan. So if I scan from Cyl 10 to Cyl 100, fine but the next request is for Cyl 11 so I change direction, but the immediately following request is for 101. Sorry, I'm already headed towards 11 so 101 must wait for my scan to complete and reverse direction.
My feeling is that it would be better to wait only at the end of a cylinder scan to check for new requests. Elevator seeking is good, but only if you are within the range of the current scan.
One of the issues we were talking about earlier was opening a calculator in the middle of a task, say Xcalc. I had the privilege in my younger days to see a toploader which took 60MB removable hard disk packs (not washing) that were about 70cm or more in diameter. The thing that always was a killer was linking a program image, moving the heads in a very visible but fairly random way.
With shareable libraries, we have delayed part of the linking until image activation. Even if the shareable library is already in memory, it still must be linked to the image before it can be started. With X11, there is a lot of stuff there and usually a burst of disk activity to bring it all in and to complete the linkage process, which is one reason why calc is always faster to start than Xcalc.
The long term solution when we have 64-bits of address space is to use based shareable libraries. This allows the image to be truely static-linked but to share code, which is a necessity for X.
I would end by saying that a large sequential read or write doesn't usualy cause scheduling problems. Especially with the higher speed disks, the main delays are cylinder to cylinder, settle time and to a lesser degree now, rotational latency. You can only read a track at a time in a cylinder, as the heads are preloaded, switching tracks within a cylinder is fast. If you hear your drive, you are usually just hearing the heads starting and stopping moving.
Your last point about backups is interesting. Some of the better backup programs will attempt to minimise head movement by sorting the data according to location. The disadvantage is that the volume shouldn't change during the backup.
I have used fadvise type calls before and they are very useful, but are best when they can be left in binary code with the kernel ignoring the call if it isn't supported.
At the same time I'm not quite sure where a solution like adaptive I/O scheduling would help on a real system because, in our example of an Apache server, whilst it is stalled writing a web page to you over TCP, it can be reading another page off disk for me. In a true server load, there is little think time because the next request comes in.
The problem is that such I/O layers need to be implemented at least partially outside user-space in the case where the file is being simultaneously accessed to allow interprocess coordination. Also, to get best use, everything should use it.
Cygwin is great for this and even allows you to run your own makes and build scripts from Linux. The GPL restrictions only apply if you link to GPL code, which you won't if you are running Visual C.
You lose the IDE though, but generally you just want to spend most of your time developing on one platform and just checking that you can compile on the second, leaving the debugging on that platform until later.
Check the SEC fileings from Microsoft and VMware. If Microsoft had a significant interest )more than about 5% or so) it would have to be disclosed.
As with software, a lot of modules exist (mostly quite expensive) for logic blocks up to and including microprocessor cores. Rather than having a chip with a single function, it is possible to squeeze multiple functions upto the limits imposed by the gate count.
FPGAs can be reprogrammable, or programmable once only. There is a often fusable link inside that once blown prevents reprogramming or designs to be read out.
If you are producing quantity, then you can go from an FPGA component to a gate array which is programmed by a photographic mask during manufacture. The mask is prepared from the same program that created the FPGA. The setup costs are high, but once you talk about big numbers of chips, the component becomes significantly cheaper than an FPGA and often better performing.
If you really want to be paranoid, you can run a server inside a User Mode Linux VM which is only a little slower than a real box (only the system calls are emulated, not the instructions) and iptables on all IP connections into and out of the box.
It wouldn't solve every problem, but it would reduce the ill-effects of most worms.