No, it can't. Refusal to vaccinate yourself or your kids does not, by itself, cause harm to anyone else. If any harm does occur later on, it will be due to interacting with others while infected and contagious. Provided that the proper steps are taken, it is perfectly possible for the unvaccinated to avoid becoming infected, and even if infected, to avoid passing the disease on to others during the contagious period. Vaccination is certainly more convenient, but it is hardly the only way to avoid passing on diseases short of total isolation.

"Negligence" is a tenuous argument at the best of times; to apply it here, you would need to show that the individual had reason to believe that he or she (or his/her child) was actually contagious and chose to interact with others anyway without taking effective precautions to prevent the spread of the disease.

I favor vaccination, but I also feel very strongly that people have the right to decline any medical procedure they do not wish to undergo, vaccination included.

What libertarians generally believe, as a direct consequence of the Non-Aggression Principle, is that the owner of the road decides the terms for the use of his or her private property. Either a space is privately owned by someone, who has the right to determine who can enter it and how it can be used, or else it is unowned and thus available for anyone to homestead. There are no "public spaces", and no one has the authority to enact a "public-health measure" restricting the use of others' property.

There's a simple solution for that: give both sides a fixed amount of time (several days) to enter a review. Reviews remain hidden until the time limit has passed.

The site should allow reviews to be edited until the time limit expires, rather than locking in reviews once both sides have submitted, to as a safeguard against coercion. Otherwise one party could force the other to enter a positive review while they watch, then lock it in by submitting their own review.

I'm not really sure how creating yet another way for a "designated program" to monitor input events is supposed to address the problem that any X11 client can monitor keyboard events on any window in the absence of a grab, unless you intend to rewrite all existing software to grab the keyboard on receiving input focus, and force all the desktop environments to implement support for the extension and move their global keybindings into a specially designated client. At that point you might was well switch to a system designed for secure I/O from day one—like Wayland.

It's no different with a rootless X server on Windows. Input received by any X window can be observed by any X client, unless one client grabs the input. XWayland will probably work the same way, with native Wayland clients secure from each other and from X11 clients but no isolation between X11 clients and no support for grabbing input directed at non-X11 windows. XWayland is meant as a shim between the Wayland compositor and ordinary X clients; it doesn't support external window managers and isn't expected to host a full X11 desktop environment. You wouldn't run something like a screen locker as an X11 client under XWayland. It wouldn't be secure, for the same reasons that screen lockers aren't secure under X11 now, and similar compatibility problems would occur if you tried to implement the Wayland input model with X11 extensions.

It's easy to implement the insecure X11 model on top of a secure system. The reverse is much more difficult.

Some other window most likely does have the keyboard focus, but that's not the same as grabbing the keyboard. Having the focus doesn't prevent input events from also being delivered to other windows, it just tells the non-focused windows to ignore the events. Integrity and privacy for both input and output is a hard problem and something very few windowing systems manage to get right. The solutions tend to involve some degree of inconvenience for the user.

What exactly would you propose to add? This isn't a matter of implementing new functionality, but rather removing fundamental misfeatures. Any change to address this issue is going to end up breaking existing applications which depend on the original input behavior.

In any case this is hardly the only reason to switch to Wayland. It's just one of many areas which highlights the drawbacks of trying to tack modern best practices on top of an aging framework. Better to adopt a clean and modern design as the base and confine the hackish workarounds needed to support older clients to a separate compatibility layer.

Yes. This isn't just X, by the way; it's a common design across most operating systems. Any client can register to receive keyboard and mouse input regardless of the current focus, unless another client has already "grabbed" the input device. This is how things like global keybindings are typically implemented. Windows used for password entry (including lock screens) can grab the keyboard to prevent other programs from listening in. The problem is that this only works if no other program has already grabbed the keyboard.

Secure input handling is one of the many reasons why everyone is eventually planning to switch to Wayland. Under Wayland, only the compositor has access to the raw input or the ability to inject simulated input events. The compositor manages any global keybindings and forwards the remaining events exclusively to the active window.

The concept of the "Nanny State" is more about means than ends. If a state's approach to "protecting" people involves restricting their freedom, then it's a Nanny State. The goal is laudable, but does not justify the means.

