I don't see corruptions in embedded devices that are usually shut off by unplugging them. I don't see the corruptions after punching the reset button. It seems journald is much more susceptible to corrupting the logs.
Is it that, or is it just that journald actually reports when it finds an incomplete log file? I've never had DOS complain about an uncleanly mounted FAT filesystem, after all, and it might have something to do with the fact that FAT doesn't even have a way of marking itself as dirty.:)
You do realize that nobody runs servers on bare metal these days, right?
I'll grant you that print servers and web servers tend to be on VMs these days, but the VM host OS has to run on bare metal, and if you're doing number crunching or large data storage, it's going to be bare metal too, because the VM host/guest overhead is a waste of resources.
Then you'll be happy that systemd ensures that your host and container service managers and loggers are well-integrated.:)
And containers have very little overhead. They are just processes.
Just what kind of corruption have you experienced in journald? It appends records sequentially to log files, the same as any text logger. If you kill your syslog abruptly do you complain if the last line of the file is cut off midstream and doesn't contain a newline? If so, do you have utilities to recover the data that wasn't written?
As far as I can tell journald just appends to its file, and regurgitates the data which is valid on reboot. If the file was truncated, it starts a new file, but doesn't discard any valid data from the old one. That is pretty-much how every database/filesystem/etc works - accept completed writes, roll back incomplete journal entries.
While the idea of moving VT out of kernel into userspace may be sound, anyone sane have to scream NOOOO upon learning it will be Lennart doing the implementation.
It isn't like there is some dictator who makes these decisions. Whoever writes the code is the one who gets to implement it, and it isn't actually Lennart in this case. Sure, the guy who wrote the code decided to work with him, but that is his choice.
If you don't like the choice, go write your own code, and you can make it refuse to run if PID1=systemd if you want to.:)
Well, you already have journald to capture all the stdout of your services, so why not have a standard way of attaching a console to them? Ditto for containers, which systemd-nspawn can launch.
Something like this has the potential to replace something like tmux. Imagine if every process that has a console is something that you can attach/detach at will, redirect to other processes, etc.
I can definitely see some rationale for close integration.
Thirty seconds every six months on a system where the motherboard BIOS POST, each NIC firmware, the SCSI card firmware, spinning up the drives, and the RAID bios take around two to three minutes to complete.
You mean thirty seconds on a container that otherwise starts up in half a millisecond? You do realize that nobody runs servers on bare metal these days, right?
A fully functional Systemd has about 69 or so binaries. That's hardly monolithic.
It is when they're all tied together so tightly that you're forced to take all or nothing.
Really? I'm certainly not using every systemd binary on every one of my systems, and the others work just fine. Do you have an example of a case where there is unnecessary inter-dependence?
Journald is failing by corrupting the log in the first place. It is the writer, it is in control of that. It fails at that.
My old text based log files on a small group of servers and a number of desktop machines contain no corruptions in the log files at all.
If your text-based log files do not contain corruptions, then journald would not be expected to create corruptions under the same conditions.
The only reason you end up with corruption is if there is an ungraceful shutdown, and that will corrupt text-based logs.
The only way to prevent this sort of situation is to use full data journaling on your logging solution, which no syslog I'm aware of implements, but most RDBMS do. If you use something like syslog-ng and you pull the plug in the middle of operations, you could end up with a truncated log entry.
I don't dispute that journald can create invalid log entries. I am just saying that it is no different from all the alternatives in this regard. If I did want to create a system log that had full data journaling I'd certainly prefer to implement it using a binary file format!
For that matter, they could make it illegal to cut your hours or fire you if you have jury duty AND enforce it.
Employers NEVER fire people for attending jury duty. They are given all the time they need, and then they are expected to get all their work done on the dates that were assigned before they left for jury duty, doing whatever is necessary to get the job done.
At my workplace I can basically take a day off anytime I like. The consequences come when I either don't get stuff done on time, or I end up working 30 hours every weekend to catch up.
This sort of thing is almost impossible to enforce. It is no different from many other forms of discrimination/etc - employers have learned how to make every separation a matter of either business needs or performance. If you're part of some kind of legally protected class and the statistics don't work out, then there can be a case. Still, if you get one discriminating boss then that often doesn't work because in the aggregate HR will usually just make sure that the next mass-layoff makes the numbers even out.
That is not helped at all by the attitude of the courts. Don't have transportation? Too bad. Parking costs more than the 'expenses' check that was adequate in 1960? Too bad. Can't afford to take time off? Too bad. Won't have a job when it's over? Too bad. Single parent and the babysitter died in the living room? Too bad. Work the night shift? Too bad, be here at 8:00 A.M.
No wonder people resent it.
Nonsense. The courts are very understanding about real-life demands.
When I was on jury duty a man stood up and said that he had to prepare for a trial that was scheduled for the following week. The judge asked if he was an attorney, and when he said yes he was immediately excused.
And if somebody in the court wastes a lot of time, the attorneys on the other side can argue that this has cost them lost time and ask for reimbursement for this.
Oh wait, you aren't an attorney? Yeah, your time is basically worth $0/hr.
Trifles such as proper evidence gathering, transfer, and storage techniques, lab accreditation, quality of the specimen, etc. are assumed to be ultra high-tech. I think most people would be horrified at how many lapses actually occur.
Do you mean that in real life when the boyfriend of somebody in the crime lab is suspected of a crime they don't assign the case to the person who is personally involved with them? How, undramatic that must be!
Agree. I suspect the issue isn't that they'd drive boats up with explosives so much that they would be able to get close enough to fire a missile from a short enough range that it couldn't be intercepted. The minimum engagement range of an AA missile has to be larger than an anti-ship missile, if for no other reason than the latter can be pointed at the ship while the former is often launched vertically, which means it has to follow a curved arc before the target is in front of the seeker. You also can't fire the AA missile until AFTER the anti-ship missile is fired, which means that even if you launch from a launcher capable of pointing at the target the launcher still has to be turned towards it since until the launch you don't know which of the 47 incoming boats to point it at.
I don't think hundreds of boats loaded with explosives could actually get in close enough. Certainly the WWII defense would stop that, and I imagine that even a single radar-controlled cannon on a small warship could sink quite a few small boats at the edge of visual range. Nobody is going to be driving a zodiac into a hail of 50 cal either. I'd also question whether you could really find that many people determined to mount a suicide attack at once. Sure, you'd get lots of people claiming that they would do it, but when you give the order to go how many would take that patrol boat and head for someplace where they'd escape prosecution?
So your eyeballs are really blind to "This significantly increases probability of corruption". How pathetic.
I read it. I just don't see how journald is any more susceptible to corruption than a text log.
You stated that they are susceptible "due to not having any transaction consistency, as an RDBMS would." That is certainly true, but it is also true of a text-based log. You're saying that because B is better than A, we should definitely go with C.
So the solution was triple the number of guns on the ship so that there was such a withering volley of fire coming out of the boat that not even a kamikaze could get through....As a result of that... if the Iranians tried this tactic on such a ship they'd all be annihilated. A modern carrier group with a swarm of drones around it might be able to fight off such an attack as well. It might be cheaper to just put WW2 close defense guns on our ships. But no one is gong to do that... it isn't futury enough for them.
Uh, I think you misunderstand the tactic. This isn't about kamikaze attacks where the explosives are on the boats - they probably couldn't get close enough to do anything unless there were thousands of boats to attack a single ship, since the ships do have 50 cal machine guns and often radar-controlled cannons.
The tactic is to swarm a target with boats, with some of those boats carrying anti-ship missiles. The boats don't need to get within range of small arms and cannons. They can't afford to equip EVERY boat with a missile. So, they send in 200 boats, and 3 of them have anti-ship missiles with something like a 10-mile range. If you sink 90 of those boats, chances are that 1-2 with missiles are still intact, and when they get within 10 miles they can fire a missile at you.
The tactic works because they force you to engage many targets with sophisticated long-range weapons, while only needing to invest in equipping a few of them with similar weapons. They have to buy 3 exocets, and we have to launch 250 harpoons to be likely to take them out.
Since you have abandoned the idea of either side painting the middle as extremists (you didn't stick to the point that "additionally anyone who wishes for abortion to remain legal for incest-rape is pro-murder - you should be bound, by law, to carry your child/nephew to term", or other statements that show either side can force any moderate opinion to an extreme one)
You're going to have to re-state that, as I am not sure what you're trying to say. You seem to be putting words in my mouth.
I really didn't intend to comment at all on whether either side paints the middle as extremists at all.
I didn't say "additionally anyone who wishes for abortion to remain legal for incest-rape is pro-murder - you should be bound, by law, to carry your child/nephew to term" so I'm not quite sure why it is in quotes.
I'm not necessarily disagreeing with you. I'm just honestly not quite sure what you're trying to express.
I'd note that the anti-abortion group is decidedly pro-murder
Uh, what does being against abortion have to do with being for murder? I'm not sure how this follows.
What's more pre-meditated killing of a human than the death penalty?
So, there are a few problems here:
1. First, you can be anti-abortion and also be anti-death-penalty. Many aren't, but they are really different issues. 2. You've basically defined "murder" as "the premeditated killing of a human." I doubt most will accept that definition. If we were to accept that definition, then murder isn't a crime, abortion is murder, many consider murder morally acceptable, etc. I'm not usually big on arguing over definitions, but this was not what I meant when I used the term.
But then, that's another way that the moderate get painted as radicals. If you aren't absolute on every statement, then they paint you as being non-committal to anything/everything.
No argument there, and that was certainly not my intent.
My point was simply that the reason the "anti-abortion" crowd tends to also be "anti-choice" is that they consider abortion to be murder, and as a result people can't be offered a choice. Most people would not say that a person has a right to choose to kill their adult neighbor without their consent. Many would actually say that a person doesn't even have the right to kill themselves, though this is far more controversial.
Whether abortion is murder is certainly something that can be debated. There is no question that abortion is pre-meditated killing. Looking at an ant and stepping on it is pre-meditated killing. Whether it is the killing of a human is just a matter of your definition of a human. However, murder usually involves more than just the pre-meditated killing of a human. For example, we generally do not use the term murder to describe the actions of a firing squad, a police officer firing on a hostage taker, or a military operation, but all of those can involve the pre-meditated killing of a human.
Both the US and Russians have destroyed satellites recently in demonstrations. In the Russian case they did it in a manner that created quite a bit of long-lasting debris. Nobody really wants to brag about this capability, but shooting down a satellite isn't really all that different from shooting down a high-altitude plane - the velocities are just much higher.
Whether the Chinese could pull it off right now is uncertain. The US clearly has the capability, and in an actual serious war they would certainly consider the pros and cons of destroying all satellites operated by anybody who might provide data to an enemy (including commercial operators who don't cooperate - but they will since they make more money with half the customers than with none of the customers and you can't really be neutral in a major war). I think the main US consideration would be losses to their own and allies satellite network due to debris, etc.
Of course, nobody is going to start shooting down satellites unless we're talking about a serious war - that is one where most likely tens of thousands to millions of people will die.
At this point systemd is about as well-supported on Gentoo as the default openrc, and there is open discussion on the lists about removing the default entirely so that there is no default, just as there is no default bootloader or kernel. The whole point of Gentoo is that you get to run what you want to run, more or less. Of course, not all configuration permutations are equally supportable.
You do not acknowledge the abuse of the Debian Community process? Or the fact that Debian is Upstream of 5 or 7 principal distros?
The fact is that virtually every distro has chosen to adopt systemd. The only one not adopting it that I'm aware of is Slackware. Gentoo isn't going to make it a default, but seems likely to drop their existing default. Of course, the #1 Gentoo derivative runs Upstart, so it will be interesting to see where it goes (hint, more systems run Upstart on a Gentoo derivative than on Ubuntu).
Sure, Debian's choice led to many derivative distros going along with it, but there have been many independent decisions to adopt it.
As far as the Debian community process goes - I only followed that tangentially, not being a part of the Debian community. I think I might have one VM somewhere running it that I fire up once a year. You'll have to ask a Debian lawyer whether their process was followed - there seemed to have been a lot of those types on that thread.
Why not stuff yourself into PID 1 and execute yourself?
At least we're getting back to the main topic - the FOSS community is full of assholes.
Under what situations would device encryption be useful without a screen lock? Your phone data can be read by anyone who gets their hands on it, since the unencrypted data is exposed to anyone who swipes right...
Simple - you keep the phone on your person, and turn it off when you leave it in an unsafe place. You still want to turn off the screen so that your battery isn't wasted, but you don't need locking. You can power off when leaving the phone unattended, giving you the device lock.
I can't think of any good reason that your screen lock password should be weaker than your device password...
Your device password should be difficult for a machine to crack, since it is designed to protect against direct access of the flash hardware. That means it needs a strong password. The machine gets an unlimited number of attempts to guess it, likely measured in many attacks per second if you have lots of rounds, or millions of attacks per second if not.
Your screen password needs to be able to be entered while you're driving in case your screen locks while you're using your GPS. That means it needs to be trivial in length. That isn't a problem, because the software can throttle entry attempts, or even shut-down the device (thus falling back to the device password) after a few failed attempts.
Screen locks and device encryption keys serve two different purposes, even if people often conflate them. They have different threat models and different ways of mitigating against them.
Now, a compromise would be a hard key stored in a TPM with an easy PIN used to access it. The TPM would permanently forget the key after a few failed attempts. However, Android does not do things this way. This would still let you have an easy PIN on boot-up without requiring a screen lock.
Slashdot Mirror
I don't see corruptions in embedded devices that are usually shut off by unplugging them. I don't see the corruptions after punching the reset button. It seems journald is much more susceptible to corrupting the logs.
Is it that, or is it just that journald actually reports when it finds an incomplete log file? I've never had DOS complain about an uncleanly mounted FAT filesystem, after all, and it might have something to do with the fact that FAT doesn't even have a way of marking itself as dirty. :)
You do realize that nobody runs servers on bare metal these days, right?
I'll grant you that print servers and web servers tend to be on VMs these days, but the VM host OS has to run on bare metal, and if you're doing number crunching or large data storage, it's going to be bare metal too, because the VM host/guest overhead is a waste of resources.
Then you'll be happy that systemd ensures that your host and container service managers and loggers are well-integrated. :)
And containers have very little overhead. They are just processes.
I can see the benefits of course. Doesn't mean it shouldn't be modular.
Well, what are you waiting for? Go make it modular then! :)
Just what kind of corruption have you experienced in journald? It appends records sequentially to log files, the same as any text logger. If you kill your syslog abruptly do you complain if the last line of the file is cut off midstream and doesn't contain a newline? If so, do you have utilities to recover the data that wasn't written?
As far as I can tell journald just appends to its file, and regurgitates the data which is valid on reboot. If the file was truncated, it starts a new file, but doesn't discard any valid data from the old one. That is pretty-much how every database/filesystem/etc works - accept completed writes, roll back incomplete journal entries.
Why not? Systemd can spawn containers and manage their services and networks. Why not have it manage their consoles as well?
You're more than welcome to merge consoled into your word processor to if you want to - it is open source.
While the idea of moving VT out of kernel into userspace may be sound, anyone sane have to scream NOOOO upon learning it will be Lennart doing the implementation.
It isn't like there is some dictator who makes these decisions. Whoever writes the code is the one who gets to implement it, and it isn't actually Lennart in this case. Sure, the guy who wrote the code decided to work with him, but that is his choice.
If you don't like the choice, go write your own code, and you can make it refuse to run if PID1=systemd if you want to. :)
Well, you already have journald to capture all the stdout of your services, so why not have a standard way of attaching a console to them? Ditto for containers, which systemd-nspawn can launch.
Something like this has the potential to replace something like tmux. Imagine if every process that has a console is something that you can attach/detach at will, redirect to other processes, etc.
I can definitely see some rationale for close integration.
My response is this: Why is this not just its own thing? Why does it have to be apart of systemd?
Because you didn't write it that way. In fact, you didn't write it at all.
Thirty seconds every six months on a system where the motherboard BIOS POST, each NIC firmware, the SCSI card firmware, spinning up the drives, and the RAID bios take around two to three minutes to complete.
You mean thirty seconds on a container that otherwise starts up in half a millisecond? You do realize that nobody runs servers on bare metal these days, right?
Those who are using Linux on server side, it seems to solve a problem that doesn't exist.
Yeah, I can't imagine why people administering a server would need to have access to a console without walking up to the keyboard... :)
When your startup manager becomes more important than the kernel, you might want to rethink your design philosophy.
Uh, you do realize that Debian on FreeBSD resembles Debian on Linux a lot more than Debian on Linux resembles Tivo on Linux, right?
The whole point of the kernel is for it to be in the background. Userspace defines the user experience almost entirely.
A fully functional Systemd has about 69 or so binaries. That's hardly monolithic.
It is when they're all tied together so tightly that you're forced to take all or nothing.
Really? I'm certainly not using every systemd binary on every one of my systems, and the others work just fine. Do you have an example of a case where there is unnecessary inter-dependence?
Journald is failing by corrupting the log in the first place. It is the writer, it is in control of that. It fails at that.
My old text based log files on a small group of servers and a number of desktop machines contain no corruptions in the log files at all.
If your text-based log files do not contain corruptions, then journald would not be expected to create corruptions under the same conditions.
The only reason you end up with corruption is if there is an ungraceful shutdown, and that will corrupt text-based logs.
The only way to prevent this sort of situation is to use full data journaling on your logging solution, which no syslog I'm aware of implements, but most RDBMS do. If you use something like syslog-ng and you pull the plug in the middle of operations, you could end up with a truncated log entry.
I don't dispute that journald can create invalid log entries. I am just saying that it is no different from all the alternatives in this regard. If I did want to create a system log that had full data journaling I'd certainly prefer to implement it using a binary file format!
For that matter, they could make it illegal to cut your hours or fire you if you have jury duty AND enforce it.
Employers NEVER fire people for attending jury duty. They are given all the time they need, and then they are expected to get all their work done on the dates that were assigned before they left for jury duty, doing whatever is necessary to get the job done.
At my workplace I can basically take a day off anytime I like. The consequences come when I either don't get stuff done on time, or I end up working 30 hours every weekend to catch up.
This sort of thing is almost impossible to enforce. It is no different from many other forms of discrimination/etc - employers have learned how to make every separation a matter of either business needs or performance. If you're part of some kind of legally protected class and the statistics don't work out, then there can be a case. Still, if you get one discriminating boss then that often doesn't work because in the aggregate HR will usually just make sure that the next mass-layoff makes the numbers even out.
That is not helped at all by the attitude of the courts. Don't have transportation? Too bad. Parking costs more than the 'expenses' check that was adequate in 1960? Too bad. Can't afford to take time off? Too bad. Won't have a job when it's over? Too bad. Single parent and the babysitter died in the living room? Too bad. Work the night shift? Too bad, be here at 8:00 A.M.
No wonder people resent it.
Nonsense. The courts are very understanding about real-life demands.
When I was on jury duty a man stood up and said that he had to prepare for a trial that was scheduled for the following week. The judge asked if he was an attorney, and when he said yes he was immediately excused.
And if somebody in the court wastes a lot of time, the attorneys on the other side can argue that this has cost them lost time and ask for reimbursement for this.
Oh wait, you aren't an attorney? Yeah, your time is basically worth $0/hr.
Trifles such as proper evidence gathering, transfer, and storage techniques, lab accreditation, quality of the specimen, etc. are assumed to be ultra high-tech. I think most people would be horrified at how many lapses actually occur.
Do you mean that in real life when the boyfriend of somebody in the crime lab is suspected of a crime they don't assign the case to the person who is personally involved with them? How, undramatic that must be!
Agree. I suspect the issue isn't that they'd drive boats up with explosives so much that they would be able to get close enough to fire a missile from a short enough range that it couldn't be intercepted. The minimum engagement range of an AA missile has to be larger than an anti-ship missile, if for no other reason than the latter can be pointed at the ship while the former is often launched vertically, which means it has to follow a curved arc before the target is in front of the seeker. You also can't fire the AA missile until AFTER the anti-ship missile is fired, which means that even if you launch from a launcher capable of pointing at the target the launcher still has to be turned towards it since until the launch you don't know which of the 47 incoming boats to point it at.
I don't think hundreds of boats loaded with explosives could actually get in close enough. Certainly the WWII defense would stop that, and I imagine that even a single radar-controlled cannon on a small warship could sink quite a few small boats at the edge of visual range. Nobody is going to be driving a zodiac into a hail of 50 cal either. I'd also question whether you could really find that many people determined to mount a suicide attack at once. Sure, you'd get lots of people claiming that they would do it, but when you give the order to go how many would take that patrol boat and head for someplace where they'd escape prosecution?
So your eyeballs are really blind to "This significantly increases probability of corruption". How pathetic.
I read it. I just don't see how journald is any more susceptible to corruption than a text log.
You stated that they are susceptible "due to not having any transaction consistency, as an RDBMS would." That is certainly true, but it is also true of a text-based log. You're saying that because B is better than A, we should definitely go with C.
So the solution was triple the number of guns on the ship so that there was such a withering volley of fire coming out of the boat that not even a kamikaze could get through....As a result of that... if the Iranians tried this tactic on such a ship they'd all be annihilated. A modern carrier group with a swarm of drones around it might be able to fight off such an attack as well. It might be cheaper to just put WW2 close defense guns on our ships. But no one is gong to do that... it isn't futury enough for them.
Uh, I think you misunderstand the tactic. This isn't about kamikaze attacks where the explosives are on the boats - they probably couldn't get close enough to do anything unless there were thousands of boats to attack a single ship, since the ships do have 50 cal machine guns and often radar-controlled cannons.
The tactic is to swarm a target with boats, with some of those boats carrying anti-ship missiles. The boats don't need to get within range of small arms and cannons. They can't afford to equip EVERY boat with a missile. So, they send in 200 boats, and 3 of them have anti-ship missiles with something like a 10-mile range. If you sink 90 of those boats, chances are that 1-2 with missiles are still intact, and when they get within 10 miles they can fire a missile at you.
The tactic works because they force you to engage many targets with sophisticated long-range weapons, while only needing to invest in equipping a few of them with similar weapons. They have to buy 3 exocets, and we have to launch 250 harpoons to be likely to take them out.
It is a kamikaze attack, but of a different kind.
Np. It was a nice pun, and much of this debate goes to whether this sort of thing is acceptable discourse.
Between two friends as a joke it goes over a lot better than between two strangers on a mailing list. :)
Since you have abandoned the idea of either side painting the middle as extremists (you didn't stick to the point that "additionally anyone who wishes for abortion to remain legal for incest-rape is pro-murder - you should be bound, by law, to carry your child/nephew to term", or other statements that show either side can force any moderate opinion to an extreme one)
You're going to have to re-state that, as I am not sure what you're trying to say. You seem to be putting words in my mouth.
I really didn't intend to comment at all on whether either side paints the middle as extremists at all.
I didn't say "additionally anyone who wishes for abortion to remain legal for incest-rape is pro-murder - you should be bound, by law, to carry your child/nephew to term" so I'm not quite sure why it is in quotes.
I'm not necessarily disagreeing with you. I'm just honestly not quite sure what you're trying to express.
I'd note that the anti-abortion group is decidedly pro-murder
Uh, what does being against abortion have to do with being for murder? I'm not sure how this follows.
What's more pre-meditated killing of a human than the death penalty?
So, there are a few problems here:
1. First, you can be anti-abortion and also be anti-death-penalty. Many aren't, but they are really different issues.
2. You've basically defined "murder" as "the premeditated killing of a human." I doubt most will accept that definition. If we were to accept that definition, then murder isn't a crime, abortion is murder, many consider murder morally acceptable, etc. I'm not usually big on arguing over definitions, but this was not what I meant when I used the term.
But then, that's another way that the moderate get painted as radicals. If you aren't absolute on every statement, then they paint you as being non-committal to anything/everything.
No argument there, and that was certainly not my intent.
My point was simply that the reason the "anti-abortion" crowd tends to also be "anti-choice" is that they consider abortion to be murder, and as a result people can't be offered a choice. Most people would not say that a person has a right to choose to kill their adult neighbor without their consent. Many would actually say that a person doesn't even have the right to kill themselves, though this is far more controversial.
Whether abortion is murder is certainly something that can be debated. There is no question that abortion is pre-meditated killing. Looking at an ant and stepping on it is pre-meditated killing. Whether it is the killing of a human is just a matter of your definition of a human. However, murder usually involves more than just the pre-meditated killing of a human. For example, we generally do not use the term murder to describe the actions of a firing squad, a police officer firing on a hostage taker, or a military operation, but all of those can involve the pre-meditated killing of a human.
Both the US and Russians have destroyed satellites recently in demonstrations. In the Russian case they did it in a manner that created quite a bit of long-lasting debris. Nobody really wants to brag about this capability, but shooting down a satellite isn't really all that different from shooting down a high-altitude plane - the velocities are just much higher.
Whether the Chinese could pull it off right now is uncertain. The US clearly has the capability, and in an actual serious war they would certainly consider the pros and cons of destroying all satellites operated by anybody who might provide data to an enemy (including commercial operators who don't cooperate - but they will since they make more money with half the customers than with none of the customers and you can't really be neutral in a major war). I think the main US consideration would be losses to their own and allies satellite network due to debris, etc.
Of course, nobody is going to start shooting down satellites unless we're talking about a serious war - that is one where most likely tens of thousands to millions of people will die.
1. Gentoo is not switching to systemd, either.
At this point systemd is about as well-supported on Gentoo as the default openrc, and there is open discussion on the lists about removing the default entirely so that there is no default, just as there is no default bootloader or kernel. The whole point of Gentoo is that you get to run what you want to run, more or less. Of course, not all configuration permutations are equally supportable.
You do not acknowledge the abuse of the Debian Community process? Or the fact that Debian is Upstream of 5 or 7 principal distros?
The fact is that virtually every distro has chosen to adopt systemd. The only one not adopting it that I'm aware of is Slackware. Gentoo isn't going to make it a default, but seems likely to drop their existing default. Of course, the #1 Gentoo derivative runs Upstart, so it will be interesting to see where it goes (hint, more systems run Upstart on a Gentoo derivative than on Ubuntu).
Sure, Debian's choice led to many derivative distros going along with it, but there have been many independent decisions to adopt it.
As far as the Debian community process goes - I only followed that tangentially, not being a part of the Debian community. I think I might have one VM somewhere running it that I fire up once a year. You'll have to ask a Debian lawyer whether their process was followed - there seemed to have been a lot of those types on that thread.
Why not stuff yourself into PID 1 and execute yourself?
At least we're getting back to the main topic - the FOSS community is full of assholes.
Under what situations would device encryption be useful without a screen lock? Your phone data can be read by anyone who gets their hands on it, since the unencrypted data is exposed to anyone who swipes right...
Simple - you keep the phone on your person, and turn it off when you leave it in an unsafe place. You still want to turn off the screen so that your battery isn't wasted, but you don't need locking. You can power off when leaving the phone unattended, giving you the device lock.
I can't think of any good reason that your screen lock password should be weaker than your device password...
Your device password should be difficult for a machine to crack, since it is designed to protect against direct access of the flash hardware. That means it needs a strong password. The machine gets an unlimited number of attempts to guess it, likely measured in many attacks per second if you have lots of rounds, or millions of attacks per second if not.
Your screen password needs to be able to be entered while you're driving in case your screen locks while you're using your GPS. That means it needs to be trivial in length. That isn't a problem, because the software can throttle entry attempts, or even shut-down the device (thus falling back to the device password) after a few failed attempts.
Screen locks and device encryption keys serve two different purposes, even if people often conflate them. They have different threat models and different ways of mitigating against them.
Now, a compromise would be a hard key stored in a TPM with an easy PIN used to access it. The TPM would permanently forget the key after a few failed attempts. However, Android does not do things this way. This would still let you have an easy PIN on boot-up without requiring a screen lock.