Sure. Perhaps you've heard of bigamy? Alice can't marry Carol because Bob already has a vested marital interest with Alice. For example, if Alice marries Carol and dies, Carol is entitled to 100% of her assets as spouse. But so is Bob.

That's not the policy rationale for the prohibition on bigamy, and while it is perhaps a little better of a reason than administrative convenience, it boils down to the same thing, since the question of marital property is one of the issues that legislatures will have to address when the ban is overturned as it inevitably will be.

On the contrary, tradition is absolutely relevant as to whether something is a fundamental right. Marriage is a fundamental right because it's enshrined in our traditions and collective conscience. ...
Polygamy does not have such a place in our traditions or collective conscience, and therefore is not a fundamental right.

Yep, that's the bullshit argument that people were rolling out against same sex marriage all right. That because it wasn't traditional, it wasn't fundamental.

The core mistake with that argument, whether in the context of same sex marriage or marriage among persons already married, or in larger numbers than two, is that what's fundamental is not opposite sex marriage, or same sex marriage, or polygamous marriage, but simply marriage, without qualification of any kind.

Issues like gender, race, consanguinity, marital status, and number of spouses are all restrictions on that singular fundamental right. Whether they stand hinges on whether they can be justified. Two of them, it transpires, cannot be. Ultimately I think the only restriction that will hold up will be consent, and perhaps consanguinity will have to be reframed in terms of consent if it's to be salvaged.

To be fair, if you're dealing with the level of malware that can cover its tracks against that kind of investigation, and if that malware is already on your system but wasn't picked up on a previous scan, the game is already over anyway and you're well into complete reinstall and restore from back-ups territory. These days, with threats that can hide in other areas of the hardware/firmware to survive the wipe and reinstall process, I'd be wary of trusting even that in any highly security-sensitive environment.

I'm freelance these days, so I'm afraid I can't help. Sorry. :-)

One of my regular clients operates in this field, and seeing things done in a reasonable way reminds me of why I used to get so irritated when I did work as part of a large, bureaucratic institution. It's not magic. It's just being aware of modern tools and practices, and being willing to make the effort (and yes, sometimes, being willing to spend the money) to set up something that provides a useful degree of security but without making things so secure that you forget why you're there in the first place.

Given the potential costs of getting security wrong, I don't really understand why any organisation large enough to be facing these issues regularly wouldn't hire people who know what they're doing and provide a reasonable budget for them to deploy proper tools. I can only assume it's the usual suspects, probably some combination of ignorance and corporate politics.

Full disclosure: Obviously I make money from working for that client and they make money in part from selling some of those tools, so I'm kinda sorta shilling here. But not really, because really, the cost of hiring smart people and giving them proper equipment vs. the cost of say a major regulatory investigation or having your whole sales team at the pub all day because they can't work... not exactly close.

Oh, OK then. It's not like full- or even part-time telecommuting is one of the most advantageous perks offered by many modern workplaces in terms of productivity or staff morale, so I don't suppose the business will suffer too much. Should I also recall our entire sales force and tell them they can't work on customer sites any more?

In other news, please be aware that due to a change in company IT policy, next time you get paged at 4am because of a network alert, remote access will not be permitted for security reasons. Instead, you will be required to get up, spend 20 minutes driving to the office, log in from a properly authorised and physically connected terminal, type the same one CLI command you do every time that alert goes off to confirm that it's still just the sensor that is on the blink, type the same second CLI command you do every time to shut off the alarm, spend 20 minutes driving home again, and then go back to bed. Sleep tight.

In a sense, yes, the most important problem is that simple, but as you then demonstrated with things like the database example, "simple" and simple aren't always the same thing.

The other point I was to make is that your example presupposes that all of the packages you need are installed using your distro's package manager. In my experience that is rarely the case, and while there are tools like checkinstall that can help, the lack of any enforced installation conventions or protections against unexpected interactions in mainstream Linux distros means you are always vulnerable to certain nasty problems. Anyone's make install can probably nuke the output from anyone else's. Someone running a make uninstall that removes something that some other project assumed would be present can break the other project. Even if you stick to distro-only packages, there is not always a guarantee of backward compatibility when moving to a new version of the distro.

