And it's well timed with HomeAssistant's new voice interaction developments. That and the news of how unprofitable Amazon and google home's offerings are.
The problem is most people only use them to set timers, start spoitfy and maybe turn on a light or two. They lack discoverability and so make poor shopping portals setting a hard cap on what other revenue sources can be found for them. This is why Amazon, Apple and Google have begun canceling or at the very least scaling back some of their smart home products.
I want Pine64 to work, but I have a shelf of e-waste because I bought in, hoping. It seems they have selectively alienated some of the developers working with their hardware, rather than feeding the community they expect to produce the software ecosystem that sits around their hardware.
Yes, but the OpenPandora is actually useful for the task. Tons of apps in the repository and not just emulation but original homebrew too. And it just works like a polished product.
After 10 years, the Pandora still is one of the best emulation handhelds out there.
I'll echo others here - they need to focus on a core set of products and get better about upstream support. They have a few legitimately good devices like the Pinebook Pro and the Pinecil. Focus on those and maybe a handful of SBCs.
AFAIK, they do next to nothing in terms of software support. It tends to come down to the community and the manufacturer of the SoC they use to make this stuff work. They're just getting cheap hardware in the hands of developers and hackers and trying to get people on-board. The RK3399 in the Pinebook Pro is very well-supported by now, though a bit old and low on RAM. I would trust that most RockChip stuff will eventually (maybe 3-5+ years after availability) get good support. The QuartzPro64 should be coming along slowly now, and I imagine once it's better-supported we'll see a Pinebook Pro 2 with the same RK3588. Similar to how we had the RockPro64 before the Pinebook Pro. The PineTab 2 and PineNote base off existing RockChip stuff (RK3566) they're already using in some SBCs (Quartz64), so we should see a lot of their devices improve at the same time.
For the same reason I expect the Orange Pi 3B and 5 Plus to mature with the current latest Pine offerings. As long as you stick to stuff with these popular chips, there's a decent chance the devices will become usable eventually. I would avoid anything too new or obscure when getting ARM devices.
All of these devices are already usable quite well for some purposes. Pretty much the level of support follows how long they were available. But neither is particularly unusable.
the pine time is one of the greatest electronics purchases I've ever made. it cost me $20 the battery lasts forever and it is the perfect minimalist smartwatch.
I think these guys are on the right track aiming for simple hardware. I will be first on the list for their bone conducting headphones
> H.264 video encoding/decoding driver isn’t in the kernel yet.
Better do H.265 because H.264 already is obsolete. It seems most of the videos made/streamed today already are either H.265 or AV1. Nevertheless supporting H.264 is also useful because the majority of old videos stored on people's drives probably is in this format.
H.264 video decoding is mainline for RK3566. Pretty sure I compiled and tested ffmpeg v4l2-requests branch for my Pinetab 2 recently and it worked (with wayland).
Yeah, RK356x has mainline support for VP8/H.264/MPEG2 decoding.
Why didn’t they just buy off the shelf rockhip? Those are affordable, have way better Linux support, similar cpu perf and an actual pcie lane so you can have a real nvme :/
> These are a set of bone conduction headphones using the same BES2300 chipset as found in the PineBuds Pro. The plan is to expand OpenPineBuds project with support for these before they enter manufacturing. Currently there is amazing work going on to sort out licencing of the BES2300 codebase; so work to support these is being done carefully to minimise impact on the code base.
It'd be cool if something materialized here. I kind of knew not to expect much for hackability with the OpenPineBuds and bit anyways, but wow, uh, was surprised just how little was available to play around and see.
Ideally someone would make some hackable Bluetooth hardware run Zephyr and Sound Open Firmware. Different class of devices, but good enough for Intel, AMD, and MediaTek to be using it as the basis for their sound firmware. It'd be great to open some access here!
Ah, more badly supported gongkai cramware, using the cheapest and hardest to obtain drivers for anything. Everything is out-of-kernel, and you're making custom kernels IF YOU CAN TRANSLATE CHINESE... And hope its made for your kernel version.
And when you say something, you'll be screamed at "these are hackers tools bla bla bla". But they don't even work with reference software. They string hardware together, and slap a PINE logo on it. You're up shit's creek, and you have to MAKE the paddle.
Or you get shit like hardware failures like "hardware destroying USB-C on the phone if the keyboard is pluged in on the Pinephone pro". Like, seriously, save your money.
After dumping $600 into this "ecosystem" I'll hard pass. And I'll speak up for the pain and suffering you're getting into if you do go this route.
Sadly (as much of a cynic as this makes me seem) I kinda figured this is exactly what would happen when the Pine people decided to partner/use MediaTek or name any other vendor who doesn't truly embrace or care about open-source. I'd spotlight Chinese SoC vendors here but that's biased, Qualcomm's track record isn't awesome here either, but it's my understanding people inside ARE trying to change that culture.
My high-level observation is the Pine people are basically selling what's effectively a "reference design" built around some questionable hardware under the guise of making an open-source hardware/phone/etc. Whether or not the device actually works as a phone, has good battery life, works reliably is kind of a secondary goal and ends up mostly resting on the shoulders of a community of unpaid software developers.
People here might be too young to remember, but there was a prior attempt at an open-phone called "OpenMoko". Despite using silicon that was more open-source friendy, it didn't really work out. It's REALLY challenging to build custom hardware, get the details right and build it on open-source software unless you're super well funded and very coordinated.
It's however not hard to sell "kits" that give you the idea they'll do something but end up tricking the end-user who doesn't find out until after the money is spent.
MediaTek has gotten much better. Yeah, my mt7621u wifi craps out a couple times a day and has to be usbreset. But in general, I think MediaTek and Qualcomm are both at B- and moving in the right direction.
This is one market, not a total picture, but looking at what OpenWRT supports is some kind of indicator. MediaTek really showed up in force for Wifi 6. Very very few 802.11ax systems were hackable, try as we might. But a bunch of very affordable pretty well performing MediaTek access points showed up early, & only more and more have been made available since.
I wish I had a real source of real information on what's forcing the bad old dirty shitty don't give a fuck world to reform into people who actually want their chips to be usable, who appreciate that having your shit upstreamed into mainline is the only way your crap isn't immediately rotting on the vine from day 0. Google's Chromebooks seemed to have had some influence, created a uniquely strong pressure to do the right thing; MediaTek seems like they've kind of had to pass the gauntlet on this, & become something more than they might have otherwise been. One of the best act's Google's ever done, having a Chromebook team that has driven hard for getting the heck out of vendor hell. Meanwhile, the Android team has the Google Kernel Image, excuse me, Generic Kernel Image (Generic Google Kernel Image at best!) to specifically enable everyone to never have to upstream their support ever again, from what it looks like (because Google will maintain a userland driver layer hitting Google APIs so folks can just ignore actual kernel support forever).
Same. I was using SailfishOS on Xperia devices and also Ubuntu Touch.
I found SailfishOS UI to be pretty bizarre and for using compiled software (Qt) the UI was oddly laggy. Basic things like attaching photos when sending an MMS were bizarre, you had to do it one at a time from the gallery app, etc.
Ubuntu Touch has a pretty reasonable UI (aside from having a start-bar like thing that you swipe in and out) but they do NOT support VoLTE at the moment which means you can't use it as a phone! Performance on Ubuntu Touch was also pretty bad even on decent hardware and while it's improved on Pixel-era devices you'd think all UI interactions would be instaneous.
Both projects seem to have made some strane prioritizations. Sailfish seems to have pointless re-invented their own UI paradigms, their own browser, etc and Ubuntu Touch doesn't seem to care the devices can't be used as phones given lack of VoLTE but they have Snaps and their own web browser...
I have an Aquaris BQ 4.5 Ubuntu phone and it's my absolute favourite smartphone I've owned (compared to a couple middle market Sony phones, Nexus 5, Nexus 5X, and my current Sony Xperia XA2 Ultra, which is way too friggin ginormous, it's as big as my hand). The dimensions are perfect for me and I really like the Ubuntu Touch OS.
Unfortunately I managed to drop it and now the screen has a dead spot in the bottom left. As that is the spot where the important icons are it means I have a device that works perfectly aside from being entirely useless (a device which resembles its owner perfectly).
You're right on the QML ; I'll admit I didn't look super hard, I was under the impression QML eventually compiled down but maybe there's some interpreter-type event loop implementation that results in a slower than expected UI.
Based on this Stackover flow post I guess it CAN be compiled but that depends on the version, open-source, commercial, etc:
JMP.chat exists but honestly that's kind of a crutch or work around if your primary cell phone can't make or receive calls on its own without ANOTHER broker or provider.
One thing I did like about Sailfish OS and to a lesser extent Ubuntu is that it's mostly "standard" Linux under the hood so you can do things like run dnsmasq or something like that and tweak it as needed.
But in this day and age I think the bare minimum for a cell phone is calling, texting (SMS), possibly MMS and GPS/maps that don't need a network or Internet connection. I'm hoping PostmarketOS, Sailfish, Ubuntu Touch, open-source-smart-phone will get there but I'm not holding my breath.
I heard rumours that the new nokia 3310 5g which will be released in may will run sailfish os. Will be interesting to see if it is true, if it will be the same mess that kaios was on the nokia 8000 or if it will actually work well.
I get some of this (have an unused Pinephone), but I'm still thankful they tried (built up a stir) and, FWIW, the PineTime is OK and the Pinecil is the best soldering iron I've seen anyone use
> I get some of this (have an unused Pinephone), but I'm still thankful they tried (built up a stir) and, FWIW, the PineTime is OK and the Pinecil is the best soldering iron I've seen anyone use
Surprised to see someone else echo my thoughts exactly, this is exactly what I've been saying for some years now whenever someone asks about buying Pine products.
The PineTime is pretty decent (though the strap included OOTB is atrocious) and the pinecil is honestly awesome.
The PinePhone is of course a disappointment, though that's par for the course for most of Pine64's stuff.
No, and I'm sure that, when you use it, the angels themselves come down from heaven and sing hymns to make your board hotter, but there's a reason I've never seen anyone use it: It doesn't cost $35.
The Pinecil is great at making things hot, even with challenging ground planes, it's very quick to reach the target temperature, and I can carry it with me in a pocket and power it from USB.
There really isn't any soldering iron even an order of magnitude close to its combination of price, power, and versatility.
I have one, but I also solder enough to justify it.
In the end, when it comes down to it the one thing that nobody should compromise on are the tips. There are open hardware soldering stations that use original hakko tips that work really well. Not sure if a similar thing exists for JBC. 10 years ago when I bought it that wasn't an option tho.
Modern tips are expensive, but the difference to older tips is that they have the temperature-sensing element in the tip (as opposed to: in the handle), that means as soon as you touch something with the iron, short temperature dips are avoided and that makes soldering easier, more pleasant and quicker.
That means the actual soldering station mainly needs to read that sensor and regulate the temperature by switching a Mosfet. That is not rocket science. Add a interface to control the temperature and maybe something that senses if the handle is put down (hall sensor in a holder?) and you are basically there in terms of functionality.
Whether it will work as reliable I can't say, but it will be at least a 75% cheaper.
I found it hard to parse whether you were describing JBC tips specifically, so as an FYI for readers, this is (AFAIK) how both JBC and Pinecil tips work (while still at very different price points)
I think some people have misplaced expectation of Pine64 hardware, because some of their products (e.g. Pinecil) have been very polished. Most of it is a better documented and more open alternative to random gadgets from AliExpress. If you want a lot more than that, it's not for you.
Maybe they should make a different brand for their products that end up being usable and polished. I think this mixed offering approach is hurting their image, which is a shame, as I see value in "cheap no-name HW, but hackable".
Yes, the Pinecil (both versions) are awesome, and if you buy several and split the shipping with friends, affordable.
But a majority of the work was done by the RalimOS project (firmware for several soldering irons). In the end, the input is DC or USB PD, a thermistor, accelerometer, volt meter, two buttons, and the output is a heating coil and a status screen.
For the soldering iron to work is several orders of magnitude lower complexity than a phone.
I’m sure they’d love for someone like Ralim to come along and write the entire OS for them. The problem is, as other posters have mentioned, there just aren’t enough millionaire programmers with nothing better to do than write a phone OS for you for free.
Every piece of hardware starts out as "out of kernel", the meaningful comparison is whether support has any chance of being upstreamed to Linux/Uboot and other such projects. And Pine64 will still fare a lot better on that score than the random fly-by-night Aliexpress vendors you're comparing them to, if only because of their FLOSS-friendly community orientation.
>you're making custom kernels IF YOU CAN TRANSLATE CHINESE
I feel this will be a useful skill to have in the mid- to long-term future if computing keeps going the way it has been going and goes where the vocal minority wants it to go.
Lest we forget, the chief force behind RISC-V advancement has been China and China is slowly but surely also coming to parity with our latest silicon. Pax Americana and English as the lingua franca aren't guarantees anymore.
Except Chinese is too hard for the world to learn, particularly in a technical context where it’s about the written form. Any logographic will have the same fate. This means it’ll end up staying within China and they’ll have a hard time globally.
Historically speaking, the countries around China started using their written characters even when they didn't adopt the language. This is one of the benefits of nonphonemic script. Certainly emoji seemed to gain broad acceptance very quickly.
The pinetime looks nice. Everything else I really want to see succeed... But it's fairly hacker-y. I like open source, but I'm not really a big fan of hackers-only stuff that doesn't just work.
Instead of releasing a bunch of half-baked hardware, Pine64 should focus on getting a decent level software support for those devices. OG PinePhone is 2 or 3 years old now, and still has crappy software support. At this point, it is reasonable to assume that Pine64 devices are a scam.
In what way are they a scam? Are they being unclear on the fact that the software is half-baked? This whole blog post is about how the software isn't ready.
Yes, it is possible by installing the Wyoming Satellite software on the Mark II. All the pieces are there, it's just missing some easy-to-install firmware.
Source: I worked at Mycroft on the Mark II and am now the voice guy for Nabu Casa (Home Assistant).
I just checked out that project, thank you! But, I don't see any instructions at all for even getting started, even after searching the issues. Is there a good place to find information? When you say "missing some easy-to-install firmware" it sounds like there is a big piece missing, no?
Now with LLM proliferation a self hosted voice assistant that actually works will become pretty possible.