Arm64
Keena Wiegert
It's a lot simpler and safer to recreate a container of Joplin as a docker container. Compared to a normal installation of Joplin.
Since it is easier to make backups of files from a container. Then having to rollback an entire system in case something goes wrong.
I and my friend would really appreciate if this would be make.
Since we run our low cost and low power consumption servers as a pi 4 arm64 installation.
And the only thing we are missing is getting Joplin on our servers as well.
I also know there is a large pi community on arm64 and they would probably appreciate it as well.
Is this behaviour intended? Now anybody can read private values from the framework from this json file. I would expect that at least this will be opt-in feature of Xcode. After little bit of searching I have found that this can be turned off by OTHER_SWIFT_FLAGS = "-Xfrontend -empty-abi-descriptor"; in the Build Settings. Another thing is that there is very little documentation about this feature. I think this can be a big surprise for some SDK developers that suddenly XCode reveals their private values in the arm64-apple-ios.abi.json file.
I have also noticed that this file is created only if BUILD_LIBRARY_FOR_DISTRIBUTION is set to YES in Build Settings. I have tried building my XCFramework with Xcode 14.1, removing arm64-apple-ios.abi.json and then use it in my app in Xcode 14.3 and it worked fine. So I am not sure if this file is required to support Library evolution or not.
Hey @jakub-vallo , This abi.json file isn't required for supporting library evolution at all. The most common usage for this file is to serve as an input for ABI stability checking purposes using the swift-api-digester tool (swift/swift_api_digester_main.cpp at main apple/swift GitHub), where two JSON files are specified for comparison. You've made a great point that whether we should turn this output file into an opt-in output instead of always emitting it when BUILD_LIBRARY_FOR_DISTRIBUTION is specified though. Could you file an GitHub issue for this?
I got an existing installation up and running in arm64 after a rebuild and some basic sanity check to make sure the frontend loads. However, a ./launcher logs web_only shows that rails.stderr.log is constantly being filled with these:
I was able to make this work end to end with STM32CubeProgrammer and IAR on Windows 11 ARM64 (running in Parallels on an Apple M1). To make that work, I have removed all references to the certificate signatures (CAT files) from INF files.
To install, you need to temporarily disable driver checks: -to-fix-the-third-party-inf-doesnt-contain-digital-signature-information/ (use the temporary solution 3 - Reset while holding Shift). After rebooting with driver signature checks, go to Device Manager, find the STLink device and manually specify the folder where you've unzipped the file attached below.
I made the modifications and because the inf changed Windows fails to install the driver (tampering). Because the driver is signed and the signature changed, I don't know of a simple way to disable the check. This means there is no viable workaround for now for all Windows ARM64 users.
The changes I've made cannot work (for security reasons as the driver package is signed). The changes are following driver documentation from Microsoft here: -us/windows-hardware/drivers/install/inf-controlflags-section
I have attached only the INF files from the STLink driver. These have been changed from NTamd64 to NTarm64. The correct fix is to add another arm64 section (i.e. wherever amd64 is used, add something similar for arm64).
TeamViewer crashes often on my Surface Pro X which runs Windows 10 on ARM (arm64). This device can run 32-bit apps through emulation when no native arm64 is available, which is the case for TeamViewer. So TeamViewer runs in 32-bit on this device.
When a crash occurs (e.g. when remotely controlling a customer's device), a log is visible in the Windows Event Viewer.
Would be great if TeamViewer was available natively on Windows on ARM though, instead of running as an emulated 32-bit application. CPU usage is quite high currently, and the battery life would definitely benefit from a native ARM version.
I'm planing to purchase a Microsoft surface pro x device, but I'm hesitated because as you've mentioned most of the windows applications runs on the Surface uses the 32-emulator, the most important application I need is teamviewer & without confirming it runs on the Surface without any problems there is no point of purchasing it except wasting my money.
I gotta say that the 32-bit version of TeamViewer has been working fine on my Pro X - I had issues with hardware acceleration in the beginning, but those have been resolved in the meantime (I believe through a display driver update on Microsoft's side).
Tried the 64-bit version two weeks ago on Windows 11 (which supports 64-bit emulation) but it crashed when I tried to connect to another computer. The 64-bit emulation in Windows 11 is slightly buggy still, so I expect that to improve over time.
I think it's just a matter of time for TeamViewer to come up with a native ARM64 version of Windows. As a developer I know that a lot of toolchains/dependencies have been updated to support ARM64 lately (which I've been contributing to myself as well), so it should become easier and easier for TeamViewer to port things to ARM64 ??
Hi
I have been using the TL Linux app during several years for work on the NSC Triolith and later Tetralith systems. AFAIK NSC never implemented the Web Access part of TL.
Any chance you will release a TL client for ARM64, not HF or consider a release for Android?
Hi Peter, as far as I know there is nothing currently on the roadmap, but perhaps one of the dev team can clarify (@samuel)? Web Access was intended to provide ThinLinc access from platforms without a native client available, like Android/iOS. So the path of least resistance may be asking NSC to activate the web access component.
In fact, IMHO it would be a great move - and probably best - if cendio could consider to open-source the client and move development of it to, e.g. GitHub so that interested third-party developers (like me) could contribute / develop own client versions and also potentially merge these changes back via pull requests.
IMHO the ThinLinc infrastructure could benefit a lot from open up more regarding open source and public development on GitHub&Co. And especially the TL client should be somewhat uncritical to open the development, which could help to significantly increase the community around ThinLinc (which is still rather small given the great technology behind this product!).
May I ask back here what the roadmap/priority regarding ARMv8/aarch64/arm64 binaries of the ThinLinc client are? As we are currently moving over from x86-based ThinClients to ARM-based ones (e.g. RaspberryPi4) and would like to use our own thinclient OS (thinRoot) with it, it is curial that the ThinLinc client is also provided as pure 64bit ARMv8/aarch64/arm64 binaries. So please consider investing some time into this as you would anyway have to go the ARM road due to the switch over of macOS from x86 to Apple Mx ARM processors.
And in addition, please keep in mind that it would still be great if you could open source the ThinLinc client at least (e.g. in GitHub) so that third-parties (like me) can compile the client for their own needs at least.
We have a release coming up this summer, after which planning will commence for future versions. Different client architectures will likely be a part of this discussion, but as of now there is nothing on the roadmap. Appreciate your input, though, and it will be taken into consideration.
I began by trying to install xubuntu-desktop, and then tried xfce4, and other packages (like GIMP) on a freshly installed Ubuntu Server 20.04 on my Raspberry Pi 4 but apt reported that it couldn't find these packages. This is very similar to another report here: Apt can't find package libasound2-dev 20.04 arm64
I suppose if I reset my RPI4 during the first couple minutes of the initial boot (display issues)... Could this cause unattended-upgrades to fail to complete or download package/repo data, for example?
You should see quite a few arm64 entries listed. There will be a few "404 not found" as repos move around. The problem is that many of the development packages for arm64 (notably libx11-dev) are in "ports"
I am happy to announce that as of versions 8.10.7, 9.0.2 and 9.2.1 the official Debian images support arm64. As support is brand new, it should be considered somewhat experimental at this stage. Any form of feedback is greatly appreciated.
Historically the Haskell images used Debian packaging to install GHC + cabal-install. Unfortunately this packaging was slow to update and caused the docker images to often be lacking the latest versions (and the Debian packaging now seems to be fully abandoned).
I am especially happy to hear that images with new versions of GHC and cabal-install will be released more quickly thanks to use of official releases instead of Debian packages. FYI: I maintain a docker-ghc project that I use to create local container images for testing new versions of GHC, such as release candidates. There are build scripts for manual installation as well as installation via ghcup. The key feature of this project is that it creates images that use a non-root user with the UID and GID of the host user so that the host filesystem can be mounted without having to deal with file ownership issues.
d3342ee215