6 ms·

Axle OS

250 points by mmphosis 3y ago

josephg 3y ago
This is super cool! I’ve had an idea I’ve been wanting to build into an OS for ages - where we use versions, message passing and structured patches to pass information between the kernel and application processes. So an application can subscribe to a file / USB device state / list of running processes / anything using a common, standard API. But it sounds really daunting to try and hack something like into the Linux kernel or something in one go. If I want to experiment with something like this, what do you recommend? How hard would it be to do something like that in a hobby kernel like Axle?
- blown_gasket 3y ago
  I've been pondering this for a moment and if I were to write an application for such a system I don't think I'd enjoy it. If you want to pass information from the kernel and bubble that all the way to the application to do something with it, I would think you now have to write signal handling in your application.
  - josephg 3y ago
    Obviously, the signal handling code can live in a library of some sort. With a generic, system wide api there’s no reason you couldn’t still poll if you really wanted to. But maybe at least with a version token. So the application can say “I want info on which processes are running. Last time I asked, you gave me token 5827275” and the kernel can respond and say “you’ve got the most recent version of that data already champ”.
- ww520 3y ago
  Linux exposes system information like processes and devices in the psuedo file system hosted at the mount point /proc. Any user mode programs can use the standard file IO API to access them. Some of the "files" like /proc/self/mounts are pollable, i.e. a program can use blocking select to wait for changes like when a new file system has been mounted.
  - josephg 3y ago
    Yeah, I know how it works in linux. I just hate it. Polling and writing a parser for a pseudo-file always seems like a super roundabout, inefficient, brittle way to send information from kernel to userspace. Think about it - the kernel stores some data in a nice, neat struct. And the kernel knows exactly when that struct is modified. Userspace wants that data, and wants to know when the data changes. So every second, userspace "reads" a pseudo file. The kernel packs the struct's contents into a big string with some sloppy, hand written text format and passes it to userspace. Then in userspace you need to write a brittle parser for whatever the kernel gives you, knowing that in different versions of the kernel you'll get slightly differently formatted strings. When the data changes in the kernel, the application has no way of being notified. It just polls and parses in a loop. Its both inefficient (when there are no changes, its all wasted effort). And its laggy (when changes happen, it'll take your application up to the polling interval to find out about the changes). For things like filesystem watching, there are special APIs applications can consume. But those APIs are different for every kind of data the kernel manages. Devices, mount points, USB connectivity, filesystem watching, CPU usage, thermal sensors, open network connections and on and on. All of this stuff has totally different kernel-level APIs for "watching" changes. (If you're lucky - a lot of it can only be polled). Its a big fat mess. I want to try replacing all of that with a nice clean API for fetching & subscribing to any kind of data. So, the kernel has a standard API for fetching (maybe it returns JSON). And a standard API for subscribing to changes - such that your application is notified when a change occurs, and the change is sent in a standard, easily digestible patch format. And ideally, eventually, I'd like applications to be able to share their own changes back with the kernel in the same form & format. And maybe, share data objects between applications like that - with the kernel acting as a broker for sending patches back and forth, and syncing them with the filesystem. I think that would be really neat and useful for all sorts of applications. But I want to prototype it all first in something thats not linux. I'm just not sure where to start. I don't really want to write an OS from scratch just to try out this generic state passing idea.
    - deleted 3y ago
      [deleted]
    - 3y ago
- rajeevk 3y ago
  There are a lot of resources here in case you want to write a kernel from scratch. https://wiki.osdev.org/Main_Page https://wiki.osdev.org/Main_Page I wrote a unix-like kernel from scratch long back. It was not a fully functional unix but had a lot of components ready to the extent it would provide a command line interfaceI from which you can run commands like ls, cat etc by loading elf executables. I would highly recommend to read this tutorial http://www.osdever.net/bkerndev/Docs/title.htm http://www.osdever.net/bkerndev/Docs/title.htm Feel free to reach out to me (email in my profile page) if you want to discuss the topic with me.
