maggit

FYI: https://news.ycombinator.com/item?id=5984223

Some information about WebM/VP8 hardware support: http://en.wikipedia.org/wiki/WebM#Hardware

Notably, "Nvidia is supporting VP8 and provides both hardware decoding and encoding in the Tegra 4 chipset."

I spend a lot of time on that site, and like you I generally think the strict criteria are a net positive.

However, I'd just like to add that I've seen lots of abusive language and misuse of powers to close/put on hold. Flagging of unnecessarily negative/harsh language is not in general followed up, which basically means that it is encouraged.

I initially interpreted "5D" in the title as five spatial dimensions, which would be incredible, but the reality is entirely credible:

> The information encoding is realised in five dimensions: the size and orientation in addition to the three dimensional position of these nanostructures.

We seem to be in full agreement. I only wanted to spell out my own reasoning for using curl and not wget, since you explicitly said you were interested in this information, and I suppose there are others that think like me in this regard as well :)

One popular UNIX-like OS that comes with curl and not wget is OS X. That might also drive adoption.

(I seem to remember having had to install both curl and wget on Ubuntu, but I am unable to verify this now)

> I'd be interested to see if many others on here do prefer curl over wget for pulling binary files.

This is how I ended up consistently prefering curl:

Last time I looked closely, I had better control with curl, and curl had better support for stuff. For example HTTP 1.1 was supported by curl, but not wget.

This makes curl a far better choice for testing HTTP servers.

And next, since I now know curl pretty well, and have it installed all over the place, it is my go-to HTTP command line client. I don't know of any reason to use both, or any reason to prefer wget, although in some situations maybe "wget <url>" acts slightly more like you want than "curl <url>". (Which is of course easy to work around by using "curl -OL <url>", if that's what you want, but convenient defaults are still convenient)

I'd say it's a paradigm. For whatever that's worth ;)

Yep, you're right.

I was thrown off by the fact that Elliptic Curve Diffie-Hellman has public and private keys. I figured you weren't talking about the DH part when you talked about public and private keys.

Today I learned more about Elliptic Curve Diffie-Hellman. A good day. Thank you :)

Of course! I apologise!

I was thinking that the adversary would discover the private keys and then learn nothing, but he can of course attack the DH exchange. My bad.

Edit: Sorry, I was confused. I missed out on the part where the adversary attacks the DH exchange, thinking he would only try to get to the private keys. Original gripe below.

----

This guy has not understood forward secrecy. The session key is never transmitted, not in clear text, nor in crypto text.

Forward secrecy over SSL is achieved by using Diffie-Hellman key exchange in combination with public key crypto. This makes sure that as long as the private keys are not compromised, the DH exchange is immune to a man in the middle-attack (which otherwise is the weak point of DH).

Recording the communication between the parties will therefore not yield any information even if the private keys are leaked or otherwise discovered in the future. So solving discrete logarithms or factoring numbers quickly in the future does not break contemporary forward secret communication.

(Read, for example, http://en.wikipedia.org/wiki/Perfect_forward_secrecy )

----

Okay, so after re-reading, I'm still inclined to believe he hasn't fully grasped forward secrecy, or at least is misrepresenting it here:

> If the NSA can break the public keys used for your sessions, and derive their corresponding private keys, it can decrypt all of your sessions, regardless of whether you used “perfect” forward secrecy.

This is still not true. What is true, though, is this: If the adversary can solve discrete logarithms (or whatever's the appropriate difficult problem) quickly, they can decrypt your session. Not simply because they get your private keys, but because they get your private keys and are able to defeat DH.

----

And finally I understand why I'm wrong and he's right: Elliptic Curve Diffie-Hellman, unlike "regular" DH, uses public and private keys. The passage I quoted above is indeed talking about breaking the DH exchange. TIL :)

I agree in general, but you are painting with too broad strokes here:

> No part of cryptography has anything to do with the code.

There have been successful attacks against cryptography based on attacking the implementation. For example if two code paths take different time to execute, it is possible that this leaks information.

This is another reason why you should use a well honed library implementation of cryptography, for example OpenSSL.

This does of course not imply that the crypto–the maths of it–is broken. One just needs to be aware that it is not, in fact, sufficient to implement the maths correctly.

You should try it on a retina mac. It's awful!

However, I am willing to put up with this for a while until maybe I can create an alternative client or something. Private communication is pretty important to me :)

