the climate has changed over the past. many times it was tremendously slow process, taking place over millions of years, which is the same timescale at which evolution and adaptation work, so it worked out.
And many times -- just during the last few million years for which we have ice core records -- it has happened in decades. There are examples of >7C changes (which is huge... like moving Nordic climate to the Mediterranean or vice versa) in less than 30 years.
In any case, my primary point is that debating the cause is really only useful insofar as it provides us with solutions... and the anthropogenic assumption does point toward one potential solution, but we don't know if that solution is adequate at this point, even if the warming is 100% anthropogenic (which we don't know), and shouldn't get fixated on it as the only approach.
Well sure it matters! Since there's bloody little we can do about it, the question is, how guilty should we feel? If it's AGW, the guilt is higher, and if it's GW, we're victims. Big difference.
Why does how we feel matter? It doesn't affect the sea level.
I'm not claiming it's not anthropogenic. I'm just saying it doesn't really matter whether it is or not. In either case, we need to react to the world as it is, and fix it so that it is/becomes the way we want it to be.
What I find interesting is Bing's result for that query: The top hit in the search results -- not ads -- is "Apps for Windows". #2 is the Google Play store and #3 is the Apple App Store. I get the same results when searching on from Chrome on Linux and from Safari on OS X.
It's possible that this result is an accurate reflection of what Bing users want, biased by the self-selection effect that only people who are deeply wedded to Microsoft's platforms use Bing. But it really seems like this is a case of artificial search result manipulation. Granted that Bing clearly has no monopoly position and is therefore under no obligation to play fair, it still seems unwise and wrong.
Great thread. You guys have done an excellent job of clarifying the issue and getting to the core questions. Much better than most/. discussion of this topic. It's almost like old slashdot.
The story below says "US Rust Belt Manufacturing Rebounds Via Fracking Boom" and asks 'do the associated environmental risks of new "tight oil" extraction techniques outweigh the benefits to these depressed economic regions?'
Well, do they?
I think that's fundamentally unknowable.
The reason is that knowing the answer depends on two pieces of knowledge, one which is hard to estimate and the other which is impossible to know. The hard-to-estimate one is the actual environmental impact of fracking, which may be anything from negligible to catastrophic. The impossible-to-know one is the ability of future technology to mitigate that environmental impact.
In the short term, the answer is clear, though: Yes. If your time horizon is just a few years, the economic benefits of fracking do outweigh the environmental impact.
IMO, the rational approach, therefore, is to proceed with fracking, but to do it cautiously, investing a portion of the economic benefit into research into the environmental impacts and mitigation strategies.
I think a bit part of the problem is the "A" in "AGW". Does it really matter whether the warming is anthropogenic or not? Won't the effects of warming be the same, regardless of the cause? I mean, it's not like we don't have ample historical data showing large swings in global temperatures over the course of just a few years, including to averages much, much higher than what we have now. Indeed, the geological record offers ample evidence that the most common (not "normal", because there really isn't a "normal") state of the planet's climate is quite a LOT hotter than what it's been in recorded history -- the human time period has been during a short warm period in an era of ice ages. Sure, the current warming is most likely caused by our actions, but regardless of that it could also be entirely "natural" and happen just the same, with the same effects.
I think people focus on the question of anthropogenesis because there's an implicit assumption that if it's not anthropogenic, then there's nothing we can/should be doing about it. The "can" alternative is at least possibly-logical, though it assumes powerlessness that I refuse to accept. The "should" alternative is just ridiculous.
The fact is that even if we manage to reduce our CO2 emissions to zero, we will face serious climate change eventually, and we have little idea when that might be. Perhaps even right now. Therefore, what we should be doing is learning to understand and modify the Earth's climate. The only way we can have "sustainability" is if we take control.
An obvious corollary of this view is that we should not be looking merely to emissions reduction as a way to fix the problem. First, it may not fix the problem, either because it's already too late, or because our emissions aren't the cause, or aren't the major part of the cause (note that I don't believe that, but it's possible). Second, even if it does fix this problem, at some point we'll face warming which we can't stop that way. So, in addition to trying to limit emissions, we should also be seriously researching other approaches to cooling the planet, perhaps by raising the albedo, or reducing incoming solar radiation (which we may have done a few decades ago by pumping a lot of particulates into the atmosphere, along with the CO2). For that matter, we should also be looking into methods of warming the planet. Should the local warm period end and return us to the ice ages, we may well appreciate the outcome of our recent accidental experiment in global warming via CO2 production.
Knowledge is the key. We need to understand how the system works, and how to manipulate it, because we DO need to be able to manipulate it. Or adapt to it, but manipulation will be more cost-effective in many cases, I think.
if i was china, i wouldn't want my peeps using google. it will result in MASSIVE American data collection and knowledge of everything that chinese people are searching for online. A major risk to national stability/security.
They don't block/degrade Google access in order to prevent information about citizens from leaking out to the rest of the world. They do it to prevent information from the rest of the world from reaching their citizens.
Home Depot deployed new card readers at all their stores (of the ones I saw at least) almost overnight shortly after the target breach. I had guessed it was in response to the breach to beef up security...
But it looks like it was the new ones that were compromised... (or else it was coincidental).
I doubt the new readers had any relationship to the Target breach. Home Depot was just being proactive and getting the new tech in well ahead of the liability shift, which is coming late next year. The Home Depot near me got them over a year before the Target breach. I know because I started using my Google Wallet there in late 2011.
The fundamental problems, though, depend on the cards, not just the terminals. As long as you're swiping a magnetic stripe you're vulnerable because (a) the POS system receives all of the card info in plaintext and (b) it's easy for skimmers to copy that data onto their own magnetic stripes. So new terminals are only half of the solution, and not the half that retailers can address -- though they should be working harder to ensure the security of the payment data they handle.
If the retailer has a chip and pin machine, but the card issuer has only swipe, then the card issuer is liable.
One correction: The US isn't going to Chip and PIN, but Chip and Signature.
Given the federal laws that prevent issuers from placing (significant) liability on cardholders, there's less motivation for imposing the inconvenience of PINs (you can debate whether signature or PIN is more convenient, but US consumers have traditionally preferred the former). In the UK, for example, Chip & PIN has allowed banks to shift the liability almost completely to the cardholder, so in that sense US cardholders are better off.
Expecting they would not seek to maximally leverage their position is not a serious option.
Well, as a Googler, I definitely do not expect Google to do anything remotely like this with their cloud offerings. Heck, Google is careful to ensure there are mechanisms for users of their free services to take their data out, and holding someone's data hostage for more money or whatever just runs counter to everything the culture holds important. I don't think Amazon would do it either. Smaller players... I suppose it's possible, but it still seems like bad business on their part.
the Cloud threatening to cut off access to the data with no option to export if the user didn't agree to unfavorable terms
That's a *very* strong assertion. In fact, it seems like the sort of thing that the courts would stop, hard. It's essentially extortion. It's absolutely the sort of thing that would send customers screaming... and discouraging everyone around them. I find it hard to believe that any reputable cloud service provider would dare risk their business by doing something like that.
First, they often dishonestly hire the H1-B's (frequently by tailoring "job requirements" in ways that only the people they want fit the "requirements" even when these phoney requirements have no relationship to the job
Umm, Google doesn't define detailed requirements for technical positions. In fact, they don't even hire people for specific positions. The interview and hiring process is all about identifying people who are smart and can think on their feet, and decisions about what projects to put them on come after the hiring decision has been made. It's expected that almost nothing you know from any previous job will even apply at Google because the environment and tools are so different (everything is custom, in-house).
What you're describing definitely does happen -- I've seen it! -- but it's not relevant at the companies involved here.
Were that true, they wouldn't be involved in this class action.
This class action has nothing to do with H1-Bs. I don't think it was even so much about keeping wages down, as it does executives thinking their friends shouldn't be "stealing" from them. Though it definitely did prevent wage increases.
Really? Evil? I don't buy it one bit. He sold a set of software products that companies wanted to buy. Products that were no fun to support, of course, or for geeks to use in many cases, but let's please not confuse "icky" with "evil".
"Evil" is probably too strong, but Microsoft's misdeeds were considerably worse than merely making products that were less than ideal. Microsoft engaged in some pretty shady business practices which were clearly detrimental to the competitive landscape, harming consumers not just by providing inferior products but by actively preventing better products from being able to reach them.
The most serious of these actions was in the agreements they made OEMs sign in order to sell machines with Windows (and before that, DOS). Because the MS OSes were dominant, OEMs had to have access to their products, so Microsoft leveraged that by requiring OEMs to sign exclusivity agreements guaranteeing that the OEMs would not offer for sale PCs with any competing software. This is the abuse that the anti-trust trial really should have focused on, not the browser wars.
There were many other examples, though. Lots of cases in which Microsoft abused their OS dominance to prevent competitive apps from running well, stabbed business partners in the back, made moves to suppress useful new technologies until they could get around to making their own (generally inferior) version, etc. Largely, this was just business as usual for an aggressive and not particularly moral company, but given Microsoft's commanding position much of it really crossed the line.
And, of course, there's the fact that when Microsoft got hauled into court and ultimately signed a consent decree agreeing to limit certain anti-competitive behaviors, they just ignored the decree.
I could go on, but it doesn't matter. All of that is in the past, because Microsoft, while still very powerful, is no longer in a position to be as dangerous as they were, and the company does seem to have mellowed and become a somewhat better corporate citizen as well.
But they definitely were much worse than what you describe, though clearly not evil on the scale of ISIS.
Your suggestion has some implicit assumptions which I don't think are valid in this case. At the level of Apple, Google, et al., they don't hire H1-Bs to suppress wages. At Google, at least, I know that salary is a non-issue in the hiring process. Salary requirements aren't even considered until after the hire/no-hire decision is made, and even then they have little impact on the offer... Google offers what it considers reasonable based on your experience, etc. And, actually, Google offers such good money that it's uncommon for candidates who receive offers to turn them down. So Google is paying enough to attract American talent. Google also hires people on H1-Bs, but only because Google hires anyone who is legally hire-able and can make it through the interview process and hiring committee. I strongly suspect that Apple is the same.
I'm not denying that there are segments of the industry who hire H1-Bs in preference to Americans in order to keep wages down, but I really don't think that's the case at the companies involved in this case.
Your DNA is part of you, as are your fingerprints, and may carry evidence against you. The fifth amendment protection against self-incrimination does not extend to refusing to give your DNA or fingerprints. You do have the right to refuse to give them voluntarily, but if there is probable cause the police can obtain a warrant and force you to provide samples. This actually exactly the same standard as with other items you might possess... your home, your papers, your cellphone, etc.
I think other forms of evidence embedded in your body will be treated similarly. You can't be compelled to give verbal testimony, but if you choose to have a recorder embedded in your body that gathers evidence that can be used against you, it will be legally permissible to compel you to hand over that evidence, unless doing so would physically harm you.
Now that I've expressed my opinion, I'll go RTFA to see if the author has a different one, and if he's convincing.
Another option, if it's really only a handful of long trips per year, is to rent a car.
I actually did that several times last year. My commuter is a Nissan LEAF, which obviously doesn't have the range for long trips, and my other vehicle is a Dodge Durango, great for trips of any length, except that it gets about 17 mpg at 80 mph. I drove round trip from the Denver area to the Salt Lake area several times and found it cost-effective and very pleasant to rent a Prius. The savings on fuel more than covered the rental, and I also didn't rack up the miles on my vehicle.
The reason I have the Durango is something else that EVs may not be able to touch for a while, not until battery prices drop dramatically: I need a vehicle that can tow heavy trailers (boat, camp trailer, mostly).
Assuming I didn't have that need, and assuming my EV had a little more range than the LEAF, say 200 miles, I think I could live just fine with only an EV and the year-round savings on gas (electricity is *much* cheaper) would easily cover a few rentals.
There's no point, because battery swapping is a silly way for achieving long ranges for electric vehicles. To make it really practical you need to make the batteries smaller, lighter and more accessible (== less well-protected) than they could be. Smaller and lighter means less range and more swapping required. Plus there are all sorts of practical and economic issues with swapping. It's much better just to have a semi-permanent battery which is large enough to take you a reasonable distance, plus sufficiently fast charging that stopping for a bite to eat and a restroom break is long enough to get you topped up enough for some more hours of driving.
Tesla has the right model, I think. Cars with a few hundred miles' range and networks of fast chargers. The top-end Model S still doesn't have quite enough range; we need battery prices to come down a bit more for that, but it's in the ballpark. Get it to, say, 500 miles with one-hour recharges, and you're good for any reasonable trip, and most unreasonable ones.
Really can you point to any contemporary operating system that would NOT free all the memory allocated to a process when it exists?
Obviously not. If there were such an OS it would be broken.
The point is that if you're managing your memory well, by the time you exit every allocated block will have been freed by your code. Yes, this is a little more work than appears to be absolutely necessary, but when that function which allocated a block which you expect to be released at exit, and which you know is only going to be called once, ends up being called in a loop a few years later, the maintainer who makes that change will hate you. And note that said maintainer may well be you.
Rofl.
Acacademic half knowledge with complete wrongs
Dude. I've been a professional software developer for 25 years, and am a respected engineer at one of the biggest names in software. You use my software daily.
If there are any heap-allocated blocks remaining (not freed) at exit, the program has a memory leak
No it has not. Where should the memory go to after the program has exited?
Well, obviously it'll all be returned to the system after exit. The point is to check AT EXIT. If there are any blocks still allocated, you've screwed up.
Technically you can test a 40 lines mess of loops and if cascades, practicaly you can't... or how likely is it that you can prove me in a reasonable time that a certain branch in an if - else inside of a cascade of nested loops and if's is executed with meaningfull data in your test? Especially if I have written the function and you want to write the test?
I've done it many times. Just check to see which branches aren't being executed and work out what needs to be done to execute them.
Though it's much, much better to refactor the function first.
The rest I leave as it stands if you like to argue about how likely it is that a single compilation unit has a bug that is not dicovered by a functional user acceptance test... unit tests without user acceptance tests or integration tests are pointless.
I've found thousands of bugs with unit tests that were not discovered by functional tests, integration tests, or user acceptance tests. In fact, unit tests are the most likely ones to find thing like subtle boundary condition errors which are hard to reproduce and are the source of nasty, rare bugs that are seen in production only once in a while.
The next thing is you tell me to test getters and setters...
Typically those get exercised by integration tests... and it is a good idea to have coverage of them at some point in your automated suite, because the whole point of getters and setters is that they may someday become non-trivial. Writing tests for them at that point isn't as good as already having tests in place, because you want to verify that your new implementation doesn't have subtle differences in behavior.
But you will figure that soon enough when you have 100% code coverage and still have bugs and wonder why
No one is claiming that unit tests are sufficient, only that they're necessary.
Btw, I never was in a team that had a memory leak in a GCed language.
Then you haven't worked on many non-trivial systems.
In a static typed language unit tests are pretty pointless.
Because static typing catches all bugs? That must be some statically-typed language that I've never seen. Unit tests are perhaps marginally less necessary than in dynamically-typed languages, but they're still necessary. Test-Driven Development is a life saver regardless of your toolset.
I can write you in 40 lines a function which you wont be able to automatically test. It only needs some nested loops and an 'if' cascades with loops inside.
There's nothing untestable about such a function. Basic code coverage tools will even identify any branches within the code that aren't taken, so you know to look for ways to write test cases that cover those branches. What's harder is ensuring coverage of all of the issues that could be provoked by different input data, even after you've covered all of the paths. With experience you learn to do that quite effectively, though.
Sure: you should refactor that into a lot of small functions, containing only a single loop or a single 'if'.
FTFY. Change it to "must" if I'm your code reviewer.
You lost quite some credibility with using terms or sentences like That even includes memory leaks when exiting. and "... even if that means correct use of the garbage collector..."
Unfortunately a exiting program can not leak memory
Sure it can. If there are any heap-allocated blocks remaining (not freed) at exit, the program has a memory leak. Again, there are good tools to help you find these leaks, like valgrind memcheck.
you don't use a garbage collector, it runs in the background. You can parametrize it perhaps... but thats it. (and please don't tell me you are doing System.gc() in Java programs at "random" intervals)
And yet you can still have leaks in garbage-collected environments, and there are ways to test for them. It's a bit more complex than in non-GC'd environments, but it can -- and must! -- be tested if you want to have reliable software.
Slashdot Mirror
the climate has changed over the past. many times it was tremendously slow process, taking place over millions of years, which is the same timescale at which evolution and adaptation work, so it worked out.
And many times -- just during the last few million years for which we have ice core records -- it has happened in decades. There are examples of >7C changes (which is huge... like moving Nordic climate to the Mediterranean or vice versa) in less than 30 years.
In any case, my primary point is that debating the cause is really only useful insofar as it provides us with solutions... and the anthropogenic assumption does point toward one potential solution, but we don't know if that solution is adequate at this point, even if the warming is 100% anthropogenic (which we don't know), and shouldn't get fixated on it as the only approach.
Well sure it matters! Since there's bloody little we can do about it, the question is, how guilty should we feel? If it's AGW, the guilt is higher, and if it's GW, we're victims. Big difference.
Why does how we feel matter? It doesn't affect the sea level.
I'm not claiming it's not anthropogenic. I'm just saying it doesn't really matter whether it is or not. In either case, we need to react to the world as it is, and fix it so that it is/becomes the way we want it to be.
What I find interesting is Bing's result for that query: The top hit in the search results -- not ads -- is "Apps for Windows". #2 is the Google Play store and #3 is the Apple App Store. I get the same results when searching on from Chrome on Linux and from Safari on OS X.
It's possible that this result is an accurate reflection of what Bing users want, biased by the self-selection effect that only people who are deeply wedded to Microsoft's platforms use Bing. But it really seems like this is a case of artificial search result manipulation. Granted that Bing clearly has no monopoly position and is therefore under no obligation to play fair, it still seems unwise and wrong.
Great thread. You guys have done an excellent job of clarifying the issue and getting to the core questions. Much better than most /. discussion of this topic. It's almost like old slashdot.
The story below says "US Rust Belt Manufacturing Rebounds Via Fracking Boom" and asks 'do the associated environmental risks of new "tight oil" extraction techniques outweigh the benefits to these depressed economic regions?'
Well, do they?
I think that's fundamentally unknowable.
The reason is that knowing the answer depends on two pieces of knowledge, one which is hard to estimate and the other which is impossible to know. The hard-to-estimate one is the actual environmental impact of fracking, which may be anything from negligible to catastrophic. The impossible-to-know one is the ability of future technology to mitigate that environmental impact.
In the short term, the answer is clear, though: Yes. If your time horizon is just a few years, the economic benefits of fracking do outweigh the environmental impact.
IMO, the rational approach, therefore, is to proceed with fracking, but to do it cautiously, investing a portion of the economic benefit into research into the environmental impacts and mitigation strategies.
I think a bit part of the problem is the "A" in "AGW". Does it really matter whether the warming is anthropogenic or not? Won't the effects of warming be the same, regardless of the cause? I mean, it's not like we don't have ample historical data showing large swings in global temperatures over the course of just a few years, including to averages much, much higher than what we have now. Indeed, the geological record offers ample evidence that the most common (not "normal", because there really isn't a "normal") state of the planet's climate is quite a LOT hotter than what it's been in recorded history -- the human time period has been during a short warm period in an era of ice ages. Sure, the current warming is most likely caused by our actions, but regardless of that it could also be entirely "natural" and happen just the same, with the same effects.
I think people focus on the question of anthropogenesis because there's an implicit assumption that if it's not anthropogenic, then there's nothing we can/should be doing about it. The "can" alternative is at least possibly-logical, though it assumes powerlessness that I refuse to accept. The "should" alternative is just ridiculous.
The fact is that even if we manage to reduce our CO2 emissions to zero, we will face serious climate change eventually, and we have little idea when that might be. Perhaps even right now. Therefore, what we should be doing is learning to understand and modify the Earth's climate. The only way we can have "sustainability" is if we take control.
An obvious corollary of this view is that we should not be looking merely to emissions reduction as a way to fix the problem. First, it may not fix the problem, either because it's already too late, or because our emissions aren't the cause, or aren't the major part of the cause (note that I don't believe that, but it's possible). Second, even if it does fix this problem, at some point we'll face warming which we can't stop that way. So, in addition to trying to limit emissions, we should also be seriously researching other approaches to cooling the planet, perhaps by raising the albedo, or reducing incoming solar radiation (which we may have done a few decades ago by pumping a lot of particulates into the atmosphere, along with the CO2). For that matter, we should also be looking into methods of warming the planet. Should the local warm period end and return us to the ice ages, we may well appreciate the outcome of our recent accidental experiment in global warming via CO2 production.
Knowledge is the key. We need to understand how the system works, and how to manipulate it, because we DO need to be able to manipulate it. Or adapt to it, but manipulation will be more cost-effective in many cases, I think.
if i was china, i wouldn't want my peeps using google. it will result in MASSIVE American data collection and knowledge of everything that chinese people are searching for online. A major risk to national stability/security.
They don't block/degrade Google access in order to prevent information about citizens from leaking out to the rest of the world. They do it to prevent information from the rest of the world from reaching their citizens.
Home Depot deployed new card readers at all their stores (of the ones I saw at least) almost overnight shortly after the target breach. I had guessed it was in response to the breach to beef up security...
But it looks like it was the new ones that were compromised... (or else it was coincidental).
I doubt the new readers had any relationship to the Target breach. Home Depot was just being proactive and getting the new tech in well ahead of the liability shift, which is coming late next year. The Home Depot near me got them over a year before the Target breach. I know because I started using my Google Wallet there in late 2011.
The fundamental problems, though, depend on the cards, not just the terminals. As long as you're swiping a magnetic stripe you're vulnerable because (a) the POS system receives all of the card info in plaintext and (b) it's easy for skimmers to copy that data onto their own magnetic stripes. So new terminals are only half of the solution, and not the half that retailers can address -- though they should be working harder to ensure the security of the payment data they handle.
This hinges on the cost of liability being greater than the cost of upgrading.
It is. Far greater.
You can bet that Home Depot or Walmart will find a way to push this cost onto the customer
Home Depot has already installed chip-capable terminals (I use them all the time). Walmart already has in many locations as well.
If the retailer has a chip and pin machine, but the card issuer has only swipe, then the card issuer is liable.
One correction: The US isn't going to Chip and PIN, but Chip and Signature.
Given the federal laws that prevent issuers from placing (significant) liability on cardholders, there's less motivation for imposing the inconvenience of PINs (you can debate whether signature or PIN is more convenient, but US consumers have traditionally preferred the former). In the UK, for example, Chip & PIN has allowed banks to shift the liability almost completely to the cardholder, so in that sense US cardholders are better off.
Expecting they would not seek to maximally leverage their position is not a serious option.
Well, as a Googler, I definitely do not expect Google to do anything remotely like this with their cloud offerings. Heck, Google is careful to ensure there are mechanisms for users of their free services to take their data out, and holding someone's data hostage for more money or whatever just runs counter to everything the culture holds important. I don't think Amazon would do it either. Smaller players... I suppose it's possible, but it still seems like bad business on their part.
the Cloud threatening to cut off access to the data with no option to export if the user didn't agree to unfavorable terms
That's a *very* strong assertion. In fact, it seems like the sort of thing that the courts would stop, hard. It's essentially extortion. It's absolutely the sort of thing that would send customers screaming... and discouraging everyone around them. I find it hard to believe that any reputable cloud service provider would dare risk their business by doing something like that.
First, they often dishonestly hire the H1-B's (frequently by tailoring "job requirements" in ways that only the people they want fit the "requirements" even when these phoney requirements have no relationship to the job
Umm, Google doesn't define detailed requirements for technical positions. In fact, they don't even hire people for specific positions. The interview and hiring process is all about identifying people who are smart and can think on their feet, and decisions about what projects to put them on come after the hiring decision has been made. It's expected that almost nothing you know from any previous job will even apply at Google because the environment and tools are so different (everything is custom, in-house).
What you're describing definitely does happen -- I've seen it! -- but it's not relevant at the companies involved here.
Were that true, they wouldn't be involved in this class action.
This class action has nothing to do with H1-Bs. I don't think it was even so much about keeping wages down, as it does executives thinking their friends shouldn't be "stealing" from them. Though it definitely did prevent wage increases.
Really? Evil? I don't buy it one bit. He sold a set of software products that companies wanted to buy. Products that were no fun to support, of course, or for geeks to use in many cases, but let's please not confuse "icky" with "evil".
"Evil" is probably too strong, but Microsoft's misdeeds were considerably worse than merely making products that were less than ideal. Microsoft engaged in some pretty shady business practices which were clearly detrimental to the competitive landscape, harming consumers not just by providing inferior products but by actively preventing better products from being able to reach them.
The most serious of these actions was in the agreements they made OEMs sign in order to sell machines with Windows (and before that, DOS). Because the MS OSes were dominant, OEMs had to have access to their products, so Microsoft leveraged that by requiring OEMs to sign exclusivity agreements guaranteeing that the OEMs would not offer for sale PCs with any competing software. This is the abuse that the anti-trust trial really should have focused on, not the browser wars.
There were many other examples, though. Lots of cases in which Microsoft abused their OS dominance to prevent competitive apps from running well, stabbed business partners in the back, made moves to suppress useful new technologies until they could get around to making their own (generally inferior) version, etc. Largely, this was just business as usual for an aggressive and not particularly moral company, but given Microsoft's commanding position much of it really crossed the line.
And, of course, there's the fact that when Microsoft got hauled into court and ultimately signed a consent decree agreeing to limit certain anti-competitive behaviors, they just ignored the decree.
I could go on, but it doesn't matter. All of that is in the past, because Microsoft, while still very powerful, is no longer in a position to be as dangerous as they were, and the company does seem to have mellowed and become a somewhat better corporate citizen as well.
But they definitely were much worse than what you describe, though clearly not evil on the scale of ISIS.
Fair? Cancel all of their H1B visas.
Your suggestion has some implicit assumptions which I don't think are valid in this case. At the level of Apple, Google, et al., they don't hire H1-Bs to suppress wages. At Google, at least, I know that salary is a non-issue in the hiring process. Salary requirements aren't even considered until after the hire/no-hire decision is made, and even then they have little impact on the offer... Google offers what it considers reasonable based on your experience, etc. And, actually, Google offers such good money that it's uncommon for candidates who receive offers to turn them down. So Google is paying enough to attract American talent. Google also hires people on H1-Bs, but only because Google hires anyone who is legally hire-able and can make it through the interview process and hiring committee. I strongly suspect that Apple is the same.
I'm not denying that there are segments of the industry who hire H1-Bs in preference to Americans in order to keep wages down, but I really don't think that's the case at the companies involved in this case.
Your DNA is part of you, as are your fingerprints, and may carry evidence against you. The fifth amendment protection against self-incrimination does not extend to refusing to give your DNA or fingerprints. You do have the right to refuse to give them voluntarily, but if there is probable cause the police can obtain a warrant and force you to provide samples. This actually exactly the same standard as with other items you might possess... your home, your papers, your cellphone, etc.
I think other forms of evidence embedded in your body will be treated similarly. You can't be compelled to give verbal testimony, but if you choose to have a recorder embedded in your body that gathers evidence that can be used against you, it will be legally permissible to compel you to hand over that evidence, unless doing so would physically harm you.
Now that I've expressed my opinion, I'll go RTFA to see if the author has a different one, and if he's convincing.
Another option, if it's really only a handful of long trips per year, is to rent a car.
I actually did that several times last year. My commuter is a Nissan LEAF, which obviously doesn't have the range for long trips, and my other vehicle is a Dodge Durango, great for trips of any length, except that it gets about 17 mpg at 80 mph. I drove round trip from the Denver area to the Salt Lake area several times and found it cost-effective and very pleasant to rent a Prius. The savings on fuel more than covered the rental, and I also didn't rack up the miles on my vehicle.
The reason I have the Durango is something else that EVs may not be able to touch for a while, not until battery prices drop dramatically: I need a vehicle that can tow heavy trailers (boat, camp trailer, mostly).
Assuming I didn't have that need, and assuming my EV had a little more range than the LEAF, say 200 miles, I think I could live just fine with only an EV and the year-round savings on gas (electricity is *much* cheaper) would easily cover a few rentals.
There's no point, because battery swapping is a silly way for achieving long ranges for electric vehicles. To make it really practical you need to make the batteries smaller, lighter and more accessible (== less well-protected) than they could be. Smaller and lighter means less range and more swapping required. Plus there are all sorts of practical and economic issues with swapping. It's much better just to have a semi-permanent battery which is large enough to take you a reasonable distance, plus sufficiently fast charging that stopping for a bite to eat and a restroom break is long enough to get you topped up enough for some more hours of driving.
Tesla has the right model, I think. Cars with a few hundred miles' range and networks of fast chargers. The top-end Model S still doesn't have quite enough range; we need battery prices to come down a bit more for that, but it's in the ballpark. Get it to, say, 500 miles with one-hour recharges, and you're good for any reasonable trip, and most unreasonable ones.
I'm not interested in educating people who don't want to be educated. Just please tell me what software you write, so I can avoid it.
Tell you what, you buy a cow and start selling milk, see how you go.
Heh. Actually I've worked a dairy farm. And there were no government-issued medallions, and yet things worked out just fine.
Really can you point to any contemporary operating system that would NOT free all the memory allocated to a process when it exists?
Obviously not. If there were such an OS it would be broken.
The point is that if you're managing your memory well, by the time you exit every allocated block will have been freed by your code. Yes, this is a little more work than appears to be absolutely necessary, but when that function which allocated a block which you expect to be released at exit, and which you know is only going to be called once, ends up being called in a loop a few years later, the maintainer who makes that change will hate you. And note that said maintainer may well be you.
Rofl. Acacademic half knowledge with complete wrongs
Dude. I've been a professional software developer for 25 years, and am a respected engineer at one of the biggest names in software. You use my software daily.
If there are any heap-allocated blocks remaining (not freed) at exit, the program has a memory leak No it has not. Where should the memory go to after the program has exited?
Well, obviously it'll all be returned to the system after exit. The point is to check AT EXIT. If there are any blocks still allocated, you've screwed up.
Technically you can test a 40 lines mess of loops and if cascades, practicaly you can't ... or how likely is it that you can prove me in a reasonable time that a certain branch in an if - else inside of a cascade of nested loops and if's is executed with meaningfull data in your test? Especially if I have written the function and you want to write the test?
I've done it many times. Just check to see which branches aren't being executed and work out what needs to be done to execute them.
Though it's much, much better to refactor the function first.
The rest I leave as it stands if you like to argue about how likely it is that a single compilation unit has a bug that is not dicovered by a functional user acceptance test ... unit tests without user acceptance tests or integration tests are pointless.
I've found thousands of bugs with unit tests that were not discovered by functional tests, integration tests, or user acceptance tests. In fact, unit tests are the most likely ones to find thing like subtle boundary condition errors which are hard to reproduce and are the source of nasty, rare bugs that are seen in production only once in a while.
The next thing is you tell me to test getters and setters ...
Typically those get exercised by integration tests... and it is a good idea to have coverage of them at some point in your automated suite, because the whole point of getters and setters is that they may someday become non-trivial. Writing tests for them at that point isn't as good as already having tests in place, because you want to verify that your new implementation doesn't have subtle differences in behavior.
But you will figure that soon enough when you have 100% code coverage and still have bugs and wonder why
No one is claiming that unit tests are sufficient, only that they're necessary.
Btw, I never was in a team that had a memory leak in a GCed language.
Then you haven't worked on many non-trivial systems.
In a static typed language unit tests are pretty pointless.
Because static typing catches all bugs? That must be some statically-typed language that I've never seen. Unit tests are perhaps marginally less necessary than in dynamically-typed languages, but they're still necessary. Test-Driven Development is a life saver regardless of your toolset.
I can write you in 40 lines a function which you wont be able to automatically test. It only needs some nested loops and an 'if' cascades with loops inside.
There's nothing untestable about such a function. Basic code coverage tools will even identify any branches within the code that aren't taken, so you know to look for ways to write test cases that cover those branches. What's harder is ensuring coverage of all of the issues that could be provoked by different input data, even after you've covered all of the paths. With experience you learn to do that quite effectively, though.
Sure: you should refactor that into a lot of small functions, containing only a single loop or a single 'if'.
FTFY. Change it to "must" if I'm your code reviewer.
You lost quite some credibility with using terms or sentences like That even includes memory leaks when exiting. and "... even if that means correct use of the garbage collector ..."
Unfortunately a exiting program can not leak memory
Sure it can. If there are any heap-allocated blocks remaining (not freed) at exit, the program has a memory leak. Again, there are good tools to help you find these leaks, like valgrind memcheck.
you don't use a garbage collector, it runs in the background. You can parametrize it perhaps ... but thats it. (and please don't tell me you are doing System.gc() in Java programs at "random" intervals)
And yet you can still have leaks in garbage-collected environments, and there are ways to test for them. It's a bit more complex than in non-GC'd environments, but it can -- and must! -- be tested if you want to have reliable software.