Ok, now we've exhausted the 10 beds at the hospital that are usable for quarantine. We've still got 150 patients with symptoms in the emergency room.
Yeah. There is no point in nationwide panic, but I think we're making a big mistake in not getting ahead of this.
The summary talks about OMG money lost because of "unnecessary" travel restrictions. That sounds a bit like "OMG look at all that money wasted over Y2K" when the whole point of the exercise was to prevent a disaster. Every year OMG I waste a ton of money on fire insurance, and yet year after year my house fails to burn down.
That's the thing about risk. If I offered you $1000 to roll the dice with the condition that I'll shoot you if it comes up snake eyes you'd be insane to take the deal. However, a dozen people could easily walk up to me, get a quick $1k, and talk about how you're an idiot for not taking the easy money.
$40B sounds like a lot of money, but it probably was over such timescales and with such widely-inclusive accounting that it was a drop in the bucket. It isn't like you can make one Earth with travel restrictions and one Earth without it and compare the evolution of each economy.
It makes sense to get ahead of this now with very serious restrictions. When there are actual cases, treat them with overkill measures now while we still can afford to. I don't get why people under quarantine aren't under guard. Just post a police officer outside their house. Heaven forbid it cost somebody $5k to deal with an Ebola case (never mind that the hospital probably went through 10x that).
You're absolutely right that if it ever takes off those overkill measures will be completely unsustainable. At that point you really need something like a field hospital and triage system. Forget assigning a doctor to everybody - it will be techs in hazmat suits and tents. Better that then sending people home, but you'll never see it happen since no hospital wants to be sued for not delivering the appropriate standard of care. See here, the official manual says that somebody with Ebola should go in a $500k isolation ward, not a $10 tent, so you now have 50M malpractice cases.
If things really go south your best bet is probably to stock up on MREs, find some way of ensuring that the virus can't enter your water supply, and hole up for a month or two.
Uh, there are people who are more knowledgeable than you at CDC who have thought of these exact problems. Also, they aren't panicking like you are, which gives them a much greater chance of solving the problem.
You do realize that the CDC is a political organization, right?
There is a pretty good chance that most of the US won't end up dying off from this, but some chance that it will. If the latter happens there is nothing to be done about it after the fact. If you dodge the bullet and were calm and collected on TV the whole time, then you come across as level-headed and get to keep your cushy job. The incentive for officials is to downplay this, just as with anything else unless there is some kind of money to be made. If big government contractors start offering portable Ebola isolation units for a mere $10k each in quantities of 1000 then you'll see a shift in policy and the disease still won't be anything to worry about but every hospital in America will end up buying a stockpile of them. To be honest, it might not be such a bad investment.
Woud such a chip device ever be allowed to have Linux drivers, considering how hard everything is getting hacked today, even without their existance?
I don't know how Chip/PIN was actually implemented, but if the makers had half a brain there would be no reason not to make the drivers/protocols/etc completely open. There is no reason that the system should have to rely on the security of the POS terminal - the crypto happens on the smartcard and all the terminal should do is relay stuff between the bank and the card. In fact, I don't get why they don't just put the keypad on the card itself, making the PIN harder to steal, as well as the credential on the chip.
Am I out of consideration if I refer to the polygraph as 'truth dowsing' while it is being administered? How about asking if it can detect witches?
That would show that you have a brain, but it would probably get you disqualified. Polygraph examiners in general give disfavorable reviews of anybody who questions the technology, or for that matter anybody who even shows any kind of knowledge about it. After all, the only reason somebody who isn't a polygraph examiner would know something about a polygraph is if they are trying to deceive the examiner.
You seem to mis-understand and also seem a little desperate for journald to not be a steaming pile (else why are you playing semantic games with situations I have made clear are not the case?). There are any number of possibilities for bugs in journald. For example, it could be attempting to be clever and as a result not writing entire records out promptly.
It could also randomly delete/etc/passwd. I'm asking for substantiation, not hand-waving.
I have no desire for semantic games. I just don't understand what failure modes journald is actually susceptible to that something like syslog-ng isn't. If it doesn't flush in the way that it should, then just point that out in detail (and please don't tell me that it should run fsync every 15 seconds in a braindead fashion like the ext3 designers would have you do).
You ask how is it unnecessary? Some administrator might not find a software with most code less than half a decade old, high recent code churn; suitable for logging in important servers.
Well, then direct the logs to syslog. You don't have to look at the journald log in order to use systemd - you can forward logs to syslog, and processes can directly log to syslog as always.
It might be fine for an init replacement because the init or its replacement runs rarely. Do you see such a person's point?
Uh, init runs continuously, and the kernel panics if it stops.
In what way does journald corrupt log files any more than any other logger?
Let us consider the following question in 2012 : In what way does btrfs corrupt files any more than any other filesystem?
Someone not willing to use btrfs in 2012 need not know the answer, but yet have every reason to not use btrfs. Including any other software that forces use of btrfs along with it. That is how software reliability (any reliability, but let us not digress) works.
A log just appends sequentially to a file, with some utility (whether that be journalctl or cat/more/less) which reads it sequentially. It is a bit much to compare that to something like btrfs. A better comparison would be to something like tar.
When the money transfers cause people to avoid utilization or purchase another product, it can be a real harm to the company (unless it is more than offset by some benefit from using the competing product - though that should REALLY motivate you to fix something).
On the other hand, as long as it doesn't affect decision-making these sorts of things can have legitimate accounting purposes. At my workplace we realized it would be a lot simpler from an accounting/legal standpoint if we just charged our suppliers fair-value for any materials they need from us, and just have them lump that back into the price they sell the resulting goods back to us at. Legally it documents all the value-adds for tax and customs purposes, and can also make costs more apparent within the company. Of course, we realize all this but we don't actually do it, which means that we have to jump through all kinds of hoops with various governments who want to make sure that taxes and such get paid on real values and not made-up ones.
But, don't expect somebody to spend a lot of time maintaining a distro that doesn't work well on containers, as opposed to one that works well on containers and bare metal.
Also, don't expect everyone to spend a lot of time maintaining a distro that's fooled by propagandists who boasts about a product that brings a handful of badly implemented improvements while breaking half of everything that already work well, and refuse to fix problems in the product which lead to the breakage:)
I look forward to the obvious impending demise of Debian, Ubuntu, RHEL, CentOS, Fedora, Gentoo, Arch, Mint, and just about every other Linux distro around other than Slackware (which as far as I'm aware is the only big one that hasn't implemented systemd). Well, Google hasn't announced any plans to move away from Upstart on Chromebooks but I'm sure that is just a matter of time - other than having the best-selling laptops around I'm not sure how those matter. Maybe they'll switch from Upstart to a hodge-podge of traditional bash scripts.
You should start your own Linux distribution company founded on a systemd-free platform. It sounds like you'll have thousands of seasoned linux contributors lining up at your doors to help build your product, and you can fork Debian or whatever to start with.
However, most likely whoever maintains your distro isn't going to want to maintain a configuration just for people who don't use containers.
Which distro? Ubuntu, Debian, Fedora, Arch or Gentoo? Is there a reference for any of them dropping non-container support? So by "most likely" you mean "barely"? Or by "whoever" you mean "a minority"?
I wasn't saying that distros are going to drop non-container support. I said that they aren't going to support a different configuration just for non-container users. All of these distros support systemd, which works fine whether you use containers or not.
Perhaps journald should be more careful how it flushes it's buffers.
In what way? How is it any different from syslog? The last time I checked syslog didn't do double-buffering, and if it did it would actually have to deal with cases where records made it out to the first log but not the second.
Syslog just doesn't bother to detect log corruptions.
You seem to think that there is something about journald that makes it more prone to log corruptions than text-based logging solutions. As far as I can tell, the only difference is one of definitions. If you get half a line in a text-based log it isn't defined as a corruption, but if you get half a record in the journald log you do call it a corruption.
The fact that people say that journald is "prone to corruptions" doesn't make it any worse than syslog.
like in most fiction/movies/anime about a robotic future, the robots would wind up being controlled by a few gigacorporations
It will probably be the same giga-corps that prevented common people from owning cars, TVs, computers, and smartphones.
That sounds like "No American has been killed by Ebola in the latest outbreak so far, so no American can ever be killed by Ebola in the latest outbreak."
You can't buy any of the things you mentioned without having money, and the main way that people earn money is via jobs. Actually, that is rather mistatated. The way most money is earned is from investments, but the way that most people earn money is from jobs (since most of the money earning actually involves fairly few of the people). Robots are just one more investment.
Robots are actually fairly expensive. Anybody can legally buy an aircraft, but the reality is that very few own them. Legally anybody can build a robot used to build cars, but to build a car you actually need a lot of them and a lot of other expensive equipment and space, and the result is that nobody owns them except car factories.
If somebody ever invented a general purpose robot - that is one that can walk, talk, assemble things, compose poetry, write software, paint masterpieces, build and operate an M1 Abrams, and perform effective crowd control, then there basically would be no more jobs for anybody. Those who could afford the first batch of robots would clean up, and the rest would live under whatever system of government the robot owners devised.
Tragically, most people are totally unaware that they are only a few weeks of discipline away from being able to comfortably maintain healthful dietary habits--and to keep away from the products that can result in the destruction of their health. Instead, most people think that if they were to eat more healthfully, they would be condemned to a life of greatly reduced gustatory pleasure--thinking that the process of Phase IV will last forever.
This meshes with my own observations when I switched to a low-carb diet. I found that I'd eat and still "feel" hungry. The low-carb solution is to just allow yourself to eat more in this case, but to still stay away from the carbs. Your brain then learns that cramming more food in your mouth no longer produces the sensations it is looking for, and it becomes easier to not eat so much. I felt a bit like a rat in a Skinner box pushing the button and not getting any food, and just like the rat in the Skinner box I eventually stopped pushing the button so much.
The change in tastes definitely happened. In the beginning I would make myself low-carb treats and think they were tasteless. Then after many months I actually had an ice cream sundae and thought that it almost tasted sickeningly sweet. I don't really make myself low carb treats all that much these days, but when I do I often just stick with erythritol and don't even bother with adding more sweetener, which should resulting in something maybe half as sweet as a normal treat.
Certainly it helps, but it isn't really a cure once you already have it. Now, I'll grant that you're MUCH better of cutting out carbs than you are if you don't, but if you already have fairly severe insulin resistance you'll probably still be on medications for life unless something changes, and this particular advance probably isn't it.
Now, cutting down the carbs early in life is probably a good way to avoid ever having insulin resistance in the first place.
There's been a few things made from adult stem cells. This may end up being one of them after a bit more work, so that then cells from the intended recipient can be taken, altered, grown and transplanted. Then it's functionally like a skin graft.
Sure, but whether this works still depends greatly on what caused the diabetes in the first place.
Type 1 diabetics are generally believed to start out with functional beta cells, but their body destroys them. If you just implant more functional beta cells, the body may very well destroy those as well. If the problem is autoimmune in nature and the target is the glucose receptors on the cells or something like that, then in order for the cell to be functional as a beta cell it would need to be vulnerable to an autoimmune response.
Now, if somebody just doesn't have the gene for insulin production or something like that, then I would think that this would cure them. However, it couldn't involve doing anything that presented new antigens to the immune system. If the problem was that the patient lacked some cell receptor on their beta cells, and you introduced new cells with that receptor, I'd think that there would be considerable risk of that being detected as a foreign antigen.
I don't pretend to be fully knowledgeable of type 1 diabetes or some of the details of the immune system, but this was the first thing I thought of when I read this summary as well.
And your sysadmin practices are based on the assumption that VMs are the same as containers.
When did I ever make that claim?
I stated that the boot time was very useful on containers. Somebody else pointed out that he never reboots his VMs. I then pointed out that it is very helpful to be able to quickly reboot containers.
So, what is your point? That you'd rather not run systemd on your servers? Then don't. But, don't expect somebody to spend a lot of time maintaining a distro that doesn't work well on containers, as opposed to one that works well on containers and bare metal.
And yet there are persistent reports of corrupted log files from journald answered with a wontfix...
Well, they should use whatever configuration you use then. What scenario is going to result in the corruption of a journal that isn't going to result in the corruption of a text log? They both involve appending data to the end of a file. If your system guarantees that it is impossible for a file to end up with only half a line, then it would guarantee that it is impossible for a file to end up with half a record.
If the wontfix bothers you that much, then write up a better explanation for why the bug reports are invalid and mark it as invalid instead.:)
You don't evaluate your server requirements or pay the maintainance for us, so you know nothing about what is suitable for us. And the same for many other use cases, which you ignorantly choose to take notice of.
Well, if you don't want to use systemd, then don't. As you point out, it might not be needed in your case.
However, most likely whoever maintains your distro isn't going to want to maintain a configuration just for people who don't use containers. It makes more sense from their standpoint to come up with the most general solution possible, and using systemd doesn't really exclude anybody on Linux. So, you may end up having to use more of a niche distro or roll your own, which probably isn't your goal.
I can look at the logs and see that they aren't corrupt. Naturally, the filesystem journal ends up replaying each time the machines are shut down rough, but that actually takes care of it.
Well, in that case I would expect it to take care of your journald logs as well.
Well, that depends on what matters to you. You can use systemd without many of its components. Just not without those. And I'm not really sure why you care if the log traffic is forwarded vs direct.
Why should one lose the ability to view non-corrupted [freedesktop.org] text logs from bootloader just to get an init replacement?
People keep quoting that bug, but it doesn't make it true. In what way does journald corrupt log files any more than any other logger? I think it is just more visible because it can actually detect if a log file wasn't cleanly closed. If you pull the plug on a system running syslog you could end up with truncated log files, but syslog will just happily keep appending to them making the error non-apparent until you try to actually parse the logs programatically.
Journald still reads whatever it can out of a log file - it just doesn't try to interpret half-records.
About as well as you can remove the preprocessor from gcc. Not every component of systemd is easy to get by without. In the case of journald you can operate it in non-persistent mode, so that it doesn't actually write any logs to disk.
Some systemd components are more essential than others, which is usually the case with modular software. Kde is modular, but good luck deleting kdelibs.
And how often are you going to reap that reward? I just did a quick spot-check of our 1,200+ host local VM farm, and didn't see any hosts with less than 60 days uptime; it would be longer if not for quarterly patch/reboot cycles. You realize that's sort of the entire point, right?
When I run updates on a container I shut it down, snapshot its subvolume, and start it up. That takes a few hundred millseconds with zero impact to anything that depends on it (nothing times out that fast). Why not do it - the reboot costs nothing and gains you a bit more consistency if you have to roll back.
Your sysadmin practices are based on the assumption that reboots result in downtime.
The whole point of the kernel is for it to be in the background.
So is the init.
When I set init=/bin/bash or/bin/tivo, the last thing I want is for it to be in the background. You're just getting stuck on your preconceived notions of how a unix box should work.
Employers NEVER fire people for attending jury duty.
Sure, where you work. Some people are stuck working McJobs and do get penalized if they dare to ask for a day off, even if it is for jury duty. They don't get the chance to put in 30 hours over the weekend so they don't end up homeless at the end of the month.
I think you missed the point. McJobs never fire people for jury duty either. They only fire people for breaking the rules. Of course, everybody breaks the rules since they're impossible to follow, but you only get written up for them if you attend jury duty, or you don't sleep with the boss, or you're the wrong race, etc.
And yes, for many simply being denied the opportunity to work can be devestating.
Slashdot Mirror
Ok, now we've exhausted the 10 beds at the hospital that are usable for quarantine. We've still got 150 patients with symptoms in the emergency room.
Yeah. There is no point in nationwide panic, but I think we're making a big mistake in not getting ahead of this.
The summary talks about OMG money lost because of "unnecessary" travel restrictions. That sounds a bit like "OMG look at all that money wasted over Y2K" when the whole point of the exercise was to prevent a disaster. Every year OMG I waste a ton of money on fire insurance, and yet year after year my house fails to burn down.
That's the thing about risk. If I offered you $1000 to roll the dice with the condition that I'll shoot you if it comes up snake eyes you'd be insane to take the deal. However, a dozen people could easily walk up to me, get a quick $1k, and talk about how you're an idiot for not taking the easy money.
$40B sounds like a lot of money, but it probably was over such timescales and with such widely-inclusive accounting that it was a drop in the bucket. It isn't like you can make one Earth with travel restrictions and one Earth without it and compare the evolution of each economy.
It makes sense to get ahead of this now with very serious restrictions. When there are actual cases, treat them with overkill measures now while we still can afford to. I don't get why people under quarantine aren't under guard. Just post a police officer outside their house. Heaven forbid it cost somebody $5k to deal with an Ebola case (never mind that the hospital probably went through 10x that).
You're absolutely right that if it ever takes off those overkill measures will be completely unsustainable. At that point you really need something like a field hospital and triage system. Forget assigning a doctor to everybody - it will be techs in hazmat suits and tents. Better that then sending people home, but you'll never see it happen since no hospital wants to be sued for not delivering the appropriate standard of care. See here, the official manual says that somebody with Ebola should go in a $500k isolation ward, not a $10 tent, so you now have 50M malpractice cases.
If things really go south your best bet is probably to stock up on MREs, find some way of ensuring that the virus can't enter your water supply, and hole up for a month or two.
Uh, there are people who are more knowledgeable than you at CDC who have thought of these exact problems. Also, they aren't panicking like you are, which gives them a much greater chance of solving the problem.
You do realize that the CDC is a political organization, right?
There is a pretty good chance that most of the US won't end up dying off from this, but some chance that it will. If the latter happens there is nothing to be done about it after the fact. If you dodge the bullet and were calm and collected on TV the whole time, then you come across as level-headed and get to keep your cushy job. The incentive for officials is to downplay this, just as with anything else unless there is some kind of money to be made. If big government contractors start offering portable Ebola isolation units for a mere $10k each in quantities of 1000 then you'll see a shift in policy and the disease still won't be anything to worry about but every hospital in America will end up buying a stockpile of them. To be honest, it might not be such a bad investment.
Woud such a chip device ever be allowed to have Linux drivers, considering how hard everything is getting hacked today, even without their existance?
I don't know how Chip/PIN was actually implemented, but if the makers had half a brain there would be no reason not to make the drivers/protocols/etc completely open. There is no reason that the system should have to rely on the security of the POS terminal - the crypto happens on the smartcard and all the terminal should do is relay stuff between the bank and the card. In fact, I don't get why they don't just put the keypad on the card itself, making the PIN harder to steal, as well as the credential on the chip.
Am I out of consideration if I refer to the polygraph as 'truth dowsing' while it is being administered? How about asking if it can detect witches?
That would show that you have a brain, but it would probably get you disqualified. Polygraph examiners in general give disfavorable reviews of anybody who questions the technology, or for that matter anybody who even shows any kind of knowledge about it. After all, the only reason somebody who isn't a polygraph examiner would know something about a polygraph is if they are trying to deceive the examiner.
You seem to mis-understand and also seem a little desperate for journald to not be a steaming pile (else why are you playing semantic games with situations I have made clear are not the case?). There are any number of possibilities for bugs in journald. For example, it could be attempting to be clever and as a result not writing entire records out promptly.
It could also randomly delete /etc/passwd. I'm asking for substantiation, not hand-waving.
I have no desire for semantic games. I just don't understand what failure modes journald is actually susceptible to that something like syslog-ng isn't. If it doesn't flush in the way that it should, then just point that out in detail (and please don't tell me that it should run fsync every 15 seconds in a braindead fashion like the ext3 designers would have you do).
You ask how is it unnecessary? Some administrator might not find a software with most code less than half a decade old, high recent code churn; suitable for logging in important servers.
Well, then direct the logs to syslog. You don't have to look at the journald log in order to use systemd - you can forward logs to syslog, and processes can directly log to syslog as always.
It might be fine for an init replacement because the init or its replacement runs rarely. Do you see such a person's point?
Uh, init runs continuously, and the kernel panics if it stops.
In what way does journald corrupt log files any more than any other logger?
Let us consider the following question in 2012 : In what way does btrfs corrupt files any more than any other filesystem?
Someone not willing to use btrfs in 2012 need not know the answer, but yet have every reason to not use btrfs. Including any other software that forces use of btrfs along with it. That is how software reliability (any reliability, but let us not digress) works.
A log just appends sequentially to a file, with some utility (whether that be journalctl or cat/more/less) which reads it sequentially. It is a bit much to compare that to something like btrfs. A better comparison would be to something like tar.
When the money transfers cause people to avoid utilization or purchase another product, it can be a real harm to the company (unless it is more than offset by some benefit from using the competing product - though that should REALLY motivate you to fix something).
On the other hand, as long as it doesn't affect decision-making these sorts of things can have legitimate accounting purposes. At my workplace we realized it would be a lot simpler from an accounting/legal standpoint if we just charged our suppliers fair-value for any materials they need from us, and just have them lump that back into the price they sell the resulting goods back to us at. Legally it documents all the value-adds for tax and customs purposes, and can also make costs more apparent within the company. Of course, we realize all this but we don't actually do it, which means that we have to jump through all kinds of hoops with various governments who want to make sure that taxes and such get paid on real values and not made-up ones.
But, don't expect somebody to spend a lot of time maintaining a distro that doesn't work well on containers, as opposed to one that works well on containers and bare metal.
Also, don't expect everyone to spend a lot of time maintaining a distro that's fooled by propagandists who boasts about a product that brings a handful of badly implemented improvements while breaking half of everything that already work well, and refuse to fix problems in the product which lead to the breakage :)
I look forward to the obvious impending demise of Debian, Ubuntu, RHEL, CentOS, Fedora, Gentoo, Arch, Mint, and just about every other Linux distro around other than Slackware (which as far as I'm aware is the only big one that hasn't implemented systemd). Well, Google hasn't announced any plans to move away from Upstart on Chromebooks but I'm sure that is just a matter of time - other than having the best-selling laptops around I'm not sure how those matter. Maybe they'll switch from Upstart to a hodge-podge of traditional bash scripts.
You should start your own Linux distribution company founded on a systemd-free platform. It sounds like you'll have thousands of seasoned linux contributors lining up at your doors to help build your product, and you can fork Debian or whatever to start with.
However, most likely whoever maintains your distro isn't going to want to maintain a configuration just for people who don't use containers.
Which distro? Ubuntu, Debian, Fedora, Arch or Gentoo? Is there a reference for any of them dropping non-container support?
So by "most likely" you mean "barely"? Or by "whoever" you mean "a minority"?
I wasn't saying that distros are going to drop non-container support. I said that they aren't going to support a different configuration just for non-container users. All of these distros support systemd, which works fine whether you use containers or not.
Perhaps journald should be more careful how it flushes it's buffers.
In what way? How is it any different from syslog? The last time I checked syslog didn't do double-buffering, and if it did it would actually have to deal with cases where records made it out to the first log but not the second.
Syslog just doesn't bother to detect log corruptions.
You seem to think that there is something about journald that makes it more prone to log corruptions than text-based logging solutions. As far as I can tell, the only difference is one of definitions. If you get half a line in a text-based log it isn't defined as a corruption, but if you get half a record in the journald log you do call it a corruption.
The fact that people say that journald is "prone to corruptions" doesn't make it any worse than syslog.
like in most fiction/movies/anime about a robotic future, the robots would wind up being controlled by a few gigacorporations
It will probably be the same giga-corps that prevented common people from owning cars, TVs, computers, and smartphones.
That sounds like "No American has been killed by Ebola in the latest outbreak so far, so no American can ever be killed by Ebola in the latest outbreak."
You can't buy any of the things you mentioned without having money, and the main way that people earn money is via jobs. Actually, that is rather mistatated. The way most money is earned is from investments, but the way that most people earn money is from jobs (since most of the money earning actually involves fairly few of the people). Robots are just one more investment.
Robots are actually fairly expensive. Anybody can legally buy an aircraft, but the reality is that very few own them. Legally anybody can build a robot used to build cars, but to build a car you actually need a lot of them and a lot of other expensive equipment and space, and the result is that nobody owns them except car factories.
If somebody ever invented a general purpose robot - that is one that can walk, talk, assemble things, compose poetry, write software, paint masterpieces, build and operate an M1 Abrams, and perform effective crowd control, then there basically would be no more jobs for anybody. Those who could afford the first batch of robots would clean up, and the rest would live under whatever system of government the robot owners devised.
Tragically, most people are totally unaware that they are only a few weeks of discipline away from being able to comfortably maintain healthful dietary habits--and to keep away from the products that can result in the destruction of their health. Instead, most people think that if they were to eat more healthfully, they would be condemned to a life of greatly reduced gustatory pleasure--thinking that the process of Phase IV will last forever.
This meshes with my own observations when I switched to a low-carb diet. I found that I'd eat and still "feel" hungry. The low-carb solution is to just allow yourself to eat more in this case, but to still stay away from the carbs. Your brain then learns that cramming more food in your mouth no longer produces the sensations it is looking for, and it becomes easier to not eat so much. I felt a bit like a rat in a Skinner box pushing the button and not getting any food, and just like the rat in the Skinner box I eventually stopped pushing the button so much.
The change in tastes definitely happened. In the beginning I would make myself low-carb treats and think they were tasteless. Then after many months I actually had an ice cream sundae and thought that it almost tasted sickeningly sweet. I don't really make myself low carb treats all that much these days, but when I do I often just stick with erythritol and don't even bother with adding more sweetener, which should resulting in something maybe half as sweet as a normal treat.
Just eat a lot less carbs.
Certainly it helps, but it isn't really a cure once you already have it. Now, I'll grant that you're MUCH better of cutting out carbs than you are if you don't, but if you already have fairly severe insulin resistance you'll probably still be on medications for life unless something changes, and this particular advance probably isn't it.
Now, cutting down the carbs early in life is probably a good way to avoid ever having insulin resistance in the first place.
There's been a few things made from adult stem cells. This may end up being one of them after a bit more work, so that then cells from the intended recipient can be taken, altered, grown and transplanted. Then it's functionally like a skin graft.
Sure, but whether this works still depends greatly on what caused the diabetes in the first place.
Type 1 diabetics are generally believed to start out with functional beta cells, but their body destroys them. If you just implant more functional beta cells, the body may very well destroy those as well. If the problem is autoimmune in nature and the target is the glucose receptors on the cells or something like that, then in order for the cell to be functional as a beta cell it would need to be vulnerable to an autoimmune response.
Now, if somebody just doesn't have the gene for insulin production or something like that, then I would think that this would cure them. However, it couldn't involve doing anything that presented new antigens to the immune system. If the problem was that the patient lacked some cell receptor on their beta cells, and you introduced new cells with that receptor, I'd think that there would be considerable risk of that being detected as a foreign antigen.
I don't pretend to be fully knowledgeable of type 1 diabetes or some of the details of the immune system, but this was the first thing I thought of when I read this summary as well.
And your sysadmin practices are based on the assumption that VMs are the same as containers.
When did I ever make that claim?
I stated that the boot time was very useful on containers. Somebody else pointed out that he never reboots his VMs. I then pointed out that it is very helpful to be able to quickly reboot containers.
So, what is your point? That you'd rather not run systemd on your servers? Then don't. But, don't expect somebody to spend a lot of time maintaining a distro that doesn't work well on containers, as opposed to one that works well on containers and bare metal.
And yet there are persistent reports of corrupted log files from journald answered with a wontfix...
Well, they should use whatever configuration you use then. What scenario is going to result in the corruption of a journal that isn't going to result in the corruption of a text log? They both involve appending data to the end of a file. If your system guarantees that it is impossible for a file to end up with only half a line, then it would guarantee that it is impossible for a file to end up with half a record.
If the wontfix bothers you that much, then write up a better explanation for why the bug reports are invalid and mark it as invalid instead. :)
You don't evaluate your server requirements or pay the maintainance for us, so you know nothing about what is suitable for us.
And the same for many other use cases, which you ignorantly choose to take notice of.
Well, if you don't want to use systemd, then don't. As you point out, it might not be needed in your case.
However, most likely whoever maintains your distro isn't going to want to maintain a configuration just for people who don't use containers. It makes more sense from their standpoint to come up with the most general solution possible, and using systemd doesn't really exclude anybody on Linux. So, you may end up having to use more of a niche distro or roll your own, which probably isn't your goal.
Then LP will reject it because it "needs" to be integrated soooo tightly into systemd ;)
So, why do you care what he thinks? Are you not allowed to install software on your computer without LP's signoff?
I can look at the logs and see that they aren't corrupt. Naturally, the filesystem journal ends up replaying each time the machines are shut down rough, but that actually takes care of it.
Well, in that case I would expect it to take care of your journald logs as well.
Systemd is NOT modular where it matters.
Well, that depends on what matters to you. You can use systemd without many of its components. Just not without those. And I'm not really sure why you care if the log traffic is forwarded vs direct.
Why should one lose the ability to view non-corrupted [freedesktop.org] text logs from bootloader just to get an init replacement?
People keep quoting that bug, but it doesn't make it true. In what way does journald corrupt log files any more than any other logger? I think it is just more visible because it can actually detect if a log file wasn't cleanly closed. If you pull the plug on a system running syslog you could end up with truncated log files, but syslog will just happily keep appending to them making the error non-apparent until you try to actually parse the logs programatically.
Journald still reads whatever it can out of a log file - it just doesn't try to interpret half-records.
Need an un-vacinated control group. How about the continent of Africa. Enough people for your test group?
They aren't a control, because they aren't treated the same as the experimental group, and haven't received a dose of placebo.
Can you remove logind and journald from systemd?
About as well as you can remove the preprocessor from gcc. Not every component of systemd is easy to get by without. In the case of journald you can operate it in non-persistent mode, so that it doesn't actually write any logs to disk.
Some systemd components are more essential than others, which is usually the case with modular software. Kde is modular, but good luck deleting kdelibs.
And how often are you going to reap that reward? I just did a quick spot-check of our 1,200+ host local VM farm, and didn't see any hosts with less than 60 days uptime; it would be longer if not for quarterly patch/reboot cycles. You realize that's sort of the entire point, right?
When I run updates on a container I shut it down, snapshot its subvolume, and start it up. That takes a few hundred millseconds with zero impact to anything that depends on it (nothing times out that fast). Why not do it - the reboot costs nothing and gains you a bit more consistency if you have to roll back.
Your sysadmin practices are based on the assumption that reboots result in downtime.
The whole point of the kernel is for it to be in the background.
So is the init.
When I set init=/bin/bash or /bin/tivo, the last thing I want is for it to be in the background. You're just getting stuck on your preconceived notions of how a unix box should work.
Employers NEVER fire people for attending jury duty.
Sure, where you work. Some people are stuck working McJobs and do get penalized if they dare to ask for a day off, even if it is for jury duty. They don't get the chance to put in 30 hours over the weekend so they don't end up homeless at the end of the month.
I think you missed the point. McJobs never fire people for jury duty either. They only fire people for breaking the rules. Of course, everybody breaks the rules since they're impossible to follow, but you only get written up for them if you attend jury duty, or you don't sleep with the boss, or you're the wrong race, etc.
And yes, for many simply being denied the opportunity to work can be devestating.