10 ms·

I just want to say that this project is amazing. At the risk of sounding hyperbolic, I think Rust is the most exciting thing that's happening in computing today

by brandur 10y ago

I just want to say that this project is amazing. At the risk of sounding hyperbolic, I think Rust is the most exciting thing that's happening in computing today. This sort of project that plausibly replaces software traditionally written only in C/C++ with something that has performance parity, but is in a language where contributions are relatively accessible and safe, is the most exciting thing even within the bounds of an intriguing ecosystem. As someone who is especially concerned about the performance of my tooling these days due to what seems to be a generally infinite willingness to accept web apps that are slower than desktop apps from decades ago, and which seem to continually demand more resources year over year, I really appreciate that such a distinguishing eye has been given to Alacritty's speed and resource usage. Some contemporary alternatives like Electron-based terminals are academically interesting, but are programs I'd never want to use due to the huge step backwards in these areas. One question: do you have any plans to use Alacritty to try and advance the state of terminal emulators more generally? e.g. Displaying images, richer interfaces that don't depend on ASCII bar characters, graphs, properly tabulated results, etc. This is a direction that I wish we were going, but it's not clear to me how to get there without many sacrifices.

EnjoyTomato 10y ago
Why do people still say C/C++? They are two different languages with different purposes and strengths/weaknesses. Rust might be a worthy competitor with C++, assuming many improvements down the line, but it's not even in the same category as C, no matter how much the enthusiasts like to claim otherwise.
dragonne 10y ago
Another Rust terminal emulator project, notty[1], aims to do this. Downthread the author mentions that the projects are looking at collaborating. [1]: https://github.com/withoutboats/notty https://github.com/withoutboats/notty
- brandur 10y ago
  That's really cool and their README gives some great background. Thanks!
- tatterdemalion 10y ago
  notty author here. notty is basically way down a yakstack for me - I wanted better CLI/TUI tools, so I wanted to write a framework for writing CLI/TUI tools, but some of the features I wanted aren't supported by terminals, so I started writing a new terminal. But I don't know anything about graphics programming & this is really far away from what I actually wanted to be doing - so when jwilm showed me alacritty & mentioned implementing notty with it I was pretty stoked.
- xxpor 10y ago
  It's too bad notty is licenced under the AGPL. That basically guarantees 0 usage at any sort of bigco.
  - nopreserveroot 10y ago
    That is not how Copyleft software licenses work at all. All the AGPL gurantees is that 'Bigco' must contribute back to the community any modifications they make to the software.
    - arandomcoder 10y ago
      Exactly! How many bigco's have a terminal emulator incorporated into a product? If you're just using this to run tmux, vim, etc. the AGPL's strengthened sharing provisions aren't going to affect you at all :-)
    - dekhn 10y ago
      The AGPL is different from the GPL. The AGPL prevents use at my Bigco (Google) for a number of good reasons.
      - nopreserveroot 10y ago
        That's company policy and not the fault of the license. EDIT: Unless you're making modifications to the software, the AGPL does not apply. EDIT2: http://www.affero.org/oagf.html#How_does_this_license_treat_commercial http://www.affero.org/oagf.html#How_does_this_license_treat_... Specifically, the question, "How does this license treat commercial enterprise use over intranets and internal networks?"
        twic 10y ago
        Is that true? My understanding of the AGPL was that any software product which uses it as a component becomes subject to the AGPL - it has the linking semantics of the GPL, not the LGPL. If that's not the case, please do disabuse me of my misconception!
