Bees Making Honey with Cannabis - <AUTHOR> https://greenrushdaily.com/2016/03/03/bees-making-honey-from-cannabis/ <comment><USER2> I can see see some good marketing opportunities for this. I would call it Honey Pot.

<comment><USER3> Amusingly, there is already a popular cannabis-infused honey for sale in California under the brand name 'Honey Pot'.

<comment><USER4> Yeah, I know about THC honey, so what's the difference between this and that; how is that made differently from above?

<comment><USER5> The difference appears to be that THC honey actually contains THC, unlike this honey, which merely contains its precursors in low quantities.

</comment></comment></comment></comment><comment><USER6> I work for CLEAR UK (clear-uk.org), a non-profit campaigning for the legalization of medicinal cannabis in the UK. When we put this article on our news feed, we got a comment from a beekeeper --

"Well, cannabis is wind pollinated, as you probably know. This means it does not produce anything attractive to pollinators. This is especially true with the cannabis plant, as the flowers do not produce a nectar of any kind. This 'beekeeper' is spraying sugar water on the buds to get the bees to work them. His theory is that the trichomes that are inadvertently picked up are going to be stored in the propolis, that he smokes, and also in the honey. The problem with the honey is that the trichomes would not be decarboxylated, thus not converting the thc-a into thc, thus having no psychoactive effect. It would be like eating raw weed...you would need to eat a ton, and the effects would be minimal, depending on the strain. Most strains have virtually no thc readily available.

The problem with smoking propolis is enormous, especially if you know what it is. It is basically sap from pine trees and such that the bees masticate and turn into a type of caulking for their hives. While it does have some serious antimicrobial properties, the amount of thc in the propolis would be minimal and you would be mostly smoking pine sap...surely, you can see the issue.

While male plants do produce a pollen, it is of low quality to a bee and definitely does not contain any cannabinoids.

My husband has been in direct contact with Nicolas trainerbee. He admits that he sprays the buds with sugar to film the bees working it...so, not only is he ruining a perfectly good harvest of cannabis, he is spreading disinformation to the beekeeping and cannabis communities."

"Training" bees, indeed.... As others have pointed out, the logic of this actually accomplishing anything is likely nil. If you read the article closely, you'll see it actually has very little content - it reads well, but it's more marketing fluff than anything. I don't want to write an essay here, so I won't explain further, but read it closely.

Unfortunately, the implication of THC-infused honey is going to drive the 'cannabis cures cancer' contingent mad (with desire) and Mr. Trainerbee is going to make some serious money... THC-infused Golden Manuka Honey! I really loathe all the @$%^^ going on in the cannabis related markets, but that is the essence or nature of capitalism...

<comment><USER7> I don't think it's a cannabis related issue, people have been buying 'natural healing' type of stuff for thousands of years without any regard for the science behind it.

</comment></comment><comment><USER8> I'm... skeptical.

Cannabis doesn't produce nectar, so bees won't be attracted to it. They might be interested in resin, so as to make propolis... but I doubt any cannaboids would turn up in the honey.

Disclaimer: I don't keep bees, but I've been looking into it. Someone with more experience might know more, listen to them. It'd be cool if this worked.

<comment><USER9> Bees collect pollen, not nectar.

<comment><USER10> They _distribute_ pollen via mechanical side-effects (on their legs and bodies), but that is not their goal. That effect is the _plant 's_ goal, which is why it produces nectar - to lure them.

It's the original Sharing Economy.

<comment><USER11> Bees absolutely collect pollen, they even have special pollen ball holding cups on their legs. They also collect nectar, in their stomach.

<comment><USER12> They distribute pollen to pay for the honey. The better they do it, the more flowers, the more honey. But in the end they are not going to complain individually if there is no pollen. They will of there is no honey.

<comment><USER13> > But in the end they are not going to complain individually if there is no > pollen.

I keep bees and they absolutely do store pollen in the hive to use as food (as well as nectar to turn into honey).

</comment></comment></comment></comment></comment></comment><comment><USER14> In nature, the male cannabis flower's pollen is carried by wind and gets stuck on the female's sticky resin. Cannabis is wind pollinated, so the beekeeper had to have trained these bees to ingest cannabis pollen (couldn't have been too hard, i'm sure most enjoy a good 'buzz').

I'd be very curious about the luxury cannabis honey industry. You can already buy honey made from wild flower or specific flowers like blueberry or other exotic flowers. I wonder if in a few years we will be able to buy honey made from specific cannabis strains. Given that honey is absorbed very readily into the body, using specific strains of cannabis honey may have real medicinal value, for fast action pain relief for instance.

Disclaimer: Not a medical professional, or a bee professional, nor a cannabis professional.

<comment><USER15> I don't see the added medicinal value of cannabis honey, relative to existing forms of cannabis.

<comment><USER14> My thought was since honey is absorbed quickly perhaps the medicinal effects could be fast acting. As opposed to with edibles which would take longer to produce an effect. Of course, inhaling it via smoke or vaporizer would be instant action, but many medicinal users would prefer to avoid inhalants like smoking. The benefit of instant action would be for people that have seizures or spasms, or need quick pain relief. Again, not a medical professional, just thinking out loud.

</comment></comment></comment><comment><USER16> I would expect the raw cannabis honey to have almost no THC, because it hasn't gone through decarboxylation. Raw cannabis has THCA but very little THC. Heating it releases the carboxyl group (COOH) and turns the THCA into THC.

This happens naturally when cannabis is smoked or vaporized or made into a cooked edible. Eating raw cannabis won't get you very high.