- codyd51 3y ago
  Hi, author here! Thanks for the kind words! I'll echo rajeevk's recommendation: the OSDev wiki is full of useful documentation and guides for setting up a bare-metal toolchain. There's also a community forum with a wealth of knowledge just waiting to be read. In terms of boots on the ground, I remember once seeing a mantra from someone on the OSDev forums that went something like this: building an x86 OS is first about getting the CPU into a usable state, then about getting as far away from it as possible. This is really true! There's a lot of work to do to set up the features that any modern environment needs as a baseline: paging, segmentation, interrupt descriptors, etc, but once you're done with all that you're free to roam in the design space and build whatever you like, however you imagine, building abstractions and then abstractions on top of those. I'd liken the early stages of OS development to a tech tree in a video game: you need serial output so that you can debug your kernel. You need to be able to allocate memory so that you can create pixel buffers, then need drawing primitives to fill them up. You need processes, and a scheduler to coordinate them. Every new feature you add opens up a myriad of possibilities that weren't there before, and although many things have a serial list of dependencies, there's always so much to do that you can just focus on whatever feels particularly inspiring to you at any given time. It's really a lot of fun. axle also uses structured messages for making requests to the kernel, as well as everything else. Here's an example of some structured requests that can be sent to the kernel: https://github.com/codyd51/axle/blob/paging-demo/kernel/kernel/util/amc/core_commands.h https://github.com/codyd51/axle/blob/paging-demo/kernel/kern.... Here's some structured data that an application (in this case, the window manager) uses to interact with other apps: https://github.com/codyd51/axle/blob/paging-demo/rust_programs/awm_messages/src/lib.rs https://github.com/codyd51/axle/blob/paging-demo/rust_progra... All the best, and feel free to reach out to me as well!
  - josephg 3y ago
    Thanks for the links and encouragement! I suppose my main hesitation is that it seems like an awful lot of work to build all that from scratch. I really want to - it looks super fun. But I've got my hands totally full at the moment building a CRDT & data engine for local first software. I really just have one idea I want to explore, which is this idea around sharing state between the kernel and userland via subscriptions and patches. (By taking some ideas from event sourcing and things like that). I guess I'm trying to figure out where I would even start prototyping something like that. I guess I could just fork axle and hack on it a bit to see how it goes?
wilg 3y ago
I love that hobby OSes are a thing!
metadat 3y ago
See also: I wrote a GameBoy emulator for my hobby OS (axleos.com) https://news.ycombinator.com/item?id=36004553 https://news.ycombinator.com/item?id=36004553 (13 comments)
CrampusDestrus 3y ago
Why is it always something Unix-like? It's a hobby project! Be bold and creative and make something nobody has ever seen!
- pjmlp 3y ago
  Sadly I can only upvote once. We need new BeOs, Inferno, Xerox like workstations,... Naturally the answer to why is clear, reuse existing UNIX software. However Apple and Google OSes also show that one can innovate, even at the bottom there is an UNIX like kernel.
  - rollcat 3y ago
    > Naturally the answer to why is clear, reuse existing UNIX software. POSIX can be added as a layer on top of (or besides) the native interface. macOS/Darwin does just that, with Mach as the microkernel. It creates opportunities for applications to use a non-standard, but more powerful or simpler interface (e.g. some sort of SpawnProcess, than can be more lightweight or less quirky than fork+exec). Unfortunately that's a tough call to make for applications that want to remain portable, and the world is already too fed up just dealing with Windows+Mac+Linux (+Android+iOS+Web+...).
