claude0001
-
Content Count
607 -
Joined
-
Last visited
-
Days Won
76
Posts posted by claude0001
-
-
On 12/31/2020 at 5:49 AM, tdm said:
A bit OT but ... does Minecraft Java run on this?
Interesting question. My guess would be that, if at all, Minecraft will run unacceptably slowly.
As far as I know, there is no native implementation of a JRE on Sailfish. Here's an old and quite defunct thread about this on the Jolla forum.
Now, I see no reason why it would not be possible to install the standard Linux versions of OpenJDK or even OracleJRE on Sailfish. Initially, this would enable text-only JAVA apps. Graphics in (Linux) OpenJDK/OracleJRE depends on X11, which SailfishOS does not support out-of-the-box. That could however be fixed using XWayland, which can be installed on SFOS somehow (see e.g. here).
However, as we discussed in that same thread, even then there will be no hardware-accelerated OpenGL. In the end, you hit the same limitation as in a Linux-Chroot on Android/LineageOS: since SFOS is still using the same (Android) Kernel, the standard Linux interfaces for HW acceleration are not available, hence programs designed for desktop Linux cannot take advantage of the GPU.
-
1
-
-
On 12/2/2020 at 4:21 PM, claude0001 said:
[...] All server startup scripts in Debian are meant for systemd. They are not expected to work in a chroot (where systemd is not around). [...]
Not sure if this will still help @PokeParadox, but just in case someone stumbles upon this thread:
After reading a little bit more about chrooting modern GNU/Linux systems, I've come to the conclusion that systemd-based distributions are not very well suited for running in a traditional Unix Chroot by first principles of systemd. Although my Debian 10 was in fact doing everything I needed, I thus decided to migrate to Devuan 3 (beowulf), a distribution derived from (and almost identical to) Debian 10, but not depending on systemd.
As a result, my system feels much more solid now: In contrast to upstream Debian, the traditional (SysV) server init-scripts of Devuan can actually be used in the Chroot, so you can do things like
sudo service ssh [start|stop|status]and it will just work. Also, Devuan provides a chroot-compatible logind (elogind), so one can start a working system D-BUS session using
# service elogind start # service dbus startin the Chroot startup script, which was not possible with my previous Debian 10.
P.S.: I do not want to start a war over init systems here (which can happen quite easily in the Linux community). I do use upstream Debian (with systemd) on all my PCs and laptops, and usually do not care about the init system much. I just came to realise that, in the specific use-case of running GNU/Linux in an Android Chroot, the architecture of systemd comes with disadvantages I had not been aware of before.
-
2
-
2
-
-
3 hours ago, npatel1050 said:
[...] no, I don't want a large keyboard. It just has to be big enough [...]
I couldn't agree more. The keyboard of the N900 was fine for me and I was able to type much faster on it than on the Pro1.
I do like the fact that the Pro1's screen is larger, though. And here we come to @EskeRahn's point: if you start from the principle that the keys should cover the full width of the (landscape) screen, inevitably, the keyboard ends up too wide for me to use comfortably.
For me, the ideal combination would be a large (landscape) screen together with a narrow(er) keyboard. I'd have quite some ideas how to fill up the resulting empty space: add a dedicaded numerical keypad, a trackpad/trackpoint, or even a gamers directional pad. Not sure if many others would like those options over larger (and more distant) keys though ...
-
6 hours ago, EskeRahn said:
[...] drifting away from the Astro Glide [...]
(emphasis mine) 🤣
Sorry, couldn't resist ...
You are right, that we are going off-topic.
-
2
-
-
5 hours ago, brunoais said:
F(x)tec is trying to get all the stuff required for the phone to work linux mainlined. Maybe F(x)tec have all the drives open-source at this time?
I have read posts by Chen that could be interpreted in that way. But is this really an active and official F(x)tec development goal? I doubt it, as I thought they they do not even have the codes themselves and just license the blobs.
More likely, it could just mean that they support community-driven reverse-engineering of drivers by providing test devices to Linux kernel developers. That would certainly be a good thing. But neither technically nor legally is this the same as open-sourcing the presently-used kernel of the Pro1. It is also a much slower process and there are chances that, this way, some hardware will never work in the end. E.g. fingerprint readers are often a problem if vendors do not provide open-source drivers themselves: as their data streams are designed to be uncrackable, the drivers are often impossible to reverse-engineer (Just an example, I do not use my fingerrint reader at all, but some may think of this as important).
Anyway, having the Pro1 supported by Linux mainline -- even with some feature missing -- would of course be awesome and probably give the device a very, very long lifetime (if the hardware endures) among enthusiasts.
-
3
-
-
2 minutes ago, flx said:
I guess I like awkward hardware.
I can see nothing bad in that principle. 🙂
That said, as far as I know (from reading alone) the external display works in tandem with PlanetComputer's Android 9 apps. I wonder if it does anything when the phone is operated with the Linux OS.
-
1
-
-
35 minutes ago, Rud said:
I'd prefer dual boot so that either active OS can benefit of all the phone's resources. In your example, Sailfish is still running while you're in Linux.
Well, that's my point: Being able to use phone apps and desktop apps in parallel.
A priori, there is no technical disadvantage of both environments running at the same time on the same (Android) Linux kernel -- apart from somewhat increased RAM usage which is not really a problem on devices like the Pro1(X) that simply have enough of that.
It is true that Chroot or LXC solutions like mine (on Lineage) or @matf's (on Sailfish) do not have direct hardware access to a lot of features (telephony, GPU, GPS, ...). However, this is not a technical problem: it is a consequence of the kernel modules not being open-sourced so that the standard GNU/Linux APIs cannot be implemented. For the same reason you cannot simply install vanilla Debian on a bare-metal Pro1: its drivers are not in the mainline kernel source. In fact, the same is true for the Cosmo.
However, a manufacturer controlling the driver source code could very well make a kernel supporting full HW access from e.g. SailfishOS and a Linux Chroot/LXC running concurrently (on any device, actually).
-
1
-
-
12 minutes ago, _DW_ said:
Convergence mode is because you have everything you need on your device already 🙂
Some might have definitions of "everything you need" that differ from yours. 🙂
I'm coming from an N900. When you are used to a full Unix computing environment, there is really no way to fulfil all your needs with Android and Android Apps alone.
Example? Using my Debian chroot, I could compile and install MAD/X [cern.ch] on my Pro1:
So I am now, literally, able to design f***ing particle accelerators using the Pro1. Now go and try that with Android 😎 .
P.S.: ... OK, OK, this port was just a fun project. I'll probably never actually design an accelerator with the Pro1 (as I have MAD/X running on more powerful workstations) -- but I think you get the point now ...
-
5
-
-
27 minutes ago, _DW_ said:
android 10 is what you want for switching between phone and desktop when docked
That's totally not what I, and many others, have in mind.
We want to run a conventional desktop Linux environment (with GNU userland et al. ) in parallel to the phone OS. Please have a look at @matf's demonstration I linked above to get the idea.
We also want to run our desktop environment on-the-go (i.e. on the device's screen). I can imagine very few practical use-cases for these so called "convergence" modes (as in Android 10 and UbuntuTouch): When I am close to a big screen, there is likely already a real PC attached to it anyway, why should I then bother to use my phone as such?
-
1
-
-
20 hours ago, Rud said:
[...]
- Mechanical keyboard?!!! If it really is a low profile truly mechanical keyboard, that would be unbelievably awesome
- Full Linux support
- Dual boot
[...]
If it is the same keyboard than on the Cosmo and Gemini, it seems to be as "mechanical" as you can get. The keys are individually supported and seem to have good travel range. This also comes with some disadvantages, though, as there have been reports of "pocket dirt" going under the key caps and being difficult to remove 😄.
It is true that since mid-2020, they seem to be making good progress with their Linux distribution for the Cosmo. However, dual-boot is really not something I would like to have on my device. For the Cosmo this may be acceptable, as it is a quite awkward phone anyway.
But on a real keyboard-phablet (like the Pro1 or the AstroSlide), I want to be able to switch between the desktop Linux environment and some conventional phone OS (Android/Lineage/Sailfish ...) on-the-fly. So for the Astro, some solution like @matf's SailfishOS with jailed desktop-Linux (see this thread) would be much preferred. No idea if they are working on something like that though ...
-
2
-
I also think that the Pro1's opening mechanism is much more robust.
However, let's be nice among keyboard-lovers and recognise that the AstroSlide will have the much better keyboard -- probably more or less identical to the one its precursors had. From all that I have read, it seems to be as close as you can get to a "real" 10-finger keyboard in a PDA.
In all honesty, I find that the Pro1 is some "in-between" solution that seeks to be compatible with, both, thumb-typing as well as multi-finger operation (when the phone sits on a table). As a result, it fulfils both roles pretty badly (for me at least): I could thumb-type much faster on my (smaller) N900, and I am not really able to use more than two fingers in "desktop-mode" either.
I do not like the fact that the AstroSlide will be even larger than the Pro1 and therefore will not get one. However, unlike its predecessors, it will actually be useful as a phone and hence have the potential to be a true competitor for the Pro1, especially as it is much more powerful.
But make no mistake: the true adversaries out there are not the few other keyboard phones. It's the billions of pure touch devices that have established the idea that smartphones are mere entertainment appliances that do not need to support real computing tasks. In that sense, I wish the Astro all the luck it will need.
-
6
-
1
-
-
On 12/6/2020 at 11:40 AM, matf said:
[...] I can confirm I have write permissions on my host's $HOME with no issue, and I think I could also mount the host's / and write there. [...]
Thanks to @Linkandzelda's support, I found the solution to my write-access problem as documented in this thread.
In short: In Android (and LineageOS) write access to partitions of the internal storage (not including SD cards, apparently) is protected by a kernel-key. While a chroot environment normally preserves those keys, they are explicitly dropped (for safety reasons) in many Linux distributions when users log on remotely (e.g. via SSH). @Linkandzelda have posted a very informative how-to [external] on their own Linux-Chroot solution that (among others) discusses that problem, which -- once understood -- is actually trivial to work-around.
-
On 12/10/2020 at 6:18 PM, Linkandzelda said:
Check my page and check the section on encryption keys, that was quite important.
That was it! Thanks @Linkandzelda!
I mostly use my chroot via SSH. Even on-device, I use termbot to access the Debian CLI. As in your Arch, also on Debian the PAM config prevents SSH logins to inherit the keys by default. Instead of patching the PAM scripts, I for now simply set "UsePAM no" in /etc/sshd_config. Up to now I see no disadavantage in doing so ...
In fact, in my X11 session, access to the /data/media/0 of Android had always worked -- as you write in your how-to, the Xsession inherits the keys automatically. I had simply never tried outside of an SSH session ... 🙂
-
23 minutes ago, Linkandzelda said:
[...] Try and use xev to monitor input. [...]
I tried that of course. I'm pretty sure xev was not showing any signal for some key combinations.
I'll give it another try at some point. I am actually now pretty happy with XRDP as that way the same client app can also transport sound to the Android side. 🙂
As for the mount: I was now pretty sure that it is Android security that prevents writing to the filesystems. This may be a side effect of not using a "helper app" like Linux Deploy (that is registered in Android to have write access). I'll read the respective section of your notes and come back if I have questions. Thanks.
-
@EskeRahn
F-Droid just updated my OpenCamera. In the release notes it says: "HDR fixes for specific scenes". Maybe time to re-test.-
1
-
-
35 minutes ago, chippisc said:
Or you pay 5$ to support the devs who did an awesome job...
This.
I am a FOSS enthusiast. But unlike many, I do not think that the security advantage of FOSS stems primarily from technical superiority. The main problem with non-free as-in-'freedom' platforms is that -- sooner-or-later -- they end up being also non-free as-in-'beer'. Then, some class of users, who are more willing to download any SPOS¹ off the Internet than to pay their 5 bucks for an official copy, reach a critical mass. The rest is history. 🙂
¹ steaming pile of sh*t
-
2
-
-
Reviving an (almost) zombie thread, because I stumbled upon this:
On 1/5/2020 at 3:05 PM, Rob. S. said:[...] I'm mostly using LibreOffice on Linux (and Windows, until my desktop migration to Linux 2½ years ago) and overall I'm quite happy with it, but not only is there no compatible Android alternative, [...]
It seems like few know that Collabora, one of the major developers of LibreOffice (and many more FOSS projects), make a free (like in 'freedom') Android (and iOS) version of LibreOffice, rebranding it to "CollaboraOffice". The apps are officially recommended on libreoffice.org.
They regularly update the app to keep it in-sync with the stable LibreOffice code base. And while it is of course difficult to compare to the desktop version in terms of usability, the software does a quite good job at viewing and editing (!) documents (text, spreadsheet, and presentations) created on my Linux PCs. I haven't tested Microsoft Office compatibility much, but up to now it digested all the .docx I have thrown at it and -- logically -- I see no reason why it would not be on-par with upstream LibreOffice in this respect.
-
1
-
-
38 minutes ago, Raksura said:
[...] Installation is very easy: https://ubuntu-touch.io/get-ubuntu-touch [...]
🤦♂️ ... that was too obvious. I did not know the Pro1 had already an image listed there. Looks promising, indeed.
Thanks for the update. Still, I'll probably wait for 2021 (and more positive reviews) before I attempt the jump.
-
Thanks @Raksura, for answering your own question and posting you experience here.
I am also very interested in UbuntuTouch. But as I rely on my Pro1 as my only phone, I cannot afford to experiment too much with it.
I would well be ready to give UT a chance for a few weeks, if I could be sure that basic stuff like telephony and GPS are working at least. Apparently this is not the case yet, so thanks for the warning.
Is there any place where one can follow UT development for the Pro1, specifically (a list of open issues/bugs related to precisely that device)? What is the presently recommended way of installing it anyway? How do you get to the latest patchlevel? Does one still follow the flashing procedure form the OP, followed by in-OS-updating?
-
44 minutes ago, VaZso said:
[...] Sometimes a specific USB port has another device(s) attached and that may cause problems, so a communication like this is not really likes interrupts of other devices attached. [...]
Sounds plausible. Of course in a laptop, some internal devices are permanently present on the bus and cannot be easily disconnected. That said, I tried every port available. Both of my Thinkpads have docking stations and it does not work even with the ports on the dock, although they have their own controllers as far as I know. 🤔
Whatever, with the Raspi it works 100% reliably up to now -- good enough for me. I do not have to understand everything.
-
25 minutes ago, MickH said:
I can believe you about the USB. I always had issues connecting phones to Windows based PCs
Well, no Windows here. 😎 All my PCs are running Linux (as does the RPi3, obviously). I believe it's the USB hardware that makes the difference, not the OS.
-
On 12/4/2020 at 10:25 AM, EskeRahn said:
As some are saying that the loader thing is very picky on the ports and cables, [...]
This. That USB connectivity on the loader level is so picky about the partner device is a huge pita - it is however no problem that seems to be limited to the Pro1.
For the records: I found that the only device I can use to reliably flash my Pro1 is my Raspberry Pi3. Both of my oh-so-sophisticated Thinkpads (one with USB2, one with USB3) either do not detect the Pro1 at all or run into random errors during data transfer.
Considering how cheap the Pi3's are, I am thinking about getting a spare one just for the purpose of interfacing with the Pro1. 😄
Edit: @MickH : Good luck with your device. I would not wait forever until I simply contacted F(x)tec for a repair/replacement, though. Have you already?
-
1
-
2
-
-
4 hours ago, matf said:
[...]
It would be interesting indeed to investigate remote desktop solutions as long as the performance and security remains the same, especially if they offer better support for right clicks.
[...]
3. That here is a significant advantage of the implementation of LXC containers in SailfishOS. I *believe* you can mount any folder you want, and you will have write permissions if you want to. I only mount my Sailfish $HOME and my SD card.
Most remote desktop solutions (on Android) can emulate right click by two-finger tapping the screen. Some can even do middle click, though my MS RD8 can´t. Security should not be an issue as you can limit access to localhost only in TigerVNC or XRDP. If needed, one can then still access the device remotely via SSH tunneling. Performance is worse than in your solution as the remoting layer adds extra overhead.
Mounting my "home" in Android (i.e. /storage/emulated/0) is precisely what is working only sort-of in my chroot. Effectively, I can only read data from there, but not write there, even though the filesystem is mounted rw in the chroot, and even if I try to write as root. I assume some higher-level Android security layer stands in my way here. I do have full write access to a separate data partition on my SD card, that I can thus use for data that should be read/writable from both systems.
As for HW accel: For the reasons I discussed with @Raksura, I still fail to see how having an accelerated Wayland compositor (the patched wlroots) would automatically give you hardware acceleration in the client apps, as I think that is completely independent of Wayland. But as I say, I am no expert on this. Just a long-time (desktop) Linux user whom this (otherwise marvelous) Pro1 with its proprietary kernel blobs reminded of the value of (truly) open-source software ...
-
1
-
-
1 hour ago, Raksura said:
I thought libhybris was a replacement for (or at least part of) Mesa 3D so it would be compatible with the Android kernel.
Yes, I believe libhybris-based systems do not contain Mesa at all (but I might be wrong). I think via libhybris programs can directly use the Android rendering libraries via EGL (not OpenGL though). Note that libhybris is for much more than just graphics.
I totally agree, that by using libhybris as a workaround one can build a GNU/Linux distribution (the "GNU" is actually the major difference) ontop of an Android kernel (with closed-source drivers). SFOS and UT demonstrate that this is possible.
All I say is: this does not help people (like me and @matf) who want to (additionally) run a desktop-Linux distribution on their phones, as those do not use libhybris but a traditional GNU/Linux graphics stack. And the latter -- understandably -- expects the traditional GNU/Linux kernel interfaces to be present in order to do HW acceleration (and they aren't).
Minecraft Java on a Pro1
in General Discussion
Posted · Edited by claude0001
Sooo ... I could not resist doing the experiment. 😄 Not on SFOS/XWayland (as I do not have that on my device), but using my LineageOS/Linux-Chroot (devuan 3) with Xvnc. As argued above, I expect the two to yield quite similar results.
As expected: Minecraft Java Edition does run in principle (yay!), but with so low framerate that it is not practically useful.
What I did:
At the end of the day, this has been an interesting test of how far you can go with desktop-Linux software on our device. After all, Minecraft is a quite complex JAVA app.
One could probably tweak performance a little by tinkering with graphics settings or by getting Optifine to run. Also, my Xvnc/XRDP solution likely adds some additional graphics overhead compared to a native X11 server.
It would thus be interesting if anyone could repeat this experiment on a SFOS/LXC system like @matf showed here. The fundamental problem -- namely the lack of GPU-accelerated OpenGL -- should be the same in both cases though ...
Obligatory screenshots: