lathiat

This issue has been driving me crazy and I spent a while a couple of times trying to figure out why the limit was 1024 and if we could bump the default. I got sidetracked and never finished it either time. I also separately knew about the select() issue but hadn't linked the two.

This sounds like a great change in that at least software can opt-in without having to even edit their systemd unit.

In the early days of card payment terminals my mum couldn't remember her PIN number to pay at a shop. Had to run over to an ATM and do a pretend transaction and take note of what she entered.

Yep

I have heard some plane infotainment systems use a 1-way optical link to solve this problem to get the speed/altitude/etc to the displays. It just receives the data as a downlink (no 2-way communications) and being optical its electrically isolated as well as impossible to transmit or even interfere the other way.

you can mark the recommendaitons as not interesting, likely to fix it up pretty quick.

A great software solution. I had a look and once Linux boots it actually uses devicemapper to map a dm device to the raw sectors containing the iso which it extracts (as it may be fragmented) to feed to dmsetup. Kinda crazy.

There is also a couple of hardware projects that to that in hardware. I used the ISOstick for many years.

You can also PXE NetBoot a lot of installers with dynamic menu selection - see http://netboot.xyz

That's basically it, this might help: http://peeterjoot.com/2019/09/20/an-example-of-linux-glibc-s...

Theoretically this would be possible but probably wouldn't help much in practice. Writes on an SSD aren't mapped 1:1 from "logical" address to physical address - they constantly balance and move writes around the entire device (the "Flash Translation Layer" it's sometimes called). As a result once you have exhausted the normal reserve capacity (perhaps allowing for some early life failures) I suspect it's likely the rest of the device will soon follow and you wouldn't extend it's life by that useful an amount.

I don't have hard data however on like the "curve" of flash cell failures as an SSD ages and therefor exactly how much longer you might get based on the minimum to median cell failure.

"Where do trees get their mass?" - https://www.youtube.com/watch?v=2KZb2_vcNTg

This was highly enlightening the first time I watched it :)

This has amazed me too. Even the iOS app, until very recently, for years, had no "news feed" for all creators in one timeline like the website had. You had to click each creator individually. They finally fixed it but like..? it's the #1 obvious feature.

Me too

Unfortunately while you shouldn't try to sync with others publically is a good theory, in the current implementation just opening the share sheet to share via messages or some other app will trigger AirDrop discovery. So you'd need to actively turn the feature off.

In some ways it seems having the "Contacts only" mode enabled is almost worse than having it set to everyone. The obvious problem with having it set to everyone though is you can easily get airdropped things by people around you. Which can be a great joke but since it displays preview of image receives can also be used in harmful or abusive ways.

The way I read it their implementation was more of a proof of concept of a better privacy preserving system that works in the same way. Rather than a separate app.

See also Tom Scott's paternoster video: https://www.youtube.com/watch?v=YgJBD1wf-YQ

This is called "Split Horizon DNS". The problem is, there is no standard way to communicate this information to a machine. e.g., afaik there is no DHCP extension to say "for .internal, please see this server, for the rest, see whatever". So you pretty much have to run a server in the middle.

It -is- possible, as others have commented, to do this within the VM or container but they need a way to get that information. systemd-resolved does this. From what I understand of fly.io, the container is setup by the user, so you're not going to have control over their networking configuration or environment - is that right?

Now there is an alternative, which is instead of using .internal, to use a public facing internet hosting that is delegated to your internal DNS servers. That way they use their normal DNS, and it resolves to your nameserver. But the DNS needs to be public, and critically, if the internet DNS goes down, your .internal resolution will also stop working. Which is highly likely to cause problems for peoples applications. And also adds un-predictable latency to their local service connections which is almost certainly going to cause problems - it's not a good idea.

Having said all of that, generally speaking, it makes sense that -you- provide the DNS. It's pretty much the standard way that your 'ISP', 'Hosting Provider', etc, provides the DNS rather than relying on the public internet DNS. Only a few years ago there was no such public DNS.

The other possible alternative would be to leverage multicast DNS (libnss-mdns/avahi-daemon) or LLMNR but I'm not sure those are really ideal for this use case either. And in both cases requires resolver support that you dont get from the basic glibc resolver. So for your use case, may still not be workable.

So I think you're stuck, unless you can mandate that all of your VM images use systemd-resolved and somehow communicate the config into them.

It exists on iOS: https://support.apple.com/en-au/HT208076

Though honestly not the most obvious or accessible thing. Most people would probably just call the emergency number directly instead of using the convoluted button combination.

"You can also add emergency contacts. After an emergency call has ended, your iPhone will alert your emergency contacts with a text message, unless you choose to cancel this option. Your iPhone sends them your current location, and, for a period of time after you enter SOS mode, it sends updates to your emergency contacts when your location changes."

Sounds like Blinkist is the service for you :)

What a stupid change. They claim support can help temporarily, but still.

