mueslix

Great. You added my project to your site without asking, then cold-emailed me about it, and wrapped the whole thing in a thin layer of "congratulations". Let me be direct: this is not flattering. It's spam.

On top of that, you're asking me to pay to "boost" something I never requested, and to help amplify your marketing on Hacker News. Essentially the holy trinity of:

1. Unsolicited outreach 2. Monetizing someone else's work without consent 3. Trying to recruit the very people you spam as your distribution channel

That's not community building. That's growth hacking at the expense of maintainers.

Sorry, that was a misunderstanding. Only the chat is using web sockets, the video stream is served as HLS.

1. Websockets

2. Depends on the size of chunks and amount of files in the HLS playlist. Both are configurable values. Anywhere between 3 and 20 seconds

3. Not yet, but it's planned

One of the authors here: it should actually automatically detect your background color and adjust its theme to it. Alternatively you can pick a different style with `-s`, or even write your own one!

This is rather unfortunate. If only the spammers realized they could simply post four PRs on their own repos. That would at least limit the problem somewhat.

A fairly short answer: code readability.

People seem to try to write their code as compact as possible, not realizing that they usually only write a piece of code once, but they and others will have to decipher and make sense of it a dozen times in the near future.

It was originally written to work nicely with IPredator first, simply because that's our current VPN service of choice. UDP support will probably come, but it actually severely impacted performance (about 30% slower). Trying to squeeze out as much bandwidth as possible, we focused on the TCP part for now.

All the heavier processing is done in C already. Lua is only used for handling dis-/reconnects, rekeying and the likes. Hence I don't think LuaJIT would improve the performance much in this particular case.

That may be true for Intel CPUs, but you're forgetting the Raspberry Pis, ODROIDs, APUs et cetera.

It actually is pretty much as modular as it can get. I'm not sure what issues Martin has with compiling Qt, but I consider it a fairly straight-forward experience.

Update: I've committed a fix that prevents building this bee (freedesktop.org notification support) on Windows/OSX.

The dbus-bee obviously won't run on Windows, but it's not a hard dependency of Beehive. You can simple comment out the import of any Bee in beehive.go.

There's a discussion to be had about how to enable/disable particular bees at build time.

I guess it can't harm to ask nicely. Thanks for the tip!

huginn is a great project, by all means keep using it! The need for Beehive originally stemmed from our local hacker space, where we wanted to run a little daemon for 'home-automation' tasks, with the ability to control it via IRC. huginn was just too much of a beast for our Raspberry Pi and so we started hacking away on Beehive.

It's certainly a lot lighter, younger and less feature-complete than huginn - but it's also a lot easier to deploy and maintain in comparison. It's written in Golang, if that's your cup of tea, and really easy to extend.

Since you would self-host your own Beehive instance, there's luckily a way around that: create your own Facebook app for development (you will never publish it) and use its tokens to connect your Beehive with it.

That being said, there's no Facebook Hive yet (any takers?), but that's exactly how it works with the Twitter Hive.

Instead of making sites that try to predict the unpredictable, I'd rather ask the question if TCP is still the right tool to use.

There shouldn't be a reason for a big page with many resources to not load - it should just be slower. Yet I can make the same observations as soon as my mobile signal drops to EDGE: the internet is essentially unusable as soon as there's packet loss involved and the roundtrip-times increase. Interestingly mosh often still works beautifully in such scenarios. So instead of focusing on HTTP2 or AMP (and other hacks) to make the net faster for the best-case scenario, I'd rather see improvements to make it work much more reliably in less than perfect conditions. Maybe it's time for TCP2 with sane(r) defaults for our current needs.

I don't feel sleepy after drinking coffee, I simply don't feel it having any effects on me whatsoever. That being said, I can't stand the taste of it either, so I've probably had less cups of coffee in my life than some people have on a daily basis. Tea though... that's another story ;-)

You can download the latest YouTube resolver from here: http://teom.org/axes/nightly/

Just "Install from file" it in the settings.

Sure, you can always find us on irc.freenode.net channel #tomahawk

I assume it just wasn't accessible enough for the average user to gain a bigger user-base. The technology behind it is still alive in Tomahawk, though, and you'll be able to use Tomahawk as a headless daemon (which you can control through a restful JSON-API) in the near future.

You can find pre-packaged versions of all our resolvers (updated nightly) here: http://teom.org/axes/nightly/ - just use "Install from file" in Tomahawk's settings and pick the .axe file.

Thanks for the kind words. We've fixed the problem with the default Ubuntu theme and also have a bunch more design improvements, as well as general bug fixes which you can find in git (stable-0.8 and HEAD).

Not being able to resolve tracks at all sounds strange, though. Right now I would guess it's either a corrupted database or index. Could you try and see if you can reproduce the issue after wiping your settings / database? (~/.local/share/Tomahawk and ~/.config/Tomahawk)

There is a working resolver here: https://github.com/tomahawk-player/tomahawk-resolvers/tree/m...

Mind you, it does require Tomahawk's latest nightlies / git version.

It's currently identifying songs by meta-data only. There is an audio fingerprinter (using Last.fm's service) in the works, but as you can imagine that only solves part of the problem: getting fingerprints for data from all the various supported sources is a lot harder.

It does, of course. You can mix your local library with Spotify, SoundCloud and many more.

We're certainly looking into this idea, a bit of a Flattr for artists. I like it.

Hope you guys like it. We've got a major update in the works too, as well as an Android app. All free and open source.

The upside to being let go by Nokia is not having to work for Nokia any longer.