To me, the fundamental problem here is that for the most part I want an OS foundation that is stable and robust, and other than security fixes I probably never want it to change for the lifetime of the system. On the other hand, I want to be able to install drivers for new hardware or protocols and of course new application software on top of that OS, and I want them to have a stable platform to run against and to be as independent as possible so swapping out one part of the system doesn't undermine any other parts. The current Linux ecosystem with its distro model does not promote that kind of separation and safety, unfortunately.

If you have a network that is wide open to "drones with mapped server drives getting cryptolocker" and causing the entire organisation to lose a day of work, the kind of scheduled scans mentioned above probably aren't going to protect you anyway.

To defeat a threat like cryptolocker you need real-time measures to prevent it operating in the first place: proper scans on incoming mail and web downloads, internal firewalls, and so on. To limit the scope of the damage if cryptolocker manages to get in somehow anyway you need least privilege access controls on your internal systems. And to restore anything it does manage to get hold of, the most important thing is to have frequent back-ups with fast recovery procedures. Scheduling a system-wide full scan so your staff can't use their laptops for 15 minutes at 10am every day is not going to give you any of those protections.

Obviously there is always a risk of some disruption if IT are responding to an ongoing incident or recovering afterwards, but if you're routinely causing significant disruption to your entire staff then there are probably better ways to achieve the results you want.

Most of us do have a need to transmit messages privately. Do you not make any online purchases?

Yes, but those have to use public-key encryption. I am sure of my one-time-pad encryption because it's just exclusive-OR with the data, and I am sure that my diode noise is really random and there is no way for anyone else to predict or duplicate it. I can not extend the same degree of surety to public-key encryption. The software is complex, the math is hard to understand, and it all depends on the assumption that some algorithms are difficult to reverse - which might not be true.

Your anecdotal experience does not make the problem any less real for others.

Objectively, for example, I have a reasonably well-known web app running on a few servers. It's written in Ruby and runs via Passenger. Between the official documentation and generally sensible tutorial/reference material on-line, I have literally seen four completely different recommendations about just where to install the related scripts, from directly under /var/www to places under /opt. As with many web applications, it also wants configuration files in certain places, often related to where those scripts are. Those configuration files should be properly backed up, and just like that, with hosting a single web app and without even installing any OS-level packages, you've got a real question about which areas of your filesystem contain data that should be safely backed up.

Now scale that up to the number of applications and packages you might have installed on a traditional Linux server used for multiple purposes or multiple teams, and it's not hard to see why configuration management tools and running separate servers (or virtual servers) for each application have become the standard practice in corporate sysadmin and devops world.

It's hard to do actual research as an end user when you're talking about devices costing hundreds of bucks and you have a software environment that won't let you move back if you "upgrade" and it renders your device effectively unusable. This is a very convenient situation for the device manufacturers and the people who don't want to bother with things like backward compatibility and long-term support of their software, of course.

But count me in for at least half a dozen similar anecdotes among friends and family with various mobile devices, particularly the expensive ones like Apple/iOS and Samsung/Android phones and tablets.

I am increasingly of the view that there should be a certain degree of mandatory regulation in these industries, where the commitment (or lack of it) to future proofing such devices against software-related breakage must be clearly stated before purchase and failure to do so is automatic grounds for a refund if the device does then get bricked or otherwise rendered effectively useless. I am generally very wary of regulating software and liability issues, because of the difficulty in establishing objective standards for what is reasonable, but there is so much abuse in our industry now because of continual updates and built-in obsolescence that I'm starting to think consumer protection authorities should actively intervene.

Coincidentally, the staff also do most of their work during the daytime.

Yes, damn those idiots who take their laptop out of the office so they can actually do their jobs. Those crazy kids are messing everything up.

Seriously, if you have security policies that are interfering unreasonably with your staff's ability to do its job -- and if you are dramatically slowing down their systems or causing disruptive behaviour like reboots during the working day, that is undermining the staff's ability to do its job -- then you're doing it wrong. IT is there to help people do whatever it is you do, not the other way around.

You and I have very different experiences of Linux-based systems, though admittedly I am mostly using Linux on servers rather than workstations, and really the problems are more about the distro/software running on top of Linux than Linux itself.

