- When I need speed, I drop down to FTP/rcp or some other cleartext protocol.
Moving a terabyte database in an upgrade, I have connected three ports direct (no switch), then used xargs to keep all three connections busy with transferring the 2gb data files. I can get the transfer done in under an hour this way.
I don't currently have a performance need for an encrypted transfer, but one may arise.
- The scp program switched to calling sftp as the server in OpenSSH version 8.9, and notably Windows is now running 9.5, so large segments of scp users are now invoking sftp behind the scenes.
If you want to use the historic scp server instead, a command line option is provided to allow this:
"In case of incompatibility, the scp(1) client may be instructed to use the legacy scp/rcp using the -O flag."
https://www.openssh.org/releasenotes.html
The old scp behavior hasn't been removed, but you need to specifically request it. It is not the default.
It would seem to me that an alternate invocation for file transfer could be tested against sftp in high latency situations:
That would be slightly faster than tar, which adds some overhead. Using tar on both sides would allow transfers of special files, soft links, and retain hard links, which neither scp nor sftp will do.ssh yourhost 'cat somefile' > somefile
Windows has also recently added a tar command.ssh yourhost 'tar cf - yourdir' | tar xpf - - OpenBSD UFS did have "soft updates" which were some kind of alternative to journaling.
I believe that these were recently removed. Perhaps they don't play well with SMP.
- The normal answer that I have heard to the performance problems in the conversion from scp to sftp is to use rsync.
The design of sftp is such that it cannot exploit "TCP sliding windows" to maximize bandwidth on high-latency connections. Thus, the migration from scp to sftp has involved a performance loss, which is well-known.
https://daniel.haxx.se/blog/2010/12/08/making-sftp-transfers...
The rsync question is not a workable answer, as OpenBSD has reimplemented the rsync protocol in a new codebase:
An attempt to combine the BSD-licensed rsync with OpenSSH would likely see it stripped out of GPL-focused implementations, where the original GPL release has long standing.
It would be more straightforward to design a new SFTP implementation that implements sliding windows.
I understand (but have not measured) that forcibly reverting to the original scp protocol will also raise performance in high-latency conditions. This does introduce an attack surface, should not be the default transfer tool, and demands thoughtful care.
- Until those options are integrated into OpenSSH itself, Wayland remains in the minority.
- OpenBSD also maintains OpenSSH, which has enormous market penetration.
Their ssh supports the -X and -Y options to run remote X applications.
Let me know when those go Wayland-specific and are able to encompass the new protocol.
Until then, get comfortable in a small and discardable minority.
- Thanks, that makes sense.
Still, for user-level systemd, that means the bus is open to any binary running with the user's credentials.
This is not any worse than the risk of running ssh-agent, though.
- I am using OpenBSD on an x86-64 desktop, and X is still very much the supported graphics environment.
That said, there is interest in Wayland in these circles.
https://www.openbsd.org/papers/eurobsdcon2023-matthieu-wayla...
- As I understand it, systemctl uses D-Bus to send commands to systemd. I have read that systemd implemented their own D-Bus which is faster than stand-alone D-Bus.
So this gives me pause:
'Ever seen kwallet or gnome-keyring? Yeah, these things. These are supposed to be "secret storage" for things like signing keys, passwords, etc. They can be protected by a password, which means they are secure... right? No. No, they aren't. These secrets may be encrypted on disk, which technically prevents them from being stolen if your laptop is stolen. If you just cringed at that because disk encryption has been a thing for 20 years now or so, you're not alone. However, the best thing is this: any app on the bus can read all secrets in the store if the store is unlocked. No, this is not a #%&@ing joke. Once you input that password, any app can just read all of them without you noticing."
So, how does systemd ensure that D-Bus commands cannot originate from an unprivileged account?
Does systemd's D-Bus implementation use a different security architecture than stand-alone D-Bus?
I admit that I don't know anything about these mechanisms.
https://www.reddit.com/r/linux/comments/1lxd0hl/systemctl_vs...
- I had vaguely remembered that chitin was equivalent to cellulose in our inability to digest. The article addresses it:
"The first modification, eliminating a gene for chitin synthase, resulted in thinner fungal cell walls."
This also has an enormous potential benefit of reducing avian flu and other zoonotic bird diseases.
- The Geneva Convention ought to have something to say about how a general may and may not be attacked.
If I remember correctly, the assailant must be dressed in some sort of military uniform to be considered a prisoner of war if captured. Lacking the uniform, it would be espionage and no Geneva Convention rights.
Obviously, neither side in the conflict is adhering to these rules.
I should give this a read:
- The language that implements Python's high-speed floating point has often been FORTRAN.
- My local grocery store offered free blood testing for Vitamin D a few years ago, and I was low.
I take a 2000IU tablet a few times a week now.
- Because you are an interesting target.
- I have never tried this, as I am happier with RFID on my individual credit cards.
However, Google Pay will certainly run on my Lineage OnePlus 5. It will not provision localhost, but I am guessing that it will provision a watch.
I would go buy the parts and try it just to know, but I doubt interest would remain here by the time I assembled everything.
Edit: Graphene has a page on this subject, and Garmin appears to be the best option.
https://discuss.grapheneos.org/d/1040-compatibility-with-sma...
- I can tell you that Wells Fargo works both on Lineage with Mind the Gapps, and Graphene with the Play store installed. I have it on my OnePlus 5 and Pixel 6a.
I understand that most U.S. banking apps work on Graphene.
As far as contactless payments, try a Pixel watch. I understand that it is entirely separate from the phone.
- If you are buying now, you want a device on a v5 Linux kernel with BPF support, where the bootloader can be unlocked and VoLTE is implemented in the 3rd-party ROM.
LineageOS has a build roster of current devices at this URL:
https://lineageos.org/Changelog-30/
The Pixels are the most flexible, but don't buy a model from Verizon (they don't allow unlocked bootloaders).
Most other OEMs require you to generate an unlock token and send it to them, then wait a week, which is extrememly inconvenient (and sometimes they just stop and refuse, as I understand OnePlus has).
If you want a locked bootloader at the end of the process for security, then you will be on a later Pixel with Graphene.
- And now Android uses mksh, a free Korn clone.
I'm assuming that would have different limits than you outlined above, although I don't think they do multi core.