I've been burned too many times kick-starting things, but a tablet that supports Yocto Linux is pretty sweet. I've worked on building Yocto-based operating systems for embedded products in my last...
I've been burned too many times kick-starting things, but a tablet that supports Yocto Linux is pretty sweet. I've worked on building Yocto-based operating systems for embedded products in my last two jobs and that's an incredibly powerful amount of flexibility.
It's the defacto standard of building Linux images for embedded (I'm more of a buildroot guy myself). The implication being if there is a yocto build then you can probably do whatever you want...
It's the defacto standard of building Linux images for embedded (I'm more of a buildroot guy myself). The implication being if there is a yocto build then you can probably do whatever you want (within the constraints of hardware) if you have the time. That is cool.
As @bme said, it's the standard for building custom Linux firmware images. It's a massive open source project that allows you to very finely customize exactly what runs on your hardware, including...
As @bme said, it's the standard for building custom Linux firmware images. It's a massive open source project that allows you to very finely customize exactly what runs on your hardware, including open- and closed-source software from an upstream source, as well as your own software. It's written in Python and recipes use the bitbake language. It can be extended with both python and bash. As long as you can compile/package it for embedded, you can run it on your hardware.
You want to run docker/podman containers on your hardware? Pull in the meta-virtualization layer and add the docker recipe to your image.
Got secrets in your password manager that you want to grab at compile time and inject into your system? You can write some python/bash code to pluck it out and use it (assuming the password manager has a CLI you can use).
You can build your own bootloader. Provision your system with custom A/B partitioning. Pull in the software you want and drop what you don't. It's hard for me to not nerd out about how cool it is!
Let me try to clarify! When you go and install a Linux operating system (OS) onto your PC (what's known as an "x86 architecture" processor), you can generally just go and download some ISO image...
Exemplary
Let me try to clarify!
custom Linux firmware images
When you go and install a Linux operating system (OS) onto your PC (what's known as an "x86 architecture" processor), you can generally just go and download some ISO image from the distribution's website (a distribution, or distro, is just a flavor of Linux. Examples are Ubuntu, Fedora, Arch, etc.), boot into that image off of a USB, and install the OS onto your hard drive. Embedded processors are very different - they use an entirely different "instruction set" (referred to as assembly, byte-code, etc.) than an x86 machine, and therefore the OS is fundamentally not compatible. Some distros provide OS images that are compatible with embedded processors, but not all of them do. And not all embedded processors use the same instruction set, so the more exotic processors usually don't have out-of-the-box support for the standard OS flavors.
More importantly, for the distros that do provide an embedded flavor ISO, the hardware support isn't guaranteed. In embedded applications, such as this tablet, there's a lot of custom hardware going on, like the keyboard attachment, camera, kill switches, power button, etc. The Linux kernel (you can think of "the kernel" as the hardware-software interface code) does a great job of supporting a wide variety of relatively common and even some niche hardware. But for custom built, in-house hardware, there's no way the Linux kernel could support it because the kernel developers have no visibility into it. So, your engineering team has to write their own kernel drivers for this custom hardware. That's fine, and installing a kernel driver isn't necessarily hard, but if your production process is to flash your final product with some off-the-shelf embedded Linux OS, then install your kernel driver onto the hardware, that's going to be cumbersome and error-prone at-scale.
Enter the Yocto project. It's a platform that allows you to build your own custom distro - no more trying to find some Linux OS on the internet that supports your processor. You say what processor you're targeting, and they'll build you a barebones OS that will run on that processor. From there, you can expand on that base OS and add exactly the elements you want and skip the stuff you don't (package managers, networking stacks, etc. that come baked in to the standard flavors like Ubuntu). For example, take the keyboard interface for this tablet - the development team will probably write a USB interface for that hardware that can be used to interpret keyboard inputs. They will write that hardware-software interface code, and that gets installed into their bespoke OS through a "recipe" in their Yocto codebase. Build the image and flash it onto the device, et voilà - a custom operating system that supports your hardware. Now, when producing at scale, you take the final version of your operating system, flash it onto the hardware, and it's guaranteed to work straight out of the box.
docker/podman containers
Containerization is a methodology to run programs in a virtual environment. If you've heard of virtual machines (VMs), they're similar, but more "lightweight" due to the fact that a container does not have to spin up its own kernel, whereas a VM does. Docker is the de facto standard for containerization software, but Podman is a competitor that's gaining momentum.
meta-virtualization layer and add the docker recipe to your image
The way the Yocto project works is by having developers build "layers" and define software packages within these layers. There are lots of open-source layers, such as the meta-virtualization layer. That layer provides the information needed to build the docker executable (and all its dependencies) to run on the custom hardware. You can just grab it from GitHub and hook it into your custom Yocto-based distro, and now you've got containerization in your custom OS.
Got secrets in your password manager that you want to grab at compile time and inject into your system?
Say you write a bot to post on Reddit/Discord/etc. You need credentials to log in to the site and make the posts. If you hard-code the credentials (API keys, passwords, etc.) into your code-base, that's a massive security problem. Anybody could go find your code base and grab that password out and log in as your bot. We've got a concept called "secrets management" where you save your "secrets" (API keys, passwords) into some vault and then grab the data out only when needed.
When one of our customers wants to do a version update on our product, we don't want them to be able to open our operating system image and reverse engineer our IP. Therefore, we encrypt our OS images before handing them out to customers. At my job, I wrote a hook into our Yocto distro that, when we compile our OS, grabs the encryption/decryption keys out of our 1Password vaults, and encrypts the final payload, rather than making that a manual process.
Provision your system with custom A/B partitioning.
Mistakes happen when updating software. In the event that a customer were to update the OS on our product and something fails during the update process, we don't want our hardware to become a useless brick that they then have to ship back to us. So, we use what's called an "A/B partitioning scheme", where you hold two copies of the operating system. One of them is the "active" partition (the one you're currently booted into), and the other is the "inactive" partition. When you perform an update, you write the new operating system into the "inactive" partition. Then, at the next boot, you swap the flags and boot into the previously inactive one.
For example, if I'm currently booted into partition A and I perform an update, I will write the new OS image into partition B. When I reboot, I'll go into the new software in partition B. If it's good, I'll keep booting into partition B. Then, when I want to update again, I'll write the new new OS back into partition A and boot into that one. If the update into partition B was bad, I'll fall back to the known good state in partition A.
Hope that helps :-) I hand-waved a few concepts, but can go into more detail as needed.
Wow, that really helped a lot in terms of clarity. Because this will be an external facing product with consumers, I am guessing that these developers would opt to include things such as a package...
That's fine, and installing a kernel driver isn't necessarily hard, but if your production process is to flash your final product with some off-the-shelf embedded Linux OS, then install your kernel driver onto the hardware, that's going to be cumbersome and error-prone at-scale.
Wow, that really helped a lot in terms of clarity. Because this will be an external facing product with consumers, I am guessing that these developers would opt to include things such as a package manager, networking, etc, correct?
I'm guessing a product like this would be super lean on resources as well right, seeing as you customized it just for the hardware, so should be slightly more performant than a typical x86 tablet/computer equivalent or something like that?
Provision your system with custom A/B partitioning.
This was the one concept I was familiar with when you were originally writing about, but it is nice to reinforce that my knowledge about it is correct!
At my job, I wrote a hook into our Yocto distro that, when we compile our OS, grabs the encryption/decryption keys out of our 1Password vaults, and encrypts the final payload, rather than making that a manual process.
That's really cool! Slightly off-topic, but how different is working embedded systems on a day to day basis compared to traditional hardware? I'm guessing you have more knowledge of low level code such as assembly? Is it something you can transition into, or something you mostly learn through schooling?
Thank you again for taking the time to explain all that!
Happy to help! I'm sure a networking stack will be included, and they'll have to hook the stack into their NIC (the wifi adapter in the tablet). They'll probably use an off-the-shelf wifi module...
Happy to help! I'm sure a networking stack will be included, and they'll have to hook the stack into their NIC (the wifi adapter in the tablet). They'll probably use an off-the-shelf wifi module that has support in the kernel already (so no custom kernel code for that) and simply configure the adapter with something like systemd-networkd configurations. The Arch wiki had a good writeup on how that works. Section 3.4 shows how to set up a wifi adapter.
They might not include the package manager (Yocto ships with rpm) in their distro, but if you were to build your own OS image and flash the tablet with it, you could add it back in.
I'm guessing a product like this would be super lean on resources as well right, seeing as you customized it just for the hardware, so should be slightly more performant than a typical x86 tablet/computer equivalent or something like that?
It kind of depends. Apple silicon chips are technically ARM processors (it was a huge deal when they came out with them - none of the existing software that runs on x86 works on the different architecture without a translation layer), but the performance is great now because Apple has tuned the hardware specifically for their software needs. However, when building a product like this tablet, you generally don't design your own processor, you pick an off-the-shelf product from companies like Qualcomm. Those processors are generally less performant than an Intel or AMD x86 processor. However, the lesser performance there is generally acceptable because it helps your battery life, and you don't really need a top-of-the-line processor on a tablet that's just going to be web browsing.
You do generally cheap out on stuff like RAM for these embedded products. It helps with margins, but you also just don't need 64GB of RAM for a product like this.
You're better off comparing the performance of this tablet running stock aarch64 Ubuntu vs a custom Yocto OS - in that case, it's very likely that the Yocto-based OS will be more performant because there's less stuff (bloat) running on the OS.
... how different is working embedded systems on a day to day basis compared to traditional hardware? I'm guessing you have more knowledge of low level code such as assembly? Is it something you can transition into, or something you mostly learn through schooling?
For background, I have a BS in Electrical and Computer Engineering (2016). Much of my curriculum was in embedded systems and we exclusively learned C and Assembly and worked a lot on STM32 dev kits. I did do some perl in my unix administration class.
In my first job out of college, I worked on building application-level code - Qt-based GUI apps for Windows and Linux. I taught myself OOP on the job. From there, I found myself living in that application level and excelling, so that's really where I've stayed. I learned about Yocto in my last job and dove into it, but 90% of my work was still in the application layer, hooking libraries together to build end-user, customer-facing products. I even worked on some web front-end code, so I guess you could say I'm a full-stack developer for embedded products? I'm in a very similar role in my new job, which I started a year and a half ago. So, to directly answer your question - you absolutely can learn this stuff on the job.
I don't do much down at the kernel level, I'm just aware of it and review the mods that my co-workers make at that layer.
I haven't heard of the company/person behind this before, and tend to be skeptical of indiegogo/kickstarter projects. Doing a forum-focused search for them, there was a strong contingent...
I haven't heard of the company/person behind this before, and tend to be skeptical of indiegogo/kickstarter projects. Doing a forum-focused search for them, there was a strong contingent throughout almost every discussion of people either outright calling them scammers, or describing the products as terrible. They appear to have made a number of phones previously. There were accusations of GPL violations, bad and overpromised hardware, ages-outdated Android versions, major security failures and fundamental architectural problems, and so on.
Those are some real lofty promises they are making. The last line of their pitch: I think you might have already messed up guys! They’re promising a tablet with 256 GB of storage, 16 GB of RAM, a...
Those are some real lofty promises they are making. The last line of their pitch:
No overpromising on features or timelines
I think you might have already messed up guys! They’re promising a tablet with 256 GB of storage, 16 GB of RAM, a replaceable battery, user accessible SSD, physical kill switches, 4 USB C ports, 2 USB A ports, HDMI out, a 120 Hz OLED screen and a keyboard case. Oh, and Linux compatibility!
If they actually deliver that for $650 and on time, I’ll be shocked.
(Side rant: I absolutely hate companies using Indiegogo as a preorder platform. $100,000 is nothing for something like this. They obviously have the money or they wouldn’t have gotten this far.)
I kinda disagree. Even if they obviously have the money (which the number of tech projects i've seen get this far and fall apart because they didn't sure isn't 0), I think getting a temperature...
(Side rant: I absolutely hate companies using Indiegogo as a preorder platform. $100,000 is nothing for something like this. They obviously have the money or they wouldn’t have gotten this far.)
I kinda disagree. Even if they obviously have the money (which the number of tech projects i've seen get this far and fall apart because they didn't sure isn't 0), I think getting a temperature for the market when making something novel is important.
You might hear about how everyone wants physical kill switches or audio jacks or whatever, but it's easy to be stuck in an echo chamber, so having campaigns like this to test the waters can be beneficial to all involved, as if it doesn't hit 100k at whatever price point then you KNOW you've messed up and there's not actually that much demand, so you shouldn't throw your million+ at development and manufacturing only to find out you'll never recover costs.
I'm not saying THIS project is a great example of that, but I have seen others that I think hit the line, and it helps smooth the early process as well.
Other than the first two items, why would the rest of the features make it unfeasible to attain a $650 price point? Does making a device modular increase the cost? For the record, I'd be surprised...
Other than the first two items, why would the rest of the features make it unfeasible to attain a $650 price point? Does making a device modular increase the cost?
For the record, I'd be surprised if they kept their $650 price target as well, but mostly because I doubt their MOQ will be enough to get it that low.
They all add complexity to the project. The cost for those extra parts might be negligible (I’m sure you can get USB connectors for pennies) but each item adds to the assembly and testing process....
They all add complexity to the project. The cost for those extra parts might be negligible (I’m sure you can get USB connectors for pennies) but each item adds to the assembly and testing process. It also adds more failure points (both pre- and post-sale).
Looks cool. If this product line is still around next time I upgrade, I'll look into these again and see if they ended up being well received. I recently got one of the 2-in-1 models that's...
Looks cool. If this product line is still around next time I upgrade, I'll look into these again and see if they ended up being well received.
I recently got one of the 2-in-1 models that's basically a laptop with a 360 degree hinge from a more mainstream manufacturer. A detachable keyboard version like open_slate or Surface would probably be better, but it works fine. I was originally looking at traditional laptops and tablets, but I started seeing videos about these types of devices, and saw people were able to get Linux on them with stylus support and everything. I realized that for my preferences and use cases, this form factor was by far the obvious choice. I didn't know much about these 2-in-1s before, but now that I've used one, it seems to me like this is the future of productivity/content consumption devices the same way that dockable handhelds like the Switch/Steam Deck feel like the future of gaming devices. It's the marriage of two types of device in a way that makes both better instead of just felling like a "jack of all trades, master of none".
The big question is what size to make these things. Mine is 14 inches, which is a perfect laptop size but a huge tablet. These open_slates and Framework's version are 12 inches, which is both a pretty big tablet and a pretty small laptop.
I've had a few of these 2-in-1's, including: Surface Go 1 Thinkpad X12 Gen 1 Surface Go 2 Surface Pro 7 Samsung Galaxy Tab S7 I got the Thinkpad and the Surface Pro because I thought I'd...
I've had a few of these 2-in-1's, including:
Surface Go 1
Thinkpad X12 Gen 1
Surface Go 2
Surface Pro 7
Samsung Galaxy Tab S7
I got the Thinkpad and the Surface Pro because I thought I'd appreciate the extra power and the slightly bigger size over the rest of the tablets which are 10", but I ended-up not liking them because of the size. The power was acceptable, though not significantly better than either of the Surface Go's because all of them were fanless.
Ultimately, between the Thinkpad and the Pro, I went back to the Go 2, because a 10" keyboard is perfectly useable for regular PC tasks, it had enough power for older games and to run most simple applications and they were a great size for actually using as a tablet. I often like to play stuff like Heroes of Might and Magic in tablet format, as well as read magazines or guides for games in tablet mode and the 10" form factor is perfect for that; I can hold it with one hand and scroll, the screen is a reasonable size and it's even mostly comfortable to laydown and hold up or hold on my side.
The 12" just never felt great. They felt like too much of a compromise to me. Too large and uncomfortable to use strictly as a tablet, but using them as a laptop felt stupid because (at the time) I had a Thinkpad X1 Nano which was only a hair bigger, offered more power and a better keyboard/mouse experience. Even now, I have a big old 16" Thinkpad P1 Gen 4 and at 4lbs, it's about twice the weight of a Surface Pro, but still feels very portable and is significantly more powerful, so again I think, "Why am I not just using my proper laptop?"
The Samsung Android tablet has taken some getting used to, but it's grown on me quite a bit. I've actually stopped using my Surface Go 2 and am considering selling it because the Samsung is significantly better in terms of screen and speakers. It has sufficient enough power to play some Android games such as Civ 6, unlike the Surface Go and it still has access to Heroes of Might and Magic. Plus can emulate DOS, as well as a lot of older consoles (Dreamcast Typing of the Dead plays great. Can you tell I'm mostly game focused?) with ease and the battery life, while obviously worn, is quite good.
I do dislike how Android is pretty locked down and I need to use hacks to get to some of my files deep in the OS, but obviously you don't seem too concerned with Android given you're interested in Linux.
Anyway, all that said, 10" is absolutely where it's at for me and it feels like a perfect compliment and travel companion to my Steam Deck for when I want more intensive games, but still want the opportunity to use a proper keyboard for stuff like this post (I am using the Samsung Tab to type this. Though irritatingly, no spellcheck with the Samsung keyboard attachment), as well as have the versatility to use it how I like to use tablets.
This thing looks really interesting and I might bite since they did actually release the Brax3 successfully. As an aside, has anyone here had hands on experience with the Brax3 phone? I'm curious...
This thing looks really interesting and I might bite since they did actually release the Brax3 successfully. As an aside, has anyone here had hands on experience with the Brax3 phone? I'm curious how well it works, its performance, and how good its privacy features actually are.
I've been burned too many times kick-starting things, but a tablet that supports Yocto Linux is pretty sweet. I've worked on building Yocto-based operating systems for embedded products in my last two jobs and that's an incredibly powerful amount of flexibility.
Mind sharing what's special about Yocto Linux for those that aren't in the know?
It's the defacto standard of building Linux images for embedded (I'm more of a buildroot guy myself). The implication being if there is a yocto build then you can probably do whatever you want (within the constraints of hardware) if you have the time. That is cool.
As @bme said, it's the standard for building custom Linux firmware images. It's a massive open source project that allows you to very finely customize exactly what runs on your hardware, including open- and closed-source software from an upstream source, as well as your own software. It's written in Python and recipes use the bitbake language. It can be extended with both python and bash. As long as you can compile/package it for embedded, you can run it on your hardware.
You want to run docker/podman containers on your hardware? Pull in the meta-virtualization layer and add the docker recipe to your image.
Got secrets in your password manager that you want to grab at compile time and inject into your system? You can write some python/bash code to pluck it out and use it (assuming the password manager has a CLI you can use).
You can build your own bootloader. Provision your system with custom A/B partitioning. Pull in the software you want and drop what you don't. It's hard for me to not nerd out about how cool it is!
Unfortunately I did not understand most of what you said lol, I guess my technical skills are woefully lacking - but it does still sound cool to me!
Let me try to clarify!
When you go and install a Linux operating system (OS) onto your PC (what's known as an "x86 architecture" processor), you can generally just go and download some ISO image from the distribution's website (a distribution, or distro, is just a flavor of Linux. Examples are Ubuntu, Fedora, Arch, etc.), boot into that image off of a USB, and install the OS onto your hard drive. Embedded processors are very different - they use an entirely different "instruction set" (referred to as assembly, byte-code, etc.) than an x86 machine, and therefore the OS is fundamentally not compatible. Some distros provide OS images that are compatible with embedded processors, but not all of them do. And not all embedded processors use the same instruction set, so the more exotic processors usually don't have out-of-the-box support for the standard OS flavors.
More importantly, for the distros that do provide an embedded flavor ISO, the hardware support isn't guaranteed. In embedded applications, such as this tablet, there's a lot of custom hardware going on, like the keyboard attachment, camera, kill switches, power button, etc. The Linux kernel (you can think of "the kernel" as the hardware-software interface code) does a great job of supporting a wide variety of relatively common and even some niche hardware. But for custom built, in-house hardware, there's no way the Linux kernel could support it because the kernel developers have no visibility into it. So, your engineering team has to write their own kernel drivers for this custom hardware. That's fine, and installing a kernel driver isn't necessarily hard, but if your production process is to flash your final product with some off-the-shelf embedded Linux OS, then install your kernel driver onto the hardware, that's going to be cumbersome and error-prone at-scale.
Enter the Yocto project. It's a platform that allows you to build your own custom distro - no more trying to find some Linux OS on the internet that supports your processor. You say what processor you're targeting, and they'll build you a barebones OS that will run on that processor. From there, you can expand on that base OS and add exactly the elements you want and skip the stuff you don't (package managers, networking stacks, etc. that come baked in to the standard flavors like Ubuntu). For example, take the keyboard interface for this tablet - the development team will probably write a USB interface for that hardware that can be used to interpret keyboard inputs. They will write that hardware-software interface code, and that gets installed into their bespoke OS through a "recipe" in their Yocto codebase. Build the image and flash it onto the device, et voilà - a custom operating system that supports your hardware. Now, when producing at scale, you take the final version of your operating system, flash it onto the hardware, and it's guaranteed to work straight out of the box.
Containerization is a methodology to run programs in a virtual environment. If you've heard of virtual machines (VMs), they're similar, but more "lightweight" due to the fact that a container does not have to spin up its own kernel, whereas a VM does. Docker is the de facto standard for containerization software, but Podman is a competitor that's gaining momentum.
The way the Yocto project works is by having developers build "layers" and define software packages within these layers. There are lots of open-source layers, such as the meta-virtualization layer. That layer provides the information needed to build the
dockerexecutable (and all its dependencies) to run on the custom hardware. You can just grab it from GitHub and hook it into your custom Yocto-based distro, and now you've got containerization in your custom OS.Say you write a bot to post on Reddit/Discord/etc. You need credentials to log in to the site and make the posts. If you hard-code the credentials (API keys, passwords, etc.) into your code-base, that's a massive security problem. Anybody could go find your code base and grab that password out and log in as your bot. We've got a concept called "secrets management" where you save your "secrets" (API keys, passwords) into some vault and then grab the data out only when needed.
When one of our customers wants to do a version update on our product, we don't want them to be able to open our operating system image and reverse engineer our IP. Therefore, we encrypt our OS images before handing them out to customers. At my job, I wrote a hook into our Yocto distro that, when we compile our OS, grabs the encryption/decryption keys out of our 1Password vaults, and encrypts the final payload, rather than making that a manual process.
Mistakes happen when updating software. In the event that a customer were to update the OS on our product and something fails during the update process, we don't want our hardware to become a useless brick that they then have to ship back to us. So, we use what's called an "A/B partitioning scheme", where you hold two copies of the operating system. One of them is the "active" partition (the one you're currently booted into), and the other is the "inactive" partition. When you perform an update, you write the new operating system into the "inactive" partition. Then, at the next boot, you swap the flags and boot into the previously inactive one.
For example, if I'm currently booted into partition A and I perform an update, I will write the new OS image into partition B. When I reboot, I'll go into the new software in partition B. If it's good, I'll keep booting into partition B. Then, when I want to update again, I'll write the new new OS back into partition A and boot into that one. If the update into partition B was bad, I'll fall back to the known good state in partition A.
Hope that helps :-) I hand-waved a few concepts, but can go into more detail as needed.
Wow, that really helped a lot in terms of clarity. Because this will be an external facing product with consumers, I am guessing that these developers would opt to include things such as a package manager, networking, etc, correct?
I'm guessing a product like this would be super lean on resources as well right, seeing as you customized it just for the hardware, so should be slightly more performant than a typical x86 tablet/computer equivalent or something like that?
This was the one concept I was familiar with when you were originally writing about, but it is nice to reinforce that my knowledge about it is correct!
That's really cool! Slightly off-topic, but how different is working embedded systems on a day to day basis compared to traditional hardware? I'm guessing you have more knowledge of low level code such as assembly? Is it something you can transition into, or something you mostly learn through schooling?
Thank you again for taking the time to explain all that!
Happy to help! I'm sure a networking stack will be included, and they'll have to hook the stack into their NIC (the wifi adapter in the tablet). They'll probably use an off-the-shelf wifi module that has support in the kernel already (so no custom kernel code for that) and simply configure the adapter with something like systemd-networkd configurations. The Arch wiki had a good writeup on how that works. Section 3.4 shows how to set up a wifi adapter.
They might not include the package manager (Yocto ships with
rpm) in their distro, but if you were to build your own OS image and flash the tablet with it, you could add it back in.It kind of depends. Apple silicon chips are technically ARM processors (it was a huge deal when they came out with them - none of the existing software that runs on x86 works on the different architecture without a translation layer), but the performance is great now because Apple has tuned the hardware specifically for their software needs. However, when building a product like this tablet, you generally don't design your own processor, you pick an off-the-shelf product from companies like Qualcomm. Those processors are generally less performant than an Intel or AMD x86 processor. However, the lesser performance there is generally acceptable because it helps your battery life, and you don't really need a top-of-the-line processor on a tablet that's just going to be web browsing.
You do generally cheap out on stuff like RAM for these embedded products. It helps with margins, but you also just don't need 64GB of RAM for a product like this.
You're better off comparing the performance of this tablet running stock aarch64 Ubuntu vs a custom Yocto OS - in that case, it's very likely that the Yocto-based OS will be more performant because there's less stuff (bloat) running on the OS.
For background, I have a BS in Electrical and Computer Engineering (2016). Much of my curriculum was in embedded systems and we exclusively learned C and Assembly and worked a lot on STM32 dev kits. I did do some perl in my unix administration class.
In my first job out of college, I worked on building application-level code - Qt-based GUI apps for Windows and Linux. I taught myself OOP on the job. From there, I found myself living in that application level and excelling, so that's really where I've stayed. I learned about Yocto in my last job and dove into it, but 90% of my work was still in the application layer, hooking libraries together to build end-user, customer-facing products. I even worked on some web front-end code, so I guess you could say I'm a full-stack developer for embedded products? I'm in a very similar role in my new job, which I started a year and a half ago. So, to directly answer your question - you absolutely can learn this stuff on the job.
I don't do much down at the kernel level, I'm just aware of it and review the mods that my co-workers make at that layer.
Edit: hit post too soon!
I haven't heard of the company/person behind this before, and tend to be skeptical of indiegogo/kickstarter projects. Doing a forum-focused search for them, there was a strong contingent throughout almost every discussion of people either outright calling them scammers, or describing the products as terrible. They appear to have made a number of phones previously. There were accusations of GPL violations, bad and overpromised hardware, ages-outdated Android versions, major security failures and fundamental architectural problems, and so on.
Does anyone here have any experience with them?
Those are some real lofty promises they are making. The last line of their pitch:
I think you might have already messed up guys! They’re promising a tablet with 256 GB of storage, 16 GB of RAM, a replaceable battery, user accessible SSD, physical kill switches, 4 USB C ports, 2 USB A ports, HDMI out, a 120 Hz OLED screen and a keyboard case. Oh, and Linux compatibility!
If they actually deliver that for $650 and on time, I’ll be shocked.
(Side rant: I absolutely hate companies using Indiegogo as a preorder platform. $100,000 is nothing for something like this. They obviously have the money or they wouldn’t have gotten this far.)
I kinda disagree. Even if they obviously have the money (which the number of tech projects i've seen get this far and fall apart because they didn't sure isn't 0), I think getting a temperature for the market when making something novel is important.
You might hear about how everyone wants physical kill switches or audio jacks or whatever, but it's easy to be stuck in an echo chamber, so having campaigns like this to test the waters can be beneficial to all involved, as if it doesn't hit 100k at whatever price point then you KNOW you've messed up and there's not actually that much demand, so you shouldn't throw your million+ at development and manufacturing only to find out you'll never recover costs.
I'm not saying THIS project is a great example of that, but I have seen others that I think hit the line, and it helps smooth the early process as well.
They sell a phone called the Brax3
Other than the first two items, why would the rest of the features make it unfeasible to attain a $650 price point? Does making a device modular increase the cost?
For the record, I'd be surprised if they kept their $650 price target as well, but mostly because I doubt their MOQ will be enough to get it that low.
They all add complexity to the project. The cost for those extra parts might be negligible (I’m sure you can get USB connectors for pennies) but each item adds to the assembly and testing process. It also adds more failure points (both pre- and post-sale).
Indiegogo page: https://www.indiegogo.com/en/projects/braxtechnologies/open_slate
YouTube trailer: https://youtu.be/dyEYum3cIQQ
Specs: https://community.braxtech.net/t/open-slate-megathread/4041
Looks cool. If this product line is still around next time I upgrade, I'll look into these again and see if they ended up being well received.
I recently got one of the 2-in-1 models that's basically a laptop with a 360 degree hinge from a more mainstream manufacturer. A detachable keyboard version like open_slate or Surface would probably be better, but it works fine. I was originally looking at traditional laptops and tablets, but I started seeing videos about these types of devices, and saw people were able to get Linux on them with stylus support and everything. I realized that for my preferences and use cases, this form factor was by far the obvious choice. I didn't know much about these 2-in-1s before, but now that I've used one, it seems to me like this is the future of productivity/content consumption devices the same way that dockable handhelds like the Switch/Steam Deck feel like the future of gaming devices. It's the marriage of two types of device in a way that makes both better instead of just felling like a "jack of all trades, master of none".
The big question is what size to make these things. Mine is 14 inches, which is a perfect laptop size but a huge tablet. These open_slates and Framework's version are 12 inches, which is both a pretty big tablet and a pretty small laptop.
I've had a few of these 2-in-1's, including:
Surface Go 1
Thinkpad X12 Gen 1
Surface Go 2
Surface Pro 7
Samsung Galaxy Tab S7
I got the Thinkpad and the Surface Pro because I thought I'd appreciate the extra power and the slightly bigger size over the rest of the tablets which are 10", but I ended-up not liking them because of the size. The power was acceptable, though not significantly better than either of the Surface Go's because all of them were fanless.
Ultimately, between the Thinkpad and the Pro, I went back to the Go 2, because a 10" keyboard is perfectly useable for regular PC tasks, it had enough power for older games and to run most simple applications and they were a great size for actually using as a tablet. I often like to play stuff like Heroes of Might and Magic in tablet format, as well as read magazines or guides for games in tablet mode and the 10" form factor is perfect for that; I can hold it with one hand and scroll, the screen is a reasonable size and it's even mostly comfortable to laydown and hold up or hold on my side.
The 12" just never felt great. They felt like too much of a compromise to me. Too large and uncomfortable to use strictly as a tablet, but using them as a laptop felt stupid because (at the time) I had a Thinkpad X1 Nano which was only a hair bigger, offered more power and a better keyboard/mouse experience. Even now, I have a big old 16" Thinkpad P1 Gen 4 and at 4lbs, it's about twice the weight of a Surface Pro, but still feels very portable and is significantly more powerful, so again I think, "Why am I not just using my proper laptop?"
The Samsung Android tablet has taken some getting used to, but it's grown on me quite a bit. I've actually stopped using my Surface Go 2 and am considering selling it because the Samsung is significantly better in terms of screen and speakers. It has sufficient enough power to play some Android games such as Civ 6, unlike the Surface Go and it still has access to Heroes of Might and Magic. Plus can emulate DOS, as well as a lot of older consoles (Dreamcast Typing of the Dead plays great. Can you tell I'm mostly game focused?) with ease and the battery life, while obviously worn, is quite good.
I do dislike how Android is pretty locked down and I need to use hacks to get to some of my files deep in the OS, but obviously you don't seem too concerned with Android given you're interested in Linux.
Anyway, all that said, 10" is absolutely where it's at for me and it feels like a perfect compliment and travel companion to my Steam Deck for when I want more intensive games, but still want the opportunity to use a proper keyboard for stuff like this post (I am using the Samsung Tab to type this. Though irritatingly, no spellcheck with the Samsung keyboard attachment), as well as have the versatility to use it how I like to use tablets.
This thing looks really interesting and I might bite since they did actually release the Brax3 successfully. As an aside, has anyone here had hands on experience with the Brax3 phone? I'm curious how well it works, its performance, and how good its privacy features actually are.