[https://www.google.com/search?q=cannabis+decarboxylation](https://www.google.com/search?q=cannabis+decarboxylation)

This page has some interesting test results:

[http://www.marijuanagrowershq.com/decarboxylating- cannabis-t...](http://www.marijuanagrowershq.com/decarboxylating-cannabis- turning-thca-into-thc/)

It looks like something similar happens with CBDA turning into CBD. The cannabis strain they used in the tests didn't have much CBD[A] in it to begin with; it would be interesting to see what happens with a CBD-rich strain. Does anyone happen to know more about this?

<comment><USER17> So the heat from the pasteurization of this honey could theoretically activate the THC?

<comment><USER16> Someone who knows more than me (OldSchoolJohnny?) could answer this better, but I think the pasteurization temperature for honey is too low. The references I've seen indicate a temperature of 145-150° F for honey, and more like 230-240° F for carboxylation.

</comment></comment></comment><comment><USER18> I am highly sceptical of his claim of "training" bees. He may make the plants and resin available and bees will tend to go for the closest convenient source, but much beyond that, I don't really believe.

I am happy to be proved wrong of course, as it would be kind of awesome to have a set of trained bees doing one's bidding!

<comment><USER19> The word "trained" does seem dubious as if the bees were taught to obey commands!

More likely the bees were "persuaded" to use cannabis by either proximity of the plants and/or treating the plants in some way to attract the bees.

</comment></comment><comment><USER20> Do the bees get high too?

<comment><USER21> No - "The bees that produce the cannahoney are not affected by cannabinoids because they do not have an endocannabinoid system"

</comment></comment><comment><USER22> I say, braking bad award of the year for Mrs Nicholas and his bees.

</comment><comment><USER23> Now I'm imagining a CG cartoon film about stoned bees starring Andy Samberg or somebody.

"Dude, like, why do we gotta serve the queen anyway? Don't you get it man? She's part of the system -- the system that oppresses us. Whoa, this is good shit."

<comment><USER24> Sounds tiresome.</comment></comment>


Ask HN: how to get "real" contracting gigs - <AUTHOR> I'm currently working as a contractor software developer, however all my jobs are for other IT companies who deliver work for the end clients.
I'd like to be in the position of delivering solutions directly to clients for two reasons - first, more lucrative, second the freedom to choose the technical solution rather than what the contracting company decides I should choose.
Could any contractors out there tell me how they got their first "real" clients ? Was it just knowing the right people, or are there steps you can take to market yourself outside the IT world ? <comment><USER2> It might sound trite but for me, the best clients I've found were people I either knew personally or who were introduced to me through an immediate acquaintance. Look around at your circle of connections - someone probably has a problem that you could solve, and they might not even realize it. After floating around on craigslist for a while, my first big client was my father in law, when I asked if he'd thought about making a website for his small business. This later turned into an online marketing campaign that paid my bills for quite a while.

If you need to build a portfolio or have no connections, you can try sites like elance or craigslist - but I wouldn't rely on them for too long. People shopping sites like that are looking for a bargain and probably won't pay what you're worth.

</comment><comment><USER3> 1\. Network of your friends and ex-colleagues. Meet or call them to say that you are available. They or someone on their network is likely to have some work available. This is your best bet for the first gig.

2\. Meet people at networking events.

3\. Ask from your earlier middlemen if you can use "non-real" gigs as a reference on your website. "Together with Company X, I helped to build Y for company Z."

4\. Be ready to do your first gig way below your price. And do it well. It's really valuable to have one gig under the belt.

5\. Pick a niche. If you build just websites, there are several established small web development companies in your area. But if you build websites for lawyers, or build iPhone-versions of an existing websites, you have a better change to become a name that is recommended when people are looking for a right person for the job.

6\. Do something small but visible as a spare-time project. It doesn't need to be on your niche, but something that other techies in your area appreciate.

The client has to have a trust that you are the right guy for the job. To get people calling you instead you calling them, you have to build that trust over the time. But you can shortcut it somewhat when people that already know you recommend you to someone.

<comment><USER4> _Be ready to do your first gig way below your price._

The best way to do this is to offer a discount for new customers. Once you're established you'll instead want to offer discounts for established customers, but framing your low initial price as a discount will help you adjust it to the market rate once you have some experience under your belt.

 _Do something small but visible as a spare-time project._

This is extremely worthwhile. For example, I organized a meetup for JavaScript developers in my city. It grew over time and is now how I meet a lot of my clients and friends.

<comment><USER3> _The best way to do this is to offer a discount for new customers._

Exactly, good that you highlighted that. And although other party knows that you couldn't ask your price at this point and the discount is not really a discount, I still did say our target price. It feels a bit stupid, but it's worth of it: "Our price is $100 per hour, but as we need a good show case project, we are ready to this for $60 per hour."

One other thing. Try to get gigs that have small enough scope in the beginning. You learn a bit about how to negotiate, how to deliver etc. Plus usually clients like it that you are not trying to structure a deal where you milk them for next 6 months.

</comment></comment></comment><comment><USER5> Networking events work wonders on finding new clients. They might start you off with a small project, probably with constraints, but as you grow with them, you will usually have more freedom.

Check with your local Chamber of Commerce for events. Also, go to events that are totally outside of IT, such as construction or travel. Talk to people and tell them what you do. Somebody will have an idea that they want coded up.

<comment><USER6> I have been to several non-tech networking/CoC-type meetings, and my problem is that after saying I do web development, the conversation usually quickly turns to "my PC has some kind of virus".

I suppose I should see this as an opportunity of some kind (installing antivirus software an "in"?), but I want to avoid becoming someone's 24x7 Windows tech support guy.

</comment></comment><comment><USER7> Personally, I started off with the 'real' clients and then moved on to the position you find yourself in. Personally, the real client's weren't worth the effort. Once I had a good relationship with a few shops, I didn't have to bother with any more marketing and sales thus freeing me up to do billable work.

Of course, this was better for me b/c I hate doing sales. YMMV.

</comment><comment><USER8> If the reason you want the freedom to choose a technical solution is because you want to use a really good technical solution, it might be a good idea to find a consulting company to work for that takes pride in their tools and practices. Ones that come to mind include Pivotal Labs, Viget Labs, Intridea, and here in Boulder, Quick Left.

If working remotely (i. e. from home or while traveling) is a big part of your reason for contracting, I suggest Intridea, where telecommuting is common and not limited to people at the bottom of the hierarchy. <http://intridea.com/careers>

<comment><AUTHOR> Thanks, but I'm looking to get started on my own rather than join yet another consulting company.

</comment></comment><comment><USER9> Can anyone comment on the intersection between (clients who are happy to interact with you purely over Skype vs. clients who fly you out to deal with the in person occasionally) and (consulting through other companies vs. consulting directly for the client)? Is there any correlation between one property and the other in your experience?

</comment><comment><USER10> I started off as a private contractor through an agency. I was hired through said agency to work for a large company.

The job went very well, and was rehired directly by that company as a 'vendor' (on their suggestion). More money in my pocket and theirs by cutting out the middle man.

Still there 3 years later, with the flexibility of being able to work on other projects outside.

</comment><comment><USER11> I was pleasantly surprised by the clientèle on Craigslist, esp the Bay Area. Meet-Up.com has landed me some deals as well.

</comment><comment><USER12> ONE and ONLY ONE word: networking. It's the most important factor in getting your initial customers. Once you have those, they are added to your network, and will continue to bring you new work IF you do good work.

</comment><comment><USER13> I might be a good client. Can you point me to some stuff you've done?

<comment><AUTHOR> Check my profile for my throwaway email account, if you want to email me I'll reply with a list of sites I've worked on.

</comment></comment><comment><USER14> Tell your next potential client about your crack staff.

1\. Get them to sign a contract.

2\. Put ads for 3 developers on craigslist. Send the developers over.

3\. You go check on them every day at 10:30 am.

4\. At about 11:30 am walk down to the client's office, chat for 10 minutes and then ask "have you had lunch yet?"

5\. Take client to lunch everyday. They pay you to take them out to lunch. Just pad the fee enough.

<comment><USER15> provide the "warm fuzzy feeling" as some freelancing/consultant how-to once said:

<http://unixwiz.net/techtips/be-consultant.html></comment></comment>


Google Ordered To Teach America How To Put Passwords On Wi-Fi Networks - <AUTHOR> http://www.forbes.com/sites/kashmirhill/2013/03/13/google-ordered-to-teach-america-how-to-put-passwords-on-wi-fi-networks

<comment><USER2> What a bullshit case, judgement, and punishment. Unencrypted wifi should be collectable. Don't broadcast in the plain on a public channel if you want some special level of privacy. This is an incredible case and probably not politically worth the fight for google. All of our rights have been limited by this judgement.

<comment><USER3> But most unencrypted wifi exists because of tech illiteracy/laziness on the part of users. Its not a conscious choice they made. Commercial collection is exploiting this. Finally your last sentence is unnecessarily hyperbolic.

<comment><USER2> Generally, it isnt the job of the state to protect the ignorant and the lazy. Sorry, but this kind of precedent is going to lead to even more draconian judgements over "computer trespassing" and "hacking." Computer crime laws aren't reasonable as-is and now with this new case law, they're arguably worse.

The ISM band exists within strict FCC control. There is no "don't sniff" provision and if there was, it would make promiscuous mode or applications like inssider illegal.

<comment><USER4> It is _exactly_ the job of the state, because the ignorant do not know how to protect themselves, or even that they are ignorant.

I dare say that _every day_ you are protected by the state from those who would take advantage of your ignorance in many, many aspects of the world. The system works well enough that you don't even notice what you're ignorant of!

<comment><USER5> This is how we end up with bans on soft drinks larger than 16 ounces.

<comment><USER6> Sorry, but I think Bloomberg is on the correct side of that issue, even if he won't win in court. It's becoming increasingly clear that large quantities of sugar are a long-term poison. Since there's no practical use for soft drinks other than "They taste good" (which is a personal-happiness argument, but a particularly juvenile and narrow-minded one), large softdrinks _should_ be banned. If arsenic salts tasted really good, and they were not already banned, would you oppose efforts to get restaurants to stop serving that?

Just because a paternalistic state is usually bad doesn't mean that government shouldn't intervene in anything.

<comment><USER7> Mandated warning labels would be a better idea. Banning things is rarely necessary to achieve policy goals.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> > to instruct Americans not to let neighbors free-ride on their Wi-Fi networks

This is such a weirdly negative framing. What's wrong with sharing? I've always left my wifi routers open and unsecured so my neighbors can use the bandwidth if they want.

<comment><USER9> > What's wrong with sharing?

A few things. Some of these things can be mitigated, but I think then we've moved beyond simple sharing.

1\. Your neighbor could use too much bandwidth, thereby impacting your usage negatively.

2\. Your neighbor could do naughty things on your Internet connection, and you'll be held liable. Practically, this might mean getting a bunch of DMCA notices. For some ISPs, this has a real impact on your account.

3\. Many applications by default share their data with whoever is on your network. Maybe this is OK, but maybe it has stuff that you'd rather your neighbors did not see.

To clarify, I think sharing is great if you decide to do it. But I also think that the uninformed should be advised to not share by default because of the issues I mentioned above.

<comment><USER10> 1\. This is not necessarily wrong. Maybe I set it up so he can use all the bandwidth that he can get

2\. Why is only the penultimate hop responsible for the last hop? Why should he be responsible in the first place? And why shouldn't all the network hops in-between be responsible as well???

3.Yes, it is OK

"Link sharing" is OK regardless of your decision whether to share or not. Don't blame the technology man.

<comment><USER9> I think you've blithely missed the point. I will quote my concluding remark for further emphasis:

> To clarify, I think sharing is great if you decide to do it. But I also > think that the uninformed should be advised to not share by default because > of the issues I mentioned above.

...

> This is not necessarily wrong. Maybe I set it up so he can use all the > bandwidth that he can get

Maybe you did. So?

> Why is only the penultimate hop responsible for the last hop? Why should he > be responsible in the first place. And why shouldn't all the network hops > in-between be responsible as well???

Red herring. We're not talking about the appropriate legal perspective of network responsibility, but rather, what _is_ the legal perspective of network responsibility.

> Yes, it is OK

For you? Great! Not for everyone. Which was my point.

<comment><USER10> I get your point. I just don't agree with it. If you don't want to share your data that doesn't make sharing bad. Which is _my_ point.

And what _is_ the legal perspective for this issue, anyway? Do you equate it with illegal activities in a house? So the owner is responsible for what's going on there? It's not the same thing.

If you could be 100% sure that the originator is the true owner maybe you could have a stand in your argument. But you can't be 100% sure that the network is uncrackable.

<comment><USER9> > If you don't want to share your data that doesn't make sharing bad.

This has two interpretations. Either you're claiming that:

1) Just because person A doesn't want to share their data doesn't mean that it's bad for person B to share their data.

or

2) Person A doesn't want to share their data, but person A having their data shared unwittingly isn't bad.

