Just because the Demicrats rule here doesn't mean that the Republican's aren't the ones behind the curtains pulling the strings. Republicans are the real rulers of Detroit and have been for more than 100 years.
Um. Is this your opinion because you know how well Republicans and Labor Unions "get along" (e.g. like matches and gasoline), or because of some other reason, like "Eat your broccoli Johnny, or the Republicans will come out of your closet and eat you while you're asleep"?
If only they had some radiation with which to treat those cancers... particularly radiation in shell fish, given shell fish are a common source of iodine.
Isn't it more likely that avoiding eating fish would account for the difference (assuming there is one, after you control for "suspected cases", and you compare to a relatively unexposed genetically similar population of children elsewhere in Japan, I mean)?
I think either yours or my idea or even both would be a good move to add more Windows Phone users.
Realize that I don't necessarily believe that more Windows phones are automatically a social good; I just believe that if that were Microsoft's goal, the way to achieve it would be for Microsoft to encourages developers to target them as a platform. This would incidentally benefit Microsoft by having developers target their code to Microsoft's IDE, rather than X Code or Eclipse.
Again, this is only about Microsoft's best interests in regard to establishing market share, and not about what I believe is necessarily a social good.
I'm not sure if this is legal or not, but if they made an iOS and Android emulator so you could run both iOS and Android apps on the Windows phones, some people might get a Windows Phone then who'd otherwise be getting one or the other because they figure they get all types of compatibility.
This would be the third worst tactical blunder of all time. The most famous of which is "never get involved in a land war in Asia" - but only slightly less well-known is this: "Never go in against a Sicilian when death is on the line"!
The correct thing to do is build Windows emulators for iOS and Android, rather than the other way around.
This will cause developers to target their development for Windows, rather than targeting iOS or Android. This get Microsoft native apps, and at the same time, detracts from having those same apps native on iOS or Android.
FreeBSD made the mistake of building a Linux emulation layer for FreeBSD, instead of a FreeBSD emulation layer for Linux, which would have had developers working on FreeBSD native code, rather than Linux native code.
I can't speak for other people, but personally I do value documentation. Not that I want to spend all my time documenting someone else's work, but when I need to learn about something, documentation is invaluable. No, it isn't as fun as writing code, but that doesn't make it useless. If someone else wants to contribute to FOSS and isn't a coder, but can do tech writing, I for one would appreciate their contribution to documentation.
I value documentation as well.
The problem is that the people changing the code out from under the documentation, so that the documentation quickly becomes out of date, or, worse, incorrect and misleading, is those people who are doing that to the code *not appreciating* the documentation effort.
At worst, there needs to be an agreement that things will stay the same for a while, or for at least a major version number, before the documentation goes out of date. And as you've noted with git: when things grow organically and incrementally, it's going to be near impossible to keep the docs in lock-step with the code -- particularly if the only way to make them match up is reverse engineering the code until you know enough about it to document it accurately and completely.
At one point in time, I wrote a rather complete internals book on FreeBSD; but the OS changed out from under the book too quickly, and so it was inaccurate, except for a particular major revision. And even then, there were sufficient differences even in the point releases (to the odd minor version number) that, unless I'd included a CDROM set or DVD with the book itself, there was no way that it was going to be useful for its intended purpose as a college textbook.
So yeah, documentation would be nice, but it's only going to get there as a divided labor effort if we agree to write design documents up front, and then follow a cathedral model for both the docs and the code that come out of those designs.
I think one of the major problems is that when you make something understandable by documenting it... it makes it a whole lot easier for someone to step in and know how to "improve" things, until the docs are out of date again. At least, that has been my personal experience.
If women don't care about making code faster and more compact, maybe they should work on other aspects of FOSS. For instance, most of it could use a lot of help in the documentation department.
Documentation is rarely valued as a contribution. We specifically had to go out of our way to hire a technical writer for Mac OS X to get the man pages covered for the UNIX Conformance requirement. And those were just command line commands, Libc, and the kernel interfaces that had coverage requirements.
It's definitely not valued nearly as well as code. The most common comment with regard to it is advice to "RTFS" and some variant of "If it was hard to write, it should be hard to understand". This is seen in the tools, as well. For example, git is written in such a way that you pretty much have to understand all of it to use any of it. This steepness of the learning curve appears to be intention, and viewed as a merit badge for when someone gets their head around it and Groks it. In the same way that you can do anything in Perl in half a dozen or a dozen different ways, the same is true of git.
Also, your verbal vs. visual thinking bias is showing. Personally, I process software in the same part of my brain that does auditory processing of music (meaning I have a hard time coding if I'm listening to music, as verified by FMRI of the dorsolateral frontal cortex and inferior frontal gyrus, Broca's, and Wernicke's areas, among other areas). Language centers tend to be common for processing both sound and software in many coders.
Ironically, if you are good with languages, you tend to be good with code as well, assuming you have a number of computer languages under your belt to generalize from. But if the tools have a crappy learning curve, then it takes a bit of OCD to be willing to invest the time necessary to overcome it. Staying overnight in a computer lab so that you can get time on the machines is not something most people do these days.
You simply fucking compile it with the same compiler flags you used for the first version. Compiling android 5.1 for a 4.4.4 phone is absolutely trivial.
You obviously do not *get* how Android partner companies deal with porting android. Most of the bits for various phones do *not* get integrated back into the main line sources.
Any given android version on any given phone is generally a stable snapshot of whatever was top of tree when the work on the phone started, plus local additions for device support.
Internally, Samsung treats each new phone as a one-off porting job. They've got an entire group that does nothing but one-off ports of whatever is a top of tree to the new phone hardware they are coming out with.
I know you'd love for this not to be the case, but it pretty much is the way things are.
What kind of dumbass company is going to spend money porting a new version of an OS to an old platform, with no payday for doing so?
Mobile phone vendors make their money selling new phones. You want a new Android, get a new phone. Your contract will be up in 2 years, and at 18 months, you will be offered a new phone with early renewal, so just wait until the contract is up, re-up the contract, and get the new phone with the fix.
There are actually 4 options... buy outright, buy financing through them, lease with an option to buy, buy power (lease, no option to buy, lower cost).
And yeah, they told me about the no panel upgrade and that bothered me as well. I have some shade in the area, and it moves around, and in order to get off the grid entirely, a 13% increase in panel efficiency for a given area would fix it. But they will not upgrade your existing panels when more efficient panels become available.
So that sticks me with a 20 year contract with no way to get off the grid.
Yes they did. It says right on the box that the computer comes with it. You accepted it by buying it. Your argument is like saying you didn't consent to cancer when you bought and smoked cigarettes.
A better analogy would be "he consented with cancer when he was born with a defective p53 gene on his c17".
By the way: shrink wrap licenses are not valid in all jurisdictions.
Keep your xenophobia to yourself. "Cultural friction". Wow. You're really not very good at this "being a human" thing, are you?
I take your use of the term "xenophobia" as an existence proof for cultural friction.
I'm not personally xenophobic, but I *do* recognize the social problems that arise because it *does* exist, and I recognize that xenophobia can not be legislated away.
New reports from Europe about various countries and municipalities not wanting to host refugees show that it is alive and well in Europe, despite the lessons of WW II.
One of the most troubling parts of the refugee situation in Europe is that the refugees are, for the most part, from countries with a strong tradition of xenophobia, and in fact the current refugee crisis has been triggered by internal xenophobia against existing (cultural, not racial) minority groups, such as being the wrong *kind* of Islam (Shia vs. Sunni), or being a Christian.
Again, nothing to do with race, and nothing to do with me personally owning the xenophobia in question.
I invite you to study Culture Conflict Theory, which is one of the major types of Conflict Theory. You can read some about it here: https://en.wikipedia.org/wiki/...
that so many gun nuts are known for. I'm surprised it took this long.
How is this racist? You act as if everyone who has a different culture is magically a different subspecies of human, with their own genotype and phenotype to go along with it.
Being anti-multiculturalist is not being racist.
If the original post wasn't clear enough, let me spell it out for you: any multicultural society is going to experience more conflict, via the tools at hand (not necessarily guns), than any monocultural society. Europe is largely monocultural, and that's in the process of changing.
You're being ridiculous. I am an energy-efficiency wonk. You can build as many nuclear power plants as you want, as long as they can compete with other forms of clean energy on price.
They can, as long as you take knee-jerk anti-nuclear stonewalling out of the equation. The primary costs in any nuclear plant are legal opposition by people who are antinuclear, and moving regulatory goalposts causing redesigns during construction, which re-triggers all the legal opposition (again). If you replace a T-31-A valve with a T-31-B valve in a design, you are pretty much required to re-do the entire "environmental impact" study, even if the valve in question is in the water faucet in the employee break room.
If that is your experience then it says more about your experience than wider practice.
Given that the regression tests used for both ChromeOS and the Mac OS X kernel are available in the publicly published source trees for each, I assure you that my experience is not unique.
Regression testing is simply ensuring that functionality that is already in place is not compromised when new versions/extensions/etc are added. Tests from the original specification for the system would be part of ongoing regression testing as the system is expanded/updated.
I said as much, when I made the post to which you are replying.
One of the process problems that both projects have is that a single test failure is considered a "build breaker"; and there is no distinction between:
* Tests which fail because they previously passed, and have regressed * Tests which fail because they were written to verify product acceptance criteria, and that code is not yet written
By not having any way to allow a test failure to be acceptable during the development process, every test failure breaks the build, and shuts down progress for the rest of the team, while that breakage is dealt with.
This is, in general, one of the major dangers of utilizing a bazaar-model iterative process to approach a goal through successive approximation. The other danger is transiently flakey tests that are not disqualified as build breakers because they are considered important enough to break the build, but not important enough to track down (and fix) the reasons for them being flakey (usually differences in timing, e.g. cache creation on initial vs. subsequent boots, etc.).
P.S.: Apple and Google typically do not hire many formal Q/A types; tests are expected to be written by engineers working on the product as part of them working on the product, and are added to build qualification relatively ad-hoc. Ubuntu development testing works in relatively the same way; the closest Open Source projects get to formal verification are probably the compiler testing that happens with gcc and llvm.
The original iPhone jailbreaking site, "jailbreakme.com", used the tiff library exploit to install the installer, and then patched the tiff exploit behind itself to prevent it being used for any other (nefarious) purpose, so this type of thing is not a unique or even new idea.
It should be made clear that Symantec is a piece of code that infects a device/with/ user consent and in that regard is the same as any other piece of malware that is installed via a phishing attack.
Here's the thing, its not absurd if SOME of the TV pass the test. When they do pass, governments tighten the tests for the next generation of machines. So car emissions wouldn't be so strict if every car failed them, and TV tests wouldn't be so strict if every TV failed them.
We know from the emissions test that BMW passed the *road* test and VW only passed the *rolling*road* test and failed the real road test. So the emission levels set isn't absurd, and the test is too artificial to properly check these limits.
You're missing the point; it's like software tests. Bear with me.
Most software tests in the waterfall model -- including tests in xnu (that's the name of the Mac OS X kernel build component) and in ChromeOS regression tests -- tests for the bugs that have already been fixed. In other words, they are regression tests, making sure we don't repeat the same mistakes that we made previously.
There are a couple of problems with this kind of testing:
(1) You are unlikely to "un-fix" a bug that was bad enough to report, spend effort tracking down, and fix (2) There's probably a big comment in the code to keep you from doing that anyway (3) You always miss new bugs with this kind of testing, since new bugs aren't regressions (4) It makes the build validation step slower and slower over time (5) It has an incredibly low probability of improving the quality of the product delivered to the customer
So why in the heck do we test software this way?
Because it's something we can test; we had to write a unit test for it anyway, to verify that the problem existed in the old code, and was not present in the new. So we throw that unit test onto the pile of build validation tests. Because we can. Because it makes us look diligent. Because management wants us to. Because marketing doesn't want the black eye of a repeat of a previous problem, especially if it was an egregious one (new egregious problems are OK, though).
What does this have to do with emissions standards on cars? Why do we test for particular emissions levels? What research has linked pollution of a particular type to specific environmental problems?
We test to these standards...Because We Can.
The NOX standards for Tier 1 were set at 1.0 g/mi. This was because, at the time Tier 1 standards were enacted, that was about the accuracy of our equipment. Tier 2 standards were phased in at 0.07 g/mi. This was because the equipment was improving, and that became our limit on accuracy.
In other words, the standards are what the standards are, and we test for those for the for the same reason we regression test software, rather than testing whether or not it meets the written specification:
Because We Can.
In other words, we don't set standards because they are environmentally reasonable, or technologically achievable on the engine side of things, we set them because they are testable on the emissions testing side of things.
BTW: Correct way to do software testing is:
(1) Write a spec (2) Write tests to verify the software meets the spec (3) Write the software to pass the tests (4) Run the tests as build validation that the product meets spec following changes
You might run the individual bug verification tests before a major release, or if you suspect something, but it's a stupid way to run waterfall.
Test something because it's useful to test it. Don't just test Because You Can.
How dare these energy-efficiency wonks want some kind of better world for our kids. How *dare* they!
They *don't* want a better world for our kids.
They want us to use less electricity, because they want to cut generating capacity, because they won't let us us nuclear -- which even the president of Greenpeace has stated is the best option, given our energy needs -- and the only other options to meet demand during time when "green" energy is not being productive (and we don't have full capacity for it built, in any case, and building it will take electricity) are fossil fuels.
But they don't want us to use fossil fuels, either (I agree with them on that), so the only other option is to front-load energy consumption on these products in the manufacturing process, so that they take less energy while in actual use. Which is how most actually energy efficient televisions achieve their efficiency, even though, in net terms, they're less efficient. But hey, they get the little "EnergyStar" sticker because they pass the tests.
So our kids aren't actually getting a better world than they'd have gotten by simply increasing generating capacity in the first place, instead of shifting the energy costs (and environmental pollution) to coal burning plants in China.
But hey, at least it's not in our back yard, right? If we don't have to see the pollution where we live, then it's not really there. Just like when we were babies playing peek-a-boo, and new we could become invisible by pulling the blanket up in front of our face, or we know that, when we are on a date, if we eat desert off the other persons plate, they get the calories instead of us, and it's therefore less fattening.
You must license it, and it generally only comes in binary form for runtime linking. This allows you to ship a GPL'ed product, but Adobe then does not have to GPL the library for the player SDK.
Again, it's only for HLS content. Earlier versions of the Android player, as indicated in the first link above, would do bot HLS and FLV, since they used the Clank (Chrome on Android) Flash implementation, and FlashAccess built-in plugin from Chrome builds, which were later redacted when Flash support was removed.
Adobe is a teensy bit angry over people stopping "unimportant content in occluded tabs" in Chrome, and now Safari.
Shamelessly stolen joke... I thought it was funny enough to steal, and this discussion needs to lighten up anyway. Wish I could credit the original source.
Intercepted text conversation:
Mars: Come over NASA: But you're 33.9 million miles away Mars: I'm wet NASA: I'm coming over
The crime of jaywalking didn't exist until cars came along. Streets were once shared spaces for everyone.
And then someone figured out that things with large amounts of momentum required long stopping distances, and that you were an idiot if you stepped out in front of them, and expected the laws of physics to bend to your whim.
And then someone else came up with traffic signals and road markings, which made it safe for pedestrians and cars to share the street again...so long as everyone, including the pedestrians, obeyed the signals and road markings.
And then "jaywalking"... not obeying the signals and road markings in a way dangerous to those sharing the road with you... became a crime.
And everyone lived happily every after! Except the people who were jaywaking: they got splatted like birds flying into the path of a 747 (something that also can't stop on a dime, even if the birds happen to be members of an endangered species).
Well, there are a lot of gun free / highly-regulated countries with far less gun crime than the US.
The U.S. has a vast cultural diversity, which most of Europe completely lacks. This leads to cultural friction. This was less of a problem, when immigrants were more or less forced to assimilate into the dominant culture ("melting pot"), rather than maintaining their own cultural identity. This was also less of a problem before most of the blue collar work was off-shored, placing those people in massive economic distress. Multiculturalism and economic straits have been a large contributor to the problem.
Perhaps the recent influx of immigrants in large enough numbers to establish cultural enclaves without ready jobs waiting for them will be enough to swing Europe's balance somewhat, although I believe that would be a sadly harsh method of getting that point across.
Amazon Prime uses Adobe FlashAccess for it's DRM to prevent copying of rented and purchased content (forget that I could just hook up an LVDS emulator as my "LCD Display" and copy it all anyway).
ChromeCast and Apple TV don't support FlashAccess because they don't support Flash.
On the other hand, I have a friend who just bought a Samsung TV on clearance, and it's Amazon Prime video quit running because it started demanding that the Flash version be updated in the TV, which would be great, but it's an embedded system with no way to do that without updating the browser, and Samsung is somewhat notorious for not updating hardware once it's been sold.
Mostly because it would cost them their ability to write firmware for a new television set, were they to take their television team, and put them on updating an older product that they're not even manufacturing any more, and that won't get them into the consumer's wallets anyway, unless they started charing about half the cost of a new TV for the firmware updates.
Amazon needs to drop their proprietary system, or insist that Adobe (1) quit changing their DRM implementation, or (2) provide the updates as plugins that *can* be downloaded to any TV, based on the fact that they are running ARM processors. #2 is problematic, since a port of Chrome is the browser used on most of these (the source code costs Samsung nothing), and Chrome quit supporting non-sandboxed third party plugins not purchased through the Chrome App store and/or Google Play.
Slashdot Mirror
Just because the Demicrats rule here doesn't mean that the Republican's aren't the ones behind the curtains pulling the strings. Republicans are the real rulers of Detroit and have been for more than 100 years.
Um. Is this your opinion because you know how well Republicans and Labor Unions "get along" (e.g. like matches and gasoline), or because of some other reason, like "Eat your broccoli Johnny, or the Republicans will come out of your closet and eat you while you're asleep"?
Correct treatment? Radioactive iodine abalation.
If only they had some radiation with which to treat those cancers... particularly radiation in shell fish, given shell fish are a common source of iodine.
Isn't it more likely that avoiding eating fish would account for the difference (assuming there is one, after you control for "suspected cases", and you compare to a relatively unexposed genetically similar population of children elsewhere in Japan, I mean)?
I think either yours or my idea or even both would be a good move to add more Windows Phone users.
Realize that I don't necessarily believe that more Windows phones are automatically a social good; I just believe that if that were Microsoft's goal, the way to achieve it would be for Microsoft to encourages developers to target them as a platform. This would incidentally benefit Microsoft by having developers target their code to Microsoft's IDE, rather than X Code or Eclipse.
Again, this is only about Microsoft's best interests in regard to establishing market share, and not about what I believe is necessarily a social good.
I'm not sure if this is legal or not, but if they made an iOS and Android emulator so you could run both iOS and Android apps on the Windows phones, some people might get a Windows Phone then who'd otherwise be getting one or the other because they figure they get all types of compatibility.
This would be the third worst tactical blunder of all time. The most famous of which is "never get involved in a land war in Asia" - but only slightly less well-known is this: "Never go in against a Sicilian when death is on the line"!
The correct thing to do is build Windows emulators for iOS and Android, rather than the other way around.
This will cause developers to target their development for Windows, rather than targeting iOS or Android. This get Microsoft native apps, and at the same time, detracts from having those same apps native on iOS or Android.
FreeBSD made the mistake of building a Linux emulation layer for FreeBSD, instead of a FreeBSD emulation layer for Linux, which would have had developers working on FreeBSD native code, rather than Linux native code.
I can't speak for other people, but personally I do value documentation. Not that I want to spend all my time documenting someone else's work, but when I need to learn about something, documentation is invaluable. No, it isn't as fun as writing code, but that doesn't make it useless. If someone else wants to contribute to FOSS and isn't a coder, but can do tech writing, I for one would appreciate their contribution to documentation.
I value documentation as well.
The problem is that the people changing the code out from under the documentation, so that the documentation quickly becomes out of date, or, worse, incorrect and misleading, is those people who are doing that to the code *not appreciating* the documentation effort.
At worst, there needs to be an agreement that things will stay the same for a while, or for at least a major version number, before the documentation goes out of date. And as you've noted with git: when things grow organically and incrementally, it's going to be near impossible to keep the docs in lock-step with the code -- particularly if the only way to make them match up is reverse engineering the code until you know enough about it to document it accurately and completely.
At one point in time, I wrote a rather complete internals book on FreeBSD; but the OS changed out from under the book too quickly, and so it was inaccurate, except for a particular major revision. And even then, there were sufficient differences even in the point releases (to the odd minor version number) that, unless I'd included a CDROM set or DVD with the book itself, there was no way that it was going to be useful for its intended purpose as a college textbook.
So yeah, documentation would be nice, but it's only going to get there as a divided labor effort if we agree to write design documents up front, and then follow a cathedral model for both the docs and the code that come out of those designs.
I think one of the major problems is that when you make something understandable by documenting it ... it makes it a whole lot easier for someone to step in and know how to "improve" things, until the docs are out of date again. At least, that has been my personal experience.
If women don't care about making code faster and more compact, maybe they should work on other aspects of FOSS. For instance, most of it could use a lot of help in the documentation department.
Documentation is rarely valued as a contribution. We specifically had to go out of our way to hire a technical writer for Mac OS X to get the man pages covered for the UNIX Conformance requirement. And those were just command line commands, Libc, and the kernel interfaces that had coverage requirements.
It's definitely not valued nearly as well as code. The most common comment with regard to it is advice to "RTFS" and some variant of "If it was hard to write, it should be hard to understand". This is seen in the tools, as well. For example, git is written in such a way that you pretty much have to understand all of it to use any of it. This steepness of the learning curve appears to be intention, and viewed as a merit badge for when someone gets their head around it and Groks it. In the same way that you can do anything in Perl in half a dozen or a dozen different ways, the same is true of git.
Also, your verbal vs. visual thinking bias is showing. Personally, I process software in the same part of my brain that does auditory processing of music (meaning I have a hard time coding if I'm listening to music, as verified by FMRI of the dorsolateral frontal cortex and inferior frontal gyrus, Broca's, and Wernicke's areas, among other areas). Language centers tend to be common for processing both sound and software in many coders.
Ironically, if you are good with languages, you tend to be good with code as well, assuming you have a number of computer languages under your belt to generalize from. But if the tools have a crappy learning curve, then it takes a bit of OCD to be willing to invest the time necessary to overcome it. Staying overnight in a computer lab so that you can get time on the machines is not something most people do these days.
Port it? are you really that completely clueless?
You simply fucking compile it with the same compiler flags you used for the first version. Compiling android 5.1 for a 4.4.4 phone is absolutely trivial.
You obviously do not *get* how Android partner companies deal with porting android. Most of the bits for various phones do *not* get integrated back into the main line sources.
Any given android version on any given phone is generally a stable snapshot of whatever was top of tree when the work on the phone started, plus local additions for device support.
Internally, Samsung treats each new phone as a one-off porting job. They've got an entire group that does nothing but one-off ports of whatever is a top of tree to the new phone hardware they are coming out with.
I know you'd love for this not to be the case, but it pretty much is the way things are.
What kind of dumbass company is going to spend money porting a new version of an OS to an old platform, with no payday for doing so?
Mobile phone vendors make their money selling new phones. You want a new Android, get a new phone. Your contract will be up in 2 years, and at 18 months, you will be offered a new phone with early renewal, so just wait until the contract is up, re-up the contract, and get the new phone with the fix.
KTHX BAI.
There are actually 4 options... buy outright, buy financing through them, lease with an option to buy, buy power (lease, no option to buy, lower cost).
And yeah, they told me about the no panel upgrade and that bothered me as well. I have some shade in the area, and it moves around, and in order to get off the grid entirely, a 13% increase in panel efficiency for a given area would fix it. But they will not upgrade your existing panels when more efficient panels become available.
So that sticks me with a 20 year contract with no way to get off the grid.
Yes they did. It says right on the box that the computer comes with it. You accepted it by buying it.
Your argument is like saying you didn't consent to cancer when you bought and smoked cigarettes.
A better analogy would be "he consented with cancer when he was born with a defective p53 gene on his c17".
By the way: shrink wrap licenses are not valid in all jurisdictions.
Keep your xenophobia to yourself. "Cultural friction". Wow. You're really not very good at this "being a human" thing, are you?
I take your use of the term "xenophobia" as an existence proof for cultural friction.
I'm not personally xenophobic, but I *do* recognize the social problems that arise because it *does* exist, and I recognize that xenophobia can not be legislated away.
New reports from Europe about various countries and municipalities not wanting to host refugees show that it is alive and well in Europe, despite the lessons of WW II.
One of the most troubling parts of the refugee situation in Europe is that the refugees are, for the most part, from countries with a strong tradition of xenophobia, and in fact the current refugee crisis has been triggered by internal xenophobia against existing (cultural, not racial) minority groups, such as being the wrong *kind* of Islam (Shia vs. Sunni), or being a Christian.
Again, nothing to do with race, and nothing to do with me personally owning the xenophobia in question.
I invite you to study Culture Conflict Theory, which is one of the major types of Conflict Theory. You can read some about it here:
https://en.wikipedia.org/wiki/...
that so many gun nuts are known for. I'm surprised it took this long.
How is this racist? You act as if everyone who has a different culture is magically a different subspecies of human, with their own genotype and phenotype to go along with it.
Being anti-multiculturalist is not being racist.
If the original post wasn't clear enough, let me spell it out for you: any multicultural society is going to experience more conflict, via the tools at hand (not necessarily guns), than any monocultural society. Europe is largely monocultural, and that's in the process of changing.
You're being ridiculous. I am an energy-efficiency wonk. You can build as many nuclear power plants as you want, as long as they can compete with other forms of clean energy on price.
They can, as long as you take knee-jerk anti-nuclear stonewalling out of the equation. The primary costs in any nuclear plant are legal opposition by people who are antinuclear, and moving regulatory goalposts causing redesigns during construction, which re-triggers all the legal opposition (again). If you replace a T-31-A valve with a T-31-B valve in a design, you are pretty much required to re-do the entire "environmental impact" study, even if the valve in question is in the water faucet in the employee break room.
If that is your experience then it says more about your experience than wider practice.
Given that the regression tests used for both ChromeOS and the Mac OS X kernel are available in the publicly published source trees for each, I assure you that my experience is not unique.
Regression testing is simply ensuring that functionality that is already in place is not compromised when new versions/extensions/etc are added. Tests from the original specification for the system would be part of ongoing regression testing as the system is expanded/updated.
I said as much, when I made the post to which you are replying.
One of the process problems that both projects have is that a single test failure is considered a "build breaker"; and there is no distinction between:
* Tests which fail because they previously passed, and have regressed
* Tests which fail because they were written to verify product acceptance criteria, and that code is not yet written
By not having any way to allow a test failure to be acceptable during the development process, every test failure breaks the build, and shuts down progress for the rest of the team, while that breakage is dealt with.
This is, in general, one of the major dangers of utilizing a bazaar-model iterative process to approach a goal through successive approximation. The other danger is transiently flakey tests that are not disqualified as build breakers because they are considered important enough to break the build, but not important enough to track down (and fix) the reasons for them being flakey (usually differences in timing, e.g. cache creation on initial vs. subsequent boots, etc.).
P.S.: Apple and Google typically do not hire many formal Q/A types; tests are expected to be written by engineers working on the product as part of them working on the product, and are added to build qualification relatively ad-hoc. Ubuntu development testing works in relatively the same way; the closest Open Source projects get to formal verification are probably the compiler testing that happens with gcc and llvm.
The original iPhone jailbreaking site, "jailbreakme.com", used the tiff library exploit to install the installer, and then patched the tiff exploit behind itself to prevent it being used for any other (nefarious) purpose, so this type of thing is not a unique or even new idea.
It should be made clear that Symantec is a piece of code that infects a device /with/ user consent and in that regard is the same as any other piece of malware that is installed via a phishing attack.
Here's the thing, its not absurd if SOME of the TV pass the test. When they do pass, governments tighten the tests for the next generation of machines.
So car emissions wouldn't be so strict if every car failed them, and TV tests wouldn't be so strict if every TV failed them.
We know from the emissions test that BMW passed the *road* test and VW only passed the *rolling*road* test and failed the real road test. So the emission levels set isn't absurd, and the test is too artificial to properly check these limits.
You're missing the point; it's like software tests. Bear with me.
Most software tests in the waterfall model -- including tests in xnu (that's the name of the Mac OS X kernel build component) and in ChromeOS regression tests -- tests for the bugs that have already been fixed. In other words, they are regression tests, making sure we don't repeat the same mistakes that we made previously.
There are a couple of problems with this kind of testing:
(1) You are unlikely to "un-fix" a bug that was bad enough to report, spend effort tracking down, and fix
(2) There's probably a big comment in the code to keep you from doing that anyway
(3) You always miss new bugs with this kind of testing, since new bugs aren't regressions
(4) It makes the build validation step slower and slower over time
(5) It has an incredibly low probability of improving the quality of the product delivered to the customer
So why in the heck do we test software this way?
Because it's something we can test; we had to write a unit test for it anyway, to verify that the problem existed in the old code, and was not present in the new. So we throw that unit test onto the pile of build validation tests. Because we can. Because it makes us look diligent. Because management wants us to. Because marketing doesn't want the black eye of a repeat of a previous problem, especially if it was an egregious one (new egregious problems are OK, though).
What does this have to do with emissions standards on cars? Why do we test for particular emissions levels? What research has linked pollution of a particular type to specific environmental problems?
We test to these standards ...Because We Can.
The NOX standards for Tier 1 were set at 1.0 g/mi. This was because, at the time Tier 1 standards were enacted, that was about the accuracy of our equipment. Tier 2 standards were phased in at 0.07 g/mi. This was because the equipment was improving, and that became our limit on accuracy.
In other words, the standards are what the standards are, and we test for those for the for the same reason we regression test software, rather than testing whether or not it meets the written specification:
Because We Can.
In other words, we don't set standards because they are environmentally reasonable, or technologically achievable on the engine side of things, we set them because they are testable on the emissions testing side of things.
BTW: Correct way to do software testing is:
(1) Write a spec
(2) Write tests to verify the software meets the spec
(3) Write the software to pass the tests
(4) Run the tests as build validation that the product meets spec following changes
You might run the individual bug verification tests before a major release, or if you suspect something, but it's a stupid way to run waterfall.
Test something because it's useful to test it. Don't just test Because You Can.
How dare these energy-efficiency wonks want some kind of better world for our kids. How *dare* they!
They *don't* want a better world for our kids.
They want us to use less electricity, because they want to cut generating capacity, because they won't let us us nuclear -- which even the president of Greenpeace has stated is the best option, given our energy needs -- and the only other options to meet demand during time when "green" energy is not being productive (and we don't have full capacity for it built, in any case, and building it will take electricity) are fossil fuels.
But they don't want us to use fossil fuels, either (I agree with them on that), so the only other option is to front-load energy consumption on these products in the manufacturing process, so that they take less energy while in actual use. Which is how most actually energy efficient televisions achieve their efficiency, even though, in net terms, they're less efficient. But hey, they get the little "EnergyStar" sticker because they pass the tests.
So our kids aren't actually getting a better world than they'd have gotten by simply increasing generating capacity in the first place, instead of shifting the energy costs (and environmental pollution) to coal burning plants in China.
But hey, at least it's not in our back yard, right? If we don't have to see the pollution where we live, then it's not really there. Just like when we were babies playing peek-a-boo, and new we could become invisible by pulling the blanket up in front of our face, or we know that, when we are on a date, if we eat desert off the other persons plate, they get the calories instead of us, and it's therefore less fattening.
Government sets absurd limits then companies cheat ...film at 11.
So you're saying that my Roku is running Flash?
No, the Roku is using the Adobe Primetime Player SDK, which is capable of content playback as well. It will do HLS streaming playback, but not FLV.
You can read Adobe's take on it here:
https://www.overdigital.com/20...
The SDK can be read about here:
http://www.adobe.com/solutions...
You must license it, and it generally only comes in binary form for runtime linking. This allows you to ship a GPL'ed product, but Adobe then does not have to GPL the library for the player SDK.
Again, it's only for HLS content. Earlier versions of the Android player, as indicated in the first link above, would do bot HLS and FLV, since they used the Clank (Chrome on Android) Flash implementation, and FlashAccess built-in plugin from Chrome builds, which were later redacted when Flash support was removed.
Adobe is a teensy bit angry over people stopping "unimportant content in occluded tabs" in Chrome, and now Safari.
Shamelessly stolen joke... I thought it was funny enough to steal, and this discussion needs to lighten up anyway. Wish I could credit the original source.
Intercepted text conversation:
Mars: Come over
NASA: But you're 33.9 million miles away
Mars: I'm wet
NASA: I'm coming over
The crime of jaywalking didn't exist until cars came along. Streets were once shared spaces for everyone.
And then someone figured out that things with large amounts of momentum required long stopping distances, and that you were an idiot if you stepped out in front of them, and expected the laws of physics to bend to your whim.
And then someone else came up with traffic signals and road markings, which made it safe for pedestrians and cars to share the street again ...so long as everyone, including the pedestrians, obeyed the signals and road markings.
And then "jaywalking" ... not obeying the signals and road markings in a way dangerous to those sharing the road with you ... became a crime.
And everyone lived happily every after! Except the people who were jaywaking: they got splatted like birds flying into the path of a 747 (something that also can't stop on a dime, even if the birds happen to be members of an endangered species).
Well, there are a lot of gun free / highly-regulated countries with far less gun crime than the US.
The U.S. has a vast cultural diversity, which most of Europe completely lacks. This leads to cultural friction. This was less of a problem, when immigrants were more or less forced to assimilate into the dominant culture ("melting pot"), rather than maintaining their own cultural identity. This was also less of a problem before most of the blue collar work was off-shored, placing those people in massive economic distress. Multiculturalism and economic straits have been a large contributor to the problem.
Perhaps the recent influx of immigrants in large enough numbers to establish cultural enclaves without ready jobs waiting for them will be enough to swing Europe's balance somewhat, although I believe that would be a sadly harsh method of getting that point across.
The problem is actually Amazon's DRM system.
Amazon Prime uses Adobe FlashAccess for it's DRM to prevent copying of rented and purchased content (forget that I could just hook up an LVDS emulator as my "LCD Display" and copy it all anyway).
ChromeCast and Apple TV don't support FlashAccess because they don't support Flash.
On the other hand, I have a friend who just bought a Samsung TV on clearance, and it's Amazon Prime video quit running because it started demanding that the Flash version be updated in the TV, which would be great, but it's an embedded system with no way to do that without updating the browser, and Samsung is somewhat notorious for not updating hardware once it's been sold.
Mostly because it would cost them their ability to write firmware for a new television set, were they to take their television team, and put them on updating an older product that they're not even manufacturing any more, and that won't get them into the consumer's wallets anyway, unless they started charing about half the cost of a new TV for the firmware updates.
Amazon needs to drop their proprietary system, or insist that Adobe (1) quit changing their DRM implementation, or (2) provide the updates as plugins that *can* be downloaded to any TV, based on the fact that they are running ARM processors. #2 is problematic, since a port of Chrome is the browser used on most of these (the source code costs Samsung nothing), and Chrome quit supporting non-sandboxed third party plugins not purchased through the Chrome App store and/or Google Play.
So Amazon is pretty screwed here.
Neither are you if you think a probe can't collect more information than a human.
Oh, it can collect *terabytes* of data. No one would argue that. It's just that most of it won't be *interesting* or *relevant* data.