wang_li 10y ago
You do seem overly excited. :) Your last paragraph suggests what you really want is a notebook style interface (in the style of mathematica) rather than a terminal.
- brandur 10y ago
  > You do seem overly excited. :) Hah, yeah I'm aware, but the potential of Rust is huge. We talk a lot about open source these days, but meanwhile the tools that we all use are sitting on huge substrates that the vast majority of us aren't contributing to and probably never will due to the complexity hurdle that needs to be overcome. This includes our web browsers, our terminals, our editors/IDEs, our operating systems, our security software (OpenSSL, NaCL, OpenSSH), and if you're a developer, things like our databases. Although I can ostensibly write C and C++, I still don't contribute to these projects because oftentimes a whole new set of local conventions around build tools and utility libraries needs to be learned for every project, and there's a high bar of experience required before contribution is possible without the risk of introducing a memory leak or security problem. Rust has the potential to change all of this, and that's really, really big. > Your last paragraph suggests what you really want is a notebook style interface (in the style of mathematica) rather than a terminal. I definitely appreciate Mathematica and its sort of rich prompt is probably closer to what a terminal should look like rather than what we have today. But most of what I'm doing all day is text editing and using companion tools like Git, which isn't a good fit for it. I'd much rather that those Mathematica utilities come to my terminal rather than me having to go to Mathematica.
  - Yoric 10y ago
    > I'd much rather that those Mathematica utilities come to my terminal rather than me having to go to Mathematica. I believe that's what the parent meant. And I like this idea – a lot.
    - baq 10y ago
      Jupyter with a sh kernel perhaps?
    - 10y ago
Hydraulix989 10y ago
It is an amazing project! One thing to note is that the terminal emulator itself isn't GPU-accelerated (there's no parallel computations that run on the GPU), the UI graphics are only rendered by the GPU (much like in the Chrome browser).
- jwilm 10y ago
  Comparing it with Mozilla's Servo project (specifically WebRender) would be more accurate.
jwilm 10y ago
> do you have any plans to use Alacritty to try and advance the state of terminal emulators more generally? I hadn't replied to this because others had already provided all of the info I have. To summarize, the author of notty[0] and I are talking about a collaboration[1]. notty has done a ton of pathfinding in this area on identifying how to add many of these features in a backwards compatible way. I'm really looking forward to see where it goes! [0]: https://github.com/withoutboats/notty https://github.com/withoutboats/notty [1]: https://github.com/jwilm/alacritty/issues/51 https://github.com/jwilm/alacritty/issues/51
- quotemstr 10y ago
  As long as we're talking about terminals: 1) TERM is broken: https://www.facebook.com/notes/daniel-colascione/term-is-terminally-broken/10154219967001102/ https://www.facebook.com/notes/daniel-colascione/term-is-ter... 2) We need to start adding capabilities to terminfo again --- see the incredible mess in bracketed paste support, true color support, etc. 3) TIOCSTI is a giant truck-sized security hole. We need to stop supporting it.
- traverseda 10y ago
  Is adding those features in a backwards compatible way really that important? Couldn't you just have a program send an escape code telling your term to go into "new" mode, and implement some completely different standard? Or I suppose use terminfo, but I like the idea of dealing with text streams better.
  - quotemstr 10y ago
    > Or I suppose use terminfo What do you think terminfo does?!
sliken 10y ago
I tried the terminal. No scroll bars, no menus, and no highlighting of URLs. Not nearly as functional as the original xterm from the early 90s. It might be super fast, but I've not really been scroll speed limited.
- barrkel 10y ago
  I generally use rxvt because xterm is too slow. It doesn't have menus or URL highlighting and scrollbars are nonfunctional in the presence of screen, tmux, Emacs or generally any interesting terminal app. On Windows I use mintty and I turn off scrollbars there. I simply don't use the mouse to interact with the terminal other than to select text, and that's with selection buffer to copy. Speed is highly relevant to me. Most modern terminal emulators are very slow, most noticeable when you get a lot of output in a panel in something like tmux. (Simplistic benchmarks that test full screen scrolling usually hand the crown to terminals that don't bother to refresh the screen with everything output, but that's not the only bit of a terminal emulator that can be slow.)
  - stuaxo 10y ago
    Interesting. For me, there isn't enough integration between the GUI and terminal ... they shouldn't seem separate, but should be bridged to create a coherent experience.
