Slow and steady with the addition of features over the last few months (http://bonhardcomputing.com/category/news/) and how does it compare to Transmit!? Transmit is an FTP app; Truck uses rsync-over-SSH.
Thanks so much for the feedback (both here and in the app). That's something we're looking into, and I totally understand it makes it hard for kids to use the app. Grasshopper is an Area 120 project (a part of Google) which is why that account system is currently used for syncing course progress and achievements between devices.
btw is there a login system you'd prefer? I'd love to forward any thoughts you have to the Area 120 leadership.
How about an anonymous login system that doesn’t require an email address and just generated a random userid / password? I’m thinking of setting up a Code Club at a local school and it would be great if kids could use it without having to provide any personal information whatsoever.
I'm surprised things like this aren't more common. Places like google strike me as great candidates for bare metal OS type setups to most effectively serve the billions of requests per days.
If I understand that project correctly, the assumption is that they think they can write assembly by hand that is more optimized than by using a compiler to optimize?
Is it time to ditch the "normal" OS? My startup is looking to do exactly that but I would like to know what others thoughts are on the matter.
My proposal is to have a small exokernel between the hardware and the application. The exokernel is there to provide very simple access to the hardware (like the disk or network) and will rely on the application to do anything complicated (like handling TCP/IP).
"Plain" OS threads certainly have their place and the OS does a fine job scheduling them. It's just that the more information you have about the threads' behavior the better they can be scheduled (you can reduce latencies by keeping related fibers on the same core to share cache; that's one of the things Quasar does).
So the increased latency of the OS scheduler has little to do with the number of layers between your application and the hardware, and a lot to do about assumptions the OS can make about your code.
You most certainly want a general-purpose OS scheduler, it's just that many applications can benefit from user-level lightweight threads.
For me, when it comes to really drastic solutions like running bare metal or building a custom OS then if you have to ask if you should then you shouldn't. But to echo the others, it depends on what you are doing.
I hope I don't come off as a creeper because I was very curious on what you are working on and dug through your comments. Is it this BareMetalOS project?
You could also be asking about whether it is time to ditch "commodity" hardware (which by the way is not massively parallel).
The answer is, of course, it depends on what your priorities are.
I've seen projects that write OS's from the ground up for a wide variety of reasons (security, correctness, optimization of use case, etc.) But very rarely is it for price reasons.
I wrote a comment about a paper I read that ditched tcp and had the application handle it to get some performance gains earlier, so you might want to page up to see it if you haven't already (Network Specialization for Performance).
How is it that you intend to do an OS startup? That's a pretty tough nut to crack.
you might want to check out the rustboot project then. one of the use-cases is to have rust boot on a hypervisor that then just has not much more than the runtime like you're after
No, it's just an immature website. I'm one of the creators. The site is just a hobby now among friends, and since we all have families, it's slow going. Thanks for the feedback everyone!
GitHub uses the open-source Pygments (http://pygments.org/) to highlight source code. If you can find the code for whatever ASM highlighter Pygments uses, you could probably fix it yourself. Though I tried searching for it and didn't find it after a while, so it would take some tracking down.
This is very interesting! It will be even more interesting to see if it can be compiled to run on my OS. This is exatly the kind of application I have been looking for. ESXi is too big :)
I can assure you it can easily be ported and used on any OS. We just a few guys right now and don't have the capacity to test it on anything but Ubuntu. However, we are designed it to portable (and NaCl/Chrome code is also portable which helps a lot). Even to run on bare-hardware. So tried to keep OS usage to minimum. In fact, porting would be a more extensive effort to architectures not naively supported by Nacl. For example zerovm on tilera-linux (MIPS variant) will be much more effort then FreeBSD on x86-linux.
As a side note, I personally convinced that today OSes are an overkill for cloud-based number crunching (the prime case for zerovm) wasting resources. I am looking forward for future a lot lighter 'cloudware'. Think 'opencompute' approach for OSes. zerovm is being a humble experiment here.
