Actually, in either case a decent log parser would be useful. I am not aware of any of these really tailored to systemd yet. The binary log format potentially offers a lot of potential here since all the data can be readily obtained broken down into fields, so you don't have to parse lines in an output designed to be terse. Without some kind of monitor systemd will capture that something failed, but it doesn't actually do anything about it besides auto-restart if you tell it to, and log it. Systemctl --failed does show failed services, which is more useful than grepping a log.
I guess that is why systems still hang on shutdown... sometimes.
Yup. Another systemd feature is that if you pair it with dracut then when your system shuts down systemd pivots back to the initramfs, which can unmount your root filesystem and so on. Granted, remounting read-only works reasonably well, but it just seems cleaner to me to fully unmount everything, and this behavior might be desirable in unusual cases.
When I first started using systemd I was expecting boot times to improve, but the thing I really noticed was that shutdown speeds were MUCH faster. I'd run shutdown on a VM and the thing would die faster than the terminal window could keep up.
Part of the reason for systemd's success is the amount of maintainer ass wiping it does.
True to an extent, but you could also say that it refactors this stuff so that instead of every single init script being 50 lines long so that it can clean up after itself, you now have 5-line unit descriptors with a service launcher that can clean up after anything.
The apache unit contains "ExecStop=/usr/sbin/apache2 $APACHE2_OPTS -k graceful-stop" but if for whatever corner case it doesn't stop (maybe a broken config file prevents apache2 from running), then systemd WILL kill it.
I have heard that systemd doesn't always play as nicely with lxc as it does with systemd+systemd-nspawn. I don't have enough experience with lxc to validate this one way or the other.
StartSSL offers free personal use TLS certificates anyway.
I hear they issue them freely, but they do not revoke them freely. So, I can only imagine how many pre-heartbleed certs they have floating around since nobody wants to revoke the bad ones.
> and self signed certificates are far more secure than HTTPS
Right, and with I MITM the wireless AP you're on and replace the self signed with another, you'll go right on thinking you're secure.
That is no different from what happens when you MITM a non-SSL connection.
I have no issues with distinguishing between self-signed and vendor-certified connections. I just don't think that self-signed should trigger MORE warnings than non-SSL connections. Maybe just don't show the padlock for self-signed, and possibly just give a non-scare warning that doesn't take a lot of work to click through the first time you see a particular certificate for a particular site.
How is providing a base level of encryption less private or less secure then sending something in plaintext simply because the other end hasn't paid a fee to a third party?
It is worse to have a false sense of security.
Then don't show the padlock icon. Then the browser behaves the same as if somebody MITM'ed the connection over an http->https gateway. I can trick the average user into not using SSL at all, so why fuss with self-signed certificates?
A small thing I've come to appreciate with systemd is that it actually cares about exit codes. This applies to any unit, including timer units (the equivalent of cron jobs). I ported most of my cron scripts over to systemd and suddenly started noticing scripts which had been having non-zero exits for ages, but fcron just didn't care about exit codes.
You can tell systemd to ignore exit codes for a process, or specific exit codes. However, I've found that in general using systemd I have a lot more awareness of abnormalities in my services.
Sure, you can often get away with ignoring exit codes, just as you can often get away with ignoring compiler warnings. However, in getting rid of them I fixed a few problems ranging from trivial to important, and my system is more robust for it.
One thing I really like about systemd is that when you stop a service, it actually stops.
I used to run monit with openrc and when you wanted to restart a service you had to play games to ensure that it was really killed, and that the service state was cleaned up, and so on. Just telling openrc to stop the service just wasn't reliable at all - it worked well when nothing was wrong, but if nothing was wrong chances are monit wouldn't be doing anything.
Systemd is very effective at containing processes and their children and when you stop them, they are all gone for good. If you want to restart a service, systemctl restart service will get the job done 100% of the time, assuming the configuration/etc lets it restart. It does support graceful shutdown of individual services, followed by process genocide.
This also applies to things like cron jobs you launch through it. When the parent process ends, anything left gets cleaned up.
I've been starting to migrate many of my services at home to containers to make them a bit easier to maintain (a bit of a tangent - having 5 containers instead of one host with 5 services means that you have to do 5x as many updates, but each update can at most break one thing at a time). This was trivial to do with systemd-nspawn.
With a command line that barely fills a terminal line I can launch a container, have it boot systemd inside the container, have a few bind mounts, and have it get its own IP like a lightweight VM. Within the container systemd just does whatever it is told to do, like launch ssh so that I can get in, configure the network, and launch whatever services the container was intended to provide. The container journal logs are symlinked back to the host log directory, so they're really easy to look at from the host.
Sure, you can do similar things with docker, but doing it with systemd involves less tooling in general.
Also, for simpler situations systemd-nspawn makes a VERY good substitute for chroot. In addition to doing everything chroot does, it starts a separate process namespace so you don't see outside processes from inside the container. It also automatically sets up/dev for you, sets up resolv.conf, etc - it can do all this while just spawning one program inside just like chroot does (so no need to run systemd inside). It can also set up bind mounts if you ask it to. When you exit it cleans up - no lingering bind mounts, or tmpfs, or/proc and such inside. Also, any mounts inside the container aren't visible outside, so you can run a backup on your chroot and not have it follow bind mounts, or try to save/proc/kcore or whatever. In fact, you could spawn 5 containers inside the same directory and they can have private/tmp and/dev and/proc while seeing changes each other make in the files in the actual chroot.
Nobody wants to pay to properly quarantine and support people who have been exposed.
Especially when it's the nuts in the US talking about it. What would you do? Arrest them on landing? For what? If you don't arrest them, you can't hold them. Also, how do you identify where they came from if they come back an indirect path?
You quarantine them on landing. This isn't a crime, and quarantine isn't punishment. By all means compensate them for their time, feed them well, and so on. As far as not being able to hold them goes, you put them in a room and you lock the door - you might argue that it is illegal, but clearly it is POSSIBLE.
As far as identification goes - put the burden of proof on the passenger. That is how we contain other health problems like BSE. If you try to sell your meat in the EU, you have to prove that it ISN'T contaminated with BSE. If you can't prove that it is safe, then it is barred from entering the EU. Typically the burden of proof is satisfied by governments cooperating with each other and policing their own industry. If a government doesn't play ball, then other countries won't respect the certifications they issue, and then that country is basically banned from shipping cow-derived anything anywhere.
The goal here isn't to make travel convenient, it is to contain the spread of a disease. I don't see what the problem is with greatly curtailing air travel for a few months while the industrialized nations of the world make a heroic effort to clean up the mess in Africa, and then resolving to never let it get this bad again. While the travel of people would be greatly reduced, you could still ship cargo for the most part. Besides, most of that cargo goes by sea and the incubation time makes that a non-issue for the most part.
Just quarantine anybody travelling from West Africa, and bill the costs to the airline to be passed along to the ticket-holders.
Illegal, and impossible. Other that that, no problems.
We ignore the law to catch terrorists, we certainly can ignore it to stop plagues.:)
And I don't get what makes it impossible. Just require any passenger bound for the US to have certification from the country they are departing from that they have not been to West Africa recently, and don't accept certifications from countries until you've ensured they're serious about it.
It will probably mean that there will be no flights at all into the US for a few weeks while everybody decides if they want to play ball, and that would certainly keep away anybody who has recently been to West Africa.:)
And I imagine they want planes filled both ways to maximize efficiency, revenue, profit, etc.
This is my problem with this whole issue. We're trying to save a buck when it comes down to it. Nobody wants to pay to properly quarantine and support people who have been exposed. Nobody wants there to be a drop in airline revenue, or trade.
It really seems like the #1 thing governments are afraid of is that people will stop going to the mall. That is not really the worst possible outcome here.
Everybody wants to save a few millions dollars by not treating problems like this at the source by applying "overwhelming force." However, if things spiral out of control then we'll all end up spending 10s to 100s of billions of dollars dealing with the resulting mess. This is the US healthcare system in a nutshell - we'll spend $50k on a hospital trying to deal with some acute medical problem suffered by a homeless person, but we won't give him a $1k/yr place to live where he wouldn't develop the problem in the first place because that would just be rewarding laziness or something.
I don't debate that if she is asymptomatic then she probably isn't actively spreading the disease. The problem is that we don't have a lot of data around just what the risks are in the time between somebody starts actively spreading the disease and the time symptoms are first DETECTED (you can't take action prior to detection unless you quarantine pre-emptively). Note that I do not intend to imply an ordering of those two events, and as far as I'm aware there is no hard scientific data supporting that either happens exclusively before the other.
IF there is always no risk of infection prior to the first detection of symptoms then that would make a good case for not doing pre-emptive quarantines. However, we're talking about a very serious problem and it seems rather risky to just try being less careful and see how it goes.
If you can't even quarantine a single person, how's that going to work when you get hundreds, thousands and millions of people infected?
We're better off staying inside our basements.
That is exactly what people are going to do if this gets out of hand. Right now it isn't widespread enough for people to worry about actually getting it. However, if you get to the point where you start having dozens or hundreds of infections in many cities, you'll see everybody go into all-out zombie apocalypse mode.
I just don't get why we're being so lackadaisical about this. We have very few people at risk for spreading Ebola right now. Just pull out all the stops to contain things, and then we don't have to deal with doomsday scenarios. Just quarantine anybody travelling from West Africa, and bill the costs to the airline to be passed along to the ticket-holders. Governments certify that food shipments are BSE-free all the time - they could just as easily certify that travellers are West-Africa free, and if they don't then their air travel will resemble their meat exports.
Yeah, they REALLY need to improve the liability laws around things like this. AEDs are designed to be applicable by untrained users, and tests have shown that people generally are able to use them correctly by following only the verbal prompts.
I checked an in the state where I live you're only protected from liability if you hold a current certificate stating that you're trained in the specific procedure you performed (typically CPR+AED). These certificates often cost $40 and last only a year, so most people aren't going to have them. That is just ridiculous - you should not be liable if you make any good faith effort to save a life.
CPR guidelines generally recognize that even improperly-administered CPR is far preferable to not administering CPR. If the person is unresponsive then CPR should be administered. Modern AHA guidelines instruct non-professionals to not even check for a pulse now - you are only supposed to look for signs of breathing. Even medical professionals are only supposed to check briefly for a pulse before assuming one is not present, since pulses are easy for even professionals to miss. The rationale is that far more people are harmed by a delay in starting CPR than from performing it unnecessarily. Certificates should be even less necessary for an AED - they're designed to diagnose the condition and they will not issue a shock unless an abnormal heart rhythm that is treatable is detected. In theory you can attach one to a healthy person at any time and it won't do anything.
Mythybusters proved that is only a problem in unusual and unlikely circumstances so any man that does that deserves to be labeled a sex offender. Their kind just goes around looking for reasons to take off our clothes. The AED excuse is not a valid one.
The AED instructions (written in the manual and spoken by the machine upon activation) almost always state to remove clothing. Non-professions would almost certainly be covered by a good samaritan law (heck, you're covered if you accidentally kill them, let alone expose them in public). Professionals who disregard the instructions given by the device might even be liable for malpractice. The instructions given by the device are approved by the FDA, and the device is only certified to be effective if used in accordance with instructions.
Sure, the bra might not cause sparks, but you're supposed to do things by the book. The AED is not programmed to argue with an operator - the instructions are streamlined for emergency use and if there is some reason the model might be less effective with a bra on the instructions will not say so - they're just written as if they will be followed.
It has been a long time since I saw that Mythbusters episode and I was not very familiar with AED operation at the time, but something that occurred to me subsequently is that they probably didn't test the diagnostics capability of the AED. If the presence of a wire near the sensors interferes with the diagnostics in the device it may make an incorrect treatment decision, either failing to shock somebody who should be shocked, or delivering a shock to somebody who should not receive one. Either is potentially a life-threatening error. It would not really be possible to test this without proper equipment/etc, since you need to simulate the heart/chest/skin/etc electrically to do it.
In any case, anybody reputable who would testify in court is going to say that the primary consideration should be to take any measure that will maximize the likelihood of saving the patient's life, and that is going to include removing clothing. Why take a chance over something as silly as modesty? If you show up in a hospital trauma OR the first thing they're going to do is chop every stitch of clothing off of you, and for good reason.
Settlement agreed upon with the FTC to include your choice of $2.99 worth of AT&T credit on your account
NO way that they'd just give you straight account credit.
They'd give you $2.99 off of the purchase of something new that you don't already have that costs about $300. Maybe you'd get $2.99 off of the purchase of a new iPad, or off of your first month of T1 service.
A vote of distribution developers, I believe at Redhat where systemd was writen the vote was overwhelming. At debian it was barely a majority. Don't know about SUSE. Certainly there was never a vote taken among users.
Gentoo certainly as folks in both camps, but it generally supports both openrc and systemd, and at this point you'd be hard-pressed to find anything that doesn't work with systemd. I don't know which "side" has a majority, but Gentoo tends to be about choice so it isn't really something that anybody really feels the need to force the issue on.
Is there no middle road between init/inittab and systemd? Why the abrupt change over in a short period of time with a program that hasn't been time tested and comes with a lot of objections? Are there ways to make incremental changes towards the goals that systemd has?
I'd call OpenRC a middle-of-the-road solution. It is probably the best sysvinit-based solution I've ever seen, and nothing would stop anybody from using it on any distro (it is even bash-free).
However, I've been using OpenRC for many years now and I've happily moved on to SystemD. For me the benefits have been worth the pain of dealing with the early-adopter bugs. Plus, I got the sense that the wind was blowing this way a good year or two ago and felt that it was worth getting used to it.
365 days without a security patch. Does uptime make you more money than protecting your customer data?
Most of my servers are behind firewalls with no incoming connections through the Internet. And, yes, uptime matters when we're doing something more critical than serving funny cat videos.
One of the nice things about systemd is that even on a box that needs network connectivity you can deny it to specific processes.
You can even use a systemd socket to accept incoming connections and pass them to a service that is running in a separate network namespace so that it doesn't have any access to the network otherwise. It can communicate via the socket it was given, but it can't make any other outgoing or incoming connection. So, it actually lets you limit your exposure to attacks quite a bit. Or, maybe it is in a network namespace that has access to some other host on the DMZ, but nothing else, including the internet from which the original connection came in.
Yup. OpenRC is about as good a traditional sysvinit implementation as I've seen anywhere - it certainly is much better than what many of the anti-systemd crowd are currently using. However, I get this kind of behavior on Gentoo all the time and is just one of the reasons that I migrated to systemd.
With systemd I can stop a service, and it STOPS, unless there is some kind of kernel bug (can't help that other than to not use less-stable kernel features). It won't have any orphans. It won't have PID files left around. Etc. When I start a service it starts, and if it dies unexpectedly I get a failure status.
I'm using systemd to replace my cron jobs now, and for the first time I actually am taking notice of things like return codes. SystemD by default expects them to be zero (gasp!). If something normally exits with something else you can tell it to ignore it, but now when something fails I actually notice.
If daemons support it systemd can behave as a watchdog beyond just seeing if the process exists. You can put some code in the idle loop to ping systemd and on a timeout systemd will restart the process. Of course, it isn't a substitute for a protocol-specific watchdog, but your monitoring service can remotely connect via ssh and restart your process, and be sure it actually restarts instead of playing games like the one you just described. I used to run monit with OpenRC and I had to play all kinds of kill/zap/etc games in scripts to be sure it would actually restart processes.
Heart disease kills 600 million americans a year. thats 150 times the number of people who died in the world trade center but we still sell sandwiches called the baconator and a small or as we rebranded it 'regular' drink is still 22 ounces.
What evidence is there that drinking a 22 ounce drink or eating a "baconator" increases your risk of heart disease compared to drinking a 12 ounce drink or eating a sandwich not called a "baconator" - or heck, not containing bacon at all? I just had a baconator for lunch today and I've lost 50 pounds in the last year, and my 16 oz drink contained no calories.
I won't argue that people eat a lot of unhealthy stuff, but I'm not convinced that bacon is necessarily among the worst of it.
Women don't particularly love to be abused and they are less willing to put up with it from management than men (who are willing to get called some nasty things by their boss most times)
I don't think that women necessarily object more to abuse, but that our culture tends to give them more freedom to leave their jobs.
Our society tends to regard a working wife as a bit of a luxury. It certainly encourages women to work, but there is also nothing wrong if a woman just stays at home and raises kids, or if a woman is out of work for a while.
Our society tends to regard a working husband as more of a necessity. There is a stigma on a married man who is out of work. Families with a stay at home father and a working mother are very rare.
I think that there is also far less pressure for a young woman to move out of the parent's house/etc than there is for a young man to do the same.
So, a married man in particular is under a lot of pressure to simply not lose a job under any circumstances, while a woman often feels much more free to do so.
I'm speaking broadly, and I'm certainly interested if others feel differently. From my standpoint the women really are the ones with the right attitude here, but the problem is that the US in particular is very cruel to anybody who is out of work. There is very little government support available for anybody who is "picky" about working conditions, and social acceptance may have a big impact on somebody's ability to find support in other ways if they lose their job. Until men are as free to quit their job as women are, I doubt you'll find the same kind of parity in the workplace.
Look at it another way. Suppose you take two groups of runners and put them in races. The one group is competing such that the #1 runner gets a prize. For the second group after each race the last-place runner is shot and replaced with a new runner for the next race. After a number of races, which group do you think is going to end up having the faster average time?
The more restrictive the quarantine rule is, the less likely someone will report symptoms. New cases don't announce themselves with a face-up card and a cube on a map. They arrive with aches and nausea, just like a thousand other ailments.
Then quarantine anybody who is coming from West Africa, or from any country that doesn't also quarantine anybody coming from West Africa. Problem solved.
Or, forcibly quarantine anybody who self-identifies as being at risk and give them a check for $1M for their inconvenience at the same time. Now there isn't incentive to avoid detection. Obviously that amount can be adjusted to whatever amount is effective.
If Ebola gets loose the costs will be astronomical. It doesn't make sense to make saving money a priority when preventing it from breaking out. That means R&D into a vaccine, treatments, as well as caring for people who are potential carriers. They shouldn't be treated as if they're being punished for something, but that doesn't mean that it is wise to just trust everybody to not ride the subway.
Slashdot Mirror
Thanks. I wasn't aware of that.
Actually, in either case a decent log parser would be useful. I am not aware of any of these really tailored to systemd yet. The binary log format potentially offers a lot of potential here since all the data can be readily obtained broken down into fields, so you don't have to parse lines in an output designed to be terse. Without some kind of monitor systemd will capture that something failed, but it doesn't actually do anything about it besides auto-restart if you tell it to, and log it. Systemctl --failed does show failed services, which is more useful than grepping a log.
I guess that is why systems still hang on shutdown... sometimes.
Yup. Another systemd feature is that if you pair it with dracut then when your system shuts down systemd pivots back to the initramfs, which can unmount your root filesystem and so on. Granted, remounting read-only works reasonably well, but it just seems cleaner to me to fully unmount everything, and this behavior might be desirable in unusual cases.
When I first started using systemd I was expecting boot times to improve, but the thing I really noticed was that shutdown speeds were MUCH faster. I'd run shutdown on a VM and the thing would die faster than the terminal window could keep up.
Part of the reason for systemd's success is the amount of maintainer ass wiping it does.
True to an extent, but you could also say that it refactors this stuff so that instead of every single init script being 50 lines long so that it can clean up after itself, you now have 5-line unit descriptors with a service launcher that can clean up after anything.
The apache unit contains "ExecStop=/usr/sbin/apache2 $APACHE2_OPTS -k graceful-stop" but if for whatever corner case it doesn't stop (maybe a broken config file prevents apache2 from running), then systemd WILL kill it.
I have heard that systemd doesn't always play as nicely with lxc as it does with systemd+systemd-nspawn. I don't have enough experience with lxc to validate this one way or the other.
StartSSL offers free personal use TLS certificates anyway.
I hear they issue them freely, but they do not revoke them freely. So, I can only imagine how many pre-heartbleed certs they have floating around since nobody wants to revoke the bad ones.
> and self signed certificates are far more secure than HTTPS
Right, and with I MITM the wireless AP you're on and replace the self signed with another, you'll go right on thinking you're secure.
That is no different from what happens when you MITM a non-SSL connection.
I have no issues with distinguishing between self-signed and vendor-certified connections. I just don't think that self-signed should trigger MORE warnings than non-SSL connections. Maybe just don't show the padlock for self-signed, and possibly just give a non-scare warning that doesn't take a lot of work to click through the first time you see a particular certificate for a particular site.
How is providing a base level of encryption less private or less secure then sending something in plaintext simply because the other end hasn't paid a fee to a third party?
It is worse to have a false sense of security.
Then don't show the padlock icon. Then the browser behaves the same as if somebody MITM'ed the connection over an http->https gateway. I can trick the average user into not using SSL at all, so why fuss with self-signed certificates?
A small thing I've come to appreciate with systemd is that it actually cares about exit codes. This applies to any unit, including timer units (the equivalent of cron jobs). I ported most of my cron scripts over to systemd and suddenly started noticing scripts which had been having non-zero exits for ages, but fcron just didn't care about exit codes.
You can tell systemd to ignore exit codes for a process, or specific exit codes. However, I've found that in general using systemd I have a lot more awareness of abnormalities in my services.
Sure, you can often get away with ignoring exit codes, just as you can often get away with ignoring compiler warnings. However, in getting rid of them I fixed a few problems ranging from trivial to important, and my system is more robust for it.
One thing I really like about systemd is that when you stop a service, it actually stops.
I used to run monit with openrc and when you wanted to restart a service you had to play games to ensure that it was really killed, and that the service state was cleaned up, and so on. Just telling openrc to stop the service just wasn't reliable at all - it worked well when nothing was wrong, but if nothing was wrong chances are monit wouldn't be doing anything.
Systemd is very effective at containing processes and their children and when you stop them, they are all gone for good. If you want to restart a service, systemctl restart service will get the job done 100% of the time, assuming the configuration/etc lets it restart. It does support graceful shutdown of individual services, followed by process genocide.
This also applies to things like cron jobs you launch through it. When the parent process ends, anything left gets cleaned up.
I've been starting to migrate many of my services at home to containers to make them a bit easier to maintain (a bit of a tangent - having 5 containers instead of one host with 5 services means that you have to do 5x as many updates, but each update can at most break one thing at a time). This was trivial to do with systemd-nspawn.
With a command line that barely fills a terminal line I can launch a container, have it boot systemd inside the container, have a few bind mounts, and have it get its own IP like a lightweight VM. Within the container systemd just does whatever it is told to do, like launch ssh so that I can get in, configure the network, and launch whatever services the container was intended to provide. The container journal logs are symlinked back to the host log directory, so they're really easy to look at from the host.
Sure, you can do similar things with docker, but doing it with systemd involves less tooling in general.
Also, for simpler situations systemd-nspawn makes a VERY good substitute for chroot. In addition to doing everything chroot does, it starts a separate process namespace so you don't see outside processes from inside the container. It also automatically sets up /dev for you, sets up resolv.conf, etc - it can do all this while just spawning one program inside just like chroot does (so no need to run systemd inside). It can also set up bind mounts if you ask it to. When you exit it cleans up - no lingering bind mounts, or tmpfs, or /proc and such inside. Also, any mounts inside the container aren't visible outside, so you can run a backup on your chroot and not have it follow bind mounts, or try to save /proc/kcore or whatever. In fact, you could spawn 5 containers inside the same directory and they can have private /tmp and /dev and /proc while seeing changes each other make in the files in the actual chroot.
Nobody wants to pay to properly quarantine and support people who have been exposed.
Especially when it's the nuts in the US talking about it. What would you do? Arrest them on landing? For what? If you don't arrest them, you can't hold them. Also, how do you identify where they came from if they come back an indirect path?
You quarantine them on landing. This isn't a crime, and quarantine isn't punishment. By all means compensate them for their time, feed them well, and so on. As far as not being able to hold them goes, you put them in a room and you lock the door - you might argue that it is illegal, but clearly it is POSSIBLE.
As far as identification goes - put the burden of proof on the passenger. That is how we contain other health problems like BSE. If you try to sell your meat in the EU, you have to prove that it ISN'T contaminated with BSE. If you can't prove that it is safe, then it is barred from entering the EU. Typically the burden of proof is satisfied by governments cooperating with each other and policing their own industry. If a government doesn't play ball, then other countries won't respect the certifications they issue, and then that country is basically banned from shipping cow-derived anything anywhere.
The goal here isn't to make travel convenient, it is to contain the spread of a disease. I don't see what the problem is with greatly curtailing air travel for a few months while the industrialized nations of the world make a heroic effort to clean up the mess in Africa, and then resolving to never let it get this bad again. While the travel of people would be greatly reduced, you could still ship cargo for the most part. Besides, most of that cargo goes by sea and the incubation time makes that a non-issue for the most part.
Just quarantine anybody travelling from West Africa, and bill the costs to the airline to be passed along to the ticket-holders.
Illegal, and impossible. Other that that, no problems.
We ignore the law to catch terrorists, we certainly can ignore it to stop plagues. :)
And I don't get what makes it impossible. Just require any passenger bound for the US to have certification from the country they are departing from that they have not been to West Africa recently, and don't accept certifications from countries until you've ensured they're serious about it.
It will probably mean that there will be no flights at all into the US for a few weeks while everybody decides if they want to play ball, and that would certainly keep away anybody who has recently been to West Africa. :)
And I imagine they want planes filled both ways to maximize efficiency, revenue, profit, etc.
This is my problem with this whole issue. We're trying to save a buck when it comes down to it. Nobody wants to pay to properly quarantine and support people who have been exposed. Nobody wants there to be a drop in airline revenue, or trade.
It really seems like the #1 thing governments are afraid of is that people will stop going to the mall. That is not really the worst possible outcome here.
Everybody wants to save a few millions dollars by not treating problems like this at the source by applying "overwhelming force." However, if things spiral out of control then we'll all end up spending 10s to 100s of billions of dollars dealing with the resulting mess. This is the US healthcare system in a nutshell - we'll spend $50k on a hospital trying to deal with some acute medical problem suffered by a homeless person, but we won't give him a $1k/yr place to live where he wouldn't develop the problem in the first place because that would just be rewarding laziness or something.
I don't debate that if she is asymptomatic then she probably isn't actively spreading the disease. The problem is that we don't have a lot of data around just what the risks are in the time between somebody starts actively spreading the disease and the time symptoms are first DETECTED (you can't take action prior to detection unless you quarantine pre-emptively). Note that I do not intend to imply an ordering of those two events, and as far as I'm aware there is no hard scientific data supporting that either happens exclusively before the other.
IF there is always no risk of infection prior to the first detection of symptoms then that would make a good case for not doing pre-emptive quarantines. However, we're talking about a very serious problem and it seems rather risky to just try being less careful and see how it goes.
If you can't even quarantine a single person, how's that going to work when you get hundreds, thousands and millions of people infected?
We're better off staying inside our basements.
That is exactly what people are going to do if this gets out of hand. Right now it isn't widespread enough for people to worry about actually getting it. However, if you get to the point where you start having dozens or hundreds of infections in many cities, you'll see everybody go into all-out zombie apocalypse mode.
I just don't get why we're being so lackadaisical about this. We have very few people at risk for spreading Ebola right now. Just pull out all the stops to contain things, and then we don't have to deal with doomsday scenarios. Just quarantine anybody travelling from West Africa, and bill the costs to the airline to be passed along to the ticket-holders. Governments certify that food shipments are BSE-free all the time - they could just as easily certify that travellers are West-Africa free, and if they don't then their air travel will resemble their meat exports.
Yeah, they REALLY need to improve the liability laws around things like this. AEDs are designed to be applicable by untrained users, and tests have shown that people generally are able to use them correctly by following only the verbal prompts.
I checked an in the state where I live you're only protected from liability if you hold a current certificate stating that you're trained in the specific procedure you performed (typically CPR+AED). These certificates often cost $40 and last only a year, so most people aren't going to have them. That is just ridiculous - you should not be liable if you make any good faith effort to save a life.
CPR guidelines generally recognize that even improperly-administered CPR is far preferable to not administering CPR. If the person is unresponsive then CPR should be administered. Modern AHA guidelines instruct non-professionals to not even check for a pulse now - you are only supposed to look for signs of breathing. Even medical professionals are only supposed to check briefly for a pulse before assuming one is not present, since pulses are easy for even professionals to miss. The rationale is that far more people are harmed by a delay in starting CPR than from performing it unnecessarily. Certificates should be even less necessary for an AED - they're designed to diagnose the condition and they will not issue a shock unless an abnormal heart rhythm that is treatable is detected. In theory you can attach one to a healthy person at any time and it won't do anything.
Mythybusters proved that is only a problem in unusual and unlikely circumstances so any man that does that deserves to be labeled a sex offender. Their kind just goes around looking for reasons to take off our clothes. The AED excuse is not a valid one.
The AED instructions (written in the manual and spoken by the machine upon activation) almost always state to remove clothing. Non-professions would almost certainly be covered by a good samaritan law (heck, you're covered if you accidentally kill them, let alone expose them in public). Professionals who disregard the instructions given by the device might even be liable for malpractice. The instructions given by the device are approved by the FDA, and the device is only certified to be effective if used in accordance with instructions.
Sure, the bra might not cause sparks, but you're supposed to do things by the book. The AED is not programmed to argue with an operator - the instructions are streamlined for emergency use and if there is some reason the model might be less effective with a bra on the instructions will not say so - they're just written as if they will be followed.
It has been a long time since I saw that Mythbusters episode and I was not very familiar with AED operation at the time, but something that occurred to me subsequently is that they probably didn't test the diagnostics capability of the AED. If the presence of a wire near the sensors interferes with the diagnostics in the device it may make an incorrect treatment decision, either failing to shock somebody who should be shocked, or delivering a shock to somebody who should not receive one. Either is potentially a life-threatening error. It would not really be possible to test this without proper equipment/etc, since you need to simulate the heart/chest/skin/etc electrically to do it.
In any case, anybody reputable who would testify in court is going to say that the primary consideration should be to take any measure that will maximize the likelihood of saving the patient's life, and that is going to include removing clothing. Why take a chance over something as silly as modesty? If you show up in a hospital trauma OR the first thing they're going to do is chop every stitch of clothing off of you, and for good reason.
Settlement agreed upon with the FTC to include your choice of $2.99 worth of AT&T credit on your account
NO way that they'd just give you straight account credit.
They'd give you $2.99 off of the purchase of something new that you don't already have that costs about $300. Maybe you'd get $2.99 off of the purchase of a new iPad, or off of your first month of T1 service.
A vote of distribution developers, I believe at Redhat where systemd was writen the vote was overwhelming. At debian it was barely a majority. Don't know about SUSE. Certainly there was never a vote taken among users.
Gentoo certainly as folks in both camps, but it generally supports both openrc and systemd, and at this point you'd be hard-pressed to find anything that doesn't work with systemd. I don't know which "side" has a majority, but Gentoo tends to be about choice so it isn't really something that anybody really feels the need to force the issue on.
Is there no middle road between init/inittab and systemd? Why the abrupt change over in a short period of time with a program that hasn't been time tested and comes with a lot of objections? Are there ways to make incremental changes towards the goals that systemd has?
I'd call OpenRC a middle-of-the-road solution. It is probably the best sysvinit-based solution I've ever seen, and nothing would stop anybody from using it on any distro (it is even bash-free).
However, I've been using OpenRC for many years now and I've happily moved on to SystemD. For me the benefits have been worth the pain of dealing with the early-adopter bugs. Plus, I got the sense that the wind was blowing this way a good year or two ago and felt that it was worth getting used to it.
365 days without a security patch. Does uptime make you more money than protecting your customer data?
Most of my servers are behind firewalls with no incoming connections through the Internet. And, yes, uptime matters when we're doing something more critical than serving funny cat videos.
One of the nice things about systemd is that even on a box that needs network connectivity you can deny it to specific processes.
You can even use a systemd socket to accept incoming connections and pass them to a service that is running in a separate network namespace so that it doesn't have any access to the network otherwise. It can communicate via the socket it was given, but it can't make any other outgoing or incoming connection. So, it actually lets you limit your exposure to attacks quite a bit. Or, maybe it is in a network namespace that has access to some other host on the DMZ, but nothing else, including the internet from which the original connection came in.
Yup. OpenRC is about as good a traditional sysvinit implementation as I've seen anywhere - it certainly is much better than what many of the anti-systemd crowd are currently using. However, I get this kind of behavior on Gentoo all the time and is just one of the reasons that I migrated to systemd.
With systemd I can stop a service, and it STOPS, unless there is some kind of kernel bug (can't help that other than to not use less-stable kernel features). It won't have any orphans. It won't have PID files left around. Etc. When I start a service it starts, and if it dies unexpectedly I get a failure status.
I'm using systemd to replace my cron jobs now, and for the first time I actually am taking notice of things like return codes. SystemD by default expects them to be zero (gasp!). If something normally exits with something else you can tell it to ignore it, but now when something fails I actually notice.
If daemons support it systemd can behave as a watchdog beyond just seeing if the process exists. You can put some code in the idle loop to ping systemd and on a timeout systemd will restart the process. Of course, it isn't a substitute for a protocol-specific watchdog, but your monitoring service can remotely connect via ssh and restart your process, and be sure it actually restarts instead of playing games like the one you just described. I used to run monit with OpenRC and I had to play all kinds of kill/zap/etc games in scripts to be sure it would actually restart processes.
Heart disease kills 600 million americans a year. thats 150 times the number of people who died in the world trade center but we still sell sandwiches called the baconator and a small or as we rebranded it 'regular' drink is still 22 ounces.
What evidence is there that drinking a 22 ounce drink or eating a "baconator" increases your risk of heart disease compared to drinking a 12 ounce drink or eating a sandwich not called a "baconator" - or heck, not containing bacon at all? I just had a baconator for lunch today and I've lost 50 pounds in the last year, and my 16 oz drink contained no calories.
I won't argue that people eat a lot of unhealthy stuff, but I'm not convinced that bacon is necessarily among the worst of it.
Women don't particularly love to be abused and they are less willing to put up with it from management than men (who are willing to get called some nasty things by their boss most times)
I don't think that women necessarily object more to abuse, but that our culture tends to give them more freedom to leave their jobs.
Our society tends to regard a working wife as a bit of a luxury. It certainly encourages women to work, but there is also nothing wrong if a woman just stays at home and raises kids, or if a woman is out of work for a while.
Our society tends to regard a working husband as more of a necessity. There is a stigma on a married man who is out of work. Families with a stay at home father and a working mother are very rare.
I think that there is also far less pressure for a young woman to move out of the parent's house/etc than there is for a young man to do the same.
So, a married man in particular is under a lot of pressure to simply not lose a job under any circumstances, while a woman often feels much more free to do so.
I'm speaking broadly, and I'm certainly interested if others feel differently. From my standpoint the women really are the ones with the right attitude here, but the problem is that the US in particular is very cruel to anybody who is out of work. There is very little government support available for anybody who is "picky" about working conditions, and social acceptance may have a big impact on somebody's ability to find support in other ways if they lose their job. Until men are as free to quit their job as women are, I doubt you'll find the same kind of parity in the workplace.
Look at it another way. Suppose you take two groups of runners and put them in races. The one group is competing such that the #1 runner gets a prize. For the second group after each race the last-place runner is shot and replaced with a new runner for the next race. After a number of races, which group do you think is going to end up having the faster average time?
The more restrictive the quarantine rule is, the less likely someone will report symptoms. New cases don't announce themselves with a face-up card and a cube on a map. They arrive with aches and nausea, just like a thousand other ailments.
Then quarantine anybody who is coming from West Africa, or from any country that doesn't also quarantine anybody coming from West Africa. Problem solved.
Or, forcibly quarantine anybody who self-identifies as being at risk and give them a check for $1M for their inconvenience at the same time. Now there isn't incentive to avoid detection. Obviously that amount can be adjusted to whatever amount is effective.
If Ebola gets loose the costs will be astronomical. It doesn't make sense to make saving money a priority when preventing it from breaking out. That means R&D into a vaccine, treatments, as well as caring for people who are potential carriers. They shouldn't be treated as if they're being punished for something, but that doesn't mean that it is wise to just trust everybody to not ride the subway.