Pinebook Pro

[SianBuForLyfe]

Anyone using?
Just happen to chance upon pinebook pro and it looks good.

Running on manjaro

 

[davidktw]

Anyone using?
Just happen to chance upon pinebook pro and it looks good.

Running on manjaro

Has the pinebook, under powered. Pinebook Pro is better, but have reasonable expectation on it. You can watch various unboxing on youtube, plentiful of people have reviewed as they got theirs.

 

[SianBuForLyfe]

Has the pinebook, under powered. Pinebook Pro is better, but have reasonable expectation on it. You can watch various unboxing on youtube, plentiful of people have reviewed as they got theirs.

Thanks!
Going to get the pinebook pro!
Hope the shipping from hk doesn't take long

 

[Rock-kun]

You guys are amazing.

I cannot ever see myself using any ARM hardware for desktop Linux as I cannot stand the idea of not being able to compile the latest software and applications directly from upstream without extensive patches.

Am permanently tied to x64 because of this. If I want a low-power processor for light computing, I'll buy one of those Apollo Lake or Gemini Lake laptops from China.

 

[davidktw]

It is not what platform you use or how you get the platform that matters. What really matters is your deliverables using that platform. Platform are just intermediary. Majority deliverables are done without the need to compile anything from the source. If you are so concern about end-to-end, you should be really concern about how these software are written. Otherwise you just merely choose to take a piece of work, done by very intelligent people, and your focus is grinding them thru a compiler and building process. I can’t say building process isn’t important. In fact, building process is very important, but it is not in totality the entire process.

ARM while still in the growing stage of competing with Intel and AMD for fast system isn’t at all uncommon in a lot of platforms, from embedded devices, mobile devices, mainstream laptop to server class cloud system. So whether you decide to embrace it or not, it is certainly your choice. The trend to move numerous platforms into ARM has certainly happened, not what if, but how much more it will be used in the industry and products.

 

[Rock-kun]

Otherwise you just merely choose to take a piece of work, done by very intelligent people, and your focus is grinding them thru a compiler and building process.

That is my core focus. To be able to take upstream code and compile them into something usable well in advance of the official release date.

I don't like the idea of being dependent on 'someone else' to provide binaries for me. If I know how to take the sources and turn them into binaries by myself, why be at that 'someone else"'s mercy?

And given how many applications still cannot compile natively on ARM (huge amount of out-of-tree patches required that only a developer will know), ARM is not even a consideration.

If I really had to go with ARM, i'll move my computing platform to Windows at the same time. Unlike Linux, I believe Microsoft has a much better chance of convincing developers that ARM-specific patches needed for building the software has to be done at upstream, and not maintained as downstream patches.

One huge example where this comes in handy is Chromium. Unlike Chrome, Chromium builds do not ship with proprietary av codecs and it still uses X, making it dependent on XWayland in a Wayland session.

My Chromium builds have proprietary av codecs enabled at build time along with the Ozone layer that allows it to run as a native Wayland application. Same for Firefox; I was already building Wayland versions of Firefox from the upstream source code since v60, well before Mozilla flipped the building the Wayland version as the default build option for Linux.

Same for GIMP and Audacity; both are still built using GTK2 and thus still rely on X. For Audacity, it's even worse, the GTK2 builds cannot handle HiDPI displays, so the GUI on such displays is a complete mess.

I grabbed the source code for the development version of GIMP and toggled the build switch to use GTK3 instead so that I had a Wayland-native version of GIMP to use. Same for Audacity; building the sources and flipping the GTK3 option on meant that I have a Wayland-native version of Audacity with full support for HiDPI displays.

Virtually all of these will not be possible for me on ARM because of the amount of x86-isms that are present in the sources of most toolkits and applications due to its ubiquity. It's practically impossible to expect that a source code bundle that builds on x64 can even compile successfully on ARM.

 

[davidktw]

That is my core focus. To be able to take upstream code and compile them into something usable well in advance of the official release date.

I don't like the idea of being dependent on 'someone else' to provide binaries for me. If I know how to take the sources and turn them into binaries by myself, why be at that 'someone else"'s mercy?

And given how many applications still cannot compile natively on ARM (huge amount of out-of-tree patches required that only a developer will know), ARM is not even a consideration.

If I really had to go with ARM, i'll move my computing platform to Windows at the same time. Unlike Linux, I believe Microsoft has a much better chance of convincing developers that ARM-specific patches needed for building the software has to be done at upstream, and not maintained as downstream patches.

One huge example where this comes in handy is Chromium. Unlike Chrome, Chromium builds do not ship with proprietary av codecs and it still uses X, making it dependent on XWayland in a Wayland session.

My Chromium builds have proprietary av codecs enabled at build time along with the Ozone layer that allows it to run as a native Wayland application. Same for Firefox; I was already building Wayland versions of Firefox from the upstream source code since v60, well before Mozilla flipped the building the Wayland version as the default build option for Linux.

Same for GIMP and Audacity; both are still built using GTK2 and thus still rely on X. For Audacity, it's even worse, the GTK2 builds cannot handle HiDPI displays, so the GUI on such displays is a complete mess.

I grabbed the source code for the development version of GIMP and toggled the build switch to use GTK3 instead so that I had a Wayland-native version of GIMP to use. Same for Audacity; building the sources and flipping the GTK3 option on meant that I have a Wayland-native version of Audacity with full support for HiDPI displays.

Virtually all of these will not be possible for me on ARM because of the amount of x86-isms that are present in the sources of most toolkits and applications due to its ubiquity. It's practically impossible to expect that a source code bundle that builds on x64 can even compile successfully on ARM.

All I can say the choice is yours. Is it better? Unfortunately my experience dealing with the entire software development workflow from writing to building to deployment to operation, is that building is just one part of the workflow, you are always dependent whether you like it or not, you are thinking at the dependency of building, but the most crucial part is the code, not the building process that determines compatibility and stability.

In fact, that fact that you don’t even write the make and configure script, you are already at dependency. Your building process done by yourself is merely running it thru the grinder with your own options, if there are options at all. Which is helpful if you need to select uncommon options. Most of us have more important focus in our line of work, which includes better parts of the entire workflow like ensuring project are on schedule, deployments are properly tested, code reviews are done properly, bugs are fixed promptly, patches from upstream are applied consistently and automatically without downtime or very little downtime. Compiling a set of codes not written by us is just carry out the very same thing done by the maintainers, and not necessarily that you can do it better.

Hence I can only say, focus on the bigger picture. Time is limited, there are alot of things to do in life and building is not the core of it. Planning and strategy makes larger changes in the entirety. That being said, it is your life and your workflow, hence you are free to choose what works for you; thus your choice.

 

[joesph]

 

[joesph]

 

[Rock-kun]

Most of us have more important focus in our line of work, which includes better parts of the entire workflow like ensuring project are on schedule, deployments are properly tested, code reviews are done properly, bugs are fixed promptly, patches from upstream are applied consistently and automatically without downtime or very little downtime. Compiling a set of codes not written by us is just carry out the very same thing done by the maintainers, and not necessarily that you can do it better.

Hence I can only say, focus on the bigger picture. Time is limited, there are alot of things to do in life and building is not the core of it. Planning and strategy makes larger changes in the entirety. That being said, it is your life and your workflow, hence you are free to choose what works for you; thus your choice.

If my focus was only to 'get things done'. I will be a devoted Windows user.

My productivity on Linux is no where near Windows levels.

 

[Tony.Manero]

No thunderbolt 3