I agree with (1). I don't see how (2) can be true. If I don't want my data shared, then having it shared is bad.

Moreover, this isn't even _just_ about sharing data. It's also about sharing bandwidth and legal/ISP ramifications.

> And what _is_ the legal perspective for this issue, anyway? Do you equate it > with illegal activities in a house? So the owner is responsible for what's > going on there? It's not the same thing.

I don't equate it with anything. My initial post was _very_ clear about potential ramifications. Perhaps you should re-read it.

> If you could be 100% sure that the originator is the true owner maybe you > could have a stand in your argument. But you can't be 100% sure that the > network is uncrackable.

You're still very clearly missing the point. I don't care who the "true" owner is. I don't care about the workings of the network. In this instance, I care about what my ISP will do to me and what the government will do to me. I was very clear about this in my initial post.

Please revisit the context of this discussion. The top post in this thread asked, "What is wrong with sharing?" I answered with what I could see as the potential pitfalls of sharing. What argument are you trying to make exactly? That sharing has no pitfalls?

</comment></comment></comment></comment></comment></comment><comment><USER11> Aren't two issues being conflated here? (1) Securing access to your wi-fi with a password so that your neighbor can't free-ride on your ISP and (2) Encrypting your wi-fi traffic so that your neighbor (or Google) can't spy on you.

<comment><USER12> Conceptually, yes, these are two different issues. But since wifi security pretty much requires encryption of the traffic (otherwise anyone could just sniff your credentials during the access negotiation), and encryption requires some sort of access control anyway, they always go together in practice.

