I was a long-time holdout for landscape-mode physical keyboards. I owned the original ADP1 from Google, which had a decent keyboard. I then upgraded to the Samsung Sidekick 4G, which had an even better keyboard. After fixing the keyboard map, I installed a cut-down Debian userspace on it for mobile software development.
After that, I looked at buying a Motorola Photon Q, but I would have had to hack it to get it on my preferred carrier. Even then it would have been expensive. I think my next actual phone was a Nexus 4, and I eventually got used to swiping.
For overall typing and mobile software development experience, I've instead settled on relatively small and handy Chromebooks. This is even easier now days, because installing the Linux development environment is a few clicks.
I would assume that this is not a factor with RAID-1, where all system, metadata, and data is duplicated. I could see this as being very important for the higher RAID levels.
We have since stopped deploying any sort of btrfs RAID (even RAID-1), and have gone back to using Linux MD.
> For data, it should be safe as long as a scrub is run immediately after any unclean shutdown
Note that btrfs-scrub (according to the docs) is looking for on-disk block errors, comparing the data to the CRC (or whatever algo) to see if that matches. If it can recover the original data, the bad block is re-written with the correct CRC.
So btrfs-scrub does not find or fix any errors with the filesystem structure.
For that you need to run btrfs-check, and that can only be done offline.
We've recently suffered a catastrophic failure with btrfs RAID-1 on two fileservers recently. They were both RAID-1 with two 4TB drives, stock Ubuntu 16.04.
With one of the two, the filesystem was allowed to fill to 99% capacity (no automatic monitoring), so obviously that is operator error, and I'm not aware of any filesystem that can handle such situations gracefully. The system became unresponsive, with btrfs-transaction taking up an increasing percentage of CPU time. Removing files and snapshots did not see an increase in free space.
So what is super-curious is that the other server, which only ever got up to about 30% full, also started exhibiting the same symptoms: unresponsive, high load from btrfs-transaction.
I was able to mount the filesystems in read-only mode, and recover the files, and checked it against the offsite backup. So no data loss, only a service loss.
Both systems had 10 or so subvolumes, and read-only snapshots were taken three times per day for each subvolume. After 4 years, that's close to 15000 snapshots, maybe more.
I searched around, but didn't find anything particularly relevant to this issue.
I was crazy enough as a high-schooler to actually build (with the help of my father) a 3D chess "board". It was mostly plywood, with eight 8x8 boards stacked vertically. I had previously gotten a "3D" chess board which was just three 8x8 boards. They weren't making Star Trek tri-dimensional chess sets back then.
With the 8x8x8 3D board, movement rules for 2D chess have a "natural" expansion to 3D, with only a few corner cases. White player's non-pawn pieces start out on the bottom board, with the pawns on the next board up.
In practice, it was hard to visualize how the game was going in general. We were constantly standing up and crouching to see. Only one of my friends wanted to play, and he only lasted about half a game. :-(
With the failure to interest my friends, I had intended to write my own chess program to play it. I had started out with the 2D version, and was then intending to expand it later. The original was written in BASIC... and that did not go too well.
I've been using VI/VIM for decades. If I am looking at a piece of code, I don't think too much about how to move around, or delete lines, or such. It mostly happens while I'm thinking of higher level issues.
Fixing indent issues is just a couple keystrokes, so that reduces my distraction too.
Practice, practice, practice with the tools you are going to use every day.
I wish there were multiple kinds of downvotes. "This is actually bad" (spam, etc.) vs. merely useless, vs. factually incorrect but reasonably presented.
There's arguments for and against that.
On the one hand, we do want to minimize the mental effort put into making a valid vote by a good community member. Up/Down is the simplest, and it is mentally the easiest. When you ask someone to put that vote into a category, that person may or may not then choose to vote at all, and we've missed the opportunity to capture a bit of information.
On the other hand, requiring a little bit more thinking effort may yield more information on average, and help better quality comments rise.
We do kind of have a two-tier vote system now anyway. You can downvote a comment that is just crap. And you can flag a comment that is awful (spam, etc.).
I'd like this scrolling scheme a lot better if there was some physical feedback on my mouse. Basically, I'd like there to be a little detent feeling at the end of the page, so that I know when I'd scrolled a complete page.
Without a force-feedback mouse... I guess I'd prefer if there was a little bit of "edge resistance" or something going from one page to the next.
Otherwise, I'm OK with just hitting page-down to go to the next part of the page. It would be nice if browsers were a little smarter, and tried to not cut off text at the top edge. So in other words, when you hit page-down, you will see a complete line of text at the top.
After that, I looked at buying a Motorola Photon Q, but I would have had to hack it to get it on my preferred carrier. Even then it would have been expensive. I think my next actual phone was a Nexus 4, and I eventually got used to swiping.
For overall typing and mobile software development experience, I've instead settled on relatively small and handy Chromebooks. This is even easier now days, because installing the Linux development environment is a few clicks.