- deleted 10y ago
  [deleted]
- bootload 10y ago
  "Not nearly as functional as the original xterm from the early 90s.:" Early Alpha concentrates on stability before bells and whistles. Agree though scroll bars would be nice but patience.
- noonespecial 10y ago
  Heh. Does it also have less space than a Nomad? Point is, that stuff is easy to add in subsequent releases. Its an early project. Give it time to become.
gwu78 10y ago
"... generally infinite willingness to accept web apps..." Interesting. I stay in textmode. Hence I do not need an emulator. If I need graphics I access the files over VLAN from another computer designed for mindless consumption of graphics, like the locked-down ones they sell today with touchscreens, etc. My understanding is that emulators like xterm can redraw the screen faster than VGA. I remember this can make textual interfaces feel snappier. But I doubt that jobs execute any faster in X11/Wayland/whatever than they do in textmode. I cannot see how the processes would be completing any sooner by virtue of using a graphics accelereted emulator. But I could be wrong. I sometimes use tmux for additional virtual consoles because on the computers I control (custom kernel, devices and userland) I do not use multiple ttys, just /dev/console. I rarely ever work within tmux. I only use it to run detached jobs. I view screen output from my tty with something like case $1 in -B|-E|-S|-t) tmux capturep $@ -- exec tmux showb $@ -- esac I'm not a seasoned tmux user. I was a very early adopter. tmux is useful high quality software IMHO. Not sure why I would ever need these slow "web apps". I guess the third parties controlling the endpoints might be able to utilise the data they gather about users. And I am sure some users appreciate the help. Thus it is a symbiotic relationship. I am continually making my "tooling" faster by eliminating unecessary resource consumption. It is an obsession of sorts. Constant improvement. But given that I am working with text, graphics processing is not something I need. I would not mind being able to run my non-graphical jobs on a fast GPU, but my understanding is that the companies making these processors are not very open. For example, the GPU in the RasperryPi. Always interesting to hear how others are meeting their computing needs.
- i336_ 10y ago
  The Web is two things. First, it's the promise that a certain runtime with a specific minimum set of capabilities is available almost anywhere. Secondly, it's a staggeringly-huge installed base of stuff written for that runtime. I don't think there's anything out there in the that matches the volume of deployed HTML, CSS and JS in the wild. The horribly sad part is that HTML, CSS and JS are a gigantic Rube Goldberg implementation of "run arbitrary code in a safe sandbox," because the Web is also the world's biggest collection of legacy dependency. IMHO, the source of the engineering cringe making everything so much sadder and less than what it could be is that the W3C/WHATWG/IETF/etc are made up of consortiums of large, foghorn-equipped corporations - corporations that have vested interests in advertising, consumer retention, and strong guarantees of indefinite consumption. I've never really gotten the reasoning behind the technical directions the Web's gone in; a lot of things have stuck and worked, but so many more have flopped, yet the associated implementations for both the successes and failures have to be maintained going forward indefinitely. The iterative pace on the various Web standards is another problem - things go so fast that the implementations can never get really really good, and Chrome uses literally all of your memory (whether you have 2GB or 20GB, apparently!) as a result. --- Regarding $terminal_emulator being faster than VGA, I can emphatically state that virtually all of them are disasterously slow. aterm had some handcoded SSE circa 2001 to support fake window shadowing (fastcopy the portion of the root window image underneath the terminal window whenever the window is moved; use SSE to darken the snagged area; apply as terminal window background) but besides that sort of thing, terminal emulators have more or less never been bastions of speed. If by VGA you mean true textmode (the 720x400 kind, generated entirely by the video card), I don't think there's much that's faster than that. Throw setfont and the Cyr_a8x8 font in there to get 80x50 (I think it is, or 80x43) and you have something hard to beat, since spamming ASCII characters at the video card's memory will always be faster than addressing pixels in a framebuffer. Which is why GPU-accelerated terminal emulators are so interesting: they're eliminating as many software/architectural bottlenecks as possible to make those expensive framebuffer updates as quick as possible. It's definitely the way to go; games are generally rated on their ability to push GPUs to >60fps at 1080p (and increasingly 2K/4K/8K), so the capacity is really there. The i3 window manager could be considered one of many comparable similar implementations to tmux. It's not perfect (it's not as configurable as I'd prefer), but it'd get you X and the ability to view media more easily. I do really appreciate the tendency to want to view a computer as an industrial terminal appliance though. Task switching is still best done by associating tasks with different objects in physical space, so keeping the computer for terminal work and keeping tablets (et al) for other tasks does make legitimate sense. --- Regarding data usage, that's a tricky one - most successful Internet companies provide some kind of service that necessarily requires the collection of arguably private information in exchange for a novel convenience. As an example, mapping services don't truly need your realtime location but having that means that they can stream the most relevant tiles of an always-up-to-date map to you. The alternative is storing an entire world map, or subsetted map(s) for the locations you think you'll need, but that'll kill almost all the storage on phones without massive SD cards. --- I find elimination of unnecessary resource consumption a fun concept to explore, almost to the point of obsession. In this regard I often come back to Forth. I was reading this yesterday - http://yosefk.com/blog/my-history-with-forth-stack-machines.html http://yosefk.com/blog/my-history-with-forth-stack-machines.... - and it explores how Forth is essentially the mindset of eliminating ALL but the smallest functional expression of the irreducible complexity of an idea, often to the point of insanity. It's not a register-based language so it's never going to beat machine code for any modern processor, but it's a very very interesting concept to seriously explore, at least. (And I say that as someone interested in actually using Forth for something practical, as described in that article.) --- AFAIK, the RPi actually boots off the GPU, or at least the older credit-card-sized ones did. I'm not sure about the current versions. ATI released some documentation about their designs a while back with the subtext of enabling open-source driver development. I don't think that panned out as much as was hoped. My understanding is that Intel has both NVIDIA and AMD beat nowadays when it comes to Linux graphics support; the two former vendors still heavily rely on proprietary drivers (on Linux) for a lot of functionality. Sadly, since they both have to successfully compete in the market, they're unlikely to release their hardware designs in significant detail anytime soon. (Even if they did like the idea of merging, single gigantic monopolies have a lot of risk, and the behemoth that resulted would be impossible for Intel to compete with, likely.) So, learning OpenCL and CUDA (depending on the GPU you have) is likely your best bet. There are extant established ecosystems of resources and domain knowledge for both implementations, and the relevant code is not too tragically licensed AFAIK.