Let's assume for a moment they want to go ahead and disable this accidentally enabled feature, OK, but they should have changed it such that - On existing installs: You could mount existing volumes, but not create new ones - Start showing a warning to users asking them to migrate - If they are desperate, on new installs, you could potentially disable mounting existing volumes or at least and a stern warning. (The downside is for example, if your NAS died, you got a new one, migrated the drives, you can't access them again. So this is a hit and miss idea, depending on how keen they are to push disabling the feature)

The good and bad news is that in all liklihood they didn't intentionally brick existing users but instead some braindead engineer went "oh that's not supposed to be enabled it, let's disable it" and didn't think about or realise how it would affect existing users until it was rolled out. Good because less malice, bad because they should ideally have smarter engineers reviewing such things.

The problem is nothing to do with btrfs itself, synology intentionally disabled its usage on specific models in a firmware update (supposedly because it wasn't supposed to be enabled in the first place - but had let or allowed people to do so for some time).

Have you seen the "Ants Canada" youtube channel? Combines fascinating ant info with fun and very good story telling.

By my reading the article says exactly what you said.

He even says in TCP it's used in TCP it's just relatively infrequent, by comparison to UDP.

The downside of this approach bares talking about. If you compute the full desired state every few minutes it can be quite expensive depending on how/what/why you are doing it. And it can also be an O(n^2) problem that is fast enough to make it into production and slow enough down the line with more data to wreak havoc.

This was common when I was writing puppet. It was easy to have your entire puppet run take minutes - and want to run every few minutes - while consuming a LOT of cpu time including on a centralised server and not just the end host.

There are of course ways and strategies to this and not every situational falls afoul of it. But it is something you very much need to be aware of.

I otherwise whole heartedly endorse this.

I feel like the lack of CarPlay on Tesla says no. But I have no actual idea.

The way it works is that the location is encrypted with a key that is only on your device, same as iMessage. So they can't directly decrypt that info.

It's possible in theory they could add hooks into the OS to then do that next time you use the key (e.g. effectively a baked in backdoor) or maybe in some cases the key can be extracted from an iCloud backup or similar (I'm not 100% sure how those keys are stored, but it's likely detailed in their security documentation) but in general the service itself cannot see the encrypted device location.

I use this all the time not due to ISP limits but in Australia the 200-400ms latency limits you instead especially as you go over 50Mbit. Mirror command is also great :)

See also: https://ubuntu.com/security/notices/USN-4891-1

Which one are you using? I'd love this. It's usually precisely to reference it in a bug report, to a coworker, in a support case explaining software behaviour, etc.

A long time ago when I designed a zfs based backup + offsite-backup solution (having the luxury of 2 backup levels) I intentionally used ZFS replication between the data and backup but then used file-based replication between the backup and offsite-backup. I also ensured that you couldn't (at least easily) directly access or influence the snapshot state of all 3 locations by starting at one of the hosts. The offsite-backup location also had it's own point-in-time snapshots.

The reason is that (a) zfs send/recv is very fast and can be done on an hourly (or even faster) basis even with billions of files, but file-based replication (e.g. rsync or rclone) is typically slower with large file counts. We can afford to have a slower pipeline to the offsite-storage.

(b) I wanted to prevent some kind of ZFS bug in send/recv handling accidentally transferring corruption from the original data store to both backups

(c) Depending on the zfs send/recv flags that are used, it can remove snapshots not on the source host. So there is scope for both accidental and malicious deletion of all snapshots depending on the circumstance.

(d) You don't want all files being removed on the source to remove all copies in either the backup or offsite-backup location. That is the reason the offsite-backup had it's own point-in-time snapshots so that if all of the files are deleted from the source + backup, when the offsite-backup replicates that state and removes all of it's files, you can still access the files from the previous point-in-time snapshot.

(e) You don't want a hacker that penetrates 1 of the 3 storage locations to be able to cause or directly access both of the other 2 locations. This is commonly possible because SSH keys are used to allow zfs send/recv or rsync. Pivoting from a production storage to all backups (and destroying them) has happened in some high profile malicious cases, e.g. Distributed IT.. At a basic level, this means for example your backup server can't directly co-ordinate both the local and offsite backups via SSH otherwise it may have direct access to both environments and if the backup server is compromised.

It's easy not to realise data is stored inside of a particular program, rather than more easily backed up Documents folders etc. When I was very young (13-ish, year 2000) I lost primary school photos because I didn't realise that they were stored inside the Program Files directory of the Kodak camrea download software I was using and not inside of the Documents and Settings directory.

Ever since then I now backup and image the entire HDD and I have almost literally terrabytes of extra OS images "just in case" I forgot or lost something. Hasn't really happened yet. Except I still can't find my Bitcoin from 2010. Doh.

You say that, but resetting all the sessions is very publicly visible and plenty of smaller companies would paper over such things. Honestly I don't really expect any less from Github or Microsoft scale but don't kid yourself into thinking that kind of things goes un-noticed, un-investigated or un-actioned elsewhere.