Apparently there's some separation of front-end and back-end, with the possibility of running alternative front-ends. See near the end of this blog post: https://retroshareteam.wordpress.com/2013/01/27/using-retros...

Is Qt 5.1 poorly integrated with Android? Have you experienced this, or are you simply assuming it?

Working with Qt could be a huge productivity boost for me compared to working with the standard Android SDK. I could have more time available to make it look and work well, and I would be able to reuse core application code (not UI code, mind you) across platforms.

Isn't it premature to declare this a categorical disadvantage for the user?

I agree. What you are saying is really important, and using RetroShare does not seem to be the correct solution to mark_integerdsv's problem.

> a few friends talking freely behind closed doors? Even dictatorships have that.

But I feel that I do not have this across the Internet! It is good to be able to talk freely behind closed doors, too. This is why RetroShare seems to solve an important problem for me :)

While it is not technically impossible to discover backdoors in closed source software, I'd say it's essential for me to trust crypto-software that it is open source.

That being said, it is probably feasible to hide a backdoor even in open source software. But it is still easier in closed source software.

I've recently started developing something like this. Now it looks like I might not have to. Thanks!

I found RetroShare worthy of its own submission, given today's climate: https://news.ycombinator.com/item?id=5983913

Second the "mass" problem. I didn't experience either misses or false alarms with the stupid phones I had before, but as my phone has been growing smarter and bigger, the vibration engine has turned into something that primarily makes noise :/ In fact, I hardly get "hits" any more :(

On the other hand, electric cars mostly get charged over night. The need for a battery swap or a stop for super charging should be much less frequent than the need to refill gas. It is hard to make a direct comparison.

I recently tried replacing Dropbox with Wuala because of privacy concerns. I failed, and in the process realized how successful Dropbox has been in creating an awesome user experience!

I'm still looking for a locally encrypted Dropbox-alternative. So if any of you are making one, please speak up :)

(Edit) I should specify that it was the user experience that made me give up on Wuala, and any proper Dropbox alternative would need to offer at least decent user experience. Looking forward to trying the alternatives you are suggesting :)

I agree.

While we wait for him to add the pictures, we can dig them out ourselves from amazon: http://www.amazon.com/gp/reader/1489522212/ref=sib_dp_ptu#re...

Use the "Surprise me"-link to get to a page inside the book.

For interest, I have now tested Chrome, Safari and Firefox on my machine (OSX), and of those the named anchor only works in Firefox. Strange.

Link to relevant place in video: http://www.youtube.com/watch?v=h3OC_mKo2Fk&t=341s