</comment></comment><comment><USER13> schneier on open wifi networks (he's for them): [http://www.schneier.com/blog/archives/2011/04/security_risks...](http://www.schneier.com/blog/archives/2011/04/security_risks_7.html)

<comment><USER12> I normally agree with Schneier, but I think he's wrong on this one. Basically his argument is that, rather than try to secure your wifi, you should just leave it open and make sure your personal computers are secure enough to be used on an open network. He points out that, if you use your laptop on public networks, you have to secure it anyway, so there's no additional risk to having your home wifi basically be a public network.

All that may be true (though I would argue that, since you use your home connection a lot more than any other, your risk exposure is much greater and therefore it makes sense to have a layered defense there), but it completely misses the point that you are responsible to your ISP for how your internet connection gets used. Starbuck's may be able to say "look, we're a public place, we can't possibly control everything that everybody does on our wifi", and get away with just making people check an "I agree to your terms of use" box when they connect to their wifi. You, as a home user, are not likely to get away with that.

Schneier also says this: "if someone did commit a crime using my network the police might visit, but what better defense is there than the fact that I have an open wireless network? If I enabled wireless security on my network and someone hacked it, I would have a far harder time proving my innocence." This seems backwards to me: if you have enabled wireless security, you know exactly who you have authorized access to--it's whoever you gave your passphrase to. So it's easy to distinguish authorized from unauthorized use. If you leave your wifi open and someone uses it for something nefarious, how can you defend yourself? You're still liable for the use of your internet connection, and you can't say the use was unauthorized because, well, you left your wifi open for anyone to use.

<comment><USER10> "You, as a home user, are not likely to get away with that."

His point is that you _should_ be able to get away with that. Precisely because there is no difference between an open network and a cracked one!!!

<comment><USER12> _there is no difference between an open network and a cracked one!!!_

Yes, there is. An open network means whoever is providing the wifi disclaims all responsibility for how the network is used. Starbuck's may be able to get away with that, as I said, but I don't think the average home user can, unless they have a really unusual ISP. Have you read the fine print in your ISP's terms and conditions?

If the point is that home users should not have to tolerate those kinds of terms and conditions, I don't disagree; but I don't expect it to happen any time soon. :-)

<comment><USER14> As Schneier describes it, there is a trade-off. Would you rather be kicked by your ISP for T&C violations, or imprisoned and branded a sex offender for your neighborhood wireless hacker's kiddie porn habits? If the chances of each scenario were roughly equal, I'd certainly agree with Schneier to prefer the former scenario. Since the former scenario seems much more likely than the latter I'm not so sure.

<comment><USER12> _your neighborhood wireless hacker's kiddie porn habits_

If your wifi is secured and there are open networks nearby, the hacker isn't going to bother trying to hack yours (I assume you're using WPA, not WEP, the latter is so easy to hack now that it doesn't really make a difference). He's going to use one of the open ones. To have a serious chance of having your WPA hacked you would need to have attracted the notice of someone much more determined than your neighborhood porn junkie, someone like the NSA. So I would say the former scenario is _much_ more likely than the latter.

<comment><USER10> Let's see: You are a high profile figure who happened to step on someone's tail. What should we do to make you behave? I know, we'll show the whole world how you download child porn. Did I say "child porn"?

You mean the burden of proof is on you that you secured your network? How can you prove this, because, you know, you can't!

<comment><USER12> So you're saying that if you are a high profile figure who happened to step on someone's tail, you should run an open wifi network to make it exponentially easier for your enemies to convince the world that you download child porn?

You say you run an open wifi network, so anybody could have downloaded that porn using your wifi? You're a high profile figure and you expect us to believe that? Yeah, right.

We can spin scenarios all day. At the end of the day, I still think that an ordinary person with an ordinary ISP is better off securing their wifi; the likelihood of WPA security being broken is _much_ smaller than the likelihood of someone using your open wifi to do something that your ISP won't like (or worse). Even a high profile figure is, IMO, better off securing their wifi than running an open network for every nutjob who has a fixation on them to use.

<comment><USER14> _You're a high profile figure and you expect us to believe that?_

For someone in this situation, it's very unfortunate that Google doesn't have this info anymore!

Although historical records would be more dispositive, it isn't difficult to verify that someone is running open wifi now.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> > Google is going to teach naive people how to put passwords on their Wi-Fi > networks.

Good luck with that. Setting up passwords varies between different routers. So what may work in their ad may not work for grandpa down the road. Telling manufacturers to set a wifi password by default would probably do more to secure people.

<comment><USER16> Setting wifi passwords would be a good start, but then you'd still have to address the security flaws in wps[1] and upnp[2][pdf].

[1]: <http://code.google.com/p/reaver-wps/> [2]: [https://community.rapid7.com/servlet/JiveServlet/download/21...](https://community.rapid7.com/servlet/JiveServlet/download/2150-1-16596/SecurityFlawsUPnP.pdf)

<comment><USER17> Well, it doesn't need to be secure _per se_, just secure enough that it mitigates Google's liability. Like the password/PIN rules at the bank.

</comment></comment></comment><comment><USER18> I would like to propose that we, as technologically literate people, start to separate the concepts of encrypting your WiFi signal, and sharing your WiFi signal.

Encryption has true security benefits, primarily the prevention of HTTP session hijacks via tools like Firesheep.

You can still share your network by simply putting the password in the SSID. Name your network "Password is 12345" or something. Encryption protects against Firesheep even if everyone knows the password.

<comment><USER19> Are you sure about that? How does that possibly work? If the shared secret is known, how can you possibly prevent people from hijacking the connection?

<comment><USER14> Both the AP and the client station produce nonces, which together with the passphrase and other values are used to calculate "pairwise" keys and eventually session keys. This makes hijacking more difficult. As you intuit, however, it can certainly be done by one who knows the passphrase and is able to sniff the nonces.</comment></comment></comment>


Clothing Gets Computerized - <AUTHOR> http://singularityhub.com/2009/06/18/clothing-gets-computerized/

<comment><USER2> The future is annoying.</comment>


Judge Dismisses Kaspersky Suit Challenging Software Ban - <AUTHOR> https://www.wsj.com/articles/judge-dismisses-kaspersky-suit-challenging-software-ban-1527711772 <comment><USER2> I just wish they'd release what they have on Kaspersky. All they've given us is vague assertions.

The only specific thing I know is that a CIA contractor took some CIA tools home had Kaspersky installed, and had it setup to auto-submit samples, so naturally it detected the hacktools and submitted them...

But the implications have been that Kaspersky has been actively used to spy on US agencies and companies. But again no technical information has been published, which would be hugely damaging to Kaspersky's reputation.

There's three possibilities:

\- They're right and Kaspersky is working for Russian intelligence (but the US aren't releasing technical information for unknown reasons).

\- They're doing this to promote American and European alternatives which can be manipulated by Western intelligence (e.g. exclude state sponsored malware from definitions).

\- It is just a "red scare" within the US DoD, and they aren't releasing technicals because they have no technicals. It is just playing Telephone between analysts using vague assertions and feeding off of one another (see Iraq War).

All I am asking for is "Here's a technical paper explaining exactly what we caught Kaspersky doing." If we got that and it held up, I'd be fully onboard.

<comment><USER3> > I just wish they'd release what they have on Kaspersky. All they've given us > is vague assertions.

