Sure is as long as your idea of diversity is a bunch of clones that differs only in the color of their skin.
I have no idea how you picked that out from my comment. I did not ever say or imply anything of the sort.
What I care about are barriers to entry and discrimination.
Good.
What I do not care about is percentages.
How can you care about discrimination if you don't care about one of the symptoms of discrimination. Disparities often (although not always) point to an underlying problem with its roots in discrimination or other forms of hostility. Yes it is true that simply solving the percentages problem does not necessarily solve whatever underlying problem may be present. I don't think anyone would disagree with you about that.
If less than 50% of group X per capita has decided they don't want to be a lawyer, that's fine with me.
Again, it depends on why they made that decision. If they think it is because they won't be respected or will be harassed at work, then there are clearly more factors to their decision beyond personal preference. Also, one of the reasons we use statistics to look at these things is because it allows us to take an unbiased look at the behavior of a population. The whims of individuals become randomly distributed events in the population, but when a pattern emerges that makes purely random chance very unlikely you start to try to understand what the underlying causes are.
When my daughter says she doesn't like her math class, I might say it is a personal preference or an individual aptitude. When 75% of the students say they don't like the math class, then I start to question whether there is something wrong with the class (either the teacher or the curriculum). If 50% of the students say they don't like the class and they are all girls, that's a curious pattern and I start to look more deeply. Maybe the teacher does not teach in an accessible way to girls. Maybe the teacher discriminates against the girls. Maybe the boys harass the girls. There are multiple possible reasons, but it is clear that it is not a pattern that arises by random chance.
the once circulated idea that people of African descent are inherently less intelligent than people of other races
I don't think that. I've never met anyone that's thought that. I've never experienced that. No one in this thread wrote that.
You should work on your reading comprehension instead of attacking random snips of comments out of context. The first part of the same sentence was this,
There is little to no scientific basis for the argument that being female genetically predisposes you to liking certain things more than others
The argument people seem to be making is that women are not choosing tech fields because they don't like them. And they don't like them because women just don't like that sort of thing. There is simply no evidence to support that line of reasoning. It is pure speculation rooted in inherent biases and attitudes about the capabilities of women and their behaviors. In other words, it is sexism.
I suppose it was just wishful thinking that anyone reading the site would have the requisite math skills...
I agree with your math, that wasn't the point of my post. My point was that if you focus only on the act of hiring a woman and on anti-discriminatory hiring policies, you are missing the key objectives of these diversity initiatives. It is not strictly about hiring and promotion, it is mostly about inclusiveness. And for the reasons you state, you won't achieve a balanced gender participation ratio overnight, or even in a few years. It will require a higher labor force participation rate by women, which happens as younger generations slowly see that yes they can succeed, yes they will be respected, and no they will not harassed or marginalized by co-workers. And remember, a workplace that fosters inclusiveness is better for everybody, not just women.
but because people are bad at statistics and people ignore that humans have preferences and individuality
Preferences and individuality are malleable. Why do women "prefer" not to work in tech or study tech in school? Can something about the tech field, culture, or educational environment change to make it more appealing to women? The people promoting diversity initiatives answer "yes" to that last question.
Sure. And why is that? I'm not sure your economic argument is the reason. It could have as much or more to do with the way the discipline is taught in school. The experience of Harvey Mudd seems to point to exactly that. They have a close to 50:50 gender participation rate in engineering majors, and they have achieved it through changes to their curriculum and teaching environment.
so it's not simply a situation of American women being discriminated against in tech
I think there is a key nuance to your statement. A state of not active and explicit discrimination is an important achievement, but it is not where the road ends. A culture of inclusiveness is the next step. You don't simply want women and other groups in attendance in the workforce, you want them actively participating in the workforce, and you can't get there if they are discouraged, unwelcome, or marginalized on the job.
much more patriarchal and discriminatory societies have much better women engineering ratios in school,
While that might be true, it's an impossible argument to make unless you can somehow quantify "patriarchal" and "discriminatory".
Google is shouting from the rooftops that they are seeking gender diversity with 31% women, plus trying to hire even more women.
No, I think they have just recognized what lot of other companies have also recognized (whether they be tech or otherwise), which is that the gender disproportions have more to do with company and workplace culture, educational opportunities and encouragement, role models, social acceptance, and work-life balance than with any inherent biological predispositions. So they are trying to address some of those issues. Of course the same is true of the other fields you mentioned, and should they ever decide that they want/can benefit from a more diverse workforce, they will probably do many of the same things that Google and other tech companies are doing now.
Yes, assuming all humans make the same choices, have the same background, and interests, skills, likes, dislikes, plans for their future, and so on.
In other words, if there's no diversity.
Of course there is diversity. The question is, what do any of those preferences/choices have to do with skin color or gender? There is little to no scientific basis for the argument that being female genetically predisposes you to liking certain things more than others, just as the once circulated idea that people of African descent are inherently less intelligent than people of other races.
Is it worth it as a means of encouraging electric cars? I would say maybe, but personally I would have made the subsidy inversely proportional to the cost of the car to encourage affordable electric cars and to prevent it from becoming a tax break for the wealthy. I'm not sold on the idea that by making a luxury electric car we're somehow speeding electric car development.
As others have noted elsewhere, the electric car tax credit was crafted by GM for the Volt. Tesla had nothing to do with it and benefits the least from it. Tesla has been clear about their market development strategy from the very beginning. First, electric cars have to be cool and sexy, to induce people to buy them. Second, they have to start with a niche market to accumulate enough capital and manufacturing capacity to expand into a larger market. The Bolt never would have been produced except to compete with the Model 3, and it is a rather shoddy attempt considering the resources available to GM. Market demand for electric cars is being almost entirely driven by Tesla, so no, I don't think we would be where we are without them. That said, Tesla would probably still be doing what it is doing even without the tax credits.
Basically, there is no such thing as a "perfect" catalyst. All catalysts eventually undergo some sort of degradation process as a side reaction and fail. So the trick is usually not finding a catalyst that can promote a particular chemical reaction (the reaction mechanisms for most of these things have been known for decades), but a combination of catalyst+stabilizer+reaction conditions that provide decent yields at reasonable costs.
In this particular case, electrolysis of water takes place as two half reactions: a hydrogen evolution reaction (HER) and an oxygen evolution reaction (OER). While the reactions must take place simultaneously, they are nonetheless fundamentally different reactions that take place at the cathode and anode, respectively. The HER is relatively facile, but the OER is much more thermodynamically unfavorable. Different catalysts are used at the cathode and anode to promote these two half reactions, but the problem usually resides with the OER. To get good OER catalysis using cost-effective materials, you usually need to perform the reaction under alkaline conditions. But under alkaline conditions the HER takes a major hit, both uncatalyzed and using common catalysts, such as platinum. A nice review here, http://onlinelibrary.wiley.com...
So there you go, that's the basic problem that this group is trying to solve. Haven't looked at the article carefully, but looks promising.
The headline states: "Monsanto Leaks Suggest It Tried To Kill Cancer Research On Roundup Weed Killer"
The summary goes on to make various aspersions about authorship credit, which is not the same thing at all! Sheesh, while I know this is Slashdot, it is unusual for the reading comprehension to be THIS bad.
The article itself is a bunch of selective misquoting in an attempt to portray a narrative that they desperately want to believe in. I have to say I'm very disappointed in the NYT. Some of the more important points:
Documents show that Henry I. Miller, an academic and a vocal proponent of genetically modified crops, asked Monsanto to draft an article for him that largely mirrored one that appeared under his name on Forbes’s website in 2015.
and then a bit further down
An academic involved in writing research funded by Monsanto, John Acquavella, a former Monsanto employee, appeared to express discomfort with the process, writing in a 2015 email to a Monsanto executive, “I can’t be part of deceptive authorship on a presentation or publication.” He also said of the way the company was trying to present the authorship: “We call that ghost writing and it is unethical.”
while Mr. Acquavella said in an email on Tuesday that “there was no ghostwriting” and that his comments had been related to an early draft and a question over authorship that was resolved.
In the first case, an academic professor who was not paid solicited an article from Monsanto and put his own name on it. Lazy and unethical, yes, but more on the professor than on Monsanto, and nothing to do with academic research. In the second case, there was a squabble about authorship and attribution, which is entirely common in academic publishing. Apparently it was resolved, nothing was suppressed.
In another part of the article:
In a 2002 email, a Monsanto executive said, “What I’ve been hearing from you is that this continues to be the case with these studies — Glyphosate is O.K. but the formulated product (and thus the surfactant) does the damage.”
In a 2003 email, a different Monsanto executive tells others, “You cannot say that Roundup is not a carcinogen we have not done the necessary testing on the formulation to make that statement.”
So, they are internally debating what they can say (legally or scientifically) about the product. And the problem is...what exactly?
Some may not see biodiversity going down as positive.
Biodiversity goes down because of market forces, economies of scale, and distribution logistics. It was happening long before GMOs ever entered the picture. Now, I don't necessarily disagree with you, but the solution isn't banning GMOs. You have to do something to address the economic pressures if you want to see change.
Some may not see glyphosate resistant weeds as positive.
Herbicide-resistant weeds existed long before GMOs. Combating them is always an arms race between developing a better (read "more effective") herbicide and the spread of resistance. A lot of strategies are put in place to deal with this, not the least of which is application management. Analogous is the spread of antibiotic-resistant bacteria. We can develop new antibiotics, but it turns out one of the most effective ways of combating resistance is using your existing antibiotics better.
And some may not see family farms closing down or being transformed to agricultural factories as positive.
See #1. As another reply noted, there are plenty of family farms. They just are not your picturesque "cottage out on the prairie with a field of corn" farms. Farming is hard work and involves a lot of risk. It is not that easy to succeed.
What is the point of all this stuff if it barely reproduce six years old performance? are there plans to go faster?
The answer is yes, but the test track is too short currently to develop/demonstrate at those speeds. But thanks for your valuable contribution to the conversation.
I was listening to an interview with one of the team members on NPR. Apparently, the biggest problem they face trying to go faster is the test track is too short! In other words, they've built the pods to go faster, but until they upgrade the track they won't be able to test it.
Actually, you can. The Linux CPU scheduler is pluggable by design, and several schedulers are available to choose from in the stock kernel. Con Kolivas was an active kernel developer for many years with a vested interest in improving kernel latency. He was one of the prime motivators behind a redesign of the scheduler to make it more suited for desktop use. And even after he stopped working on the main kernel, he maintained a few of his own out-of-tree patches, including the infamous Brain Fuck Scheduler (BFS). You can read about it here, http://ck.kolivas.org/patches/...
The main argument between CK and the rest of the kernel team was that CK wanted extremely good latency in the linux kernel, and he wanted to set it up in a way to be configurable, so you could purpose a machine for a specific task (desktop or server) with different priorities. The main kernel team (Linus, Alan Cox, Greg Kroah-Hartman, Ingo Molnar, etc) wanted a more elegant solution. They wanted an intelligent CPU scheduler that could scale well depending on the load and hardware capabilities, with the idea being that a sysadmin should not have to think too much about it. A mainframe has very different hardware, but it also is used for a very different purpose, from a desktop machine, so the kernel should be able to realize that and figure out what it needed to prioritize. There were a few tuning variables exposed, but it was not supposed to require an extensive configuration. Also, they specifically had the developer workstation in mind when they were working on the scheduler. That is, they were considering situations where a user likely wanted both interactivity and throughput performance. The best of both worlds as best they could manage. They went back and forth a few times until CK finally got frustrated and left, because he didn't think it was possible.
So, there is BFS, and it probably still can be used to patch the stock kernel, but CK didn't design it to be pluggable. So if you patch your kernel with it, you will lose the other options, like the Completely Fair Scheduler (CFS). However, this thread on Stack Overflow might be a good resource if you are either interested in writing a new scheduler, or you want to modify BFS to be pluggable. https://stackoverflow.com/ques...
And, I was Googling a bit and found that CK is apparently working on another scheduler (MuQSS) which he is intending to be the successor to BFS, http://ck-hack.blogspot.pt/201...
In the end, though, while CFS is not as good as BFS at latency, it strikes a pretty good balance. And GKH has been working on soft realtime patches to the kernel for a number of years that are slowly getting incorporated into the main branch. So Linux is pretty good in general; much better than it was when CK first started his work. Here is an old, but nice, comparison of the two schedulers, http://cs.unm.edu/~eschulte/cl...
Maybe. It depends on the grade of the track and the tolerances involved. One of the design features of the hyperloop is to not be carrying around heavy cars pulled by large locomotives. The individual pods are much smaller and lighter. Also, the hyperloop one uses a track, but the original hyperloop proposal did not.
But the biggest cost is actually a push -- land and rights of way.
Correct. And this is why the original hyperloop proposal was made to fit in already existing rights of way, following interstate roads.
He talks about the cost of a ticket, and then later that it will soak up billions.
Yeah.... Billions is clearly hyperbole. Millions is in the range of what you would expect for an infrastructure project. How much do you think it costs to build a new bridge, or another lane on the highway? Who pays for it is a valid question, but I think there is room for both some taxpayer contribution and some private investment. Amtrak blows because it is both expensive AND it is slow and unreliable. If hyperloop succeeds in its goals, it could conceivably pay for itself eventually.
I have no idea which he thinks is too expensive, but my guess was both.
OP complains about needing to drive, but thinks it is too expensive to invest in new infrastructure. Can't have it both ways. Also, gas isn't free.
You are making a lot of assumptions, for example that the highest costs for building are the costs of materials and equipment. And the GP was referring to the cost of a ticket, which is partially affected by the cost of building, but there are many other factors.
How do you know this? I don't see any estimates of cost in the article. They aren't anywhere near a production model, so how is it that you know it is too expensive?
Point taken, but not quite sure why you felt it necessary to be so rude in your rebuttal. Yes, I described a gross oversimplification in order to keep my comment short, simple, and to the point: kernels need to do scheduling.
However, modern operating systems could at least give soft realtime guarantees
And while Linux does this to some degree, you already described the trade-off.
it's because kernels with realtime scheduling are slower
Getting a real-time guarantee will help responsiveness, but at the cost of performance, which is the essence of what I said in my above comment.
Fair comment. My point was to attempt to explain why scheduling by the kernel is necessary, why kernels need to use locks, and why there are trade-offs in deciding which processes/threads to execute when. But I left out a lot of details, hence the "oversimplified" qualifier at the beginning of my comment. Agree that Linux has generally better scheduler performance overall when compared to Windows. Linux has had the benefit of being able to go through quite a few radical scheduler changes over the years with accompanying changes to the various locks. While the Windows kernel team can probably do some, they are definitely not able to be as flexible with the internals as Linux.
If this were a discussion about the Linux userspace, you might have a point, although that can be debated as well.
With respect to the kernel, yes, third-party drivers (not necessarily closed source, but out of tree) are the relevant players impacted by ABI/API changes. If you have to recompile your driver after a kernel update, you don't have backwards-compatibility (ABI). If you have to make updates to your driver, however minor, before it will compile against a newer kernel, you don't have backwards-compatibility (API).
Just to be clear: that is not necessarily bad or wrong. Backwards-compatibility has both a benefit and a cost, as exemplified by the issue under discussion. Linus has repeatedly made it clear that he generally regards the cost of backwards-compatibility to be very high. If he needs to make a compatibility-breaking change to the kernel to improve security/increase efficiency/clean up interfaces/reduce cruft/add features/etc, he will. (You can claim, as Linus does, that this isn't really breaking backwards-compatibility because the Linux kernel has never advertised a stable interface for out-of-tree drivers, but it is a rather semantic argument as people generally expect the ability to use out-of-tree modules and may need them for varying reasons.)
Microsoft, on the other hand, has a distinct profit-motive to get as many people to upgrade to newer versions as possible. So they have a rather different POV. Namely, that backwards-compatibility must be maintained to facilitate smooth upgrade paths for potential customers.
Like I said, an oversimplification. There may be multiple CPUs, but there is only one kernel. There is one kernel because those multiple CPUs have to share memory, an i/o bus, and all of the rest of the hardware in the system. The kernel's responsibility is to manage which processes get access to which hardware resources at any given time. More (or faster CPUs) aids in the performance of CPU-bound processes, but does nothing to help, and often hurts other resource sharing requirements, including the i/o bus and interprocess communication.
Sure, it definitely helps when your OS can be extremely specialized towards a specific task. BeOS was designed for the explicit purpose of being a multimedia desktop platform, and it did what it did very well. But there were a lot of things it did not do.
Nope, I have dedicated hardware fifos for audio on the "sound card".
And if you are streaming audio from the Internet, does your sound card also have dedicated hardware to set up a TCP/IP stack...?
If I'm moving the mouse enough to toss the filesystem while committing to disk, then I have a poorly built file system in need of replacement.
Yes, that was exactly my point. Your filesystem is one of the responsibilities of the kernel, and it is impacted by kernel scheduling just like every other kernel subsystem. You do want your filesystem to be able to handle atomic commits to disk, so the kernel scheduler has to allow that.
Highest priority in a desktop should be UI with ability to pop up a limited system control panel to nuke bad behaving programs/processes/services.
I would argue that if you need a special UI dedicated to nuking bad behaving processes, you have a fairly poor operating system design in general.
Although not perfect, I think Linux gets the balance about right. The completely fair scheduler does round-robin load balancing of processes and threads on the available CPU resources, while also doing its best to avoid context switches. It has a heuristic to determine whether a process that has suddenly asked for CPU time should be allowed to preempt other processes, so that it can have acceptable responsiveness while under load. The end result is that if you are doing a build or crunching a data set in the background, you can still operate the UI and check your email, albeit sometimes with a little bit of lag. The alternative would be to make the UI crisp and smooth at all times, but then you would be taking a bit hit in performance on your background computations. The Linux kernel can and does occasionally deadlock, but it is a fairly rare circumstance in my experience and is not usually a failure of the scheduler.
It's easy to criticize from the outside, but the Linux kernel has historically had kernel locks that created similar problems, such as the "big kernel lock", removed ca 2011 (ie: not ancient history). https://kernelnewbies.org/BigK...
As noted in the article, this particular locking problem appeared in Windows 10 and wasn't present in Windows 7, so the balancing acts between the fine-grained locking mechanisms, thread performance, and backwards-compatibility are clearly challenging to maintain. Not excusing; just observing. Windows has never been known for it's ability to support massive numbers of parallel threads, so it is not surprising that previously overlooked problems can appear or become exacerbated in these situations. Many people, even here on Slashdot, laud Microsoft for the generally excellent backward- compatibility in Windows, and criticize the Linux kernel for being generally horrible at it. But here you go, a pretty nice example to illustrate that backwards-compatibility has a cost.
Again, slow and over-used everything else should not slow the UI and user input processes. This is basic.
The oversimplified, but short answer is that there is no such thing as a multiprocess CPU. All CPUs can execute on only a single thread per cycle. The kernel exists to allow multiple processes to be resident and to provide the illusion of multiple thread execution. In other words, the essential function of the kernel is scheduling, and in doing this the kernel has to make decisions about process priority that impact responsiveness and resource utilization in often diametrically opposite fashions. To gain responsiveness, a process that is further down the execution queue has to preempt processes further up the queue, delaying their execution. This has a negative impact on overall thread performance as your CPU will be mostly underutilized if there is a lot of preempting going on. If the kernel inhibits (or prohibits) preempting, it can more efficiently utilize your CPU, allowing many threads to get as much CPU time as possible, but this will have a very negative impact on responsiveness.
UI and user input processes are just processes to the kernel. You can, of course, just give UI and user input processes the highest possible priority at all times, but this is not automatically the best thing to do in every circumstance. For example, you probably don't want your audio stream in the background to stutter or stop playing just because you started moving the mouse. And if you are flushing a file to disk, you probably want that operation to complete atomically, rather than be interrupted by a pop-up dialog, because corrupted filesystems tend to make users pretty unhappy.
Slashdot Mirror
Of course there is diversity.
Sure is as long as your idea of diversity is a bunch of clones that differs only in the color of their skin.
I have no idea how you picked that out from my comment. I did not ever say or imply anything of the sort.
What I care about are barriers to entry and discrimination.
Good.
What I do not care about is percentages.
How can you care about discrimination if you don't care about one of the symptoms of discrimination. Disparities often (although not always) point to an underlying problem with its roots in discrimination or other forms of hostility. Yes it is true that simply solving the percentages problem does not necessarily solve whatever underlying problem may be present. I don't think anyone would disagree with you about that.
If less than 50% of group X per capita has decided they don't want to be a lawyer, that's fine with me.
Again, it depends on why they made that decision. If they think it is because they won't be respected or will be harassed at work, then there are clearly more factors to their decision beyond personal preference. Also, one of the reasons we use statistics to look at these things is because it allows us to take an unbiased look at the behavior of a population. The whims of individuals become randomly distributed events in the population, but when a pattern emerges that makes purely random chance very unlikely you start to try to understand what the underlying causes are.
When my daughter says she doesn't like her math class, I might say it is a personal preference or an individual aptitude. When 75% of the students say they don't like the math class, then I start to question whether there is something wrong with the class (either the teacher or the curriculum). If 50% of the students say they don't like the class and they are all girls, that's a curious pattern and I start to look more deeply. Maybe the teacher does not teach in an accessible way to girls. Maybe the teacher discriminates against the girls. Maybe the boys harass the girls. There are multiple possible reasons, but it is clear that it is not a pattern that arises by random chance.
the once circulated idea that people of African descent are inherently less intelligent than people of other races
I don't think that. I've never met anyone that's thought that. I've never experienced that. No one in this thread wrote that.
You should work on your reading comprehension instead of attacking random snips of comments out of context. The first part of the same sentence was this,
There is little to no scientific basis for the argument that being female genetically predisposes you to liking certain things more than others
The argument people seem to be making is that women are not choosing tech fields because they don't like them. And they don't like them because women just don't like that sort of thing. There is simply no evidence to support that line of reasoning. It is pure speculation rooted in inherent biases and attitudes about the capabilities of women and their behaviors. In other words, it is sexism.
Not sure those are mutually exclusive.
I suppose it was just wishful thinking that anyone reading the site would have the requisite math skills...
I agree with your math, that wasn't the point of my post. My point was that if you focus only on the act of hiring a woman and on anti-discriminatory hiring policies, you are missing the key objectives of these diversity initiatives. It is not strictly about hiring and promotion, it is mostly about inclusiveness. And for the reasons you state, you won't achieve a balanced gender participation ratio overnight, or even in a few years. It will require a higher labor force participation rate by women, which happens as younger generations slowly see that yes they can succeed, yes they will be respected, and no they will not harassed or marginalized by co-workers. And remember, a workplace that fosters inclusiveness is better for everybody, not just women.
but because people are bad at statistics and people ignore that humans have preferences and individuality
Preferences and individuality are malleable. Why do women "prefer" not to work in tech or study tech in school? Can something about the tech field, culture, or educational environment change to make it more appealing to women? The people promoting diversity initiatives answer "yes" to that last question.
Sure. And why is that? I'm not sure your economic argument is the reason. It could have as much or more to do with the way the discipline is taught in school. The experience of Harvey Mudd seems to point to exactly that. They have a close to 50:50 gender participation rate in engineering majors, and they have achieved it through changes to their curriculum and teaching environment.
so it's not simply a situation of American women being discriminated against in tech
I think there is a key nuance to your statement. A state of not active and explicit discrimination is an important achievement, but it is not where the road ends. A culture of inclusiveness is the next step. You don't simply want women and other groups in attendance in the workforce, you want them actively participating in the workforce, and you can't get there if they are discouraged, unwelcome, or marginalized on the job.
much more patriarchal and discriminatory societies have much better women engineering ratios in school,
While that might be true, it's an impossible argument to make unless you can somehow quantify "patriarchal" and "discriminatory".
Google is shouting from the rooftops that they are seeking gender diversity with 31% women, plus trying to hire even more women.
No, I think they have just recognized what lot of other companies have also recognized (whether they be tech or otherwise), which is that the gender disproportions have more to do with company and workplace culture, educational opportunities and encouragement, role models, social acceptance, and work-life balance than with any inherent biological predispositions. So they are trying to address some of those issues. Of course the same is true of the other fields you mentioned, and should they ever decide that they want/can benefit from a more diverse workforce, they will probably do many of the same things that Google and other tech companies are doing now.
Yes, assuming all humans make the same choices, have the same background, and interests, skills, likes, dislikes, plans for their future, and so on.
In other words, if there's no diversity.
Of course there is diversity. The question is, what do any of those preferences/choices have to do with skin color or gender? There is little to no scientific basis for the argument that being female genetically predisposes you to liking certain things more than others, just as the once circulated idea that people of African descent are inherently less intelligent than people of other races.
Is it worth it as a means of encouraging electric cars? I would say maybe, but personally I would have made the subsidy inversely proportional to the cost of the car to encourage affordable electric cars and to prevent it from becoming a tax break for the wealthy. I'm not sold on the idea that by making a luxury electric car we're somehow speeding electric car development.
As others have noted elsewhere, the electric car tax credit was crafted by GM for the Volt. Tesla had nothing to do with it and benefits the least from it. Tesla has been clear about their market development strategy from the very beginning. First, electric cars have to be cool and sexy, to induce people to buy them. Second, they have to start with a niche market to accumulate enough capital and manufacturing capacity to expand into a larger market. The Bolt never would have been produced except to compete with the Model 3, and it is a rather shoddy attempt considering the resources available to GM. Market demand for electric cars is being almost entirely driven by Tesla, so no, I don't think we would be where we are without them. That said, Tesla would probably still be doing what it is doing even without the tax credits.
Basically, there is no such thing as a "perfect" catalyst. All catalysts eventually undergo some sort of degradation process as a side reaction and fail. So the trick is usually not finding a catalyst that can promote a particular chemical reaction (the reaction mechanisms for most of these things have been known for decades), but a combination of catalyst+stabilizer+reaction conditions that provide decent yields at reasonable costs.
In this particular case, electrolysis of water takes place as two half reactions: a hydrogen evolution reaction (HER) and an oxygen evolution reaction (OER). While the reactions must take place simultaneously, they are nonetheless fundamentally different reactions that take place at the cathode and anode, respectively. The HER is relatively facile, but the OER is much more thermodynamically unfavorable. Different catalysts are used at the cathode and anode to promote these two half reactions, but the problem usually resides with the OER. To get good OER catalysis using cost-effective materials, you usually need to perform the reaction under alkaline conditions. But under alkaline conditions the HER takes a major hit, both uncatalyzed and using common catalysts, such as platinum. A nice review here,
http://onlinelibrary.wiley.com...
So there you go, that's the basic problem that this group is trying to solve. Haven't looked at the article carefully, but looks promising.
The headline states: "Monsanto Leaks Suggest It Tried To Kill Cancer Research On Roundup Weed Killer"
The summary goes on to make various aspersions about authorship credit, which is not the same thing at all! Sheesh, while I know this is Slashdot, it is unusual for the reading comprehension to be THIS bad.
The article itself is a bunch of selective misquoting in an attempt to portray a narrative that they desperately want to believe in. I have to say I'm very disappointed in the NYT. Some of the more important points:
Documents show that Henry I. Miller, an academic and a vocal proponent of genetically modified crops, asked Monsanto to draft an article for him that largely mirrored one that appeared under his name on Forbes’s website in 2015.
and then a bit further down
An academic involved in writing research funded by Monsanto, John Acquavella, a former Monsanto employee, appeared to express discomfort with the process, writing in a 2015 email to a Monsanto executive, “I can’t be part of deceptive authorship on a presentation or publication.” He also said of the way the company was trying to present the authorship: “We call that ghost writing and it is unethical.”
while Mr. Acquavella said in an email on Tuesday that “there was no ghostwriting” and that his comments had been related to an early draft and a question over authorship that was resolved.
In the first case, an academic professor who was not paid solicited an article from Monsanto and put his own name on it. Lazy and unethical, yes, but more on the professor than on Monsanto, and nothing to do with academic research. In the second case, there was a squabble about authorship and attribution, which is entirely common in academic publishing. Apparently it was resolved, nothing was suppressed.
In another part of the article:
In a 2002 email, a Monsanto executive said, “What I’ve been hearing from you is that this continues to be the case with these studies — Glyphosate is O.K. but the formulated product (and thus the surfactant) does the damage.”
In a 2003 email, a different Monsanto executive tells others, “You cannot say that Roundup is not a carcinogen we have not done the necessary testing on the formulation to make that statement.”
So, they are internally debating what they can say (legally or scientifically) about the product. And the problem is...what exactly?
Some may not see biodiversity going down as positive.
Biodiversity goes down because of market forces, economies of scale, and distribution logistics. It was happening long before GMOs ever entered the picture. Now, I don't necessarily disagree with you, but the solution isn't banning GMOs. You have to do something to address the economic pressures if you want to see change.
Some may not see glyphosate resistant weeds as positive.
Herbicide-resistant weeds existed long before GMOs. Combating them is always an arms race between developing a better (read "more effective") herbicide and the spread of resistance. A lot of strategies are put in place to deal with this, not the least of which is application management. Analogous is the spread of antibiotic-resistant bacteria. We can develop new antibiotics, but it turns out one of the most effective ways of combating resistance is using your existing antibiotics better.
And some may not see family farms closing down or being transformed to agricultural factories as positive.
See #1. As another reply noted, there are plenty of family farms. They just are not your picturesque "cottage out on the prairie with a field of corn" farms. Farming is hard work and involves a lot of risk. It is not that easy to succeed.
I was more responding to GP's question,
What is the point of all this stuff if it barely reproduce six years old performance? are there plans to go faster?
The answer is yes, but the test track is too short currently to develop/demonstrate at those speeds. But thanks for your valuable contribution to the conversation.
Absolutely. Long pressurized pipe^H^H^H^H tubes certainly sounds unpossible!
https://en.wikipedia.org/wiki/...
I was listening to an interview with one of the team members on NPR. Apparently, the biggest problem they face trying to go faster is the test track is too short! In other words, they've built the pods to go faster, but until they upgrade the track they won't be able to test it.
Actually, you can. The Linux CPU scheduler is pluggable by design, and several schedulers are available to choose from in the stock kernel. Con Kolivas was an active kernel developer for many years with a vested interest in improving kernel latency. He was one of the prime motivators behind a redesign of the scheduler to make it more suited for desktop use. And even after he stopped working on the main kernel, he maintained a few of his own out-of-tree patches, including the infamous Brain Fuck Scheduler (BFS). You can read about it here,
http://ck.kolivas.org/patches/...
The main argument between CK and the rest of the kernel team was that CK wanted extremely good latency in the linux kernel, and he wanted to set it up in a way to be configurable, so you could purpose a machine for a specific task (desktop or server) with different priorities. The main kernel team (Linus, Alan Cox, Greg Kroah-Hartman, Ingo Molnar, etc) wanted a more elegant solution. They wanted an intelligent CPU scheduler that could scale well depending on the load and hardware capabilities, with the idea being that a sysadmin should not have to think too much about it. A mainframe has very different hardware, but it also is used for a very different purpose, from a desktop machine, so the kernel should be able to realize that and figure out what it needed to prioritize. There were a few tuning variables exposed, but it was not supposed to require an extensive configuration. Also, they specifically had the developer workstation in mind when they were working on the scheduler. That is, they were considering situations where a user likely wanted both interactivity and throughput performance. The best of both worlds as best they could manage. They went back and forth a few times until CK finally got frustrated and left, because he didn't think it was possible.
So, there is BFS, and it probably still can be used to patch the stock kernel, but CK didn't design it to be pluggable. So if you patch your kernel with it, you will lose the other options, like the Completely Fair Scheduler (CFS). However, this thread on Stack Overflow might be a good resource if you are either interested in writing a new scheduler, or you want to modify BFS to be pluggable.
https://stackoverflow.com/ques...
And, I was Googling a bit and found that CK is apparently working on another scheduler (MuQSS) which he is intending to be the successor to BFS,
http://ck-hack.blogspot.pt/201...
In the end, though, while CFS is not as good as BFS at latency, it strikes a pretty good balance. And GKH has been working on soft realtime patches to the kernel for a number of years that are slowly getting incorporated into the main branch. So Linux is pretty good in general; much better than it was when CK first started his work. Here is an old, but nice, comparison of the two schedulers,
http://cs.unm.edu/~eschulte/cl...
Maybe. It depends on the grade of the track and the tolerances involved. One of the design features of the hyperloop is to not be carrying around heavy cars pulled by large locomotives. The individual pods are much smaller and lighter. Also, the hyperloop one uses a track, but the original hyperloop proposal did not.
But the biggest cost is actually a push -- land and rights of way.
Correct. And this is why the original hyperloop proposal was made to fit in already existing rights of way, following interstate roads.
He talks about the cost of a ticket, and then later that it will soak up billions.
Yeah.... Billions is clearly hyperbole. Millions is in the range of what you would expect for an infrastructure project. How much do you think it costs to build a new bridge, or another lane on the highway? Who pays for it is a valid question, but I think there is room for both some taxpayer contribution and some private investment. Amtrak blows because it is both expensive AND it is slow and unreliable. If hyperloop succeeds in its goals, it could conceivably pay for itself eventually.
I have no idea which he thinks is too expensive, but my guess was both.
OP complains about needing to drive, but thinks it is too expensive to invest in new infrastructure. Can't have it both ways. Also, gas isn't free.
You are making a lot of assumptions, for example that the highest costs for building are the costs of materials and equipment. And the GP was referring to the cost of a ticket, which is partially affected by the cost of building, but there are many other factors.
it's too expensive.
How do you know this? I don't see any estimates of cost in the article. They aren't anywhere near a production model, so how is it that you know it is too expensive?
Point taken, but not quite sure why you felt it necessary to be so rude in your rebuttal. Yes, I described a gross oversimplification in order to keep my comment short, simple, and to the point: kernels need to do scheduling.
However, modern operating systems could at least give soft realtime guarantees
And while Linux does this to some degree, you already described the trade-off.
it's because kernels with realtime scheduling are slower
Getting a real-time guarantee will help responsiveness, but at the cost of performance, which is the essence of what I said in my above comment.
Fair comment. My point was to attempt to explain why scheduling by the kernel is necessary, why kernels need to use locks, and why there are trade-offs in deciding which processes/threads to execute when. But I left out a lot of details, hence the "oversimplified" qualifier at the beginning of my comment. Agree that Linux has generally better scheduler performance overall when compared to Windows. Linux has had the benefit of being able to go through quite a few radical scheduler changes over the years with accompanying changes to the various locks. While the Windows kernel team can probably do some, they are definitely not able to be as flexible with the internals as Linux.
If this were a discussion about the Linux userspace, you might have a point, although that can be debated as well.
With respect to the kernel, yes, third-party drivers (not necessarily closed source, but out of tree) are the relevant players impacted by ABI/API changes. If you have to recompile your driver after a kernel update, you don't have backwards-compatibility (ABI). If you have to make updates to your driver, however minor, before it will compile against a newer kernel, you don't have backwards-compatibility (API).
Just to be clear: that is not necessarily bad or wrong. Backwards-compatibility has both a benefit and a cost, as exemplified by the issue under discussion. Linus has repeatedly made it clear that he generally regards the cost of backwards-compatibility to be very high. If he needs to make a compatibility-breaking change to the kernel to improve security/increase efficiency/clean up interfaces/reduce cruft/add features/etc, he will. (You can claim, as Linus does, that this isn't really breaking backwards-compatibility because the Linux kernel has never advertised a stable interface for out-of-tree drivers, but it is a rather semantic argument as people generally expect the ability to use out-of-tree modules and may need them for varying reasons.)
Microsoft, on the other hand, has a distinct profit-motive to get as many people to upgrade to newer versions as possible. So they have a rather different POV. Namely, that backwards-compatibility must be maintained to facilitate smooth upgrade paths for potential customers.
Like I said, an oversimplification. There may be multiple CPUs, but there is only one kernel. There is one kernel because those multiple CPUs have to share memory, an i/o bus, and all of the rest of the hardware in the system. The kernel's responsibility is to manage which processes get access to which hardware resources at any given time. More (or faster CPUs) aids in the performance of CPU-bound processes, but does nothing to help, and often hurts other resource sharing requirements, including the i/o bus and interprocess communication.
Sure, it definitely helps when your OS can be extremely specialized towards a specific task. BeOS was designed for the explicit purpose of being a multimedia desktop platform, and it did what it did very well. But there were a lot of things it did not do.
Nope, I have dedicated hardware fifos for audio on the "sound card".
And if you are streaming audio from the Internet, does your sound card also have dedicated hardware to set up a TCP/IP stack...?
If I'm moving the mouse enough to toss the filesystem while committing to disk, then I have a poorly built file system in need of replacement.
Yes, that was exactly my point. Your filesystem is one of the responsibilities of the kernel, and it is impacted by kernel scheduling just like every other kernel subsystem. You do want your filesystem to be able to handle atomic commits to disk, so the kernel scheduler has to allow that.
Highest priority in a desktop should be UI with ability to pop up a limited system control panel to nuke bad behaving programs/processes/services.
I would argue that if you need a special UI dedicated to nuking bad behaving processes, you have a fairly poor operating system design in general.
Although not perfect, I think Linux gets the balance about right. The completely fair scheduler does round-robin load balancing of processes and threads on the available CPU resources, while also doing its best to avoid context switches. It has a heuristic to determine whether a process that has suddenly asked for CPU time should be allowed to preempt other processes, so that it can have acceptable responsiveness while under load. The end result is that if you are doing a build or crunching a data set in the background, you can still operate the UI and check your email, albeit sometimes with a little bit of lag. The alternative would be to make the UI crisp and smooth at all times, but then you would be taking a bit hit in performance on your background computations. The Linux kernel can and does occasionally deadlock, but it is a fairly rare circumstance in my experience and is not usually a failure of the scheduler.
It's easy to criticize from the outside, but the Linux kernel has historically had kernel locks that created similar problems, such as the "big kernel lock", removed ca 2011 (ie: not ancient history).
https://kernelnewbies.org/BigK...
As noted in the article, this particular locking problem appeared in Windows 10 and wasn't present in Windows 7, so the balancing acts between the fine-grained locking mechanisms, thread performance, and backwards-compatibility are clearly challenging to maintain. Not excusing; just observing. Windows has never been known for it's ability to support massive numbers of parallel threads, so it is not surprising that previously overlooked problems can appear or become exacerbated in these situations. Many people, even here on Slashdot, laud Microsoft for the generally excellent backward- compatibility in Windows, and criticize the Linux kernel for being generally horrible at it. But here you go, a pretty nice example to illustrate that backwards-compatibility has a cost.
Again, slow and over-used everything else should not slow the UI and user input processes. This is basic.
The oversimplified, but short answer is that there is no such thing as a multiprocess CPU. All CPUs can execute on only a single thread per cycle. The kernel exists to allow multiple processes to be resident and to provide the illusion of multiple thread execution. In other words, the essential function of the kernel is scheduling, and in doing this the kernel has to make decisions about process priority that impact responsiveness and resource utilization in often diametrically opposite fashions. To gain responsiveness, a process that is further down the execution queue has to preempt processes further up the queue, delaying their execution. This has a negative impact on overall thread performance as your CPU will be mostly underutilized if there is a lot of preempting going on. If the kernel inhibits (or prohibits) preempting, it can more efficiently utilize your CPU, allowing many threads to get as much CPU time as possible, but this will have a very negative impact on responsiveness.
UI and user input processes are just processes to the kernel. You can, of course, just give UI and user input processes the highest possible priority at all times, but this is not automatically the best thing to do in every circumstance. For example, you probably don't want your audio stream in the background to stutter or stop playing just because you started moving the mouse. And if you are flushing a file to disk, you probably want that operation to complete atomically, rather than be interrupted by a pop-up dialog, because corrupted filesystems tend to make users pretty unhappy.