You need about 0.2 ATM oxygen partial pressure at more or less any altitude. So even at the surface this thing would need other gasses to keep you healthy. If it's got some sort of gas segregation technology it's possible to build a re-breather system that mostly re-uses the non-oxygen, non-CO2 gasses, but that's not a trivial task even if you have a readily available supply of oxygen.
Plex uses an internal ffmpeg to decode (and transcode, if needed) media files -- if it doesn't play there it will be hard to play in general. And you don't need to muck with an OS-level codecs, as Plex won't see or use them anyway.
But that's not relevant in this discussion; Plex will add files to the library even if it can't read them, so long as it can figure out from the file path what they are. If you need Plex to parse the tags in the file it will have to be able to decode it, but if it can match based on the name it doesn't care if the file can even be opened.
The problem is almost certainly a naming issue, or possibly a selection of the wrong scanner type. If you select a TV or Movie scanner Plex will only add files it can specifically match to databases like thetvdb.com, and you must use one of the naming conventions to help it do so. If you just want it to put up all of your media as-is without matching against a DB you need to select the "Home Videos" scanner type, which simply walks the filesystem and builds a matching hierarchy in the Plex library. And of course Music has its own scanner, which can similarly match against Last.fm or simply read local tags, depending on wishes.
It's not quite brain-dead simple if you have a mess of unorganized media, but it's not hours of work either, and the DB-matching modes provide rich metadata with all the hassle of ensuring that your paths include the series title and episode number somewhere along the line.
That's a one-time problem though -- it's a barrier, but it's a small one given how frequently mail is used. And modern mail clients are happy to guess virtually all of the settings, at least if your mail server has a standard configuration and you can remember your own email address.
You can select which ciphers you accept. In Firefox the preference is something like "security.ssl3.rsa_rc4_128_md5" -- I'm sure if you search for RC4 in the about:config page you can find the relevant settings. You can explicitly allow or disallow whatever combination of ciphers you like.
And it's not a "false sense of security" when the indicator is binary. It's not as descriptive as telling you what cipher is in use, but it's still encrypted and would take a lot of effort to decrypt (weaknesses have been demonstrated but there's no known attack that's even vaguely plausible in the general case), so given only binary choices "secure" is probably the right one, at least for the time being.
Only if you measure by absolute deaths. By proportion of the global population death count has been going steadily down for a long time, even counting WWII.
I don't think it's quite as simple as that, either. The imbalance of power is part of the point -- after WWI large industrial power engaged in fewer direct conflicts. Arguably at least part of the reason superpowers don't engage, and the reason fewer people die, is because weaponry is more advanced.
You could make exactly the opposite argument with exactly the same evidence (i.e. none): that the decision should be made by someone not at immediate risk of death because they'll be more likely to make the safer-for-others choices and clearly identifying targets rather than making the safer-for-them choices and shooting anything that moves.
Only if you're okay with your remote access solution registering with a third-party that writes all of the software involved and with whom you don't have a contract.
We should all stop being coy about what we used to make, so that employers lose their knowledge advantage in salary negotiations. Your salary is currently being depressed because you *don't* know what other people are making.
The problem with not publishing salary data is this: employers have asymmetric knowledge of salaries which puts them at a huge negotiating advantage, driving down the average salary. Which is far and away the #1 reason that companies discourage discussion of compensation. This basic economic fact is true in any market with asymmetric knowledge and there's absolutely not reason that you as an employee should want such a thing in the job market -- you'd be much better off in your negotiations (and they'd be simpler and faster for everyone involved) if both you and your employer had access to the same information about compensation.
I don't understand what's scarier about this: lvextend -L+6G/dev/foo/bar than this: vmkfstools -X 6G/vmfs/volumes/foo/bar.vmdk
But that wasn't really the the question I was asking -- what's the different between file-system snapshots and LVM-snapshots (other than filesystem-snapshots obviously don't allow changes to the filesystem itself, which most people don't care about most of the time). Is there something that makes tasks like backups or upgrades easier or faster? Is there some other task I'd snapshot for that just isn't possible with LVM?
There are lots of reasons to like newer filesystems, but the +4 poster above specifically said the LVM snapshots were not as useful as filesystem snapshots, and I'm just wondering what I'm missing.
You missed the part where deflation increases the real value of debt, which most individuals, corporations, and governments in modern economies hold to some degree or another. You can argue that they shouldn't, but so long as the do deflation is a big problem.
Because there are already better options for time-shifiting energy usage that most companies haven't done. For example, building ice at night with the A/C and melting the next day. All that requires is a tank of water and a bit of antifreeze in your chiller loop, which are much cheaper and have a much longer lifetime than batteries.
If you're worried about independent functionality and reliability you should regulate those aspects *directly* rather than requiring a particular solution. There isn't anything inherent about either of the technologies that guarantee the features you want, nor that prevents those features from being provided.
It's quite unusual for anyone in rural or semi-rural areas; I visited one museum in my entire primary and secondary education and that required extra attendance on Saturday and a $50 fee.
Even in urban areas we do a lot to lock children away from the world rather than engage them in it. The amount of staff you need to keep them locked up is a lot smaller than the amount of staff you need if they were allowed to interact with the world, so guess which one we pick?
So you're aware that there's a bias, and you don't have any explanation for that bias, but you're somehow sure it's not the result of gender discrimination? How does that work?
Women might well be avoiding coding because of the social environment. But why is that a necessary component of coding jobs -- if it's not that's an example of gender discrimination, not evidence against it.
Try framing this issue differently: All people, regardless of gender, are different and have different interests. Some of them will be more interested in coding than others. But given an arbitrary segregation factor -- eye color, for example -- wouldn't you expect the distribution of the general public to match the distribution among coders? And wouldn't you want to understand why a bias existed if you found one?
Maybe that bias is directly related to suitability for the job; the ability to exchange data with a computer is strictly necessary for coding so people who have trouble with human-computer interfaces are less likely to be coders and we're probably okay with that. But if you don't understand exactly what causes the bias how can you assume it's not discrimination?
The fact that outcomes aren't the same means that *something* is already tilting the playing field. Maybe that's a thing we're okay with, and if that's the case we can let he imbalanced outcome continue. But maybe it's not. If the thing titling the playing field is something we understand and directly control it's easy to fix, but that's not always the case, and I don't think it's not acceptable to say "well, the results are biases but I don't know why so I guess we'll just have to accept the bias" -- I actually want to understand the cause and resolve it as necessary, even if it's hard.
Complain all you want about the particular way that people try to solve problems, but the idea that we should just ignore biased outcomes under the assumption that nothing is wrong is absurd.
/ I also object to the idea that just because something is "natural" or "old" it's acceptable
Charging for parking doesn't do a lot to regulate demand, it's done to regulate turnover. Essentially all publicly-run pay parking is also time-limited, and frequently the rate for short-term usage is lower than commercial parking in the same area. Demand for parking is more or less inelastic because people still need to go places whether or parking is expensive; at best expensive parking encourages the use of other modes of transit.
Turnover isn't actually an issue on public conveyances; loitering *could* be, depending on the circumstances, but most transit systems include a layover point where it's easy to determine if someone is merely camping out.
It was working fine here in Seattle (and Des Moines, where I know they also provide some free downtown bus service). Since the whole route wasn't free it created some hassle with payment collection, but that's only an issue with the mix-and-match plan not the free part. The program has ended recently as funding for it was withdrawn but statistics suggest it did increase ridership in the free zone.
"Trust" and "verify" are contradictory. It's fine that you want to verify, but don't pretend that you are trusting while you actively violate the concept of trust.
Slashdot Mirror
You need about 0.2 ATM oxygen partial pressure at more or less any altitude. So even at the surface this thing would need other gasses to keep you healthy. If it's got some sort of gas segregation technology it's possible to build a re-breather system that mostly re-uses the non-oxygen, non-CO2 gasses, but that's not a trivial task even if you have a readily available supply of oxygen.
Plex uses an internal ffmpeg to decode (and transcode, if needed) media files -- if it doesn't play there it will be hard to play in general. And you don't need to muck with an OS-level codecs, as Plex won't see or use them anyway.
But that's not relevant in this discussion; Plex will add files to the library even if it can't read them, so long as it can figure out from the file path what they are. If you need Plex to parse the tags in the file it will have to be able to decode it, but if it can match based on the name it doesn't care if the file can even be opened.
The problem is almost certainly a naming issue, or possibly a selection of the wrong scanner type. If you select a TV or Movie scanner Plex will only add files it can specifically match to databases like thetvdb.com, and you must use one of the naming conventions to help it do so. If you just want it to put up all of your media as-is without matching against a DB you need to select the "Home Videos" scanner type, which simply walks the filesystem and builds a matching hierarchy in the Plex library. And of course Music has its own scanner, which can similarly match against Last.fm or simply read local tags, depending on wishes.
It's not quite brain-dead simple if you have a mess of unorganized media, but it's not hours of work either, and the DB-matching modes provide rich metadata with all the hassle of ensuring that your paths include the series title and episode number somewhere along the line.
That's a one-time problem though -- it's a barrier, but it's a small one given how frequently mail is used. And modern mail clients are happy to guess virtually all of the settings, at least if your mail server has a standard configuration and you can remember your own email address.
You can select which ciphers you accept. In Firefox the preference is something like "security.ssl3.rsa_rc4_128_md5" -- I'm sure if you search for RC4 in the about:config page you can find the relevant settings. You can explicitly allow or disallow whatever combination of ciphers you like.
And it's not a "false sense of security" when the indicator is binary. It's not as descriptive as telling you what cipher is in use, but it's still encrypted and would take a lot of effort to decrypt (weaknesses have been demonstrated but there's no known attack that's even vaguely plausible in the general case), so given only binary choices "secure" is probably the right one, at least for the time being.
Only if you measure by absolute deaths. By proportion of the global population death count has been going steadily down for a long time, even counting WWII.
I don't think it's quite as simple as that, either. The imbalance of power is part of the point -- after WWI large industrial power engaged in fewer direct conflicts. Arguably at least part of the reason superpowers don't engage, and the reason fewer people die, is because weaponry is more advanced.
And at a range of 600 miles the missile is orders of magnitude more accurate.
You could make exactly the opposite argument with exactly the same evidence (i.e. none): that the decision should be made by someone not at immediate risk of death because they'll be more likely to make the safer-for-others choices and clearly identifying targets rather than making the safer-for-them choices and shooting anything that moves.
Only if you're okay with your remote access solution registering with a third-party that writes all of the software involved and with whom you don't have a contract.
"sane" and "rc.d" are mutually exclusive requirements. Maybe systemd is not the answer, but we know from decades of experience how bad rc.d is.
We should all stop being coy about what we used to make, so that employers lose their knowledge advantage in salary negotiations. Your salary is currently being depressed because you *don't* know what other people are making.
The problem with not publishing salary data is this: employers have asymmetric knowledge of salaries which puts them at a huge negotiating advantage, driving down the average salary. Which is far and away the #1 reason that companies discourage discussion of compensation. This basic economic fact is true in any market with asymmetric knowledge and there's absolutely not reason that you as an employee should want such a thing in the job market -- you'd be much better off in your negotiations (and they'd be simpler and faster for everyone involved) if both you and your employer had access to the same information about compensation.
I don't understand what's scarier about this: /dev/foo/bar /vmfs/volumes/foo/bar.vmdk
lvextend -L+6G
than this:
vmkfstools -X 6G
But that wasn't really the the question I was asking -- what's the different between file-system snapshots and LVM-snapshots (other than filesystem-snapshots obviously don't allow changes to the filesystem itself, which most people don't care about most of the time). Is there something that makes tasks like backups or upgrades easier or faster? Is there some other task I'd snapshot for that just isn't possible with LVM?
There are lots of reasons to like newer filesystems, but the +4 poster above specifically said the LVM snapshots were not as useful as filesystem snapshots, and I'm just wondering what I'm missing.
I'm currently using LVM snapshots for upgrades and backups -- what am I missing compared file system snapshots?
You missed the part where deflation increases the real value of debt, which most individuals, corporations, and governments in modern economies hold to some degree or another. You can argue that they shouldn't, but so long as the do deflation is a big problem.
Because there are already better options for time-shifiting energy usage that most companies haven't done. For example, building ice at night with the A/C and melting the next day. All that requires is a tank of water and a bit of antifreeze in your chiller loop, which are much cheaper and have a much longer lifetime than batteries.
Rules are rarely harmless. And these rules in particular have been used to justify the deaths of many.
If you're worried about independent functionality and reliability you should regulate those aspects *directly* rather than requiring a particular solution. There isn't anything inherent about either of the technologies that guarantee the features you want, nor that prevents those features from being provided.
It's quite unusual for anyone in rural or semi-rural areas; I visited one museum in my entire primary and secondary education and that required extra attendance on Saturday and a $50 fee.
Even in urban areas we do a lot to lock children away from the world rather than engage them in it. The amount of staff you need to keep them locked up is a lot smaller than the amount of staff you need if they were allowed to interact with the world, so guess which one we pick?
So you're aware that there's a bias, and you don't have any explanation for that bias, but you're somehow sure it's not the result of gender discrimination? How does that work?
Women might well be avoiding coding because of the social environment. But why is that a necessary component of coding jobs -- if it's not that's an example of gender discrimination, not evidence against it.
Try framing this issue differently:
All people, regardless of gender, are different and have different interests. Some of them will be more interested in coding than others. But given an arbitrary segregation factor -- eye color, for example -- wouldn't you expect the distribution of the general public to match the distribution among coders? And wouldn't you want to understand why a bias existed if you found one?
Maybe that bias is directly related to suitability for the job; the ability to exchange data with a computer is strictly necessary for coding so people who have trouble with human-computer interfaces are less likely to be coders and we're probably okay with that. But if you don't understand exactly what causes the bias how can you assume it's not discrimination?
The fact that outcomes aren't the same means that *something* is already tilting the playing field. Maybe that's a thing we're okay with, and if that's the case we can let he imbalanced outcome continue. But maybe it's not. If the thing titling the playing field is something we understand and directly control it's easy to fix, but that's not always the case, and I don't think it's not acceptable to say "well, the results are biases but I don't know why so I guess we'll just have to accept the bias" -- I actually want to understand the cause and resolve it as necessary, even if it's hard.
Complain all you want about the particular way that people try to solve problems, but the idea that we should just ignore biased outcomes under the assumption that nothing is wrong is absurd.
/ I also object to the idea that just because something is "natural" or "old" it's acceptable
Charging for parking doesn't do a lot to regulate demand, it's done to regulate turnover. Essentially all publicly-run pay parking is also time-limited, and frequently the rate for short-term usage is lower than commercial parking in the same area. Demand for parking is more or less inelastic because people still need to go places whether or parking is expensive; at best expensive parking encourages the use of other modes of transit.
Turnover isn't actually an issue on public conveyances; loitering *could* be, depending on the circumstances, but most transit systems include a layover point where it's easy to determine if someone is merely camping out.
It was working fine here in Seattle (and Des Moines, where I know they also provide some free downtown bus service). Since the whole route wasn't free it created some hassle with payment collection, but that's only an issue with the mix-and-match plan not the free part. The program has ended recently as funding for it was withdrawn but statistics suggest it did increase ridership in the free zone.
"Trust" and "verify" are contradictory. It's fine that you want to verify, but don't pretend that you are trusting while you actively violate the concept of trust.
So what you're saying is this is a completely accurate simulation of real human life?