While your comment is true, that's not to say that corporations don't make fraudulent promises when angling for a tax or legal break. I can't tell which one is lying.
While your point is valid, so is the GP's. It's possible that some kind of license could be written that would address this problem, so that certain activities would be promised to never be engaged in by the software. It would need to be originally chosen by the original author, but even so.... I'm not sure how this would work, or how it could be done. I suppose that a "new version has a new license" would be a tip-off that could be used. Even so, it reminds me of the licenses that restrict fields of activity for which the software can be used...not really a free license.
Unfortunately, I'm not sure that's a valid expectation. It *usually* works that way, but if the electrodes are weak and then overcharged (not sure what that means) it's my understanding that there is an increased chance of a short inside the battery.
OTOH, I don't see why it should catch fire except while being charged.....
A reasonable point. It is worth remembering, however, that batteries will go bad over time even without being used. This isn't just ni-cads, it's all of them. If you leave them uncharged it tends to collapse the electrodes, and if they're full charged it tends to over expand them. I'm told this is why batteries are normally at 70% charge when you buy something, but that charge will leak off over the years.
So it seems plausible to me that even if there weren't manufacturing defects, and the device was unused, that the battery *might* have become defective over the years.
There's weak and there's fake. These journals have been proven to have fake peer review, but real journals often have weak peer review...weak in both the positive and negative sense. Some papers are rejected because the reviewer didn't believe the results, and some papers are accepted because the verifiable assertions were not carefully checked. BOTH modes of failure happen. As to frequency...that's another question. There's obvious a reporting bias, where one only hears about the failures (as such). It's like the refusal to print negative finding. We know it happens, but we don't know how frequently, and how often people are discouraged from even trying to repeat an experiment because they expect that negative findings will be repeated. Thus we know there is sample bias, but we don't know the size of the bias. It's possible that it isn't large enough to matter (but that's not the way I'd bet).
It depends on what you are doing. For my part, I find your objections mainly irrelevant to most of my code, but I have a problem with how difficult it is to lay out structures with specified bit length variables. (Java's no better for my purposes.) I *need* for some variables to be 64 bits long, and others to be 16 or 32 bits long regardless of what the particular value stored in the variable happens to be. Easy in many languages, but quite difficult in Python. And the GIL is a real problem. It means that I need to run my program as a bunch of separate interpreter invocations. (Essentially I *could* use multiprocessing, though not multithreading, but there's no real benefit to make up for the costs.) And I need to know the format of strings. Utf8 is fine, and so is utf32 (though I'd want to convert to utf8 for output), but an unspecified format doesn't work at all. I most recently ended up converting all my strings into byte strings coded in utf8, and not using the language facilities. Annoying.
Fortunately it's not just the number of initial spaces, the number of initial tabs works just as well. Just don't try to mix the two approaches. (I quite strongly prefer tabs.)
That said, I still prefer explicit block grouping in the C style ({}). But Java has rather proven that this can be done in a manner much worse than Pythons indentation level approach...and I want to indent my code anyway. (OTOH, I also strongly prefer braces over more verbose forms. My ideal loop format is: ...code ...loop start ...{..loop code ......loop code ......etc. ...}
replace '.'s by ' 's. For some reason slashcode doesn't like preformatted computer code.
I believe that oil is more from bacterial decomposition. Plants turned into coal instead. (OTOH, any decent coal was made longer ago than T.Rex was around. But maybe lignite.)
Well, the day *has* been lengthening, which means that there is less centrifugal force, which would make weight decrease, even with no actual change in gravity. And T.Rex got pretty heavy, so it might have lost half a pound that way. (That's probably an overestimate, though.)
From the summary I assumed that it was based on modeling the strength of T.Rex's bones, and that the fossil data on footsteps was just included to say that the result was consistent with the apparent data.
FWIW, I doubt that T.Rex often ran even as rapidly as they are indicating. The body seems built more for striding.
It's not clear that a T.Rex could run for hours...but at its walking pace you'd need to run.
Also, they're comparing the run of a T.Rex to the sprint of a human, but how far can you sprint? T.Rex had a quite long stride, so by the time it hits full speed it probably gone further than you could sprint.
That said, any of our ancestors who were around at the time would be about the size of shrews, and not worth T.Rex even bending over for. So the question would be more "But how fast could a hadrosaur run?".
EVERY previous administration has a least pretended to care about the privacy of the citizenry. I'll admit that it was often clearly a pretense, and none cared very much.
No quite nobody. EULAs are why I first switched from MS to Apple, and then later to Linux. And this was before Linux had a decent word processor, so it took motivation.
Sorry, but you're forgetting that the current system has had a bunch of startup pains that have been corrected. But this is what makes replacing it with systemd except on a few test systems such a bad idea.
Note: Pottering may be less pleasant and more opinionated than the current maintainers of the standard tools, but the early builders of those tools weren't mild and unopinionated themselves. And they weren't all experts to start with. The difference is that the tools they were working on were relatively small, and they didn't have a major corporation pushing their megalomania.
The past wasn't anything golden, but over time we worked through the problems. And a part of the way we did so was by modularizing so that small pieces were worked on at any particular time.
That's plausibly the same device, but I've got to admit that *I'm* still not sure.
OTOH, even if I were to accept the explanation, that wouldn't mean that there wasn't a way around it.
Estrogen mimic plasticizers are all over the environment. They're in your clothes, your bottled water, your food, the chairs you sit in, ETC.
They would be my first guess as to the reason for many abnormalities, and certainly for something involving sperm counts.
While your comment is true, that's not to say that corporations don't make fraudulent promises when angling for a tax or legal break. I can't tell which one is lying.
Nor does it deserve the title Everyone's favorite init tool
Personally, I read that as sarcasm. I still presume it was intended that way.
While your point is valid, so is the GP's. It's possible that some kind of license could be written that would address this problem, so that certain activities would be promised to never be engaged in by the software. It would need to be originally chosen by the original author, but even so.... I'm not sure how this would work, or how it could be done. I suppose that a "new version has a new license" would be a tip-off that could be used. Even so, it reminds me of the licenses that restrict fields of activity for which the software can be used...not really a free license.
Yuck!!!
That's one of the recent changes in Kate that I really despise. (Just not enough to even try to fork the source...but enough to avoid Kate.)
Unfortunately, I'm not sure that's a valid expectation. It *usually* works that way, but if the electrodes are weak and then overcharged (not sure what that means) it's my understanding that there is an increased chance of a short inside the battery.
OTOH, I don't see why it should catch fire except while being charged.....
A reasonable point. It is worth remembering, however, that batteries will go bad over time even without being used. This isn't just ni-cads, it's all of them. If you leave them uncharged it tends to collapse the electrodes, and if they're full charged it tends to over expand them. I'm told this is why batteries are normally at 70% charge when you buy something, but that charge will leak off over the years.
So it seems plausible to me that even if there weren't manufacturing defects, and the device was unused, that the battery *might* have become defective over the years.
change
because they expect that negative findings will be repeated.
to
because they expect that negative findings will not be reported.
There's weak and there's fake. These journals have been proven to have fake peer review, but real journals often have weak peer review...weak in both the positive and negative sense. Some papers are rejected because the reviewer didn't believe the results, and some papers are accepted because the verifiable assertions were not carefully checked. BOTH modes of failure happen. As to frequency...that's another question. There's obvious a reporting bias, where one only hears about the failures (as such). It's like the refusal to print negative finding. We know it happens, but we don't know how frequently, and how often people are discouraged from even trying to repeat an experiment because they expect that negative findings will be repeated. Thus we know there is sample bias, but we don't know the size of the bias. It's possible that it isn't large enough to matter (but that's not the way I'd bet).
It depends on what you are doing. For my part, I find your objections mainly irrelevant to most of my code, but I have a problem with how difficult it is to lay out structures with specified bit length variables. (Java's no better for my purposes.) I *need* for some variables to be 64 bits long, and others to be 16 or 32 bits long regardless of what the particular value stored in the variable happens to be. Easy in many languages, but quite difficult in Python. And the GIL is a real problem. It means that I need to run my program as a bunch of separate interpreter invocations. (Essentially I *could* use multiprocessing, though not multithreading, but there's no real benefit to make up for the costs.) And I need to know the format of strings. Utf8 is fine, and so is utf32 (though I'd want to convert to utf8 for output), but an unspecified format doesn't work at all. I most recently ended up converting all my strings into byte strings coded in utf8, and not using the language facilities. Annoying.
Fortunately it's not just the number of initial spaces, the number of initial tabs works just as well. Just don't try to mix the two approaches. (I quite strongly prefer tabs.)
That said, I still prefer explicit block grouping in the C style ({}). But Java has rather proven that this can be done in a manner much worse than Pythons indentation level approach...and I want to indent my code anyway. (OTOH, I also strongly prefer braces over more verbose forms. My ideal loop format is:
...code
...loop start
...{..loop code
......loop code
......etc.
...}
replace '.'s by ' 's. For some reason slashcode doesn't like preformatted computer code.
How much money do you think this took? This sounds like the spare time work of some grad students.
I believe that oil is more from bacterial decomposition. Plants turned into coal instead. (OTOH, any decent coal was made longer ago than T.Rex was around. But maybe lignite.)
Well, the day *has* been lengthening, which means that there is less centrifugal force, which would make weight decrease, even with no actual change in gravity. And T.Rex got pretty heavy, so it might have lost half a pound that way. (That's probably an overestimate, though.)
From the summary I assumed that it was based on modeling the strength of T.Rex's bones, and that the fossil data on footsteps was just included to say that the result was consistent with the apparent data.
FWIW, I doubt that T.Rex often ran even as rapidly as they are indicating. The body seems built more for striding.
It's not clear that a T.Rex could run for hours...but at its walking pace you'd need to run.
Also, they're comparing the run of a T.Rex to the sprint of a human, but how far can you sprint? T.Rex had a quite long stride, so by the time it hits full speed it probably gone further than you could sprint.
That said, any of our ancestors who were around at the time would be about the size of shrews, and not worth T.Rex even bending over for. So the question would be more "But how fast could a hadrosaur run?".
To me is looks as if this story has dragged in a bunch of astroturfers.
EVERY previous administration has a least pretended to care about the privacy of the citizenry. I'll admit that it was often clearly a pretense, and none cared very much.
No quite nobody. EULAs are why I first switched from MS to Apple, and then later to Linux. And this was before Linux had a decent word processor, so it took motivation.
And I think she got that one right. Circumstantial evidence seems to support her. (A stopped clock, and all that.)
It's a little bit more than just "someone else's computer", it's "someone else's computer, and I don't know which one".
Sorry, but you're forgetting that the current system has had a bunch of startup pains that have been corrected. But this is what makes replacing it with systemd except on a few test systems such a bad idea.
Note: Pottering may be less pleasant and more opinionated than the current maintainers of the standard tools, but the early builders of those tools weren't mild and unopinionated themselves. And they weren't all experts to start with. The difference is that the tools they were working on were relatively small, and they didn't have a major corporation pushing their megalomania.
The past wasn't anything golden, but over time we worked through the problems. And a part of the way we did so was by modularizing so that small pieces were worked on at any particular time.
I might well if OpenBSD supported ext4 in read/write mode. As it is I can't test it out without trashing my files.
When I've moved files between systems, what ported was the userid#, not the user name. Has that changed recently?