Big difference! That's a full VM, while Termux is more like a Debian container. For most use cases you will have a better time with Termux, which also ships useful Android integrations such as clipboard and notifications.
Yeah but it sucks. There's a button in its settings to install a Debian chroot environment; gave it a go and it bricked itself, had to clear the app's storage and factory reset it.
Yeah, I can always use the Android Terminal once. If I re-open it, it says it's corrupted, and has to delete and re-install its minimal Debian environment.
Probably because it's trying to establish a network connection, and it might be running a networking setup that blocks until the network is up. Also, it's trying to run networking with the host so it can run things like the storage balloon driver and mounting the host filesystem.
I don't understand this comment. Yes, absolutely. Alpha versions of software absolutely suck. The end goal is making it not suck, but if it's full of breaking bugs your can't just say it doesn't suck just because they're expected.
Does it? I've looked at it only briefly (like enabled it, waited a while for it to download something big, then got a basic shell) but it seemed much less capable than Termux. Can you get cell tower info or copy to clipboard for example, or use other Android APIs?
Edit: looked into it a bit more, /etc/issue says it's a Debian 13 (latest stable), apt works with sudo (this is a locked-down device where I don't have root permission on, why does it need a fake sudo to use apt?) but of course programs like wavemon are useless because Android doesn't let you access the WiFi interface. There's no settings besides port forwarding and resetting the "partition". I don't see any documentation or info on how/whether you can interface with the rest of the system in any way. Looking on the web for Android terminal or "Linux developer environment" (as the system settings calls it) is predictably useless and only results in Google's unrelated Android SDK or other terminal emulator apps
Edit 2: okay, beware of it: I was curious if the same "you can't make the OS not kill your script" problem also happened in this OS terminal and.. it's worse. So I ran `while true; do date >> latest.txt; sleep 10; done` to see how long it'd stay alive and then did some other tasks like turning the screen off and on, opening a navigation app and zooming into a dense city, and loading a few websites. Locked the screen once more for good measure and then unlocked and opened the terminal. Guess what? It's broken. Not just crashed: I simply cannot start it anymore. The only "error handling" (Fehlerbehebung it says) step it offers is to delete all data and start with a clean system. The stack trace says there's a nullpointer in TerminalWebViewClient, with the next line being in Trichrome. It's a web browser apparently
YMMV, but I've had pretty good luck with just force closing it and launching again when getting errors like that. It doesn't necessarily mean the whole environment is corrupt, even though that is the recovery option that is presented.
It is very unreliable though. I hope Android 17 improves it, as other than the restart issues, I've generally found it to be very functional.
Even if you have Android 16 it's not guaranteed the terminal works. It's disabled by Samsung on my Galaxy A55 for some reason. Maybe the hardware doesn't support the feature.
Gadget mode can do more things than just network.
I beleive you can set up your raspberry pi zero to work as USB mass storage microsd card reader.
That seems kinda lame, until you realize you can also run transparent encryption on the raspi and unlock your SD card using passphrase entered via USB serial (also possible in gadget mode).
At first it might seem that 6 is furthest to starting point and therefore it's quite likely it will be the last one reached. However whole process is chaotic enough, that once ladybug finally arrives to 4 and/or 8, the starting position has very little impact on overall outcome.
Well the starting position has no impact on the outcome. Each number other than the starting number has exactly 1/11 chance of being the last remaining number.
yes. and the websites require you to verify transactions with (unrooted?) phone.
on the other hand phone does not require you to verify with your pc, so there's no second factor unless there is some unacessible secure island within the phone itself.
funny enough, you can probably use that website directly on the phone that you use as 2F, which probably circumvents the 2F idea (at least as long as you use SMS 2F instead of app that checks for root)
The stale-bots are even worse than that. The reporter may have responded quickly, and the bug may be acknowledged as real. But if there's simply no activity in the issue for the month following, it will be closed.
I do want to say that HPN-SSH is also well audited; you can see the results of CI tests on the github. We also do fuzz testing, static analysis, extensive code reviews, and functionality testing. We build directly on top of OpenSSH and work with them when we can. We don't touch the authentication code and the parallel ciphers are built directly on top of OpenSSL.
I've been developing it for 20+ years and if you have any specific questions I'd be happy to answer them.
It could safely be used on public internet, all this fearmongering has no basis under it.
Better question is 'does it have any actual improvements in day-to-day operations'? Because it seems like it mostly changes up some ciphering which is already very fast.
Concern about it being less secure is fully justified. I'm the lead developer and have been for the past 20 years. I'm happy to answer any questions you might happen to have.
I remember the last time I really cared to look into this was in the 2000’s, I had these wdtv embedded boxes that had a super anemic cpu that doing local copies with scp was slow as hell from the cipher overhead. I believe at the time it was possible to disable ciphers in scp but it was still slower than smbfs. NFS was to be avoided as wifi was shit then and losing connection meant risking system locking up. This of course was local LAN so I did not really care about encryption.
It's still possible but we only suggest doing it on private known secure networks or when it's data you don't care about. Authentication is still fully encrypted - we just rekey post authentication with a null cipher.
The while loop surrounds the whole thread, which does multiple tasks. The conditional is there to surround some work completing in a reasonable time. That's how I understood, at least.
reply