I had to settle for a phone with no headphone jack. I thought it can't be that bad, I got a usbc adapter. It's a strictly worse experience:
- It disconnects easily
- It's much more uncomfortable to keep in the pocket with it plugged on, since it's longer
- I feel like I'm stressing the usbc port much more
- I can't charge and use headphones at the same time (unless I buy a different, bulkier, adapter)
- If I don't have the adapter on me, I can't plug my phone in some music system that doesn't have bt. This has bit me in the ass twice already in four months.
- The adapter already seems to be breaking down (I didn't get the cheapest one available) and sending weird inputs to the phone which pauses the music or causes the assistant to tell me the time
So yeah, nothing's stopping me, but my experience is worse now for the sole reason that Apple decided they wanted to sell Bluetooth headphones
> I can't charge and use headphones at the same time (unless I buy a different, bulkier, adapter)
Well, that's better than things used to be...
I had a Zen Stone that I used to play music in the car by plugging a cassette tape adapter into the audio jack.
For convenience, I bought a cigarette lighter adapter to power it, so that I wouldn't have to take it out of my car when it needed charging.
Except it turned out not to be able to play audio while charging. Not because it charged through the audio jack. It charged through a USB port. You just weren't allowed to do both at once.
I also had a Zen Phone (if that's what you meant) and it definitely played audio while charging.
All the phones that I have had with a audio jack would charge and play audio without any issues, ranging from a lot of different Samsung Galaxy to Wiko phones.
> I shudder to imagine what the next tier (cal us') costs.
There is no enterprise tier, instead you pay for any additional features you need. I.e. log streaming is 2$/month/user and SSH recording is 3$/month/user.
While I do that, is that really the case? I can imagine database snapshots are consistent most of the time, but it can't be guaranteed, right? In the end it's like a server crash, the database suddenly stops.
That's why you do a filesystem snapshot before the backup, something supported by all systems. The snapshot is constant to the backup tool, and read order or subsequent writes don't matter.
The main difference is that Windows and MacOS have a mechanism that communicates with applications that a snapshot is about to be taken, allowing the applications (such as databases) to build a more "consistent" version of their files.
In theory, of course, database files should always be in a logically consistent state (what if power goes out?).
Well, supported by Windows and MacOS. Linux only if you happen to use zfs or btrfs, and also only if the backup tool you use happens to rely on those snapshots.
That works if the backup uses a snapshot of the filesystem or a point in time. Then the backup state is equivalent to what you'd get if the server suddenly lost power, which all good ACID databases handle.
The GP is talking about when the backup software reads database files gradually from the live filesystem at the same time as the database is writing the same files. This can result in an inconsistent "sliced" state in the backup, which is different from anything you get if the database crashes or the system crashes or loses power.
The effect is a bit like when "fsync" and write barriers are not used before a server crash, and an inconsistent mix of things end up in the file. Even databases that claim to be append-only and resistant to this form of corruption usually have time windows where they cannot maintain that guarantee, e.g. when recycling old log space if the backup process is too slow.
I use both, and I never had problems with any of them. Restic has the advantage that it supports a lot more endpoints than ssh/borg, f.e. S3 (or anything that rclone supports). Also borg might be a little bit more complicated to get started with than restic.
I don't think an accurate and automated public status page is something any management would want. If it was accurate they wouldn't be able to lie to customers about the uptime. So I always suspect status pages are adjusted manually.
That's exactly what happens. How we need to respond though is by not linking to status pages hosted by that party, instead we should be linking to a StatusGator or DownDetector page as a 'source of truth'.
reply