Skipping fsck during boot with systemd?(lists.debian.org)
lists.debian.org
Skipping fsck during boot with systemd?
https://lists.debian.org/debian-user/2014/12/msg00184.html
16 comments
I wonder if Mr/Mrs [email protected] talks to his friends and family like that, what an asshole.
From an outsiders point of view, linux projects are filled with people like this. Linus, Ulrich Depper, etc. Really turns me off from ever contributing when these dudes (or girls I dunno) act like this.
From an outsiders point of view, linux projects are filled with people like this. Linus, Ulrich Depper, etc. Really turns me off from ever contributing when these dudes (or girls I dunno) act like this.
I think there's an important difference between Linus and some debian-users posters. Linus directs most of his rants towards developers who don't care about users. "Don't break user space" rule is all about users. Compare with some debian-users participants.
Exactly this
In the Linux world, it seems to me that Linus has the users at heart, which unfortunately cannot be said of several others
In the Linux world, it seems to me that Linus has the users at heart, which unfortunately cannot be said of several others
Don't forget Lennart.
Just watch this video of him disrupting a talk: https://www.youtube.com/watch?v=ZTdUmlGxVo0
The shenanigans start around 12 minutes in, and continue throughout.
The last few minutes are particularly weird. He even gets up on stage at around 53:40.
It's unbelievable!
Just watch this video of him disrupting a talk: https://www.youtube.com/watch?v=ZTdUmlGxVo0
The shenanigans start around 12 minutes in, and continue throughout.
The last few minutes are particularly weird. He even gets up on stage at around 53:40.
It's unbelievable!
Yes it is quite unbelievable how much bullshit and mis-information the presenter is talking, luckily somebody who actually knows the stuff was in the audience to point out some of the actual requirements of modern desktops.
That "modern desktop" is why many stopped using Windows in the first place.
Whose requirements? Gnomes.
Yeah, i don't get the netizens sometimes. Torvalds venting on the LKML is bad, But this heckling is acceptable?
> these dudes (or girls I dunno)
https://en.wikipedia.org/wiki/Ada_Initiative
https://en.wikipedia.org/wiki/Ada_Initiative
So the solution to this, if you want to abort an fsck, go back in time, and pass fsck.mode=skip to the kernel parameters.
A fairly bad answer, we can all admit that.
By clicking a few links further one also finds out that systemd has ctrl-c to cancel fsck on the ToDo list.
All right! To the Chron-O-John!
The way I interpreted his "solution" of "add a kernel boot parameter" was if you want to interrupt the fsck, you should hard-reset the machine to add it on the next boot, making it even more likely your filesystem will need fsck'ing. fsck itself is AFAIK safe with ctrl+c (i.e. it won't corrupt the filesystem further to interrupt it) so this change means users who really want to cancel a fsck have to take the route of possibly causing filesystem corruption themselves. Absolutely fscking insane.
Is anyone else grossed out with the fact that systemd is parsing the kernel's command line? This is like if some program started reading unrelated crap from another program's command line, just because.
Edit: I guess downvoters don't care about code smell. This is literally like an unrelated process pulling out someone else's argv and using it as their own. Ick.
Edit: I guess downvoters don't care about code smell. This is literally like an unrelated process pulling out someone else's argv and using it as their own. Ick.
Linus Torvalds thinks it's perfectly fine and exactly how /proc/cmdline was intended to be used, but what does he know anyway? If systemd is doing it, it must be wrong.
http://lwn.net/Articles/593677/
http://lwn.net/Articles/593677/
There is a lot of strong criticism of systemd in that thread. I was actually considering posting it as sympathetic to my point. It simultaneously expresses what both of us are saying. (You can read the command line, but don't do it for stupid shit.) From your link:
> But the problem appears when system services seem to think that they own those flags, and nothing else matters, and they don't do something "sane" any more.
Then later:
> It does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem.
Next paragraph indicates the rant is directed at Kay Sievers, udev and systemd developer, and his "continued bad behavior".
It does ring true for me as a user, I have noticed systemd-based systems spam a lot of things that used to be "for the kernel" and a bit more sacred, like dmesg and command line.
> But the problem appears when system services seem to think that they own those flags, and nothing else matters, and they don't do something "sane" any more.
Then later:
> It does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem.
Next paragraph indicates the rant is directed at Kay Sievers, udev and systemd developer, and his "continued bad behavior".
It does ring true for me as a user, I have noticed systemd-based systems spam a lot of things that used to be "for the kernel" and a bit more sacred, like dmesg and command line.
The kernel command line has widely been considered an API to userspace. That's why the kernel exports it in /proc/cmdline.
By this logic I might as well say everything in /proc is an API that I can use for any purpose, rotten or not. "It's ok because I read it from /proc/1276/mem". No sir, nothing bad about that design!
No, the discussion was mostly about the parameter as a way to suppress fsck if you know you're in a hurry at boot time.
That argument was followed with other 'bad luck, if you want tonchange your choice' examples, like rm-ing a file. The argument sucks, but at no point a hard reset was part of the suggestion, really. More a "Yeah, so why didn't you pass the parameter and why do you complain about that afterwards"
That said, both sides of the discussion became immature rather quickly (my favorite is the "I killed a Windows 8 laptop because only that stopped the updates") and the issue isn't all that big in the first place, because systemd might support fsck interruption in the future/it seems to be on the todo list and therefor accepted as a missing feature.
That argument was followed with other 'bad luck, if you want tonchange your choice' examples, like rm-ing a file. The argument sucks, but at no point a hard reset was part of the suggestion, really. More a "Yeah, so why didn't you pass the parameter and why do you complain about that afterwards"
That said, both sides of the discussion became immature rather quickly (my favorite is the "I killed a Windows 8 laptop because only that stopped the updates") and the issue isn't all that big in the first place, because systemd might support fsck interruption in the future/it seems to be on the todo list and therefor accepted as a missing feature.
It's really not hard to add a kernel book param if you're booting via grub
sigh i don't even.
The real answer is to use a filesystem that doesn't require off-line integrity checks, and to disable automatic fsck when you're stuck with something that does.
I use ZFS, which does this sort of thing in the background while the system is live. In fact, every read from a ZFS filesystem does a complete integrity check of everything that read depends on. If it finds an error during that process it fixes it before returning data to the caller, or returns a read error if it cannot. Those errors get collected and logged, so that if they do occur (usually due to faulty hardware) you can recover the effected files from backup.
This is much better than a surprise fsck when you're running late.
I use ZFS, which does this sort of thing in the background while the system is live. In fact, every read from a ZFS filesystem does a complete integrity check of everything that read depends on. If it finds an error during that process it fixes it before returning data to the caller, or returns a read error if it cannot. Those errors get collected and logged, so that if they do occur (usually due to faulty hardware) you can recover the effected files from backup.
This is much better than a surprise fsck when you're running late.
The real story is the toxic attitude of some people on debian-users mailing list.
If you use ZFS, you probably are on FreeBSD. Then you would not see the advocacy of systemd that sometimes borders on insane, as a problem.
If you use ZFS, you probably are on FreeBSD. Then you would not see the advocacy of systemd that sometimes borders on insane, as a problem.
But then you're stuck with systemd, which you could avoid with Freebsd.
Its kind of like upgrading an outdoor carpentry project, like a deck, from nails to deck screws, then just in case you miss the feeling of hitting your thumb with a hammer, someone helpfully finds a link to install deck screws using a hammer. That's impressive in its own way, but ... I think I'll continue moving everything to Freebsd instead.
Its kind of like upgrading an outdoor carpentry project, like a deck, from nails to deck screws, then just in case you miss the feeling of hitting your thumb with a hammer, someone helpfully finds a link to install deck screws using a hammer. That's impressive in its own way, but ... I think I'll continue moving everything to Freebsd instead.
no! the whole point of this post is to complain about the attitude of debian devs.
for you to suggest "not getting yourself in this situation in the first place", well, that's exactly the bullshit behaviour that i think most of us find utterly abhorrent.
for you to suggest "not getting yourself in this situation in the first place", well, that's exactly the bullshit behaviour that i think most of us find utterly abhorrent.
Same for XFS and Btrfs, both of which should have fstab fs_passno set to 0, both of which have place holder fsck that don't actually do a file system check. The actual check is done from user space on an unmounted file system.
Strictly speaking ext4 doesn't require it either, it's just highly recommended that there be a periodic e2fsck -f (i.e. check even if the journal is consistent and says the file system is clean), by default this is 180 days but the user can modify or disable this with tune2fs. It's possible to make it mount-count or time-dependent. See tune2fs -i.
Strictly speaking ext4 doesn't require it either, it's just highly recommended that there be a periodic e2fsck -f (i.e. check even if the journal is consistent and says the file system is clean), by default this is 180 days but the user can modify or disable this with tune2fs. It's possible to make it mount-count or time-dependent. See tune2fs -i.
Of course zfs is superior to many fs in many ways. But this is also a systemd way of telling people to "use this, not anything other. That's the best".
Systemd people are not helping the community.
Systemd people are not helping the community.
Same holds for btrfs.
Didn't CoreOS just remove btrfs because it tended to break?
Also: https://rudd-o.com/linux-and-free-software/ways-in-which-zfs...
Also: https://rudd-o.com/linux-and-free-software/ways-in-which-zfs...
The cited article has a. nothing to do with CoreOS, and b. contains very incorrect information about btrfs, not just a matter of also being outdated. e.g. "btrfs does not allow you to organize subvolumes" has never been true. The article must be old because send/receive, deduplication, and preliminary raid56 support have been there for a while.
Damn ironic, given that Poettering wants to build a whole OS using cloud containerization and BTRFS. And CoreOS depends heavily on Poettering's systemd (to the point that they have built their own containerization system on top of it).
We should be very careful about fixing those kind of things, this is one of the biggest complaints against Windows, when you cannot shut down your machine, or boot wait a long time to boot it up, because it did the Windows Upgrade dance.
What's worrisome in this discussion is that the bug was reported 3 years ago, and acknowledge as upstream TODO, 2 years ago, but nothing has changed!
What's worrisome in this discussion is that the bug was reported 3 years ago, and acknowledge as upstream TODO, 2 years ago, but nothing has changed!
That thread features a few participants I would never want talking to a customer.
This is a real problem. Really
There are enough ironic/rude answers, failure to solve the problem or give a good workaround, etc
Now imagine this with paying customers.
There are enough ironic/rude answers, failure to solve the problem or give a good workaround, etc
Now imagine this with paying customers.
There was a more productive thread on a related topic on debian-devel recently:
https://lists.debian.org/[email protected]....
Basically it isn't possible to check at runtime if the next boot will require an fsck, so developer filed a bug asking for mechanism to do that:
https://bugs.debian.org/773267
https://lists.debian.org/[email protected]....
Basically it isn't possible to check at runtime if the next boot will require an fsck, so developer filed a bug asking for mechanism to do that:
https://bugs.debian.org/773267
The atmosphere on debian-users is… not very helpful.
That Brian guy in particular is a total cunt. Holy crap. Willful ignorance of specific issues being raised combined with smug superiority. I find people on IRC to be a lot more pleasant. I am never mailing a mailing list.
"is a total cunt"
I agree completely with what you're apparently trying to say in a general sense, but with respect to precisely how you phrased it, it could use a little work.
I agree completely with what you're apparently trying to say in a general sense, but with respect to precisely how you phrased it, it could use a little work.
[deleted]
"cunt" is a fairly common word in Australia, mate. Life does exist outside of politically correct, cultural Marxist bubbles.
I think he is being reasonable and helpful.
Q. I can't stop fsck.
Brian: You can add a parameter to kernel startup.
Q. This does not help because I want to stop one that has started. I should raise a bug.
Brian: Don't do that there is already a bug report at number ....> Remedial action is not needed because the right choice was made from the grub menu. If it wasn't, you get to live with the consequences and don't do it again.
Is this polite or helpful in solving the issue? It's being preachy about the idea that nobody ever makes wrong choices, ever, and should definitely never be given the opportunity to fix their mistakes.
Is this polite or helpful in solving the issue? It's being preachy about the idea that nobody ever makes wrong choices, ever, and should definitely never be given the opportunity to fix their mistakes.
If only we could all be as perfect as Brian! I find it funny that he rants about choice. The thing I dislike most about systemd is that it is removing choice! I suppose I am just going to have to go and choose to use FreeBSD.
You've reworded what he said to make him sound a lot more polite. In fact on that last point, I had no idea what "Don't get carried away and start typing. #758902" meant until I just read your comment.
You just took what he said and completely reinterpreted it.
His attitude wasn't "don't do that there is already a bug report". It was "well you made bad decisions by (a) wanting to stop fsck in the first place and (b) not being prepared for it happening i.e. by setting up two GRUB options".
His attitude wasn't "don't do that there is already a bug report". It was "well you made bad decisions by (a) wanting to stop fsck in the first place and (b) not being prepared for it happening i.e. by setting up two GRUB options".
Did you read the other branch of thread that contains 180 email conversations about why his initially wrong answer was justifiable? I've given up reading after 10 emails since it was fairly useless. I think that thread is why this is posted in HN.
Yeah, this is precisely what I meant by "willful ignorance of specific issues being raised". :/
I really hope Brian is not like that in real life interactions.
I really hope Brian is not like that in real life interactions.
TIL there isn't much professionalism in the systemd camp.
these are debian developers, i believe.
Not as far as I know. Most devs I know will post with their @debian.org address (or perhaps @ubuntu) when doing debian work in public. Mostly. Also most devs refuse to wallow in the filth that is the mailing lists. On -dev or -project or -private you'll find devs, not so much on -users.
Maybe Maintainers or unofficial, or applicants, at most. Or not very proud of the participation so they semi-obfuscate their address.
Maybe Maintainers or unofficial, or applicants, at most. Or not very proud of the participation so they semi-obfuscate their address.
Can someone explain why systemd which seems so hated (by me too due to wrong philosophical decisions), yet managed to convince almost all big distros (including the one I use) to use systemd by default?
Thanks.
Thanks.
This answer totally sucks, I agree. And I have run into this annoyance myself (I've been using systemd for almost three years).
But just so everyone knows, and so nobody finds themselves in this position, there is an easier way. By default, I believe systemd will skip the fsck if running on battery power (this is the case on Arch, at least). So if you know you are in a hurry but haven't added this to your GRUB config, the easiest thing to do is just boot the laptop and wait about ten seconds before plugging in the power cord (the fsck check happens early enough, so it'll have been skipped by that point). This doesn't help kill it if it's already in progress, but it has saved me many times.
Brian's response is laughably rude and unhelpful, but hopefully this will be a bit easier and more helpful than telling people to edit their GRUB config before-the-fact.
But just so everyone knows, and so nobody finds themselves in this position, there is an easier way. By default, I believe systemd will skip the fsck if running on battery power (this is the case on Arch, at least). So if you know you are in a hurry but haven't added this to your GRUB config, the easiest thing to do is just boot the laptop and wait about ten seconds before plugging in the power cord (the fsck check happens early enough, so it'll have been skipped by that point). This doesn't help kill it if it's already in progress, but it has saved me many times.
Brian's response is laughably rude and unhelpful, but hopefully this will be a bit easier and more helpful than telling people to edit their GRUB config before-the-fact.
Well, this answer is a workaround. And I'm sorry it's a ridiculous one. What if I'm not on a laptop? What if this is a server system?
> this answer is a workaround. And I'm sorry it's a ridiculous one.
If you're trying to have an argument, you've picked the wrong person. I'm not defending Brian; I'm simply pointing out a relevant trick that I thought people reading this thread may find helpful.
If you're trying to have an argument, you've picked the wrong person. I'm not defending Brian; I'm simply pointing out a relevant trick that I thought people reading this thread may find helpful.
You make it clear that you are not backing Brian. I'm just trying to tell the shortcomings of your trick. Also in this case it also involves back in time travel or being prepared. If you want to be prepared tune2fs would be a better choice.
It was incredibly obvious that he already understands those are shortcomings.
You're just stating the obvious in a condescending fashion. Reddit is over there.
You're just stating the obvious in a condescending fashion. Reddit is over there.
so, we need systemd-fsckd.
Some would already argue systemd is already fsckd.
That's some good irony. But on the other hand, just you watch...
Thankfully mke2fs(8) has been changed not to enable enforced fsck intervals some years ago (in 2011), so it's no longer necessary to manually disable it with "tune2fs -i 0 -c 0" on new deployments.
I love trolling from Brian <[email protected]>
Every single answer is "you are holding it wrong". And people wonder what is wrong with systemd and its proponents ....
Uhm. What does "decided it was time to run fsck on my 1TB hard drive" mean? Decided how?
Every n boot (n usually around 30) is scheduled a fsck at boot. It is more a legacy thing as ext4 is really robust. I remember checking my /home/lost+founds regularly in this time and often finding random stuff, music, documents where the i-node has been made orphan so that it doesn't belongs to any directory.
Today, we have ntfs and ext4 with amazing journals which can replay most of the operation that has been made. So, when the Virtual-FS layer (the component of the kernel that map the bytes on your HDD to the logical file-tree in the exporer) detect an inconsistency it can replay and apply the correct state to the fs tree on the fly.
Now that we have robust disks and robust fs, I think that this fsck at boot setting could be relaxed. However, think of the people needing saving their data with an fsck because their HDD wasn't as robust as yours. It's not an easy choice to do. You can't even base your decision on the SMART metrics as the worst HDD, the one you want to check regularly, lie to/don't implement correctly SMART.
Now that we have robust disks and robust fs, I think that this fsck at boot setting could be relaxed. However, think of the people needing saving their data with an fsck because their HDD wasn't as robust as yours. It's not an easy choice to do. You can't even base your decision on the SMART metrics as the worst HDD, the one you want to check regularly, lie to/don't implement correctly SMART.
This value is configurable per file system. It is set at install time but you can change it at will.
You can set it with tune2fs using -c count or -i interval. A machine that is often rebooted might do without the interval, and vice versa.
You can turn it off completely but don't do that unless you have reason to. Running a fsck regularnly brings a bit of peace of mind, especially if your file system has been through a lot of upgrades.
You can set it with tune2fs using -c count or -i interval. A machine that is often rebooted might do without the interval, and vice versa.
You can turn it off completely but don't do that unless you have reason to. Running a fsck regularnly brings a bit of peace of mind, especially if your file system has been through a lot of upgrades.
> You can turn it off completely but don't do that unless you have reason to. Running a fsck regularnly brings a bit of peace of mind, especially if your file system has been through a lot of upgrades.
The filesystem maintainers seem to disagree: since 2011 mke2fs(8) creates new file systems without enforced fsck intervals.
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=...
The filesystem maintainers seem to disagree: since 2011 mke2fs(8) creates new file systems without enforced fsck intervals.
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=...
Thankfully ext4 fsck is significantly faster than ext3, which means any inconvenience for users running robust storage isn't as prolonged as it once was.
[deleted]
Offline filesystem integrety checks should not be stopped.There is a reason they take place to begin with. From the OP, it sounds like Eduardo takes every opportunity to stop filesystems checks from happening when booting. So long as he has a policy of doing them manually, and understand why they take place, that's fine. So, instead, he should just:
# tune2fs -c 0 /dev/sda1
Or whatever his filesystems are. Then again, this is risky, and the OP should understand why.
# tune2fs -c 0 /dev/sda1
Or whatever his filesystems are. Then again, this is risky, and the OP should understand why.
I don't that there is any basis for your assumptions about the poster. What makes you think that he takes every opportunity to stop filesystems checks? Did you read a part of the message that I did not?
His opening sentence makes it pretty clear that he's executed Ctrl-C enough that he's familiar with it, likely executed it more than once, and expected it to work in Systemd.
OK, so it's pretty clear that he's likely to have pressed ^C more than once. That sure is a strong foundation for saying that it sounds like he takes every opportunity to stop filesystems checks.
... Especially since he didn't go out of his way to explain the exceptional circumstances that prompted him to try to skip fsck in the reported case... or did he?
... Especially since he didn't go out of his way to explain the exceptional circumstances that prompted him to try to skip fsck in the reported case... or did he?
so your fix involves time travel, and you think that's reasonable?
Time travel? Huh? I'm only stating that if the OP does not want his filesystem checks taking place on boot, rather than Ctrl-C them on every boot, to just disable them completely. Who said anything about time travel?
his issue is not that fscks happen. his issue is that he cannot safely stop them when they happen.
so, you've given some information about setting the fsck counter to 0, so that it never happens. the only way anyone in this situation could utilise that information, would be to go back in time, run this command, and then boot again.
so, you've given some information about setting the fsck counter to 0, so that it never happens. the only way anyone in this situation could utilise that information, would be to go back in time, run this command, and then boot again.
No. You missed it. The OP stops filesystem checks happening fairly regularly. The great thing about computers, is identifying when you are repeating a behavior, to either have the computer automate your behavior for you, or to change your behavior entirely.
I am fully aware that the OP wants to cancel the fsck(8) in progress, and I am aware of both of the Debian and Systemd bugs in place to address the issue. Arguing on the Internet about whether or not he can or should Ctrl-C an active check, certainly when bugs already exist for both projects, is pointless.
Instead, to prevent additional filesystem checks, there are tools to make this possible. Unless he likes getting frustrated that he cannot press Ctrl-C during a check on boot, which doesn't seem to be the case. His system is booted now, so he has some options available to him:
* Do nothing, so the OP cannot press Ctrl-C on the next check.
* Disable filesystem checks from future boots.
* Switch from Systemd back to SysV Init.
The concept of "going back in time" during an active check, to change a kernel parameter, so it doesn't start to begin with is a strange one. Bugs have been filed, it's even on the TODO for Systemd. So, why not discuss alternatives to the issue until it's fixed?
I am fully aware that the OP wants to cancel the fsck(8) in progress, and I am aware of both of the Debian and Systemd bugs in place to address the issue. Arguing on the Internet about whether or not he can or should Ctrl-C an active check, certainly when bugs already exist for both projects, is pointless.
Instead, to prevent additional filesystem checks, there are tools to make this possible. Unless he likes getting frustrated that he cannot press Ctrl-C during a check on boot, which doesn't seem to be the case. His system is booted now, so he has some options available to him:
* Do nothing, so the OP cannot press Ctrl-C on the next check.
* Disable filesystem checks from future boots.
* Switch from Systemd back to SysV Init.
The concept of "going back in time" during an active check, to change a kernel parameter, so it doesn't start to begin with is a strange one. Bugs have been filed, it's even on the TODO for Systemd. So, why not discuss alternatives to the issue until it's fixed?
i haven't missed anything, you're inventing a scenario based on fragments of knowledge and assumptions.
> is there a mysterious set of commands they came up with to skip an fsck
the final sentence of the opening post.
> I am fully aware that the OP wants to cancel the fsck(8) in progress
well then why are you offering a priori fixes?
> Instead, to prevent additional filesystem checks, there are tools to make this possible
of course there are, but this is entirely irrelevant to the discussion at hand.
> The concept of "going back in time" during an active check, to change a kernel parameter, so it doesn't start to begin with is a strange one.
no strange, impossible. this is my point.
ok, imagine, someone had been in a car accident, and fractured their skull on the window because they weren't wearing their seatbelt. this discussion is akin to a doctor telling the patient (or whoever) that they could wear a seatbelt, and then this wouldn't have happened. just wear a seatbelt in future and you wont fracture your skull. just change the fsck counter/add a kernel boot parameter and fscks wont happen.
> is there a mysterious set of commands they came up with to skip an fsck
the final sentence of the opening post.
> I am fully aware that the OP wants to cancel the fsck(8) in progress
well then why are you offering a priori fixes?
> Instead, to prevent additional filesystem checks, there are tools to make this possible
of course there are, but this is entirely irrelevant to the discussion at hand.
> The concept of "going back in time" during an active check, to change a kernel parameter, so it doesn't start to begin with is a strange one.
no strange, impossible. this is my point.
ok, imagine, someone had been in a car accident, and fractured their skull on the window because they weren't wearing their seatbelt. this discussion is akin to a doctor telling the patient (or whoever) that they could wear a seatbelt, and then this wouldn't have happened. just wear a seatbelt in future and you wont fracture your skull. just change the fsck counter/add a kernel boot parameter and fscks wont happen.
..
> Remedial action is not needed because the right choice was made from the grub menu. If it wasn't, you get to live with the consequences and don't do it again.
this discussion made me angry, and i wasn't even involved. someone has a reasonable request, and it's immediately brushed off in one of the most passive aggressive statements of the 21st century thus far.
he advocates choice, and yet propagates dogma. idiot.