by brandur 10y ago

EnjoyTomato 10y ago

Why do people still say C/C++? They are two different languages with different purposes and strengths/weaknesses. Rust might be a worthy competitor with C++, assuming many improvements down the line, but it's not even in the same category as C, no matter how much the enthusiasts like to claim otherwise.

dragonne 10y ago

Another Rust terminal emulator project, notty[1], aims to do this. Downthread the author mentions that the projects are looking at collaborating. [1]: https://github.com/withoutboats/notty https://github.com/withoutboats/notty

brandur 10y ago
That's really cool and their README gives some great background. Thanks!
tatterdemalion 10y ago
notty author here. notty is basically way down a yakstack for me - I wanted better CLI/TUI tools, so I wanted to write a framework for writing CLI/TUI tools, but some of the features I wanted aren't supported by terminals, so I started writing a new terminal. But I don't know anything about graphics programming & this is really far away from what I actually wanted to be doing - so when jwilm showed me alacritty & mentioned implementing notty with it I was pretty stoked.
xxpor 10y ago
It's too bad notty is licenced under the AGPL. That basically guarantees 0 usage at any sort of bigco.
- nopreserveroot 10y ago
  That is not how Copyleft software licenses work at all. All the AGPL gurantees is that 'Bigco' must contribute back to the community any modifications they make to the software.
  - arandomcoder 10y ago
    Exactly! How many bigco's have a terminal emulator incorporated into a product? If you're just using this to run tmux, vim, etc. the AGPL's strengthened sharing provisions aren't going to affect you at all :-)
  - dekhn 10y ago
    The AGPL is different from the GPL. The AGPL prevents use at my Bigco (Google) for a number of good reasons.
    - nopreserveroot 10y ago
      That's company policy and not the fault of the license. EDIT: Unless you're making modifications to the software, the AGPL does not apply. EDIT2: http://www.affero.org/oagf.html#How_does_this_license_treat_commercial http://www.affero.org/oagf.html#How_does_this_license_treat_... Specifically, the question, "How does this license treat commercial enterprise use over intranets and internal networks?"
      - twic 10y ago
        Is that true? My understanding of the AGPL was that any software product which uses it as a component becomes subject to the AGPL - it has the linking semantics of the GPL, not the LGPL. If that's not the case, please do disabuse me of my misconception!

