Knowing critical concepts...technical and business is essential. But when it comes to implementing those concepts, you need to know the mechanics. There is a place for code monkeys. Just as there is a place for analysts and architects. No one has, or can have, the complete solution. If you think you do, you are deluded.
Well, I'd argue that there isn't really any place for code monkeys, at least if you want to have customers.
And yes, I've seen it first hand. One place I worked was a company (Company A) that was bought by another company (Company B). The two had very different philosophies of programming and hiring, and it reflected in the opinion their customers had of them. Company A hired mid-level to senior devs; had a small but knowledgeable team; and products that actually worked as advertised requiring little support from the software devs; yes, bugs still had to get fixed but they were not critical and the customer could still use the system. Company B would only hire one or may be two senior devs and then a bunch of cheap code monkeys out of college; a larger team but less knowledge; and they had a hard time delivering products. One case I am aware of their customer accepted the system (signed off the contract) to get rid of them so they could buy a difference system (which was a product of Company A before Company B bought them).
So if you need good products, good customer relations, etc it's best to stay away from code monkeys and hire people that can perform well and deliver products. If you can support having people in training (e.g out of college, train to become the next round of mid/senior devs) all the better; but even then the guys you hire out of college can be differentiated into code-monkeys and not based on their skill set at that time too and your good coders coming out of college won't be code monkeys.
If you can by-pass it then it effectively nullifies any security provided, so yes, it does count.
So if I try to rob a house, and I "bypass" the security system by robbing the next house over, does that mean the security system of the first house sucks?
If you are able to use entry into the second house to steal stuff from the first house, then yes, that the security on the first house is insufficient protection.
If the two are completely unrelated, then the security of the first makes no difference.
In this case, card vs card+chip+pin is like two homes with a tunnel between them. The first home might be more secure, but the tunnel is doesn't have any security on it. So the valuables in the first house are still at risk through entry into the second house; and the guy that sold the first house to the current owners failed to mention the existence of the tunnel.
Even aside from that, chip+PIN it no where near as secure as things like Google Wallet that provide single-use card numbers for each transaction.
How is this more secure?
The card number is single use. If they try to use it again, it doesn't work. So it's more secure in the same way that a one-time password is more secure.
Google approves the single transaction, and denies any further ones. So yes, it's actually more secure but it also relies on NFC (Wallet+NFC, now Android Pay). It's less secure in that you're putting your bank/credit cards at a single source (Google, Apple, etc) and then using their services to make more secure transactions with others - so single point of failure in security. However, you're card numbers won't be stolen from Target, Home Depot, Walmart, or any other vendor you do business with.
It's also been shown that people can completely clone a chip+PIN card, again rendering the added security null and void.
This is even more silly, where I live if you simply put your card in backwards, the reader will say read error, ask you to swipe, then ask to put the card in again, if you put the card in backwards again it will ask to swipe and accept that. Yes you need to know the pin but you don't need the chip.
Yeah. It doesn't save anything - just causes more headaches. They're only going after it to shift some liability.
It reminds me of Microsoft Bob's security if you entered your password wrong 3 times it would ask if you wanted to change it.
lol...kind of like a disk encryption software I used a few employers ago...if you ran out of attempts it was suppose to require help desk to unlock it. I accidentally discovered all you had to do was reboot the computer - even a soft-reboot worked IIRC.
It doesn't count as "chip and pin" if the hack involves bypassing the use of the chip and pin. A safe can't protect any items that aren't actually in it.
If you can by-pass it then it effectively nullifies any security provided, so yes, it does count.
Even aside from that, chip+PIN it no where near as secure as things like Google Wallet that provide single-use card numbers for each transaction.
It's also been shown that people can completely clone a chip+PIN card, again rendering the added security null and void.
Just good to mention that Chip & PIN cards would not have prevented the Target breach in any way as mentioned in Brian Krebs follow up article:
https://krebsonsecurity.com/20...
"0 – The number of customer cards that Chip-and-PIN-enabled terminals would have been able to stop the bad guys from stealing had Target put the technology in place prior to the breach (without end-to-end encryption of card data, the card numbers and expiration dates can still be stolen and used in online transactions)."
Correct. Chip & PIN would not have solved anything.
To provide an example...I used my Chip card the other day. The vendor was having an issue with their chip reader, so the POS operator put in an override to allow it to be swiped. So another easy way to by pass the Chips? Make a hack that makes the system think the reader is unusable.
It is worse than that, because after they were shown that it could be done, they did nothing about it until this latest exploit threatened to make their failure general knowledge.
Why is it that the stupidest people always seem to be the ones making the decisions in matters of security?
Because everyone is stupid when it comes to security until something security related happens to them.
You can move into C++, but then you have to be extremely careful of new/delete support
How much more careful do you have to be of new/delete support than malloc/free support?
Not much I'll wager.
You actually have to completely avoid it until you setup the functions necessary to support it. It's been a while since I've looked at doing it, but it's non-trivial, as is much functionality at that early boot stage.
And it's not like you have to support it. None of my Atmel code uses new or delete. Static allocation all the way.
This is why most embedded and kernel stuff only uses C as even C++ adds enough bloat due to those supports that when every byte counts it's just not useful.
C++ does not add bloat. That's an old, false meme which needs to die.
True, you can avoid stuff by following best practices for embedded and using pure stack allocation. But that only goes so far. You can also run into issues with Exceptions. For instance http://wiki.osdev.org/Bare_Bon... documents several issues.
That is not how the supreme court interpreted it. You're correct the wording says that but the supreme court disagreed. The court was clear that treaties do not hold a privileged position over congress specifically allowing for them to pass laws to deny enforcement of, modify or repeal a treaty with nothing more than any other law.
No, they don't hold special position over Congress because Congress has to - and in accordance with the Consitution - approve all Treaties; and only Congress has that power. The SCOTUS ruling, as described, also doesn't mean that - again as per the Constitution - Treaties are not on par with the U.S Code (law) as opposed to their Constitutional place of being between the Constitution and U.S Code. They're not special by any means.
TPP and, and especially the Iran Deal, have a fault in how they are being pursued since SCOTUS has ruled that Congress cannot delegate its authority to other groups. So even though the Iran Deal may be accepted on its face without a specific vote for approval, that would not - per SCOTUS - make it legally binding.
K&R tells you to match a free() with every malloc(). Do so - no memory leaks. Yes, K&R doesn't teach you how to debug your code - it teaches you how to avoid the bug in the first place.
Mod parent up.
One of my first programmer reads was Elements of C by Morton H. Lewin (1986) which covered K&R C. I read it in 2004. It made me realize just how much C I actually do (I learned C/C++). even when doing C++. And yes, simple things like matching every malloc() call with an equivalent free() call is some of the essentials of programming without memory leaks.
Though in the C++ world if you're using a parenting model like Qt does, then the delete matching the new is usually (except in special well documented and obvious cases) handled by the parenting model - e.g. all objects have a parent; on destruction of an object, it automatically cleans up all its children; you have to clean up the ones that don't have parents, most of which can be managed by allocating them on the stack. While I'm sure you can figure out a similar approach in C, I'm not sure their is really any framework that does that in C.
The only benefit C++ arguably has over C in terms of avoiding common pitfalls is the STL and automatic destructors.
I probably do more C and than C++ when writing C++ code. I typically use C++ classes (abstract, etc), namespaces, and (now) STL. This just helps with segregating the code into their logical parts so structure X doesn't get used on functions only meant to manage structure Y or data type Z.
new/delete? Well, I'll use them for classes only. Structures get allocated with malloc/free. Yes, a class is only use for data+functions and structures are only used for pure data; allocation patterns follow this same methodology which enables easy transition between pure C and C/C++ code when necessary. If a class allocates data, then I also provide an API in the class (typically instance agnostic) to clean it up to ensure that there is one-place that cleans it up, ensuring that the same allocator/destructor methods are used.
I also stay away from streams when I have a choice, and prefer C-style printf/scanf processing.
So there are useful bits in C++; you just have to find the right balance. Doing so makes for very easy to maintain code.
But it's still just as error-prone (just fewer places for errors), and the fact that the destructor doesn't get called if the constructor throws isn't broadly internalized by coders (and is my least-favorite intermittent resource leak to run down).
Well, there is another (better) solution - stop using Exceptions! They cause more headaches than anything else, including leaving programs in unrecoverable states.
I know, I know - everyone loves Exceptions. But in all honestly, they should never be used. Functions/ClassMethods/etc should all be explicit in their error handling, and errors should always be handled as close to what generated the error as possible. This one little thing saves all of the headaches of trying to track down bad pointers, incorrect states, etc - e.g 99% of what people complain about in C and C++ code.
There's really no reason ever to use C over C++ if you have a C++ compiler available
Well, unless your bootstrapping an OS. C is the easiest language to move to from Assembly as there are zero things to setup to move into C. You can move into C++, but then you have to be extremely careful of new/delete support - which has to get setup almost immediately if you did not before you moved into C++ land. This is why most embedded and kernel stuff only uses C as even C++ adds enough bloat due to those supports that when every byte counts it's just not useful. I expect Rust would be more like C++ in that respect.
So as always, it's depends on what you do. In most cases, it probably won't make a difference. But there are some vital cases out there - especially in the embedded world - that the small differences have huge impacts.
You, my friend, need to learn about precompiled headers. If your modules have more than one include statement, you're doing it wrong. Large projects can compile quickly if set up correctly. Also, modern compilers can compile 8 files from a single project in parallel on an I7. I don't know if it's still true, but Visual Studio is / was terrible at this; only compiling single files from multiple projects in parallel. This caused bloat in the solution with multiple projects to get any kind of speed improvement in build times, at the cost of complexity.
I avoid pre-compiled headers at all cost. They only cause problems with builds, and typically don't save me anything since to correct those problems you have to blow away the pre-compiled headers any way.
There are different methods of being able to manage the header bloat you mentioned. On method (in C++) is forward declarations - e.g. you don't include any classes, etc; you just forward declare them, which works wonderfully when you keep the implementation out of the headers. The other big method (my favorite) is keeping you headers clean and well separated - including only what you have to and not everything under the sun (e.g no "#include " type stuff).
I know that's a joke, but it's of course nonsense. Plenty of people have gotten fired for using C, especially when their code had dangerous security vulnerabilities (which it ALWAYS does).
Wrong.
Yes, people have been fired for being bad programmers. I doubt many have been fired over security vulnerabilities, most likely because either (a) the vulnerability was discovered after the programmer already voluntarily left or (b) was rooted in standard operating procedures (e.g you just don't do that) - most due to people not realizing the consequences of network computers. (Prior to networking, security didn't really matter too much outside of specialized environments.)
Further more, C-based software probably runs about 99+% of devices out there - most notably everyone's favorite OS kernel - Linux - is entirely written in C, as is the Windows NT Kernel, the BSD Kernels, etc. Most all operating systems use it at the core, and many applications use it - IOW, the world runs on C; aside from Assembly is it probably the most used programming language out there when you look at all aspects of software (even C++ doesn't compare). It only bites you if, like with any tool (including Java), you mis-use it. Best practices will save you from 99.99% of issues.
Oh, and the OS's that don't use C in their kernel? They're all research or hobby stuff that more or less proves you could do it, but the performance is so abysmal (compared to the same thing in C) that no one would really use it, or they use C to bootstrap and load into their alternative language - typical of C++ OS Kernels. (Yes, there have been Java-based Operating Systems; they also relied on specialized hardware-based JVMs and no one uses them outside of small research projects.)
What your looking for is Head Money Cases, 112 U.S. 580 (1884) that said specifically that treaties do not hold special case above congress outside how they are negotiated and approved.
Except the Constitution places Treaties just under itself and above all other laws of the land - e.g a Treaty can only be invalid if it violates the Constitution, all other laws are subject to the Treaty on equal footing to the Constitution.
It is Science, Technology, Engineering, and Mathematics, I think comsci qualifies for the last three but not for the first one and I have a comsci degree.
Beat me to it. It's a mixture of engineering, maths, and art (we don't have technology degrees here so I'm not sure what that entails), but very little science. Like other fields that feel the need to put "science" in their name (for example political science), it mostly isn't.
It *should* be engineering, but it isn't. It's hard to qualify it as science as it's more like mathematical theory than anything else.
That said, CompSci should be split to have a formal engineering track for 99% of students, and a formal research/theory track for those that want to just stick to academia and related research. The software world would be better for it since a true discipline to how programs are written could be brought about instead of all this bs'ing over how it's art.
where I wouldn't dare venture with such things as implanted RFID chips.
Want to use your implanted RFID chip to access your bank via ATM? What's to stop criminals from cutting off your finger and racing to the nearest ATM before your finger and the chip become non-operational? Probably the PIN you also use to authenticate, but still.......
Ummmmm, the same thing that keeps them from stealing your card and doing the same thing? Yeah, stealing an ATM access device is already a problem, though not a huge one. What makes you think it will become a larger problem when the device in question is implanted? Seems like it would be a more difficult robbery with greater legal repercussions than a simple mugging.
What will stop them - or at least make it harder - would be additional bio-metrics requirements - things like needing a pulse, matching fingerprint, etc.
This is, of course, an issue for all biometrics authentication - an organ/appendage is forcefully removed, leaving the original owner for dead, and then used to access the systems it was for.
The greater legal repercussions will simply be "murder in the first degree" (e.g with intent) instead of a simple felony or misdemeanor for stealing their wallet.
Implants like fingertip magnets and RFID chips are as easy to remove as they are to put in. It shouldn't take more than a few minutes and can be done without anesthesia (though it may hurt...).
Well, an MRI will do it in just a couple seconds, and may happen incidentally - for instance, you're in a car wreck, unconscious, and they put you in an MRI to try figure out why (e.g check brain swelling, etc). It'll be painless when it happens; and surprise the medical technicians when you're all of a sudden losing more blood on the table.
Personally, I wondered why there were any mortgages with "stated income" and "stated assets", in which the mortgage company didn't verify income and assets - liar's loans, as they were called.
Politics.
For example, Columbus, OH went on a spree where the city worked (at behest of I think the mayor IIRC) with banks to qualify financially poor people in the Columbus itself for mortgages in outlying towns, such as Reynoldsburg, OH where my parents are. It didn't matter what kind of income they had. The goal of the politicians was to get the poor out of Columbus and make them an SEP - "someone else's problem". And it worked, but it also saddled those outlying towns with (a) a higher housing demand and (b) people that were destined to be foreclosed on.
Case in point: One young lady in my parent's neighborhood graduated high school, didn't have a job, but got a mortgage for a $150k house. There was no way she was going to be able to make the payments, and was eventually foreclosed on, devaluing other houses in the neighborhood as a result.
As I said...there were many different factors. The above was one of them, and sadly those politicians will never be held accountable for that kind of fraud - fraud that really did make contributions to the over 2008 financial crisis.
the thing with 2008 isn't that 20% defaulted. it's that the banks built an insurance pyramid scheme to borrow more money and one bank was left holding the bad debt.
Bank A , B , C and D each have 100 loans of which 95% are good and 5% are bad. Each bank is maxed out on loans they can legally, and fiscally move. to make more money they need to insure the loans.
So Bank A and Bank B take 50 loans each 45 good one and the 5 bad ones and get insurance from bank C. This gives Bank A and B the ability to take on 20 more loans each with at least 2 of them being bad.
Bank C goes to Bank D for insurance and gives Bank D their 5 bad loans as well as the 10 bad loans from Banks A and B. this gives Bank C ability to also take on 20 more loans.
Bank D is now holding 190 loans including 20 bad ones and their risk went up from 5% to 10%.
Wash rinse repeat. they did this until one bank had 20% plus bad loans in their portfolio. when it collapsed all the cross insurance collapsed as well. That is why 75% of the government bailout loans were repayable in 4 months. The banks just needed to cover short term costs with the pyramid to each other.
Quite an over simplification, but it also assumes that the banks knew in advance which loans where bad - which they didn't.
One of the big pit falls for the home loans was that there were (a) a lot of loans that were themselves loans for other loans (Jumbo Mortgages, Subprime lending), and (b) there were a lot of loans with variable interest rates which were then defaulted on when the Federal Reserve attempted to raise the Interest Rates; inevitably there was quite a few of 'a' in 'b', and the various risk calculators that were used by the 'C' and 'D' banks in your example didn't know how to account for that kind of thing in the risk assessment, in part because it was unaware of some of the necessary parts of the risk and unable to control others.
Keep in mind that the mortgage grouping and selling that was part of the issue was a known thing. You bought a $1M USD note containing 10 mortgages knowing that 2 would default but it would be made up from and exceeded by the interest paid on the other 8. What was not accounted for was the issue of variable rate interest loans so when the interest rates when up a greater than expected number of loans defaulted, wiping out the ability to cover the $1M note.
Now there were several dozen different factors that caused the issues in 2008. However, a lot of the home mortgage issues were solved by (a) stopping the robo-signing practices that approved a lot of bad loans, (b) converting variable interest loans to fixed interest loans, and (c) actually trying to work with borrowers to solve the problems (typically variable interest loans). There was also quite a sizeable chunk of loans that were just completely written off - no sold, not insurance repaid, not government repaid; but actually taken off the books and discarded as a loss.
The money borrowed from the government, however, more or less was a temporary hold-over to stabilize the books and came with severe restrictions - which is really why it got repaid quickly as the banks didn't like the restrictions so they made every effort to repay it and get out from those restrictions instead of making the effort to restore a working economy as was intended by Congress.
Well, considering that as revealed by the OOXML ISO specifications there are quite a few functions in Excel - like FLOOR() and CEILING() - whose behavior is not the defined mathematical behavior...yes, to a certain degree Microsoft is culpable since it is a reasonable expectation that these functions should work as defined by mathematics and the result is subtle in its effect. (For instance, FLOOR(-2.5) in Excel will yield a result of -2 instead of -3.)
However, I would expect that someone that deals with these kinds of functions regularly - like a scientist - would be analyzing the data using tools other than Excel - such as SAS, R, Mathematica, MatLab, etc - where the functions are mathematically correct so these kinds of errors should have been caught. Thereby the researcher, scientist, engineer, etc are more culpable than Microsoft for these errors.
This is totally off-topic, but why do I see so many people refer to it as "Visual Studios"? It's not plural, and I don't think it ever has been, where does that come from?
B/c it's really multiple environments. Visual Studio provides multiple studios - C#, C++, Managed C++, VB.Net, F#, J#, Visual Installer,.. all the Microsoft specific languages and technologies. They're even using it as the base for other tools - SQL Server Studio/Manager.
MS is using its own custom distro. Every different piece of hardware has its own custom distro. The work of the open source community towards a common project has been so fragmented (not to mention so co-opted) that it's not common. And on top of that, people treat each other like crap, so that good ideas become splinter schism religions instead of adding to one common greater good. There isn't one Linux; there are dozens, perhaps hundreds, of Linux-like or Linux-derived systems, with no real guarantee of complete interoperability. Maybe "Linux will never win" is an oversimplification, but I stand by it.
Linux is just the operating system kernel, and there is only one real source tree - hosted at kernel.org - which has (a) thousands of options, (b) thousands of drivers, and (c) a few hundred CPU architectures, nearly all of which support every driver provided in-kernel. So there is only one Linux, but many builds of it depending on the use-case you're targeting.
Now to say each Linux distro is different is quite accurate. You can usually replace the Linux Kernel in most distro installations with your own custom variant that you made yourself - and I say most due to Tivoization where there's hardware+software locks to only allow the vendor to update it. Android really is just another Linux distribution; just like OpenWRT, Debian, or Slackware - it's userland is just dramatically different from other Linux distros, but the underlying Operating System kernel is still the same one as the others; it's just as close to a vanilla kernel as you get with Debian, Ubuntu, and Red Hat - that is, they all apply some patches for what they think makes it better.
So yes, "Linux wins", but there will never likely be any given Linux distro that will win. And honestly, Linus and the Linux Kernel community could care less about which Linux distro is on top or "winning".
Hmmm...I think the world begs to differ since Linux is on the vast majority of hardware out there - everything from watches to super computers (far more breadth than *any* other operating system or operating system kernel out there). And then there's also:
"If Microsoft ever does applications for Linux it means I've won." - Linus Torvalds
Slashdot Mirror
Maybe.
Knowing critical concepts...technical and business is essential. But when it comes to implementing those concepts, you need to know the mechanics. There is a place for code monkeys. Just as there is a place for analysts and architects. No one has, or can have, the complete solution. If you think you do, you are deluded.
Well, I'd argue that there isn't really any place for code monkeys, at least if you want to have customers. And yes, I've seen it first hand. One place I worked was a company (Company A) that was bought by another company (Company B). The two had very different philosophies of programming and hiring, and it reflected in the opinion their customers had of them. Company A hired mid-level to senior devs; had a small but knowledgeable team; and products that actually worked as advertised requiring little support from the software devs; yes, bugs still had to get fixed but they were not critical and the customer could still use the system. Company B would only hire one or may be two senior devs and then a bunch of cheap code monkeys out of college; a larger team but less knowledge; and they had a hard time delivering products. One case I am aware of their customer accepted the system (signed off the contract) to get rid of them so they could buy a difference system (which was a product of Company A before Company B bought them).
So if you need good products, good customer relations, etc it's best to stay away from code monkeys and hire people that can perform well and deliver products. If you can support having people in training (e.g out of college, train to become the next round of mid/senior devs) all the better; but even then the guys you hire out of college can be differentiated into code-monkeys and not based on their skill set at that time too and your good coders coming out of college won't be code monkeys.
If you can by-pass it then it effectively nullifies any security provided, so yes, it does count.
So if I try to rob a house, and I "bypass" the security system by robbing the next house over, does that mean the security system of the first house sucks?
If you are able to use entry into the second house to steal stuff from the first house, then yes, that the security on the first house is insufficient protection. If the two are completely unrelated, then the security of the first makes no difference.
In this case, card vs card+chip+pin is like two homes with a tunnel between them. The first home might be more secure, but the tunnel is doesn't have any security on it. So the valuables in the first house are still at risk through entry into the second house; and the guy that sold the first house to the current owners failed to mention the existence of the tunnel.
Even aside from that, chip+PIN it no where near as secure as things like Google Wallet that provide single-use card numbers for each transaction.
How is this more secure?
The card number is single use. If they try to use it again, it doesn't work. So it's more secure in the same way that a one-time password is more secure. Google approves the single transaction, and denies any further ones. So yes, it's actually more secure but it also relies on NFC (Wallet+NFC, now Android Pay). It's less secure in that you're putting your bank/credit cards at a single source (Google, Apple, etc) and then using their services to make more secure transactions with others - so single point of failure in security. However, you're card numbers won't be stolen from Target, Home Depot, Walmart, or any other vendor you do business with.
It's also been shown that people can completely clone a chip+PIN card, again rendering the added security null and void.
Do you have a citation?
here's a couple:
http://securityaffairs.co/word...
http://www.theage.com.au/it-pr... - also referenced at http://krebsonsecurity.com/201...
So yeah, if Krebs mentions it, it's probably been proven sufficiently, and likely happening.
This is even more silly, where I live if you simply put your card in backwards, the reader will say read error, ask you to swipe, then ask to put the card in again, if you put the card in backwards again it will ask to swipe and accept that. Yes you need to know the pin but you don't need the chip.
Yeah. It doesn't save anything - just causes more headaches. They're only going after it to shift some liability.
It reminds me of Microsoft Bob's security if you entered your password wrong 3 times it would ask if you wanted to change it.
lol...kind of like a disk encryption software I used a few employers ago...if you ran out of attempts it was suppose to require help desk to unlock it. I accidentally discovered all you had to do was reboot the computer - even a soft-reboot worked IIRC.
It doesn't count as "chip and pin" if the hack involves bypassing the use of the chip and pin. A safe can't protect any items that aren't actually in it.
If you can by-pass it then it effectively nullifies any security provided, so yes, it does count.
Even aside from that, chip+PIN it no where near as secure as things like Google Wallet that provide single-use card numbers for each transaction.
It's also been shown that people can completely clone a chip+PIN card, again rendering the added security null and void.
Just good to mention that Chip & PIN cards would not have prevented the Target breach in any way as mentioned in Brian Krebs follow up article: https://krebsonsecurity.com/20... "0 – The number of customer cards that Chip-and-PIN-enabled terminals would have been able to stop the bad guys from stealing had Target put the technology in place prior to the breach (without end-to-end encryption of card data, the card numbers and expiration dates can still be stolen and used in online transactions)."
Correct. Chip & PIN would not have solved anything.
To provide an example...I used my Chip card the other day. The vendor was having an issue with their chip reader, so the POS operator put in an override to allow it to be swiped. So another easy way to by pass the Chips? Make a hack that makes the system think the reader is unusable.
It is worse than that, because after they were shown that it could be done, they did nothing about it until this latest exploit threatened to make their failure general knowledge.
Why is it that the stupidest people always seem to be the ones making the decisions in matters of security?
Because everyone is stupid when it comes to security until something security related happens to them.
You can move into C++, but then you have to be extremely careful of new/delete support
How much more careful do you have to be of new/delete support than malloc/free support?
Not much I'll wager.
You actually have to completely avoid it until you setup the functions necessary to support it. It's been a while since I've looked at doing it, but it's non-trivial, as is much functionality at that early boot stage.
And it's not like you have to support it. None of my Atmel code uses new or delete. Static allocation all the way.
This is why most embedded and kernel stuff only uses C as even C++ adds enough bloat due to those supports that when every byte counts it's just not useful.
C++ does not add bloat. That's an old, false meme which needs to die.
True, you can avoid stuff by following best practices for embedded and using pure stack allocation. But that only goes so far. You can also run into issues with Exceptions. For instance http://wiki.osdev.org/Bare_Bon... documents several issues.
That is not how the supreme court interpreted it. You're correct the wording says that but the supreme court disagreed. The court was clear that treaties do not hold a privileged position over congress specifically allowing for them to pass laws to deny enforcement of, modify or repeal a treaty with nothing more than any other law.
No, they don't hold special position over Congress because Congress has to - and in accordance with the Consitution - approve all Treaties; and only Congress has that power. The SCOTUS ruling, as described, also doesn't mean that - again as per the Constitution - Treaties are not on par with the U.S Code (law) as opposed to their Constitutional place of being between the Constitution and U.S Code. They're not special by any means.
TPP and, and especially the Iran Deal, have a fault in how they are being pursued since SCOTUS has ruled that Congress cannot delegate its authority to other groups. So even though the Iran Deal may be accepted on its face without a specific vote for approval, that would not - per SCOTUS - make it legally binding.
K&R tells you to match a free() with every malloc(). Do so - no memory leaks. Yes, K&R doesn't teach you how to debug your code - it teaches you how to avoid the bug in the first place.
Mod parent up.
One of my first programmer reads was Elements of C by Morton H. Lewin (1986) which covered K&R C. I read it in 2004. It made me realize just how much C I actually do (I learned C/C++). even when doing C++. And yes, simple things like matching every malloc() call with an equivalent free() call is some of the essentials of programming without memory leaks.
Though in the C++ world if you're using a parenting model like Qt does, then the delete matching the new is usually (except in special well documented and obvious cases) handled by the parenting model - e.g. all objects have a parent; on destruction of an object, it automatically cleans up all its children; you have to clean up the ones that don't have parents, most of which can be managed by allocating them on the stack. While I'm sure you can figure out a similar approach in C, I'm not sure their is really any framework that does that in C.
The only benefit C++ arguably has over C in terms of avoiding common pitfalls is the STL and automatic destructors.
I probably do more C and than C++ when writing C++ code. I typically use C++ classes (abstract, etc), namespaces, and (now) STL. This just helps with segregating the code into their logical parts so structure X doesn't get used on functions only meant to manage structure Y or data type Z.
new/delete? Well, I'll use them for classes only. Structures get allocated with malloc/free. Yes, a class is only use for data+functions and structures are only used for pure data; allocation patterns follow this same methodology which enables easy transition between pure C and C/C++ code when necessary. If a class allocates data, then I also provide an API in the class (typically instance agnostic) to clean it up to ensure that there is one-place that cleans it up, ensuring that the same allocator/destructor methods are used.
I also stay away from streams when I have a choice, and prefer C-style printf/scanf processing.
So there are useful bits in C++; you just have to find the right balance. Doing so makes for very easy to maintain code.
But it's still just as error-prone (just fewer places for errors), and the fact that the destructor doesn't get called if the constructor throws isn't broadly internalized by coders (and is my least-favorite intermittent resource leak to run down).
Well, there is another (better) solution - stop using Exceptions! They cause more headaches than anything else, including leaving programs in unrecoverable states.
I know, I know - everyone loves Exceptions. But in all honestly, they should never be used. Functions/ClassMethods/etc should all be explicit in their error handling, and errors should always be handled as close to what generated the error as possible. This one little thing saves all of the headaches of trying to track down bad pointers, incorrect states, etc - e.g 99% of what people complain about in C and C++ code.
There's really no reason ever to use C over C++ if you have a C++ compiler available
Well, unless your bootstrapping an OS. C is the easiest language to move to from Assembly as there are zero things to setup to move into C. You can move into C++, but then you have to be extremely careful of new/delete support - which has to get setup almost immediately if you did not before you moved into C++ land. This is why most embedded and kernel stuff only uses C as even C++ adds enough bloat due to those supports that when every byte counts it's just not useful. I expect Rust would be more like C++ in that respect.
So as always, it's depends on what you do. In most cases, it probably won't make a difference. But there are some vital cases out there - especially in the embedded world - that the small differences have huge impacts.
You, my friend, need to learn about precompiled headers. If your modules have more than one include statement, you're doing it wrong. Large projects can compile quickly if set up correctly. Also, modern compilers can compile 8 files from a single project in parallel on an I7. I don't know if it's still true, but Visual Studio is / was terrible at this; only compiling single files from multiple projects in parallel. This caused bloat in the solution with multiple projects to get any kind of speed improvement in build times, at the cost of complexity.
I avoid pre-compiled headers at all cost. They only cause problems with builds, and typically don't save me anything since to correct those problems you have to blow away the pre-compiled headers any way.
There are different methods of being able to manage the header bloat you mentioned. On method (in C++) is forward declarations - e.g. you don't include any classes, etc; you just forward declare them, which works wonderfully when you keep the implementation out of the headers. The other big method (my favorite) is keeping you headers clean and well separated - including only what you have to and not everything under the sun (e.g no "#include " type stuff).
I know that's a joke, but it's of course nonsense. Plenty of people have gotten fired for using C, especially when their code had dangerous security vulnerabilities (which it ALWAYS does).
Wrong.
Yes, people have been fired for being bad programmers. I doubt many have been fired over security vulnerabilities, most likely because either (a) the vulnerability was discovered after the programmer already voluntarily left or (b) was rooted in standard operating procedures (e.g you just don't do that) - most due to people not realizing the consequences of network computers. (Prior to networking, security didn't really matter too much outside of specialized environments.)
Further more, C-based software probably runs about 99+% of devices out there - most notably everyone's favorite OS kernel - Linux - is entirely written in C, as is the Windows NT Kernel, the BSD Kernels, etc. Most all operating systems use it at the core, and many applications use it - IOW, the world runs on C; aside from Assembly is it probably the most used programming language out there when you look at all aspects of software (even C++ doesn't compare). It only bites you if, like with any tool (including Java), you mis-use it. Best practices will save you from 99.99% of issues.
Oh, and the OS's that don't use C in their kernel? They're all research or hobby stuff that more or less proves you could do it, but the performance is so abysmal (compared to the same thing in C) that no one would really use it, or they use C to bootstrap and load into their alternative language - typical of C++ OS Kernels. (Yes, there have been Java-based Operating Systems; they also relied on specialized hardware-based JVMs and no one uses them outside of small research projects.)
What your looking for is Head Money Cases, 112 U.S. 580 (1884) that said specifically that treaties do not hold special case above congress outside how they are negotiated and approved.
Except the Constitution places Treaties just under itself and above all other laws of the land - e.g a Treaty can only be invalid if it violates the Constitution, all other laws are subject to the Treaty on equal footing to the Constitution.
It is Science, Technology, Engineering, and Mathematics, I think comsci qualifies for the last three but not for the first one and I have a comsci degree.
Beat me to it. It's a mixture of engineering, maths, and art (we don't have technology degrees here so I'm not sure what that entails), but very little science. Like other fields that feel the need to put "science" in their name (for example political science), it mostly isn't.
It *should* be engineering, but it isn't. It's hard to qualify it as science as it's more like mathematical theory than anything else.
That said, CompSci should be split to have a formal engineering track for 99% of students, and a formal research/theory track for those that want to just stick to academia and related research. The software world would be better for it since a true discipline to how programs are written could be brought about instead of all this bs'ing over how it's art.
where I wouldn't dare venture with such things as implanted RFID chips.
Want to use your implanted RFID chip to access your bank via ATM? What's to stop criminals from cutting off your finger and racing to the nearest ATM before your finger and the chip become non-operational? Probably the PIN you also use to authenticate, but still.......
Ummmmm, the same thing that keeps them from stealing your card and doing the same thing? Yeah, stealing an ATM access device is already a problem, though not a huge one. What makes you think it will become a larger problem when the device in question is implanted? Seems like it would be a more difficult robbery with greater legal repercussions than a simple mugging.
What will stop them - or at least make it harder - would be additional bio-metrics requirements - things like needing a pulse, matching fingerprint, etc.
This is, of course, an issue for all biometrics authentication - an organ/appendage is forcefully removed, leaving the original owner for dead, and then used to access the systems it was for.
The greater legal repercussions will simply be "murder in the first degree" (e.g with intent) instead of a simple felony or misdemeanor for stealing their wallet.
Implants like fingertip magnets and RFID chips are as easy to remove as they are to put in. It shouldn't take more than a few minutes and can be done without anesthesia (though it may hurt...).
Well, an MRI will do it in just a couple seconds, and may happen incidentally - for instance, you're in a car wreck, unconscious, and they put you in an MRI to try figure out why (e.g check brain swelling, etc). It'll be painless when it happens; and surprise the medical technicians when you're all of a sudden losing more blood on the table.
So you are a time traveler?
"The artificial kidney project, which is targeted for clinical trials in 2017" -- http://www.ucsf.edu/news/2013/...
Probably just a kidney transplant...it would be "artificial" since it's from someone else; it'd also be "powered by [their] own metabolic process".
Personally, I wondered why there were any mortgages with "stated income" and "stated assets", in which the mortgage company didn't verify income and assets - liar's loans, as they were called.
Politics.
For example, Columbus, OH went on a spree where the city worked (at behest of I think the mayor IIRC) with banks to qualify financially poor people in the Columbus itself for mortgages in outlying towns, such as Reynoldsburg, OH where my parents are. It didn't matter what kind of income they had. The goal of the politicians was to get the poor out of Columbus and make them an SEP - "someone else's problem". And it worked, but it also saddled those outlying towns with (a) a higher housing demand and (b) people that were destined to be foreclosed on.
Case in point: One young lady in my parent's neighborhood graduated high school, didn't have a job, but got a mortgage for a $150k house. There was no way she was going to be able to make the payments, and was eventually foreclosed on, devaluing other houses in the neighborhood as a result.
As I said...there were many different factors. The above was one of them, and sadly those politicians will never be held accountable for that kind of fraud - fraud that really did make contributions to the over 2008 financial crisis.
the thing with 2008 isn't that 20% defaulted. it's that the banks built an insurance pyramid scheme to borrow more money and one bank was left holding the bad debt.
Bank A , B , C and D each have 100 loans of which 95% are good and 5% are bad. Each bank is maxed out on loans they can legally, and fiscally move. to make more money they need to insure the loans.
So Bank A and Bank B take 50 loans each 45 good one and the 5 bad ones and get insurance from bank C. This gives Bank A and B the ability to take on 20 more loans each with at least 2 of them being bad.
Bank C goes to Bank D for insurance and gives Bank D their 5 bad loans as well as the 10 bad loans from Banks A and B. this gives Bank C ability to also take on 20 more loans.
Bank D is now holding 190 loans including 20 bad ones and their risk went up from 5% to 10%.
Wash rinse repeat. they did this until one bank had 20% plus bad loans in their portfolio. when it collapsed all the cross insurance collapsed as well. That is why 75% of the government bailout loans were repayable in 4 months. The banks just needed to cover short term costs with the pyramid to each other.
Quite an over simplification, but it also assumes that the banks knew in advance which loans where bad - which they didn't.
One of the big pit falls for the home loans was that there were (a) a lot of loans that were themselves loans for other loans (Jumbo Mortgages, Subprime lending), and (b) there were a lot of loans with variable interest rates which were then defaulted on when the Federal Reserve attempted to raise the Interest Rates; inevitably there was quite a few of 'a' in 'b', and the various risk calculators that were used by the 'C' and 'D' banks in your example didn't know how to account for that kind of thing in the risk assessment, in part because it was unaware of some of the necessary parts of the risk and unable to control others.
Keep in mind that the mortgage grouping and selling that was part of the issue was a known thing. You bought a $1M USD note containing 10 mortgages knowing that 2 would default but it would be made up from and exceeded by the interest paid on the other 8. What was not accounted for was the issue of variable rate interest loans so when the interest rates when up a greater than expected number of loans defaulted, wiping out the ability to cover the $1M note.
Now there were several dozen different factors that caused the issues in 2008. However, a lot of the home mortgage issues were solved by (a) stopping the robo-signing practices that approved a lot of bad loans, (b) converting variable interest loans to fixed interest loans, and (c) actually trying to work with borrowers to solve the problems (typically variable interest loans). There was also quite a sizeable chunk of loans that were just completely written off - no sold, not insurance repaid, not government repaid; but actually taken off the books and discarded as a loss.
The money borrowed from the government, however, more or less was a temporary hold-over to stabilize the books and came with severe restrictions - which is really why it got repaid quickly as the banks didn't like the restrictions so they made every effort to repay it and get out from those restrictions instead of making the effort to restore a working economy as was intended by Congress.
That sounds about right.
Well, considering that as revealed by the OOXML ISO specifications there are quite a few functions in Excel - like FLOOR() and CEILING() - whose behavior is not the defined mathematical behavior...yes, to a certain degree Microsoft is culpable since it is a reasonable expectation that these functions should work as defined by mathematics and the result is subtle in its effect. (For instance, FLOOR(-2.5) in Excel will yield a result of -2 instead of -3.)
However, I would expect that someone that deals with these kinds of functions regularly - like a scientist - would be analyzing the data using tools other than Excel - such as SAS, R, Mathematica, MatLab, etc - where the functions are mathematically correct so these kinds of errors should have been caught. Thereby the researcher, scientist, engineer, etc are more culpable than Microsoft for these errors.
This is totally off-topic, but why do I see so many people refer to it as "Visual Studios"? It's not plural, and I don't think it ever has been, where does that come from?
B/c it's really multiple environments. Visual Studio provides multiple studios - C#, C++, Managed C++, VB.Net, F#, J#, Visual Installer,.. all the Microsoft specific languages and technologies. They're even using it as the base for other tools - SQL Server Studio/Manager.
MS is using its own custom distro. Every different piece of hardware has its own custom distro. The work of the open source community towards a common project has been so fragmented (not to mention so co-opted) that it's not common. And on top of that, people treat each other like crap, so that good ideas become splinter schism religions instead of adding to one common greater good. There isn't one Linux; there are dozens, perhaps hundreds, of Linux-like or Linux-derived systems, with no real guarantee of complete interoperability. Maybe "Linux will never win" is an oversimplification, but I stand by it.
Linux is just the operating system kernel, and there is only one real source tree - hosted at kernel.org - which has (a) thousands of options, (b) thousands of drivers, and (c) a few hundred CPU architectures, nearly all of which support every driver provided in-kernel. So there is only one Linux, but many builds of it depending on the use-case you're targeting.
Now to say each Linux distro is different is quite accurate. You can usually replace the Linux Kernel in most distro installations with your own custom variant that you made yourself - and I say most due to Tivoization where there's hardware+software locks to only allow the vendor to update it. Android really is just another Linux distribution; just like OpenWRT, Debian, or Slackware - it's userland is just dramatically different from other Linux distros, but the underlying Operating System kernel is still the same one as the others; it's just as close to a vanilla kernel as you get with Debian, Ubuntu, and Red Hat - that is, they all apply some patches for what they think makes it better.
So yes, "Linux wins", but there will never likely be any given Linux distro that will win. And honestly, Linus and the Linux Kernel community could care less about which Linux distro is on top or "winning".
This is why Linux will NEVER WIN
Hmmm...I think the world begs to differ since Linux is on the vast majority of hardware out there - everything from watches to super computers (far more breadth than *any* other operating system or operating system kernel out there). And then there's also:
"If Microsoft ever does applications for Linux it means I've won." - Linus Torvalds
Which since Microsoft is now making a version fo Visual Studios for Linux, is using its own custom Linux Distro in its data center....
well, I'll just leave it to you, but it seems that Linux has indeed won.