That's probably what they have. But imagine you're a Government Official and the Member of The Press asks you: "Do you know that your office is running software produced by Russians? The same Russians that hacked our elections?! And not just by any Russians, but Russians with links with Russian Government, which includes Russian Military, Russian Intelligence Service and controls Russian Nukes?!"

Of course, you could start explaining that doing business with Russian government (aka "links") is not weird for a Russian company, especially a major one and near-monopoly on the local market, and you can not declare every Russian a spy just because Russian spies exist and sometimes even mess with some American interests, even though nothing of the sort happened in the election - you can try to do all that and earn a headline "Government Official N. Is Soft on Russia - Idiocy or Corruption?" And God forbid it turns out you visited an industry conference in Russia 3 years ago or attended, among other 500 people, a reception which (unknowingly to you) was paid by a Russian oligarch living in New York...

Or you can ban Kaspersky software - which has a bunch of viable local alternatives anyway - and earn a headline "Government Official N. is Exercising Reasonable Prudence in the Face of the Red Threat". Which one would you choose?

> They're doing this to promote American and European alternatives which can > be manipulated by Western intelligence

Could be but more likely they are just opportunist and doing CYAing.

> It is just a "red scare" within the US DoD, and they aren't releasing > technicals because they have no technicals.

Rem acu tetigisti.

> All I am asking for is "Here's a technical paper explaining exactly what we > caught Kaspersky doing

Don't hold your breath.

<comment><USER4> And Russians are using products produced by Google, the same Google that has deep relationship with government and military contracts. With your reasoning, every countriy should ban products of GAFA.

<comment><USER5> They most definitively should.

In that case we even know, that US companies are be forced to cooperate and are legally barred from reporting it. Any foreign government using commercial US software for sensitive information is at least reckless.

</comment></comment></comment></comment><comment><USER6> Paywall bypass: [https://archive.is/bTGtX](https://archive.is/bTGtX)

</comment><comment><USER7> Predictable. No word yet on whether the evil witch floats or not.

The entire thing is a fairly transparent attempt to gin up some anti-russian sentiment in the wake of a growing presidential scandal under active investigation that keeps turning up damning evidence. At best it pulls the administration out of the fire for a few days but frankly all its doing is insisting the US is open for business until we find a big enough bus to throw you under for our own political gain.

Same with Huawei. Its difficult to cast an outright ban on import as anything less than telecom players waving their hands and crying red-scare to an audience of congressmen that are either old enough to remember duck-and-cover drills or ancient enough to have actually participated in some of the clandestine blacklisting and CIA funded government overthrow in central America.

</comment><comment><USER8> Who needs proofs when it comes to Russia. It's mordor according to the american media and deep state. Everything that stems from it represents Dark Lord aka Putin. Let's just keep inventing stories about it until we all eventually believe our own lies. Maybe inventing more stories about how good we are and how evil they are will make our beliefs stronger like it has always worked throughout history.

<comment><USER9> Why give Russia the benefit of the doubt when there are many proven instances of wrongdoing on their part?</comment></comment>


Ready 0.6 Released - <AUTHOR> https://plus.google.com/u/0/110214848059767137292/posts/WDxsi4GkbYx

<comment><USER2> For anyone else who has never heard of it, very cool:

 _Ready is a program for exploring continuous and discrete cellular automata, including reaction-diffusion systems, on grids and arbitrary meshes. OpenCL is used as the computation engine, to take advantage of the many-core architectures on graphics cards and modern CPUs. OpenCL also allows rules to be written in a text format and compiled on the fly. Ready supports a compact XML-based file format so that images and rules can be shared easily. Ready supports 1D, 2D and 3D data, as well as polygonal and polyhedral meshes._</comment>


Reinvented 'Iron Lung' Technology - <AUTHOR> https://www.independent.co.uk/news/health/coronavirus-iron-lung-nhs-ventilation-papworth-a9440931.html <comment><AUTHOR> _"... non-invasive method of ventilation that is cheaper and easier and which works at least as well if not better than traditional ventilation."

"... This is cheap and easy and can be built with off-the-shelf materials available in the UK with very few moving parts for around £1,000. A standard ventilator starts at 10 times this."_</comment>


Objectify for Mac: Convert JSON to Objective C code - <AUTHOR> http://tigerbears.com/objectify/

<comment><USER2> Sounds useful, but I hardly see myself spending 20$ on something that looks trivial. Did I miss any complicated feature?</comment>


BusinessWeek names Inkling (YC 06) one of America's most promising startups - <AUTHOR> http://blog.inklingmarkets.com/2010/03/businessweek-names-inkling-one-of.html

<comment><USER2> Congrats! Overall, this list had some great ideas. It's refreshing to see a whole crew that aren't being discussed in the typical Silicon Valley blogs. I thought sparefoot.com was especially cool.

</comment><comment><USER3> Are you guys gonna be at the HN meetup tonight?

<comment><AUTHOR> :( I don't think it can work for me tonight. I'll see how it goes. But I've had dinner slow cooking since 10 am for Lynette and I :) And she might be getting home kinda late. I'll try and get us to the next one.

</comment></comment><comment><USER4> Congrats Adam!

</comment><comment><USER5> Also an interesting company: <http://www.inkling.com/></comment>


Experimenting with Node.js - <AUTHOR> http://jeffkreeftmeijer.com/2010/experimenting-with-node-js/

<comment><USER2> While I think it's great that more and more developers are being exposed to building network applications using async I/O (which I guess is "evented" now) via Node.js, I think it's worthwhile to point out that the state of the art has moved well beyond these kind of callback frameworks. The reason is simple: it sucks programming in callback patterns on serious, large projects. You end up with lots of routines that are 6 or 7 callback chained together--and don't forget to attach error callbacks as well at each point.

In the Python world, for example, eventlet, gevent, and diesel (disclosure: my project) all use coroutines to achieve very high performance asynchronous I/O that's still written in a "synchronous" style. And before that, CCP games has been using stackless python to do coroutine-based networking for the servers behind the very popular MMORPG eve online (<http://www.tentonhammer.com/node/10044>).

Even slicker, in languages like Erlang and Haskell (via forkIO + the select/epoll I/O manager), support for asynchronous networking using "blocking-style" code is a fundamental language/compiler/vm feature. When you write _any_ code in these languages, you're transparently taking advantage of the same scaling characteristics node.js and its ilk provide.

So, I'd humbly suggest to anyone getting serious about doing this kind of programming that they investigate some of these systems (which are usually built by weary callback-style async I/O veterans) and leapfrog the rest of their peers. Consider Node.js a gateway drug.

Linkage:

<http://eventlet.net/> <http://github.org/jamwt/diesel> [http://en.wikipedia.org/wiki/Asynchronous_I/O#Light- weight_p...](http://en.wikipedia.org/wiki/Asynchronous_I/O#Light- weight_processes_or_threads) [http://www.galois.com/~dons/slides/a-scalable- io-manager-for...](http://www.galois.com/~dons/slides/a-scalable-io-manager- for-ghc.pdf)

<comment><USER3> I've heard this before. "Oh, callbacks are fine for little things like this hello world demo, but for Big Programs, you need (threads/coroutines/etc.) because they're Serious Business."

That might be true. Maybe for Big Programs, something else is better. But I think the problem is that setting out to build a Big Program for Serious Business is Doing It Wrong.

The best frameworks (or, at least, my _favorite_ frameworks) are collections of small tools with consistent interfaces and interchangeable parts.

If you can manage callbacks for a 100-200 LOC program, then you can build a Big Program out of such modules with a little bit of forethought. Instead of setting out to write a Big Program, why not try to figure out how to express your Big Problem in terms of a bunch of Little Problems, and then come up with a way to have Little Programs assemble.

Then, assemble the Little Programs to solve the Little Problems. There is no solveable Big Problem which cannot be broken down into some finite set of Little Problems.

Callbacks make it natural to solve problems in this manner.

I actively develop a several thousand line NodeJS project. It's quite nice, actually.

<comment><USER2> I don't know how to completely address your post b/c it responds to assertions I didn't make. I said nothing about "Serious Business"--and bundling threads and coroutines together is like bundling horseshoes and bicycles. I made no defense of threads.

Callback style, within an I/O handler, is (almost always) a concession to the event loop. When I'm writing a program, I write:

      routine():
        result = do_one_thing()
        do_next_thing(result)
        do_whatever()

With callback based I/O, you need the routine to _end_ so the "reactor" up the call stack can get control again to do I/O on your behalf:

      routine_1():
        return make_some_io_request(callback=routine_2)

      routine_2():
        return make_another_io_request(callback=routine_3)

      routine_3():
        return send_response_to_original_socket()

Now, if you were desperate, you could just call over to the reactor like this:

      routine():
        resp = do_io_for_me()
        next_resp = do_more_io_for_me(resp)
        return transform(next_resp)

.. but, there are (at least) two problems with this:

1\. You're making the stack deeper every time you "call over" to the reactor... you will stack overflow eventually

2\. In most languages, the reactor doesn't have a way to "call back into" your stack frame and resume it.

Coroutines are a way to "call over" to the reactor, have your stack state frozen (in heap space, without going deeper in the call stack), and then "unfreeze it" later on, when the reactor has completed the IO.

The greenlet package provides this for Python; Haskell and Erlang have native support for this. And, this is ultimately how you want to program. A(); B(); C(). Sure, there are exceptions for UI driven callbacks, and callback patterns aren't all bad, but typically in network IO cases, the callbacks are explicitly a concession to the I/O loop's need to be scheduled, made necessary by a missing language or vm feature.

And: cleaner code benefits 200 LOC apps as much as it does 200k LOC apps. A good design is a good design at any scale.

<comment><USER4> Could you be a bit clearer about what's going on in your third example?

<comment><USER5> I think he's saying that the main event loop has called a callback, only to have that callback either call the main event loop, or something similar that processes events until a certain condition, and that in turn may cause other callbacks to be called. Stack depth has increased. And it tends to lead to bugs because sometimes unconsidered things happen in the midst of the first callback's processing.

</comment></comment></comment></comment></comment><comment><USER6> Why is it that within ten seconds, I felt compelled to "hump" other arrows with my own?

It was also interested to see if I could get other people to form lines and other constructs, without any communication other than my own cursor.

<comment><USER7> I'm with you that I found the social implications of this many times more interesting than the technical ones!

</comment></comment><comment><USER8> I made this RPG node demo a while back: <http://sleeperbot.com>

I'm not using any server monitoring so it can crash at any moment.

Would love to get more than 15 users on here moving around and see what happens.

code: <http://github.com/weixiyen/avatar>

<comment><USER9> I would highly recommend sanitizing chat input. As a quick demo, type '<script>alert("a")</script>' or something.

Very cool concept though.

<comment><USER8> thanks, i put that in.

the blinky body toggle was pretty cool to see though :)

</comment></comment></comment><comment><USER10> Make it funnier, show us a maze and people trying to solve it in real time. Replace the mouse pointer with a colored token and constrain its movement to the walls of the maze.

<comment><USER11> This was a startup idea I had when I started Mibbit (I decided on balance webchat had more potential than multiplayer web games).

The idea was 'mouse games'. I had a similar setup where you could see everyones mouse cursor. I planned a whole load of multiplayer games where you could chase each other, complete puzzles, click on other people to kill them, draw circles round other players to trap them, etc etc. You could have messages show up like "First to draw a square gets a point". "Move to the left get a point". "Move as far away from everyone else as you can. Most isolated player gets a point". You could have objects being thrown at cursors, and you have to dodge them. Tons of potential to be a fun way for people to waste time :)

