AIX has become a good workhorse over the years, although it still gives some problems when porting. The users that you mention have their apps working nicely now on AIX will not want to change until they see equal performance and reliability on Linux. Easy system management is always useful, but already we have tools supporting Linux like Webmin. Ok, it isn't SMIT, but it is fast and extensible.
The thing is, AIX is a traditional closed source system. It gets better, but Linux evolves faster. There are simply more heads available for Linux than there are for AIX. IBM only really sees AIX as a platform to rest their servers on. With Linux, the advantage is all they have to care about is ensuring it works with their hardware, so they can save a lot of money.
Their real interest now is consultancy, and there are a lot more potential Linux systems out there than AIX.
I think that such physical things as atom bombs, guns and chemical weapons killed a fair share of those people
In the case of Stalin and Mao, most deaths happened because of a combination of political science and poor economics. Both starved their populations and worked them to deaththrough improperly thought out work programs. Between them, they probably killed between 30 and 40 million people. Definitely worse than any technical means, although it took a few years longer.
Of the three quoted, only Hitler relied on technology, and without politics, he wouldn't have got there.
There have been medical writeups since Roman times and crtainly quite detailed views of a persons health since the 17th Century or so. Essentially, little or no allergies untill the 1930s or so.
Nut allergies are even newer - and extremly life threatening. It is fascinating that in this case the IgA was transplanted with the liver, but how do all the other people become allergic????
The issue is not that there is a 3% error - as you say there a lot of problems over accounting. The problem is that it seems to have taken place over a long period. This implies that day to day accounting may not be quite what it should be.
Before, I have heard about 10Kg to 20Kg discrepencies happening elsewhere (Sellafield/Windscale) but never 200Kg.
I just fetched everything I could as source packackages (I use apt under rpm) like someone else here mentioned. I rebuilt to get the 686 binaries and installed those.
As for MPlayer, I ran./configure, make and make install and it went in very easily. Most things do (of course they tend to end up in/usr/local unless specified otherwise, but thats ok with me). To be honest, I think compilation from source wouldn't be such a problem if imessages that were simply informative could be filtered. Failure messages could just be turned into something more intelligable like 'you must install package x first'. This is the main benefit of package managers, that they at least give reasonable dependancy messages.
you don't live in Redmond do you?
on
Potato Bazookas
·
· Score: 1
I could imagine one or two more people there who might be interested in shooting penguins!
To be honest, packaging MPlayer as binary is far from easy because it has so many dependancies, especially on some software that is changing. It really is easier to install from source and to run configure and build on your own system to avoid a dependency hell which brings back memories of another well known company.
Once built and optimised for your architecture it does run well, and on my poor little notebook (500MHz PIII), it beats the pants off media player under Win 2K.
Having to build from source is inconvenient, but unless MPlayer is linked statically, I reaaly thing that this is better than installing a prepacked binary.
Ah yes, that would certainly explain things. MOVC3 also ties up some registers.
I loved that VAX macro but was rarely allowed to use it because of portability issues. The joke is that Digital wrote a Macro-32 compiler to get VMS up on the Alpha. It was sufficiently high level that it could be converted without too many problems. I loved that assembler though, like the PDP-11, the archiitecture was orthogonal so everything kind of made sense.
Regrettably our high end VAXes couldn't be used for anything like Mandlebrots as the QA people had to vet all migrations into production. I managed to do some neat things elsewhere on the smaller systems that we had in development though.
It appears that Duff was working on the VAX, it suprises me why he didn't code the thing so that on a VAX, it produces the instruction:
MOVC3 cnt, src dst
Yes, the good old VAX could do some pretty awesome things as instructions (it was the king of CISC). This particular instruction is in the architecture so it will work whichever model you use. There was also a MOVC5 which would allow you to give different sizes for src and destination and if srclen was
In later times, we would use an #ifdef to either use Duff's device or use the single instruction version.
Another varient of Duff's device is the long multiply (much used for public key encryption). Instead of moves, you have an add carry and multiply sequence.
Yes, it does seem unlikely that it would really work but I still don't like the idea of speeding up the process - it would be just a little too dangerous if it functioned properly.
Effficient bureacracy did a lot of damage during the era of Nazi Germany. It wasn't enough to win them the war but it caused a lot of people to be eliminated (all with supporting paperwork). This is an extreme example, but I like the fact that certain processes needed by law enforcement take time - it makes everyone think whether they really should be doing this.
Re:Elegant code
on
Immortal Code
·
· Score: 2, Interesting
This is one of the reasons for the projects to emulate historical computers. It doesn't matter whether it is a PDP-11, an IBM 360 or whatever, there is often a simulator out there. The odd thing about it is that due to the speed of modern hardware, you can often run the emulations at the proper speed.
Actually, Duff did this the most elegantly in C. However, I had seen the equivalent in assembler much earlier. The buffer mover used by the RSX11-M executive running on the 16-bit PDP-11 used the assembler version and was written in the seventies. I'm sure that other implementations were written but Digital's highly configurable executive had todelivered in source form.
The author was a certain David N. Cutler. He works for Microsoft now.
Maybe it is getting interesting again...
on
Immortal Code
·
· Score: 1
I gave up on WIred after they went through a spate of cutting edge graphical design which carefully made the text almost impossible to read - and that was the paper edition. On attempting to read the electronic edition, yes, the content was more visible but generally it wasn't that good.
Maybe it is time to start reading WIred again, so it is good for people to let us know that it is worth looking at.
One of the things that caused problems for the KGB and the Stasi (the state security organisation of the former DDR) was the work involved in processing an intercept. Despite the fact that both regimes were totally fscked, they used legalistic and bureaucratic procedures. The system became limited by the need to approve and process their equivalent of intercept warrants and what to do with the information.
Neither the KGB nor the STASI had much in the way of computer power to process the information gathered and the legal procedures were manual. What is happening here is that one of the last brakes to quick intercepts is being removed. The bottleneck connected with the approval process made law enforcement types think before ordering an intercept: Do they really need it?
It will be possible for intercepts to be implemeneted with less controls and far faster than in Soviet Russia).
You mention VMS, so you probably came across a little toy called the Run-Time-Library, which gave a language independent set of tools to do a lot of things, from messing with queues to complex math.
Calling the library meant that what you were building a layer upon something that was already debugged. However, the library routines contained sanity checks of their own, so if you supplied a null rather than a pointer where one was needed, you found out about it quickly.
We have a series of different library tools now. Unfortunately, not all try to check what the caller is doing (it does cost performance to be paranoid). What is good though is it means tht you aren't building pyramids on quicksand. Yes, the RDBMS is a layer, but there is nothing to stop us from creating distinct layers within our own systems - layers that can be tested and debugged independently of the application as a whole.
It has advantages too, because it means that you can come back and reengineer something fundemental at a low cost. You can even change the layer itself.
However, in the end I don't worry about debugging a large program because the compile/link/debug/edit cycle takes too long. I don't mind large systems (one I have recently worked on is over 30 million LOC on the backend alone) - but I prefer the programs and modules to be smaller.
Must you build the whole thinmg for debugging? Is it not possible to build and debug KDE at the component or subsystem level rather than to always try to go for the whole thing?
Probably the single largest thing I have needed when working on debugging/building large systems was enough diskspace. Processor power and memory were usually not a major problem because although we would be running the entire system, only part would be in debug at any one time. The rest would be instrumented, but that is all.
It seems like someone should be looking very hard at the engineering aspects if this is really a bottleneck.
Unlikely for a grade school teacher........
on
How High is Your AP?
·
· Score: 1
Unless the Grade School teacher is heavily sponsored and given a leave of absence during term-time.
It takes some time to go up Everest and it costs serious money. Organised expeditions are charging $20000 or so for participants. The license alone to climb Everest costs about $50000 or more per expedition. If you add Sherpas, equipment and so on, you can see where the costs go.
On the other hand, connecting the people up is generally a good thing. It helps democracy by keeping people informed. Informed people are less likely to be potential rebel sympathisers.
Re:Centimetre Wave (SHF and above) Radar
on
Tuxedo Park
·
· Score: 1
Actually, this seems like it is another of those things with a varied history (depends on where you came from). The Encylopedia Britannica and the IEEE put the inventor as an American in 1921. However Calpoly credit Randall and Boot for making an invention in 1940. However the Japenese invented the divided anode magnetron in 1928. Most agree that an american, Spencer invented the microwave oven though.
I suppose the truth of it is probably that the compact and relatively high power magnetron was invented by the British for use in radar and this was why a prototype was sent to the US as they didn't know how to make them in this form before. The previous microwave amplifiers such as the klystron were large, fragile an not so efficient.
It was these factors (size, robustness and efficiency) that made the magentron so useful for mobile warfare.
For me, I thought I knew the figures (but I have never planned a/c) - however in a big trading room, we could feel the room go cold as they transitioned from CRTs to TFT displayed.
In particular, when the a/c came on, cold draughts became noticeable and unpleasant. The end result was to reduce air flow and heat exchange capacity. I believe this means that water and power consumption went seriously down. At the same time the PCs were upped so that they arrived with PSUs of 350w instead of 200w or 250w. This didn't seem to affect the room nearly as much.
Of course, the biggest factor was Sept 11th. SInce then, the financial markets have been doing little and the traders have not escaped being downsized. If a trading position isn't in use, the PCs and the screens are just left powered off and new positions remain unequipped.
I really like apt4rpm because as you say, it sorts out the dependencies very nicely. It has worked for me since RH 6.something and has helped me a lot.
Ocassionally I hit a library dependancy problem under RH8.0, then I have to get and build the source RPM. Overall, I haven't had a big problem running apps built for Gnome 1.4 or 2 under RH8.0. I understand about where jwz is coming from, nobody really like a major version upgrade, but the payback with 8.0 is great and compensates for the inconvenience.
I installed the latest Mplayer under RH8.0, using the rpms and it works fine apart from some minor stuff. For example, full-screen was 'fixed' after the last release and I can flip between a window and full screen. Unfortunately after being in full screen, the display window can no longr be moved.
Apart from that, yes the interface is a little clunky, but it works and some of the skins make things easier. My biggest UI complaint is that although it is possible to rebind the keys, there is no way to see the current bindings. It is a little complex to run and to optimise, but this is something that is easily fixable.
I use the latest, GATOS XV drivers and frankly, the performance on my 500MHz Dell Notebook is better than WMP on a 1GHz machine un der Win2K. I use the low latency stuff, of course, but this is just setting an option in proc to enable under an RH 8.0 kernel.
Ok, if I want the DVD menus, there is always Ogle (also performs well). Ogle doesn't seem quite as stable but I can't complain about mplayer.
So much? Interesting, because I thought a human disapates about 400W/hr. Mind you a lot of that is dumped as humidity, which is easier to get rid of with just ventilation. A monitor dumps its heat through convection, warming a lot of more of the surrounding air.
Centimetre Wave (SHF and above) Radar
on
Tuxedo Park
·
· Score: 2, Interesting
The chain of radar stations constructed in the late thirties were VHF/UHF only.
The problem was that the wavelengths used were not sufficiently well reflected by smaller objects such as periscopes or to give the resolution neccessary for bomb navigation. Hence the invention of the magnetron by the British which produced RF at 3cm or above at high power. Unfortunately British industry couldn't produce the device cheaply enough (a magnetron dpends upon a very precisely engineered cavity). Loomis was responsible for the ideas for mass production of the magnetron in the mid 40s.
The magnetron was used in warships and by planes (such as night fighters) but it was not permitted over German held territory until towards the end of the war so it didn't help bomber command much (the Americans flew by day, so they had less problems with navigation). It was decided that the wreckage of a magnetron (it is basiclly a precisely machined lump of metal) would give German intelligence enough information to be able to duplicate it.
If you work in a room full of screens, say in a banks trading room, the reduced level of heat from LCDs is quite noticeable. In some cases, they have have even had to downgrade the airconditioning, because it was cooling the room too fast after the switch. Mind you some of that heat saving is going because of the computers going to 300w power-supplies to keep the P4s running at 2+GHz.
Slashdot Mirror
The thing is, AIX is a traditional closed source system. It gets better, but Linux evolves faster. There are simply more heads available for Linux than there are for AIX. IBM only really sees AIX as a platform to rest their servers on. With Linux, the advantage is all they have to care about is ensuring it works with their hardware, so they can save a lot of money.
Their real interest now is consultancy, and there are a lot more potential Linux systems out there than AIX.
In the case of Stalin and Mao, most deaths happened because of a combination of political science and poor economics. Both starved their populations and worked them to deaththrough improperly thought out work programs. Between them, they probably killed between 30 and 40 million people. Definitely worse than any technical means, although it took a few years longer.
Of the three quoted, only Hitler relied on technology, and without politics, he wouldn't have got there.
Nut allergies are even newer - and extremly life threatening. It is fascinating that in this case the IgA was transplanted with the liver, but how do all the other people become allergic????
Before, I have heard about 10Kg to 20Kg discrepencies happening elsewhere (Sellafield/Windscale) but never 200Kg.
As for MPlayer, I ran ./configure, make and make install and it went in very easily. Most things do (of course they tend to end up in /usr/local unless specified otherwise, but thats ok with me). To be honest, I think compilation from source wouldn't be such a problem if imessages that were simply informative could be filtered. Failure messages could just be turned into something more intelligable like 'you must install package x first'. This is the main benefit of package managers, that they at least give reasonable dependancy messages.
I could imagine one or two more people there who might be interested in shooting penguins!
Once built and optimised for your architecture it does run well, and on my poor little notebook (500MHz PIII), it beats the pants off media player under Win 2K.
Having to build from source is inconvenient, but unless MPlayer is linked statically, I reaaly thing that this is better than installing a prepacked binary.
I loved that VAX macro but was rarely allowed to use it because of portability issues. The joke is that Digital wrote a Macro-32 compiler to get VMS up on the Alpha. It was sufficiently high level that it could be converted without too many problems. I loved that assembler though, like the PDP-11, the archiitecture was orthogonal so everything kind of made sense.
Regrettably our high end VAXes couldn't be used for anything like Mandlebrots as the QA people had to vet all migrations into production. I managed to do some neat things elsewhere on the smaller systems that we had in development though.
MOVC3 cnt, src dst
Yes, the good old VAX could do some pretty awesome things as instructions (it was the king of CISC). This particular instruction is in the architecture so it will work whichever model you use. There was also a MOVC5 which would allow you to give different sizes for src and destination and if srclen was In later times, we would use an #ifdef to either use Duff's device or use the single instruction version.
Another varient of Duff's device is the long multiply (much used for public key encryption). Instead of moves, you have an add carry and multiply sequence.
Effficient bureacracy did a lot of damage during the era of Nazi Germany. It wasn't enough to win them the war but it caused a lot of people to be eliminated (all with supporting paperwork). This is an extreme example, but I like the fact that certain processes needed by law enforcement take time - it makes everyone think whether they really should be doing this.
This is one of the reasons for the projects to emulate historical computers. It doesn't matter whether it is a PDP-11, an IBM 360 or whatever, there is often a simulator out there. The odd thing about it is that due to the speed of modern hardware, you can often run the emulations at the proper speed.
The author was a certain David N. Cutler. He works for Microsoft now.
Maybe it is time to start reading WIred again, so it is good for people to let us know that it is worth looking at.
Neither the KGB nor the STASI had much in the way of computer power to process the information gathered and the legal procedures were manual. What is happening here is that one of the last brakes to quick intercepts is being removed. The bottleneck connected with the approval process made law enforcement types think before ordering an intercept: Do they really need it?
It will be possible for intercepts to be implemeneted with less controls and far faster than in Soviet Russia).
Calling the library meant that what you were building a layer upon something that was already debugged. However, the library routines contained sanity checks of their own, so if you supplied a null rather than a pointer where one was needed, you found out about it quickly.
We have a series of different library tools now. Unfortunately, not all try to check what the caller is doing (it does cost performance to be paranoid). What is good though is it means tht you aren't building pyramids on quicksand. Yes, the RDBMS is a layer, but there is nothing to stop us from creating distinct layers within our own systems - layers that can be tested and debugged independently of the application as a whole.
It has advantages too, because it means that you can come back and reengineer something fundemental at a low cost. You can even change the layer itself.
However, in the end I don't worry about debugging a large program because the compile/link/debug/edit cycle takes too long. I don't mind large systems (one I have recently worked on is over 30 million LOC on the backend alone) - but I prefer the programs and modules to be smaller.
Probably the single largest thing I have needed when working on debugging/building large systems was enough diskspace. Processor power and memory were usually not a major problem because although we would be running the entire system, only part would be in debug at any one time. The rest would be instrumented, but that is all.
It seems like someone should be looking very hard at the engineering aspects if this is really a bottleneck.
It takes some time to go up Everest and it costs serious money. Organised expeditions are charging $20000 or so for participants. The license alone to climb Everest costs about $50000 or more per expedition. If you add Sherpas, equipment and so on, you can see where the costs go.
On the other hand, connecting the people up is generally a good thing. It helps democracy by keeping people informed. Informed people are less likely to be potential rebel sympathisers.
I suppose the truth of it is probably that the compact and relatively high power magnetron was invented by the British for use in radar and this was why a prototype was sent to the US as they didn't know how to make them in this form before. The previous microwave amplifiers such as the klystron were large, fragile an not so efficient.
It was these factors (size, robustness and efficiency) that made the magentron so useful for mobile warfare.
In particular, when the a/c came on, cold draughts became noticeable and unpleasant. The end result was to reduce air flow and heat exchange capacity. I believe this means that water and power consumption went seriously down. At the same time the PCs were upped so that they arrived with PSUs of 350w instead of 200w or 250w. This didn't seem to affect the room nearly as much.
Of course, the biggest factor was Sept 11th. SInce then, the financial markets have been doing little and the traders have not escaped being downsized. If a trading position isn't in use, the PCs and the screens are just left powered off and new positions remain unequipped.
Ocassionally I hit a library dependancy problem under RH8.0, then I have to get and build the source RPM. Overall, I haven't had a big problem running apps built for Gnome 1.4 or 2 under RH8.0. I understand about where jwz is coming from, nobody really like a major version upgrade, but the payback with 8.0 is great and compensates for the inconvenience.
Apart from that, yes the interface is a little clunky, but it works and some of the skins make things easier. My biggest UI complaint is that although it is possible to rebind the keys, there is no way to see the current bindings. It is a little complex to run and to optimise, but this is something that is easily fixable.
I use the latest, GATOS XV drivers and frankly, the performance on my 500MHz Dell Notebook is better than WMP on a 1GHz machine un der Win2K. I use the low latency stuff, of course, but this is just setting an option in proc to enable under an RH 8.0 kernel.
Ok, if I want the DVD menus, there is always Ogle (also performs well). Ogle doesn't seem quite as stable but I can't complain about mplayer.
So much? Interesting, because I thought a human disapates about 400W/hr. Mind you a lot of that is dumped as humidity, which is easier to get rid of with just ventilation. A monitor dumps its heat through convection, warming a lot of more of the surrounding air.
The problem was that the wavelengths used were not sufficiently well reflected by smaller objects such as periscopes or to give the resolution neccessary for bomb navigation. Hence the invention of the magnetron by the British which produced RF at 3cm or above at high power. Unfortunately British industry couldn't produce the device cheaply enough (a magnetron dpends upon a very precisely engineered cavity). Loomis was responsible for the ideas for mass production of the magnetron in the mid 40s.
The magnetron was used in warships and by planes (such as night fighters) but it was not permitted over German held territory until towards the end of the war so it didn't help bomber command much (the Americans flew by day, so they had less problems with navigation). It was decided that the wreckage of a magnetron (it is basiclly a precisely machined lump of metal) would give German intelligence enough information to be able to duplicate it.
In the EU they are looking at recycling taxes. Monitors are more expensive to recycle than LCDs, even though the leaad is worth something.
If you work in a room full of screens, say in a banks trading room, the reduced level of heat from LCDs is quite noticeable. In some cases, they have have even had to downgrade the airconditioning, because it was cooling the room too fast after the switch. Mind you some of that heat saving is going because of the computers going to 300w power-supplies to keep the P4s running at 2+GHz.