Hacker News new | past | comments | ask | show | jobs | submit | nextw33k's comments login

"you should never use your own crypto code"

The sentiment behind that is to keep out those that don't know how to code. If everybody followed that advice there wouldn't be crypto code.

If you have the ability to create good code and are confident you can understand the maths of cryptography then by all means contribute to the community. If the past year has taught us anything it's that the crypto community needs more good engineers.


The sentiment should be "write your own code, but don't use it without independent audit". There's another recent discussion about it here: https://www.reddit.com/r/crypto/comments/418nyl/write_crypto...


People write their own toy kernels or malloc()s all the time, and there's never the assumption that they would actually try to use them for real, and the security implications are just as real there as for toy crypto.


That's not entirely true though. IPv6 has been prioritised on various devices and Google taught us over a decade ago that response time makes the web experience feel better to the user.

You'd better be on dual stack if you don't want your users to think the competitors feels faster/smoother. Otherwise you'll be the Yahoo of your market.


Not true at all - the problem is that IPv6 routes are less mature and less monitored than IPv4 routes, so using v6 preferentially is actually often slower.

I work with VOIP and we had to disable v6 for our customers because we were getting complaints about latency issues repeatedly from customers on v6. Disabled IPv6, no more complaints.

IPv6 is more likely to make you "the Yahoo of your market" than the inverse, especially if you work in latency sensitive applications.


This is contrarian to real world testing:

http://www.internetsociety.org/deploy360/blog/2015/04/facebo... https://www.youtube.com/watch?v=EfjdOc41g0s

Facebook and many other companies are finding that IPv6 is faster, personally at home I have found that disabling IPv4 allows me to more quickly buffer and stream Netflix, and about 30 - 40% of my traffic is IPv6. My Apple TV is the last hold-out that still seems to use IPv4 over IPv6 for Netflix.


It's actually not too contrarian - The problem isn't the average speed or what happens when things are working, it's what happens when it fails or when things need servicing. Packet loss and latency or slow response times for servicing of the routes affected our customers greatly. Far more than a small bandwidth improvement would buy us on a service that isn't bandwidth constrained at all.

In large part, this just boils down to the fact that less people use it, so less people notice problems and they're addressed less quickly. However, it makes it very unusable for applications like VOIP to customers when there are issues occurring. So while the bandwidth may be better on IPv6, I have no experience with that side of things personally, we're far more concerned with link stability - packet loss, latency spikes, that kind of thing. Again, just anecdotal, but not necessarily contrarian either.


Studies report the answer is yes:

http://www.bbc.co.uk/news/magazine-18233843


> It's just that you can't have your cake and eat it too.

You can build up instead of out.


I know the Pidgin project used to build their windows version on Linux using GCC and setting the make target.

You get a constantly up to date compiler (because of the system package management) and you don't need a MS license for your buildbot. It's a win win.


Yes they can grab the IPv6 address but IPv6 has a privacy extension to cater for this. It will alter your local IPv6 address periodically. You could configure it to update every hour and effectively they'd be thinking you were a new PC on the network.

IPv4 you'd have a small range of IP addresses but with IPv6 you can have a different IPv6 address each hour if you so choose.

http://www.internetsociety.org/deploy360/resources/privacy-e...


Thanks for that link (IPv6 newbie here, I really need to properly learn it some day...)


"New York must stand up to the hostile takeover being attempted by a Mafia-like Silicon Valley, in conjunction with predator banks,” Freidman said.

I understand someone is lashing out at losing their cash cow but I don't think I've heard Silicon Valley described as a Mafia before.

Can anybody explain how this is even a remotely comparable thing to say?


> I don't think I've heard Silicon Valley described as a Mafia before

You haven't ?

http://www.telegraph.co.uk/technology/11106473/The-PayPal-Ma...


It is in the creditors interest to only provide a short term solution. They want to see reforms actually put in place to ensure the money is going to where it is needed.

If Greece were given enough to tide them over for 10 years how do you think the government would spend it?

Debt management is about a partnership, where financial responsibility is learned but both sides. The creditors are learning to be more cautious and Greece is/has learnt to control its spending.


I don't know the exact details but I didn't think Iceland was in Europe, the UK wanted to rush them in so that those rules could apply:

https://en.wikipedia.org/wiki/Accession_of_Iceland_to_the_Eu...


Iceland is and was in the EFTA and hence in the EEA where the single-passport rules apply -- and applied back then as well, otherwise the Iceland banks operating in the UK and the Netherlands would have been under UK/NL supervision instead of IS supervision. UK/NL were not ALLOWED under those rules to meaningfully supervise IS banks operating in their countries. As long as they operated under IS law and IS supervision, they operated under IS insurance rules with the usual EU (EEA) 100k€ limit. Iceland blatantly broke the rules.

Later, after the shit hit the fan, Iceland did apply for EU membership and negotiations begun. Iceland later withdrew their application.


I would hazard to suggest those outnumber the skilled large organisations by quite a margin.


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: