I'm sure patches to the default file are more than welcome. So, why aren't you contributing? Do you really expect anybody else to be able to do as good a job with it?
The problem with logind is that you do not communicate with it like you communicate with everything else in a UNIXy system. It has an API, which is not fixed, and logind in turn relies on API's to communicate with other parts of systemd.
Well, changing APIs reflects the immaturity of the project more than anything - I suspect it will tend to settle down.
And the plan for Linux is for kdbus to be the preferred way for processes to communicate. That is how just about everything in systemd communicates. Sure, it isn't as elegant as sending one of 32 fixed signals (most of which already have intended uses leading to hacks like using SIGHUP for everything and its uncle) to everything to try to get it to do something, but it works.:)
OpenBSD truly adheres to "KISS", especially regarding simple configuration files. Exactly of what systemd isn't.
Uh, what isn't simple about configuration in systemd?
The article mentions logind. Here is my logind config: [Login] #NAutoVTs=6 #ReserveVT=6 #KillUserProcesses=no #KillOnlyUsers= #KillExcludeUsers=root #InhibitDelayMaxSec=5 HandlePowerKey=ignore HandleSuspendKey=ignore HandleHibernateKey=ignore HandleLidSwitch=ignore #PowerKeyIgnoreInhibited=no #SuspendKeyIgnoreInhibited=no #HibernateKeyIgnoreInhibited=no #LidSwitchIgnoreInhibited=yes #IdleAction=ignore #IdleActionSec=30min #RuntimeDirectorySize=10% #RemoveIPC=yes
Just what about that isn't simple? The defaults are basically how most unix-y systems behave anyway, and you can set things like what happens if a user logs out and leaves some processes behind, what happens if somebody pushes the power button, what happens if the console is idle, etc?
And the functionality of this daemon seems like the definition of "do one thing well." If it didn't have systemd in the filename people would be arguing that "systemd should be more like this."
And if you had a policy where anyone fighting had to exit the craft (parachute optional) then there wouldn't even be fighting.
If you propose on-the-spot executions for people who violate the rules, you'll get the exact opposite of what you intend. What do you think would happen when a flight attendant asked the passenger to get into the newly-installed airlock? Do you imagine that they'll just happily comply?
If you could fit in three bunks (may require rearranging the overhead luggage), it might even save space.
I wonder just how big a space you could use if you made them horizontal. You wouldn't need space between rows - just dividers. Evacuation might be a problem - people would tend to get trampled when everybody tries to de-bunk at the same time.
No. At some point the airlines will start charging the idiots for the cost of diverting the flight (I'd guess it's at least $100,000 by the time you include the costs of moving other passengers to other flights after they're delayed), and then the idiots will stop being idiots.
The idiots just won't pay the bill, and will declare bankruptcy if necessary. I suspect many of them lack significant assets. That is a losing battle for the airlines, and suing your customers isn't all that great for business either. Even if they win they won't get much of it back after costs.
The problem is that if the issue is egregious enough, new complainers will be created at a faster rate than the old ones can get banned. And banned passengers don't buy tickets either, so that is hardly good for revenue.
Locking up people who complain is about as likely to stop complaints as locking up drug users is likely to stop drug use.
Go to SeatGuru.com enter in the flight number and date. Tada!
That only works if your aircraft doesn't change, and it often does.
And an economy plus upgrade usually costs more than $20. At that price I'd take it without thinking, even though I wouldn't get reimbursed for it on business travel. When you have to pay $100 for an extra inch or two, that is quite a premium.
There is law and precedent for the FAA's regulation of aircraft. The 'model', 'drone' or 'unpiloted' distinction is something that hobbyists and the FAA informally agreed upon in order to facilitate the hobby.
The law says that the FAA is allowed to regulate aircraft. The FAA has specifically excluded unmanned aircraft from its regulations so far. That is, there is no law or regulation on the books that pertains to unmanned aircraft.
If that is untrue, you can supply a citation to a single law or regulation which contradicts what I just said above. Please note that I'm not interested in advisory circulars, cease and desist letters, or press releases. I'm interested in laws and regulations - published in accordance with the laws set forth by congress for legislation and rulemaking.
It really sounds like you dont understand the distinction between layer 4 and layer 7. Once you are dealing with URLs, the application no longer cares about "TCP", it cares about generic "connections".
I fully understand that what I just proposed isn't the right way to do things. That is my whole point. You can still pass a law that says that at the IP layer you must search for packets that match some regex and drop them if the destination IP isn't on some whitelist. Obviously that isn't going to work right if packets get fragmented across the search string, but that doesn't mean that legislators can't write a stupid law.
You're missing the point. You're making excellent arguments as to why doing DRM at the wrong layer doesn't make sense. However, all it takes is some money in the right pockets and everybody will have to do it anyway.
If you want to white-list the ability to transmit data and what kinds of data you can transmit, then you could certainly enforce that at a pretty low level. For example, you could enforce at the TCP level that you're only allowed to receive packets on port 80 if your IP appears on the list of licensed webservers. You could even forbid receiving packets that contain "GET" followed by a URL without a permit of some kind. Sure, it would be dumb, but we pay our lawmakers to come up with dumb laws and they do a very good job of it.
If you really want to pay for breakthrough research, you're inevitably going to spend a LOT of money on things that don't pan out. You can't just look at some breakthrough in isolation and say, "those guys discovered foo with only $bar in funding!" You have to look at the other 47 guys that were also given $bar in funding and they came up with nothing.
If you could predict ahead of time whose research was going to pan out, then it wouldn't really be research, and you certainly wouldn't need to use tax dollars to fund it since every venture capitalist in town would already be funding it themselves.
The fellow up above had it correct, do the research first so you can point to it, then ask for funding for it promising some incremental improvements which, if you are on the ball, you've already done but not published, and then use the money to work on your next line of research.
I departed from the academic track back in the 90s, but even back then this was already recognized as the way to get stuff done. Nobody worked on the stuff that was the subject of the grant.
ratings systems are abitrary and error prone (who computes the ratings? is it an algorithm, or some full time secretarial type? Does he/she even have a degree?)
Well, the whole point of ratings systems is that you can have as many of them as you want, each with their own method of operation, and people can choose which ratings they follow.
I mean, who regulates who is allowed to write movie reviews? People tend to try to find the review sources that they believe most reflect what they're looking for, and use them.
I think that the ability to replicate results is far more important than peer review in science, and that tends to be very difficult to do even if you are a peer.
In elementary school, my kids did an independent science fair project every year. They learned to do graphical programming in Scratch. The school had several teams that competed in robotic competitions.
FYI that's not a normal public school.
The problem with public education in the US is that it tends to be locally funded, so you get whatever your neighbors are willing to pay for. If you're into the "why should I have to pay money so that some poor kid in the local city can learn how to read" school of thought, you probably consider that a good thing. Likewise, if you live in the one progressive town in some red state then you probably appreciate not having to stock your science classroom with Bibles.
I work in biomedical research and yes - a lot of money is diverted into research with incremental benefits - me-too drugs.
I don't buy into this line of argument. What you say is obviously true, but the implied argument is that this money is wasted. Every antibiotic since pennicilian is in a sense a me-too drug, but I hear doctors always going on about how we don't invest enough in antibiotics because there isn't a big market for new ones (and it doesn't help that we squander the ones that we have).
You never want just one drug to treat a particular condition. You don't even want one drug that has a particular mechanism to treat a particular condition. The problem is that while only one drug can statistically be the best treatment for a problem, when it comes down to individuals you have a lot of variance. Maybe drug A is the drug with the best outcomes for a condition you have, but you take it and after two days you have hives breaking out everywhere. Drug B might be a me-too drug that doesn't even work as well, but if you can't take drug A without suffocating then drug B is probably a lot better than take some aspirin for the pain until the disease kills you.
Research into me-too drugs is already self-limiting. If somebody comes up with another statin that only works 5% better than the current ones, they'll have very little market - the extra competition will depress prices on all the branded treatments, and the generic ones are already out there and will always be far cheaper.
Also, often the me-too drugs are drugs that were 80% through development when somebody beat them to the market. At that point a company can either just cancel the program and eat the sunk costs, or spend incrementally more to bring the drug to market and at least recover some of those costs. Often the math works out better to move ahead, and patients are better for having an extra option.
remember that big pharma spend more on marketing than on research.
Very true, but that is also true of just about every industry out there. Pharma actually spends a lot more on R&D than most companies do.
I'm all for getting rid of the non-value-add marketing, but that requires a change in consumer behavior. If people stop buying whatever the Hollywood actors tell them to buy, then companies will stop paying those actors to hawk their products.
Thanks. I'm not very familiar with the original FreeBSD ports implementation. If it is menu-driven I'd think that the obvious limitations would be:
1. No way to just set a flag once at the system level and have it apply to many packages automatically. With Gentoo I could switch a flag at the system level and have it rebuild everything in one operation that is affected by the change.
2. No way to express dependencies on how a package is configured. With Gentoo package A can depend on package B being configured in a particular way. Then when you install A the system will automatically propose reconfiguring B for you. For example, the initramfs builder dracut requires that kmod be configured with --enable-tools.
Source-based distros aren't everybody's cup of tea, but there are quite a few things that Gentoo does to automate things like this which you will be very hard-pressed to find elsewhere.
From what I understand, FreeBSD Ports does not support USE flags
You can set global compiler options so it's almost the same thing, at least if you are compiling for specific hardware with some processor extensions but not others somewhere between the usual defaults.
USE flags are less about CFLAGS/LDFLAGS, and more about compiling kde without baloo support, or building openssh with or without the high-performance patches, or building openssl with or without tls heartbeat support. Many upstream packages have behavior that is modifiable at compile time. Doing so might eliminate dependencies, or perhaps it changes behavior that isn't otherwise configurable.
On Gentoo every package has its defaults, and then there are profiles like desktop/minimal/etc that have their own layer of defaults, and then everything is user-overridable either globally or per-package. I can disable SSL support system-wide and install just about any of the usual daemons without having either openssl or gnutls on my system. It can be especially useful for embedded systems, but there are other things it can be useful for as well.
I was simply stating that this was how things would be done, not that it is good public policy.
The thing is, just about every country pulls these kinds of stunts. If some German citizen living in Germany hosted a server in the USA and used it to sell Nazi paraphernalia, US law would protect the data, but I imagine that the German government would still stick the owner in jail until they divulged it.
I'm not saying it is right - it is just that most governments aren't too happy about not asserting their will on people/companies they can get at.
Sure, the CPU has a temperature sensor, but how precise is it? And how much power does that CPU consume to do the job, vs a dedicated machine? And how long will the test take - I can't see a CPU dropping from 90C to 45C in nearly the same time as a thermocycler that uses peltier cooling backed by variable speed fans.
The CPU temperature sensor is also in the CPU core, not at whatever point in the heatsink the sample is placed at. This would probably make a difference as well.
If it really saved $19k it might be worth it, but the current DIY thermocycler I referenced is $600. I bet that could be improved on if you wanted to make compromises, and I imagine you could still make it better/cheaper than doing it with a CPU.
It doesn't use TPM or anything like that. I fully agree that it would buy you something if it did, but I'd still want a way to export my credentials. If I want to have more than one two-factor device, why shouldn't I? I have more than one set of car keys, and I fully appreciate that either could be used to steal my car.
I'd think this might also be useful for taking out modern SAM systems. Look how worried the US was about a few potential SA-10s in Syria. Those sites aren't that easy to take out - they are VERY capable.
People talk about that exercise as if it was rigged, but the point of the exercise wasn't just to figure out who won, but also to, well, be an exercise.
If one side wins in 3 hours and you booked a week for the exercise spending millions of dollars to have everybody there, it seems a bit silly to just send everybody home.
But, not learning something from the initial lesson would be foolish indeed. The problem is that we don't fight enough World War IIIs to know if carriers won't have some kind of usefulness. We do know that they are very useful when pushing around minor powers, because they reduce the need to have a local airbase as long as there is a body of water nearby. Whether they are useful against somebody like China remains to be seen. To destroy a carrier you would need to know where it is, and that isn't a guarantee in wartime. Nobody will have satellite technology during a major war - satellites are too vulnerable and after they are all destroyed you won't be able to put anything up for a century or two unless it is wrapped in a foot of titanium.
Not necessarily. The point of containers is to do this stuff in the kernel so that your box doesn't have to run 10 kernels, with 10 sets of disk caches, and 10 sets of extra ram so that the OOM killer doesn't get triggered 3 times per day, etc. You can get rid of a lot of overhead with containers, and allow resource allocation to be much more dynamic.
However, the problem is that the security isn't 100% there. It is fine for hosting 10 of your own services in containers when you could otherwise safely run them all as traditional services on a single box. It is completely inadequate for something like VPS where you can't trust that nobody will be hacking into the rest of the box.
Yeah, but that Google authenticator app is a two-edged sword. I just upgraded my android phone the other day and realized that I lost all my two-factor credentials. Granted, I could have created new ones, but it was easier to do a TitaniumBackup restore of the application (which otherwise does not let you export your credentials - I get the security implications but it isn't like the credentials aren't copyable anyway and I'd rather have a backup).
Slashdot Mirror
I'm sure patches to the default file are more than welcome. So, why aren't you contributing? Do you really expect anybody else to be able to do as good a job with it?
The problem with logind is that you do not communicate with it like you communicate with everything else in a UNIXy system. It has an API, which is not fixed, and logind in turn relies on API's to communicate with other parts of systemd.
Well, changing APIs reflects the immaturity of the project more than anything - I suspect it will tend to settle down.
And the plan for Linux is for kdbus to be the preferred way for processes to communicate. That is how just about everything in systemd communicates. Sure, it isn't as elegant as sending one of 32 fixed signals (most of which already have intended uses leading to hacks like using SIGHUP for everything and its uncle) to everything to try to get it to do something, but it works. :)
OpenBSD truly adheres to "KISS", especially regarding simple configuration files. Exactly of what systemd isn't.
Uh, what isn't simple about configuration in systemd?
The article mentions logind. Here is my logind config:
[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
HandlePowerKey=ignore
HandleSuspendKey=ignore
HandleHibernateKey=ignore
HandleLidSwitch=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10%
#RemoveIPC=yes
Just what about that isn't simple? The defaults are basically how most unix-y systems behave anyway, and you can set things like what happens if a user logs out and leaves some processes behind, what happens if somebody pushes the power button, what happens if the console is idle, etc?
And the functionality of this daemon seems like the definition of "do one thing well." If it didn't have systemd in the filename people would be arguing that "systemd should be more like this."
And if you had a policy where anyone fighting had to exit the craft (parachute optional) then there wouldn't even be fighting.
If you propose on-the-spot executions for people who violate the rules, you'll get the exact opposite of what you intend. What do you think would happen when a flight attendant asked the passenger to get into the newly-installed airlock? Do you imagine that they'll just happily comply?
If you could fit in three bunks (may require rearranging the overhead luggage), it might even save space.
I wonder just how big a space you could use if you made them horizontal. You wouldn't need space between rows - just dividers. Evacuation might be a problem - people would tend to get trampled when everybody tries to de-bunk at the same time.
No. At some point the airlines will start charging the idiots for the cost of diverting the flight (I'd guess it's at least $100,000 by the time you include the costs of moving other passengers to other flights after they're delayed), and then the idiots will stop being idiots.
The idiots just won't pay the bill, and will declare bankruptcy if necessary. I suspect many of them lack significant assets. That is a losing battle for the airlines, and suing your customers isn't all that great for business either. Even if they win they won't get much of it back after costs.
The problem is that if the issue is egregious enough, new complainers will be created at a faster rate than the old ones can get banned. And banned passengers don't buy tickets either, so that is hardly good for revenue.
Locking up people who complain is about as likely to stop complaints as locking up drug users is likely to stop drug use.
Go to SeatGuru.com enter in the flight number and date. Tada!
That only works if your aircraft doesn't change, and it often does.
And an economy plus upgrade usually costs more than $20. At that price I'd take it without thinking, even though I wouldn't get reimbursed for it on business travel. When you have to pay $100 for an extra inch or two, that is quite a premium.
There is law and precedent for the FAA's regulation of aircraft. The 'model', 'drone' or 'unpiloted' distinction is something that hobbyists and the FAA informally agreed upon in order to facilitate the hobby.
The law says that the FAA is allowed to regulate aircraft. The FAA has specifically excluded unmanned aircraft from its regulations so far. That is, there is no law or regulation on the books that pertains to unmanned aircraft.
If that is untrue, you can supply a citation to a single law or regulation which contradicts what I just said above. Please note that I'm not interested in advisory circulars, cease and desist letters, or press releases. I'm interested in laws and regulations - published in accordance with the laws set forth by congress for legislation and rulemaking.
It really sounds like you dont understand the distinction between layer 4 and layer 7. Once you are dealing with URLs, the application no longer cares about "TCP", it cares about generic "connections".
I fully understand that what I just proposed isn't the right way to do things. That is my whole point. You can still pass a law that says that at the IP layer you must search for packets that match some regex and drop them if the destination IP isn't on some whitelist. Obviously that isn't going to work right if packets get fragmented across the search string, but that doesn't mean that legislators can't write a stupid law.
Congress does not legislate OSI.
No, they tend to focus more on the tubes.
You're missing the point. You're making excellent arguments as to why doing DRM at the wrong layer doesn't make sense. However, all it takes is some money in the right pockets and everybody will have to do it anyway.
If you want to white-list the ability to transmit data and what kinds of data you can transmit, then you could certainly enforce that at a pretty low level. For example, you could enforce at the TCP level that you're only allowed to receive packets on port 80 if your IP appears on the list of licensed webservers. You could even forbid receiving packets that contain "GET" followed by a URL without a permit of some kind. Sure, it would be dumb, but we pay our lawmakers to come up with dumb laws and they do a very good job of it.
ITT people dont understand the OSI model.
Layer 4 vs layer 6: who can tell me where DRM, and NDN, would fall?
Wherever Congress legislates that it will fall, or maybe it will be up to a Judge to decide.
DRM is just a technical solution to a legal problem, and legal requirements are not written by computer scientists.
Well said.
If you really want to pay for breakthrough research, you're inevitably going to spend a LOT of money on things that don't pan out. You can't just look at some breakthrough in isolation and say, "those guys discovered foo with only $bar in funding!" You have to look at the other 47 guys that were also given $bar in funding and they came up with nothing.
If you could predict ahead of time whose research was going to pan out, then it wouldn't really be research, and you certainly wouldn't need to use tax dollars to fund it since every venture capitalist in town would already be funding it themselves.
The fellow up above had it correct, do the research first so you can point to it, then ask for funding for it promising some incremental improvements which, if you are on the ball, you've already done but not published, and then use the money to work on your next line of research.
I departed from the academic track back in the 90s, but even back then this was already recognized as the way to get stuff done. Nobody worked on the stuff that was the subject of the grant.
ratings systems are abitrary and error prone (who computes the ratings? is it an algorithm, or some full time secretarial type? Does he/she even have a degree?)
Well, the whole point of ratings systems is that you can have as many of them as you want, each with their own method of operation, and people can choose which ratings they follow.
I mean, who regulates who is allowed to write movie reviews? People tend to try to find the review sources that they believe most reflect what they're looking for, and use them.
I think that the ability to replicate results is far more important than peer review in science, and that tends to be very difficult to do even if you are a peer.
In elementary school, my kids did an independent science fair project every year. They learned to do graphical programming in Scratch. The school had several teams that competed in robotic competitions.
FYI that's not a normal public school.
The problem with public education in the US is that it tends to be locally funded, so you get whatever your neighbors are willing to pay for. If you're into the "why should I have to pay money so that some poor kid in the local city can learn how to read" school of thought, you probably consider that a good thing. Likewise, if you live in the one progressive town in some red state then you probably appreciate not having to stock your science classroom with Bibles.
On the whole, though, I think it hurts us.
I work in biomedical research and yes - a lot of money is diverted into research with incremental benefits - me-too drugs.
I don't buy into this line of argument. What you say is obviously true, but the implied argument is that this money is wasted. Every antibiotic since pennicilian is in a sense a me-too drug, but I hear doctors always going on about how we don't invest enough in antibiotics because there isn't a big market for new ones (and it doesn't help that we squander the ones that we have).
You never want just one drug to treat a particular condition. You don't even want one drug that has a particular mechanism to treat a particular condition. The problem is that while only one drug can statistically be the best treatment for a problem, when it comes down to individuals you have a lot of variance. Maybe drug A is the drug with the best outcomes for a condition you have, but you take it and after two days you have hives breaking out everywhere. Drug B might be a me-too drug that doesn't even work as well, but if you can't take drug A without suffocating then drug B is probably a lot better than take some aspirin for the pain until the disease kills you.
Research into me-too drugs is already self-limiting. If somebody comes up with another statin that only works 5% better than the current ones, they'll have very little market - the extra competition will depress prices on all the branded treatments, and the generic ones are already out there and will always be far cheaper.
Also, often the me-too drugs are drugs that were 80% through development when somebody beat them to the market. At that point a company can either just cancel the program and eat the sunk costs, or spend incrementally more to bring the drug to market and at least recover some of those costs. Often the math works out better to move ahead, and patients are better for having an extra option.
remember that big pharma spend more on marketing than on research.
Very true, but that is also true of just about every industry out there. Pharma actually spends a lot more on R&D than most companies do.
I'm all for getting rid of the non-value-add marketing, but that requires a change in consumer behavior. If people stop buying whatever the Hollywood actors tell them to buy, then companies will stop paying those actors to hawk their products.
Thanks. I'm not very familiar with the original FreeBSD ports implementation. If it is menu-driven I'd think that the obvious limitations would be:
1. No way to just set a flag once at the system level and have it apply to many packages automatically. With Gentoo I could switch a flag at the system level and have it rebuild everything in one operation that is affected by the change.
2. No way to express dependencies on how a package is configured. With Gentoo package A can depend on package B being configured in a particular way. Then when you install A the system will automatically propose reconfiguring B for you. For example, the initramfs builder dracut requires that kmod be configured with --enable-tools.
Source-based distros aren't everybody's cup of tea, but there are quite a few things that Gentoo does to automate things like this which you will be very hard-pressed to find elsewhere.
You can set global compiler options so it's almost the same thing, at least if you are compiling for specific hardware with some processor extensions but not others somewhere between the usual defaults.
USE flags are less about CFLAGS/LDFLAGS, and more about compiling kde without baloo support, or building openssh with or without the high-performance patches, or building openssl with or without tls heartbeat support. Many upstream packages have behavior that is modifiable at compile time. Doing so might eliminate dependencies, or perhaps it changes behavior that isn't otherwise configurable.
On Gentoo every package has its defaults, and then there are profiles like desktop/minimal/etc that have their own layer of defaults, and then everything is user-overridable either globally or per-package. I can disable SSL support system-wide and install just about any of the usual daemons without having either openssl or gnutls on my system. It can be especially useful for embedded systems, but there are other things it can be useful for as well.
I was simply stating that this was how things would be done, not that it is good public policy.
The thing is, just about every country pulls these kinds of stunts. If some German citizen living in Germany hosted a server in the USA and used it to sell Nazi paraphernalia, US law would protect the data, but I imagine that the German government would still stick the owner in jail until they divulged it.
I'm not saying it is right - it is just that most governments aren't too happy about not asserting their will on people/companies they can get at.
Sure, the CPU has a temperature sensor, but how precise is it? And how much power does that CPU consume to do the job, vs a dedicated machine? And how long will the test take - I can't see a CPU dropping from 90C to 45C in nearly the same time as a thermocycler that uses peltier cooling backed by variable speed fans.
The CPU temperature sensor is also in the CPU core, not at whatever point in the heatsink the sample is placed at. This would probably make a difference as well.
If it really saved $19k it might be worth it, but the current DIY thermocycler I referenced is $600. I bet that could be improved on if you wanted to make compromises, and I imagine you could still make it better/cheaper than doing it with a CPU.
It doesn't use TPM or anything like that. I fully agree that it would buy you something if it did, but I'd still want a way to export my credentials. If I want to have more than one two-factor device, why shouldn't I? I have more than one set of car keys, and I fully appreciate that either could be used to steal my car.
I'd think this might also be useful for taking out modern SAM systems. Look how worried the US was about a few potential SA-10s in Syria. Those sites aren't that easy to take out - they are VERY capable.
People talk about that exercise as if it was rigged, but the point of the exercise wasn't just to figure out who won, but also to, well, be an exercise.
If one side wins in 3 hours and you booked a week for the exercise spending millions of dollars to have everybody there, it seems a bit silly to just send everybody home.
But, not learning something from the initial lesson would be foolish indeed. The problem is that we don't fight enough World War IIIs to know if carriers won't have some kind of usefulness. We do know that they are very useful when pushing around minor powers, because they reduce the need to have a local airbase as long as there is a body of water nearby. Whether they are useful against somebody like China remains to be seen. To destroy a carrier you would need to know where it is, and that isn't a guarantee in wartime. Nobody will have satellite technology during a major war - satellites are too vulnerable and after they are all destroyed you won't be able to put anything up for a century or two unless it is wrapped in a foot of titanium.
Not necessarily. The point of containers is to do this stuff in the kernel so that your box doesn't have to run 10 kernels, with 10 sets of disk caches, and 10 sets of extra ram so that the OOM killer doesn't get triggered 3 times per day, etc. You can get rid of a lot of overhead with containers, and allow resource allocation to be much more dynamic.
However, the problem is that the security isn't 100% there. It is fine for hosting 10 of your own services in containers when you could otherwise safely run them all as traditional services on a single box. It is completely inadequate for something like VPS where you can't trust that nobody will be hacking into the rest of the box.
Yeah, but that Google authenticator app is a two-edged sword. I just upgraded my android phone the other day and realized that I lost all my two-factor credentials. Granted, I could have created new ones, but it was easier to do a TitaniumBackup restore of the application (which otherwise does not let you export your credentials - I get the security implications but it isn't like the credentials aren't copyable anyway and I'd rather have a backup).