Strongly agree.

It happens to civilizations and countries and corporations, and it can happen to linux distros too. It's perfectly possible for them to get corrupted from the inside. Humans are at the controls, and no humans are perfect.

Services will and do crash for no reason

Appeal to magic? I think if you give the matter even a tiny bit more thought you will agree that it is never "no reason". It may be an extreme low-runner software bug or a hardware glitch, but those are reasons. We may not always be able to figure out the reason, but it is always there. Heck, even an alpha particle in a memory cell is not "no reason:.

And repetition does not magically make an argument persuasive.

No, upstart is in there, too, and that's about all

Is there some genuine reason for dismissing OpenRC?

Yeah, those "rouge" access points sure are a problem. Is that jeweller's rouge, or morticians rouge? Just ladies' make-up rouge?

A balloon on a string is not a blimp.

No problem. Turns out I am an idiot anyway. I see it says "used", not "acquired". I voted. Mainframes edge to within 1 of a tie!

So in this poll, it's like the MITS Altair 8800 never happened in 1975? And none of the 8080/Z-80 CP/M systems mattered?

I have zero security concern about sshd on my VPS. It's pretty much child's play to make it mathematiocally impossible for them to break in even if they keep trying for billions of years using thousands of bots.
1) Disallow root sshd logins. And never use root or sudo.
2) For admin, have a second UID 0 user account with a long name that no one would ever find in a dictionary. Give it a long, super obscure password and make sure it is set to use SHA512 hashing. Then login to this account using an ssh key which has a long obscure passphrase. Use ssh-agent to manage the passphrase.
3) For ordinary user accounts, use the same name and password policy.

One good aspect of this technique: whatever the waste byproducts of the process are, if you just throw them back in the ocean you haven't contributed any pollution to it.

In reply to the second question, yes, of course.

Don't see how anyone can be anything but welcoming to this initiative. Something like this is the missing piece without which the FAA would be remiss NOT to be highly cautionary about mass civilian drone use. I would say this makes the FAA look smart for its existing stand, and a whole lot of clueless lay people are looking pretty dumb for seeing no problem with helter-skelter unregulated commercial drone use.

From the user viewpoint this really sucks, though we can all understand Jeff's priorities.

The question makes no sense. The question you should be asking is "is there any reason to prefer btrfs", and the answer is, at this time, no. ZFS is not "getting there", it is THERE. Has been for a while. Super stable. btrfs is still very much in development. A very slow development.

If you really, really, really must insist on the question as framed, here are some reasons:
* I do not believe btrfs has as yet any counterpart to raidz, raidz2, or raidz3
* snapshots are handled in a very clumsy manner in btrfs, and very succinctly in ZFS
* ZFS has no fsck because by design it doesn't need one. btrfs needs fsck and has only a limited version as yet.
* ZFS filesets are much more versatile than btrfs subvolumes.
* Creation and destruction of ZFS filesets is essentially instantaneous. As I remember it, btrfs like ext2/3/4, etc, is emphatically not.
* Many, many more reasons.

I agree that arch shouting down the opposition to systemd when they forced it on the users was not their finest hour. To put it mildly.

As a fellow arch user, let's agree that arch users have the advantage on everybody else here with the AUR. I'm surprised no one in any of the other distros has figured out yet what a massive advantage the concept of the AUR is.

I don't know a lot about power grids, but I presume this is a good thing for them

Well, I do know the fundamentals of power grids, and I'll tell you the "And?".

The normal household chart shows a very grid-friendly usage. It is quite even over time. The one peak and one valley are both comparatively mild and gradual.

The electric car household chart shows an extremely grid-hostile usage. If it's a few isolated households; no big deal; it is probably even a good thing. But if you get a lot of households with this same pattern, the gigantic abrupt peak at 11 pm will put an extremely heavy demand on electric energy peaking, and on the neighborhood grid wiring. Probably heavy investments will have to be made.

