I don't think speed of payroll systems is any longer an advantage of Cobol. Computers today are thousands of times faster than they were 40 years ago, but payrolls are not any larger. So if Cobol running on a machine clocked at 1MHz was fast enough in the past, even the slowest possible language running on a modern CPU will be fast enough today.
The part that sucks is the name. To me, 'HP Superdome' conveys images of leaky Buckminster Fuller spheres at Epcot Disney World and Britain's miserable 'millennium' celebration. Or perhaps the foreheads of the aliens from Mars Attacks mixed with some kind of overhyped sporting event. Either way I wouldn't want a pulsating monstrosity like that in my server room, unless it were some kind of server chysalis from which a flight of shimmering laptop butterflies would one day break out.
Trust your uncle Bjarne. If you don't use it, you don't pay for it. You need not worry that the language is turning into C# or Python. It's still just as efficient for bare-metal programming as C ever was (and more so in some cases, with template specialization at compile time).
As for 'automatic memory management', that was one of C's big features. Remember the 'auto' keyword?
Firstly, C# version 3 (supported by current Mono, and also by that alternative Mono implementation from Microsoft) is much more functional in style, if you want it to be. IIRC it has let-expressions (perhaps as part of LINQ) and lambdas, and it might even have algebraic data types (I need to check that).
Secondly, F# is a pretty sweet functional language that compiles to CLR bytecode, letting you do anything you can do in C#.
I must admit I was thinking of GPLv2 (which I have read many times) not v3. V2 says
You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
Not under some other licence that meets some conditions: under the GPLv2 itself.
By my reading, 'Corresponding Source' defined here means the source code of the program, including scripts such as Makefiles. But not the whole compiler toolchain. By your argument of 'everything needed to build the binary' you would have to ship an entire operating system down to the bootloader. If that's really your interpretation then I agree, the GPL's requirements are pretty onerous. It doesn't seem to be the interpretation that everyone else is using.
Not true. You must distribute the GPL'd code under the GPL and your own code under a license which does not impose any restrictions not found in the GPL
This depends on whether copyright law in your country considers linking together code to create a derived work. If it does, then your resulting program which links in GPLed code is a derived work of that code, and you need permission from all copyright holders to distribute it, which is to say you must distribute under GPL or not at all.
OTOH, if your own code is separate from the GPLed code and courts would not consider it a derived work, then of course it's your right to distribute it however you want.
The GPL covers a lot more than just source code, it also covers reproducibility and crossdevelopment toolchains.
Which part of the GPL says that?
And actually, yes, the proprietary software we use allows unlimited distribution of binaries we produce using it without entangling us into having to distribute the source and build chain years later.
I thought you were talking about distributing a copy of the program itself, not a binary produced using it. Admittedly if you link GPL code into your program you must then distribute it under GPL or not at all.
Interesting... I hadn't realized it was such a problem in practice. I thought you would just include source code on the same CD as the binary, and that would be it.
If some forgotten mid-development cycle binary produced by code that was never checked in and only existed for as long as it took a developer to fix a bug and compile it again gets 'distributed' as part of a legal discovery process that grabs the contents of every hard disk in the company, do we get to go out of business because we can't comply with a GPL demand?
The worst that happens here is that you are infringing copyright by distributing the software without complying with its licence. Check the licences for some proprietary software you use. Do they allow unlimited distribution of binaries? No? Then you are just as likely to be sued by the copyright holder of a proprietary program for distributing their executable without permission, in this hypothetical court-discovery situation.
This is an interesting new kind of FUD about free software: that there are legal requirements for 'using it'. The GPL is quite explicit: running the program is not restricted; unless you are modifying or distributing the software, you can do absolutely what you like. Every other free software licence is the same. This message needs to be spread more widely.
Would a forger then be able to replace the printed key with one of their own and if so would anyone notice?
Forging every single passport issued by a country, or even just 1% of them, would be quite a task. If you take ten Ruritanian passports at random and all of them have the same public key signature, you can be pretty certain you have the right key signature for Ruritania.
But anyway, the key signature doesn't really need to be printed on passports; having it available on request from the embassy would be good enough.
Yeah, as far as I can tell the problem is that nobody bothered to import the public keys of all the world's passport signing authorities. In a sane world, each country would publish their public key on a web page, and maybe have paper copies available from embassies so you could check you weren't getting a fake. (Indeed, the passport authority's key signature could be printed on the inside front page of every passport issued, just to get it as widely distributed as possible.)
There's an interesting project to lock down applications so they have no access to files not explicitly given by the user. So if you run a shell command on some files, it can read only those files. If you run a GUI application, it can read only files you load using the Load dialogue box, and similarly cannot write any file except the one you Save.
I think this is an excellent idea and (though hordes of Slashdotters will fiercely disagree) should become the default for all applications. But, darn it, I've forgotten the project's name.
Usually the antivirus software will catch and disable your program before it gets a chance to present the box to the user asking them to disable antivirus software. So yes, you still need to 'penetrate' or evade it somehow.
Hah, I never knew that. At least 'k' for thousand is unambiguous. (Those who prefer 1024 should use uppercase K, which is also Kelvin, though unlikely to be confused.)
MM for million is not such a great idea; in scientific notation it would be a million million, and in Roman numerals 2000.
Assuming that the first connect isn't a MITM is risky.
I guess this is a reasonable point.
But again, if you go to http://mybank.com/ and it turns out to be a phishing site, there is no warning whatsoever. Most users have no idea what the difference is between http and https; even when typing in URLs by hand they don't type the http:/// part.
In olden days users were encouraged to look for the padlock icon. Nowadays the connotation of trust that provides has been worn down by the CAs' sloppiness in handing out certificates, so the new user interface marker is the green glowing bar for an EV certificate. As long as the self-signed https website does not appear any more secure to the user than an unauthenticated site, I don't see there is a problem.
By all means have the scary warning appear for self-signed sites, as long as you make it appear for unencrypted sites as well! They are both equally likely to be fakes.
I was just promoted by what the other poster mentioned about Quake. The old Quake rendering engine was optimized like crazy for Pentium processors. Larabee is going to be a phalanx of them (well, not quite the original Pentium, something a bit better). The Quake code might run on it rather well, with each CPU rendering a small tile of the display. Of course, Quake's visual effects are hardly state-of-the art nowadays, but it would be an interesting hack.
What the browser is doing is saying "This website is asserting it's safe when it isn't."
That's the assumption that needs fixing: that merely by using encryption a site must be claiming all kinds of super trusted certificated warm fuzzies. Why can't a website (like, say, Slashdot) use SSL to stop people sniffing passwords as they go over the wire? What's so bad about that? If you want the green glowing bar or the padlock icon, sure, you need a certificate from Verisign (for all the extra security that provides, which is pretty dubious). Why is an SSL website which hasn't paid Verisign money somehow *less* trustworthy than a website not using SSL?
The user has a reasonable expectation that there's something secure about HTTPS (otherwise, why use it?)
Ninety-nine users out of a hundred have no idea what HTTPS is. They rely on their web browser to show them indicators like green bars to indicate 'safe' and warning pages to indicate 'unsafe'. They are not well served by Firefox marking a self-signed SSL certificate as unsafe but giving no warning whatsoever about an unencrypted page.
I meant track record in terms of technical achievement, not marketing. Perhaps the number of third-party.NET apps that officially run on Linux is pretty small; it's hard to get numbers for these things (especially for in-house work which is much more than half of all development).
Even if that happens it would be worth it just to kill Flash... I'll take a free software implementation over a binary blob any day, no matter what company originated the standard.
Slashdot Mirror
I don't think speed of payroll systems is any longer an advantage of Cobol. Computers today are thousands of times faster than they were 40 years ago, but payrolls are not any larger. So if Cobol running on a machine clocked at 1MHz was fast enough in the past, even the slowest possible language running on a modern CPU will be fast enough today.
The part that sucks is the name. To me, 'HP Superdome' conveys images of leaky Buckminster Fuller spheres at Epcot Disney World and Britain's miserable 'millennium' celebration. Or perhaps the foreheads of the aliens from Mars Attacks mixed with some kind of overhyped sporting event. Either way I wouldn't want a pulsating monstrosity like that in my server room, unless it were some kind of server chysalis from which a flight of shimmering laptop butterflies would one day break out.
Are you sure that the features you are asking for need to be implemented in the core language? Can they not be provided by libraries?
Trust your uncle Bjarne. If you don't use it, you don't pay for it. You need not worry that the language is turning into C# or Python. It's still just as efficient for bare-metal programming as C ever was (and more so in some cases, with template specialization at compile time).
As for 'automatic memory management', that was one of C's big features. Remember the 'auto' keyword?
What exactly are the advantages of C over C++? Assuming a programmer with good taste.
Firstly, C# version 3 (supported by current Mono, and also by that alternative Mono implementation from Microsoft) is much more functional in style, if you want it to be. IIRC it has let-expressions (perhaps as part of LINQ) and lambdas, and it might even have algebraic data types (I need to check that).
Secondly, F# is a pretty sweet functional language that compiles to CLR bytecode, letting you do anything you can do in C#.
Yes you are right. What I said is a weaker statement.
I must admit I was thinking of GPLv2 (which I have read many times) not v3. V2 says
Not under some other licence that meets some conditions: under the GPLv2 itself.
By my reading, 'Corresponding Source' defined here means the source code of the program, including scripts such as Makefiles. But not the whole compiler toolchain. By your argument of 'everything needed to build the binary' you would have to ship an entire operating system down to the bootloader. If that's really your interpretation then I agree, the GPL's requirements are pretty onerous. It doesn't seem to be the interpretation that everyone else is using.
This depends on whether copyright law in your country considers linking together code to create a derived work. If it does, then your resulting program which links in GPLed code is a derived work of that code, and you need permission from all copyright holders to distribute it, which is to say you must distribute under GPL or not at all.
OTOH, if your own code is separate from the GPLed code and courts would not consider it a derived work, then of course it's your right to distribute it however you want.
Which part of the GPL says that?
I thought you were talking about distributing a copy of the program itself, not a binary produced using it. Admittedly if you link GPL code into your program you must then distribute it under GPL or not at all.
Interesting... I hadn't realized it was such a problem in practice. I thought you would just include source code on the same CD as the binary, and that would be it.
The worst that happens here is that you are infringing copyright by distributing the software without complying with its licence. Check the licences for some proprietary software you use. Do they allow unlimited distribution of binaries? No? Then you are just as likely to be sued by the copyright holder of a proprietary program for distributing their executable without permission, in this hypothetical court-discovery situation.
This is an interesting new kind of FUD about free software: that there are legal requirements for 'using it'. The GPL is quite explicit: running the program is not restricted; unless you are modifying or distributing the software, you can do absolutely what you like. Every other free software licence is the same. This message needs to be spread more widely.
Forging every single passport issued by a country, or even just 1% of them, would be quite a task. If you take ten Ruritanian passports at random and all of them have the same public key signature, you can be pretty certain you have the right key signature for Ruritania.
But anyway, the key signature doesn't really need to be printed on passports; having it available on request from the embassy would be good enough.
Yeah, as far as I can tell the problem is that nobody bothered to import the public keys of all the world's passport signing authorities. In a sane world, each country would publish their public key on a web page, and maybe have paper copies available from embassies so you could check you weren't getting a fake. (Indeed, the passport authority's key signature could be printed on the inside front page of every passport issued, just to get it as widely distributed as possible.)
There's an interesting project to lock down applications so they have no access to files not explicitly given by the user. So if you run a shell command on some files, it can read only those files. If you run a GUI application, it can read only files you load using the Load dialogue box, and similarly cannot write any file except the one you Save.
I think this is an excellent idea and (though hordes of Slashdotters will fiercely disagree) should become the default for all applications. But, darn it, I've forgotten the project's name.
Isn't this just what SELinux policies provide?
Usually the antivirus software will catch and disable your program before it gets a chance to present the box to the user asking them to disable antivirus software. So yes, you still need to 'penetrate' or evade it somehow.
This reminds me of the BBC Micro on a chip which is currently available for about $60, though without a keyboard.
If you connect to a television you could save the expense of a keyboard by using a light pen; a shame this only works with CRTs.
Hah, I never knew that. At least 'k' for thousand is unambiguous. (Those who prefer 1024 should use uppercase K, which is also Kelvin, though unlikely to be confused.)
MM for million is not such a great idea; in scientific notation it would be a million million, and in Roman numerals 2000.
I guess this is a reasonable point.
But again, if you go to http://mybank.com/ and it turns out to be a phishing site, there is no warning whatsoever. Most users have no idea what the difference is between http and https; even when typing in URLs by hand they don't type the http:/// part.
In olden days users were encouraged to look for the padlock icon. Nowadays the connotation of trust that provides has been worn down by the CAs' sloppiness in handing out certificates, so the new user interface marker is the green glowing bar for an EV certificate. As long as the self-signed https website does not appear any more secure to the user than an unauthenticated site, I don't see there is a problem.
By all means have the scary warning appear for self-signed sites, as long as you make it appear for unencrypted sites as well! They are both equally likely to be fakes.
I was just promoted by what the other poster mentioned about Quake. The old Quake rendering engine was optimized like crazy for Pentium processors. Larabee is going to be a phalanx of them (well, not quite the original Pentium, something a bit better). The Quake code might run on it rather well, with each CPU rendering a small tile of the display. Of course, Quake's visual effects are hardly state-of-the art nowadays, but it would be an interesting hack.
That's the assumption that needs fixing: that merely by using encryption a site must be claiming all kinds of super trusted certificated warm fuzzies. Why can't a website (like, say, Slashdot) use SSL to stop people sniffing passwords as they go over the wire? What's so bad about that? If you want the green glowing bar or the padlock icon, sure, you need a certificate from Verisign (for all the extra security that provides, which is pretty dubious). Why is an SSL website which hasn't paid Verisign money somehow *less* trustworthy than a website not using SSL?
Ninety-nine users out of a hundred have no idea what HTTPS is. They rely on their web browser to show them indicators like green bars to indicate 'safe' and warning pages to indicate 'unsafe'. They are not well served by Firefox marking a self-signed SSL certificate as unsafe but giving no warning whatsoever about an unencrypted page.
I meant track record in terms of technical achievement, not marketing. Perhaps the number of third-party .NET apps that officially run on Linux is pretty small; it's hard to get numbers for these things (especially for in-house work which is much more than half of all development).
No, no sarcasm intended. Mono is excellent.
Even if that happens it would be worth it just to kill Flash... I'll take a free software implementation over a binary blob any day, no matter what company originated the standard.