I've had to repeatedly mention they shouldn't remove attribution from PKGBUILDs they take from Arch ARM.
Also begging for donations to Manjaro ARM, but with no mentions of Arch ARM. This was fixed with the old announcements, but it seems like any donations has been removed from current announcements.
> We will donate $10 per unit sold to the Manjaro development team. To learn more about this scheme please click here.
But where? Currently there is Manjaro the Company and Manjaro the Community. Both has separate funds, which is partially where the treasurer drama stems from. And is there any donations to the dependant projects?
This annoys me as most of the packaging efforts are on the Arch ARM side of things, not Manjaro. You can open any of their distributed ISOs and take a look at the packager information.
You probably mean Manjaro/Pinephone or something like this, I initially thought you equated Pinephone with Manjaro. (hint for others: it is not, there are a various other compatible distros). I agree that Arch Arm upstream does a pretty good job, though that packaging job is 70% orthogonal to, say, alpine+postmarketos packaging :)
I wish PinePhone would partner with Arch or Debian instead.
Their apparent respect for their own stated internal practices was basically non-existent and their way of addressing concern raised does not appear to have been great, and their attempt to shut down discussion without explaining anything was bad, and when they did make a statement it did not feel entirely forthright or comprehensive, and it was different in many ways from what the treasurer had said, making it hard to figure out what really happened.
It doesn't appear that any money was used in an improper way (all valid project-related costs, no tickets to Disneyland), only that it was not reviewed + processed consistently with their own internal policies. The management wants to emphasize the 'no improper use' part, which is fair enough so far as it goes. But it does not make them appear trustworthy should there be a real question in the future where we need to rely on their version of events to get to the bottom of something.
Related discussion on lemmy: https://dev.lemmy.ml/post/38078
Otherwise it feels like a parasitic project masquerading as "Arch but easier." While there is truth to the latter, the oddly curious aspect to me--having been helping newbie Linux users for a couple years now--is that it seems new users generally have more long-term problems with Manjaro than they do with Arch. I don't have any facts to back this up, but speaking from my own anecdotes one would think the "easier" distro wouldn't be subject to this sort of trouble.
Also, they recently lost all of their support forum images earlier this month.
Leap is an LTS distro that is more up to date than Ubuntu LTS and Tumbleweed is a rolling release that has enough QA that it doesn't blow up as frequently as Arch.
Overall my experience has been great and I love OpenSUSE. However, I definitely would not recommend them for beginners for a few reasons.
Tumbleweed doesn't support certain browser video out of the box in Firefox. I had to enable a repository, and download libav packages to get it to work. The package names were confusing (why do I need libav 56 and 57 when 58 is already installed?). I had already installed the packages from the default repo, but they specifically needed to be installed from Packman.
GUI scaling between different displays is completely broken on Leap. Certain things scale, other things don't, and it looks horrible.
Normally, I get super annoyed when people take little things like that and make a huge issue out of them. They are little problems and I solved both of them, and love OPENS USE. But with Manjaro, I didn't have any problems from fresh install. Even switchable laptop graphics worked. Manjaro is very easy to recommend to someone afraid to open a terminal.
I don't think that necessarily absolves problems with the AUR or including AUR helpers out of the box. I do understand that the AUR is incredibly useful for a wide(r?) array of software, but I take issue with Manjaro's approach of foisting it on potentially unsuspecting users who may not know enough to understand that these are user-maintained packages that anyone could upload. I'd say I don't think it's a particularly responsible thing to do, but Manjaro's approach seems to eschew caution, throwing it entirely to the wind.
But, I confess it could be because I'm a long time Arch user protecting the status quo. I understand that the traditional approach (install base-devel, copy the target PKGBUILD, run makepkg, run pacman -U) is an obstacle to a lot of users. That said, I think it's a good thing because the community repo has a ton of commonly used software (maintained by TUs) so there isn't a huge requirement on diving into the AUR now as there was 5 years ago.
My fear is that encouraging people to blindly install PKGBUILDs via yay or pamac will eventually nail someone.
The Mobian project (Debian for PinePhone) is doing very well.
A Mobian PinePhone edition is possible - but in the meantime people can install the OS on existing PinePhones.
Word. Debian is great! In the past when I see people using Ubuntu, I always wondered why? It is so interesting how people in tech just fall into the fashion trap.
Canonical showed up to the party with a substantial concerted and sustained effort of funding/developers to take the existing Debian framework and make it more user-friendly.
In particular, Ubuntu was willing to package substantially non-free software into the experience. Things like Flash just worked most of the time. There was a substantial emphasis on usability, so that Linux-on-the-desktop could reach people with less background knowledge (everyone was doing this, of course, but Ubuntu seemed to put less emphasis on other things).
When Ubuntu emerged, Debian users were concerned that Ubuntu would take over the DFSG-software world and make it, in the long run, less free. What turned out to happen, in this case, was that the approachability of Ubuntu, built atop the Debian foundation, drew many more users away from RedHat/Fedora and ultimately strengthened the Debian/Ubuntu userbase and ecosystem. The usability really mattered -- I've repaired the occasional Debian system with Ubuntu boot-disks simply because the drivers, at the time, worked better.
Thanks to the intrinsic properties of open-source development, many of the good things about Ubuntu have found their way into Debian (and GNU/Linux at large). The Debian of today is a much more-readily usable experience than the Debian of 2004 thanks to the work of a great many people.
As someone (still) using Ubuntu today, I have 1 simple answer: OOB experience.
Back in the days, I could insert a Ubuntu live-CD (remember CDs?), and have a fully working system, including proprietary graphics-driver and wifi-firmware. And installing from that Live-CD gave me the same experience once installed.
Basically, it was a machine 100% ready to use, with everything autodetected, with absolutely zero manual effort.
Debian otoh required me to hook up a wired network connection (because those had free drivers), and then manually track down which packages contained the proprietary drivers and firmware I needed.
That single thing made a world of difference to me back then, and it still does today.
I would rather attribute it to advertising, and probably some contracts with the right people. Canonical did a lot of advertising in the past years, and contracts can mean a school mandates the installation of Ubuntu, which translates in hundreds of students becoming accustomed to it, together with some of their parents and friends, and so on.
This is something completely out of the reach for a community supported distribution like Debian; attempting to change it would mean putting a corporation behind it, which would be a recipe for destruction of its principles.
Debian is great. I particularly respect Debian as an organization. On my home laptop, I've used Debian, Arch, Ubuntu, Fedora, etc etc.
But on my work computer, I've always used Ubuntu (or sometimes MacOS), because:
- I prefer Ubuntu LTS to Debian's testing/stable approach.
- Lots of other devs use Ubuntu, so instructions are often focused on the distro
- It's always had all the drivers I need packaged with the distro
- Smaller projects are more likely to set up a PPA than host their own package repository.
May I ask why?
I realize I could do something similar with Debian, but testing isn't generally stable enough for the use cases I have in mind, whereas stable gets stuck with some very old packages. If I need a new package toward the end of the lifespan of a LTS, I can often find PPA. If not, I'll just compile it myself.
It's just my preference. To be honest, probably a big part is that Ubuntu is mostly what I've used the past decade.
Personally, I shifted to Ubuntu since it removed headaches re: getting a system running out of the box. By the time i shifted in ~2011 I had already transitioned through SLS -> Slackware -> RedHat -> Debian over the 1993-2011 period. After 18 years, Ubuntu brought relief in that I didn't have to deal with fiddling with things to get a system up and running. At that point the fun-factor of fiddling with the system had worn off and I was mostly concerned with getting work done, which Ubuntu addressed. Last time I tried Debian (~4 years ago?), it felt like it had caught up in terms of the out-of-the-box experience, which was nice.
Because I don't have a wired internet connection, and my wifi adapter requires proprietary drivers. If I could just download and install from an ISO like I can with Ubuntu, I'd switch to Debian in a heartbeat, but I don't feel like having to do manual workarounds just to get a running Linux distro.
And there lies the problem.
The Ubuntu way is to suggest installing non-free drivers from the same reputable source as the rest of the distro: by clicking your assent right there in the installer.
Debian's download page makes it hard to find the images with the non-free bits. They're there, though, if you dig just a bit.
Then, on laptops that have both Intel and Nvidia graphics hardware, for some reason the installers insist on loading both the i915 and nouveau kernel modules, which then fight over the console. (I asked over at the nouveau IRC, and they said a one-liner patch would fix that, still after all these years.) So, you add "nouveau.modeset=0" to the boot line on those laptops.
Finally, there is the confusion over the name "unstable", which is what people using Debian run, at least for the parts that need to be up to date, like browsers, media players (mpv), and firmware.
But the experience once you have got set up is better than on Ubuntu.
This was after several years of running Redhat, Suse and Debian on desktops, so I wasn’t a newbie.
for me personally easier to use installer, proprietary driver/codec support out of the box, faster release cycle, debian stable is too old for me and unstable can break at at all times/doesn't receive any major updates before new releases and so on. Also Ubuntu for the longest time used to be the only distro shipping with good font rendering settings, staring at code all day this actually was fairly important to me
so basically Ubuntu 'just works', if I ran Debian I'd just replicate Ubuntu's default settings pretty much anyway so I can just save myself the few hours.
Sid has been quite stable for me, the packages are much newer than Ubuntu (generally on par with Arch or close to it) and the few noteworthy bugs I have seen over the years have been reported and handled within 24 to 48hrs of said package being updated with the problematic code.
But they do a lot of marketing.
My impression is that Ubuntu always respected Debian and always encouraged all fixes to happen upsteeam, for example for new packages you can see that Ubuntu is asking people to submit them to Debian (so everyone benefits) https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#NEW_pa...
This seems desirable if you're setting up a PC, but is there really added value there if you're building a ROM image for a phone? It seems like you'd be doing a ton of manual installing and configuring anyway, since it's such an unusual target compared to a typical desktop, regardless of cpu architecture...
Not sure about manjaro specifically, but it looks like it will be another phosh based distro. Their forum will probably have more info eventually:
I exclusively use Arch on my other computers, so I initially put the upstream Arch ARM on my PinePhone, but it's just not in a state that most users (even tinkerers) would be inclined to work with. Manjaro and some of the other distributions are close to fully functional.
I'm sure Pine64 would love to partner with Arch ARM (or any distribution) that would like to focus on providing a good user experience on the device.
IMO, Postmarket OS provides the best experience on the device at this time.
I'll make some multi-boot SD card demo image next, perhaps with postmarket, arch linux, mobian and ubuntu touch. :)
Arch Linux to some lightweight GUI based on Xorg/i3wm takes about 8s. Similar for my Electron/X11 fullscreen based GUI for the phone (also in the video). Both are much larger.
Sadly, the Linux userspace is quite bloated, and the limiting factor is loading times from storage to RAM. You basically need to load >200 MiB of binaries/.so files to have anything useable running.
With eMMC speed of ~85MiB/s and SD card speed of 25MiB/s max for sequential reads only, you get the picture of where the most of the delay is.
blue text ≠ links → grumpy reader
“opesource” typo under “Support the project”
too simple and speedy, fast and flawless to criticize, complain, or comment
If it's Android/iOS replacement, then not at all.
I think, the way Pine64 is pushing these CE devices is smart and definitely a positive step for overall pure Linux smartphone ecosystem. But, I'm also hearing great things about Mobian on PinePhone and AFAIK it's being largely developed by an individual. I would like Pine64 to come up with a way to support these talented individual developers as well, besides supporting large well-established communities.
I personally wish for a "Linux kernel CE" edition, in the future, being one of those kernel devs. ;)
I don't know if Samuel accepts donations, but his contact info is here: https://sholland.org/about/ (he's responsible for the huge power saving optimizations that PinePhone got this year, and for the sound codec improvements, that were necessary for making calls work)
And I have a page here: https://xnux.eu/contribute.html
As for the mobian I don't know. I don't follow distributions that much.
There's plenty of stuff to do. I can give you a bunch of hints if you're a kernel dev. :)
Allwinner SoC used in PinePhone has a longstanding community around it organized around http://linux-sunxi.org/ There are a lot of materials, including datasheets there, etc.
https://wiki.pine64.org/index.php/PinePhone wiki also has a lot of information.
#pinedev at freenode is where the kernel development discussion happens, so feel free to join there.
I recently bought a new, unlocked Samsung phone on Amazon. When I put a Verizon SIM card into it, a Verizon-specific firmware module got added. I don't understand why that would be necessary.
Asking because I'm attracted to the idea of a phone I truly control, but not sure what that means for carrier compatibility.
Sprint (which is now T-Mobile) has required an activation app for their CDMA devices called SprintDM. Without it, phone will not activate and work. Most alternative OS like LineageOS don't include it, but if you activate on stock OS and don't wipe modem partitions, it continues to work. Thankfully they are transitioning to T-Mobile network.
AT&T has no activation crap but may not let imported devices based on IMEI numbers they don't have.
I still remember being at RadioShack and glancing at the Verizon section and thinking "hey, it's the island of misfit phones!"
On the other hand there must be quite a lot of embedded devices using only GSM. For example, this year the elevator maintenance company offered our housing company GSM emergency phone units to replace landline-based ones. WCDMA-supported units would have cost a few thousand euros more.
I got a Verizon SIM recently and it would not work in my iPhone 8, which I bought in Germany. Fortunately the salesperson thought to ask if it was a foreign phone! Turns out Apple only sells the Verizon-compatible phones in the US, but doesn't exactly broadcast that fact elsewhere.
The Android (or Linux) situation is probably different in the details, but not in principle.
I haven't looked in a while but IMO if you want this, the only feasible way is likely to go with carrying an internet hotspot and off-shoring 2/3/4G functionality. Ideally, a phone without the second processor is the only way to actually achieve this -- then you have "only" the chip hardware and wifi chips to deal with/secure.
I used WireShark on a hotspot that my unlocked IPhone was using and captured the visual voicemail blob used by Cricket/AT&T just last week.
Also, the SIM card toolkit can be used remotely by your provider.
Lookup SimBad exploit
The reason why I'm asking is that I have yet to find a feature phone or smartphone that my father (in his 80s) can use. He basically doesn't want to learn new things, and he's more interested in learning/memorizing repeatable steps than intuiting how to do things by reading text on the screen.
All he needs is the ability to make/receive calls, and easily get the bluetooth built into his car to connect to the phone. The bluetooth is a nice-to-have though.
I haven't had much luck with feature phones because he doesn't (want to) understand rocker switches or navigation using arrow keys. I also tried the "dummy" launchers on Android, but didn't get very far with him. He's also tried iPhones, but didn't get very far.
The funny thing is that he's pretty good with the Nortel phone he uses with his land line in terms of dialing favorites, etc.
Wireless charging is also incredibly useful as an accessibility feature for older people, but manufacturers only seem to have young people working in their product teams.
Absolutely. Some guy even made his own cool and geeky interface: https://sr.ht/~mil/Sxmo/
> Age should never be a reason for not being able to enjoy all that a modern smartphone has to offer. Our stylish smartphones bring you not only the full Android® experience and an elegant design, but also unique features that make them easier to use the older we become.
Maybe check out some video review before buying? Good luck.
I've tried having him use a "simplified" home screen on one of my old Android phones, and that didn't work very well either.
Personally, as far as "smartphones" go, I think he needs something without a home screen, and a phone app (that can't easily exit to a home screen) with a recognizable skeuomorphic UI with minimal navigation and lots of discrete buttons for performing the few actions he needs.
Right now he has a Nokia feature phone (which has virtually the same user experience as his older off-brand feature phone), and even that is too complicated for him to properly learn how to use.
The problem is that a feature phone has more features than he needs, and sometimes requires navigation to perform a task.
Also, some of the physical controls are rockers, which he doesn't seem to grasp.
If I could at least limit him to a phone app (with no easy way to get to the home screen) with discrete buttons for almost everything and almost no navigation, I think he'd be able to get by better than he does now.
"Phosh is current available on 8 different mobile distros that have been ported to the PinePhone, and Phosh is the preferred DE on 7 of those 8."
The list of those distros is in the link.
1) Is a Pinephone a viable alternative either iOS or Android?
2) How do you get it connected to carrier X?
> 1) Is a Pinephone a viable alternative either iOS or Android?
A Pinephone will never support all the proprietary apps (Facebook, Instagram, Snapchat, TikTok, Fortnite, etc). In order to be viable, I would say a phone needs to support phone calls, SMS, MMS, camera, GPS/Navigation, and have a fast and snappy web browser. Currently the Pinephone supports everything except MMS (which is necessary for "texting" pictures and groups). Because you will not have access to FB Messenger, Whatsapp, Instagram, Snapchat, etc on a Pinephone, you will have to you SMS/MMS for communication if you want to interoperate with people from the mainstream.
2) For T-Mobile based carriers in the US, you just stick in the simcard.
Actually you can access Facebook, Instagram and Twitter messages through their respective websites (and you can get notifications from the site if the browser supports it), but no WhatsApp nor Snapchat -- though Anbox might just fix this problem.
That sounds like a feature I'm excited about :).
No, probably not, not currently. It's a prototype phone, in low-production numbers, with a somewhat underpowered SOC (but with proper FOSS drivers/kernels).
The regular "Linux-distros" you would typically boot on this phone instead of iOS or Android are still under heavy development, although things are improving.
I consider the PinePhone a good first POC for a pure Linux phone, and I'm happy to have one though.
> 2) How do you get it connected to carrier X?
This applies to any phone any place in the world: You insert the SIM-card given to you by your carrier.
This is literally how it has been done since mobile phones were invented with no change. Seeing a question like this on HN honestly has me quite baffled.
Not sure how /e/ is supposed to be more private yet less open?
I'm using my i9506 (ks01lte) as a daily driver, though I think I'll switch to a i9505 because it has official lineageos support, which means probably less weird SD card bugs.
I wish I could install it on my mi a1
I am not sure how much work that would be to maintain it yourself on your particular phone, but it might not be that much? I don't really know, though.
(PS: I know supremacists will claim Android is linux but the thing about supremacists is they no real ideals so they will ignore how close Android is)
That Android contains the Linux (R) kernel is no mere "claim", rather it is the truth. Also, obviously, Android is not what anyone was thinking of when they say "Linux". This confusion stems from people using the term "Linux" both to refer to a kernel (the original and still accepted meaning) and to refer to an operating system combining said kernel with the GNU userspace.
(A lot of the apps on the Ubuntu phone were web based rather than native, which is actually a drawback when you don't have an internet connection. There was no way to do offline maps for example).
Not to mention that UBports is based on some idiosyncratic 2014-era Ubuntu-specific software that even Ubuntu moved away from. Under the hood it doesn’t at all feel like a "normal Linux" (whether you define that as the software stack found nowadays on RedHat or Debian, or the more conservative and purist approach of some other distros).
Specifically Pure Maps is available as a Flatpak and can be used in conjunction with OSM Scout Server for Offline Maps.
Also, Anbox support got almost usable in the PinePhone’s ArchLinuxARM distribution with working networking and a working keyboard just yesterday, so some Android apps are going to work. I expect Manjaro to ship at least the same level of Anbox support with their PinePhone CE.
That's not true, you can use https://open-store.io/app/pure-maps.jonnius
Offline mapping is possible by installing OSM Scout Server https://open-store.io/app/osmscout-server.jonnius
About the apps, you can help developing native apps using https://clickable-ut.dev/en/latest/
I would recommend using GTK and LibHandy. Purism has written some tutorials on their blog about writing apps for mobile GNU/Linux systems .
They do not, at least not yet. They may support anbox at some point, but that's not a given.
> How would I develop a native app for one of these?
The same as you would for any Linux distro. I would check out Plasma Mobile, as they have toolkit's and a workflow already in place is my understanding.
And hopefully never. Almost all Android apps rely on the closed-source GMS for essential functionality (eg: push notifications). There will need to be an open alternative to GMS if the goal is to support Android apps but a better idea would be to abandon Android as template basis going forward.
I think getting people onto devices that support open and flexible alternatives is the first step to actually converting users to these alternatives. I won't switch to a platform that doesn't let me communicate with people I know, and I wouldn't expect others to do so either. However, I could get people to switch from a less convenient option (e.g. Signal on Anbox) to a more convenient option (e.g. Matrix for messaging) in time.
This is a daemon that provides an API for signal
This is a libpurple plugin for it (Pidgin messenger, or even irssi, Weechat etc)
Chatty, the SMS messenger that works in Phosh also supports libpurple plugins, so presumably Signal could work alongside SMS (The SMS feature itself is a libpurple plugin IIRC)
I've used libpurple-signald with irssi and it works alright. It's not feature complete yet by a long shot, but much nicer to interact with than the Electron bloat.
Is there a serious effort on this front? At the very least a mobile version of Electron applications would be a great interim step: you just need a browser for the UI and performance-critical bits can be written in C/C++ for accuracy and speed. Ultimately a modular UI paradigm can replace the dependence on a browser but that is likely years down the road.
 Cordova used to be the model; Ionic's Capacitor project is far more advanced but targeting iOS and Android specifically.
There is a very fine repository of fully-free Android apps hosted at https://f-droid.org.
Further, I would argue that "almost all" Android apps that are free software can easily be tweaked to not rely on Google Play Services. Non-free Android apps will not be made any better by becoming nonfree GNU/Linux apps.
About Android apps, there's the Anbox project but it needs a lot of work yet.
Also an Android ROM called GloDroid exists:
Native app development depends on the OS, it differs whether you would develop for Ubuntu Touch, the GNOME on Mobile effort by Purism or for Plasma Mobile.
I checked XDA but they don't have any device specific info. Google returns sketchy pages wanting to install software. The phone is not on the list of supported devices on lineage OS website. And I have been unable to find a how-to do it yourself guide.
I followed a guide on how to do it over a decade ago and that is as far as my knowledge goes. I suspect things have changed since???
I would appreciate if someone could point me in the right direction. The device, a blu G5 plus (which when I search on XDA it returns Moto G5 ¯\_(ツ)_/¯)
Edit: Nevermind, I believe I've got it.
From what I can tell, this is the same HW, but without a different distro pre-loaded.
I'm super-stoked to try out the different distros, and will definitely give Manjaro a shot too :)
How did you get notified? I didn't receive any email since my purchase (I only have the receipt). Contacted sales@pine64 and opened up a support ticket, but haven't got any replies from them.
Anyway I did.
I also never got an order-confirmation upon ordering, but received one later quite swiftly when I emailed support and asked.
I imagine that is what the final retail version will be?
I'm on pre-order for a Librem 5, but the Pinephone is more compact, and since I'd want it essentially as a portable linux computer in addition to a regular daily driver smartphone (i.e. carry two "phones"), it might fit my needs better...
> Both configurations of the Manjaro CE PinePhones feature rev. 1.2a PCBA, introduced with postmarketOS CE that is currently shipping.
I don’t even need purposely-built Linux phone, I am OK getting one with Android and installing Linux myself. I want modern hardware (LTE, GLES 3.1, ideally optical camera stabilization), reasonably new Linux kernel, and good software support for basic functions (touch screen, phone, SMS, camera, web browser).
Pi's SOC was meant to be designed in to a variety of products, so needed to be documented and understood. Cell phone chips are dumpster fires, as a rule, and are forgotten by their manufacturer within months of first delivery.
There’re thousands of exceptionally good software developers worldwide. It’s surprising no one so far found a good way to re-purpose the hardware. The OS kernel is open source already (wasn’t the case for the original xbox), and all these proprietary firmware blobs are shipped with the devices.
Phones are hard, maybe the FOSS world should put more effort into the pine tablet for now.
Because the core system of not ready yet much less the telephony stuff, and yet here we are doing distro hoping and pretending our apps are touch friendly.
I am though wondering, if the current version is stable & working well enough to be a daily driver / main phone.