- codyd51 3y ago
  Unix-like is definitely a misnomer, and I've gone ahead and removed it from the home page. It might've been true many years ago, but it's no longer the case. axle is fundamentally organised around structured messages. This mechanism is used both for interaction between userspace applications, and for nearly all interaction between kernel and userspace. For example, creating a process, allocating virtual memory regions, profiling the system and registering process hooks, are all just special messages that are sent to the kernel, rather than to another userspace app. Want to transmit a packet? If you have the rights, send a message to the NIC. Want to create a window on the desktop, or update its contents? Send a message to the window manager. It'll send some messages back to you when the user interacts with your content. The GUI toolkits use custom idioms. It's certainly true that axle reuses some common ideas (like featuring a desktop environment, and a process model), but I'm happy to go my own way from there! It's also true, as pjmlp mentioned, that some level of POSIX compatibility is necessary if you want to run external software, which I certainly do! DOOM, for example, requires read() and write(), among other common syscalls. If you want to run, say, GCC, you need fork().
ksaj 3y ago
And it runs Doom. Very important feature. I like how you've given the desktop a unique look. Doesn't look like it's trying to clone anything in particular.
- grepfru_it 3y ago
  To be fair, a lot of hobbyist operating systems have a fairly unique 1990s lock
  - wkat4242 3y ago
    Probably because they're made by engineers and not designers. Just like OSes in the 90s.
    - pjmlp 3y ago
      The 90's also used designers, hence stuff like Apple's HIG. The big difference is that they still weren't in the position of defending their job, and keep redoing the UI just for the sake of not being fired. After all when the UI is considered done, the size of the team can be largerly reduced.
ugh123 3y ago
Amazing work!
unixhero 3y ago
I love the picture of a woman, to show off the window manager/gui. Very 1990s :)
- throwme_123 3y ago
  https://en.wikipedia.org/wiki/Lenna https://en.wikipedia.org/wiki/Lenna Edit: Maybe someone should edit the Wikipedia intro that overly insists on very modern issues on gender. Lena herself happily participated to several research conferences on image processing: https://www.icip2015.org/banquet.html https://www.icip2015.org/banquet.html
  - fnimick 3y ago
    Times change and people realize how inappropriate it is. She herself has called for an end to the use of the image as a relic of a male dominated field. https://www.sfgate.com/news/article/How-a-Nude-Playboy-Photo-Became-a-Fixture-14878319.php https://www.sfgate.com/news/article/How-a-Nude-Playboy-Photo...
    - dfee 3y ago
      Inappropriate selling yourself as a centerfold for Playboy or using the image?
      - pavlov 3y ago
        The latter, obviously.
    - throwme_123 3y ago
      Is it truly the case? 2015 is not that far away, and from a personal account she was happy to be there and proud to have her image used in a research community. When you read your article, it seems the _journalist_ tried to extract a saying from her. So she says something quite vague instead, mentioning "time to retire" again... because it's what is going to happen because of "time changes.
    - 3y ago
vrglvrglvrgl 3y ago
[dead]
matthrtly 3y ago
Awesome to see it so far along! I've been interested in OS dev since my teenage years. I remember reading about BeOS in 2005 and wanting to run it. I didn't even have the internet so that wasn't going to happen. I am extremely intimidated but I've been working through some of the tutorials on the osdev wiki. How much did you know about OS theory before you started on this?
- codyd51 3y ago
  Thank you! I didn't know anything about working with bare metal when I started out, and relied on the OSDev Wiki and other online resources. The work of those early years isn't as mature as now, but I learned a lot. Later on, I graduated to being comfortable reading (for example) the CPU manuals, and realised that I could now really get value out of them! Overall, I feel a lot more comfortable in the domain and like I can tackle a new device driver, or set off making the hardware do something obtuse and wrangle it out, but I only got there through trying to do it with less expertise under my belt. There's definitely a bootstrapping problem with the lower-level knowledge, but there are enough resources out there for the initial steps that anyone can get started, and you can do a lot if you enjoy the journey!