wang_li 10y ago

You do seem overly excited. :) Your last paragraph suggests what you really want is a notebook style interface (in the style of mathematica) rather than a terminal.

brandur 10y ago
> You do seem overly excited. :) Hah, yeah I'm aware, but the potential of Rust is huge. We talk a lot about open source these days, but meanwhile the tools that we all use are sitting on huge substrates that the vast majority of us aren't contributing to and probably never will due to the complexity hurdle that needs to be overcome. This includes our web browsers, our terminals, our editors/IDEs, our operating systems, our security software (OpenSSL, NaCL, OpenSSH), and if you're a developer, things like our databases. Although I can ostensibly write C and C++, I still don't contribute to these projects because oftentimes a whole new set of local conventions around build tools and utility libraries needs to be learned for every project, and there's a high bar of experience required before contribution is possible without the risk of introducing a memory leak or security problem. Rust has the potential to change all of this, and that's really, really big. > Your last paragraph suggests what you really want is a notebook style interface (in the style of mathematica) rather than a terminal. I definitely appreciate Mathematica and its sort of rich prompt is probably closer to what a terminal should look like rather than what we have today. But most of what I'm doing all day is text editing and using companion tools like Git, which isn't a good fit for it. I'd much rather that those Mathematica utilities come to my terminal rather than me having to go to Mathematica.
- Yoric 10y ago
  > I'd much rather that those Mathematica utilities come to my terminal rather than me having to go to Mathematica. I believe that's what the parent meant. And I like this idea – a lot.
  - baq 10y ago
    Jupyter with a sh kernel perhaps?
  - 10y ago

Hydraulix989 10y ago

It is an amazing project! One thing to note is that the terminal emulator itself isn't GPU-accelerated (there's no parallel computations that run on the GPU), the UI graphics are only rendered by the GPU (much like in the Chrome browser).

jwilm 10y ago
Comparing it with Mozilla's Servo project (specifically WebRender) would be more accurate.

jwilm 10y ago

> do you have any plans to use Alacritty to try and advance the state of terminal emulators more generally? I hadn't replied to this because others had already provided all of the info I have. To summarize, the author of notty[0] and I are talking about a collaboration[1]. notty has done a ton of pathfinding in this area on identifying how to add many of these features in a backwards compatible way. I'm really looking forward to see where it goes! [0]: https://github.com/withoutboats/notty https://github.com/withoutboats/notty [1]: https://github.com/jwilm/alacritty/issues/51 https://github.com/jwilm/alacritty/issues/51

quotemstr 10y ago
As long as we're talking about terminals: 1) TERM is broken: https://www.facebook.com/notes/daniel-colascione/term-is-terminally-broken/10154219967001102/ https://www.facebook.com/notes/daniel-colascione/term-is-ter... 2) We need to start adding capabilities to terminfo again --- see the incredible mess in bracketed paste support, true color support, etc. 3) TIOCSTI is a giant truck-sized security hole. We need to stop supporting it.
traverseda 10y ago
Is adding those features in a backwards compatible way really that important? Couldn't you just have a program send an escape code telling your term to go into "new" mode, and implement some completely different standard? Or I suppose use terminfo, but I like the idea of dealing with text streams better.
- quotemstr 10y ago
  > Or I suppose use terminfo What do you think terminfo does?!

