You can as well reap the few benefits you gain out of it before throwing it away.
But how long would you want to run them? In theory, they'll be switched off at EOL. In practice, they'll keep running them well past their useful / safe life. Just take the Belgian power stations Tihange and Doel with their 6000+ micro-fissured reactors they keep on running by extending the deadlines over and again... until they'll finally give and we'll get a Chernobyl II with fallout all over the densely populated Rhine Area (think Cologne, Duesseldorf, the Ruhr-Area etc).
When the University of Berkeley wanted to release its Unix distribution, they also had the problem of finding a suitable permissible license, without falling into the extreme of Public Domain, which, as others have rightfully observed, isn't always recognized internationally. So they invented the beautiful BSD license. This license had a couple of clauses, that ultimately went down to just two now. How about the DoD releasing their stuff under the 2-Clause BSD License as well? Short, sweet, crisp, neutral, developer-friendly, and free of all ideology and cruft. I know, that's taking side in an open debate, and opening a can of worms, but seriously, for government-funded work, that may really be like U. Berkeley's code the best option.
Concerning Rust, it still has to be seen if it is not just yet another fad of the year. We've seen programming languages come and go in the last couple of decades, and the sheer inertia of the C/C++ code-base and programmer-base would make me very skeptical w.r.t. any new languages, including Rust (not that I dislike it, far from that).
As to Ada... I've coded in Ada too back then, and I know of some big code-bases that are rock solid in Ada. Unfortunately, there is a severe shortage of Ada programmers who are willing to maintain those code-bases, so what happens is that a lot of money is being thrown at converting all that Ada code to C++ code, using semi-automated tools where possible. This auto-generated C++ code is then manually re-validated by C++ hackers (and that's what is so costly), and from here on, it will persist as C++ code, maybe for decades.
That's the way it goes. A language may have merits of its own, but if it is not popular and if you can't get enough people to maintain your sizeable code-bases, that language is ultimately of no use. C++ seems like a good compromise between openness, royalties/patent-lessness, speed, type safety, maintainability (when done right!), and long-term maintainability through coders. Despite its known shortcomings. No Rust, not even Ada can beat that.
Maybe someday someone will figure out how to use C++ in a clean, nice looking style. Then I'll use it. Until then, I'm staying away.
You may also make suggestions and contribute to shape the next iterations of the C++ standard...
Personally, I really like what has become of C++ since C++11, and I'm seeing that C++17 is getting some real nice additions in the Standard Library too. What I'm still missing though: standardized networking (Boost.ASIO looks like a monster at this stage, don't know if that would or even should make it into the ISO standard anytime soon). Missing networking is a big minus IMHO. I also consider the difficulty of writing more specialized streams, e.g. for encryption etc. a small minus... but that may only be me not yet grokking enough the iostreams / streambuf library design to extend it that way.
Save for that, C++11's style and philosophy is something you get used to after a while. It takes some time to finally "get it" and get the hang out of it. That's not just a couple of syntactic rules and keywords and weird ways to write templates and template specializations and throw in iterator flavors everywhere where you don't expect them to come up, it is more than that. Once you finally reach some stage of enlightenment, you'll start to really like C++ and will start coding in it as it was supposed to be and designed to be. I know, it sounds like a pathetic excuse for not being easily accessible...
I don't want to play the devil's advocate here, but to AT&T's defense, the POTS was an analog system, and back then, there were no clearly defined interfaces between CPE (customer premises equipment) and "the network". If a customer screwed up the local loop in some really bad way (the system was really robust, it could take a lot of abuse, but it was not indestructible), he could easily damage a certain part of the attached parts up to and including the switch, and that could be costly. And in general, playing around in an analog network where everyone has to play by the rules is a tricky business better left to people who are at least a little bit trained in it. Of course, later things changed considerably, and there was a loose coupling and clear interfaces between CPE and the rest of the network, so customers were free to fool around with their equipment and house wiring as much as they desired without risking to take down other customers with them.
Sadly, Google amputated Ad hoc mode (IBSS) in Android, even though that would have been the perfect method in this particular case. Not the technically inferior Wifi-Direct. Some people have tried to hack CyanogenMod on some devices to resurrect IBSS mode on some devices a while ago, but that is not so easy. I think this deserves more attention and love by devs and by Google. There's no reason why we don't have IBSS (ad hoc) mode on those devices out of the box, so we could experiment with real P2P routing algorithms that would be ideal for disaster recovery and deployment of ad hoc meshes.
To C++ aficionados, weekends are for reading and meditating through Stroustrup's and others' fine books, the ISO standard, Boost code, etc. to get a better grasp of the language and its modern features to then be used during the week days to create even more obscure, beautiful metaprograms that solve the Halting Problem at compile time by applying a policy meta-template instantiated with some magic traits. Do you think there's time to commit code like that on GitHub on the weekends and hoping those commits to still make sense on Monday?
I couldn't agree more. Most CS graduates can get by writing and maintaining application code, but as soon as it gets to getting their hands dirty and doing library / infrastructure work, i.e. touch real data structures, etc., good luck with that! And that's only foundational stuff... I'm not even mentioning serious aspects like IT security, where a solid mathematical understanding of crypto basics is required nowadays, along with a good base of discrete mathematics, complexity theory and so on. Your typical CS graduate will only have a very superficial understanding of those topics, unless he specialized deeply into that... and even then I wouldn't be the farm on their cognitive skills. That's really sad.
C isn't dying, but I think that it is being slowly replaced more and more by C++. Not all of a sudden, but when new code gets added, it is just more convenient to use std::string, RAII, the whole C++ Standard Library. Especially since C++11, C++ and its library have matured a lot to actually become useful and have you write beautiful and fast/efficient code, thanks to move semantics. So no, C isn't dying, it is morphing into C++11 and later. Even for embedded and kernel-level programming: check out recent projects: many use C++, carefully avoiding features like virtual functions that would slow down running time. It is as good as C can get, only better.
Still relying on OpenBSD, and sometimes also on a trimmed-down FreeBSD with Capsicum for security-related work; but I'm wondering what the most hardened (minimalist) Linux distro you guys are recommending? I understand that the less software, the smaller the attack surface, but I'm also thinking along the lines of SELinux-by-default, settable access policies (not just discretionary access policies but also rules-based access policies), etc...
Let me put this file I encrypted with PGP on an anonymous FTP site / dropbox. You can then download it and tell me what's in the file. No wait, you can't, because it's encrypted with an OS-agnostic algorithm and you don't have the key.
I'm not sure you get the point. Are the (private) keys located on the Android device? Do you enter the passphrase to unlock the private keys directly on the Android device? If so, your beloved App's security is toast, because key material is hitting the OS before it even reaches the App.
Encryption is out there, and a reality. If the phone manufacturer compromises their full-disk encryption, then app makers start writing un-compromised encryption into their apps.
If it were only so simple! If the underlying OS is compromised and can't be trusted, what's the value of any encryption on top of that?
Let's say Gov't passes an anti-encryption law for smartphones. First thing Apple and Google will (have to) do, is to purge their App Stores from all apps that implement un-snoopable encryption. That's the first step. So no un-compromised encryption in apps for the plebs.
Then, next step, Apple and Google will (have to) remove all encryption libraries and support in the OS (libraries etc.), or cripple them with backdoors, so the Government(s) and other evil-doers can snoop right back in, even if Apps are still allowed to call encryption APIs.
Finally, every I/O in and out of an App has to go through some layer of the OS; and if the OS can't be trusted, what good is solid encryption? You as a user can't listen to encrypted voice, you can't read encrypted messages, you can't watch encrypted photos and videos: you're the analog counterpart that requires decryption, and this is the point where device makers will be compelled by the Gov't to let the snooping start.
Of course, there's still the option of alternative ROMs that you compile yourself out of reliable source code (CyanogenMod et al. come to mind); but here, there are still some binary blobs that are required to drive the modems etc.: same problem as with a regular Linux: do you trust these, if Government were to mandate snooping on a hardware low-level from manufacturers?
Your politicians took the bribes from the US to part ways with Russia, now you get to enjoy the wonderful world of American IP law.
That's exactly the point. On the other hand, Russia is also cracking down on file sharing sites: remember AllofMP3.{com,ru} folding under US pressure/blackmail, or, more recently, their draconian laws on personal identification for users of Russian-based Internet services?
As an older programmer (say, 50+), learning new programming paradigms is easy. Hell, absorbing new frameworks, programming languages etc. in a week or two is still a piece of cake. Why? Because that's not too far from the domain you know. BUT, diving into totally new application domains requires a lot more efforts than when you were younger. As an example: if you've never been exposed to an EE education and you suddenly have a project about, say, writing an antennae simulator, you'll have to absorb Maxwell's Equations, and related maths. Even if you've had CS training with maths background in your prime, you'll definitively need a lot more time to wrap your head around this with 50, 60 than if you were in your 30ies. That's not impossible, of course, but the additional time to understand this new domain, and apply it to programming, will slow you down so much that companies will often refrain from hiring you, despite your immense wealth of additional side-knowledge that could be very useful.
You can't be sure if they don't provide the source code. But even if they did... basically, they claim to implement Signal Private Messenger's protocol, which is strong end-to-end encryption. However, even this protocol doesn't hide metadata from WhatsApp's servers. For example, every WhatsApp user needs to keep WhatsApp directory server(s) updated about his/her current IP so she can be found by others WhatsApp users. This alone is already up to a couple of hours pretty accurate meta data that can be invaluable to Facebook... which can target you with better ads, based on your current (network) location.
I'm working in Unix and Network programming and also Systems programming, and I made an early habit of explicitly destroying / releasing / closing resources that are not needed anymore, even when they are reclaimed by the OS when the program exits. This includes in particular open files, and all kinds of network descriptors. Why? Because most of my code usually ends up repackaged into libraries and reused inside longer running programs (i.e. inside loops); and not being disciplined about releasing resources would result in all kinds of leaks. This is particularly bad when that code gets reused inside device drivers.
Of course, things got a lot easier once I switched from C to C++ and the STL and RAII idiom, but trying to release resources is still ingrained in my muscle memory; it takes a conscious effort in C++ NOT to explicitly release a resource acquired through initialization.
Please help refine this by pointing out shortcomings of this scheme.
The shortcomings is that the encryption is visible to the average guard and unnecessarily raises eyebrows.
How about this (on Android)? You install two operating system images on the phone, say, two instances of CyanogenMod, one encrypted, and the other non-encrypted, and you setup the boot loader TWRP so that it usually boots the unencrypted one. So, if the unsuspecting guard boots the phone, he'll be able to login and see a perfectly regular OS. But if YOU want to access your confidential files, you reboot the phone into TWRP with the usual key combo, and then you boot into the encrypted instance of the OS. Added bonus: you modify TWRP so that it doesn't even display that encrypted OS in the list of available bootable partitions.
Shortcomings: forensics will show that there is an encrypted partition on the phone... if they ghosted it. But if it is just the guard booting up the phone and nosing around a little bit, you're pretty safe.
It's worth repeating ad nauseam: when traveling abroad, always use a new clean phone, i.e. another phone with a new SIM card that is not linked to your Google and other accounts... It's not just the US that seizes or snoops on phones at its borders, foreign countries do so as well. Basically, once they got hold of your phone and take it out of your sight for a couple of minutes, you never know if it hasn't been copied, and bugged. And when you're back home, always assume the phone has been physically tampered with, and make sure to throw it away (or sell it e.g. on eBay to some poor unsuspecting buyer, fair warning would be nice though). Sorry, but that's the way it is.
On one of my Windows 7 machines, I actually reserved the Windows 10 upgrade many months ago, but nothing happens. Clicking on the icon in the task bar always shows "Your upgrade is reserved... blah blah blah". So it's kind of funny to be nagged by GWX, and at the same time to wait in vain for a download that never completes. Not that it matters that much to me, it's just funny. If it doesn't complete by the deadline, that machine will stay on Windows 7 which runs just fine. I got an upgrade on another test machine without any problems; and all this is only to analyze the behavior of Windows 10 w.r.t. security. Real work with sensitive data I do on Linux and FreeBSD anyway.
Indeed. And even if we opt for a USE, there are different models for such a USE: a centralized ideal French-style, a federalized one German-style,... and economically, a more socialist-authoritarian one French/German-style, a more capitalist-liberal one British/Eastern-European-style. Trying to find a common ground and to converge towards a model that is acceptable by all member states is nearly impossible. Just look at the total fiasco that the single currency Euro turned out to be: due to different financial philosophies between North and South, the whole Euro-Zone is shattered, and their central bank is printing billions of Euros like there's no tomorrow, heading right towards a super crash. Frankly, the anti-USE in the UK have won, and it pains me to say: they were right. I too was hoping for some kind of USE, but I grew disillusioned. I think right now that the EU should be rebooted and rebuilt (much more carefully) from scratch. On the second try, things could improve. As it stands now, keeping working on it will only add more misery to an utterly broken design, IMHO.
Slashdot Mirror
But how long would you want to run them? In theory, they'll be switched off at EOL. In practice, they'll keep running them well past their useful / safe life. Just take the Belgian power stations Tihange and Doel with their 6000+ micro-fissured reactors they keep on running by extending the deadlines over and again... until they'll finally give and we'll get a Chernobyl II with fallout all over the densely populated Rhine Area (think Cologne, Duesseldorf, the Ruhr-Area etc).
Just one word: Tahoe-LAFS. Deploy, use, relax.
When the University of Berkeley wanted to release its Unix distribution, they also had the problem of finding a suitable permissible license, without falling into the extreme of Public Domain, which, as others have rightfully observed, isn't always recognized internationally. So they invented the beautiful BSD license. This license had a couple of clauses, that ultimately went down to just two now. How about the DoD releasing their stuff under the 2-Clause BSD License as well? Short, sweet, crisp, neutral, developer-friendly, and free of all ideology and cruft. I know, that's taking side in an open debate, and opening a can of worms, but seriously, for government-funded work, that may really be like U. Berkeley's code the best option.
As to Ada... I've coded in Ada too back then, and I know of some big code-bases that are rock solid in Ada. Unfortunately, there is a severe shortage of Ada programmers who are willing to maintain those code-bases, so what happens is that a lot of money is being thrown at converting all that Ada code to C++ code, using semi-automated tools where possible. This auto-generated C++ code is then manually re-validated by C++ hackers (and that's what is so costly), and from here on, it will persist as C++ code, maybe for decades.
That's the way it goes. A language may have merits of its own, but if it is not popular and if you can't get enough people to maintain your sizeable code-bases, that language is ultimately of no use. C++ seems like a good compromise between openness, royalties/patent-lessness, speed, type safety, maintainability (when done right!), and long-term maintainability through coders. Despite its known shortcomings. No Rust, not even Ada can beat that.
You may also make suggestions and contribute to shape the next iterations of the C++ standard...
Personally, I really like what has become of C++ since C++11, and I'm seeing that C++17 is getting some real nice additions in the Standard Library too. What I'm still missing though: standardized networking (Boost.ASIO looks like a monster at this stage, don't know if that would or even should make it into the ISO standard anytime soon). Missing networking is a big minus IMHO. I also consider the difficulty of writing more specialized streams, e.g. for encryption etc. a small minus... but that may only be me not yet grokking enough the iostreams / streambuf library design to extend it that way.
Save for that, C++11's style and philosophy is something you get used to after a while. It takes some time to finally "get it" and get the hang out of it. That's not just a couple of syntactic rules and keywords and weird ways to write templates and template specializations and throw in iterator flavors everywhere where you don't expect them to come up, it is more than that. Once you finally reach some stage of enlightenment, you'll start to really like C++ and will start coding in it as it was supposed to be and designed to be. I know, it sounds like a pathetic excuse for not being easily accessible...
Yes, indeed.
I don't want to play the devil's advocate here, but to AT&T's defense, the POTS was an analog system, and back then, there were no clearly defined interfaces between CPE (customer premises equipment) and "the network". If a customer screwed up the local loop in some really bad way (the system was really robust, it could take a lot of abuse, but it was not indestructible), he could easily damage a certain part of the attached parts up to and including the switch, and that could be costly. And in general, playing around in an analog network where everyone has to play by the rules is a tricky business better left to people who are at least a little bit trained in it. Of course, later things changed considerably, and there was a loose coupling and clear interfaces between CPE and the rest of the network, so customers were free to fool around with their equipment and house wiring as much as they desired without risking to take down other customers with them.
Sadly, Google amputated Ad hoc mode (IBSS) in Android, even though that would have been the perfect method in this particular case. Not the technically inferior Wifi-Direct. Some people have tried to hack CyanogenMod on some devices to resurrect IBSS mode on some devices a while ago, but that is not so easy. I think this deserves more attention and love by devs and by Google. There's no reason why we don't have IBSS (ad hoc) mode on those devices out of the box, so we could experiment with real P2P routing algorithms that would be ideal for disaster recovery and deployment of ad hoc meshes.
To C++ aficionados, weekends are for reading and meditating through Stroustrup's and others' fine books, the ISO standard, Boost code, etc. to get a better grasp of the language and its modern features to then be used during the week days to create even more obscure, beautiful metaprograms that solve the Halting Problem at compile time by applying a policy meta-template instantiated with some magic traits. Do you think there's time to commit code like that on GitHub on the weekends and hoping those commits to still make sense on Monday?
I couldn't agree more. Most CS graduates can get by writing and maintaining application code, but as soon as it gets to getting their hands dirty and doing library / infrastructure work, i.e. touch real data structures, etc., good luck with that! And that's only foundational stuff... I'm not even mentioning serious aspects like IT security, where a solid mathematical understanding of crypto basics is required nowadays, along with a good base of discrete mathematics, complexity theory and so on. Your typical CS graduate will only have a very superficial understanding of those topics, unless he specialized deeply into that... and even then I wouldn't be the farm on their cognitive skills. That's really sad.
No, not if you keep using that old 1st gen Pentium CPU in the basement...
C isn't dying, but I think that it is being slowly replaced more and more by C++. Not all of a sudden, but when new code gets added, it is just more convenient to use std::string, RAII, the whole C++ Standard Library. Especially since C++11, C++ and its library have matured a lot to actually become useful and have you write beautiful and fast/efficient code, thanks to move semantics. So no, C isn't dying, it is morphing into C++11 and later. Even for embedded and kernel-level programming: check out recent projects: many use C++, carefully avoiding features like virtual functions that would slow down running time. It is as good as C can get, only better.
Still relying on OpenBSD, and sometimes also on a trimmed-down FreeBSD with Capsicum for security-related work; but I'm wondering what the most hardened (minimalist) Linux distro you guys are recommending? I understand that the less software, the smaller the attack surface, but I'm also thinking along the lines of SELinux-by-default, settable access policies (not just discretionary access policies but also rules-based access policies), etc...
I'm not sure you get the point. Are the (private) keys located on the Android device? Do you enter the passphrase to unlock the private keys directly on the Android device? If so, your beloved App's security is toast, because key material is hitting the OS before it even reaches the App.
If it were only so simple! If the underlying OS is compromised and can't be trusted, what's the value of any encryption on top of that?
Let's say Gov't passes an anti-encryption law for smartphones. First thing Apple and Google will (have to) do, is to purge their App Stores from all apps that implement un-snoopable encryption. That's the first step. So no un-compromised encryption in apps for the plebs.
Then, next step, Apple and Google will (have to) remove all encryption libraries and support in the OS (libraries etc.), or cripple them with backdoors, so the Government(s) and other evil-doers can snoop right back in, even if Apps are still allowed to call encryption APIs.
Finally, every I/O in and out of an App has to go through some layer of the OS; and if the OS can't be trusted, what good is solid encryption? You as a user can't listen to encrypted voice, you can't read encrypted messages, you can't watch encrypted photos and videos: you're the analog counterpart that requires decryption, and this is the point where device makers will be compelled by the Gov't to let the snooping start.
Of course, there's still the option of alternative ROMs that you compile yourself out of reliable source code (CyanogenMod et al. come to mind); but here, there are still some binary blobs that are required to drive the modems etc.: same problem as with a regular Linux: do you trust these, if Government were to mandate snooping on a hardware low-level from manufacturers?
That's exactly the point. On the other hand, Russia is also cracking down on file sharing sites: remember AllofMP3.{com,ru} folding under US pressure/blackmail, or, more recently, their draconian laws on personal identification for users of Russian-based Internet services?
As an older programmer (say, 50+), learning new programming paradigms is easy. Hell, absorbing new frameworks, programming languages etc. in a week or two is still a piece of cake. Why? Because that's not too far from the domain you know. BUT, diving into totally new application domains requires a lot more efforts than when you were younger. As an example: if you've never been exposed to an EE education and you suddenly have a project about, say, writing an antennae simulator, you'll have to absorb Maxwell's Equations, and related maths. Even if you've had CS training with maths background in your prime, you'll definitively need a lot more time to wrap your head around this with 50, 60 than if you were in your 30ies. That's not impossible, of course, but the additional time to understand this new domain, and apply it to programming, will slow you down so much that companies will often refrain from hiring you, despite your immense wealth of additional side-knowledge that could be very useful.
You can't be sure if they don't provide the source code. But even if they did... basically, they claim to implement Signal Private Messenger's protocol, which is strong end-to-end encryption. However, even this protocol doesn't hide metadata from WhatsApp's servers. For example, every WhatsApp user needs to keep WhatsApp directory server(s) updated about his/her current IP so she can be found by others WhatsApp users. This alone is already up to a couple of hours pretty accurate meta data that can be invaluable to Facebook... which can target you with better ads, based on your current (network) location.
Of course, things got a lot easier once I switched from C to C++ and the STL and RAII idiom, but trying to release resources is still ingrained in my muscle memory; it takes a conscious effort in C++ NOT to explicitly release a resource acquired through initialization.
And what exactly would prevent the government from forcing Microsoft to keep sending those messages?
The shortcomings is that the encryption is visible to the average guard and unnecessarily raises eyebrows.
How about this (on Android)? You install two operating system images on the phone, say, two instances of CyanogenMod, one encrypted, and the other non-encrypted, and you setup the boot loader TWRP so that it usually boots the unencrypted one. So, if the unsuspecting guard boots the phone, he'll be able to login and see a perfectly regular OS. But if YOU want to access your confidential files, you reboot the phone into TWRP with the usual key combo, and then you boot into the encrypted instance of the OS. Added bonus: you modify TWRP so that it doesn't even display that encrypted OS in the list of available bootable partitions.
Shortcomings: forensics will show that there is an encrypted partition on the phone... if they ghosted it. But if it is just the guard booting up the phone and nosing around a little bit, you're pretty safe.
It's worth repeating ad nauseam: when traveling abroad, always use a new clean phone, i.e. another phone with a new SIM card that is not linked to your Google and other accounts... It's not just the US that seizes or snoops on phones at its borders, foreign countries do so as well. Basically, once they got hold of your phone and take it out of your sight for a couple of minutes, you never know if it hasn't been copied, and bugged. And when you're back home, always assume the phone has been physically tampered with, and make sure to throw it away (or sell it e.g. on eBay to some poor unsuspecting buyer, fair warning would be nice though). Sorry, but that's the way it is.
Still owning an HP-15C here, and it is actually still working. Got to love RPN and programming in constrained space though.
On one of my Windows 7 machines, I actually reserved the Windows 10 upgrade many months ago, but nothing happens. Clicking on the icon in the task bar always shows "Your upgrade is reserved... blah blah blah". So it's kind of funny to be nagged by GWX, and at the same time to wait in vain for a download that never completes. Not that it matters that much to me, it's just funny. If it doesn't complete by the deadline, that machine will stay on Windows 7 which runs just fine. I got an upgrade on another test machine without any problems; and all this is only to analyze the behavior of Windows 10 w.r.t. security. Real work with sensitive data I do on Linux and FreeBSD anyway.
Indeed. And even if we opt for a USE, there are different models for such a USE: a centralized ideal French-style, a federalized one German-style, ... and economically, a more socialist-authoritarian one French/German-style, a more capitalist-liberal one British/Eastern-European-style. Trying to find a common ground and to converge towards a model that is acceptable by all member states is nearly impossible. Just look at the total fiasco that the single currency Euro turned out to be: due to different financial philosophies between North and South, the whole Euro-Zone is shattered, and their central bank is printing billions of Euros like there's no tomorrow, heading right towards a super crash. Frankly, the anti-USE in the UK have won, and it pains me to say: they were right. I too was hoping for some kind of USE, but I grew disillusioned. I think right now that the EU should be rebooted and rebuilt (much more carefully) from scratch. On the second try, things could improve. As it stands now, keeping working on it will only add more misery to an utterly broken design, IMHO.