birdyrooster 3y ago
[flagged]
pkphilip 3y ago
What I would love is an alternative to Android and IOS for mobile devices! Something with a simple UI and SDK which allows apps to be developed for it easily without jumping through the hoops and without losing all the control to the device manufacturers and the OS company
- waboremo 3y ago
  Hasn't there been several attempts at this? Vaguely recall firefoxOS and sailfishOS. I believe the problem always came down to hardware, due to it being essentially dominated by Android (ignoring iOS due to how tightly wound hardware and software are) you always ran into trouble requiring Android in some way before being able to switch to that new OS, even if the drivers themselves were freely and openly available. Which is a much harder problem to solve since there is so much upfront cost involved with hardware that most wouldn't dare bothering not prioritizing Android.
  - tpoacher 3y ago
    FirefoxOS is dead, but Sailfish is very much alive and kicking, with a reasonably thriving community; some of which inevitably overlapping with projects like pinephone etc.
  - pkphilip 3y ago
    My thought is: what would it take to produce a hardware with the following features: 1. Should be able to make and receive phones 2. Should be able to send/receive SMS 3. Should be able connect to the data plan (4G) 4. Wifi Support 5. Should be able to function as a hotspot so that you can use a laptop for more complex work 6. Should have a basic colour touch screen - need not be very high resolution, but sufficient for a basic UI. 7. Hardware or software keyboard 8. Support for SD cards 9. Headphone jack 10. Micro USB port or USB type c port for charging and data 11. Optional: A camera module for photos/videos if possible 12. Optional: Bluetooth LE 13. Software: 13.1 - Ability to install applications using a root/admin login (similar to any desktop os). The application may be downloaded off the web or obtained from an SD card etc. May be installed into a specific directory which can be backed up or restored. Example: "/usr/apps" 13.2 - Directory for contacts to be stored. Example: "/usr/contacts" with open format for contacts which can be read by apps 13.3 - Directory for photos and videos to be stored. Example: "/usr/media/photos", "/usr/media/videos" 13.4 - Ability to save / load contacts from disk or network 13.5 - Ability to run network servers - example: Samba server or even a basic HTTP server for sharing and receiving files.
m00x 3y ago
Does it have a C interpreter?

250 points by mmphosis 3y ago

This is super cool! I’ve had an idea I’ve been wanting to build into an OS for ages - where we use versions, message passing and structured patches to pass information between the kernel and application processes. So an application can subscribe to a file / USB device state / list of running processes / anything using a common, standard API. But it sounds really daunting to try and hack something like into the Linux kernel or something in one go. If I want to experiment with something like this, what do you recommend? How hard would it be to do something like that in a hobby kernel like Axle?

blown_gasket 3y ago
I've been pondering this for a moment and if I were to write an application for such a system I don't think I'd enjoy it. If you want to pass information from the kernel and bubble that all the way to the application to do something with it, I would think you now have to write signal handling in your application.
- josephg 3y ago
  Obviously, the signal handling code can live in a library of some sort. With a generic, system wide api there’s no reason you couldn’t still poll if you really wanted to. But maybe at least with a version token. So the application can say “I want info on which processes are running. Last time I asked, you gave me token 5827275” and the kernel can respond and say “you’ve got the most recent version of that data already champ”.