To the extent this peak might offset a heavy daytime peak in industrial use, this might be a partially good thing, but the article does not address this or give any related data in this connection. In any case, the ideal would be not to fight one peak with another, opposite peak. The ideal would be to minimize peaks in general.

You could do this for industry by running it 24x7 using shifts, which would be far more plant-efficient anyway.

And you could do it for electrioc car households by having two batteries that are swapped daily. The charging of the swapped-out battery would be regulated by a smart charger to deliver constant current over the 24 hour period, the value of the current being calculated to exactly reach full charge at the end of the 24 hour period.

Yes, I am aware that the customary lithium ion charging strategy is to have a constant current phase, followed by a shorter constant-voltage phase during which the current falls toward zero. So it wouldn't be quite as idealized as I described, but you could come a whole lot closer to ideal than that chart shows now.

That chart seems to have been prepared by someone with poor technical knowledge. kWh is an integration of power drain over time, not a direct measure of power drain over time A time-varying chart of kWh is an absurdity. I strongly suspect the vertical axis is mislabeled. It should be kW, not kWh.

Comprehension of concepts matters.

I'm with a LOT of other people. I am currently under EDT, and the map and reality agree that I am -4 (until DST goes out of effect). But I answered -5. The full specification of my TZ ID is EST5EDT. Everybody thinks of it as 5 h behind Greenwich; hence conceptually it is 5 hr behind GMT or UTC "sort of" (i.e., the EST base spec is). I am OCD and perhaps overthink questions, but you are going to get other "wrong" votes. EST5EDT is a VERY popular TZ.

And RAID-Z is just as dead easy to set up as a mirror. I set up a number of 6-drive RAID-Z2's, which gives the same double redundancy as a three-way mirror, but is much more space-efficient (4 times the storage space as a 3-drive 3-way mirror with only twice the total number of drives). What blew me away was that setting up the array was essentially instantaneous.

The next delight I had was when it dawned on me that I could extemporaneously "zfs create" separate "sub" file systems within each of those storage pools; again, essentially an instantaneous operation, and the disk space apportioning is automatic and dynamic. You don't have to set size limits for those "sub" file systems.

After that I just kept discovering new wonders. The use of snapshots for live archiving without consuming much storage space is a warm glow.

Agreed 100%, and I couldn't put it better.

What I really, really like is that this decision cuts through the liberal/conservative, left/right divide decisively. It is a false divide, anyway. It is not what matters. The divide that matters is the totalitarian/libertarian one. I am pleased and surprised that the court decision is so decisively on the right^W, er, correct side.

First, let's be clear that I think it is dandy to address this shortcoming.

Having said that, and the tiny sprinkling of FreeBSD workstations aside, who uses the local text-mode console in a FreeBSD server for anything aside from dealing with hardware failure and dealing with a boot process which has gone awry?

All my text mode interaction with FreeBSD servers is through ssh, whether from a text mode terminal (very occasionally) or using an X terminal (most of the time). Does this change have any effect on that at all? Because it appears to work fine as is.

[2][root@fnjomega ~/unitest]# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=
[2][root@fnjomega ~]# mkdir unitest
[2][root@fnjomega ~]# cd unitest
[2][root@fnjomega ~/unitest]# touch ͲͻΉΏπξηθ
[2][root@fnjomega ~/unitest]# cat > ЉЏГЯШ
now is the time
[2][root@fnjomega ~/unitest]# ls -l
total 4
-rw-r--r-- 1 root wheel 0 Jun 26 09:07 ??ΉΏπξηθ
-rw-r--r-- 1 root wheel 16 Jun 26 09:08 ЉЏГЯШ
[2][root@fnjomega ~/unitest]# cat ЉЏГЯШ
now is the time
[2][root@fnjomega ~]# rm ͲͻΉΏπξηθ
[2][root@fnjomega ~/unitest]#

I'm guessing the "??" in the Greek string above is a font shortcoming rather than a basic problem using unicode in bash on FreeBSD.

Pipedot is far and away technically and esthetically the best of the three. The editors are doing a fine job.