(Somewhere along the way the & in the parent's URL turned into #)

Mildly related, and mildly humorous: After the last update to my phone I've started randomly experiencing dips in responsiveness. It might be doing GC or some other heavy tasks, but it remains in low (not zero) responsiveness for several seconds.

Whenever I experience it, I start tapping the back-button furiously, in a quick steady rythm, causing a pileup of tap-events. These will be dispatched in batches, each tap causing a small buzz in the vibrator engine. When the buzzes start happening at an even pace, I am back to having a responsive phone.

The purpose of this behaviour is to know when my phone is usable again, but it kind of evolved from me just wanting to see if I could provoke it or whatever. People are curious things.

I don't have a problem with relational databases. Or rather, I don't have a problem with relational data modelling.

I do have a problem with Oracle. Even the Oracle experts at my former job could barely get Oracle to do something sensible, and running it on my own computer was basically a death sentence for getting anything done.

I have a problem with MySQL, from a sysadmin perspective. When I had it installed, MySQL was the package that would always break on every update. No upgrade was small enough that the data files would continue working.

(I don't have experience with Postgres, but SQLite seems more comfortable than any of the mentioned alternatives)

I have a problem with schemas in my database. It requires upfront work with modelling my data. I'd rather iterate. Also, nobody I've worked with seems to put the schemas in automatically; you need to run the special "initdb" script that isn't maintained to make it start working.

I have a problem with SQL. It would be awesome if we had a standard query language, but we don't. You can't apply the same SQL to different database engines mostly because it won't even compile, secondarily because it will give different results and finally because it will have a completely different performance profile.

All of this can be fixed by learning stuff, so I know better what I am doing.

But I already know CouchDB [1]. It took me little effort to learn, and it makes a lot of sense to my mind. I can solve problems with it, and it has neat properties with regards to master-master replication. So for me, CouchDB works just fine, just like a relational database works just fine for you :)

So, from my perspective, it seems that using some SQL solution would be the time consuming option.

[1]: CouchDB can't be considered a "Big data" database for many cases. It is slow. But it scales neatly :)

You could do something like:

  <script
    src="my-copy-of-jquery.1.9.2.js.min"
    cannonical-uri="https://jquery.com/jquery.1.9.2.js.min" 
    hash="SHA1-blablabla"
  ></script>

With this setup:

1. Old browsers could work as before

2. New browsers could download your resource and cache it with the cannonical-uri and calculated (not declared!) hash as cache key (no dependency on third party CDNs)

3. New browsers could serve this resource from cache if it had downloaded it before with matching cannonical-uri AND hash, disregarding src and host

The hash would make sure that the jquery the user downloaded from whereever would indeed be the same jquery you are serving up.

----

Going back to your original idea, browsers could absolutely come with prepopulated caches for such resources, but they might as well fill these caches on demand.

The important thing in both cases would be to allow shared caching between sites without forcing everybody to agree on which CDN is the most pleasing. Notice that the cannonical-uri is only a name, it is not supposed to be dereferenced.

Yes. They call it "hidden classes": https://developers.google.com/v8/design#prop_access

You say "Installing Linux is really easy", but in my experience installing Linux on a Mac is really involved. It could be the case that it has become easier. Would you say it has become significantly easier with newer models?

There are some instructions for installing Ubuntu on a Mac here: https://help.ubuntu.com/community/MactelSupportTeam/AppleInt...

It involves installing a bootloader (rEFIt, which starts GRUB), partitioning in OSX, partitioning in Linux and variants for different possible desired outcomes. After this, one should consider model-specific instructions for getting more details right (See https://help.ubuntu.com/community/MacBookPro)

Finally, in my experience, it will be a little off. The trackpad won't act just right, the backlight of the screen will have full brightness when starting X, etc. ("Thunderbolt Support Still Has Problems On Linux", December 2012 http://www.phoronix.com/scan.php?page=news_item&px=MTI1M...)

----

Is this what you consider "really easy"? Does it fulfill the requirement "The hardware must work well with linux"?

As far as I can tell it isn't, and it doesn't, but please enlighten me if you disagree :)

From memory, I seem to remember that the x64 name originally came from Microsoft. They certainly make good use of it, at least, so Sun/Oracle isn't alone :)

Just to fill in a (the?) missing piece in an otherwise well assembled puzzle ;)

In general, no, natural gas is not part of our infrastructure and people don't use it for heating. This has to do with our easy access to hydroelectric power.

> Burning wood is also completely unnecessary, because in the developed world we invariably have better and cleaner alternatives for heating our homes.

This assumption seems to be at the center of his argument (about the fireplace, not the analogy-part). However, in my modern apartment here in Norway it is regularly so cold that I am unable to heat it properly without using my wood-burning stove. So it is not recreational.

With regards to environmental impact, Norway is no stranger to legislation and have mandated that all new stoves are catalytic [1] since 1998. I am not sure how this impacts the findings referenced in the article, but I am sure that this is one of the possible things to consider other than "ban everything" or "legislate nothing".

In conclusion: Of course smoke is bad for you. Bad air quality is a big problem in winter in my town. But I need the heat!

[1]: Or "clean burn". Unsure about the English nomenclature here. http://en.wikipedia.org/wiki/Wood-burning_stove#Catalytic_an...