ramLlama

Yup, I can see it for computational experiments or "applied CS" fields. I realized this soon after I posted the comment, but I didn't bother to update my comment.

However, this still isn't clear in their website. I will give them the benefit of the doubt since they are early in their project, but I think it would behoove them to nail down their mission sooner rather than later.

This is probably what I get being in the CS bubble. =)

I like this idea, but I do not really understand who it is aimed at. The focus seems to be on reproducibility of scientific experiments and code, which is great! Many existing code artifacts are WOGSL (Works On Graduate Student's Laptop) which is the CS equivalent of "runs when parked".

So, let's break down the fields of CS for which this should be applicable:

* Systems: This won't work except for the few systems projects that are entirely in-RAM AND will work on tinycore's kernel version

* ML: This, I can see, especially with the seeming focus on dataset management. Much ML is compute-bound and the overhead of using the FUSE FS's is hopefully negligible.

So, is this focused on ML and ML-using code and experiments? If so, I think that should be clarified. I think a lot of systems folk will be (rightly or wrongly) turned away from it due to the seeming overhead of the various hyper* extensions. Not to mention that they are all written in Node/JS (Again, rightly or wrongly, many systems folk will not want to run their stuff on platforms written in JS)

I like the direction this project can go, but there seems to be a lack of focus or direction in your mission right now.

Yes, they do.

Microwave works on line-of-sight and weather patterns easily mess it up and drop the link.

That's why you usually also run your microwave data over a fiber link as backup. Of course, when microwave works, it gives you a decent improvement in latency, at the cost of bandwidth.

Another advantage of having the microphones (yes, there can be more than one!) near the ear itself is for DSP. Many hearing aids use multiple microphones to selectively amplify sounds from the direction you are facing. I think this would work best with microphones near the ear, or at least in a known position.

I too wear BTE's with glasses and most people are surprised when I tell them I wear hearing aids. They cannot see them.

This is especially true of modern "Receiver In The Ear" (RITE) models where instead of a tube carrying sound, you have a very thin wire going into your ear canal.

A bigger issue with separating the microphone and amplifier is cosmetic: hearing aids sadly have a stigma attached to them and people are more likely to wear them if they are invisible. There is a reason why hearing aids are produced in hair colors.

Also, I found that the best way to get rid of feedback was to get an ear mold rather than using an "open-fit" mold. This is a clear separation between the speaker and the microphone and pretty much solves the problem in my experience.

EDIT: I noticed late that you addressed the cosmetic issue in your post. I don't see the elderly changing but our generation just might.

This is exactly right. GNOME, KDE and other out-of-the-box solutions make sure to set the GTK and Qt themes so that everything looks pretty. When you use a WM (window manager) rather than a DE (desktop environment), it is up to you to setup all the ancillary things such as themes and daemons. This is why .xprofile exists!

Also, I find lxappearance an easy and quick way to set GTK themes via GUI rather than having to edit the .gtkrc files for every option.

Thanks! Spacemonkey looks terrific and is pretty much what I envision! I often feel that with the move to "cloud computing" over the last decade, we have essentially made a dichotomy between working "locally" and working "in the cloud". However, they really should be seamless! The cloud should extend your computational resources and make it more accessible, not replace it! With things like spacemonkey, Office 365 and other "seamless" apps, it seems that we are finally learning how to make things be location and device independent. Cloud computing is the vanishing mediator that is finally starting to vanish!

Thing is, userspace networking is a lot like the GPU business. Often times, the software is free or even OSS, but the hardware is proprietary.

I know Intel has software for their NIC's to enable userpace networking, but I don't think any HFT uses it. It may be all right for hobbyist experimentation. I left the industry about a year ago, so my information is a bit out-of-date, but my former employer used either Solarflare cards with the OpenOnload stack (very good cards and awesome software) or the Mellanox CX series with VMA stack (amazing hardware with mediocre software. VMA is now open-source, so perhaps that situation has improved).

Note that these cards are a few thousand dollars each, so out-of-reach for hobbyists.

I graduated in 2011 and my sequence used:

Alice/Java => "101"-type class

C/Perl/Shell => Intro to Systems

C => rest of the systems branch

Java => Data Structures

Standard ML => functional and logic classes.

Many of the more esoteric electives used their own thing. For example, I used Serpent in Computer Music Systems.

The curriculum changed in my final year. The new students now do:

Python => "101"-type classes and basic data structures and algorithms

Standard ML => parallel data structures and algorithms and other functional and logic classes

C0 transitioning to C => Systems courses.

I do think our distributed systems class was experimenting with Go at some point.

That's true, and I completely forgot that you can do that. In fact, that's how I last deposited a check!