Subject choice is not the problem. No one paying attention is the problem. Nobody knows pipedot exists.

What LUKS doesn't give you is HIDDEN, deniable containers.

I just install a minimal system, and as soon as I am booted and running, as the occasion arises and I find I need package X, I just use apt-get, yum, or pacman to install it. I don't grasp what the problem is. All that stuff is always online and a few keystrokes away.

I don't use Nvidia or AMD video crap, so the whole cluster foxtrot of getting that garbage working is not anything that affects me. I am perfectly happy with my Intel video which has excellent drivers built into every distro and Just Works.

s/deside/design/

It was pretty hard even for me to figure out what word I was trying to type only yesterday. Maybe I had a cold :-)

I remain puzzled why Canonical seems to care to fix UI elements to particular places in the first place? I am not sure what they gain from this?

The motivation is simple zealotry on the part of their UI priesthood. They know what is the Only True Way in every detail, and by god, that is all you will get. Some might theink there must be a rational motivation: that rigidity and removal of customizability reduces the code complexity and footprint. This is a false attribution. Do not underestimate the religious fervor of deside wonks with the bit in their teeth.

RockVPS offers BSD VMs? They don't list it.

I'm not sure there's any difference between getting a time share of 2 cores or a time share of 8 cores (or a time share of 8000 cores for that matter). It all depends on how many VMs are sharing a pool of how many total cores. I assume the number of VMs greatly exceeds the number of cores available in the host. It's not as if you're getting any dedicated cores in any case.

AFAIK the soft ocean "landing" is only intended as an experiment/demonstration, and that is its only conceivable use. As such it represents commendable progress. The reason I am confident that SpaceX does not consider ocean landing as an end in itself is (1) they have brilliant talent and surely recognize what salt water immersion would do to the thin aluminum alloy bodies and to the rocket engines, and (2) the fact that the vehicle extended landing legs clearly indicates the intent to work toward a soft touchdown on land.

... but iut's "just" a forked Apache. Apache's model of thread/process-per-connection is simple and reliable, but performance slides toward terrible as the number of concurrent connections becomes vbery large.

NASA has a pretty amazing history of accomplishments.

Absolutely, but pretty much ending in 1986. I'm much more impressed by SpaceX than NASA in the 21st century.

Huge Asimov fan here. I dug them all, starting with E.E. Doc Smith; through Clarke of course; Laumer; Lloyd Biggle; Heinlein was awesome; and so many others. But Asimov was da man. All that science fact writing as well as science fiction. I don't agree with the common opinion that Asimov's characters and their speech was stilted. I really enjoyed detective Lije Bailey's interplay with the robots he worked with. Extra-terrologist Wendell Urth was wonderful.

The Foundation series was absolutely unique. Nobody else even came close to that. The Robot series of short stories and novels were incredibly inventive and thoughtfyl. There were none better to me personally, in the New Yorker or anywhere else.

Nothing at all against OpenBSD, it is great, but do you have something of substance against FreeBSD? Why specifically do you think basing pfsense on FreeBSD is a negative? I may be reading too much into your comment.

Not violently opposed to the new, but would have been better not to change it.

From TFA: "P.S. Secure hash functions are not for hashing passwords! Secure hash functions are building blocks in cryptographic protocols and they should be as efficient as possible while still being secure. Password-hashing functions are for impeding brute force guessing of passwords, and they should be as inefficient as possible while still being usable."

This is complete and utter BULLSHIT. Anybody who does not use SHA512 for a *NIX login password by now is a fool. Ask DOD if you don't believe me. It's the default in RHEL6, FreeBSD10 and many other modern security-conscious distros. Nobody runs just a single round of SHA512 for passwords. As the very next paragraph in TFA admits, you can make any algorithm as bloody slow as you want by running a large number of rounds. The default in glibc is 5000. You can turn up the number of rounds for passwords in PAM, up to at least 999,999,999 if you don't mind everybody logging in having to wait and load a CPU to 100% for minutes for the password to be verified (and making sure any attacker would take millenia to brute force a single password).