If Florida seceded from the American union, would the Russians give two kopecks?
Bad analogy. What's happening in Ukraine is more like the USA supporting Canadian and/or Mexican rebels with an eye to picking up a province or two up north or a state or two down south"....
not the specs per say
Per se.
Do try not to write things you've only heard spoken.
I never once thought about the "God of War" as a living thing as you describe it, but you are totally right.
And of course the rest of the gang are also still out there, from Venus to Dionysus, made all the more powerful by being hidden from view. Any fool could had seen that trying to legislate the "God of Wine" out of existence would be an epic fail, but we had somehow managed to convince ourselves that it didn't exist, thus Prohibition and War on Drugs. Or look at Catholic Church and what their attempts to banish "Goddess of Sex" led to.
I think there's a whole new branch of psychology we desperately need, and could conceivably develop by going through ancient myths, this time without assuming the people who came up with and believed them were blind idiots. Which was pretty weird to begin with, after all, we sum up observed reality by anthropomorphising various aspects of it all the time, from countries to capitalism to the abstract concepts of justice and freedom.
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.
That's really what I look for too and value in a degree -- it shows that they have at least some history being committed to a large effort, seeing things through, learning new things, having communication skills, knowing how to write technical reports, etc.
Everything you wrote above can be applied to someone who has been with an employer for a number of years and been committed to a large project. Changes in teams, technologies and positions can demonstrate the ability to see things through, a willingness to learn new things, having communication skills and knowing how to write technical reports.
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
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
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
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
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.
Yes, and they are throwing it at all kinds of ideas hoping something pays off big before it dawns on all the marketing folks that "Internet advertising" is practically worthless, and the market collapses.
Actually, the reason Google got so big was precisely because they were (and are) able prove to marketing folks that they were getting a lot of value from their Internet advertising. A big part of what makes Google so popular among advertisers is the tools that allow them to quantify with a fair degree of precision how many of the clicks they pay for translate into sales and of what amount. In the advertising space this was Google's big innovation: a way to overcome the problem implied by the marketing saw "I know that half of what I spend on advertising is wasted; the trouble is I don't know which half". With Google's ads, advertisers (at least those selling online) can measure exactly how much return they're getting on their advertising investment, and use that to manage their online ad strategy. So... if it didn't have good ROI, it would already be dead.
(Disclaimer: I work for Google, but the stuff I work on has no direct relation to ads. My comments here are actually derived mostly from comments by businesspeople I know who operate online stores and use Google's ad services -- and love them.)
By your argument we need to regulate the number of dairies and cows or there will be boom and bust cycles of milk availability in the grocery store. After all, there are substantial barriers to entry in getting into the dairy business. That's ridiculous, of course, because the fact is that optimizing such marginal differences in provisioning and pricing is what markets are best at. Markets have their disadvantages but this area, specifically, is where they really shine and have been proven to be vastly more efficient and responsive than central planning.
It's possible that there is something about taxi service that demands central planning, but you haven't identified it, so if we were to accept your argument then we'd have to conclude that every industry with non-trivial barriers to entry must be regulated at least as tightly as taxi service. Indeed, most industries have far higher barriers to entry.
The level of training German taxi drivers go through is far more rigorous than just paying for a medallion. In the US your argument makes a lot of sense (the taxis I've had in the US have usually been terrible), but in Germany it's just not the German way. Taxi drivers are highly regulated, and part of that is the extended driving test and accreditation process, which provides a great taxi service.
So what?
Why should riders not be allowed to choose lesser service at a lower price if that's what they prefer?
I disagree that police ought to carry always-on cameras. Police officers are humans too, like you and I and all of us have things we would prefer not to be recorded on video for posterity. Small but embarassing things like digging your nose, loosening your belt after a good meal, private calls with family members, complaining to friends about the boss, sharing scandalous gossip or dirty jokes... the list goes on. Everyone is entitled to their own privacy and carrying a badge should not strip you of these human foibles.
Police officers can get away with killing a civilian. Under some circumstances.
Civilians cannot get away with killing police officers. In general.
Given that disparity, it is entirely reasonable that police officers be held to a higher standard. And if they have to give up their privacy, well, they can always quit the force and become a civilian....
If you want to know the real reason all the major distro's love systemd it is the manpower savings they get on not having to maintain and tailor initscripts.
Seriously? Because frankly, they are just not that complicated. I'm actually pretty surprised that nobody has yet come up with an init script processor that isn't a shell, because most scripts boil down to a small handful of functions, especially given that most of the options are now in
Comcast vs Amazon, whoever wins, we lose!
Maybe the primary reason they made systemd is because they thought init scripts were too complicated?
Well, they were wrong. Init scripts are gloriously simple compared to systemd.
The rule on staying alive as a program manager is to give 'em a number or give 'em a date, but never give 'em both at once.