ww520 3y ago
Linux exposes system information like processes and devices in the psuedo file system hosted at the mount point /proc. Any user mode programs can use the standard file IO API to access them. Some of the "files" like /proc/self/mounts are pollable, i.e. a program can use blocking select to wait for changes like when a new file system has been mounted.
- josephg 3y ago
  Yeah, I know how it works in linux. I just hate it. Polling and writing a parser for a pseudo-file always seems like a super roundabout, inefficient, brittle way to send information from kernel to userspace. Think about it - the kernel stores some data in a nice, neat struct. And the kernel knows exactly when that struct is modified. Userspace wants that data, and wants to know when the data changes. So every second, userspace "reads" a pseudo file. The kernel packs the struct's contents into a big string with some sloppy, hand written text format and passes it to userspace. Then in userspace you need to write a brittle parser for whatever the kernel gives you, knowing that in different versions of the kernel you'll get slightly differently formatted strings. When the data changes in the kernel, the application has no way of being notified. It just polls and parses in a loop. Its both inefficient (when there are no changes, its all wasted effort). And its laggy (when changes happen, it'll take your application up to the polling interval to find out about the changes). For things like filesystem watching, there are special APIs applications can consume. But those APIs are different for every kind of data the kernel manages. Devices, mount points, USB connectivity, filesystem watching, CPU usage, thermal sensors, open network connections and on and on. All of this stuff has totally different kernel-level APIs for "watching" changes. (If you're lucky - a lot of it can only be polled). Its a big fat mess. I want to try replacing all of that with a nice clean API for fetching & subscribing to any kind of data. So, the kernel has a standard API for fetching (maybe it returns JSON). And a standard API for subscribing to changes - such that your application is notified when a change occurs, and the change is sent in a standard, easily digestible patch format. And ideally, eventually, I'd like applications to be able to share their own changes back with the kernel in the same form & format. And maybe, share data objects between applications like that - with the kernel acting as a broker for sending patches back and forth, and syncing them with the filesystem. I think that would be really neat and useful for all sorts of applications. But I want to prototype it all first in something thats not linux. I'm just not sure where to start. I don't really want to write an OS from scratch just to try out this generic state passing idea.
  - deleted 3y ago
    [deleted]
  - 3y ago
rajeevk 3y ago
There are a lot of resources here in case you want to write a kernel from scratch. https://wiki.osdev.org/Main_Page https://wiki.osdev.org/Main_Page I wrote a unix-like kernel from scratch long back. It was not a fully functional unix but had a lot of components ready to the extent it would provide a command line interfaceI from which you can run commands like ls, cat etc by loading elf executables. I would highly recommend to read this tutorial http://www.osdever.net/bkerndev/Docs/title.htm http://www.osdever.net/bkerndev/Docs/title.htm Feel free to reach out to me (email in my profile page) if you want to discuss the topic with me.
codyd51 3y ago
Hi, author here! Thanks for the kind words! I'll echo rajeevk's recommendation: the OSDev wiki is full of useful documentation and guides for setting up a bare-metal toolchain. There's also a community forum with a wealth of knowledge just waiting to be read. In terms of boots on the ground, I remember once seeing a mantra from someone on the OSDev forums that went something like this: building an x86 OS is first about getting the CPU into a usable state, then about getting as far away from it as possible. This is really true! There's a lot of work to do to set up the features that any modern environment needs as a baseline: paging, segmentation, interrupt descriptors, etc, but once you're done with all that you're free to roam in the design space and build whatever you like, however you imagine, building abstractions and then abstractions on top of those. I'd liken the early stages of OS development to a tech tree in a video game: you need serial output so that you can debug your kernel. You need to be able to allocate memory so that you can create pixel buffers, then need drawing primitives to fill them up. You need processes, and a scheduler to coordinate them. Every new feature you add opens up a myriad of possibilities that weren't there before, and although many things have a serial list of dependencies, there's always so much to do that you can just focus on whatever feels particularly inspiring to you at any given time. It's really a lot of fun. axle also uses structured messages for making requests to the kernel, as well as everything else. Here's an example of some structured requests that can be sent to the kernel: https://github.com/codyd51/axle/blob/paging-demo/kernel/kernel/util/amc/core_commands.h https://github.com/codyd51/axle/blob/paging-demo/kernel/kern.... Here's some structured data that an application (in this case, the window manager) uses to interact with other apps: https://github.com/codyd51/axle/blob/paging-demo/rust_programs/awm_messages/src/lib.rs https://github.com/codyd51/axle/blob/paging-demo/rust_progra... All the best, and feel free to reach out to me as well!
- josephg 3y ago
  Thanks for the links and encouragement! I suppose my main hesitation is that it seems like an awful lot of work to build all that from scratch. I really want to - it looks super fun. But I've got my hands totally full at the moment building a CRDT & data engine for local first software. I really just have one idea I want to explore, which is this idea around sharing state between the kernel and userland via subscriptions and patches. (By taking some ideas from event sourcing and things like that). I guess I'm trying to figure out where I would even start prototyping something like that. I guess I could just fork axle and hack on it a bit to see how it goes?