sliken 10y ago

I tried the terminal. No scroll bars, no menus, and no highlighting of URLs. Not nearly as functional as the original xterm from the early 90s. It might be super fast, but I've not really been scroll speed limited.

barrkel 10y ago
I generally use rxvt because xterm is too slow. It doesn't have menus or URL highlighting and scrollbars are nonfunctional in the presence of screen, tmux, Emacs or generally any interesting terminal app. On Windows I use mintty and I turn off scrollbars there. I simply don't use the mouse to interact with the terminal other than to select text, and that's with selection buffer to copy. Speed is highly relevant to me. Most modern terminal emulators are very slow, most noticeable when you get a lot of output in a panel in something like tmux. (Simplistic benchmarks that test full screen scrolling usually hand the crown to terminals that don't bother to refresh the screen with everything output, but that's not the only bit of a terminal emulator that can be slow.)
- stuaxo 10y ago
  Interesting. For me, there isn't enough integration between the GUI and terminal ... they shouldn't seem separate, but should be bridged to create a coherent experience.
deleted 10y ago
[deleted]
bootload 10y ago
"Not nearly as functional as the original xterm from the early 90s.:" Early Alpha concentrates on stability before bells and whistles. Agree though scroll bars would be nice but patience.
noonespecial 10y ago
Heh. Does it also have less space than a Nomad? Point is, that stuff is easy to add in subsequent releases. Its an early project. Give it time to become.

gwu78 10y ago

"... generally infinite willingness to accept web apps..." Interesting. I stay in textmode. Hence I do not need an emulator. If I need graphics I access the files over VLAN from another computer designed for mindless consumption of graphics, like the locked-down ones they sell today with touchscreens, etc. My understanding is that emulators like xterm can redraw the screen faster than VGA. I remember this can make textual interfaces feel snappier. But I doubt that jobs execute any faster in X11/Wayland/whatever than they do in textmode. I cannot see how the processes would be completing any sooner by virtue of using a graphics accelereted emulator. But I could be wrong. I sometimes use tmux for additional virtual consoles because on the computers I control (custom kernel, devices and userland) I do not use multiple ttys, just /dev/console. I rarely ever work within tmux. I only use it to run detached jobs. I view screen output from my tty with something like case $1 in -B|-E|-S|-t) tmux capturep $@ -- exec tmux showb $@ -- esac I'm not a seasoned tmux user. I was a very early adopter. tmux is useful high quality software IMHO. Not sure why I would ever need these slow "web apps". I guess the third parties controlling the endpoints might be able to utilise the data they gather about users. And I am sure some users appreciate the help. Thus it is a symbiotic relationship. I am continually making my "tooling" faster by eliminating unecessary resource consumption. It is an obsession of sorts. Constant improvement. But given that I am working with text, graphics processing is not something I need. I would not mind being able to run my non-graphical jobs on a fast GPU, but my understanding is that the companies making these processors are not very open. For example, the GPU in the RasperryPi. Always interesting to hear how others are meeting their computing needs.

