racbart

This is truly great as proof of concept and also as a reminder that in software development building 80% of perceived* functionality usually takes only tiny fraction of total development time which is required to build final product.

* - this app looks and feels like “almost complete spreadsheet” yet it provides much less than 1% features of even a basic spreadsheet.

Yup, my provider is quite easy to find, I don't mind. I just didn't want to make this info to be googleable with their name, to respect that they never publicly wrote about it.

No idea why they don't advertise this feature. They wrote that they only tell about it to people that are actually having a problem about it. I guess it might be easier for them or for other email-ops to handle abuse/spam issues when this header is available?

Protip: If you use paid email, ask your email provider how to hide your IP while sending via SMTP. I asked mine and it turned out that they run a separate SMTP port which you can use and then your IP won't be included in message headers. This is a fairly popular provider, but I won't mention their name as they don't advertise this feature and provide it on request.

> The app doesn't auto-update favorites yet. For now you can manually update via pull-to-refresh.

Just to let you know: I favorited a song (using menu bar) and then pulled to refresh in my favorites view. The song was shown twice on the list. Same after another refreshes. After restarting the app the song is shown only once, but after pulling to refresh it's doubled again. The second copy appears slightly after the first, so it's probably some list populating launched twice.

The app is awesome and I loved it at the first sight. Thank you! I didn't know Hype Machine before, but they seem to serve some good music.

You should provide links to iTunes & Amazon to allow easy purchases if someone would like to add songs to their music library.

This is a summary of my understanding of their method after a very quick scan of their docs:

They assume working as a malicious/selfish pool having less than 50% of hash rate, but still a significant portion of the total hash rate. All other miners that are not part of the selfish pool are called honest miners.

When selfish pool finds a block, they don't advertise it but continue mining their forked, private blockchain. They have an advantage of one block over the public blockchain now. Of course they have no chance of building longer blockchain in the long term, as they have less than 50% of hashing power and the public blockchain will always get longer after some number of blocks. But what they count on is this:

Scenario 1: honest miners discover a block and the public blockchain gets the same length as the selfish blockchain. They immediately publish their block as soon as they discover someone else discovered a block. They hope to create a race condition and a public blockchain fork - so that some hones miners will get the “honest” block, but some of honest miners will get their “selfish” block and start mining using it as a base. Having some of the honest miners on their side they have a chance that their fork will get longer and the “honest” fork will be declined by the network.

Scenario 2: selfish pool is lucky and discovers another block, giving their blockchain two blocks advantage over the public blockchain. They continue mining and they publish one block for every block discovered by the honest miners. This creates race condition with some of the honest miners on their side, but they still have some blocks found and not published. They publish all their remaining blocks as soon as their advantage decreases to one block. The network chooses their branch as it's longer and they get all the reward coins from their secretly mined chain.

Now, I know nothing about blocks discovery/notification mechanisms over the network and how fast it works, so an important question to someone knowledgeable is if this is a probable scenario that their block published only after some competing block has been found and published has still a chance to get to some significant number of honest miners first so that they start mining over their block - as this is required for their strategy to work.

If the above is viable, then this strategy of course requires some significant hash rate share, but I remember that even having 10% of total hash rate, the probability that you will mine couple of blocks in a row is quite high - and that's all you need to create situations when you have two-three blocks advantage over the public blockchain.

This should be a feature on the NSA website.

This is nice if considered a programming exercise but it's actually pretty useless for real world use.

This data is static, that is it very rarely changes. The whole dataset is also very tiny. It's just better to store this data in-house and don't provide unnecessary point of potential failure by using an external service.

An idea on how to make it more useful is to provide downloadable data dump in several formats suited for immediate import into various data stores. An extra addition might be modules for popular frameworks providing access to this (local) data in all the ways your web service does.

I'm not trying to diss, just trying to find some value for real world usage. The service is neat otherwise.

Current Matchbook offer seems quite humble. Publishers will be naturally reluctant to sell their $22 books for $2 but I hope they'll understand very soon that this isn't actually a discounted sale. It's either extracting more money from past sales or making future sales more likely to happen (and also extracting more money from them).

At today's Apple, both software and hardware are means to sell 3rd party software. They earn so much on their ecosystem that it's more profitable to give OS updates for free and provide more unified and less fragmented ecosystem to both users and 3rd party developers.

Lowering prices for next generations of their hardware is also a sign that they really want to put their foot in as many users' doors as possible. I think they rarely lowered hardware prices just couple years ago, before they had this massive revenue stream called App Store.

This actually looks shady. If you're not going to charge me, then why the hell do you want my CC number?

You are correct and I'm not saying that I described the Holy Grail of detecting porn in a single paragraph. I'm just pointing to another direction. No solution to a very complex problem could be one-dimensional. Combining several different tests might lead to a solution. I.e. these jujitsu photos should not even be detected as “certain body configurations” as people there are fully clothed and there's not much actual bodies seen in the picture (so mentioned skin color definitely should come to play when detecting wether you see a body or not).

At the end of the day I doubt there could be a fully bulletproof and always correct solution using current state of tech. But you need to factor much more than just skin color if you try to build an automated solution to this problem.

Wouldn't testing for skin colors produce far too many false positives to be useful? All these beach photos, fashion lingerie photos, even close portraits. And how about half of music stars these days who seem to try to never get caught more clothed than half naked?

Nudity != porn and certainly half-nudity != porn.

I'd rather go for pattern recognition. There's lot of image recognition software these days that can distinguish the Eiffel Tower from the Statue of Liberty and it might be useful to detect certain body parts and certain body configurations (for these shots that don't contain any private body part but there are two bodies in an unambiguous configuration).

So one day you get an email that you got $100 and all you need to do as a recipient is to click on a link and enter your full credit card details? Sounds like a phishing paradise.