Preach on brother.
Liked the skalman comment, seems hi know what is going on gnu+lnx mobile.
Yeah Purism team is the best for real gnu phone.
I disagreed with most of his points as well. He talked a lot about how much more powerful the Pixel and his phone are but failed to mention the SoC Android phones use and how we don’t know what things it could be executing or phoning home in the background. Even with a de-Googled ROM, the SoC can still be invading your privacy.
I do admit Purism has a reputation problem. I do not think Purism is a pyramid scheme like he mentions but because of the delays, they have to fight an uphill battle to gain the trust of people outside of its community. For those not involved with the Librem 5’s development, they might find videos like these and not understand the work that is going on. To be clear, I’m not recommending anyone evangelize what Purism is doing – that’s for their PR and marketing teams to handle.
I haven’t seen the actual review, but clearly he doesn’t know what he is talking about when it comes to economics: what Purism is doing, has none of the hallmarks of a pyramid scheme, whatsoever.
X-rays imagining of assembled Librem 5
The video is very quiet, at least for me. Still, I think he highlights a lot of good points about the Librem 5.
We need video passthrough soon-ish.
There are inaccuracies mentioned in this video such as needing to turn off the kill switches (enable the modules) to turn on the phone. I’ve seen the slow response times and sluggish animations been mentioned here and in Rob Braxman’s video, though I don’t personally view this as a top priority; having the OS feel snappy and responsive will make it feel like a polished experience but libadwaita is still in the early stages and has a lot of room to grow. This video was more of an overview of the phone rather than a complete review.
Programming and flashing my keyboard via Librem 5. After setup everything, all I need is one command to compile and flash. The Librem 5 is a true GNU/Linux toolbox designed for the pocket.
If we think a bit further: it can/could also fix or upgrade other (maybe more important) devices without the need to carry a laptop around. You have an open source robotic arm, have an issue outside the house and all you carry with you is your phone? Plug in and flash another firmware version. At least this is my vision when I think about the future of GNU/Linux phones.
But that also means that we need open source in all the other devices we want to interact with.
and unfortunately the only one! there is lacking competition out there for true open source mobile hardware. At it’s heart it allows developers to finally create apps that are mobile friendly on Linux, so having that hardware is a necessary step for the adaptability and creation of touch friendly Linux apps to become a reality. I think several roadblocks are:
- Competition of more open source / hardware phone vendors
- Incentive mechanisms to encourage and reward developers creating apps that work well on the phone
- Some framework that will allow the creation, use of, and adoption of major platform apps to run securely on this hardware (instagram, etc.)
Elias wherever you are, thank you for the post sentence and photo even if candles scare me.
Openmoko what’s that?
Oh yeah, i’ve seen it before, cool.
Looks like 120fps 720P? i mean something look 60fps something 120fps.
No, it’s 386x522@30fps.
I checked out one of my captured videos, it was 390x526@23fps.
The cool things about his video are:
- 30 fps (7 more than what I had).
- Stability!!! You don’t know how many hangs my video had running 178 seconds. He was running 195 seconds without a single issue!
- His video has a size of 37MB, while my video has a size of 91MB! So it takes much less space for much more quality.
720p would take 4.57 times the amount of pixel and therefor lots of more computation power and 9,15 times when it should be 720p@60fps. I have no idea how much resources dos had when capturing, but a stable recording is all I want - everything else is a nice bonus.
How 37? as far i know dos is using a super fast h.264 ffmpeg profile transcoding which generates more storage size. unless dos is using vp9 which generate less storage size.
There can be three reasons:
- Better algorithm than used before.
- Pictures may just better to save data amounts (I don’t think so, but who knows).
- It’s maybe not the original file. You know, Webpages sometimes transcode the video to save storage - I don’t know if Mastodon has such features.
I guess dos has to tell us more about.
I guess dos is using VP9 video codec, to get less size, or mastodon transcoding to better video codec.
Anyways lets wait dos explaining about…
It’s actually a clip cut from a longer recording, but it’s been transcoded afterwards to fit Mastodon’s 40MB limit.
At this resolution I can encode in real-time (for as long as there’s disk space available) at up to about 35 FPS. It can go higher at lower resolutions (up to 120 FPS). I can also increase the resolution, but the framerate needs to go lower then:
2x res: ~10 FPS, 4x res (as above): ~2.5 FPS.