wilg 3y ago

I love that hobby OSes are a thing!

metadat 3y ago

See also: I wrote a GameBoy emulator for my hobby OS (axleos.com) https://news.ycombinator.com/item?id=36004553 https://news.ycombinator.com/item?id=36004553 (13 comments)

CrampusDestrus 3y ago

Why is it always something Unix-like? It's a hobby project! Be bold and creative and make something nobody has ever seen!

pjmlp 3y ago
Sadly I can only upvote once. We need new BeOs, Inferno, Xerox like workstations,... Naturally the answer to why is clear, reuse existing UNIX software. However Apple and Google OSes also show that one can innovate, even at the bottom there is an UNIX like kernel.
- rollcat 3y ago
  > Naturally the answer to why is clear, reuse existing UNIX software. POSIX can be added as a layer on top of (or besides) the native interface. macOS/Darwin does just that, with Mach as the microkernel. It creates opportunities for applications to use a non-standard, but more powerful or simpler interface (e.g. some sort of SpawnProcess, than can be more lightweight or less quirky than fork+exec). Unfortunately that's a tough call to make for applications that want to remain portable, and the world is already too fed up just dealing with Windows+Mac+Linux (+Android+iOS+Web+...).
codyd51 3y ago
Unix-like is definitely a misnomer, and I've gone ahead and removed it from the home page. It might've been true many years ago, but it's no longer the case. axle is fundamentally organised around structured messages. This mechanism is used both for interaction between userspace applications, and for nearly all interaction between kernel and userspace. For example, creating a process, allocating virtual memory regions, profiling the system and registering process hooks, are all just special messages that are sent to the kernel, rather than to another userspace app. Want to transmit a packet? If you have the rights, send a message to the NIC. Want to create a window on the desktop, or update its contents? Send a message to the window manager. It'll send some messages back to you when the user interacts with your content. The GUI toolkits use custom idioms. It's certainly true that axle reuses some common ideas (like featuring a desktop environment, and a process model), but I'm happy to go my own way from there! It's also true, as pjmlp mentioned, that some level of POSIX compatibility is necessary if you want to run external software, which I certainly do! DOOM, for example, requires read() and write(), among other common syscalls. If you want to run, say, GCC, you need fork().

ksaj 3y ago

And it runs Doom. Very important feature. I like how you've given the desktop a unique look. Doesn't look like it's trying to clone anything in particular.

grepfru_it 3y ago
To be fair, a lot of hobbyist operating systems have a fairly unique 1990s lock
- wkat4242 3y ago
  Probably because they're made by engineers and not designers. Just like OSes in the 90s.
  - pjmlp 3y ago
    The 90's also used designers, hence stuff like Apple's HIG. The big difference is that they still weren't in the position of defending their job, and keep redoing the UI just for the sake of not being fired. After all when the UI is considered done, the size of the team can be largerly reduced.

ugh123 3y ago

Amazing work!

unixhero 3y ago

I love the picture of a woman, to show off the window manager/gui. Very 1990s :)