I'm sure it would have been great fun to make :)

<comment><USER12> It still sounds like a pretty cool idea to me - I'd certainly check it out if something like that existed.

<comment><USER11> But would you also:

      * Come back regularly to play it?
      * Pay to play it?!! :/
      * Click on ads? (If the creator were evil, they'd confuse
        the users into clicking on ads, making them think it's
        part of the game).

Still a fun thing to make though!

<comment><USER12> As with everything, it depends on the implementation ;)

I think it's probably tougher to monetize a web game, but flash game creators seem to be doing moderately well with advertisements that run before you can play the game.

There's an interesting hook in what you're talking about: I could IM a friend and say "hey jump on here, let's play together". It's much more social than most web games out there which is intriguing.

In general most web pages feel like you're there by yourself. The model of seeing many other people there at the same time is novel enough right now that it should be a little easier to get people to tell each other about it.

</comment></comment></comment></comment></comment><comment><USER13> Extremely cool demo. It would be interesting to see this applied to analytics, so you could see exactly what people are doing on your site in real time. Although that would also be a bit creepy.

<comment><USER14> There's already something called Hummingbird that does that: <http://mnutt.github.com/hummingbird/>

<comment><USER13> Hummingbird shows traffic in real time. It doesn't show mouse movement or user activity in real time.

</comment></comment></comment><comment><USER9> I am thoroughly impressed, and excited for the prospect of unimaginably awesome web applications. I do have a few thoughts:

\- How easy would this be to implement in another event-driven server, such as Tornado?

\- I have an identifiable "mouse ID" in this app. Is this secure? Surely the security aspects of web sockets have been key in their design, but I am left with a bit of uneasiness with my browser opening a TCP connection to another server. I believe WebSockets will pave the way for a whole new class of web- based attacks, and possibly even highly mobile worms.

</comment><comment><USER15> Please could you move your cursors out of the way? I'm trying to read the text.

Edit: This lame comment is the highest rated here? You disappoint me.

<comment><AUTHOR> There's a "disable" button in the yellow box. That'll make them go away completely. :)

</comment></comment><comment><USER16> I'm wondering if Javascript will start being heavily used server-side? Would it be wise to start learning JS and how to use Node.js or is it absolutely not suitable for production use?

