Org-mode in emacs.

There are various mobile clients.

If you have something to synch files, it’s just syncing org files. Probably mostly interesting to people who use a lot of emacs on a PC, though.

No, because the DBMS is going to be designed to permit power loss in the middle of a write without being corrupted. It’ll do something vaguely like this, if you are, for example, overwriting an existing record with a new one:

1. Write that you are going to make a change in a way that does not affect existing data.

2. Perform a barrier operation (which could amount to just syncing to disk, or could just tell the OS’s disk cache system to place some restrictions on how it later syncs to disk, but in any event will ensure that all writes prior to to the barrier operation are on disk prior to those write operations subsequent to it).

3. Replace the existing record. This may be destructive of existing data.

4. Potentially remove the data written in Step 1, depending upon database format.

If the DBMS loses power and comes back up, if the data from Step #1 is present and complete, it’ll consider the operation committed, and simply continue the steps from there. If Step 1 is only partially on disk, it’ll consider it not committed and delete it, treat the commit as not having yet gone through. From the DBMS’s standpoint, either the change happens as a whole or does not happen at all.

That works fine for power loss or if a filesystem is snapshotted at an instant in time. Seeing a partial commit, as long as the DBMS’s view of the system was at an instant in time, is fine; if you start it up against that state, it will either treat the change as complete and committed or throw out an incomplete commit.

However, if you are a backup program and happily reading the contents of a file, you may be reading a database file with no synchronization, and may wind up with bits of one or multiple commits as the backup program reads the the file and the DBMS writes to it – a corrupt database after the backup is restored.

You need RAID

I’d say that one needs backups.

After one has backups, if it’s necessary, then I’d look at RAID for reducing downtime in the event of a drive failure.

But one doesn’t want to use RAID instead of backups.

https://serverfault.com/questions/2888/why-is-raid-not-a-backup

Why is RAID not a backup?

When someone mentions RAID in a conversation about backups, invariably someone declares that “RAID is not a backup.”

Sure, for striping, that’s true. But what’s the difference between redundancy and a backup?

RAID guards against one kind of hardware failure. There’s lots of failure modes that it doesn’t guard against.

• File corruption

• Human error (deleting files by mistake)

• Catastrophic damage (someone dumps water onto the server)

• Viruses and other malware

• Software bugs that wipe out data

• Hardware problems that wipe out data or cause hardware damage (controller malfunctions, firmware bugs, voltage spikes, …)

and more.

No disagreement with your broader point about a single drive ultimately being bounded in the kind of reliability that it can provide, though.

Note: If you want to backup a DBMS, you’re going to want to use some system that ensures that the backup is atomic.

I don’t use iOS. But I have used Android, and what I found that a larger irritation for me than the client – I use ConnectBot, and do local Linux stuff in Termux – is the on-screen keyboard. While there are various people who have taken a stab at the situation, the basic problem is that nearly all Android users are using on-screen keyboards for stuff like sending SMSes to their friends. Maybe the more verbose are doing things like posting text to the Threadiverse. Few of them need things like some of the more-exotic keys – control, alt, modifier keys, etc.

Even on onscreen keyboards that have support, if you want to hit something like “control alt shift 5” in emacs on a remote Linux machine, it’s just awkward on many onscreen keyboards, need to toggle between multiple keyboard layouts just to hit that combination. Then you’ve got things like brackets and pipes and curly braces and such that are used by shell environments. Yes, it’s…usable in a pinch, but it’s an irritation if you’re going to be doing much in the environment.

And even if you’re just mostly sticking with alphanumerics, it’s still a bit exasperating to use an onscreen keyboard to operate a primarily-text-based environment.

A tablet like yours might actually have the space for a larger onscreen keyboard, but IME, keyboards tend to be designed for the more-commonly-used phones than tablets.

If you are willing to carry one and don’t presently have one, and you expect this to be the primary route to use the Linux machine, use it via the terminal, I’d consider getting a physical Bluetooth keyboard with at least all of the keys that a “60%” keyboard has, and preferably more like a “TKL”/“tenkeyless” keyboard.

https://www.keyboard.university/100-courses/keyboard-sizes-layouts-gdeby

Just makes the experience a lot more pleasant.

Isn’t Jenkins a continuous integration system? I’d think that you’d want a configuration management system (like ansible) if you’re not trying to set up CI infrastructure.

Link: !sysadmin@lemmy.world