My experience of trying to back-up a real world Linux system is that you start with backing up /home. Then you also figure out what you need to back up from other places, like /root, /etc, /opt and /var. Some of the configuration files in there will be automatically generated from others, but if you overlook any of the underlying ones, you'll be running at 640x480 forever or your RAID won't be as redundant as you thought. Some of the configuration data will be specific to the particular version of something you currently have installed, and the new version will fail to initialise properly after you've upgraded because it doesn't update the previous configuration completely and correctly without user intervention. Some of the executable code you run will be under those directories too, because web apps and scripting and interpreters.

And that's just with standard applications that are provided with your distro. $DEITY help you if you want to install anything else or need to build anything from source, because no-one else is going to. Try not to allow too many breaking conflicts under /etc or /usr/local, where there are essentially no naming conventions and everything just gets a short/abbreviated name and goes into the global namespace. Oh, never mind, we forgot to add the important things under /usr/local/somedirectorymylastdistrodidntevenhave to the back-up scripts anyway.

And then you upgrade your distro to the next major revision because the price of OS stability in the Linux ecosystem is falling behind with all your applications as well, and... Well, in my entire career, across different organisations and with different teams of sysadmins, I can probably count the number of completely smooth major distro upgrades I've seen on no hands. On the server side, I now see a lot of "one install only" policies: the expectation of success with any in-place update process is so low that the standard MO is to set up a new clean machine with the new software required, figure out how to migrate specific configuration and data from the essential applications from the old system to the new one, and then retire/reformat the old machine. Even then, the actual applications and packages installed are tightly controlled; there is an entire industry these days making tools like Puppet or Chef or Ansible because trying to manage these things manually on modern Linux systems is crazy, and making any local changes to standard configurations is frowned upon. Personally I prefer to run Windows for my main workstations for various reasons, but I work with several colleagues who prefer to run Linux workstations and they seem to run into analogous problems with end user/client applications too.

Linux is great in many respects, but with most popular Linux distros, having a clean filesystem structure and code/config/data set-up are not among them. Maintaining most real world Linux-based systems is absurdly complicated as a direct result.

Most algorithms to do this use the time between keypresses, measured to very high precision so that the lower bits are chaotic. So it doesn't really matter what keys you hit, and it doesn't matter how rythmic your typing is.

The problem with FM static is that you could start receiving a station, and if you don't happen to realize you are now getting low-entropy data, that's a problem.

There are many well-characterized forms of electronic noise: thermal noise, shot noise, avalanche noise, flicker noise, all of these are easy to produce with parts that cost a few dollars.

True randomness comes from quantum mechanical phenomena. Linux /dev/random is chaotic, yes, enough to seed a software "R"NG. But we can do better and devices to do so are cheap these days.

I wouldn't trust anything but diode noise for randomness. If I had a need to transmit messages privately, I'd only trust a one-time pad.

because, as noted earlier, 3>2. Equal protection is an issue where two groups that are equally situated are treated differently. For marriage, there is no difference between a gay couple and a heterosexual couple. There is a difference between a couple and a larger group, however.

The litigant needn't be the entire group. Marriage is a fundamental right, subject to various restrictions, such as consent and consanguinity. Yesterday, one of the restrictions, at least in some places, was that the genders of two of the spouses couldn't be the same. Today, it's fine nationwide if they're the same.

The restriction to look at now is whether the marital status of each spouse in the marriage at hand is single. Today it has to be. But there's not a good reason for it. (As already mentioned, administrative convenience is not a good reason). So why can't Alice, who is married to Bob, now also marry Carol? Bob isn't marrying Carol; the A-C marriage would be between two people only. You're treating Alice differently merely because she is already married.

It's also not a fundamental right, as polygamy is not part of the traditions and collective conscience of society, except for Mormons.

Marriage is a fundamental right and is extremely broad. Restrictions on marriage, such as requiring the spouses to be of opposite genders, or of the same race, or of the same religion, or of compatible castes, etc. are not inherently part of marriage and are certainly not part of the fundamental right of marriage.

Also, today's events make it clear that tradition is irrelevant; polygamy is practiced today among many groups, and has a long history back into antiquity. Same sex marriage was known in the past but was far more rare.