<comment><USER17> Regardless of the popularity of Javascript on the server-side, if you're writing a web-based application, then your architecture will benefit from:

1\. Shared code between client and server.

2\. Specialization in one language.

V8 and Node are at least a very good combination for server-side Javascript.

Re: "is it absolutely not suitable for production use?"

Node in alpha state is already more production ready than many "production ready" tools.

</comment></comment><comment><USER18> The cursors looked disturbingly like flies. Pretty insane demo.

</comment><comment><USER19> amusing: <http://i.imgur.com/qHWYm.jpg>

</comment><comment><USER20> <http://i.imgur.com/OCaBf.jpg>

I feel OK about doing this.

<comment><USER21> I feel conflicted about doing this: [http://www.youtube.com/watch?v=jULOA7mSOac&fmt=22](http://www.youtube.com/watch?v=jULOA7mSOac&fmt=22)

</comment></comment><comment><USER22> It would be interesting to hear from the author how the server is handling HackerNews traffic

<comment><AUTHOR> Hi, author here. While building this thing, the Node server had the tendency to drop out. I'm monitoring it with God (<http://god.rubyforge.org/>) now, so it restarts whenever anything goes wrong.

I'm genuinely impressed by how it's holding out now. :)

<comment><USER23> Could you elaborate on this at all? What kind of traffic are you getting (max concurrent requests handled perhaps)? Any idea why Node dropped out?

</comment></comment></comment><comment><USER24> Web sockets are great, but almost all of the demos I see use a separate port (i.e. not port 80), making the app useless in practice.

Come on guys - it's _Web_ sockets, not intranet sockets.

<comment><USER25> Could you elaborate on why a nonstandard port makes these apps useless?

<comment><USER26> corporate firewalls blocking nonstandard ports, you running other apps on those ports, your firewall throwing a wobbly, general nonstandardness.

if 80 is impractical, many people suggest running off 443 as that (the https port) is unlikely to be filtered.

<comment><USER24> It's not hard to serve both regular http requests and web socket requests on the port 80 on the same host. Just use a special context path for web socket requests, for example /websocket/*

Some of the node.js websocket impls let you do this easily while others don't. Don't use the ones that require a separate port. Nobody behind a corporate firewall will be able to use your app if you do.

<comment><USER27> I think it is possible to have a ws server listening on the same port (and even path) as an http server, hence it shouldn't really matter.

And if you really care, you could make a http forwarding proxy with node to forward normal http requests through to your app if it's written in something else, but deal with websockets itself.

</comment></comment></comment></comment></comment><comment><USER28> It a strange mix of disappointment and excitement to find out someone has just released a better finished version of what you were working on. Oh well, I guess I'll finish it anyways.

<comment><AUTHOR> Please let me know when you finish it. I would love to see your code. :)

<comment><USER28> It has mutated quite a lot since I started... I'm taking the positions of everyone's mouse and feeding them to Fortune's sweep line algorithm to make Voronoi diagrams. I've made it look like you are a cell squeezing through layers of tissue. <http://uncc.ath.cx/applets/Voronoi_Standalone/>

</comment></comment></comment><comment><USER29> Great stuff.

Just for sake of completeness, you can basically copy-paste that code into Ruby as well via em-websocket: <http://github.com/igrigorik/em-websocket>

Also, to avoid some of the callback muck that a few have brought up: <http://github.com/igrigorik/em-synchrony>

(same idea, closures + coroutines to abstract the callbacks).

</comment><comment><USER30> Is the server down? I cannot see any arrow even when I open multiple windows (Chrome 5).

<comment><USER31> Check your firewall, the websocket doesn't use the port 80.

</comment></comment><comment><USER30> For some reason, the background picture is distorted when remote mouses hover it (Chrome 5). Anyone has an explanation?</comment>


Apple is taking away iPhone owners' right to bear (emoji) arms - <AUTHOR> http://qz.com/747769/apple-is-taking-away-iphone-owners-right-to-bear-emoji-arms/ <comment><USER2> Jesus tap dancing Christ.

Now even emojis are politicized and infantelized.

Good to know that my apple products are "safe spaces" now.</comment>


Lessons From How The Planet Communicated Their Data Center Explosion - <AUTHOR> http://ryanspoon.com/blog/2008/06/03/lessons-from-how-the-planet-communicated-their-data-center-explosion/ <comment><USER2> I'm not sure what lessons are to be learned here -- "be transparent"?

The author mostly complains that they are still taking new customers during downtime -- which is probably not good, I agree, but seems like nitpicking.</comment>


Two big challenges in machine learning [pdf] - <AUTHOR> http://icml.cc/2015/invited/LeonBottouICML2015.pdf <comment><USER2> It seems Léon Bottou is an important figure in Machine learning. His personal website has interesting stuff too.

[https://research.facebook.com/researchers/1558013787807218/l...](https://research.facebook.com/researchers/1558013787807218/leon- bottou/)

[http://leon.bottou.org/](http://leon.bottou.org/)

</comment><comment><USER3> I wasn't aware Leon Bouttou was with facebook as well now. They're building quite a research team. Interesting slides.

<comment><USER2> It's fascinating that now that things like deep learning have massive traction, people like LeCrun and Bouttou (both now at Facebook), who apparently pioneered the stuff, are taking a critical position on it - critical not being negative or dismissive but rather a "we have to see the limitations and good beyond them" approach.

See: LeCrun's What Wrong With Deep Learning [https://drive.google.com/file/d/0BxKBnD5y2M8NVHRiVXBnOVpiYUk...](https://drive.google.com/file/d/0BxKBnD5y2M8NVHRiVXBnOVpiYUk/view?sle=true)

<comment><USER3> To be fair, he's been talking about the relationship between theory and empiricism with regards to neural networks for some time now. See, for instance, page 12 here [1] (the titles of his talks all seem to be provocative questions; almost in a tongue-in-cheek sort of way).

One of the problems (in my opinion) with networks is that the analysis has always been post hoc. Personally, I think it's more preferable to build a method starting from theory [2] which can then be tested empirically to see if the assumptions of the theory hold. Then augment the theory, the method, and experiment again.

Now, there's nothing inherently wrong with post hoc analysis - it's just a different start point in the loop of science. However, because we didn't start from theory, the burden is then to extract some theory from empirical observation. Again IMO, this is can be problematic because:

1) It more easily allows for confirmation bias.

2) It leads to a multitude fragmented theories.

The second is why everything surrounding neural networks seems so incredibly ad hoc.

