Quoting somebody 'Mathematics is the queen of sciences'

I would have thought mathematical physics was a tautology, but nevermind.

Doctorate in Chemistry or not, your Uncle is in the minority of scientists, and the people who are specialists (meteorologists, etc.) are generally lined up with the doom and gloom side.

Yes, Copernicus was in the minority too, but the argument here is not against established dogma, pretty much the opposite by now.

Uh - huh.
Let's create a control group that does not smoke, then another that does, by taking a fairly homogeneous groups of people and randomly dividing them into several groups. Each group smokes a prescribed amount - say no cigarattes a day, 5 day, 10 a day, and so on.

We try to not let them or the researchers know who is in what group - double blind, then assess the health impacts over a period of time.

That's the usual scientific method, but good luck ever getting that past any ethics committee, or finding participants, or not getting fired for even suggesting it.

Separation between cause and effect is always a problem with survey based experiments, but it would be hard to find a plausible mechanism where people with these diseases or conditions were more likely to smoke...

There is some evidence that toxoplasmosis leads to an increase in risk taking in humans - so while it is an unlikely cause, it may be possible.

Coverity will certainly tell you a lot of things that are broken, but probably wont help you decide how to fix them.
Brain power is probably the best approach to this one, although some automated detection of unused code and paths won't hurt.
Amy number of other static analysers will do the same job.

I concur.
I've been managing machines using sysv init for some 20 years or more, and never really had a problem. It's generally straighforward, works well, and well understood.
Upstart rolled in on Ubuntu, then systemd, and it's hard to find the config, never mind do anything with it. Why did we need to do this - *nix approach was always about small tools that interoperated, not kitchen sink applications that are opaque (well... if you don't think too hard about emacs).

Rabid towels - now that is scary.

Actually, I migrated from Cobol, and never looked back.

There are man scary things about becoming a 'senior engineer'.
One of the most disturbing is supervising staff who were not born when you were cutting code for a living.
The guys I worked for when I went to work (1984) mostly had no formal qualifications, as they were hard to find in the 70's.

It's difficult coming to grips with the fact that you cannot stay ahead of the tech change wave. Tend to spend too much time doing what I am paid for instead.
The most scary thing is that after 20 years in a company, you know more and more about less and less (embedded 68302 development in C/C++). To go anywhere else would be very difficult based on that technical skillset. Soft skills, that gets harder too, as you start to be seen as out of date by the new guys.

Tried btrfs on two machines at work (Ubuntu 14.04), one new partition, one migration of an existing ext3 filesystem.
Can't say the performance is noticeably different, and it has been reliable. My initial observation was 'ok, works, but not real difference'. I have found 3 things that have changed my mind.
  1) Snapshots, particularly read only snapshots
  2) Use of send / receive operations to backup snapshots remotely, including incrementally.
  3) Ability to defrag as needed.

This is still quite bleeding edge... Using it I don't get the feeling that it as rock solid as the ext2/3/4 filesystems, for instance. OTOH, it has not failed in my fairly lightweight testing so far. Converting a root filesystem to btrfs was more complicated than I hoped, and took me a while to make work. Having re-organised my partitions so the boot partition started on the correct boundary, and performed the correct 'rituals' it came up OK, and has been solid ever since.

Other features of btrfs are still works in progress - notably RAID support.

It might not be based on unix, but it is strongly supported by tools from unix, and does it's best to provide you access to most unix tools in some form.

I certainly first encountered it on unix platform of some kind, and it is (in my mind) strongly associated with various unix descendants, derivatives, and other hangers on. Including the unix toolset supported by linux.

After going through the process of moving from VSS to Subversion here some 10 years ago, I am in no hurry to change source control again.

We had to educate a whole bunch of people, many of whom had never used anything more sophisticated than a tarball for version control, on how to use subversion.

Much as I like DVCS, and in hindsight it would be useful to have some form of it here, it would have to:
1) Be able to import our large and complex codebase,
2) Cope with the fact that we have one repos with multiple projects, each with multiple code modules, each using (for some reason) non standard path names, not trunk/branches/tags, but Trunk/Branches/Releases.
3) Be easy to learn and tolerant of mistakes, so probably Mercurial rather than git
4) Integrate with our home grown automated build system that resolves dependencies, records svn version info in headers, and ties in with at least 3 different build environments.

The barrier to entry is now too high - we have tried twice now to jump it, even tried to rework the svn2hg scripts, but have not found a solution that wouldn't stope us working for over a month.

Sigh!

Includes everything, including the kitchen sink :-)
First editor I ever really liked, and my standard for longer than I care to think now.

It is perilously close to an operating system - in stark contrast to the usual unix philosophy of small tools to do single jobs well.
Aaahh!, I see the cunning plan. By using all of those small tools, emacs can do everything for you without ever needing to see the shell again!

Fiendishly cunning, those GNU people!

As opposed, for instance, to another "murican" asshole with their world view centred in North America.

The view from the outside, guys, is that the US does many things to other countries that it would never tolerate having done to itself.

Unfortunately, the more moderate citizens of the US (I've met quite a few), don't seem to get heard outside of the US.

Cyber attacks are an extension of espionage - been happening for thousands of years, nearly everyone does it, probably never going to stop, so let's not go down the path of "OMG, they stole our technology by cyber espionage, lets cut trade / shoot them / bomb them / water board them / whatever..."

Previous posters are correct, trade wars can lead to real wars where many real people die - and those people in the news, in other countries, are real people too.

Well...
As a software engineer they expect me to be a sysadmin.

Seriously!
Shell scripts have been known to be basically insecure for a long time. Why would you expose one to a web or network interface?

Of course, that just leaves ssh, but at least some authentication SHOULD be required there.

Looking at the limited information available on this page, I would be more concerned about the gender disparity than any perceived racial disparity.

Let's make the following assumptions:
1) Apple employs people in many countries, all of whom were counted in this report
2) We do not know the racial mix in the populations of these countries. If it was just the US, 55% white would seem to be less than the population demographic, for instance. From some dim memory, I recall about 10% of the US population being afro-american, not sure what proportion hispanic, asian, or other groups that identify as not white.
3) We could be pretty confident that the gender proportions are close to 50% across most places - this means that 30% of the workers female is not very good. Is 30% better than other similar industries? I don't know. We are a much smaller business, and it's probably better than our numbers.

BTW - when does it become not acceptable to classify 'west european' descent (or similar) as white, when grouping other races and cultures by colour is clearly unacceptable.