Some of the big monitors (21") hate to sit back to back, as in two desks back to back. Especially when one moniitor is switched on, the other judders with the degauss.
What about cooperation? Sea Launch is a Boeing project, but the bits come from the Ukraine and Russia. Interestingly, it doesn't even launch from the territorial US, but rather moves into position somewhere near the equator. I guess that NASA's monoply can't touch it directly. The launch capacity is 6000Kg payloads to geosynch orbit, which is definitely the heavy side of medium.
The sad part of it is that all that Boeing are doing is building the payload module and the interstage stuff. The rocket is to all intents and purposes an import.
I wish you the best of luck with your career. Maybe NASA will slacken up on their control of commercial launches. Otherwise, maybe you should learn French and move (pay is still a problem in Russia/Ukraine).
Regrettably for NASA it isn't the only show in town. If I want serious heavy-lift then I should go to the Russians, otherwise there is always the new Ariane (as long as they can get it flying better than windows). Then if I have to buy US, then there is always Sea-Launch (a US-Russian cooperation), but I understand this isn't for very heavy payloads.
The main point of VMS is that you can do a lot with it. However, VMS security revolves around unique users, who have identifiers that give them access rights and sometimes privileges. Applications sometimes do their own thing, this has an unpleasant effect of bypassing the user model.
The main point is ensuring that accounts can be tied to users (as that is what gets audited) and that unlike Unix, you may have many system administrators with individual accounts. VMS also supports the concept of Security Administrators as separate from the System Administrator.
What you are looking for is documentation on who can do what and who approves it. For various reasons, it is a good idea to keep users or at least their rights identifiers around for a long time, even after users have left. It is better to disable the user until you are certain that their rights identifier is no longer in the system.
As with many systems, an OpenVMS console can be used for breaking into the system. However, it can be secured in such a way that bypassing security is extremely difficult.
This is probably the single best resource now. There used to be a nice little paperback which gave an overview but I doubt it is produced now. I would add that the biggest thing to learn about are users, rights and identifiers.
It depends upon the practice, but in general, when I have worked in places which were ISO9000 certified, at least they knew what they were doing, even if it was producing crap. In theory at least, whoever is your customer can then understand that you are producing crap and to act accordingly (unless they too are producing crap - arguably true in the case of Ford).
The problem is that when the shuttle was designed, everything was new. The basics of the Saturn V went back to Werner von Braun's ideas developed at the time of WW2. The ideas then evolved over a series of disposable boosters.
A disposable booster is a little like a formula one car, it only needs to last one race so it doesn't matter if you overrate it, because you will rebuild it from scratch. The Shuttle concept should have been more like the rally car, needing some maintenance but not a total rebuild between races.
What I don't understand is how management ignored the fact that the shuttle would need so much work between flights. The fact that the components were being overrated should have triggered some warning.
Yes, I agree with you that a more commercial approach would have been sensible, but who would want to take the risk?
The shuttle isn't that useful for satellite maintenance. It has been useful for Hubble and some other low orbit stuff (military spy satellites) but it can't get anywhere near geostationary orbit where the expensive birds sit. Anything going to geostationary orbit from the shuttle needs an auxillary booster (Payload Assist Module) for deployment and it is one way only.
The shuttle was only ever a prototype, yes a couple more should have been built but that is all. The redesign process should have been started immediately for version 2. As flight experience was built up, then this could be incorporated into version 2 which would be truely reusable.
This version 2 shuttle is the model that should have been mass produced.
Your references to the merchant adventurers is quite accurate, and is the foundation of double-entry accounting and the company limited by shares (I believe both started in Venice). The first English company was founded in the 16th Century for the exploration of a new route to China via a North-East passage. The voyage failed because of the ice and ship wintered in Archangel. The crew eventually were taken to Moscow and met up with the Czar and ended up with special trading rights. An excellent example of how you may fail to achieve the primary objective but achieve something else which is also profitable.
LOX is oxidiser and kerosene is the fuel. The only time that Buran only needs kerosene is when it transports itself around (A very neat trick, the US shuttle requires a special version of a 747 to transport it). Normally, LOX is required as well. You were probably referring to the Liquid Hydrogen fuel used in the US shuttle.
Yes, Buran could fly itself (it did to orbit) and I believe it was able to land in winds far higher than
the US Shuttle can achieve.
The top priorities for the Center admin. when I lefts were: (1) Safety, (2) Security, & (3) ISO 9000 compliance. He never even mentioned space flight! It's all about covering your...
ISO 9000 and its successors are about ensuring that everyone knows what they are supposed to do and how they are supposed to be doing it. It really isn't a bad thing even on projects the scale of the space program. ISO 9000 isn't a goal, it is a process. Using it reduces project risks by increasing transparency. If used properly, it even reduces bureaucracy.
When NASA wants to make a mission statement, it should start with space and aviation research and end by stating that it should be achieved via ISO9000. Risks are part of research, you don't want to blow anyone up or to lose the mission but if risks are quantified and accepted, no individual should be blamed.
I have spoken with people who worked in the Soviet Union. One of the biggest problems was whenever something went wrong, there would be a formal inquiry. Someone would whisper "Sabotage" and the KGB would be involved. Generally the blame would be transferred to the politically weakest person who could be blamed, and the person fired.
Sound a little like NASA now? That is, except the bit about the KGB (I'm sure that the FBI would be pleased to help).
Unfortunately, the computers that could compile and run it were painfully slow by today's standards and also memory limited. Some reduced variants were created (68R), but they still didn't exactly sing. It was used for some defence and telecoms applications in the UK, but was largely supplanted by CORAL 66 until ADA came along (also not exactly fast).
Not really. I worked on several "Enterprise" applications whereby shaving time off algorithms was vital to the competitiveness of the application. Graphics tricks are somewhat more specialised, but look inside a real flight simulator, and you will see how the programmers try to get everything to work as fast as possible (they work at the limits of the hardware).
The real problem for commercial users is that this level of optimisation is dirty, i.e., difficult to test and maintain. However, it is usually only need for a very small percentage of the application.
Does Win 2K run on Alpha, I heard that the support was dropped in NT4.0?
If HPaq are so dedicated towards Itanium, I can't see them wanting to let it go in the form where it may become a competitor to them. They may sell the hardware but would they sell Tru64? What commercial sense would there be for AMD to go for a chip that only will be supported by Open Source software. It would be nice, but very brave!
I would like it. I have an Alpha at home (running OpenVMS) and have written for Alphas in C, Fortran and COBOL and Bliss. My biggest client is still running Alphas for the server part of their application. Regrettably, they killed off the Alpha clients due to poor management of the development process and the low level of interest by their cutomers (who wanted Sparcs and Windoze, the latter because of the commodity cost of the platform).
Base 10 was on more recent computers too...
on
Hacker's Delight
·
· Score: 1
Converting decimal to binary and back again was relatively expensive so many commercial computers could work in decimal mode. The computer kept working in binary, it was just the numeric representation used. All that it meant was that the bytes were divided into two BCD nibbles, and numbers were represented as strings of 4-bit BCD digits.
Yes, but what do run on it, just Linux? HP 'owns' VMS and the dying Tru64. HP will be pushing VMS onto Itanium and will not be interested in keeping the Alpha users happy a moment lpnger than necessary. Microsoft dropped support for the Alpha from NT. Unless you develop your own apps, there isn't a lot of stuff that will run on an Alpha these days.
Alpha was great but unlike SPARC, it never had the numbers to get a low price for the high-end corporate workstation market. With better market saturation, it would have been a clear winner. At Digital, they had a saying "Digital make watches, don't they?" because of the poor efforts at corporate marketing. The Suns people were buying for the desktop were crap and badly engineered (lots of daughter boards, reducing reliability). However, people thought that the Suns were fast. Solaris was also not exactly easy to use (it has got better) and had a lot of problems whilst OpenVMS and Tru64 were boring (they worked). You bought 50 Sun workstations, then you went out and bought a Sun server or two to go with it. Sun didn't even have proper clustering in those days and failover was something you more or less had to do yourself. However, those Sun UltraSparcs were dirt cheap (low margin).
Alpha is nice, but I believe that Compaq and now HP have blown it through not understanding what they have. AMD believes that Hammer will be supported by Microsoft, so they have a market there.
Re:Advice: One new thing per project
on
Effective Java
·
· Score: 2
I have always worked on the principle of one new thing per project wherever possible. New languages are a no-no, so when I speced out projects, we stuck with languages where there was a good level of in-house knowledge - and delivered on time. Java is mainstream now so it remains a good choice even though there are OO languages that may be better. It is well supported and comes with a good collection of objects.
Yes, they have a lot of Digital's former design team.
A lot of people would love to see Alpha continue, but this would be a issue for HPaq/Intel who have a lot of the rights at the moment and wish to drive high end customers in the direction of Itanium.
I guess developing a new Alpha isn't easy because of the diversion of resouces away from x86. It doesn't sell the numbers associated with x86 so it would take longer to pay for itself. AMD has already spent a bundle on Hammer, so I can't see them wanting to change their direction and although Alpha was an engineer's dream, it was a marketing disaster.
Not correct, P2P programs only require a stable IP address while they are running. Many networks allocate IP addresses dynamically (to prevent servers), so you boot your computer and it comes up with one address, reboot and it comes up with another. P2P clients don't worry as they have otherways to find each other and serve files. Most P2P networks allow clients to resume downloads now so if the IP address changes, it shouldn't be a major problem to resume the d/l from another host.
At this time of year, Wales tends to be very wet. However the sheep are friendly!!!!
Back on topic, it is part of the EU whose patent office in Munich is carrying on like S/W patents are a 'done deal'. There is serious pressure to avoid this from people like FSF Europe amongst others, and ironically enough a lot of local S/W producers who would rather hire programmers than lawyers.
Yes, but you can't sell whatever resulted in the US. This is a serious limitation in a business where the US accounts for a large share of sales.
OTOH, it is kind of useful for Open Source because you can develop something outside the US that may leak back there without fear of reprisal. The only things is, that can't then expect whatver you produce to be placed on a major distribution.
All a TDR does is to generate a pulse and show the reflection. Suitable pulse generators can be made for a matter of a few dollars. A scope costs money, but this can be replaced by a good A/D and a computer.
There are already devices out there that replace a scope, that you can connect to a laptop. Too big to be PCMCIA, but not that large and can connect in via USB/Serial/Parallel interfaces.
I would guess that a PCMCIA sized device combining a pulse generator with a fast A/D would be difficult, but something a little larger would be possible.
A Fluke LANmeter is nice but not at all cheap. It is also well built like their multimeters and can take a certain amount of abuse.
I had a beamer with this feature and it seemd to be ok. If you are driving through varied territory (we have hills up to 800m/2450 feet in my neighbourhood) - some bits may be risky (especially as cold air can be trapped in 'frost hollows'), some bits not and I don't mind the bong warning me or less experienced codrivers to take it easy.
Slashdot Mirror
Some of the big monitors (21") hate to sit back to back, as in two desks back to back. Especially when one moniitor is switched on, the other judders with the degauss.
This is another item of interest for the big ticket sales promotion campaigns. I'm not talking about the liquid stuff either!!!
A good locksmith can even work from photographs (even without the blanks).
The sad part of it is that all that Boeing are doing is building the payload module and the interstage stuff. The rocket is to all intents and purposes an import.
I wish you the best of luck with your career. Maybe NASA will slacken up on their control of commercial launches. Otherwise, maybe you should learn French and move (pay is still a problem in Russia/Ukraine).
Regrettably for NASA it isn't the only show in town. If I want serious heavy-lift then I should go to the Russians, otherwise there is always the new Ariane (as long as they can get it flying better than windows). Then if I have to buy US, then there is always Sea-Launch (a US-Russian cooperation), but I understand this isn't for very heavy payloads.
The main point is ensuring that accounts can be tied to users (as that is what gets audited) and that unlike Unix, you may have many system administrators with individual accounts. VMS also supports the concept of Security Administrators as separate from the System Administrator.
What you are looking for is documentation on who can do what and who approves it. For various reasons, it is a good idea to keep users or at least their rights identifiers around for a long time, even after users have left. It is better to disable the user until you are certain that their rights identifier is no longer in the system.
As with many systems, an OpenVMS console can be used for breaking into the system. However, it can be secured in such a way that bypassing security is extremely difficult.
This is probably the single best resource now. There used to be a nice little paperback which gave an overview but I doubt it is produced now. I would add that the biggest thing to learn about are users, rights and identifiers.
It depends upon the practice, but in general, when I have worked in places which were ISO9000 certified, at least they knew what they were doing, even if it was producing crap. In theory at least, whoever is your customer can then understand that you are producing crap and to act accordingly (unless they too are producing crap - arguably true in the case of Ford).
A disposable booster is a little like a formula one car, it only needs to last one race so it doesn't matter if you overrate it, because you will rebuild it from scratch. The Shuttle concept should have been more like the rally car, needing some maintenance but not a total rebuild between races.
What I don't understand is how management ignored the fact that the shuttle would need so much work between flights. The fact that the components were being overrated should have triggered some warning.
Yes, I agree with you that a more commercial approach would have been sensible, but who would want to take the risk?
The shuttle isn't that useful for satellite maintenance. It has been useful for Hubble and some other low orbit stuff (military spy satellites) but it can't get anywhere near geostationary orbit where the expensive birds sit. Anything going to geostationary orbit from the shuttle needs an auxillary booster (Payload Assist Module) for deployment and it is one way only.
This version 2 shuttle is the model that should have been mass produced.
Your references to the merchant adventurers is quite accurate, and is the foundation of double-entry accounting and the company limited by shares (I believe both started in Venice). The first English company was founded in the 16th Century for the exploration of a new route to China via a North-East passage. The voyage failed because of the ice and ship wintered in Archangel. The crew eventually were taken to Moscow and met up with the Czar and ended up with special trading rights. An excellent example of how you may fail to achieve the primary objective but achieve something else which is also profitable.
Yes, Buran could fly itself (it did to orbit) and I believe it was able to land in winds far higher than the US Shuttle can achieve.
When NASA wants to make a mission statement, it should start with space and aviation research and end by stating that it should be achieved via ISO9000. Risks are part of research, you don't want to blow anyone up or to lose the mission but if risks are quantified and accepted, no individual should be blamed.
I have spoken with people who worked in the Soviet Union. One of the biggest problems was whenever something went wrong, there would be a formal inquiry. Someone would whisper "Sabotage" and the KGB would be involved. Generally the blame would be transferred to the politically weakest person who could be blamed, and the person fired.
Sound a little like NASA now? That is, except the bit about the KGB (I'm sure that the FBI would be pleased to help).
Unfortunately, the computers that could compile and run it were painfully slow by today's standards and also memory limited. Some reduced variants were created (68R), but they still didn't exactly sing. It was used for some defence and telecoms applications in the UK, but was largely supplanted by CORAL 66 until ADA came along (also not exactly fast).
The real problem for commercial users is that this level of optimisation is dirty, i.e., difficult to test and maintain. However, it is usually only need for a very small percentage of the application.
If HPaq are so dedicated towards Itanium, I can't see them wanting to let it go in the form where it may become a competitor to them. They may sell the hardware but would they sell Tru64? What commercial sense would there be for AMD to go for a chip that only will be supported by Open Source software. It would be nice, but very brave!
I would like it. I have an Alpha at home (running OpenVMS) and have written for Alphas in C, Fortran and COBOL and Bliss. My biggest client is still running Alphas for the server part of their application. Regrettably, they killed off the Alpha clients due to poor management of the development process and the low level of interest by their cutomers (who wanted Sparcs and Windoze, the latter because of the commodity cost of the platform).
Converting decimal to binary and back again was relatively expensive so many commercial computers could work in decimal mode. The computer kept working in binary, it was just the numeric representation used. All that it meant was that the bytes were divided into two BCD nibbles, and numbers were represented as strings of 4-bit BCD digits.
Alpha was great but unlike SPARC, it never had the numbers to get a low price for the high-end corporate workstation market. With better market saturation, it would have been a clear winner. At Digital, they had a saying "Digital make watches, don't they?" because of the poor efforts at corporate marketing. The Suns people were buying for the desktop were crap and badly engineered (lots of daughter boards, reducing reliability). However, people thought that the Suns were fast. Solaris was also not exactly easy to use (it has got better) and had a lot of problems whilst OpenVMS and Tru64 were boring (they worked). You bought 50 Sun workstations, then you went out and bought a Sun server or two to go with it. Sun didn't even have proper clustering in those days and failover was something you more or less had to do yourself. However, those Sun UltraSparcs were dirt cheap (low margin).
Alpha is nice, but I believe that Compaq and now HP have blown it through not understanding what they have. AMD believes that Hammer will be supported by Microsoft, so they have a market there.
I have always worked on the principle of one new thing per project wherever possible. New languages are a no-no, so when I speced out projects, we stuck with languages where there was a good level of in-house knowledge - and delivered on time. Java is mainstream now so it remains a good choice even though there are OO languages that may be better. It is well supported and comes with a good collection of objects.
A lot of people would love to see Alpha continue, but this would be a issue for HPaq/Intel who have a lot of the rights at the moment and wish to drive high end customers in the direction of Itanium.
I guess developing a new Alpha isn't easy because of the diversion of resouces away from x86. It doesn't sell the numbers associated with x86 so it would take longer to pay for itself. AMD has already spent a bundle on Hammer, so I can't see them wanting to change their direction and although Alpha was an engineer's dream, it was a marketing disaster.
Not correct, P2P programs only require a stable IP address while they are running. Many networks allocate IP addresses dynamically (to prevent servers), so you boot your computer and it comes up with one address, reboot and it comes up with another. P2P clients don't worry as they have otherways to find each other and serve files. Most P2P networks allow clients to resume downloads now so if the IP address changes, it shouldn't be a major problem to resume the d/l from another host.
Back on topic, it is part of the EU whose patent office in Munich is carrying on like S/W patents are a 'done deal'. There is serious pressure to avoid this from people like FSF Europe amongst others, and ironically enough a lot of local S/W producers who would rather hire programmers than lawyers.
OTOH, it is kind of useful for Open Source because you can develop something outside the US that may leak back there without fear of reprisal. The only things is, that can't then expect whatver you produce to be placed on a major distribution.
There are already devices out there that replace a scope, that you can connect to a laptop. Too big to be PCMCIA, but not that large and can connect in via USB/Serial/Parallel interfaces.
I would guess that a PCMCIA sized device combining a pulse generator with a fast A/D would be difficult, but something a little larger would be possible.
A Fluke LANmeter is nice but not at all cheap. It is also well built like their multimeters and can take a certain amount of abuse.
I had a beamer with this feature and it seemd to be ok. If you are driving through varied territory (we have hills up to 800m/2450 feet in my neighbourhood) - some bits may be risky (especially as cold air can be trapped in 'frost hollows'), some bits not and I don't mind the bong warning me or less experienced codrivers to take it easy.