[1]: [https://www.cs.nyu.edu/~yann/talks/lecun-20071207-nonconvex....](https://www.cs.nyu.edu/~yann/talks/lecun-20071207-nonconvex.pdf)

[2]: The principles could be based on statistical learning (see SVM), neurophysiology (see work by Poggio or Olshausen), mathematical invariants (see work by Mallat), etc...

<comment><USER2> Thanks for the post, I was hoping for more discussion of this.

I'd be even more pessimistic about one's ability to go forward from empirical observation of opaque mechanisms.

Aside from your incisive observations, there's the point that if you have a "good" "working" "theory of how neural networks operate", what is it a "theory of"? It's dependent on the mechanisms that gather the test data, the sort of answer that a certain kind of person wants out of the test data and so-forth - the "epistemological" questions you didn't answer and couldn't answer will come to bite you.

I'd add that SVMs do seem more firmly founded but their ultimate tweak, the kernel trick plus projection onto feature space, is basically ad-hoc too - still much closer to a "real" probability model etc. The problem with SVMs is that they wind-up more or less equivalent to a 1st order neural network and thus they don't scale - once data becomes truly huge, they require too much storage.

Ironically, I think the best single overall critique of AI efforts was articulated by Paul Allen[1]. The problem is that in building large systems, people encounter a "complexity" barrier that prevents further progress[1]. Creating more complex systems to tackle that tends to fail as people wind-up understanding less and less of their own complex systems.

The problems with all the neurophysiological models is that raw neurons are very complex things and one doesn't know immediately which parts even carrying meaningful signals, a problem made worse by not having a model of what those "meaningful signals" might be.

Consider that if aliens looked at human-made microchips and tried to model them fully, they get the clock signal and various nonlinearities in the transitors right but have enough computation errors that no program would run on it.

Another good argument is that just all our methodology hinges on classical Western epistemology and a change in that may be necessary[2].

[1] [http://www.technologyreview.com/view/425733/paul-allen- the-s...](http://www.technologyreview.com/view/425733/paul-allen-the- singularity-isnt-near/)

[2] [http://aeon.co/magazine/technology/david-deutsch- artificial-...](http://aeon.co/magazine/technology/david-deutsch-artificial- intelligence/)

<comment><USER3> > if you have a "good" "working" "theory of how neural networks operate", what > is it a "theory of"?

I think we should make the distinction between theory pertaining to a task and theory pertaining to methods that perform (or approximate) the task. Certainly, the former can be incorporated into the latter, so the boundary is fuzzy. Actually, the previous is quite important because known principles of the task can be expressed mathematically and incorporated functionally into the approximation method. In this sense, a network architecture could arise naturally. In fact, it sort of does with anything with a cascade-type pattern.

On the other hand, if we're going to talk about the method (networks, in particular) independently of the task, this is more difficult. The question is now: is the network model remarkable in some sense? Meaning: is there some class of functions which are "best" or "more efficiently represented" by network approximations, and what are the properties of the class that make this the case? Yoshua Bengio has touched on this with regards to depth from the point of view of circuit theory, but the argument is basically: "here's a couple circuits which are more efficiently represented by increased depth, therefore deep = good always". It would be more interesting if there was a more rigorous analysis from a function approximation view. Perhaps literature exists on this. I'm not sure - I'm sort of rambling now.

> kernel trick plus projection onto feature space, is basically ad-hoc too

The choice of kernel - yes I agree, but the driving theory of the method is to maximize the margin, not choose the best kernel.

> Creating more complex systems to tackle that tends to fail as people wind-up > understanding less and less of their own complex systems.

Interesting. Maybe there's something going on with the relationship between entropy and complexity.

</comment></comment></comment></comment></comment><comment><USER4> Did I just read a powerpoint presentation?

<comment><USER2> Yeah, the presentation format is annoying but argument is good, in fact, the argument is really important.

Machine learning is about approximate reasoning but with no real guarantees of the approximation. Even if the approximation is usually very good, being occasionally bad can be "deeply problematic" when we don't have control over exactly how exactly the bad recommendations are created.

<comment><USER5> Isn't that what confidence intervals are for?

<comment><USER6> I'd say that's more what cost functions are for, but that is neither here nor there.

I think the biggest takeaways are...

1) Machine learning in large software projects is complex because decisions made by one algorithm can influence the data of other algorithms, creating massive biasing.

2) Simple cross-validation / hold back methodology is limited as we expand what we want machine learning to be able to handle. Reason: big data is too big and "correctness" is difficult to evaluate for things like Q/A systems.</comment></comment></comment></comment>


Apple Tablet 'Isn't Going To Cost Anywhere Near $1,000' - <AUTHOR> http://www.businessinsider.com/apple-tablet-isnt-going-to-cost-anywhere-near-1000-2010-1

<comment><USER2> Content free-flagged.</comment>


Ask HN: How do you invoice - especially you freelancers out there? - <AUTHOR>

Hi guys, I'm a relatively young bloke who does some freelance web development around my university and part-time job. This mainly means me either working from home, or driving out to an office or house with my laptop.
I'm interested in a simple invoicing solution which generates a professional PDF. I don't mind if the solution is a downloadable program or webapp, however something which I can have running real-time that takes away the burden of monitoring my time would be great, especially if it's integrated and not in itself a separate application. Something that goes further and monitors time spent on a single task would be great too, both for me so I can evaluate time management, and for the customer so they have a much more detailed invoice and are better able to see where their money is going.
So, how do you guys invoice, and (if you have time to detail further) what would you suggest for my circumstances? <comment><USER2> Try <http://getharvest.com> for time-tracking + invoicing. Plans are cheap (the $12/mo starter plan should suit you) and you can easily interface with services such as Basecamp and QuickBooks should your business grow into the need for it.

<comment><AUTHOR> I see. I'll look into it, thanks. Not too sure how keen I am on the subscription model, though. I much prefer 1-off payments if I'm going to pay.

</comment></comment><comment><USER3> We use Blinksale <http://www.blinksale.com/home> for invoices and TikTrac <http://tiktrac.com/> for time sheets. Very cheap and easy to work with. You can try both for free.

</comment><comment><USER4> Hi,

i had the same problem so developed my own lamp based app Simple Invoices - <http://www.simpleinvoices.org>

its free/open-source - does PDF invoices blah blah

doesn't do time tracking though

Cheers

Justin

<comment><AUTHOR> I don't have time to check it out now, so I'll gloss over it tomorrow... but I think I might just have to kiss you (run away now). This seems to be exactly what I'm looking for!

I'll drop another line and some feedback after trying it in the morning!

<comment><USER4> no worries woodsider

also you can check out a demo at <http://www.simpleinvoices.org/demo> if you don't have time to do the install

cheers

justin

</comment></comment></comment><comment><AUTHOR> In the quest of self-research I've come across <http://www.curdbee.com> and <http://www.invoicejournal.com/> and <http://klok.mcgraphix.com/klok/index.htm> \- has anyone had any experience with these services?</comment>


Your washing machine could make you money with an 'Uber for laundry' - <AUTHOR> http://www.thememo.com/2016/11/28/your-washing-machine-electrolux-could-make-you-money-with-an-uber-for-laundry/ <comment><USER2> _Would you use it?_

Honestly? No. I'm curious what others think but my trust for the 'gig' or 'sharing' or whatever new %adjective% gets conjured up next week by %news_outlet% is entirely gone.</comment>