You're assuming that they already know that you have the keys. If they don't know that, then demanding that you open the cabinet amounts to a call for self-incrimination—not because of the contents per se, but because it would show that you had access to the contents. (Perhaps you received a locked cabinet with no key, and have no idea what may be inside.)

Similarly, if they haven't already shown that you have access to the social media account in question, then simply revealing that you know the password would be self-incrimination. Perhaps someone else set up the account in an attempt to frame you.

If they know that an account was used for cyber-bullying, but don't know for sure that it was you using the account, revealing that you know the password would already be self-incrimination. You don't need to make up a convoluted password in order to plead the 5th.

Timezones exist because the world is curved around the axis of rotation, meaning that the angle to the Sun varies according to one's longitude. If the world were flat, but still rotating so as to allow for day and night, then the Sun would be at (very nearly) the same angle to the ground everywhere, and thus the time should be the same everywhere.

Unless there are people living on the back of the plane, that is, in which case there would be two diametrically opposed timezones rather than the continuous variation you get with a sphere or cylinder.

Please; this had nothing to do with systemd. It's about PackageKit, which has been around for quite a bit longer. The problem is with the part of their PackageKit configuration which apparently allows administrators to install software without authenticating first. It's rather like putting the line

in your sudoers file. PolicyKit can also be configured to require authentication for each action, it just wasn't set up that way on their system. There's nothing wrong with identifying the members of the "wheel" group as administrators, but the policies should be configured such that administrators need to authenticate prior to installing new software. (This seems to be the default on CentOS 6.4; I have no idea what they were running. "pkcon install" does not work by default here without authentication, even for a member of the "wheel" group.)

You can put whatever data you want inside a "plain text" message. Even under wartime conditions where all messages in and out are reviewed by actual humans, people still manage to get secrets through—and that approach doesn't scale. Any automated Internet censorship system (short of shutting down the Internet entirely) would leak like a sieve.

You can, however, mine iron more efficiently if you have plenty of information at hand regarding the locations of the richest deposits, the latest mining techniques, and the state of the futures markets. The same goes for crops—better information regarding the health of your fields, meteorological forecasts, market conditions, and the latest agricultural developments all make for higher yields, and that's before you even consider the information-heavy R&D required for modern GMO crops.

Rapid worldwide information networks take the guesswork out of the economy, so that you don't spend months mining iron ore or growing crops only to discover when you finally deliver your finished product to market half a world away that the demand lies elsewhere. Producers can find out about changes in supply and demand as they occur and adjust their investments accordingly. That alone is a major development in its own right.

Provided there's still anyone who cares about the data after 100 years, I'd say the odds of it surviving completely intact are fairly good, especially if you use the space recovered through digital compression to store error-correcting codes. It's unlikely that we'd forget how to decode popular formats like MP3, FLAC or JPEG in such a short time, absent a global catastrophe of sufficient order to drive the entire human race back into the stone age.

I'll admit that analogue still images do have digital beat in one area, ease of access. For all its faults, at least film doesn't need a complicated decoder; just shine some light on it (or through it). Of course, that only works because you're not operating anywhere near the limits of your storage medium. How many analog images do you think you can fit in 15x11mm? My comparatively cheap 32GB micro-SD card can hold around 3,000 8MP raws (~10MB each), which is pushing the limits of consumer optics. With reasonable compression you could easily double that. At that scale I think you'd need a bit more than just a magnifying glass to see the individual images.

My response was really to this line, however:

Any "modern analog technology" can be exploited for the storage of digital data, and thus benefits digital at least as much as analog. Analog is never going to "blow digital out of the water". It has its niche areas, like archival film for ease of access, and loses to digital everywhere else regardless of the recording technology.

You could use those same materials to store digital versions of the media far more compactly, with equivalent quality. Even lossless audio compression (FLAC) would reduce the amount of material required by 40-50%; the benefits are greater for video, much less something like a hologram. (Yes, you can store holograms digitally.)

Raw signals contain a lot of redundancy. Any real-world signal can be converted losslessly between analog and digital; a prime advantage of the digital representation is that it can be processed to remove that redundancy. Also, near-ideal filters can be implemented much more easily as DSP programs than as networks of analog components.