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...
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).
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.
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!
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.
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.
I recommend Haskell. Just because it will take you a week to get your head around how a Functional Language works, the syntax is subtle and terse, and the whole programming model is different should be no reason to put you off. At least it's not Malbolge... I mean - pure functions, no side effects, infinite lists, lazy evaluation, indentation sensitive, the list goes on... A convenient 'out' that lets you handle that awful non-deterministic I/O, what's not to like?
(note sarcasm) (note for the humour or intelligence deficient!)
Seriously, I like Haskell, I just can't imagine working in it, and I'm not suggesting you should learn it in preference to (say) Python.
Yup, I'm am older developer, been struggling to stay on top of the game for some 30 years now.
All those young university qualified software engineers, with their craqzy ideas, like design by contract, formal specification, agile methods, PSP, TSP, coding standards (!),... (sarcasm, just in case you missed it).
Seriously, we take the young guys from uni, impose some development and workplace discipline, and tap every bit of new knowledge, process, and methodology from them that we can. We're all happy, even if I am still way more comfortable in C than C++.
Seems to me that there ought to be something in the constitution about 'the right not to be shot dead at somebodies whim'.
Living in a country where guns are carefully controlled (Australia), we do not have anything like the issues with gun crime here, and really don't miss them. We do have quite different social conditions too, so the comparison is something like apples with oranges, but it is still fruit.
If you want a gun here, you either need to use it for your livelihood (eg, be a farmer with feral animals to control); or belong to a gun club, have 2 safes for storage, one with the weapon, one with the firing pin, etc. Rates of accidental and deliberate firearms deaths are very low.
I laugh at it because it reminds me of some (even many) of the people I went to university with. Yes, many of the characters are stereotypes, somewhat exaggerated for comedic license, but it's scary how many of them resemble people I knew back then (1980 - 1983) I studied with students of physics, computer science, mathematics, chemistry, theoretical physics, biology, biochemistry, and they are all there. We had no engineers then (can't have everything, sorry Howard), but I work with lots of them now. Still think the earlier seasons were better, plots are becoming more contrived lately, not as funny, but it is still one of the few shows that makes me watch tv.
Never watch 'reality' TV, soap operas. Rarely watch crime drama.
It's like a CRO, but considered more general purpose, more entertaining, but less useful to the tech head. Which is funny, as the average CRT just hums gently, while a CROw is pretty noises (Vaaark!)
It's not so hard to track down local variables. If you have a failure, you will have a stack pointer, and your memory map will give you an offset into the stack allocation for the function in question.
For those of us 'doing it old school' (mc68302 processor, no hardware debug support at all, no RTOS), the standard tools are a logic analyser dump and the compiler memory map output. Same tools are applicable to many other environments.
I think the standard you are referring to is MISRA. I can't see any good reason why recursion would be used in such a control system, and in any embedded application it is asking for trouble - principally (as you say) stack overflows.
I am less convinced of the dangers of using local variables - the trade off is to use globals, or at least global to file (C static global), which is an open invitation to side effects all through the code.
Use of malloc or free - might not cause stack overflows, but
1) can easily cause heap overflows, which can be as bad.
2) can fail to return the memory, which is difficult to handle robustly in an embedded application.
We don't use the full MISRA set (for radar systems), but we absolutely do not allow recursion, or dynamic memory use. Nobody wants their control system to run out of memory after a few hours/days use, and fail (eg Patriot failure in Iraq).
We have lots of them grow around here (Canberra, Australia). For some reason they like the pine and casuarina plantations around Canberra, possibly because not much else will grow in the bed of needles under those things.
We had two people (cooks at a chinese restaurant) die last year who picked them, thinking they were straw mushrooms. Just glad they did not serve them up at the restaurant!
I remember mushrooming as a kid, under my father's guidance. We only picked field mushrooms, which are dark underneath. Deathcaps are much lighter underneath. I think he learnt to do it because he grew up in the bush, and food and money were scarce for a while.
I've always considered the damn things a death sentence, so wont pick wild mushrooms any more, as it has been too long since I last did it (40 years).
Slashdot Mirror
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.
I recommend Haskell.
Just because it will take you a week to get your head around how a Functional Language works, the syntax is subtle and terse, and the whole programming model is different should be no reason to put you off. At least it's not Malbolge...
I mean - pure functions, no side effects, infinite lists, lazy evaluation, indentation sensitive, the list goes on...
A convenient 'out' that lets you handle that awful non-deterministic I/O, what's not to like?
(note sarcasm)
(note for the humour or intelligence deficient!)
Seriously, I like Haskell, I just can't imagine working in it, and I'm not suggesting you should learn it in preference to (say) Python.
It's also much easier for idiots to post inflammatory remarks anonymously.
For me, Ctrl-S always meant Xon - pause the scrolling output so you can read it.
Still works on most systems (at least most systems worth using!)
Otherwise, it's Ctrl-X Ctrl-S to save, none of those namby pamby single key strokes.
Yup, I'm am older developer, been struggling to stay on top of the game for some 30 years now.
All those young university qualified software engineers, with their craqzy ideas, like design by contract, formal specification, agile methods, PSP, TSP, coding standards (!), ... (sarcasm, just in case you missed it).
Seriously, we take the young guys from uni, impose some development and workplace discipline, and tap every bit of new knowledge, process, and methodology from them that we can. We're all happy, even if I am still way more comfortable in C than C++.
Seems to me that there ought to be something in the constitution about 'the right not to be shot dead at somebodies whim'.
Living in a country where guns are carefully controlled (Australia), we do not have anything like the issues with gun crime here, and really don't miss them.
We do have quite different social conditions too, so the comparison is something like apples with oranges, but it is still fruit.
If you want a gun here, you either need to use it for your livelihood (eg, be a farmer with feral animals to control); or belong to a gun club, have 2 safes for storage, one with the weapon, one with the firing pin, etc. Rates of accidental and deliberate firearms deaths are very low.
I laugh at it because it reminds me of some (even many) of the people I went to university with.
Yes, many of the characters are stereotypes, somewhat exaggerated for comedic license, but it's scary how many of them resemble people I knew back then (1980 - 1983)
I studied with students of physics, computer science, mathematics, chemistry, theoretical physics, biology, biochemistry, and they are all there.
We had no engineers then (can't have everything, sorry Howard), but I work with lots of them now.
Still think the earlier seasons were better, plots are becoming more contrived lately, not as funny, but it is still one of the few shows that makes me watch tv.
Never watch 'reality' TV, soap operas. Rarely watch crime drama.
It's like a CRO, but considered more general purpose, more entertaining, but less useful to the tech head.
Which is funny, as the average CRT just hums gently, while a CROw is pretty noises (Vaaark!)
It's not so hard to track down local variables.
If you have a failure, you will have a stack pointer, and your memory map will give you an offset into the stack allocation for the function in question.
For those of us 'doing it old school' (mc68302 processor, no hardware debug support at all, no RTOS), the standard tools are a logic analyser dump and the compiler memory map output. Same tools are applicable to many other environments.
I have had to do it more times than I like...
I think the standard you are referring to is MISRA.
I can't see any good reason why recursion would be used in such a control system, and in any embedded application it is asking for trouble - principally (as you say) stack overflows.
I am less convinced of the dangers of using local variables - the trade off is to use globals, or at least global to file (C static global), which is an open invitation to side effects all through the code.
Use of malloc or free - might not cause stack overflows, but
1) can easily cause heap overflows, which can be as bad.
2) can fail to return the memory, which is difficult to handle robustly in an embedded application.
We don't use the full MISRA set (for radar systems), but we absolutely do not allow recursion, or dynamic memory use. Nobody wants their control system to run out of memory after a few hours/days use, and fail (eg Patriot failure in Iraq).
We have lots of them grow around here (Canberra, Australia). For some reason they like the pine and casuarina plantations around Canberra, possibly because not much else will grow in the bed of needles under those things.
We had two people (cooks at a chinese restaurant) die last year who picked them, thinking they were straw mushrooms. Just glad they did not serve them up at the restaurant!
I remember mushrooming as a kid, under my father's guidance. We only picked field mushrooms, which are dark underneath. Deathcaps are much lighter underneath. I think he learnt to do it because he grew up in the bush, and food and money were scarce for a while.
I've always considered the damn things a death sentence, so wont pick wild mushrooms any more, as it has been too long since I last did it (40 years).