i336_ 10y ago
The Web is two things. First, it's the promise that a certain runtime with a specific minimum set of capabilities is available almost anywhere. Secondly, it's a staggeringly-huge installed base of stuff written for that runtime. I don't think there's anything out there in the that matches the volume of deployed HTML, CSS and JS in the wild. The horribly sad part is that HTML, CSS and JS are a gigantic Rube Goldberg implementation of "run arbitrary code in a safe sandbox," because the Web is also the world's biggest collection of legacy dependency. IMHO, the source of the engineering cringe making everything so much sadder and less than what it could be is that the W3C/WHATWG/IETF/etc are made up of consortiums of large, foghorn-equipped corporations - corporations that have vested interests in advertising, consumer retention, and strong guarantees of indefinite consumption. I've never really gotten the reasoning behind the technical directions the Web's gone in; a lot of things have stuck and worked, but so many more have flopped, yet the associated implementations for both the successes and failures have to be maintained going forward indefinitely. The iterative pace on the various Web standards is another problem - things go so fast that the implementations can never get really really good, and Chrome uses literally all of your memory (whether you have 2GB or 20GB, apparently!) as a result. --- Regarding $terminal_emulator being faster than VGA, I can emphatically state that virtually all of them are disasterously slow. aterm had some handcoded SSE circa 2001 to support fake window shadowing (fastcopy the portion of the root window image underneath the terminal window whenever the window is moved; use SSE to darken the snagged area; apply as terminal window background) but besides that sort of thing, terminal emulators have more or less never been bastions of speed. If by VGA you mean true textmode (the 720x400 kind, generated entirely by the video card), I don't think there's much that's faster than that. Throw setfont and the Cyr_a8x8 font in there to get 80x50 (I think it is, or 80x43) and you have something hard to beat, since spamming ASCII characters at the video card's memory will always be faster than addressing pixels in a framebuffer. Which is why GPU-accelerated terminal emulators are so interesting: they're eliminating as many software/architectural bottlenecks as possible to make those expensive framebuffer updates as quick as possible. It's definitely the way to go; games are generally rated on their ability to push GPUs to >60fps at 1080p (and increasingly 2K/4K/8K), so the capacity is really there. The i3 window manager could be considered one of many comparable similar implementations to tmux. It's not perfect (it's not as configurable as I'd prefer), but it'd get you X and the ability to view media more easily. I do really appreciate the tendency to want to view a computer as an industrial terminal appliance though. Task switching is still best done by associating tasks with different objects in physical space, so keeping the computer for terminal work and keeping tablets (et al) for other tasks does make legitimate sense. --- Regarding data usage, that's a tricky one - most successful Internet companies provide some kind of service that necessarily requires the collection of arguably private information in exchange for a novel convenience. As an example, mapping services don't truly need your realtime location but having that means that they can stream the most relevant tiles of an always-up-to-date map to you. The alternative is storing an entire world map, or subsetted map(s) for the locations you think you'll need, but that'll kill almost all the storage on phones without massive SD cards. --- I find elimination of unnecessary resource consumption a fun concept to explore, almost to the point of obsession. In this regard I often come back to Forth. I was reading this yesterday - http://yosefk.com/blog/my-history-with-forth-stack-machines.html http://yosefk.com/blog/my-history-with-forth-stack-machines.... - and it explores how Forth is essentially the mindset of eliminating ALL but the smallest functional expression of the irreducible complexity of an idea, often to the point of insanity. It's not a register-based language so it's never going to beat machine code for any modern processor, but it's a very very interesting concept to seriously explore, at least. (And I say that as someone interested in actually using Forth for something practical, as described in that article.) --- AFAIK, the RPi actually boots off the GPU, or at least the older credit-card-sized ones did. I'm not sure about the current versions. ATI released some documentation about their designs a while back with the subtext of enabling open-source driver development. I don't think that panned out as much as was hoped. My understanding is that Intel has both NVIDIA and AMD beat nowadays when it comes to Linux graphics support; the two former vendors still heavily rely on proprietary drivers (on Linux) for a lot of functionality. Sadly, since they both have to successfully compete in the market, they're unlikely to release their hardware designs in significant detail anytime soon. (Even if they did like the idea of merging, single gigantic monopolies have a lot of risk, and the behemoth that resulted would be impossible for Intel to compete with, likely.) So, learning OpenCL and CUDA (depending on the GPU you have) is likely your best bet. There are extant established ecosystems of resources and domain knowledge for both implementations, and the relevant code is not too tragically licensed AFAIK.