which is a good thing - a program that crashes during development is easy to fix. A program that slowly gets worse and worse and is only noticed when shipped is difficult to fix. I know which I prefer, from bitter experience! And to top it all, this was a 10k loc program, hardly anything major - imagine you had one of these leaks in a million loc app, built out of a dozen components.
Actually, its the result of a Delphi programmer being given so much money he thinks he's the best compiler designer the world has known, and a bunch of Microsofties being fooled by Sun's marketing machine into thinking Java was the best language ever.
First we learn that memory leaks are impossible in the CLR. Later, when our app consumes all available RAM, we learn that Microsoft's marketing department and all those MS bloggers who told us how useless reference counting was and that the GC was the perfect answer to all our memory problems, lied through their teeth to sell us the new visual studio.
That's true of every program, allocating memory has always been a relatively slow operation. For speed, one good trick is to use a custom allocator - create yourself a chunk of memory that holds blocks of fixed sizes. (eg think of it like an array of 1 byte), then create another for 2byte blocks etc. When you allocate, just take the next block off the appropriate 'array'. Its very fast, and allows you to reuse the memory very efficiently (as the 'arrays' can't get fragmented)
C# managed heap does something similar, so does the COM heap.
And given the level of skill the average programmer has, anything that makes memory leaks less likely (though not impossible) has got to be seen as a good thing. NO! It is not a good thing, if a program slowly leaks memory then it just makes it harder to find the bug. If you have to reboot the app every week because it has a little leak, no-one's going to be bothered (except the users who see it slowly getting slower). If it has to be restarted daily then you're going to be looking to fix the bug.
It is easy to leak memory in C++, if you don't know what you're doing. Its easy to leak memory in C#/Java if you don't know what you're doing. That the language makes it easy for you to avoid becoming a better programmer is NOT a good thing.
I have a good analogy - Firefox. I use FF a lot, I like it, but it does tend to increase its memory usage over time, and has been rightly criticised for it. Now, I'm sure the 'bug' is an aspect of its design and not a programming bug (and I don't want to start a FF memory discussion - I'm only using it as a real-world example) but just imagine if *every* program was like FF - slowly using more and more RAM over time until you restarted it.
This is what you're asking for when you say that its ok for the average programmer to use C# because the app will have fewer leaks: you'll get fewer leaks. Not none. If the app leaked like a sieve, it'd be spotted in development/test and fixed; if it leaks slowly enough so it passes an hour's testing in certification, then it'll be shipped - and its you that'll get to find the bug as you use it.
Of course, the wrst case scenario with UAVs would be a hijacking scenario
Oh no, the worst case scenario is where the now-truly-autonomous UAV decides that a civilian target is actually the enemy and starts attacking it. If the UAV comes at you, you have plenty of other defences to tackle it as if it were an enemy unit. If you lost control of your UAV miles away, it could do a lot of damage that you didn't want doing. Considering all wars nowadays are more peace-keeping operations where you're there to protect the civilians against the bad guys, this would be the end of it. And just imagine the political fallout.
ok, so COM was an 'answer' to the OMG's object broker (I'm not sure about that, back in those days, the number of Windows people who even knew Corba existed could be counted on one hand).
Fortunately, the differences between them are as wide as the differences between sun rpc and dce-rpc. They're just not the same thing, which is what the OP was implying - that COM was a MS 'extended+embrace version' of CORBA.
FYI. CORBA is not based on DCOM at all. CORBA came about from a OO version of lrpc, whereas COM (and therefore DCOM) inherited from DCE-RPC (which was fantastic system, ho well)
There's a lot of commonality, especially in the terminology used, but that's because they solve the same problem. The implementation is completely different and you shouldn't get the 2 confused.
There are excellent reasons to push Mono; in the long term, Linux needs something better than C/C++. Not really, there's no evidence that C# is better than C/C++ - not once you've ignored the hype that's come out of MS over the last couple of years proclaiming C#/.NET to be the answer to world hunger, global peace et al. (remember, they said that last time with COM too, and no doubt will be scathing about garbage collection when the next technology refresh from MS comes along).
If you think C# is better than C/C++, for arguments sake, there's alwats Java. Don't forget that the differences between C# and Java are tiny. And of course, MS can still do to Mono what Sun did to MS-Java.
If Linux needs more specialised languages, there's hundreds of them already. There's no reason to get another, especially one that duplicate nearly all of Java's features. Python, Perl, Ruby, PHP even - these are all good at various aspects of coding different type of application, combined with shell scripts and the "unix way" of reusing commands through pipes, you'll find there's no need for Mono.
Considering you have to pay the licence fee to receive broadcasts, and the player is a free adjunct to that; then yes, I think they should actually refund you every penny you spent on the free player that you cannot access.
Lets just hope that the BBC doesn't make all its media player technology geeks redundant in the cutbacks that are going on! The cutbacks are a direct example of why they must offer content in the most cost effective way, and a player that runs on Windows does reach the vast majority of people. Once its done, no doubt a full version will appear for Linux, then Mac. You just have to be patient.
I think the absolute best thing the BBC can do is release a gcc-compilable module (or just a closed source binary and API) and let the F/OSS community build their own players on top of it.
RAM uses all the power it uses no matter how much is used. The hardware still needs to keep the "unused" chips fed with power to maintain their state, even if that state is garbage values.
I think the load v idle factor is more important, when you use your computer you know you're draining the battery/burning dead trees and you accept that. When you put it into an idling state, you want it to use as little as possible. PCs tend to be kept in an idling state for far longer than a used state (eg overnight, while you do something else for a while, while you sit staring at the screen thinking of what to do next, while the PC waits and waits for you to press the next key as your typing)
Perhaps the point of the article wasn't to criticise the current version, but to raise awareness that power consumption is directly linked to applications, especially daemons, and that developers might like to remember that next time they do a bit of coding on them.
I got to disagree about the narration, it made it more reminiscent of a 50s film noir private eve detective movie. I mean, it was a 50s private eye movie complete with rainy city and hot dame with the bright red lippy. The narration was in keeping with all that.
The ending was better in the remake though. Perhaps the new one has bits of both, and to be honest they could put everything on the DVD so I could choose the options I want! Of course they won't, they'll just try to rip us off with the same movie, 2 deleted scenes, a voice-over from Rutger reminiscing about his Guiness adverts and charge us £15 for it... actually, if they put Rutger's Guiness adverts on the disc, it'd be worth every penny!
Well, firstly don't believe everything you read on wikipedia, or we'll tell you you're dumb:-)
Secondly, Google published their findings (some links) of their HDD reliability, and while they say the MTBF cited by the manufacturers errs on the optimistic side, its still not that far out.
For a 300,000-hour MTBF, one would expect an AFR of 1.46%, but the best the Googlers observed was 1.7% in the first year, rising to over 8.6% in the third year. So MTBF has a direct correlation to failures when you have a lot of drives, which is obvious as its a 'mean' average for lifetimes. So while it doesn't say anything about the life expectancy of any given drive it does say whether one drive will last longer than another of lesser MTBF. eg the 100,000 v 50,000 MTBF drives - if you had a million of each type of drive, after 100,000 hours 50% of the 100k drives, and all of the 50k drives would be dead.
It doesn't mean anything to a single drive though, if you buy one of that million drive batch, its all down to luck whether you got the one that dies first or the one that dies last.
I was dumbing it down a little for easier understanding. In Apache, using mod_php (like mod_perl too), you fork a heap of processes and reuse them. But you only ever have 1 client running on each process. In apache 2 (not in worker MPM mode) I believe you'd run the php sessions in a single process.
I didn't realise it was that larger, but CPU cycles doesn't tell the whole story. On a 1.8Ghz CPU, that's... 0.03 seconds on Windows.
Still, if only PHP could fix their threading issues in their modules, it'd make sense to run scripts in worker threads (using Apache 2, of course) and Linux webservers would appear to run faster.
Its kind of a fallacy that 'forking' processes on Windows is significantly more expensive than forking them on Linux. I think it is somewhat more expensive, but that doesn't alter the fact that forking processes on linux is still expensive in the first place.
So, we needed ways to make things go faster - mod_php for example, that ran php scripts inside an apache process, but you still had to fork the apache process for each web request because of many thread-safety issues in php modules. This was also a security problem because every php script ran as the apache user. So the next idea was to start an apache process for each client and re-use it until that client disconnected (and stayed disconnected). This is the fastCGI approach.
With windows, you had 2 ways of running PHP scipts: as a CGI application (slow due to new processes all the time), and as an ISAPI (think of this as the equivalent of mod_php) module. The ISAPI one worked but you had the thread-safety issues of PHP to contend with (just like on Apache 2 that doesn't spawn worker processes).
In summary: nothing much to see, someone's just released fastCGI for IIS now so you have the same configuration options for IIS as you have for Apache.
I'm not sure whether you think IIS has a text file or not...
Still, for my fellow readers:
With IIS7, all IIS configuration is now stored in a simple XML file called applicationHost.config, which is placed by default in the \windows\system32\inetsrv\config directory from an Apache v IIS blog entry that also discusses the fastCGI module.
The trouble with that argument is that *everything* on Linux is unsupported. Nvidia drivers just being one of the most obvious.
eg. If I have a problem with an application, can I get support or am I directed to RTFM, use the forums, or search Google?
Even the things that are supported on a version require support with configuration, practically nothing works out-of-the-box, or it works but is completely insecure or needs configuring with your setup.
I know this is the way Linux is, and is not a bad thing per-se, but it means that the ordinary user who wants to click-and-go will not find Linux suitable for their needs unless someone else has set it up for them.
none of them should be a defacto choice by virtue of being taught at university. Teach kids the concepts, use specialised languages that demonstrate what it is trying to achieve and how it is doing it. Don't ever try to teach kids so they come out with a book full of cut&paste examples of how to program. The moment they hit real work, they'll flounder otherwise.
I was taught Concurrent Euclid for my threading classes. It taught me what was going on, and I can apply that knowledge to whatever language I have to use at my job, or whatever language I decide to use in the future.
Absolutely, GC langauges are pretty poor at multi-core applications simply becuase they have to cater for the worst-case in every case.
As a quick example, I was discussing singleton creation with someone and we tested the difference between a statically initialised singleton object and one that was initialised behind a lock. (in C# BTW). On my single-core laptop the differences were significant (1.5 second running time v 6 for the lock), but when I ran the same 2 apps on a fast multi-CPU server, it took 23 seconds for both apps. Obviously the VM was optimising locking away on my 1-core, but had to put proper locks in to ensure data consistency on the multi-cpu box. Note that when I ran the apps with affinity for a single-core, they still performed worse than my laptop.
I know from experience that locking is the single biggest cause of highly-parallel performance issues so its not too much of a surprise, but the length of time it took to run was.
Difference between 1993 and 2007 code is that old code... uses 10000 times more RAM and still performs slower than the old stuff did on a 10Mhz CPU!:-0
Slashdot Mirror
which is a good thing - a program that crashes during development is easy to fix. A program that slowly gets worse and worse and is only noticed when shipped is difficult to fix. I know which I prefer, from bitter experience! And to top it all, this was a 10k loc program, hardly anything major - imagine you had one of these leaks in a million loc app, built out of a dozen components.
Actually, its the result of a Delphi programmer being given so much money he thinks he's the best compiler designer the world has known, and a bunch of Microsofties being fooled by Sun's marketing machine into thinking Java was the best language ever.
:)
And its known as C-Octothorpe.
First we learn that memory leaks are impossible in the CLR. Later, when our app consumes all available RAM, we learn that Microsoft's marketing department and all those MS bloggers who told us how useless reference counting was and that the GC was the perfect answer to all our memory problems, lied through their teeth to sell us the new visual studio.
That's true of every program, allocating memory has always been a relatively slow operation. For speed, one good trick is to use a custom allocator - create yourself a chunk of memory that holds blocks of fixed sizes. (eg think of it like an array of 1 byte), then create another for 2byte blocks etc. When you allocate, just take the next block off the appropriate 'array'. Its very fast, and allows you to reuse the memory very efficiently (as the 'arrays' can't get fragmented)
C# managed heap does something similar, so does the COM heap.
It is easy to leak memory in C++, if you don't know what you're doing. Its easy to leak memory in C#/Java if you don't know what you're doing. That the language makes it easy for you to avoid becoming a better programmer is NOT a good thing.
I have a good analogy - Firefox. I use FF a lot, I like it, but it does tend to increase its memory usage over time, and has been rightly criticised for it. Now, I'm sure the 'bug' is an aspect of its design and not a programming bug (and I don't want to start a FF memory discussion - I'm only using it as a real-world example) but just imagine if *every* program was like FF - slowly using more and more RAM over time until you restarted it.
This is what you're asking for when you say that its ok for the average programmer to use C# because the app will have fewer leaks: you'll get fewer leaks. Not none. If the app leaked like a sieve, it'd be spotted in development/test and fixed; if it leaks slowly enough so it passes an hour's testing in certification, then it'll be shipped - and its you that'll get to find the bug as you use it.
Of course, the wrst case scenario with UAVs would be a hijacking scenario
Oh no, the worst case scenario is where the now-truly-autonomous UAV decides that a civilian target is actually the enemy and starts attacking it. If the UAV comes at you, you have plenty of other defences to tackle it as if it were an enemy unit. If you lost control of your UAV miles away, it could do a lot of damage that you didn't want doing. Considering all wars nowadays are more peace-keeping operations where you're there to protect the civilians against the bad guys, this would be the end of it. And just imagine the political fallout.
ok, so COM was an 'answer' to the OMG's object broker (I'm not sure about that, back in those days, the number of Windows people who even knew Corba existed could be counted on one hand).
Fortunately, the differences between them are as wide as the differences between sun rpc and dce-rpc. They're just not the same thing, which is what the OP was implying - that COM was a MS 'extended+embrace version' of CORBA.
FYI. CORBA is not based on DCOM at all. CORBA came about from a OO version of lrpc, whereas COM (and therefore DCOM) inherited from DCE-RPC (which was fantastic system, ho well)
There's a lot of commonality, especially in the terminology used, but that's because they solve the same problem. The implementation is completely different and you shouldn't get the 2 confused.
I agree Java is a disaster, but WTF do you think C#/.NET/Mono is?
clue: MS-Java, repackaged with a different name.
disclaimer: some people like Java. Still no excuse for creating an incompatible fork of it becuase you don't want/can't work with Sun.
If you think C# is better than C/C++, for arguments sake, there's alwats Java. Don't forget that the differences between C# and Java are tiny. And of course, MS can still do to Mono what Sun did to MS-Java.
If Linux needs more specialised languages, there's hundreds of them already. There's no reason to get another, especially one that duplicate nearly all of Java's features. Python, Perl, Ruby, PHP even - these are all good at various aspects of coding different type of application, combined with shell scripts and the "unix way" of reusing commands through pipes, you'll find there's no need for Mono.
Considering you have to pay the licence fee to receive broadcasts, and the player is a free adjunct to that; then yes, I think they should actually refund you every penny you spent on the free player that you cannot access.
Lets just hope that the BBC doesn't make all its media player technology geeks redundant in the cutbacks that are going on! The cutbacks are a direct example of why they must offer content in the most cost effective way, and a player that runs on Windows does reach the vast majority of people. Once its done, no doubt a full version will appear for Linux, then Mac. You just have to be patient.
I think the absolute best thing the BBC can do is release a gcc-compilable module (or just a closed source binary and API) and let the F/OSS community build their own players on top of it.
one good thing is that MS has a lot of good lawyers, so if/when these licences ever got challenged in court, you'd expect them to hold up pretty well.
RAM uses all the power it uses no matter how much is used. The hardware still needs to keep the "unused" chips fed with power to maintain their state, even if that state is garbage values.
I think the load v idle factor is more important, when you use your computer you know you're draining the battery/burning dead trees and you accept that. When you put it into an idling state, you want it to use as little as possible. PCs tend to be kept in an idling state for far longer than a used state (eg overnight, while you do something else for a while, while you sit staring at the screen thinking of what to do next, while the PC waits and waits for you to press the next key as your typing)
Perhaps the point of the article wasn't to criticise the current version, but to raise awareness that power consumption is directly linked to applications, especially daemons, and that developers might like to remember that next time they do a bit of coding on them.
All those quotes will be lost in time, like tears in rain.
I got to disagree about the narration, it made it more reminiscent of a 50s film noir private eve detective movie. I mean, it was a 50s private eye movie complete with rainy city and hot dame with the bright red lippy. The narration was in keeping with all that.
.. actually, if they put Rutger's Guiness adverts on the disc, it'd be worth every penny!
The ending was better in the remake though. Perhaps the new one has bits of both, and to be honest they could put everything on the DVD so I could choose the options I want! Of course they won't, they'll just try to rip us off with the same movie, 2 deleted scenes, a voice-over from Rutger reminiscing about his Guiness adverts and charge us £15 for it.
Secondly, Google published their findings (some links) of their HDD reliability, and while they say the MTBF cited by the manufacturers errs on the optimistic side, its still not that far out. For a 300,000-hour MTBF, one would expect an AFR of 1.46%, but the best the Googlers observed was 1.7% in the first year, rising to over 8.6% in the third year. So MTBF has a direct correlation to failures when you have a lot of drives, which is obvious as its a 'mean' average for lifetimes. So while it doesn't say anything about the life expectancy of any given drive it does say whether one drive will last longer than another of lesser MTBF. eg the 100,000 v 50,000 MTBF drives - if you had a million of each type of drive, after 100,000 hours 50% of the 100k drives, and all of the 50k drives would be dead.
It doesn't mean anything to a single drive though, if you buy one of that million drive batch, its all down to luck whether you got the one that dies first or the one that dies last.
I was dumbing it down a little for easier understanding. In Apache, using mod_php (like mod_perl too), you fork a heap of processes and reuse them. But you only ever have 1 client running on each process. In apache 2 (not in worker MPM mode) I believe you'd run the php sessions in a single process.
I didn't realise it was that larger, but CPU cycles doesn't tell the whole story. On a 1.8Ghz CPU, that's... 0.03 seconds on Windows.
Still, if only PHP could fix their threading issues in their modules, it'd make sense to run scripts in worker threads (using Apache 2, of course) and Linux webservers would appear to run faster.
Its kind of a fallacy that 'forking' processes on Windows is significantly more expensive than forking them on Linux. I think it is somewhat more expensive, but that doesn't alter the fact that forking processes on linux is still expensive in the first place.
So, we needed ways to make things go faster - mod_php for example, that ran php scripts inside an apache process, but you still had to fork the apache process for each web request because of many thread-safety issues in php modules. This was also a security problem because every php script ran as the apache user. So the next idea was to start an apache process for each client and re-use it until that client disconnected (and stayed disconnected). This is the fastCGI approach.
With windows, you had 2 ways of running PHP scipts: as a CGI application (slow due to new processes all the time), and as an ISAPI (think of this as the equivalent of mod_php) module. The ISAPI one worked but you had the thread-safety issues of PHP to contend with (just like on Apache 2 that doesn't spawn worker processes).
In summary: nothing much to see, someone's just released fastCGI for IIS now so you have the same configuration options for IIS as you have for Apache.
Still, for my fellow readers: With IIS7, all IIS configuration is now stored in a simple XML file called applicationHost.config, which is placed by default in the \windows\system32\inetsrv\config directory from an Apache v IIS blog entry that also discusses the fastCGI module.
The trouble with that argument is that *everything* on Linux is unsupported. Nvidia drivers just being one of the most obvious.
eg. If I have a problem with an application, can I get support or am I directed to RTFM, use the forums, or search Google?
Even the things that are supported on a version require support with configuration, practically nothing works out-of-the-box, or it works but is completely insecure or needs configuring with your setup.
I know this is the way Linux is, and is not a bad thing per-se, but it means that the ordinary user who wants to click-and-go will not find Linux suitable for their needs unless someone else has set it up for them.
I believe you're getting Computer Science and Software Engineering confused :-)
Computer Science is an art
Programming is a craft
Software Engineering is a science
and Systems Architecture is a way.
just lets not discuss what project management is.
none of them should be a defacto choice by virtue of being taught at university. Teach kids the concepts, use specialised languages that demonstrate what it is trying to achieve and how it is doing it. Don't ever try to teach kids so they come out with a book full of cut&paste examples of how to program. The moment they hit real work, they'll flounder otherwise.
I was taught Concurrent Euclid for my threading classes. It taught me what was going on, and I can apply that knowledge to whatever language I have to use at my job, or whatever language I decide to use in the future.
Absolutely, GC langauges are pretty poor at multi-core applications simply becuase they have to cater for the worst-case in every case.
As a quick example, I was discussing singleton creation with someone and we tested the difference between a statically initialised singleton object and one that was initialised behind a lock. (in C# BTW). On my single-core laptop the differences were significant (1.5 second running time v 6 for the lock), but when I ran the same 2 apps on a fast multi-CPU server, it took 23 seconds for both apps. Obviously the VM was optimising locking away on my 1-core, but had to put proper locks in to ensure data consistency on the multi-cpu box. Note that when I ran the apps with affinity for a single-core, they still performed worse than my laptop.
I know from experience that locking is the single biggest cause of highly-parallel performance issues so its not too much of a surprise, but the length of time it took to run was.
Difference between 1993 and 2007 code is that old code ... uses 10000 times more RAM and still performs slower than the old stuff did on a 10Mhz CPU! :-0