Last time I looked at this, L4 was some 1-2mS context switch on x86, back in the 1GHz chip era; Minix was 100uS; and it was some 20uS on ARM. ARM is a good architecture--even L4 was ridiculously fast on ARM. Mach was slow as balls all the time.
No idea. I've seen the performance tests where they repeatedly send kill signals to the disk driver to crash it over and over, and measure its impact on performance--large when you have this in a tight loop, yet the system trudges along, and stops being so god damn slow when you stop killing the disk service 1000 times per second.
I can conjecture a lot about how it is and isn't possible--obviously you can't just restart a snapshot from a few ns ago, or tell it to try again, or rerun the service and dump the same exact data back over it; but you can resubmit requests and messages in any number of ways. If you're careful to use a request-acknowledge-free workflow (send a request, wait for an acknowledgement that it's completed, then free the memory for the request when it's acknowledged or when the requested information is returned), you can always replay a request if the server dies. You can even use a mediator to resubmit uncompleted requests or stored state (received frames, journaled file system actions, etc.) to a service if it gets restarted, hiding that process from other services.
Minix documentation and demonstration show that they restart the service and it completes all requests--state is snapshotted and restored. How that state is snapshotted--internal to service, mediated by a message passer, or resubmitted by client services--I don't actually know. I just know it does it and it's technically possible in any number of ways.
You can reconstruct state. A read request from hard disk will work the same way, repeatedly; a write request to a file system will write to a journal or the same blocks in a file or inode, while a write to a hard drive sector is isometric. Keeping the request buffer, resubmitting the request, and so on lets you reconstruct state. Even a network driver theoretically could read state from the network: it could request DMA from the NIC to a buffered memory area with a control structure of known layout, and the resurrection server could provide the control structure and buffered memory areas back to the driver if it needs to restart.
The remainder of the driver state can be discarded. Bringing in new network frames, new writes to file systems, or the like shouldn't depend on the driver's internal state. Repeated crashing--for example, reloading the network driver as above and having the control structure point to a buffer of unmapped memory--could signal the OS to simply drop state and start fresh. Recovery is possible in many cases: TCP/IP, as a separate driver, would simply experience a dropped frame (lost packet), handling a state-reset network driver the same way as any other faulty media; a failed hard drive write would signal the FS driver to resubmit its write; and a failed file system operation could go so far as to reload the driver and run a journal replay or file system check (non-journaled file systems could use an in-memory journal to facilitate file system driver recovery).
Consider state as a collection of significant and insignificant states. My Web browser right now has a lot of stuff in memory, a lot of things rendered on the screen, a state of how far down I've scrolled, and state describing where in memory all these things are--and where this text I'm typing is stored. If we unload the browser and then re-launch, the only state I need restored to post this message is a copy of this message, dumped anywhere in RAM, with a specific pointer somewhere referencing that buffer as the context of this particular textbox on this Web site. The browser's state may be completely different, yet only that piece of information is important; I can recover the rest by coming to this page and hitting "Reply To This".
From that view, it's not hard to recover discrete processes in an OS. File system separate from disk driver means the FS can handle a disk driver crash and reload; user prorgrams won't notice a file system driver crash if the system just waits for the FS driver to reload and replay a journal or such to return state to sanity. The task entry for the user program tracks all the file handles. All of these things are separate, can communicate between mediators, or can mediate their own communications.
Linux currently leads. Minix needs a bunch of drivers implementing kernel event hooks, inotify, dnotify, etc. Essentially, everything for udevd, systemd, and dbus. These wouldn't be integrated in core, and so could only come online when building a distribution to support a Linux-like user space. Could even implement iptables. Would need ext4, xfs, btrfs, zfs, and fuse drivers eventually.
The file system write or read request doesn't return anything, the driver is detected as dead (heartbeat?), it's killed, resurrected, journals are replayed, and the request is resubmitted to the FS driver.
It'll work. The program might notice a small pause, as if the disk was busy or the kernel yielded schedule to an interrupt handler.
The novel approach is that Tanenbaum invented the fucking thing. The specific current advantage is low-latency IPC--on ARM, Minix IPC doesn't even have a measurable cost (the context switch time required is under 20 microseconds), while on x86 IPC is more than 10 times faster than L4.
Monoliths, e.g. Linux, don't have IPC latency because they don't context switch when making calls between major kernel functional units. Of course, if your network driver crashes, your whole system gets fucked up and dies; whereas Minix tries to take a state snapshot, reconstruct something workable, load it into a fresh run of the network driver, and continue without a hickup. This works extremely well with the disk and FS drivers. Ideally, we want this without paying for it.
Yeah this is what I was thinking. Nobody says to google it on Bing; they tell you to google it, or try using Bing instead. We may have forgotten what a "search" is, but we still say "use Yahoo" or "try Bing" if googling fails.
It's funny because they said they want the books to be more "accurate", and they've decided this means "unicorns shitting rainbows".
We're writing books about the logical conclusion of what we see around us. By the nature of evolution and survival of the fittest, the most violent carnivore always rises to the top: it survives best, it develops a brain capable of developing new ways to kill things, and then it murders the shit out of bears and tigers trying to eat its children. Being that you have physical force to protect your species, you also have dead predators; being that there are other animals, you have competition for food, hence predation--slimming down the number of animals eating all the food and turning some of those animals into food.
Carnivores are a reality; and analytic, violent carnivores are the kind of thing that dominates an entire planet. They then develop minds fit for getting around all obstacles--predation, rivers, fires, trees, natural disasters, illness (fire to cook food, or the first caveman to notice chewing a certain plant reduced fever and fatigue from sickness, and thus worshiped the plant as some kind of magic). Technology. Space travel.
They either destroy themselves with war or they come invade all your shit. At best, it'd be like dealing with other humans: we'd be suspicious of each other, attempt diplomacy, and then engage in war when one side or the other throws a tantrum over some trivial bullshit.
If you look domestically, you'll see our public servants have trained us to call them "leaders". Corporations have taken over our lives and our government. Nothing good there, either.
What the hell "accurate"? Do you think we'll invent nuclear fusion and immediately enter a utiopia where we meet the Vulcans, burn the peace flower, and sing Kumbaya next to the fire while they give us the secret to ending disease and creating an equal power distribution? Humans wouldn't even be happy with a flat power distribution; we need someone above us right until everyone else is below us, just to have another rung to climb. How can we compete if we annihilate competition, erase the whole concept of one human being better than another human? You can't get any pussy that way, and--if you've talked to anyone in America in the past 40 years, or Freud--that's what life is all about.
This looks like smoke and mirrors. It looks like they're proposing a compromise to dazzle the American people with fancy words that amount to the same thing. That's an immoral strategy--they've been told no, so they're rephrasing the same proposal to sound like something else so as to deceive everyone--and such behavior should bring a prompt end to negotiations.
It depends, really. It's relatively easy to estimate schedule, if you know what you're doing; project managers can balance constraints for repeated projects in a program by reducing the scope of individual projects, adjusting the schedule to meet a release schedule.
With Git, you can begin on the next release while performing QA on the current code base to be released next month--increasing cost risk (every adjustment to the code base requires merging those changes back into the next branch), but not a lot when you consider the nature of mostly-stable code (and bug fixes) along with Git's high-quality merge features. Thus it's possible to have a 6-month or 3-month release schedule, but start work on the next release a month in advance (or even earlier); of course, you need the resources to do so--when you go into QA, your main programmers might suddenly be 99% idle in favor of specialist quality testers, and thus free to move on to the next project.
Open Source Software development is run like a poorly-planned adaptive agile project: people throw a few features down, but largely just work. Adaptive projects chunk off a budget, a time frame (6 months, 5 years, etc.), and a large strategy (create a Web browser), and modify the project plan continuously. This is expensive--it produces a lot of work, rework, unplanned work, etc.--and only viable for very specific cases. Mostly people like the adaptive approach because either they can't see the inefficiency or they don't have the capacity to plan. The second group usually involves staffing support projects: you have $15 million to supply 120 employees for a Government agency over 5 years for the various positions supporting a certain group of operational functions, but the requirements (jobs open, job descriptions, length of employment for temps) will change wildly along that timeline. Notice this looks more like operations than a project.
A plan-driven project uses an approach like Waterfall to fully plan a project before beginning. This is the most efficient, but also relatively high risk. A plan-driven project doesn't account for changes; they always happen, but there's lacking effort in minimizing impact. Instead, effort goes into controlling risk (as always) and minimizing everything else--cost, schedule drift, risk of change.
Most open source products--indeed, most software projects and most projects in general--would benefit from an iterative or incremental agile approach.
In an incremental approach, the project manager arranges the project schedule to focus work on discrete, immediately-useful deliverables: something 100% complete and ready for release is produced as quickly as possible at each step. As each deliverable is released, it is evaluated by the customer (e.g. all Firefox users, all Ubuntu users), and the state of the whole product is accounted for and used to re-plan the next deliverables. In essence, you see how it's fitting together, and can adjust further features to work best with what you've delivered so far, or perform defect repair to improve the product if it's shaping up shitty.
In an iterative approach, a broad framework is lain and then built upon. For example, you would lay out the class structure and APIs for a large Python application; then build on that to provide the basic interface; then work on top of that to refine all the basic features into something workable; then build upon that to flesh out the features. This strategy reduces risk by first producing a broad platform to build upon, allowing for greater knowledge when planning further iterations.
Compound approaches are also viable: you can build the main platform iteratively, and start building incremental deliverables (i.e. features) on top of that. It doesn't make strict sense to iterate every single feature--and besides, if it did, every independent feature would be an incrementally-deliverable iteration, and thus the only cost of delivering them incrementally is management overhead. With unlimited resou
They all talk about "serving their country". They join "to serve", or they join because they think they're hot shit and want to get some combat experience so they can feel tough. The second group should be shoved in a locker and tossed off the bridge; the first wouldn't join if they thought 95% of the wars they would get deployed to were unjust, as they'd only see themselves as instruments of murder and not heroes fighting for freedom.
In other words: people who worship glorious, heroic veterans of wars are more likely to become veterans themselves. They see it as some high honor, and jump into a war they know nothing about. If they start thinking war is a horrible thing and not an exercise of glory and valor, they might start thinking if war is necessary--and, deciding that it is, might grasp further to decide if any given war is itself necessary rather than a political sideshow. They may stop worshiping returned veterans and start pitying them.
We want dead bodies and stories about the war and trauma and your buddies dying at the hands of krauts and sand-niggers, not living proof of the pain and suffering of war.
War is a far-away thing: your daddy went off and didn't come back, or he came back with mental problems because he is a pussy. We don't want war sitting in our houses, in our day-to-day lives. We might stop worshiping veterans and start questioning if all the wars we're in are necessary or if we should only take to arms under more scrutiny.
It is, but it's also not as much of a problem as people think. Come on, we find 6000 year old urns and reverse engineer the recipe for the beer they used to contain; do you think we can't analyze dried meat for atherosclerosis?
Sure there's going to be noise; but there will also be some mild level of confidence about whether this guy had a body full of horrific bullshit from a bad diet or what.
The renal system is supposed to adjust after a few days and correct this, such that you expel the excess salt and your blood pressure normalizes. Of course jumping from a 2000mg sodium diet to a 4000mg sodium diet will up your blood pressure; but, three days later, it should be normal again, while you're still downing 4000mg of sodium every day.
The original study linking sodium to high blood pressure was to feed a rat an intake equivalent to 500g of salt in a human per day. Humans are safe up to 6g of sodium intake per day; salt is a lot more than 10% sodium by mass.
People living in countries with a high salt consumption—such as Japan—also tend to have high blood pressure and more strokes. But as a paper pointed out several years later in the American Journal of Hypertension, scientists had little luck finding such associations when they compared sodium intakes within populations, which suggested that genetics or other cultural factors might be the culprit.
If, 150 years ago, the average life expectancy was 30-40 years, but the average human level of general health in those 30-40 years was better than the same in the first 30-40 years of modern humans's lives, then you could say that something we did back 150 years ago was better and we were healthier and living well on whatever we were doing.
In short: strain, work, lack of surgery and vaccines, poor understanding of disease, bad hygiene, the like, could take a toll; but, meanwhile, people have healthy hearts, strong livers, good blood flow, clear blood vessels, low blood pressure, strong lungs. In such a situation, we could conclude with relative certainty that our lower constant work load, lower exposure to disease, and greater access to health services has provided the greater lifespan; and everything else is suspect, and something in that pile of everything was better off 150 years ago.
This is relatively easy to explore. All we need are dissection records or dissection of well-preserved corpses from the era, so as to examine the state of organs. Finding the source material is difficult. We don't, however, need to take a time machine back and put people on EKG and take blood tests and blood pressure.
If a bad guy "jumps you" then unless you're Aikido dude or what have you, you're probably already fucked no matter how you intend to defend yourself. Initiative is massively important, and I don't mean that in a dungeons and dragons kind of way. Often, the first shot decides the fight.
Not really, but somewhat. Being aware of everyone and not being surprised that someone is suddenly on you is good; if you hear them or otherwise notice them rushing at you, you have time and space to work with--it may not be enough to draw a gun, but it's enough to take control of the knife arm.
On the other hand, most people aren't carrying around long sheathed knives, if the knife is big enough to need a weapon to defend against it then it's probably a folder and you very much can draw a gun, point it, and shoot in about the same kind of time.
I can stab you fatally with a pencil. A 3 inch folder (which can be a fixed blade, not a folding knife) is plenty bad; it doesn't need to be an 11 inch Tanto. Boot knives are effective, but far away from the hand. For muggery, murder, or rape, the best weapon is a small, fixed-blade knife easily concealed in the hand: you can hold the blade in your hand without cutting yourself (even a very sharp knife), and then rotate it to have a proper grip on the knife for assault in a smooth, immediate motion.
That's what you need to defend against: knives coming out of nowhere.
At a shorter distance, guns are still massively deadly. Point blank is scary for a reason.
Point-blank is the distance at which the travel of a bullet by wind resistance or gravity is not an issue, and so you don't need to adjust for any drift. You point directly at the target (on a practice target, this is the white "blanc" bull's eye) and fire. If the target is a human, there is no leading; you don't shoot in front of, but rather directly at a person.
This can be a lot of distance.
Second, any weapon is massively deadly. My fists are massively deadly. If they can't be used effectively, that doesn't much matter. At close range, the opportunity to score a fatal or disabling hit with a gun is much lower; and the threat of losing the firearm in grappling is higher. Stray bullets are more likely. If it's not pointed at your face, it's not going to shoot you in the face.
The best defense is to be somewhere else. Yeah, blaming the victim, but if you have the opportunity to be somewhere [relatively] nonviolent, take that option.
This is a passive-predatory stance. If everyone left the violent areas, the criminals would move after the victims. It's like saying you should be a highland sheep, because the population of highland sheep is too low to sustain a generational wolf population, and the highlands are just a tad too far out for wolves to come to hunt, and there are virtually endless sheep in the lowlands and so the wolves are not interested in moving outward for prey. If the sheep all move to the highlands, the wolves will follow.
The problem with blaming people for living in violent areas is they would put you at risk by moving out of those violent areas. You should thank them for being decoys.
Slashdot Mirror
Last time I looked at this, L4 was some 1-2mS context switch on x86, back in the 1GHz chip era; Minix was 100uS; and it was some 20uS on ARM. ARM is a good architecture--even L4 was ridiculously fast on ARM. Mach was slow as balls all the time.
No idea. I've seen the performance tests where they repeatedly send kill signals to the disk driver to crash it over and over, and measure its impact on performance--large when you have this in a tight loop, yet the system trudges along, and stops being so god damn slow when you stop killing the disk service 1000 times per second.
I can conjecture a lot about how it is and isn't possible--obviously you can't just restart a snapshot from a few ns ago, or tell it to try again, or rerun the service and dump the same exact data back over it; but you can resubmit requests and messages in any number of ways. If you're careful to use a request-acknowledge-free workflow (send a request, wait for an acknowledgement that it's completed, then free the memory for the request when it's acknowledged or when the requested information is returned), you can always replay a request if the server dies. You can even use a mediator to resubmit uncompleted requests or stored state (received frames, journaled file system actions, etc.) to a service if it gets restarted, hiding that process from other services.
Minix documentation and demonstration show that they restart the service and it completes all requests--state is snapshotted and restored. How that state is snapshotted--internal to service, mediated by a message passer, or resubmitted by client services--I don't actually know. I just know it does it and it's technically possible in any number of ways.
You can reconstruct state. A read request from hard disk will work the same way, repeatedly; a write request to a file system will write to a journal or the same blocks in a file or inode, while a write to a hard drive sector is isometric. Keeping the request buffer, resubmitting the request, and so on lets you reconstruct state. Even a network driver theoretically could read state from the network: it could request DMA from the NIC to a buffered memory area with a control structure of known layout, and the resurrection server could provide the control structure and buffered memory areas back to the driver if it needs to restart.
The remainder of the driver state can be discarded. Bringing in new network frames, new writes to file systems, or the like shouldn't depend on the driver's internal state. Repeated crashing--for example, reloading the network driver as above and having the control structure point to a buffer of unmapped memory--could signal the OS to simply drop state and start fresh. Recovery is possible in many cases: TCP/IP, as a separate driver, would simply experience a dropped frame (lost packet), handling a state-reset network driver the same way as any other faulty media; a failed hard drive write would signal the FS driver to resubmit its write; and a failed file system operation could go so far as to reload the driver and run a journal replay or file system check (non-journaled file systems could use an in-memory journal to facilitate file system driver recovery).
Consider state as a collection of significant and insignificant states. My Web browser right now has a lot of stuff in memory, a lot of things rendered on the screen, a state of how far down I've scrolled, and state describing where in memory all these things are--and where this text I'm typing is stored. If we unload the browser and then re-launch, the only state I need restored to post this message is a copy of this message, dumped anywhere in RAM, with a specific pointer somewhere referencing that buffer as the context of this particular textbox on this Web site. The browser's state may be completely different, yet only that piece of information is important; I can recover the rest by coming to this page and hitting "Reply To This".
From that view, it's not hard to recover discrete processes in an OS. File system separate from disk driver means the FS can handle a disk driver crash and reload; user prorgrams won't notice a file system driver crash if the system just waits for the FS driver to reload and replay a journal or such to return state to sanity. The task entry for the user program tracks all the file handles. All of these things are separate, can communicate between mediators, or can mediate their own communications.
Linux currently leads. Minix needs a bunch of drivers implementing kernel event hooks, inotify, dnotify, etc. Essentially, everything for udevd, systemd, and dbus. These wouldn't be integrated in core, and so could only come online when building a distribution to support a Linux-like user space. Could even implement iptables. Would need ext4, xfs, btrfs, zfs, and fuse drivers eventually.
The file system write or read request doesn't return anything, the driver is detected as dead (heartbeat?), it's killed, resurrected, journals are replayed, and the request is resubmitted to the FS driver.
It'll work. The program might notice a small pause, as if the disk was busy or the kernel yielded schedule to an interrupt handler.
The novel approach is that Tanenbaum invented the fucking thing. The specific current advantage is low-latency IPC--on ARM, Minix IPC doesn't even have a measurable cost (the context switch time required is under 20 microseconds), while on x86 IPC is more than 10 times faster than L4.
Monoliths, e.g. Linux, don't have IPC latency because they don't context switch when making calls between major kernel functional units. Of course, if your network driver crashes, your whole system gets fucked up and dies; whereas Minix tries to take a state snapshot, reconstruct something workable, load it into a fresh run of the network driver, and continue without a hickup. This works extremely well with the disk and FS drivers. Ideally, we want this without paying for it.
Yeah this is what I was thinking. Nobody says to google it on Bing; they tell you to google it, or try using Bing instead. We may have forgotten what a "search" is, but we still say "use Yahoo" or "try Bing" if googling fails.
Nobody says "well use Bing to google it then".
It's funny because they said they want the books to be more "accurate", and they've decided this means "unicorns shitting rainbows".
We're writing books about the logical conclusion of what we see around us. By the nature of evolution and survival of the fittest, the most violent carnivore always rises to the top: it survives best, it develops a brain capable of developing new ways to kill things, and then it murders the shit out of bears and tigers trying to eat its children. Being that you have physical force to protect your species, you also have dead predators; being that there are other animals, you have competition for food, hence predation--slimming down the number of animals eating all the food and turning some of those animals into food.
Carnivores are a reality; and analytic, violent carnivores are the kind of thing that dominates an entire planet. They then develop minds fit for getting around all obstacles--predation, rivers, fires, trees, natural disasters, illness (fire to cook food, or the first caveman to notice chewing a certain plant reduced fever and fatigue from sickness, and thus worshiped the plant as some kind of magic). Technology. Space travel.
They either destroy themselves with war or they come invade all your shit. At best, it'd be like dealing with other humans: we'd be suspicious of each other, attempt diplomacy, and then engage in war when one side or the other throws a tantrum over some trivial bullshit.
If you look domestically, you'll see our public servants have trained us to call them "leaders". Corporations have taken over our lives and our government. Nothing good there, either.
What the hell "accurate"? Do you think we'll invent nuclear fusion and immediately enter a utiopia where we meet the Vulcans, burn the peace flower, and sing Kumbaya next to the fire while they give us the secret to ending disease and creating an equal power distribution? Humans wouldn't even be happy with a flat power distribution; we need someone above us right until everyone else is below us, just to have another rung to climb. How can we compete if we annihilate competition, erase the whole concept of one human being better than another human? You can't get any pussy that way, and--if you've talked to anyone in America in the past 40 years, or Freud--that's what life is all about.
If it's immoral or illegal, don't negotiate.
This looks like smoke and mirrors. It looks like they're proposing a compromise to dazzle the American people with fancy words that amount to the same thing. That's an immoral strategy--they've been told no, so they're rephrasing the same proposal to sound like something else so as to deceive everyone--and such behavior should bring a prompt end to negotiations.
It depends, really. It's relatively easy to estimate schedule, if you know what you're doing; project managers can balance constraints for repeated projects in a program by reducing the scope of individual projects, adjusting the schedule to meet a release schedule.
With Git, you can begin on the next release while performing QA on the current code base to be released next month--increasing cost risk (every adjustment to the code base requires merging those changes back into the next branch), but not a lot when you consider the nature of mostly-stable code (and bug fixes) along with Git's high-quality merge features. Thus it's possible to have a 6-month or 3-month release schedule, but start work on the next release a month in advance (or even earlier); of course, you need the resources to do so--when you go into QA, your main programmers might suddenly be 99% idle in favor of specialist quality testers, and thus free to move on to the next project.
Open Source Software development is run like a poorly-planned adaptive agile project: people throw a few features down, but largely just work. Adaptive projects chunk off a budget, a time frame (6 months, 5 years, etc.), and a large strategy (create a Web browser), and modify the project plan continuously. This is expensive--it produces a lot of work, rework, unplanned work, etc.--and only viable for very specific cases. Mostly people like the adaptive approach because either they can't see the inefficiency or they don't have the capacity to plan. The second group usually involves staffing support projects: you have $15 million to supply 120 employees for a Government agency over 5 years for the various positions supporting a certain group of operational functions, but the requirements (jobs open, job descriptions, length of employment for temps) will change wildly along that timeline. Notice this looks more like operations than a project.
A plan-driven project uses an approach like Waterfall to fully plan a project before beginning. This is the most efficient, but also relatively high risk. A plan-driven project doesn't account for changes; they always happen, but there's lacking effort in minimizing impact. Instead, effort goes into controlling risk (as always) and minimizing everything else--cost, schedule drift, risk of change.
Most open source products--indeed, most software projects and most projects in general--would benefit from an iterative or incremental agile approach.
In an incremental approach, the project manager arranges the project schedule to focus work on discrete, immediately-useful deliverables: something 100% complete and ready for release is produced as quickly as possible at each step. As each deliverable is released, it is evaluated by the customer (e.g. all Firefox users, all Ubuntu users), and the state of the whole product is accounted for and used to re-plan the next deliverables. In essence, you see how it's fitting together, and can adjust further features to work best with what you've delivered so far, or perform defect repair to improve the product if it's shaping up shitty.
In an iterative approach, a broad framework is lain and then built upon. For example, you would lay out the class structure and APIs for a large Python application; then build on that to provide the basic interface; then work on top of that to refine all the basic features into something workable; then build upon that to flesh out the features. This strategy reduces risk by first producing a broad platform to build upon, allowing for greater knowledge when planning further iterations.
Compound approaches are also viable: you can build the main platform iteratively, and start building incremental deliverables (i.e. features) on top of that. It doesn't make strict sense to iterate every single feature--and besides, if it did, every independent feature would be an incrementally-deliverable iteration, and thus the only cost of delivering them incrementally is management overhead. With unlimited resou
They all talk about "serving their country". They join "to serve", or they join because they think they're hot shit and want to get some combat experience so they can feel tough. The second group should be shoved in a locker and tossed off the bridge; the first wouldn't join if they thought 95% of the wars they would get deployed to were unjust, as they'd only see themselves as instruments of murder and not heroes fighting for freedom.
In other words: people who worship glorious, heroic veterans of wars are more likely to become veterans themselves. They see it as some high honor, and jump into a war they know nothing about. If they start thinking war is a horrible thing and not an exercise of glory and valor, they might start thinking if war is necessary--and, deciding that it is, might grasp further to decide if any given war is itself necessary rather than a political sideshow. They may stop worshiping returned veterans and start pitying them.
We want dead bodies and stories about the war and trauma and your buddies dying at the hands of krauts and sand-niggers, not living proof of the pain and suffering of war.
War is a far-away thing: your daddy went off and didn't come back, or he came back with mental problems because he is a pussy. We don't want war sitting in our houses, in our day-to-day lives. We might stop worshiping veterans and start questioning if all the wars we're in are necessary or if we should only take to arms under more scrutiny.
I don't get it. Doesn't thin ice melt faster? I spread my ice to make it melt more quickly.
Yeah the scripted thing is best supported by timestamps, not writing style. That's a dumb argument.
It is, but it's also not as much of a problem as people think. Come on, we find 6000 year old urns and reverse engineer the recipe for the beer they used to contain; do you think we can't analyze dried meat for atherosclerosis?
Sure there's going to be noise; but there will also be some mild level of confidence about whether this guy had a body full of horrific bullshit from a bad diet or what.
From American high school history, Freedom was invented in the 1700s, in the new world.
So we need average infant and child mortality, and average adult lifespan?
So it's bayesian science instead of frequency science?
The renal system is supposed to adjust after a few days and correct this, such that you expel the excess salt and your blood pressure normalizes. Of course jumping from a 2000mg sodium diet to a 4000mg sodium diet will up your blood pressure; but, three days later, it should be normal again, while you're still downing 4000mg of sodium every day.
The original study linking sodium to high blood pressure was to feed a rat an intake equivalent to 500g of salt in a human per day. Humans are safe up to 6g of sodium intake per day; salt is a lot more than 10% sodium by mass.
People living in countries with a high salt consumption—such as Japan—also tend to have high blood pressure and more strokes. But as a paper pointed out several years later in the American Journal of Hypertension, scientists had little luck finding such associations when they compared sodium intakes within populations, which suggested that genetics or other cultural factors might be the culprit.
That's not really the issue.
If, 150 years ago, the average life expectancy was 30-40 years, but the average human level of general health in those 30-40 years was better than the same in the first 30-40 years of modern humans's lives, then you could say that something we did back 150 years ago was better and we were healthier and living well on whatever we were doing.
In short: strain, work, lack of surgery and vaccines, poor understanding of disease, bad hygiene, the like, could take a toll; but, meanwhile, people have healthy hearts, strong livers, good blood flow, clear blood vessels, low blood pressure, strong lungs. In such a situation, we could conclude with relative certainty that our lower constant work load, lower exposure to disease, and greater access to health services has provided the greater lifespan; and everything else is suspect, and something in that pile of everything was better off 150 years ago.
This is relatively easy to explore. All we need are dissection records or dissection of well-preserved corpses from the era, so as to examine the state of organs. Finding the source material is difficult. We don't, however, need to take a time machine back and put people on EKG and take blood tests and blood pressure.
If a bad guy "jumps you" then unless you're Aikido dude or what have you, you're probably already fucked no matter how you intend to defend yourself. Initiative is massively important, and I don't mean that in a dungeons and dragons kind of way. Often, the first shot decides the fight.
Not really, but somewhat. Being aware of everyone and not being surprised that someone is suddenly on you is good; if you hear them or otherwise notice them rushing at you, you have time and space to work with--it may not be enough to draw a gun, but it's enough to take control of the knife arm.
On the other hand, most people aren't carrying around long sheathed knives, if the knife is big enough to need a weapon to defend against it then it's probably a folder and you very much can draw a gun, point it, and shoot in about the same kind of time.
I can stab you fatally with a pencil. A 3 inch folder (which can be a fixed blade, not a folding knife) is plenty bad; it doesn't need to be an 11 inch Tanto. Boot knives are effective, but far away from the hand. For muggery, murder, or rape, the best weapon is a small, fixed-blade knife easily concealed in the hand: you can hold the blade in your hand without cutting yourself (even a very sharp knife), and then rotate it to have a proper grip on the knife for assault in a smooth, immediate motion.
That's what you need to defend against: knives coming out of nowhere.
At a shorter distance, guns are still massively deadly. Point blank is scary for a reason.
Point-blank is the distance at which the travel of a bullet by wind resistance or gravity is not an issue, and so you don't need to adjust for any drift. You point directly at the target (on a practice target, this is the white "blanc" bull's eye) and fire. If the target is a human, there is no leading; you don't shoot in front of, but rather directly at a person.
This can be a lot of distance.
Second, any weapon is massively deadly. My fists are massively deadly. If they can't be used effectively, that doesn't much matter. At close range, the opportunity to score a fatal or disabling hit with a gun is much lower; and the threat of losing the firearm in grappling is higher. Stray bullets are more likely. If it's not pointed at your face, it's not going to shoot you in the face.
The best defense is to be somewhere else. Yeah, blaming the victim, but if you have the opportunity to be somewhere [relatively] nonviolent, take that option.
This is a passive-predatory stance. If everyone left the violent areas, the criminals would move after the victims. It's like saying you should be a highland sheep, because the population of highland sheep is too low to sustain a generational wolf population, and the highlands are just a tad too far out for wolves to come to hunt, and there are virtually endless sheep in the lowlands and so the wolves are not interested in moving outward for prey. If the sheep all move to the highlands, the wolves will follow.
The problem with blaming people for living in violent areas is they would put you at risk by moving out of those violent areas. You should thank them for being decoys.
This is what I've been trying to explain, but nobody listens.
"Cosmologists can speculate with high confidence." Everything about that sentence is terrible.