Many phone exchanges only clear down the call when the originating party hangs up (or after a timeout - it won't keep the line open forever where the recipient is on hook and caller is still off hook).
I found this out when a friend called me, and my mother decided she didn't want me talking to him, so pressed the hook on the phone for a couple of seconds. She was very surprised when she let go of the hook when we just kept right on talking - since it was him who'd originated the call.
There's an old proverb: 'A bad worker blames his tools'.
I don't have this problem with Perl.
Re:Sometimes the correct answer is the simplest
on
Why Corporates Hate Perl
·
· Score: 4, Insightful
Your regexp example isn't awfully good - any language that has regexp support will have lines like that. These days, PHP has regexp support (possibly always has), C has regexp support, C++ has it, Java has it, and I expect that even C# has regexp libraries.
The alternative to a regular expression is usually a very convoluted parser that's a lot of effort to support.
IPv6 has neither of these features. It is difficult to deal with in software (I know, I do this for a living), does not fit into any native data type (and won't until we move to 128 bit architectures
It's not that difficult. In fact, it's not difficult at all.
Just for fun, a retrocomputing project I'm working on is an ethernet card for an 8 bit 1980s home computer (the Sinclair Spectrum). Dealing with 32 bit addresses on an 8 bit system is trivially easy, even in Z80 assembly language. It would be no harder to deal with 128 bit addresses on a 32 bit machine.
I have a dedicated server in London. When I go away on holiday, I start up Squid on the server, so I can still see BBC programmes while I'm away. I got to introduce my friends in the US to things like Top Gear and Little Britain this way (my American friends are 'worldly' enough to be able to understand the rather British-centric comedy).
I suspect the BBC iPlayer detects open proxies, however, if you own the machine, you can make sure they can't connect back to detect a proxy.
No, it improves the situation greatly. Your view is far too simplistic.
A big power station is a lot more efficient than a small car engine. A typical gasoline engine is perhaps 15% efficient. The combined cycle gas power station they recently built here makes use of about 80% of the thermal energy of the gas. The gas turbines are the first stage, then waste heat from the gas turbines drive a steam turbine, then any heat that is still left is used to heat the NSC sports centre swimming pool and the sports centre itself. Those efficiencies are simply impossible for a small internal combustion engine on a car.
An electric car is a lot more efficient than a gasoline one - for a start, it doesn't idle, and you can have regenerative braking.
If you change the power generation (say, from coal to nuclear) you don't have to also change the fleet of vehicles. Automatically, overnight, they are suddenly nuclear powered.
No it is not. It puts Apple's current success into context: it shows that it has been a tremendous turnaround of a company that was once - in the estimation of the very successful businessman, Michael Dell - ready for the scrapheap. It shows the turnaround has been so successful that it has even surpassed Michael Dell's own business. Devoid of this context, the current market cap is pretty meaningless to most people who don't follow the stock market.
What bothers me about this is that you take away risk to persons from war, and those persons are more willing to wage war...which leads to more war.
Probably the only thing that has saved us since WWII is the fact that the leadership realised that they were personally no longer safe in the context of nuclear weapons - so to save their own skins, they strenously avoided world war 3.
If we can wage war at no risk to ourselves, then war will become a more viable option - which is a bad development.
No one's life was in the hands of a text message. Airplanes fly on the principles set out by Bernoulli and Newton, *not* Marconi. A radio failure is something that's trained for, and the aircraft's captain was merely using an additional tool at his disposal; a radio failure should never be something that's life threatening.
Cell phones, certainly GSM cell phones *DO* interfere with aircraft communication systems.
It was a dark and stormy night (OK, it wasn't stormy, just light rain, with a cloud base at 600 feet, and it was very dark). I was returning from the UK with a friend in his light aircraft. It was my friend's first IFR approach for real - in the clouds, at night. The air was smooth though, so the conditions weren't too bad for a first time.
Unfortuantely he had forgotten to turn off his phone.
ATC cleared us for the approach, giving us a final vector to the localiser (the localiser is what gives you horizontal guidance on an instrument landing) - the vector is a heading ATC gives you such that you intercept the localiser course sufficiently far out on the approach and at a shallow enough angle that it's practical to start your approach. Just as the localiser needle started moving towards the centre, *all* audio was blocked by this noise:
Bip-bip bip-bip b b b bip-bip bip-bip brrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
It was very loud and very distracting. We could no longer hear any instructions from ATC. Fortunately, I could take over flying the approach while my friend hunted down his cell phone and turned it off, and fortunately, while this racket was going on, ATC didn't give us any new instructions.
If you have a GSM phone, chances you'll know exactly the sound I describe above. They are terrible at interfering with all kinds of stuff.
Don't get me started on AJAX. It doesn't matter what pretty framework you wrap it up in, it fundamentally sucks hard. The RAF apparently had a term "graunching" - forcing something to fit in a place where it shouldn't. AJAX is just one massive graunch, and any AJAX system is a bit like a Vogon spaceship - congealed, rather than designed.
You seem to be under the mistaken impression that object orientation is a silver bullet. It isn't. Going from a well-written COBOL program to something 'that supports objects' doesn't buy you anything except having the program in a language that more people know (which is a valid benefit, of course, but a personnel benefit, rather than a technical one). You can write modular programs in COBOL already (and have been able to for decades).
But wages are lower in Britian, there's the rub. A typical Briton will pay twice as much for products as a typical American, yet probably earns half as much - effectively, products in the UK are 4 times more expensive (when compared relative to income) than they are in the US.
I still use one. My 21 inch Trinitron still works fine and has a nicer picture than all but the most expensive LCD panels. Its only drawback is its enormous weight, leaving a permanent bow in my desk!
If the original poster is right, it's not ports that are the issue, it's the number of *sockets* it's grabbing. It's doing the equivalent of
fd[x]=socket(AF_INET, SOCK_DGRAM, 0);
2500 times. You don't need to do that to use a random port for each reply, you just open the socket when you need to. Unless, of course, the underlying OS's call to socket() is extremely inefficient.
5x the mass != 5G as other posters have pointed out (more like 1.7G if it has the same density as Earth).
In any case, if the planet can support life, any life that evolved there will have evolved to be adapted to the gravitational environment there - to life on that planet, it wouldn't be a "crushing G load". 1.7G isn't even crushing to a human, although it wouldn't be fun walking about.
My LED bike light is something like 5000K. When you first turn it on, it looks very pale violet rather than white (like most "white" LEDs). But after a couple of minutes you are used to it. Since I cycle on unlit roads, whenever a car comes by with normal halogen headlights, its headlights look as orange as low pressure sodium lights. But I'm sure the car's driver sees the same light as white (and see my headlight as pale violet).
Probably Elite (disc version) for the BBC Micro. It certainly had the best sounds. I never played ArcElite, but those who did think it's the best, and some of the fundamental features of Oolite are inspired by ArcElite.
Using electronic memory is far easier than say, a disc. With a disc, you need a lot of precision mechanical stuff in addition to electronics. With a semiconductor, you don't need all the mechanical stuff. It would take me about 45 minutes to make a circuit on breadboard to read a ROM that was made in 1975 onto a modern MacBook Pro. To homebrew a laser disc player would probably be two years work.
That's also how the Spectrum loading scheme worked, too. A zero took less time than a 1. As a consequence there wasn't a fixed baud rate, but the average speed with the Spectrum's scheme was 1500 bps. Custom schemes were also made too, but they were all generally the same 'constant number of zero crossings per bit', but at different frequencies (generally for higher loading speed, or to make tape copying less trivial). Some people even used Manchester encoding (which was faster for the same fundamental frequency). I've toyed with the idea of making an NRZI tape save/load routine using 4B5B coding, since it should work and no one did it (at least on the Spectrum!)
Yes - I thought this too - the article's slashdotted at the moment but the summary makes me think he made a mountain from a molehill. In the Sinclair Spectrum world, loading Speccy tapes on to a PC, and encoding them in a useful format (TZX) has been a solved problem for years.
All these tape formats were physically pretty similar when it comes to how they were encoded, and the same techniques could have been used by looking at any home computer emulator that loaded stuff from tape even if the details were different.
Slashdot Mirror
Many phone exchanges only clear down the call when the originating party hangs up (or after a timeout - it won't keep the line open forever where the recipient is on hook and caller is still off hook).
I found this out when a friend called me, and my mother decided she didn't want me talking to him, so pressed the hook on the phone for a couple of seconds. She was very surprised when she let go of the hook when we just kept right on talking - since it was him who'd originated the call.
There's an old proverb: 'A bad worker blames his tools'.
I don't have this problem with Perl.
Your regexp example isn't awfully good - any language that has regexp support will have lines like that. These days, PHP has regexp support (possibly always has), C has regexp support, C++ has it, Java has it, and I expect that even C# has regexp libraries.
The alternative to a regular expression is usually a very convoluted parser that's a lot of effort to support.
It's not that difficult. In fact, it's not difficult at all.
Just for fun, a retrocomputing project I'm working on is an ethernet card for an 8 bit 1980s home computer (the Sinclair Spectrum). Dealing with 32 bit addresses on an 8 bit system is trivially easy, even in Z80 assembly language. It would be no harder to deal with 128 bit addresses on a 32 bit machine.
I have a dedicated server in London. When I go away on holiday, I start up Squid on the server, so I can still see BBC programmes while I'm away. I got to introduce my friends in the US to things like Top Gear and Little Britain this way (my American friends are 'worldly' enough to be able to understand the rather British-centric comedy).
I suspect the BBC iPlayer detects open proxies, however, if you own the machine, you can make sure they can't connect back to detect a proxy.
No, it improves the situation greatly. Your view is far too simplistic.
A big power station is a lot more efficient than a small car engine. A typical gasoline engine is perhaps 15% efficient. The combined cycle gas power station they recently built here makes use of about 80% of the thermal energy of the gas. The gas turbines are the first stage, then waste heat from the gas turbines drive a steam turbine, then any heat that is still left is used to heat the NSC sports centre swimming pool and the sports centre itself. Those efficiencies are simply impossible for a small internal combustion engine on a car.
An electric car is a lot more efficient than a gasoline one - for a start, it doesn't idle, and you can have regenerative braking.
If you change the power generation (say, from coal to nuclear) you don't have to also change the fleet of vehicles. Automatically, overnight, they are suddenly nuclear powered.
No it is not. It puts Apple's current success into context: it shows that it has been a tremendous turnaround of a company that was once - in the estimation of the very successful businessman, Michael Dell - ready for the scrapheap. It shows the turnaround has been so successful that it has even surpassed Michael Dell's own business. Devoid of this context, the current market cap is pretty meaningless to most people who don't follow the stock market.
What bothers me about this is that you take away risk to persons from war, and those persons are more willing to wage war...which leads to more war.
Probably the only thing that has saved us since WWII is the fact that the leadership realised that they were personally no longer safe in the context of nuclear weapons - so to save their own skins, they strenously avoided world war 3.
If we can wage war at no risk to ourselves, then war will become a more viable option - which is a bad development.
Mode S and other associated gubbins already exists for that type of thing.
No one's life was in the hands of a text message. Airplanes fly on the principles set out by Bernoulli and Newton, *not* Marconi. A radio failure is something that's trained for, and the aircraft's captain was merely using an additional tool at his disposal; a radio failure should never be something that's life threatening.
Cell phones, certainly GSM cell phones *DO* interfere with aircraft communication systems.
It was a dark and stormy night (OK, it wasn't stormy, just light rain, with a cloud base at 600 feet, and it was very dark). I was returning from the UK with a friend in his light aircraft. It was my friend's first IFR approach for real - in the clouds, at night. The air was smooth though, so the conditions weren't too bad for a first time.
Unfortuantely he had forgotten to turn off his phone.
ATC cleared us for the approach, giving us a final vector to the localiser (the localiser is what gives you horizontal guidance on an instrument landing) - the vector is a heading ATC gives you such that you intercept the localiser course sufficiently far out on the approach and at a shallow enough angle that it's practical to start your approach. Just as the localiser needle started moving towards the centre, *all* audio was blocked by this noise:
Bip-bip bip-bip b b b bip-bip bip-bip brrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
It was very loud and very distracting. We could no longer hear any instructions from ATC. Fortunately, I could take over flying the approach while my friend hunted down his cell phone and turned it off, and fortunately, while this racket was going on, ATC didn't give us any new instructions.
If you have a GSM phone, chances you'll know exactly the sound I describe above. They are terrible at interfering with all kinds of stuff.
Don't get me started on AJAX. It doesn't matter what pretty framework you wrap it up in, it fundamentally sucks hard. The RAF apparently had a term "graunching" - forcing something to fit in a place where it shouldn't. AJAX is just one massive graunch, and any AJAX system is a bit like a Vogon spaceship - congealed, rather than designed.
You seem to be under the mistaken impression that object orientation is a silver bullet. It isn't. Going from a well-written COBOL program to something 'that supports objects' doesn't buy you anything except having the program in a language that more people know (which is a valid benefit, of course, but a personnel benefit, rather than a technical one). You can write modular programs in COBOL already (and have been able to for decades).
But wages are lower in Britian, there's the rub. A typical Briton will pay twice as much for products as a typical American, yet probably earns half as much - effectively, products in the UK are 4 times more expensive (when compared relative to income) than they are in the US.
I still use one. My 21 inch Trinitron still works fine and has a nicer picture than all but the most expensive LCD panels. Its only drawback is its enormous weight, leaving a permanent bow in my desk!
This is my favorite power loss story.
It's great.
http://www.alioth.net/tmp/vaxen.html
If the original poster is right, it's not ports that are the issue, it's the number of *sockets* it's grabbing. It's doing the equivalent of
fd[x]=socket(AF_INET, SOCK_DGRAM, 0);
2500 times. You don't need to do that to use a random port for each reply, you just open the socket when you need to. Unless, of course, the underlying OS's call to socket() is extremely inefficient.
Well, actually, 60 years - don't forget it'll take 20 years for the signal to get back when the probe arrives.
5x the mass != 5G as other posters have pointed out (more like 1.7G if it has the same density as Earth).
In any case, if the planet can support life, any life that evolved there will have evolved to be adapted to the gravitational environment there - to life on that planet, it wouldn't be a "crushing G load". 1.7G isn't even crushing to a human, although it wouldn't be fun walking about.
My LED bike light is something like 5000K. When you first turn it on, it looks very pale violet rather than white (like most "white" LEDs). But after a couple of minutes you are used to it. Since I cycle on unlit roads, whenever a car comes by with normal halogen headlights, its headlights look as orange as low pressure sodium lights. But I'm sure the car's driver sees the same light as white (and see my headlight as pale violet).
Probably Elite (disc version) for the BBC Micro. It certainly had the best sounds. I never played ArcElite, but those who did think it's the best, and some of the fundamental features of Oolite are inspired by ArcElite.
Pity it's so expensive - from my usual electronics supplier it's over an order of magnitude more expensive than NOR flash of the same size.
Using electronic memory is far easier than say, a disc. With a disc, you need a lot of precision mechanical stuff in addition to electronics. With a semiconductor, you don't need all the mechanical stuff. It would take me about 45 minutes to make a circuit on breadboard to read a ROM that was made in 1975 onto a modern MacBook Pro. To homebrew a laser disc player would probably be two years work.
That's also how the Spectrum loading scheme worked, too. A zero took less time than a 1. As a consequence there wasn't a fixed baud rate, but the average speed with the Spectrum's scheme was 1500 bps. Custom schemes were also made too, but they were all generally the same 'constant number of zero crossings per bit', but at different frequencies (generally for higher loading speed, or to make tape copying less trivial). Some people even used Manchester encoding (which was faster for the same fundamental frequency). I've toyed with the idea of making an NRZI tape save/load routine using 4B5B coding, since it should work and no one did it (at least on the Spectrum!)
Yes - I thought this too - the article's slashdotted at the moment but the summary makes me think he made a mountain from a molehill. In the Sinclair Spectrum world, loading Speccy tapes on to a PC, and encoding them in a useful format (TZX) has been a solved problem for years.
All these tape formats were physically pretty similar when it comes to how they were encoded, and the same techniques could have been used by looking at any home computer emulator that loaded stuff from tape even if the details were different.