throwme_123 3y ago
https://en.wikipedia.org/wiki/Lenna https://en.wikipedia.org/wiki/Lenna Edit: Maybe someone should edit the Wikipedia intro that overly insists on very modern issues on gender. Lena herself happily participated to several research conferences on image processing: https://www.icip2015.org/banquet.html https://www.icip2015.org/banquet.html
- fnimick 3y ago
  Times change and people realize how inappropriate it is. She herself has called for an end to the use of the image as a relic of a male dominated field. https://www.sfgate.com/news/article/How-a-Nude-Playboy-Photo-Became-a-Fixture-14878319.php https://www.sfgate.com/news/article/How-a-Nude-Playboy-Photo...
  - dfee 3y ago
    Inappropriate selling yourself as a centerfold for Playboy or using the image?
    - pavlov 3y ago
      The latter, obviously.
  - throwme_123 3y ago
    Is it truly the case? 2015 is not that far away, and from a personal account she was happy to be there and proud to have her image used in a research community. When you read your article, it seems the _journalist_ tried to extract a saying from her. So she says something quite vague instead, mentioning "time to retire" again... because it's what is going to happen because of "time changes.
  - 3y ago

vrglvrglvrgl 3y ago

[dead]

matthrtly 3y ago

Awesome to see it so far along! I've been interested in OS dev since my teenage years. I remember reading about BeOS in 2005 and wanting to run it. I didn't even have the internet so that wasn't going to happen. I am extremely intimidated but I've been working through some of the tutorials on the osdev wiki. How much did you know about OS theory before you started on this?

codyd51 3y ago
Thank you! I didn't know anything about working with bare metal when I started out, and relied on the OSDev Wiki and other online resources. The work of those early years isn't as mature as now, but I learned a lot. Later on, I graduated to being comfortable reading (for example) the CPU manuals, and realised that I could now really get value out of them! Overall, I feel a lot more comfortable in the domain and like I can tackle a new device driver, or set off making the hardware do something obtuse and wrangle it out, but I only got there through trying to do it with less expertise under my belt. There's definitely a bootstrapping problem with the lower-level knowledge, but there are enough resources out there for the initial steps that anyone can get started, and you can do a lot if you enjoy the journey!

birdyrooster 3y ago

[flagged]

pkphilip 3y ago

What I would love is an alternative to Android and IOS for mobile devices! Something with a simple UI and SDK which allows apps to be developed for it easily without jumping through the hoops and without losing all the control to the device manufacturers and the OS company

waboremo 3y ago
Hasn't there been several attempts at this? Vaguely recall firefoxOS and sailfishOS. I believe the problem always came down to hardware, due to it being essentially dominated by Android (ignoring iOS due to how tightly wound hardware and software are) you always ran into trouble requiring Android in some way before being able to switch to that new OS, even if the drivers themselves were freely and openly available. Which is a much harder problem to solve since there is so much upfront cost involved with hardware that most wouldn't dare bothering not prioritizing Android.
- tpoacher 3y ago
  FirefoxOS is dead, but Sailfish is very much alive and kicking, with a reasonably thriving community; some of which inevitably overlapping with projects like pinephone etc.
- pkphilip 3y ago
  My thought is: what would it take to produce a hardware with the following features: 1. Should be able to make and receive phones 2. Should be able to send/receive SMS 3. Should be able connect to the data plan (4G) 4. Wifi Support 5. Should be able to function as a hotspot so that you can use a laptop for more complex work 6. Should have a basic colour touch screen - need not be very high resolution, but sufficient for a basic UI. 7. Hardware or software keyboard 8. Support for SD cards 9. Headphone jack 10. Micro USB port or USB type c port for charging and data 11. Optional: A camera module for photos/videos if possible 12. Optional: Bluetooth LE 13. Software: 13.1 - Ability to install applications using a root/admin login (similar to any desktop os). The application may be downloaded off the web or obtained from an SD card etc. May be installed into a specific directory which can be backed up or restored. Example: "/usr/apps" 13.2 - Directory for contacts to be stored. Example: "/usr/contacts" with open format for contacts which can be read by apps 13.3 - Directory for photos and videos to be stored. Example: "/usr/media/photos", "/usr/media/videos" 13.4 - Ability to save / load contacts from disk or network 13.5 - Ability to run network servers - example: Samba server or even a basic HTTP server for sharing and receiving files.

m00x 3y ago

Does it have a C interpreter?